反范式在海量数据库设计中应用.docVIP

反范式在海量数据库设计中应用 　　摘要 所谓反范式，即不完全按照范式的理论来设计数据表结构。本文就海量数据存储下数据库设计的一些反范式方法进行讨论，旨在解决海量数据中因大量的表连接操作而带来的性能瓶颈问题。 　　关键词 反范式；海量数据；关系数据库；哈希关联；字段冗余 　　中图分类号TP392 文献标识码A 文章编号 1674-6708（2011）38-0214-02 　　随着关系数据库理论的不断发展和成熟，加上关系数据库在消除数据冗余、保持数据一致性上的优异表现，目前在数据领域使用最多的是关系数据库。因此人们一谈到数据库，几乎都是指关系数据库模型。 　　构造关系数据库必须遵循一定的规则，我们称为范式。在关系数据库中，范式有六种：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。其中第一范式（1NF）即满足数据表中不重复列；在第一范式的要求的基础上，满足非主属性非部分依赖于主关键字即为第二范式；以此类推，范式级别越高，数据库设计的要求也越高。同时随着范式的增高，数据库的冗余逐级减少，数据一致性逐级增强。在实际应用中，大部分的数据库只要满足3NF即可。 　　然而关系数据库理论亦存在不足之处，范式越高，数据模型越细，意味着需要更多的数据表，这使得程序在运行过程中需要更多的表连接操作，尽管部分数据库系统支持存储过程等技术，但这并不能带来革命性的效率的提升，尤其是当需要连接的两张或者多张表数据非常庞大的时候，表连接操作几乎是一个噩梦。 　　本文就海量数据存储下数据库设计的一些反范式方法进行讨论，所谓反范式，即不完全按照范式的理论来设计数据表结构，旨在解决海量数据中因大量的表连接操作而带来的性能瓶颈问题。 　　1 字段重复 　　字段重复在关系数据库中是最常见也是最有效的一种反范式的设计方法，是一种典型的以空间换时间的设计理念。这种设计理念随着硬件产品更新和降价不断加速，而被越来越多的人认可和采用。许多大型公司甚至直接通过扩大存储和提升硬件的处理能力来提升程序的运行效率，因为这样的成本和风险甚至比升级程序所带来的要小得多。以下是一个典型的例子： 　　通常情况下查看文章列表，都会显示文章标题、作者、发布时间等，此时作者需要通过uid连接用户表得到用户姓名。由于实际应用当中，用户名是很少修改的，甚至有些应用的特殊需要，用户名是不允许修改的，所以更高效的做法是，用户名在文章表中重复一次，如下表所示： 　　字段冗余适用于那些不经常变动，甚至不允许变动，但又经常需要通过表连接而获得的字段，可以将该字段和字段直接冗余到对应的表里。 　　字段重复还有一种情况就是在父表建立统计字段，比如：文章通常会显示对应的评论条数，这样就需要去评论表统计文章出现的对应评论的数量。可以通过在文章表建立评论总数字段，减少大量的聚合操作。 　　2 分表存储 　　分表存储，顾名思义即把一张完整的表分成多张子表。分割方法有两种：水平分割和垂直分割。我们通常说的分表存储多指水平分割。 　　2.1 水平分割 　　水平分割一般用在单张表数据量非常大的场合，比如一张表的数据已经超过了1 000万条，即使合理的设置了索引，通常这样的大表在检索和数据插入时的表现都会不如人意。此时可以将表水平分割成多张表，并增加一张索引表。如下图1所示： 　　我们也可以用水平分表的方法将表中陈旧的历史数据分离开来，分成活动表和静态表，这种应用在论坛程序里较为常见，这也就是为什么经常看到历史帖子无法进行增、删、改操作的原因。 　　2.2 垂直分割 　　垂直分割一般用在单张表字段非常多的场合，如下文章表： 　　Article（aid,uid,username,title,excerpt,content, iscommend, viewnum, allow_comment,ischeck, postip, dateline） 　　实际情况是，一个大型的CMS（Content Management System）系统，它的文章字段可能更多，比如文章来源，文章是否原创，文章查看密码等字段。然而查看文章列表时常见的就3、4个字段，其余的在查看文章详细页面时才有用，因此为了提高文章的读取速度，可以将文章表一分为二如下两张表，在必要的时候进行表连接操作。 　　Article（aid,uid,username,title,excerpt,content, ischeck） 　　Article_ extend （aid, iscommend, viewnum, allow_comment, postip, dateline） 　　通过表垂直分割，将表中的繁重和轻松的字段分离出来，避免持续物理扫描很少使用的数据