BigTable的使用原则处处透着Web 2.0的设计原则，也是BASE原则的体现（牺牲一致性），BASE原则是Web 2.0设计的高度抽象
================================================
从围绕着Google App Engine的大量讨论中，Todd Hoff总结出了一组优化使用分布式及高可伸缩性存储系统——如BigTable——的指导原则。Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价，只有在以下情况下使用BigTable才能带来益处：a)需要伸缩到巨量的用户数，b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”，所采取的理论路线与关系数据库中的做法存在根本的分歧，很可能初看起来是违背直觉甚至相当冒险的。关系数据库的世界是以防止错误为根基的；以正规化（normalization）为工具消除重复和防止更新异常。为了提高可伸缩性，数据应该重复而非正规化。Flickr久悬着了这种路线，决定让“评论重复出现于评论者和被评论者两个用户数据分片中，而非单独建立一个评论关系”(hunter:绝！)，因为“如果把用户数据分片作为可伸缩性的单元，就没有地方放置这种关系”。因此，虽然去正规化（denormalization）违背了“关系数据的伦理”，但它是BigTable数据范式不可缺少的组成部分。
在以上论述的基础上，Todd针对优化使用BigTable存储系统总结了若干必须牢记的原则：
- 如果你的目的不是创建一个百万级用户访问的网站，那请不要使用BigTable（Hunter:译文好像漏了这条）。
Bigtable不是为了做OLAP或者其他传统关系数据模型下的使用而设计的；
- 假定数据访问是较慢的随机访问而非较快的连续访问。
因为“在BigTable里数据可能放在任何地方[……]，平均读取时间可能相对较高”。
(Hunter补: 在BigTable里面遍历数据是非常昂贵的，因为每次读取下一条记录都会涉及到一个远程某台机器的磁盘读写)
- 为并发读取对数据进行分组
为了最大程度提高并发读取，应该去正规化。也就是说，“应该改变实体的存储方式，使得一次读取操作即可读出整个实体，避免执行会导致多次读取的join操作”，并且“将属性复制到需要使用它们的地方。”
- 磁盘和CPU都很便宜，不要再为它们操心，尽力提高可伸缩性吧
“[……]你的应用可以任意地扩大规模，只要简单地增加新机器就可以了。所有可伸缩性瓶颈都已消除。”
- 围绕数据的用途来决定数据的结构
要提高查询速度，数据的格式应该尽可能与数据被使用时的格式接近。因此Hoff主张用“以应用为出发点的实体取代SQL集合”。必须强调“这种方式不同于面向对象的数据库”。行为不是绑定到实体上的，而是由应用提供的，“多个应用可以读取相同的实体，却实现截然不同的行为”。
- Compute attributes at write time.
这样可以“最小化读取时的工作量”，并能防止“应用程序遍历大量的数据”，因为这种操作是低效的。
(Hunter补: 由于遍历大量数据是昂贵的操作，因此如果要跟踪总数据或者平均值这类状态数据，建议在写的时候预先计算好，而不是每次通过读一批数据来计算）
- 创建大型的实体，允许可选的字段
放弃正规化和建立大量小实体的旧做法，应该“创建大型的实体，允许可选的字段，以便一次操作即可读取出全部需要的数据，运行时再确定存在那些字段”。
- 在模型中定义Schema
为了在去正规化的条件下，保证数据跨多个实体的一致性，schema必须“在代码中定义，因为那是唯一能跟踪所有关系和保证数据正确性的地方。”
(Hunter补：所有数据库访问必须通过model去读写，否则数据一致性会有很大问题） — key!
- 用Ajax隐藏更新操作。
以小的增量更新数据库是有利的。
（Hunter：由于更新是比较慢的，因此用Ajax将大量数据的更新由一个大的调用变为一批小量的调用，在用户体验上和系统承受能力上，可以取得较好的平衡）
- Put是昂贵的
由于“在一次查询中能执行的根新数量十分有限”，Todd建议“执行小批量的更新，并且由外部CPU来驱动。” — 跟上条比较类似
- 按显式费用模型设计
“点击查询表单的OK按钮，表示你确定准备为GAE的数据库操作而付费。”
- 将many-to-many关系包含到实体中，但减少关联元素的数量
由于“维护一个较大的列表相对低效”，所以应该“尽量将列表中元素的数量减到最小。”
- 避免无限制条件的查询
Todd建议只显示某字段最新的少量记录，因为“大的查询伸缩性不佳”。
- 避免出现对数据存储实体的争用
应该“避免全局计数器，即跟踪记录数量，且每次请求都要更新或读取的实体。”
- 避免庞大的实体组
“对实体组的写入是顺序执行的”，因此最好“使用小的、局部的组”。
- 共享计数器
将计数器分为N个，每次根据hash算法计算出偏移x，然后更新 x/N 计数器；读的时候，将N个计数器累加；这样的做法可以有效的避免写瓶颈。
— bingo，这个方法我们现在也在用啊….
Todd Hoff对上面的每一条原则都给出了深入的解释，对其中一些原则还引用了来自GQL讨论组的例子进行详细解说。
—— 原文这句话很有意思
Designing to scale for reads and taking the pain on writes takes some getting used to. It’s a massive change to standard relational tactics. But this is what it takes to scale web applications, even if it feels a little strange at first.
——-