Google发布面向App Engine的High Replication Datastore

分布式、可伸缩及高可靠的数据存储将成为业界的下一个圣杯。在发布Google App Engine Datastore两年后，Google开始直面这个问题。其Master/Slave复制架构的设计意图在于支持“快速、一致的读需求”，同时还支持快速的写需求。但Google需要重新审视这个问题：

你可能注意到了，我们过去半年一直在与App Engine Datastore的某些 可靠性问题进行着斗争。在过去的几个月中，我们取得了长足的进步。然而，解决这些问题所积累的经验使我们认识到需要重新考虑一下设计假定了。

上周，Google发布了“High Replication Datastore”以为读和写提供更高层次的可用性。但这也是有代价的，那就是增加了写延迟，同时API中的一致性保证也发生了变化。

High Replication Datastore使用Paxos算法来实时同步跨越多个数据中心的数据，进而增加了用于维护数据复制的数据中心数量。这么做最大的好处在于计划的维护周期内，应用的所有功能都保持完全的可用性，对于大多数意外的基础设施问题也一样。

Google警告开发者：

由于是分布式数据库，正如CAP（Consistency，一致性；Availability，可用性；Partition tolerance，分区容错性）所示，开发者需要非常小心地对应用进行架构，因为随着成本的增加、可靠性的增强以及复杂性的增加，性能不可避免地会降低。

为了帮助开发者将现有的应用数据迁移到High Replication Datastore上，Google提供了一些迁移工具。由于复制量的增加，Google还将价格提高了1/3。

Todd Hoff称之为“向完全的分布式未来迈进的一大步”：

HRD的目标是需要将数据复制到至少3个数据中心的、需要完整的ACID语义、高一致性保证的任务关键性应用。

Google新的数据存储定义了一种介于RDBMS抽象元组和NoSQL具体的行列存储之间的一种数据模型。在RDBMS中，数据模型声明在Schema中并且是强类型的。每个Schema都有一个表集合，每张表包含一个实体集合，每个实体包含了一个属性集合。属性具有名称，其值具有相应的类型。

Bigtable可以在相同的行/列对中存储多个值，只不过时间戳不同。该特性实现了多版本并发控制（MVCC）：当使用了事务时，在写入值时需要带上其事务的时间戳。在读取时会使用上一次事务的完整时间戳以避免部分更新的情况出现。

平均的读延迟在10毫秒左右，具体时间取决于数据量，这表明大部分读都是本地的；平均的写延迟在100——400毫秒左右，具体时间取决于数据中心之间的距离、写入的数据大小以及完整复制的数量等因素。

曾经只被大公司用于构建任务关键性应用的“大基础设施”现在也充分利用了长尾理论，可以构建创新型应用了，这在几年前是无法想象的事情。你打算使用Google App Engine么？自己的解决方案中需要这样的数据存储么？这种基础设施给你带来的最大好处是什么呢？

查看英文原文：Google Releases the High Replication Datastore for App Engine