论文阅读笔记 - Megastore : ProvidingScalable, Highly Available Storage for Interactive Services
作者:刘旭晖 Raymond 转载请注明出处
Email:colorant at 163.com
BLOG:http://blog.csdn.net/colorant/
更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145
关键字
跨机房,数据同步,paxos,一致性,Google Megastore
==目标问题 ==
提供一个可伸缩的,高可靠,一致性好,跨地域,低延迟,易用性好的数据库存储方案
==核心思想 ==
以上目标(本质需求上相冲突)很难做到面面俱到,需要在不同的方面进行取舍。Megastore的核心思想是将数据分割成不同的EntityGroup,EntityGroup的数据备份是跨Datacenter存放的,在EntityGroup内部提供完整的ACID支持,保证数据写操作在所有数据中心的同步备份。在EntityGroup之间只提供受限的ACID,例如不保证数据的强一致性等。
这种数据划分的思想主要是基于多数的数据内在的都可以按照一定的原则分组(如按用户划分),组内的操作的对一致性,实时性的要求比较高,但是因为多方同时操作同一个组的概率比较低,数据冲突发生的可能性较小,所以满足一致性等指标所带来的代价也比较小,而跨组的操作可以对数据一致性和更新延迟的容忍程度较高。可以降低这方面的指标。
如何在保证一致性的基础上做到高可靠性和高可用性的数据备份,是整个系统的关键。常见的广域数据备份方案各有优缺点:
Megastore的方案有点类似平等的节点方案,没有主从节点之分,任何节点都可以发起写操作,但是通过Paxos机制来决定哪个写操作最终被采纳并分发,从而保证数据的一致性。
每个EntityGroup有自己的多备份的操作Log,保证高可用性,也可以最大并行化不同EntityGroup的操作。
跨EntityGroup的操作通过消息队列来实现,因而是弱一致性的。不过对于一致性要求高的应用,也可以使用两阶段提交的方式保证强一致性。
如何合理的划分EntityGroup,达到最佳性能则是用户需要考虑的。
==实现细节 ==
==数据 ==
平均读延迟10ms,平均写延迟100-400ms,取决于读写数据量的大小,数据备份replica的数量和数据中心的分布距离。可用性方面,基于多年100+的实际上线应用的数据统计多数可以达到99.999%以上的读写可用性。
==相关研究,项目等 ==
项目相关的首先当然是底层的BigTable,其次是Chubby。理论相关如Paxos,和各种Fast Paxos的优化方案研究等
类似的项目:阿里的Wasp,大概是基于Megastore的理论,在HBase上的一个仿照实现。
==其它 ==
个人理解简单总结:
megastore本身不是数据库,更像一个基于Bigtable数据库的多数据中心数据备份读写解决方案,采用了各式各样的最佳实践来达到它的目的。使用Paxos来同步和保证数据Replica的读写一致性,采用划分EntityGroup的方式来减少Paxos过程的冲突,使用Coordinator/localread/chubby lock以及其它各种机制来提高效率,减少延迟,检测失效。使用megastore client Library屏蔽底层实现复杂性的同时,也提供给用户足够的灵活性来指导数据的存放和读写以提高效率。同时提供了Index,schema,queue等以提高底层BigTable数据库的易用性。