在两三年前，选择数据库是一件非常容易的事。资金充足的企业会选择甲骨文数据库，使用微软产品的企业通常SQL Server，而预算不足企业则会选择MySQL。不过，如今的情况已经大不相同了。

　　最近两三年，许多企业都推出了他们自己的开源项目以用于存储信息。在许多案例中，这些项目抛弃了传统的关系型数据库准则。许多人将这些项目称为NoSQL，即“Not Only SQL”的缩写。虽然有些NoSQL数据库很简单，但是还有一部分NoSQL数据库极为复杂。不过，它们的目标都是通过替代关系型数据库，并实现更高的系统性能。

　　NoSQL的支持者通过放弃传统架构成功建立起了速度更快，扩展性更高的应用。不过，一些保守的数据库管理员对此却不屑一顾。他们认为，许多SQL已经解决的问题将成为NoSQL的绊脚石。对此，NoSQL支持者并不在意，因为他们有着不同的项目需求，而如今他们正在瞄准新的目标。

　　NoSQL项目有什么不同之处呢？这些新型数据库被人们以自己的方式建立起来。相反，老的SQL数据库则聚合了大量的功能和一套标准语言。程序包可能会将键与值进行配对，但是它们可以针对不同的使用案例进行调整。主要的变量并不在于数据格式，而在于它们多久被复制、存储和分割。

　　例如，你是否存储一些例如个人电子邮件地址等经常被恢复的数据？一些数据是否被存储起来，以防不时之需，比如日志文件？你是希望有更多使用小容量数据的用户，还是希望只有几名使用大容量数据的用户？如果你丢失了几行用户数据，那么你的行为是否会影响到你的用户的生存，这些用户是否会起诉你？

　　过去，每名架构师都会为MySQL的设置而苦恼。现在，架构师可以选择一个全新的项目。如果你的项目需求与新型数据库的性能匹配，那么这种混乱中无疑蕴藏着巨大的优势。如果它们非常规整，性能将会获得不可思议的提升。但是，开发人员不会建造出一个可以解决所有问题的“无畏战舰”。

　　以前，开发者会创建很好的跨数据库函数库以消除差异，让它们变得更加容易转换。例如，许多Java开发者会在JDBC函数库上编写代码。这些数据库有着很好的互操作性。老的函数库没有一个可以与这些新数据库协同工作。尽管许多项目使用的是相似的方法，但是将一个函数库移植到另一个之上需要进行大量的重新编写工作。

　　更糟糕的是，许多辅助项目消失了。报告生成工具有许多种类，但是没有一个新型数据库可以使用这些工具。如果不进行一番折腾，它们是不会工作的。与SQL协同工作的程序包可能有成百上千种，但是能够帮助NoSQL的程序包却很少。有迹象显示，这种互操作性需要很长时间才能出现在NoSQL上。此外，查询语言也存在着很大的差异。

　　Cassandra

　　Facebook需要一个更快、更廉价的方式处理数以亿计的状态更新。因此，他们启动了这一项目，并最终将其移植到了Apache上，这就是Cassandra。在Apache上，它能够得到许多社区的帮助。目前Cassandra已经不再仅仅用于Facebook，许多为该项目工作的程序员来自其他公司。如今DataStax.com公司正致力于为Cassandra提供商业支持。

　　Cassandra是一个跟踪如Facebook上的状态更新等大量数据的优秀工具。这一工具可以帮助创建一个计算机网络，网络上的所有计算都拥有相同的数据。这意味着每台机器都可以被相互替代。一旦数据通过P2P网络节点，它们的一致性就会丧失。关键是“最终一致”，而不是“时刻一致”。如果你发现你的状态更新在Facebook消失一下，然后又重新出现，你就明白这意味着什么。

　　CouchDB

　　CouchDB被用于存储文档，最大的变化在于查询。取代一些基本查询结构的是，CouchDB通过两种功能来搜索文档，以导航并减少数据。一个编排文档格式，另一个确定包括哪些文档。一名清楚存储程序的、熟练的甲骨文数据库操作人员会做同样的事情。但是，导航和减少结构将让基层程序员大开眼界。目前，AJAX开发人员已经能够编写出相当复杂的搜索程序，这些程序可以写入一些更为复杂的逻辑。

　　CouchDB的核心由Erlang编写。但是API和界面却是JavaScript或是JSON。

　　JavaScript API仅仅是加强CouchDB对普通Web开发人员的吸引力。这些开发人员可以将文档，甚至整个网站存储在数据库中。

　　MongoDB

