NoSQL 实例
亚马逊的Dynamo是一个高度可用性的关键字-数据存储库，是北美最大的商务网站的基础骨架之一。 Dynamo 的可扩展性和可用性采用的都是比较成熟的技术，使用一致性哈希方式进行数据分区和复制，利用数据对象的版本实现一致性。采取类似法定人数（ quorum ）的机制以及去中心化的复制同步协议解决复制时因为更新产生的一致性问题。使用一种相互交谈（gossip)的机制监测服务器成员的变化（详见附录）。Dynamo 是完全去中心化的系统，需要的人工管理工作量很小。
Dynamo使用一致性哈希来分片和复制数据。关键字被哈希散列分布到可用的机器上。 每个关键字和数据被复制在N台机器上。当数据需要读写时，系统保证有最低R（或W)台机器存储或返回相应的数据。这样保证 了数据的一致性。任何一台机器可以请求数据。每台机器有足够的本地路由信息，找出哪台机器包含请求的数据。如果该数据是在同一台机器，结果被立即返回。否则，该请求将被转发到包含该数据的关键字的哈希范围的任何的N个机器。
Dynamo一个重要特点是永远支持写操作。 因为写入失败往往给的应用程序的最终用户带来比读操作失败更严重的后果，Dynamo被设计为对写人操作高度可用的系统。为了提高写人操作的效率，写入的过程中不解决任何数据冲突问题，留给读操作处理。如某些机器上有最新的数据，而另一些机器有过时的数据，表明存在数据冲突。如果有冲突，那么Dynamo将尝试利用向量时钟中记载的检查对象的版本历史链。如果最新的数据和陈旧的数据存在-> 关系，返回最新的数据； 如果冲突的数据不共享相同的祖先，那么所有检索到的数据都会返回给客户端，让用户解决这些冲突。
在更新过程中的副本之间的一致性是通过一个类似法定人数的分散同步协议来实现的。Merkle 树是一棵二叉数 ，每个父节点是两个子节点的 哈希值 。Dynamo使用Merkle树来减少同步机制中的网络传输开销 。（见附录）
2007年Amazon发表了Dynamo的论文，对NoSQL世界的Apache Cassandra, Voldemort, Riak 等都产生影响。 最近，为了克服Dynamo 和SimpleDB的缺点，Amazon将Dynamo和SimpleDB整合成 DynamoDB。 Amazon的AWS使用DynamoDB，DynamoDB被Amazon看作是“15年大规模非关系数据库和云 服务的经验总结”（Werner Vogels).
目前的DynamoDB提供二种类型的主索引查询：简单哈希键和复合哈希键（区间键）。 简单哈希键查询API是Dynamo本身支持的；而复合哈希键允许用户使用带有特性区间的主键查询。比如汤姆过去24小时的所有订单；服务器16上的所有客户IP地址属于192.168.1.0的日志记录。
DynamoDB不要求固定的数据模式（Schema), 数据对象可以含有任意数目的属性。所有数据存储在固态硬盘（SSD)，属性不做任何索引；Vogels (Amazon CTO)声称DynamoDB对于1KB的对象的查询速度在毫秒级。更为重要的是，基于Dynamo DB 的分布式结构，延迟很稳定，并不因为数据量增加而增加。
CouchDB是通过REST API访问的面向文档的数据库。Couch是Cluster Of Unreliable Commodity Hardwared 的缩写，意为“不可靠的商用硬件集群”，强调的数据库的分布式特性。CouchDB的设计理念是基于Web应用程序的资源，方法和显示的模式，来提供对数据的查询，映射，合并和过滤。 CouchDB强调系统的容错性，高度的可扩展性和渐进性的复制机制，适合论坛，bug跟踪，维基，电子邮件等大规模文档系统。
一个CouchDB文档是一个包含命名字段的对象。字段值列表可能包含字符串，数字和日期。CouchDB是这些文档的集合，每个文档是单独的存储元素，包括一个唯一的ID（DocID），修改历史（Revision)，也可以带有任意尺寸大小的附件。
CouchDB通过以下方法来满足数据管理的四大支柱：
-
保存（Save)：ACID兼容，有效保存
-
查阅（See)：易检索，简单的报告方法，全文检索
-
安全（Secure)：强的模块化支持，ACL，基于SSL的连接
-
分享（Share)：分布式的方式
CouchDB不使用锁。RDBMS 使用锁机制来控制读写的并发操作，同时锁也是RDBMS性能的瓶颈。 在高负载情况下，RDBMS可能在锁管理上消耗比实际读写操作更多的时间。为了避免锁对性能的负面影响，CouchDB使用开放式锁定的多版本并发控制（MVCC）系统。 使用MVCC比锁定模型的主要优点是在MVCC里， 对检索（读）数据的锁要求与写数据的锁要求不冲突， 所以读不会阻塞写，而写也从不阻塞读。
CouchDB可以看作一个使用REST前端的版本控制系统。CouchDB中的文档都带有版本号，对文档的修改产生带有更新版本号的新文档。 新版本的数据附加到文件（“数据库”），而不是覆盖原有数据。这也是CouchDB 数据模型的独特之处：只提供追加写操作。
CouchDB的MVCC如何避免使用锁机制呢？请求A读文档，在读操作过程中请求B要修改文档。因为修改操作产生新的文档，CouchDB不必等到A的读操作完成就开始B的写操作，然后把写操作产生的新文档附加到CouchDB. 当请求C要求读文档时，CouchDB直接返回具有新版本号的新文档。 也就是说读操作永远读到最新的数据快照。
前面提到维持数据的不变性是提高系统可用性和可扩展性的一个重要策略。 CouchDB只提供追加写操作的另一个优点是， 系统重新启动快，不需要启动检查或运行别的进程。 CouchDB同时提供了应用程序摆脱旧数据版本，并节省空间。
CouchDB的数据存储在B-tree中，以保证数据的搜索，插入，去除操作O(logN) 的复制度。数据查询最初是使用XML语言，现在CouchDB推荐使用JSON。 JSON的查询语言使用类似正则表达式的结构模式，更加灵活。
[此图出自http://couchdb.apache.org/]
CouchDB使用MapReduce计算搜索结果。MapReduce对每个文档并行进行Map和Reduce操作，而且操作的结果是 【键-值】 对，可以高效的插入B-tree。
CouchDB通过索引和搜索管理程序来管理全文搜索。CouchDB通过这些守护进程的API 来调用第三方搜索引擎。 目前提供了一个使用Lucene的实现。也有可能开发一个基于CouchDB的MySQL的存储引擎。这意味着为CouchDB提供RDBMS接口。
CouchDB是如果获得分布式环境中的一致性呢？ 一台服务器脱机数据被更改 后可以周期性的渐进更新其他服务器。如果发生数据冲突，CouchDB会选择一个胜利者作为最新数据。用户可以手动修改这种解决冲突后的结果。
