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查询，以利用所有的潜在优势。其中的过程可能很艰辛，但是当程序员找到了解决办法，这些数据库就能够真正焕发出活力。