　　MongoDB是一个关于JavaScript如何掌握世界的典型。程序获取格式化为JSON格式的数据，然后将它们存储起来。查询是JavaScript的基础功能，这与使用浏览器控制台没有太大的差别，只是简化了一些东西。最大的区别是，MongoDB会为你的数据库创建索引，如果索引被正确地创建，那么反馈查询结果的速度将会很快。另外，该数据库可以与大量的其他工具协同工作。

　　Redis

　　与CouchDB和MongoDB一样，Redis用于存储文档和由键值对组织的文件。与其他的NoSQL数据库不同的是，其存储的不仅仅是字符串或是数字，其中还包括分类和未分类的字符串集合作为与键关联的值。这一特点使其可以为用户提供更为复杂的集合操作。用户不再需要下载数据计算交集，因为Redis能够在服务器上做这一工作。

　　Redis催生了一些没有过多编码的简单结构。Luke Melia通过创建一个全新集合追踪其网站上的访问者。最后五个集合的并集可确定那些当时在线的访问者。这一带有好友列表的并集的交集可以生成在线好友列表。这类集操作拥有许多应用。Redis集群为我们揭示了其强大的功能。

　　Redis将数据存储在内存中，仅记录下每次变化的列表。由于其具有功能强大，可写入硬盘中写入的缓存，许多人甚至并不将Redis称之为数据库。由于Redis只需要在数据读入内存之前进行等待，因此速度要比传统数据库快很多，但是不适时机的断电导致其存在潜在的应用风险。

　　Riak

　　Riak是设计最为精巧的数据存储，其拥有其他产品的绝大多数功能，并且对副本有着更多的控制。尽管基本结构存储着多对键值，但是恢复它们和确保它们的一致性的选项很多。比如写入操作包括了要求Riak确认数据何时被成功传输到集群其他机器上的参数。如果你不希望仅信任一台机器，在发送确认信息前，你可以要求其等待，直至两台、三台或是54台机器写入了数据。这也是该团队能够打出“最终一致性不是数据遗失的借口”这一口号的原因。

　　数据自身并不仅仅写在硬盘中。这只是其中的一个选项，但是并不是主要的。Riak使用的是插件式存储引擎（默认为Bitcask）。该引擎用它们自己的内部格式将数据写入硬盘中。此外，它还有多种选项，包括MySQL使用的InnoDB版本。Riak的集群能力可以确保所有一切都万无一失。

　　在抓取数据时，Riak会消除任何可能出现的错误。如果在两个节点的目标版本不同，那么Riak会选择最新升级版本，或是将两个目标版本都反馈回来，交由你的客户端代码做决定。对于发现数据中存在的潜在错误，这是一个非常有用的选项。

　　Neo4J

　　在我们所提到的几个应用之中，Neo4J是最具特色一个。它可以用于存储图而不是数据。它对图数据是以节点和边（关系）模式进行存储。社交网络应用是它的强项。Neo4J非常的新，开发人员仍然在寻找更好的算法。在新版本中，开发人员开始尝试新的缓存策略：由于Neo4J能够缓存节点信息，因此搜索算法运行速度很快。开发人员还为其增加了类似XSL模式匹配的新查询语言。

　　Neo4J受到了Neo Technology公司的支持。该公司推出的商业用版本数据库拥有备份、故障恢复和复杂监视功能。

　　FlockDB

　　有些人抱怨代码过于复杂，他们认为Neo4J过于复杂，超出了他们的需求。那么他们不妨尝试一下FlockDB。FlockDB是一个实时的、分布式的数据库，是Twitter网站基础设施的核心组件。Twitter在一年多以前推出了基于Apache许可证的开源项目FlockDB。如果你想建立起自己的Twitter，那么你需要下载Gizzard工具，其作用是分割跨多个Flock的数据。由于FlockDB存储两个节点之间的关联，我们中的许多人将FlockDB称为“图数据库”。不过，也有人认为这一称呼仅适用于像Neo4J这类复杂的工具。（范范编译）

　　如何选择NoSQL数据库？

　　关于如何选择NoSQL数据库这一问题并不好回答。许多IT部门会随便选一个，有时候他们选择的数据库并不能满足他们的需求。由于优秀的开发人员希望能够平衡项目的优势、商业支持的可获得性以及文档质量，因此选择一个最佳数据库是十分困难的。

　　这些数据库都存储了大堆的键和值，但是真正的问题是如何在服务器中合理分配负载，如何将变更传递给它们。另一个问题是托管。云服务能够替你完成所有的维护，这一点非常具有吸引力。与SQL数据库相比，NoSQL数据库的数据交换更为困难。目前全球还没有一个标准的查询语言，也没有一个像JDBC一样的大型虚拟层。尽管如此，NoSQL数据库已经对我们具备了足够的吸引力。