?

?

灵活

Amazon DynamoDB 支持文档和键值数据结构，您可以灵活地设计最适合您的应用程序的最佳架构。

?

精细访问控制

Amazon DynamoDB 与 AWS Identity and Access Management (IAM) 集成，对组织内的用户实现精细的访问控制。您可以为每名用户分配唯一的安全证书，控制每名用户对服务和资源的访问。

完全托管

Amazon DynamoDB 是完全托管的云 NoSQL 数据库服务，您只需创建数据库表并设置吞吐量，其余事情都交由该服务来代劳。您无需再担心数据库管理任务，例如硬件或软件配置、创建设置和配置、软件更新、操作可靠的分布式数据库集群，或者随着扩展需要在多个实例间对数据进行分区等问题，您只需尽享 Amazon DynamoDB 服务之大成。

（4）FaceBook图形数据库TAO

在Facebook上，人们已经形成了一个复杂的社会关系网络，如何去存储、扩展和展示这个网络是Facebook工程师的一大难题。早在几年前，Facebook的工程师就意识到：关系型数据库的老方法，正在逐步降低基础设施和代码的效率。2009年，他们开始设计一种新的数据库体系结构，也就是分布式数据库TAO（The Associations and Objects）。6月25日，Facebook在官方博客上公布了支持其基础设施细节。

Facebook的软件工程师Mark Marchukov在博客中表示他们之所以创建TAO的原因之一在于同时使用MySQL和Memcached读取数据太复杂了。产品工程师要工作在两种完全不同的数据模型之间：大规模的MySQL服务器用关系表存储持久数据，类似数量的缓存数据服务器用来存储SQL查询到的键值对。即便是封装在数据访问库中最常见的操作，也需要产品工程师对系统内部有充分的了解，才能高效地使用memcache-MySQL组合。

TAO的图型架构在信息组织方面类似于Facebook的图搜索工具，它将世界看作由节点（对象，即人、地点和事物）和边（关联，即他们之间的关系）组成的图。随着数据量的增大，保持数据的关系模式变得不再重要，TAO及其对应的API应运而生。

?

Marchukov认为TAO最大的突破在于实现了图解模型，Facebook的主要工作负载在于读取数据，TAO证明了图数据模型很适合这类查询操作较多的网站。实际上，类似Neo4j的图形数据库一直备受关注，因为它能有效表示人际关系。

Marchukov 在博客中提到，TAO不仅大规模实现了图数据结构，也使用MySQL实现硬盘上的持久存储，同时要保证数据在各个数据中心的最终一致性，用户才能获取“新鲜事”。

?

TAO服务运行在大量的服务器集群上，这些分布在不同地理位置的集群构成一个树形网络。有另外的集群用来持久存储对象和对象关联，RAM和闪存实现缓存。这种分层结构在单独进行不同类型的集群扩展时更方便，也能有效利用服务器硬件。

（5）Google Spanner简介

Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能 同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。

?

Spanner是个可扩展，多版本，全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能 做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能：无锁读事务， 原子schema修改，读历史数据无block。

下面主要是Spanner的背景，设计和并发控制。

Spanner背景

要搞清楚Spanner原理，先得了解Spanner在Google的定位。

从上图可以看到。Spanner位于F1和GFS之间，承上启下。所以先提一提F1和GFS。

F1

和众多互联网公司一样，在早期Google大量使用了Mysql。Mysql是单机的，可以用Master-Slave来容错，分区来扩展。但是需 要大量的手工运维工作，有很多的限制。因此Google开发了一个可容错可扩展的RDBMS——F1。和一般的分布式数据库不同，F1对应RDMS应有的 功能，毫不妥协。起初F1是基于Mysql的，不过会逐渐迁移到Spanner。

F1有如下特点：

· 7×24高可用。哪怕某一个数据中心停止运转，仍然可用。

· 可以同时提供强一致性和弱一致。

· 可扩展

· 支持SQL

· 事务提交延迟50-100ms，读延迟5-10ms，高吞吐

众所周知Google BigTable是重要的NoSql产品，提供很好的扩展性，开源世界有HBase与之对应。为什么Google还需要F1，而不是都使用 BigTable呢？因为BigTable提供的最终一致性，一些需要事务级别的应用无法使用。同时BigTable还是NoSql，而大量的应用场景需 要有关系模型。就像现在大量的互联网企业都使用Mysql而不愿意使用HBase，因此Google才有这个可扩展数据库的F1。而Spanner就是 F1的至关重要的底层存储技术。

Colossus（GFS II）

Colossus也是一个不得不提起的技术。他是第二代GFS，对应开源世界的新HDFS。GFS是著名的分布式文件系统。

初代GFS是为批处理设计的。对于大文件很友好，吞吐量很大，但是延迟较高。所以使用他的系统不得不对GFS做各种优化，才能获得良好的性能。那为什么 Google没有考虑到这些问题，设计出更完美的GFS ?因为那个时候是2001年，Hadoop出生是在2007年。如果Hadoop是世界领先水平的话，GFS比世界领先水平还领先了6年。同样的 Spanner出生大概是2009年，现在我们看到了论文，估计Spanner在Google已经很完善，同时Google内部已经有更先进的替代技术在 酝酿了。笔者预测，最早在2015年才会出现Spanner和F1的山寨开源产品。

Colossus是第二代GFS。Colossus是Google重要的基础设施，因为他可以满足主流应用对FS的要求。Colossus的重要改进有：

· 优雅Master容错处理 (不再有2s的停止服务时间)

· Chunk大小只有1MB (对小文件很友好)

· Master可以存储更多的Metadata(当Chunk从64MB变为1MB后，Metadata会扩大64倍，但是Google也解决了)

Colossus可以自动分区Metadata。使用Reed-Solomon算法来复制，可以将原先的3份减小到1.5份，提高写的性能，降低延迟。客户端来复制数据。具体细节笔者也猜不出。

?

与BigTable， Megastore对比