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