文档介绍：用BigTable的原则和关系数据库的原则比较2008-06-3013:05在infoq看到这一篇优化使用BigTable的原则与方针,觉得对做大规模数据库设计时有很大参考作用,特拿来与关系型数据库做一下比较。Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价,只有在以下情况下使用BigTable才能带来益处:a)需要伸缩到巨量的用户数,b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”,所采取的理论路线与关系数据库中的做法存在根本的分歧,很可能初看起来是迁背直觉甚至相当冒险的。关系数据库的世界是以防止错误为根基的;以正规化(normalization)为工具消除重复和防止更新异常。为了提高可伸缩性,数据应该重复而非正规化oFlickr久悬着了这种路线,决定让“评论重复出现于评论者和被评论者两个用户数据分片中,而非单独建立一个评论关系”,因为“如果把用户数据分片作为可伸缩性的单元,就没有地方放置这种关系”。因此,虽然去正规化(denormalization)违背了“关系数据的伦理”,但它是BigTable数据范式不可缺少的组成部分。=〉其实很多时候在做系统设计时,为了应付将来可能的大规模情况,根本都不考虑数据库里面的那些范式要求,一切的目的都是为了可扩展性和性能。比如把复杂的字段合并在一起变成id=>data的结构,设计很大的数据冗余,外键约束也很少考虑,类似join这种关系型数据库特性基本不用……为了可扩展性和性能,无所不用其极,而关系型数据库本身的一些设计范式倒放到一边To有时以后用数据库只是因为数据库提供了缓存、数据文件管理、并发、基本的数据格式管理、复制备份‘Cluster等必不可少基础特性,即使有时候关系数据库系统不足以发挥系统的最大效能,使用它也算是性价比很高的一种方案。在以上论述的基础上,Todd针对优化使用BigTable存储系统总结了若干必须牢记的原则:•假定数据访问是较慢的随机访问而非较快的连续访问。因为“在BigTable里数据可能放在任何地方[……],平均读取时间可能相对较l=J=〉在数据库里一般数据的扫描加载,原理上都是从前往后逐行筛选得到结果的,但是由于数据在物理硬盘上实际不一定连续,所以最终差不多都是随机访问数据,真正连续访问的情况很少。而按照BigTable的原则,它的数据你只能认为随机存放、随机访问,必须针对这种特性来设计。平均读取时间可能相对较高(这个我认为还是要看最终系统设计的好坏)•为并发读取对数据进行分组为了最大程度提高并发读取,应该去正规化。也就是说,“应该改变实体的存储方式,使得一次读取操作即可读出整个实体,避免执行会导致多次读取的join操作”,并且“将属性复制到需要使用它们的地方。”=〉就像上面提到的Flickr对评论数据采用的存储策略,这种方式在以往的数据库里面是很难接受的。采用这样的方案也都是因为数据分片所需要的,同样的道理,如果在数据库里面采用数据分片,基本上也是往这条路上走。茴盘和CPU都很便宜,不要再为它们操心,尽力提高可伸缩性吧……]你的应用可以任意地扩大规模,只要简单地增加新机器就可以了。所有可伸缩性瓶颈都已消除。”=〉有点夸张,看看Facebook的上亿美金主要用来买服务器了说不用考虑cpu和硬盘那是有点撤了,不过可伸缩性