Megastore在Google中已经部署和使用了若干年，有超过100个产品使用Megastore作为其存储系统从图中可以看出，绝大多数产品具有极高的可用性（>99.999%）。这表明Megastore系统的设计是非常成功的，基本达到了预期目标

协调者在系统中是比较重要的——协调者的进程运行在每个数据中心。每次的写操作中都要涉及协调者，因此协调者的故障将会导致系统的不可用Megastore使用了Chubby锁服务，为了处理请求，一个协调者必须持有多数锁。一旦因为出现问题导致它丢失了大部分锁，协调者就会恢复到一个默认保守状态除了可用性问题，对于协调者的读写协议必须满足一系列的竞争条件

1、快速读利用本地读取实现快速读，带来更好的用户体验及更低的延迟关键是保证选择的副本上数据是最新的协调者是一个服务，该服务分布在每个副本的数据中心里面。它的主要作用就是跟踪一个实体组集合协调者的状态是由写算法来保证2、快速写如果一次写成功，那么下一次写的时候就跳过准备过程，直接进入接受阶段Megastore没有使用专门的主服务器，而是使用leadersleader主要是来裁决哪个写入的值可以获取0号提议客户端、网络及Bigtable的故障都会导致一个写操作处于不确定的状态

在Megastore中共有三种副本1、完整副本（FullReplica）2、见证者副本（WitnessReplica）3、只读副本（Read-onlyReplica）

current：总是在单个实体组中完成snapshot：总是在单个实体组中完成系统取出已知的最后一个完整提交的事务的时间戳，接着从这个位置读数据inconsistent：忽略日志的状态直接读取最新的值

同关系型数据库一样，Megastore的数据模型是在模式（schema）中定义的且是强类型的（stronglytyped）每个模式都由一系列的表（tables）构成，表又包含有一系列的实体（entities），每实体中包含一系列属性（properties）属性是命名的且具有类型，这些类型包括字符型（strings）、数字类型（numbers）或者Google的ProtocolBuffers。

传统的关系型数据库是通过连接（Join）来满足用户的需求的，但是就Megastore而言，这种数据模型是不合适的，主要有以下三个原因：1、对于高负载的交互式应用来说，可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多2、Megastore所面对的应用是读远多于写，因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上3、在Bigtable这样的键/值存储系统中存储和查询级联数据（HierarchicalData）是很方便的

设计目标及方案选择：设计一种介于传统的关系型数据库和NoSQL之间的存储技术，尽可能达到高可用性和高可扩展性的统一。方法一：针对可用性的要求，实现了一个同步的、容错的、适合远距离传输的复制机制。方法二：针对可扩展性的要求，将整个大的数据分割成很多小的数据分区，每个数据分区连同它自身的日志存放在NoSQL数据库中，具体来说就是存放在Bigtable中。

Bigtable向用户提供了一种称为布隆过滤器的数学工具。布隆过滤器是巴顿•布隆在1970年提出的，实际上它是一个很长的二进制向量和一系列随机映射函数，在读操作中确定子表的位置时非常有用。优点：布隆过滤器的速度快，省空间不会将一个存在的子表判定为不存在缺点：在某些情况下它会将不存在的子表判断为存在

1、选取并保证同一时间内只有一个主服务器（MasterServer）。2、获取子表的位置信息。3、保存Bigtable的模式信息及访问控制列表。