Megastore在论文中被介绍为一种"storage system"，但我更倾向于认为它是一种跨地域的数据库存储方案。
Megastore 提供一个可伸缩的，高可靠，一致性好，跨地域，低延迟，易用性好的数据库存储方案
System Design
在数据量过于庞大的时候，数据的增删改查都是十分耗时的操作，特别是join操作，相信很多人都深有感触，在跨地域的data centers之间的延迟与通信消耗更是难以承受的。
Megastore不出意外地也对数据进行了partition, 这是通过对实践中的业务观察得到的结论，大部分数据都可以通过某种规则进行partition(如按用户对数据进行划分)，这无形中契合了之前学过的现实世界的小世界特性。这些数据的小集合更加适合用NoSQL的key-value形式存储，而小集合之间的关系则比较适合关系型数据库。而Megasotre也正是使用这种思想设计的。
在应用层面，Meagastore结合了关系型数据库与与非关系型数据库，设计了很简洁的API，屏蔽了底层的实现细节。同时提供了Index，schema，queue等以提高底层BigTable数据库的易用性。使用megastore client Library屏蔽底层实现复杂性的同时，也提供给用户足够的灵活性来指导数据的存放和读写以提高效率。
一个entity group内部，必须要满足ACID的强一致性，因为这些数据很大概率是会被同时实用的，但是对于跨entity group的操作，则只保证部分的一致性，因为业务中对其要求没有这么高。
Replication
一旦涉及到分布式系统设计，replication就是永恒的话题。在Megastore中，同一个entity group的replica是可以跨data centers存在的，这是为了保证分布式系统的高可靠性，属于很正常的设计。比较复杂的部分往往是replica之间数据的同步与更新。
Megastore没有实用比较常见的同步、异步Master-Slave模型来保证数据的读写一致性，而是采用了Paxos通过自选举majority的形式来进行replica之间的同步。这毫无疑问可以解决Single point of failure问题。
然而，这样做的一个问题在于跨地域replica之间的通信开销有些过大了，Megastore通过在每个data centers的replica加一个使用Coordinator服务来解决这个问题，Coordinator保存在当前data center中哪些replica的数据是up-to-date的，如果是这样的replica，就不必使用Paxos来得到最新数据，直接local read就可以，有一种缓存的感觉有木有。
最后，如果coordinator失效了，写操作会被Block，这也就要求有一个机制检测coordinator的失效，megastore使用Chubby Lock服务检测coordinator失效，对于coordinator自己来说，如果更新chubby lock失败，就认为本地的数据都不是最新的，Read操作都要走Paxos流程，对于写操作，在检测到coordinator失效时就不等待他的invalidate操作返回，在失效被发现前，大概有10秒的时间write会被block，但是，实效的coordinator的恢复期间，读写操作都不会被block，依然可以正常进行。
总结
Megastore的核心思想是：
使用Paxos来同步和保证数据Replica的读写一致性，采用划分EntityGroup的方式来减少Paxos过程的冲突。使用Coordinator/localread/chubby lock以及其它各种机制来提高效率，减少延迟，检测失效。
