海量数据挖掘--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的服务器，为全世界人民服务，它也在时刻追被更新换代，有时候的资金投入恰恰是在进行成本控制！

总结：

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