Megastore-Bigtable上的封装

Megastore-Bigtable上的封装

Google在SIGMOD 2008上透露了Megastore部分实现细节，详情参考大牛James Hamilton的blog： perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx
大牛的文章固然不错，不过肯定不大好懂，下面我说一下我对文章的翻译+理解：
1. Google Bigtable只支持最简单的insert, update, del, ...等函数调用API，不支持SQL形式的API，这个转换工作放到了Megastore层次上来做。SQL对于异步Bigtable调用的支持需要仔细考虑。
2. 对于索引支持文章中已经说得很明显了，维护一个<索引，row_key>的索引表，更新时先更新数据表再更新索引表，索引项越多，更新效率越低，但是读基本不怎么影响，特别适合互联网这种读/写比例一般超过10倍的应用。
3. Megastore不提供通用的分布式事务支持，分布式事务仅仅限于同一个entity group。Bigtable支持单行的事务，而Megastore支持row key前缀相同的多行事务，如一个用户的blog, post, photo，可以将它们存在到Bigtable的一张表中，row key为user_id + blog_id + post_id + photo_id，这样同一个user的数据即为一个entity group。然而，这样就导致不能支持像百付宝、支付宝等电子商务转账事务，我暂时也还不清楚支持同一个entity group内部的事务意义有多大，即有多少web应用需要这种同一个entity group下的事务支持。
4. Megastore支持事务的方式当然还是传统的Two-phase commit协议，为了解决这个协议中协调者失效导致的问题，引入Paxos协议(Google Chubby)使协调者不再成为单点。具体做起来会非常复杂，这里提供超级大牛Jim Gray和Lamport的一篇论文供大家参考： scholar.google.com/scholar   个人认为Oracle的事务内部是一个基本的Two-phase commit协议，协调者宕机时由Oracle DBA手工介入，由于其复杂性，对DBA要求很高，所以Taobao一直网罗国内顶级DBA牛人。
5. Megastore具体事务实现时会借用Bigtable 原有的机制来实现commit log, replication等功能。可能的实现为：建一张专门的Entity group root表，加载Entity group root表的Tablet Server做为协调者角色进行分布式事务控制。然而问题在于加载Entity group root表的Tablet Server是一个单点，实现多个Tablet Server服务同一个Bigtable Tablet又是一件极其困难的事情。
6. Megastore不支持复杂的Join操作，这和互联网公司应用性质相关。Join操作一般不要求强一致性，可以通过多表冗余方式实现。
7. 事务的并发控制采用最优控制策略。简单来说，就是事务过程中不要锁住其它事务操作，提交的时候看一下是否与其它事务冲突，如果有冲突则重试。Megastore实现时没有rollback，失败了都是retry，宕机了就回放操作日志。
8. Megastore/Bigtable的实现者认为让用户自己指定entity group, locality group是合理的（和数据存储位置相关)。这样的效果是同一个entity group的数据经常存放在一台机器上，分布式事务的性能损耗较小，这也就说明在分布式系统中，没有代价的scalable是不存在的，要想获得scalable和性能，就必须牺牲关系数据库的一些特性及用户的易用性。

上述均为个人的粗浅看法，如何避免协调者的单点等很多问题还没有想清楚，Bigtable和Megastore的replication策略看起来也有些冲突，想清楚后将续写！