架构设计—数据库的性能与建模

         数据库的设计无非就是在数据的完整性、一致性和并发性之间玩平衡。在不同的业务场景下总是会或多或少的偏向其中两个方面。乍一看貌似这和数据库的架构设计密切相关，可是事实真是如此么？性能方面我们举一个耳熟能详的公认原则读写分离、分表分区为例来说，这些明显是由业务系统划分并主导的。只不过在具体的数据落盘上体现出来了而已，怎么能落到数据库架构上面呢？至于数据建模更是考验了一个系统的抽象组织方式，简单的说，如果完全按照数据建模的三大范式来解构一个系统的话，那么抽象组织方式必然是有缺陷的。这两个论断可能有些粗暴，但是我们不妨以一个经典的选课系统为例来看。
        在一个经典的选课系统中，明显存在的参与方有学生、教师、课程、教室等四个实体要素和不太明显的参与方选课规则、考试记录等两个抽象规则要素。这六个要素的基本属性我们都是可以明确的按照第一范式的要求确定出来，可是对第三范式的要求我们就有些力不从心了，最简单的例子就是名称这个属性，在四个实体要素中是必然会出现。单将这个字段单独抽象成一个表绝对是少之又少的(很不幸，笔者曾犯过这样的错误，参见律师管理系统)。事实上我们对于这个例子中的数据库设计大部分情况下就是按照这样的垂直映射方式进行的。有人说你这个映射也太粗糙了。至少学生和教师之间的共同点太多了，至少应该再加上一个人表。嗯，听起来挺好，看起来也挺好，至少让第三范式违反的不是那么难看。
         在传统行业中，比如学校内这么做，不是很美(毕竟多少违反了一些范式三)，但也是很美了，可是如果在一个开放的环境中(比如互联网)真这么做了，考虑到数据的增长量的话，很多时候我们是哭都没有眼泪的。在传统行业中，虽然学生的增长量是远大于教师的，而且学生的增长消失规模是明显的比教师大得多。但是每年入学、毕业的学生也不过几万人了不起了，人这个表的增长规模还是可容忍的，就以每年入学、毕业10w人计算，一个二流的数据库支撑上100年也能勉强凑活，毕竟对于单表1000w数据来说，如果主键，索引设置得当的话，性能还是有所保障的。
      可是如果放在一个开放的环境中，动辄几千万甚至上亿的学生当期涌入时，人这个表的存在就要大打折扣了。因为此时，我们让位的只能是性能，因为没有一个数据库敢打包票在这种数据量下还能保持良好的并发性。转了一圈我们貌似又回到了原点，因为我们发现，这四个实体和两大规则其实没有更多的让我们去遵循数据建模的那些条条框框，因为很多时候变成我们去适应范式一都是一种奢求。比如当我们发现当我们对学生表根据某种规则分区分表后，考试表也会无可奈何的跟随着这些规则进行分区分表，更多的时候如果大家都很好学甚至过分好学，，学生表和考试表jion一把虽然耗时很大，但是得到的信息也多，我们也可以欣慰一下，可是如果大部分学生都不是那么好学的话，那我们只能表示很悲催，jion的代价太高了，高到针对某一个具体的学生，我们宁愿去牺牲范式一，也要把他的考试成绩作为学生表的一部分来处理了，权当做缓存了。在这种情况下，数据的二次建模又意义何在？
       问题是这还没完，在这种情况下，当我们想去利用(关系)数据库中最得意的集合运算、聚合运算去做一些统计分析工作时才发现悲剧仅仅是刚刚开始。于是代表主流的map reduce不可避免的需要登上舞台，map reduce看起来很是高大上其实说穿了就是归并算法的再表述。对于归并算法，大家都很熟悉，就不罗嗦了。你说到现在独立于整个业务场景的数据建模还有什么意义。