Megastore初探(预览版预览版)预览版前言去年年底,团队内部成员分享了这篇google论文,初读了下,发现其有蛮多有意思的东西,就想把他翻译下来,但是翻译了一小部分,明显感觉如果这样的翻译发出去,很可能误人子弟,所以改成了概要式的博文,这篇文章会将原论文最核心的几个部分做不完全的翻译和个人理解,如有不解或者错误的地方,请查看原论文.正文Megastore是谷歌一个内部的存储系统,它的底层数据存储依赖Bigtable,也就是基于NoSql实现的,但是和传统的NoSql不同的是,它实现了类似RDBMS的数据模型(便捷性),同时提供数据的强一致性解决方案(同一个datacenter,基于MVCC的事务实现),并且将数据进行细颗粒度的分区(这里的分区是指在同一个datacenter,所有datacenter都有相同的分区数据),然后将数据更新在机房间进行同步复制(这个保证所有datacenter中的数据一致).Megastore的数据复制是通过paxos进行同步复制的,也就是如果更新一个数据,所有机房都会进行同步更新,因为使用paxos进行复制,所以不同机房针对同一条数据的更新复制到所有机房的更新顺序都是一致的,同步复制保证数据的实时可见性,采用paxos算法则保证了所有机房更新的一致性,所以个人认为megastore的更新可能会比较慢,而所有读都是实时读(对于不同机房是一致的),因为部署有多个机房,并且数据总是最新.为了达到高可用性,megastore实现了一个同步的,容错的,适合长距离连接的日志同步器为了达到高可扩展性,megastore将数据分区成一个个小的数据库,每一个数据库都有它们自己的日志,这些日志存储在NoSql中Megastore将数据分区为一个EntityGroups的集合,这里的EntityGroups相当于一个按id切分的分库,这个EntityGroups里面有多个EntityGroup(相当于分库里面的表),而一个EntityGroup有多个Entity(相当于表中的记录)在同一个EntityGroup中(相当于单库)的多个Entity的更新事务采用single-phaseACID事务,而跨EntityGroup(相当于跨库)的Entity更新事务采用two-phaseACID事务(2段提交),但更多使用Megastore提供的高效异步消息实现.需要说明的一点是,这些事务都是在同一个机房的,机房之间的数据交互都是通过数据复制来实现的.机房1EntityGroups1EntityGroup_0000EntityGroups2EntityGroup_0001机房2EntityGroups1EntityGroup_0000EntityGroups2EntityGroup_0001多机房复制EntityGroup_0002EntityGroup_0003EntityGroup_0002EntityGroup_0003传统关系型数据库使用join来满足用户的需求,对于Megastore来说,这种模型(也就是完全依赖join的模型)是不合适的.原因包括1.高负载交互性型应用能够从可预期的性能提升得到的好处多于使用一种代价高昂的查询语言所带来的好处.2.Megastore目标应用是读远远多于写的,所以更好的方案是将读操作所需要做的工作转移到写操作上面(比如通过具体值代替外键以消除join)3.因为megastore底层存储是采用BigTable,而类似BigTable的key-value存储对于存取级联数据是直接的所以基于以上几个原因,Megastore设计了一种数据模型和模式语言来提供基于物理地点的细颗粒度控制,级联布局,以及申明式的不正规数据存储来帮助消除大部分joins.查询时只要指定特定表和索引即可.当然可能有时候不得不使用到join,Megastore提供了一种合并连接算法实现,具体算法这里我还是没弄清楚,原文是[theuserprovidesmultiplequeriesthatreturnprimarykeysforthesametableinthesameorder;wethenreturntheintersectionofkeysforalltheprovidedqueries.]使用Megastore的应用通过并行查询实现了outerjoins.通常先进行一个初始的查询,然后利用这个查询结果进行并行索引查询,这个过程我理解的是,初始查询查出一条数据,就马上根据这个结果进行并行查询,这个时候初始查询继续取出下一条数据,再根据这个结果并行查询(可能前面那个外键查询还在继续,使用不同的线程).这种方法在初始查询数据量较小并且外键查询使用并行方式的情况下,是一种有效的