zoukankan      html  css  js  c++  java
  • 海量数据挖掘--DB优化篇

             上一篇博客我们介绍了针对大数据量的处理,我们应该对程序做什么样的处理,但是一个程序的优化是有底线的,我们要考虑人力,物力,程序的优化是海量数据处理的一部分,这里介绍我们的重头戏,对数据库的优化!

             这里我们将数据库的优化,分为三个大的方面:


             


    一,设计之初优化

         1,反范式思维

             在数据库优化的方向上,没有什么范式是绝对的,我们要根据情况设计合理的表结构,一味地追求完美的三范式是一个错误且固执的想法!

            举例:大家看看这两个考试记录表的设计区别:

            

             分析:

             我们看,哪个更符合三范式呢,明显是第二个,因为第一个设计有分值这个字段的冗余,也有得分的冗余,这样看第二个是合理的!

              但是在实际考试中,每个专业和每个专业的考核标准不一样,分值有可能完全不一样,这时我们在第一场考试每个选择题1分,但是第二场考试每个选择题3分,难道我们要重新导入一个新的题库吗?明显第二个要这么做(知识其中一个解决方法),这时就增加了数据量,也增加了处理难度!

            由此可见,适当的反范式更利于数据的存储和检索!

        2,建立索引

            我们理解的索引,是数据库什么都不用改,建立索引之后就可以增加查询效率的机制,但是,哪有百分百完美的解决方案,索引的建立,确实帮助我们较为有效地解决了查询的问题,但是在增,删,改的操作上,就不会那么出力!关于怎么解决这个问题,我们下边会有讨论!为了更好滴利用索引,我们要坚持几个原则

             原则一,索引字段必须最常用

             原则二,多个索引,首个索引保证常用

             原则三,索引字段能够和其他字段明显区分

        3,回归三范式,对表进行合理的划分

            这次我们要回归三范式,要对我们的表进行合理的划分,对数据进行有效的分流,这里主流的方法有两种,水平划分和垂直划分。

             我们用一张表的图来理解这两种的区别:

             


            

            

              这里的划分手段也是多种多样的,可以将表从逻辑和物理上都拆开,也可以逻辑上在一起,物理上是拆开的(类似于视图和表之间的关系)!

        4,分配合适的字段类型,减少冗余

              一个好的数据库设计,要做到合适,这个问题就是空间利用合适,同样是1万条数据,本来这个数据就简单16位就可以解决,如果用用32位的类型存储整个空间就多出去一倍,检索效率就会下降一半,这个例子告诉我们,合适的空间,就意味着更高地检索效率!


        5,非关系型数据的处理

             我们的设计中,有时会用到非关系型数据,比如图片,我们怎么处理,他是数据处理的一部分,但是SQL又力不能及?怎么办?这时候我们可以单独拿出这个问题,可以存在一个文件夹下,但是数据就会暴露,我们这时就不要死守SQL的阵营了,这时候可以考虑考虑去非关系型数据库找找出路,思路就会一下子打开!


        6,合理外键

            数据的设计之初,每个数据和每个数据都会有看见或者看不见的联系,我们设计主外键的时候,对外键的设置要格外慎重,主键的设置就是一个表的变化,而外键的设置是一个表群的变化,外键过多,过于复杂不仅仅增加了数据处理的灵活性,也增加了数据处理的时间(具体原因参考上一篇博客),外键要精简且合适,该有必须有,改减少的就必须减少!

        7,时机的把控

            初步的DB设计,我们会想,改怎么用数据语句,就怎么用,改写就写,改查就差,但是,这是初级的水平,更高层次的发展,要综合考虑,我们不一定写入数据和处理数据同时进行。

            举个例子,比如考试,学生考试,学生的答题记录的写入和分值的计算还有统计的结果。我们应该分开进行,把数据库的压力,分到不同的时间,比如晚上,决不能影响这场考试的进行!


    二,SQL语句

        1,日志

            在程序建立之初,我们建立日志系统时,应该考虑到以后的升级和优化的问题,这时候建立个系统“慢日志”显得很有必要,为我们的系统建立个日志,用来检测SQL语句的执行大于预定值的事件,让我们在分析的时候能够很好地通过这些日志了解我们的系统,分析优化的部分。

            除了“慢日志”我们还要有“满日志”,用来记录CPU利用率超过80%的时间及事件,让我们对我们的系统有个全面清晰的认识!

        2,全索引扫描

            如果我们想更好滴利用好我们的DB,适当的实际,对系统进行整理是必要的,这时候,我们可以对数据进行一个整体的全索引扫描,提高我们的效率!


    三,资源

        1,参数

            这里的内容是对数据库的进一步优化,对数据库的参数根据实际的情况进行调整,比如查询超时,如果一个查询真的需要2分钟,我们不妨就暂时将30秒的超时改为3分钟,但是这是表象的解决,我们还是尽量做到数据的读取控制在30秒内,给用户一个好的直观感受!

             还有参数是SQL对内存的占用,我们有的系统是控制了SQL对内存的占用,这时在优化查询的同时,增大内存的占用就可以很好的解决我们的饿问题!


        2,硬软件资源

             这是最后一个问题,也是个耗钱的工程啊,一个DB软件会升级,电脑配置会更新换代,在合适的时机投入资金升级自己公司的软硬件系统,跟上世界潮流的变化才是硬道理!想想Google的服务器,为全世界人民服务,它也在时刻追被更新换代,有时候的资金投入恰恰是在进行成本控制!


    总结:

            在我们的学习中,我们最大的优势是我们有错误可以犯!错误使我们印象深刻,在公司中,什么是经验,经验就是我们不会犯大多数人都会犯的错误,所以在今后的学习中,要珍惜每次犯错的机会,这是我们提高最快的地方!要珍惜每个为大家服务的机会,这是我们将要犯错的地方!更要珍惜每次的现场学习,这是使我们永远忘不了的地方!与大家分享,让我们在走向大鸟的道路上,共同努力……


  • 相关阅读:
    Jquery 图片走马灯效果原理
    jquery实现跑马灯效果(一)
    jQuery实现网页放大镜功能
    JavaScript仿淘宝实现放大镜效果的实例
    jquery实现放大镜简单方法
    jQuery实现放大镜效果
    小白jquery横向菜单弹出菜单制作
    转载 Log4j2在WEB项目中配置
    Struts2关于命名空间的例子
    转载关于struts命名空间的一则报警
  • 原文地址:https://www.cnblogs.com/javawebsoa/p/3225739.html
Copyright © 2011-2022 走看看