NoSQL风行之后，其提供更快数据存储速度让人们倍感兴奋和陶醉。如今NoSQL的蜜月期已经结束，热情散去之后，我们需要以冷静的目光审视那些难以接受的真相。

　　请不要误会。我们目前仍然在不断地尝试创建一个简单的数据存储机制，也仍然在挖掘MongoDB、CouchDB、Cassandra、Riak和其他NoSQL数据库的深层次价值。我们仍然在规划将最重要的数据存储在NoSQL数据库中，因为它们正在日益强大，越来越经得起考验。

　　不过，我们也开始察觉到了一些问题，NoSQL似乎没有我们想像中的那么完美，它们甚至经常令人感到恼火。明智的开发者明白这一切只是刚刚开始。他们没有扔掉SQL操作手册，也没有中断与他们曾经信任的SQL数据库供应商之间的联系。他们将NoSQL理解为“Not Only SQL”。

　　以下是NoSQL目前面临问题的列表，这些问题或大或小，我们这样做的目的是向公众展现实际的情况并澄清事实。只有坦然面对这些问题，才能够更好地理解NoSQL的优势与不足。

　　真相1：一致性困扰

　　人们对SQL系统的一个不满意地方是，在两个表单间执行一个连接（JOIN）所需的计算成本。其理念是在一个，即唯一的一个地方存储数据。如果你保存一个客户名单，将他们的住址保存在一张表单上，在其他的每一张表单上使用客户的ID。当你拖动数据时，JOIN将所有ID与住址连接在一起，让所有的数据保持一致性。

　　问题是JOIN非常昂贵，一些DBA（数据库管理员）使用极为复杂的JOIN命令，它们能让最好的硬件也会变成垃圾。NoSQL开发者是这么解决JOIN不足的：让我们将客户的地址像其他所有的东西一样都存储在相同的表单上。NoSQL的做法是存储与每个人配对的键值。在需要时，你可以检索到它们。

　　不幸的是，希望让自己的表单保持一致的人们仍然需要JOIN。一旦开始存储客户的地址，你需要经常将这些地址的多个拷贝保存在每张表单中。你拥有多个拷贝，并且需要同时升级它们。如果你没有这么做，那么NoSQL将不会帮你进行交易。

　　真相2：交易复杂性

　　如果说你能够习惯没有JOIN的表单，因为你希望获得更高的速度。这种取舍还是可以接受的。有时候，SQL的数据库管理员就是出于这种原因才使用非规范化表单的。问题是NoSQL难以保持各种条目的一致性。很多时候，没有一个交易可以确保能同时对多个表单做出调整。出于这种原因，你只有依靠你自己，一个崩溃将会导致表单变得前后矛盾。

　　最早的NoSQL部署无视这些交易。除非没有设定一致性，否则它们将提供保持一致性的数据列表。换句话说，他们追求的是最低价值的数据。在这种情下，错误不会导致任何重大差异。

　　真相3：灵活性怪圈

　　许多NoSQL程序员喜欢吹嘘他们的代码如何简洁，工作机制运行的速度有多快，等等。当任务像NoSQL那样简单时，通常他们的说法是对的，但是当问题复杂之后，情况就改变了。

　　我们应该考虑到JOIN的挑战。一旦NoSQL程序员开始在他们自己的逻辑中加入自己的JOIN命令，他们就会开始尝试更为有效地做这项工作。SQL数据库开发者花了数十年的时间开发巧妙的引擎，以便让JOIN命令尽可能地高效化。一个SQL数据库开发者告诉我，他正在尝试让自己的代码与硬盘转速同步。这样一来，他就能够仅在磁头处于正确位置时请求数据。这看起来有些极端，但是SQL数据库开发者为此已经努力了十余年的时间。

　　毫无疑问，程序员们已经绞尽脑汁组织他们的SQL查询，以利用所有的潜在优势。其中的过程可能很艰辛，但是当程序员找到了解决办法，这些数据库就能够真正焕发出活力。

　　真相4：访问模式过多

　　在理论上，SQL被认为是一种标准的语言。如果你在一个数据库中使用SQL，你应该能够在另外一个兼容版本中执行相同的查询。这一说法可能仅对一些简单的查询有效，但是每个DBA都清楚，他们需要花上数年时间才能掌握不同版本数据库的SQL的特点。关键词被重新定义，在一个版本中正常运行的查询，在另一个版本中可能就无法正常运行。

