对Megastore做了简要的笔记，语言通俗易懂些，只关注了一部分，比如数据模型，如何解决应用对数据的需求，join的处理，事务机制等。
摘要
开发Megastore是为了满足现在的交互式在线服务的需求。它混合了NoSQL的可扩展性和
RDBMS的方便性，从而既提供了强一致性也提供了高可用性。它在数据分区内实现了完全的串行化的ACID语义。
This partitioning(分区方法) 允许我们在不同的数据中心之间同步的复制每次写，并且有较好的延迟，同时
能够支持数据中心之间的无缝故障恢复。这篇文章描述了Megastore的语义和复制算法。也描述了google在使用
Megastore方面的经验
介绍
交互式在线服务正在对存储社区提出越来越多的挑战。email，协作式文档，社会化网络 指数式的增长正在对现有的基础架构提出挑战。满足这些服务
很有挑战，因为很多的需求都是互相冲突的。
1 互联网用户会越来越多，因此应用程序必须有高的可扩展性，应用程序能够使用mysql作为数据库来快速的构建，但是当用户达到百万级别时，存储架构需要重新设计。
2 应用程序需要快速构建争夺市场和用户
3 应用程序的响应时间要短，所以存储系统需要低延迟。
4 服务应该给用户提供数据的一致性视图：更新操作必须马上被看见并且需要持久化
5 24 * 7，要求高可用性，机器错误，磁盘错误，或者大范围的故障都应该对服务是透明的。
这些需求是相互冲突的：关系型数据库提供给了丰富的特性，但是很难扩展到亿级用户。bigtable，hbase，cassandra具有高可扩展性，但是api比较受限，而且宽松的一致性使得应用程序的开发很复杂。跨数据中心同步数据又提供低延迟很难，就像在多副本上保持一致性一样难，特别是当发生故障的时候。
Megastore 使用同步复制来达到高可用性和数据的一致性视图。简而言之，MegaStore 对"不同地域的低延迟性的replica" 提供了完全的串行化ACID语义 来支持交互的在线服务
Megastore 为了达到这个目标在RDBMS和NoSQL取了个折中，将数据进行分区，每个分区进行复制，分区内部提供完全的ACID 语义，但是分区和分区之间只保证有限的一致性。
Megastore提供了RDBMS的一些特性，例如secondary index等，但是仅仅支持用户可以忍受的延时范围内并且Megastore的分区模式能够支持的特性。互联网的数据可以很好的
进行分区(比如根据用户进行分区)。
Megastore使用Paxos来构建高可用性系统，它可以为交互式在线服务提供可容忍的延迟，同时也可以跨数据中心复制数据。许多系统使用Paxos来进行master的选举，
lock，元数据的复制，配置的复制，Megastore使用paxos在每次写的时候复制主要用户数据。
Megastore会大量的部署在google，每天处理30亿的写事务，20亿的读事务，存储1PB的数据。
文章的关键贡献在：
1 数据模型的设计，对交互式在线应用程序提供高可用高扩展的存储系统的设计
2 为了提供低延时的数据中心之间的复制，一种优化过的paxos复制和一致性算法的实现
复制
数据中心内的复制容忍了单机故障问题，但是还需要处理数据中心与外部的连接故障的情况。所以需要在数据中心之间复制数据。
策略
1.异步 master/slave
master 复制write-ahead log给至少一个slave。log 并行的被发送给master，确认并行的返回给master。master能够支持快的ACID事务但是可能宕机会丢数据(fail over 到
slave期间的数据)。
2.同步 master/slave
master回复客户端前必须先同步到slave，master和slave的失败需要被外部系统监控。
3.乐观复制
一个group中的任何一个replica都可以接受mutation。然后mutation异步传播给group内的其它replica。这种方法可用性和延时性都很好。
但是全局更新顺序在commit的时候是不知道的，所以事务是不可能实现的。
Megastore没有选择会丢数据的策略(抛弃策略1)，也不选择不支持ACID事务的策略(策略3)
改进的Paxos
算法较复杂，暂不关注
分区和局部性
为了scale 复制的schema，提高数据库的性能，Megastore允许应用程序可以控制数据的分区和局部性
Entity Groups
同一个虚线长方形框里面有三个圆柱体，即同一个entity group的3个replica。
为了使吞吐量可扩展，并且让服务故障局部化，将数据分为很多的entity group。每个entity group被独立的在数据中心之间同步。
一个entity group内部的entities用single-phase 的ACID 事务修改，其中的commit log通过Paxos算法复制。而跨entity groups的操作
需要依赖高代价的两阶段提交，它利用Megastore的有效的异步消息队列。发送的entity group中的一个事务将一个或者多个消息放入消息队列，然后接收的
entity group原子性的消费这些消息，并且应用其中的改变。
异步消息队列 用在逻辑上distant的entity group之间，而不是物理上distant。一个entity group内部的索引遵循ACID语义。跨entity groups的索引是
loose 一致性的。
选择entity groups边界
如果entity group的粒度太小，那么跨entity group的操作就会很多，可能就需要很多2PC，而如果将很多不相关的数据放入同一个entity group会序列化不相关的
写操作，这会降低吞吐量。
email：每个用户账号作为一个entity group，一个账户内的操作都是事务的，一致性的：一个用户发送消息或者label一个消息能够被观察到即使fail over到别的replica。
而不同账户的消息由外部的router负责。
blogs：blog应用可以被建模为多类的entity group。首先，用户的资料被归为一类entity group，由于博客是协作的，没有永久的owner，所以创建第二类entity group
来hold住posts和元数据。第三类 key offs the unique name claimed by each blog(啥意思?)
Maps: 地理数据没有什么很自然的切分粒度。mapping应用程序可以通过把地图切分成很多有重叠的片。对于跨patch的操作，使用2PC。
Physical Layout
Megastore在单数据中心内使用bigtable，支持随机读和写吞吐。
a tour of Megastore
关系型数据库在服务客户请求时使用的join不适合Megastore上的应用程序，有很多原因：
1 可预测的性能(predictable performance)可以很好的来得到high-volumn 的workload，而不是表达能力很强的查询语言。
2 应用程序中读的比例很大，it pays to move work from read time to write time(理解为，所以我们需要将更多的工作重点放在读操作的处理上，所以相反的，如果
将很多工作放在写上，这样代价会很大)
3 存储，查询hierarchy 数据在bigtable系统中很直接。
结合这几点，Megastore设计了一个比较好的数据模型和schema语言来给应用程序提供 对physical locality的比较好的粒度的控制。
hierarchy布局和 声明的反范式化(通过对数据进行冗余等手段？) 基本排除了大部分join的需求。查询会指定对指定的表和索引 进行扫描或者查找。
join操作如果需要的话，可以在应用层做。megastore 提供了merge join算法(也就是sort merge join，join算法的一种，还有nested loop join[mysql的实现] 和hash join )的merge阶段的实现，看原文，原理和RDBMS的方法一样，就是在join的表上按照join字段进行排序，然后merge
外连接(outer join)也是通过并行查询实现的，这个过程的原理也与RDBMS相同，看了下原文，貌似使用的nested loop join，对多个被驱动表并行查询index
数据模型和事务机制
参看 http://www.nosqlnotes.net/archives/145
全文翻译参看：http://duanple.blog.163.com/blog/static/709717672011515113727309/