用BigTable的原则和关系数据库的原则比较

用BigTable的原则和关系数据库的原则比较2008-06-3013:05在infoq看到这一篇优化使用BigTable的原则与方针，觉得对做大规模数据库设计时有很大参考作用，特拿来与关系型数据库做一下比较。Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价，只有在以下情况下使用BigTable才能带来益处：a)需要伸缩到巨量的用户数，b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”，所采取的理论路线与关系数据库中的做法存在根本的分歧，很可能初看起来是违背直觉甚至相当冒险的。关系数据库的世界是以防止错误为根基的；以正规化（normalization）为工具消除重复和防止更新异常。为了提高可伸缩性，数据应该重复而非正规化。Flickr久悬着了这种路线，决定让“评论重复出现于评论者和被评论者两个用户数据分片中，而非单独建立一个评论关系”，因为“如果把用户数据分片作为可伸缩性的单元，就没有地方放置这种关系”。因此，虽然去正规化（denormalization）违背了“关系数据的伦理”，但它是BigTable数据范式不可缺少的组成部分。==其实很多时候在做系统设计时，为了应付将来可能的大规模情况，根本都不考虑数据库里面的那些范式要求，一切的目的都是为了可扩展性和性能。比如把复杂的字段合并在一起变成id=data的结构，设计很大的数据冗余，外键约束也很少考虑，类似join这种关系型数据库特性基本不用......为了可扩展性和性能，无所不用其极，而关系型数据库本身的一些设计范式倒放到一边了。有时以后用数据库只是因为数据库提供了缓存、数据文件管理、并发、基本的数据格式管理、复制备份、Cluster等必不可少基础特性，即使有时候关系数据库系统不足以发挥系统的最大效能，使用它也算是性价比很高的一种方案。在以上论述的基础上，Todd针对优化使用BigTable存储系统总结了若干必须牢记的原则：假定数据访问是较慢的随机访问而非较快的连续访问。因为“在BigTable里数据可能放在任何地方[……]，平均读取时间可能相对较高”。==在数据库里一般数据的扫描加载，原理上都是从前往后逐行筛选得到结果的，但是由于数据在物理硬盘上实际不一定连续，所以最终差不多都是随机访问数据，真正连续访问的情况很少。而按照BigTable的原则，它的数据你只能认为随机存放、随机访问，必须针对这种特性来设计。平均读取时间可能相对较高（这个我认为还是要看最终系统设计的好坏）为并发读取对数据进行分组为了最大程度提高并发读取，应该去正规化。也就是说，“应该改变实体的存储方式，使得一次读取操作即可读出整个实体，避免执行会导致多次读取的join操作”，并且“将属性复制到需要使用它们的地方。”==就像上面提到的Flickr对评论数据采用的存储策略，这种方式在以往的数据库里面是很难接受的。采用这样的方案也都是因为数据分片所需要的，同样的道理，如果在数据库里面采用数据分片，基本上也是往这条路上走。磁盘和CPU都很便宜，不要再为它们操心，尽力提高可伸缩性吧“[……]你的应用可以任意地扩大规模，只要简单地增加新机器就可以了。所有可伸缩性瓶颈都已消除。”==有点夸张，看看Facebook的上亿美金主要用来买服务器了说不用考虑cpu和硬盘那是有点撤了，不过可伸缩性确实是非常重要的，先满足了这一点再考虑CPU/硬盘吧:)围绕数据的用途来决定数据的结构要提高查询速度，数据的格式应该尽可能与数据被使用时的格式接近。因此Hoff主张用“以应用为出发点的实体取代SQL集合”。必须强调“这种方式不同于面向对象的数据库”。行为不是绑定到实体上的，而是由应用提供的，“多个应用可以读取相同的实体，却实现截然不同的行为”。==这应该是一种缓存的策略，无论用BigTable还是数据库，这种方式都是不错的。一般应用场景有：点击数统计中一般只需要知道最终统计数字，而不用知道每一次点击的详细信息，这时候直接存一个统计结果+实时更新就可以了。在其他类似的场景下都可以做这样的处理，比如每个月的财务统计数据，在月底的时候先统计计算好，后面查询的时候直接调用就可以了。Computeattributesatwritetime.这样可以“最小化读取时的工作量”，并能防止“应用程序遍历大量的数据”，因为这种操作是低效的。==这个道理跟上面的一样，上面是强调数据的格式，而这里是强调的计算时机，不过在实际应用中一般也不用区分那么细了。创建大型的实体，允许可选的字段放弃正规化和建立大量小实体的旧做法，应该“创建大型的实体，允许可选的字段，以便一次操作即可读取出全部需要的数据，运行时再确定存在那些字段”。==在使用数据库时，很多时候查询是这样的selectcol1,col2fromtablewherecontidtion（查询出更少的列，避免更多的io读操作），而表里面不止col1、col2列。如果说系统中不考虑缓存的应用，那读取更少的字段无疑是更好的，但是在大规模的系统中怎么也得考虑使用缓存吧，因此直接读取所有的数据(select*)+实体缓存是种更好的选择。在模型中定义Schema为了在去正规化的条件下，保证数据跨多个实体的一致性，schema必须“在代码中定义，因为那是唯一能跟踪所有关系和保证数据正确性的地方。”==在数据库里面有表定义来约束数据，但是真正要保证数据的一致性，在不考虑故障的情况下，程序上有一致的数据处理逻辑是必不可少的。用Ajax隐藏更新操作。以小的增量更新数据库是有利的。==所有数据写的地方，一次更新量太大对性能的影响都是很大的。比如在数据库中使用大型的Blob字段，一般需要避免这样的操作和设计。Put是昂贵的由于“在一次查询中能执行的根新数量十分有限”，Todd建议“执行小批量的更新，并且由外部CPU来驱动。”按显式费用模型设计“点击查询表单的OK按钮，表示你确定准备为GAE的数据库操作而付费。”将many-to-many关系包含到实体中，但减少关联元素的数量由于“维护一个较大的列表相对低效”，所以应该“尽量将列表中元素的数量减到最小。”==目的就是减小数量、减小数据量。这也是存储系统很重要的原则。避免无限制条件的查询Todd建议只显示某字段最新的少量记录，因为“大的查询伸缩性不佳”。避免出现对数据存储实体的争用应该“避免全局计数器，即跟踪记录数量，且每次请求都要更新或读取的实体。”避免庞大的实体组“对实体组的写入是顺序执行的”，因此最好“使用小的、局部的组”。ToddHoff对上面的每一条原则都给出了深入的解释，对其中一些原则还引用了来自GQL讨论组的例子进行详细解说。其实无论采用哪种基础系统，最终都需要解决数据分片、线性扩展的问题，并且都会映射到物理io上和缓存命中率上，不同的系统各有不同的方案罢了。