　　NoSQL更为神秘莫测，它们就如同通天塔一样。从一开始，NoSQL开发者就在竭尽全力地想要设计出最佳语言，但是他们的设想有着很大的差别。起初实验效果还是不错的，但是当你尝试在工具间切换时情况就变了。CouchDB查询被表述为用于映射与约简的java script功能。Cassandra早期版本使用了一个原始而低级的API（应用编程接口），即Thrift。新版本推出了CQL，一种与SQL类似的查询语言，它必须要被服务器所解析和理解。每一个的设计原理都不尽相同。

　　真相5：纲要灵活性存在问题

　　NoSQL的一个重要理念是不需要纲要。换句话说，程序员不需要提前决定表单中的每一个行需要使用哪个列。一个条目可能有20个相关的字符串，另一个可能有12个整数类型，另一个可能完全是空白。程序员能够在他们需要存储时随时做出决定。他们不需要获得DBA的许可，他们也不需要填写所有的文档，以增加一个新的列。

　　这些自由听起来非常具有诱惑力，并且能够加快开发速度。但是对于需要三个开发团队的数据库来说，这真的是一个好主意吗？对于可能持续六个月以上时间的数据库来说，它们是否可行？

　　换句话说，开发者可能希望利用这些自由将老的Pair（对）加入到数据库中。但是，在四名开发者已经选择了他们自己的键后，你希望成为了第五名开发者吗？我们可以想象一下“birthday”（生日）的多种表达方式。在添加用户生日进入条目中时，每名开发者都会选择他们自己的表示方式。一个开发团队几乎可能会想到所有的表示形式，例如“bday”、“b-day”和“birthday”。NoSQL架构并不支持限制这一问题，因为这意味着要重新设计纲要。它们不希望对个性化的开发者加以限制。

　　真相6：没有附加功能

　　你不希望把所有的数据存储在所有的行中。你希望得到单选索引的总数。SQL用户能够通过SUM操作执行一个查询，然后向你反馈一个数字。NoSQL用户则将所有的数据反馈至他们那里，然后自己进行添加。添加并不是问题，因为在任何机器上增加数字都需要花上相同的时间。但是数据反馈却非常慢。反馈所有数据所需要的带宽也非常的昂贵。

　　NoSQL数据库中几乎没有附加功能。除了存储和检索数据外，如果你想做任何事情，你可能需要自己动手。在许多案例中，通过完整的数据复制，你可以在不同的机器上做这些事情。真正的问题是，它对在保留有数据的机器上进行计算有帮助，因为可以省去数据反馈的时间，但是对于你来说却是非常的困难。

　　MongoDB提供的映射与约简查询架构可以让你通过任意的java script架构来简化数据。在拥有数据的机器间分发计算方面，Hadoop是一个强大的机制。它是一个快速演进的架构，可以为创建复杂的分析快速提供改良的工具。这听起来非常酷，但是Hadoop技术本身却非常新。尽管Hadoop与NoSQL之间的差别正在消失，但是在技术上，Hadoop是一个与NoSQL完全不同的东西。

　　真相7：工具太少

　　你能够在服务器上部署NoSQL并运行它们。当然，你也能够编写你自己自定义代码以读写数据。但是如果你希望做更多的事，那它们会怎么样呢？如果你想购买一个报告套件，一个绘图套件或是下载一些用于创建图表的开源工具，它们又会怎么样呢？

　　很不幸，大多数工具都是针对SQL数据库编写的。如果你想生成报告，创建图表，或是利用NoSQL堆栈中的数据做一些事情，你需要重新进行编写。目前已经有了用于处理来自甲骨文数据库、微软SQL Server、MySQL和Postgres等SQL数据库中数据的标准工具。你的数据是NoSQL类型的吗？目前工具制造商们正在努力解决这些问题。

　　目前有20多个不同的NoSQL选择，这些选择都拥有自己的理念和处理数据的方式。对于工具制造商而言，他们难以支持SQL的特点和不一致性。然而与之相比，为NoSQL解决方案制造相关工具则更为困难。

　　当然，这一问题会慢慢消灭。开发者们已经意识到了NoSQL的优势，他们将修改自己的工具，以适合这些新的系统，不过这要花上些时间。或许他们会针对MongoDB开发出一些工具，但是这对于使用Cassandra的用户而言没有丝毫的帮助。在这种情况下，标准就显得尤为重要，但是在这一方面，NoSQL并不擅长。