SimpleDB的一项关键特性是它使用一种最终一致性模型。这个一致性模型对并发性很有好处，但意味着在你改变了项目属性之后，那些改变有可能不 能立即反映到随后的读操作上。尽管这种情况实际发生的几率很低，你也得有所考虑。比如说，在你的演出订票系统里，你不会想把最后一张音乐会门票卖给5个 人，因为在售出时你的数据是不一致的。
Google AppEngine Data Store
Google AppEngine Datastore 是在BigTable之上建造出来的，是Google的内部存储系统，用于处理结构化数据。AppEngine Datastore其自身及其内部都不是直接访问BigTable的实现机制，可被视为BigTable之上的一个简单接口。
AppEngine Datastore所支持的项目的数据类型要比SimpleDB丰富得多，也包括了包含在一个项目内的数据集合的列表型。
如果你打算在Google AppEngine之内建造应用的话，几乎可以肯定要用到这个数据存储。然而，不像SimpleDB，使用谷歌网络服务平台之外的应用，你并不能并发地与 AppEngine Datastore进行接口 (或通过BigTable)。
微软: SQL数据服务
SQL数据服务 是微软 Azure 网络服务平台的一部分。该SDS服务也是处于测试阶段，因此也是免费的，但对数据库大小有限制。 SQL数据服务其自身实际上是一项处在许多SQL服务器之上的应用，这些SQL服务器组成了SDS平台底层的数据存储。你不需要访问到它们，虽然底层的数 据库可能是关系式的；SDS是一个键/值型仓储，正如我们迄今所讨论过的其它平台一样。
微软看起来不同于前三个供应商，因为虽然键/值存储对于可扩性而言非常棒，相对于RDBMS，在数据管理上却很困难。微软的方案似乎是入木三分，在 实现可扩性和分布机制的同时，随着时间的推移，不断增加特性，在键/值存储和关系数据库平台的鸿沟之间搭起一座桥梁。
非云服务竞争者
在云之外，也有一些可以独立安装的键/值数据库软件产品。大部分都还很年轻，不是alpha版就是beta版，但大都是开源的；通过看看它的代码， 比起在非开源供应商那里，你也许更能意识到潜在的问题和限制。
CouchDB
CouchDB 是一个免费、开源、面向文档的数据库。它来自于键/值存储，使用JSON（译者：JavaScript Object Notation，一种轻量级的数据交换格式）来定义项目的模式。CouchDB允许通过JavaScript动态创建“视图”，意在跨越面向文档型数据 库与关系数据库之间的鸿沟。这些视图将文档数据映射在类似表的结构上，可被索引和查询。
现在，CouchDB 还不是真正的分布式数据库。它的复制功能允许数据在服务器间同步，但这并非建设高可扩性的环境所需的那种分布类型。毫无疑问，CouchDB团队将朝此目 标继续努力。
Project Voldemort
Project Voldemort 是分布式的键/值数据库，旨在横向扩展于大量的服务器中。它产生自LinkedIn所完成的工作，据报告在那儿为几个有着极高可扩性要求的系统所使用。 Project Voldemort也使用了Amazon的最终一致性模型。
Project Voldemort还很新；它的网站前几周才刚开张。
Mongo
Mongo是由Geir Magnusson和Dwight Merriman (提到DoubleClick你可能就想到他)在10gen开发出来的数据库系统。跟CouchDB一样，Mongo是一个面向文档的JSON数据库，除 了它是被设计为一个真正的对象数据库，而不是一个纯粹的键/值存储这一点之外。起初，10gen关注于整合出一个完整的网络服务栈;然而最近，它已经把重 点转移到Mongo数据库上了。其beta测试版计划在二月中发布。
Drizzle
Drizzle可被认为是键/值存储要解决的问题的反向方案。Drizzle诞生于MySQL（6.0）关系数据库的拆分。在过去几个月里，它的开 发者已经移走了大量非核心的功能（包括视图、触发器、已编译语句、存储过程、查询缓冲、ACL以及一些数据类型），其目标是要建立一个更精简、更快的数据 库系统。Drizzle 仍能存放关系数据；正如MySQL/Sun的Brian Aker所说那样：“没理由泼洗澡水时连孩子也倒掉”。它的目标就是，针对运行于16核（或以上）系统上的以网络和云为基础的应用，建立一个半关系型数据 库平台。
决策
最终，有四条理由支持你为应用选择非关系式的键/值数据库平台：
1. 你的数据很大程度上是面向文档的，使得它比关系数据库更自然地适合于键/值数据模型。
2. 你的开发环境严重地面向对象时，键/值数据库能尽量减少对“管道”代码的需求。
3. 数据存储很廉价，易于集成进供应商的网络服务平台。
4. 你优先考虑的是随需应变的高端可扩性 -- 也就是说，那种通过简单的扩充所无法获得的大规模、分布式的可扩性。
但是在作决定的时候，要记得这种数据库的限制，以及从关系式大路出走时所面临的风险。
对于其他需求而言，你也许在RDBMS那里能得到最好的满足。因此，关系数据库的死期是不是到了？显然不是。嗯，至少还没有。
