【51CTO精选译文】在网络世界中，大规模数据存储发生了有趣的变化，一种全新的可扩展数据存储正快速普及，传统的LAMP组合开始变得越来越落伍。最近几年以来，Memcached经常出现在MySQL身边，现在整个“数据层”都开始动摇了。
虽然有些人认为这是摆脱MySQL和PostgreSQL等传统的开源关系数据库的机会，实际上事情并不是这么简单，从这些有趣的变化中我们得出一些启示：
1）关系数据库并不适合所有的数据模型；
2）关系数据库扩展难度大，特别是当你一开始就设计为单机配置，未进行分布式设计时；
3）标准化通常会伤害到性能；
4）在许多应用中，主键就是你的一切。
新的数据存储完全改变了传统的观念，但总的来说，它们借鉴了一套类似的高级特征，但它们并非能够满足一切。下面给出一个列表，让你看看它们正试图实现什么。
1）反标准化，通常是无模式的，文档型存储；
2）以key/value为基础，支持通过key进行查找；
3）水平扩展；
4）内置复制；
5）HTTP/REST或很容易编程的API；
6）支持MapReduce的风格的编程；
7）最终一致。
如果还要列的话，我可能还可以列出一打来。但前面两个是对传统数据库最大的叛离（51CTO编者注：所以说NoSQL是数据库领域的革命），当然你也可以坚持使用MySQL，并将其去关系化，这也是FriendFeed要做的事情，FriendFeed使用MySQL作为后端，实现分布式key/value存储。
对这些分布式无模式的数据存储，开始有一个新名称来称呼，那就是NoSQL。与其在NoSQL存储系统理论上花大量的时间阐述，我更愿意花点时间来谈谈吸引我眼球的一些东西。
Redis
关于Redis我不想说太多，因为我在最近的一篇文章“Redis: Lightweight key/value Store That Goes the Extra Mile”中已经说得很详细了，这里我只简要说一下。它是一个轻量级内存中的key/value存储，可以处理字符串，数据集和列表，拥有一个优秀的数据类型操纵核心。Redis内置了复制支持，保证数据在磁盘上的连续性，它还很年轻，但现在已经发布了1.0版本。
Redis吸引我的另一个原因是它的API很简单，通过增加特殊的数据结构，并提供更快速的原子操作，给传统key/value存储开了一个口。
Tokyo Cabinet
Tokyo Cabinet来自日本，它是一个快速和成熟的基于磁盘的key/value存储，感觉好像是BerkeleyDB为Web领域应用重写的。它通常和Tokyo Tyrant搭配使用。Tokyo Tyrant是一个网络服务器，它将Tokyo Cabinet转变成网络服务，使用HTTP和memcached协议以及它自己的二进制协议通信。
和其它现代DBM实现类似，Tokyo Cabinet提供B-Tree，Hash和固定大小的类似数组的记录存储选项。它打动我是因为，使用Tokyo Tyrant时，在稳定的低级数据库架构上有一个现代网络协议和接口，让你选择正确的数据结构使用。它是相对成熟的技术，在某些高容量网站上也有其身影。
Apache CouchDB
下面的内容引自Apache CouchDB主页：
“Apache CouchDB是一个面向文档的数据库，可以使用JavaScript以MapReduce风格进行查询和索引，CouchDB也提供了增量复制，具有双向冲突检测和解决能力。”
CouchDB提供了一个RESTful JSON API，可以从任何允许HTTP请求的环境访问，也有无数的第三方客户端库使用，无论选择哪种编程语言都会变得很容易，CouchDB内置的Web管理控制台直接使用来自浏览器的HTTP请求与数据库交流。
CouchDB是用Erlang编写的，Erlang是一门功能强大的编程语言，它的理想是构建并发的分布式系统，Erlang允许灵活的，易于扩展且可轻松扩展的设计。
换句话说，CouchDB很时髦！
严格说来，CouchDB是第一个面向文档的针对Web设计的数据库，它现在属于Apache软件基金会，该项目相对比较成熟。
CouchDB吸引我是因为它看起来总是有点非关系数据存储的未来主义风格，它也使你能够使用服务器端JavaScript表现出Mapreduce风格，听起来似乎有定疯狂，但它确实能工作得很好，其API很简单，都是经过深思熟虑的，因此进入的门槛非常低，你可以在PC或笔记本电脑上轻松部署一个CouchDB实例，然后与云中或你公司数据中心的CouchDB服务器进行同步。
CouchDB也实现了一个非常有用的版本控制方案，从而不必重新发明车轮构建一个协作系统。
Riak
Riak是我最近才感兴趣的一个数据存储，它也是一个面向文档的Web数据库，它结合了分散的key/value存储，拥有一个灵活的Map/Reduce引擎和一个友好的HTTP/JSON查询接口，为Web应用程序提供了一个理想的数据库选择，为了最大限度提高网络和服务器中断时的可用性，它使用了最终一致性模型。实际上，Riak最有趣的特性是你可以很容易地控制参数，定义在出现问题时系统的可用性。
这些参数来自Eric Brewer的CAP定理，该定理指出我们应该关心的三种要素是：不同程度的一致性，可用性和分区冗余。和其它系统不一样，Riak并不强制你使用一组特定的CAP值，相反，它允许你在每个请求的基础上决定如何约束你想要的内容。
这得感谢三个变量：N，R和W。在一个分布式系统中，N是系统中复制品的数量，因此，如果你要写入一个新的key/value对，N设置为4，那么将有4个节点会收到它的复制品。
R和W是以每请求为基础设置的，为了控制节点的数量，客户端必须从一个完整的读或写操作接受一个响应，R表示读，W表示写。这提供了非常细粒度的控制，在集群环境中，客户端可以对失效的节点做出反应。
其它
还有很多其它的NoSQL系统，下面是我准备尝试的非关系数据库系统：
MongoDB：MongoDB是一个以VC为后端的分布式无模式数据库，有商业支持（参考阅读：MongoDB简介）。
Voldemort：Voldemort是一个相当成熟的系统，在LinkedIn上有大量的使用，它具有自动复制和分区功能。
MemcacheDB：MemcacheDB结合了BerkeleyDB存储系统和使用memcached网络协议的网络服务器，因此你可以创建一个类memcached的节点，可以比传统的基于RAM的memcached节点容纳更多的数据，并可以保证重启后数据不会丢失，在某些方面它和Tokyo Cabinet 和Tokyo Tyrant组合有些类似。
最后，我想问的是你已经涉足NoSQL了吗？它将何去何从？
【编辑推荐】
原文：NoSQL: Distributed and Scalable Non-Relational Database Systems 作者：Jeremy Zawodny
【51CTO.com译稿，非经授权请勿转载。合作站点转载请注明原文译者和出处为51CTO.com，且不得修改原文内容。】
