Darrell Burgan：“我是专业信息系统架构师，擅长将云扩展产品和业务需求结合起来。在这个行业，我已经工作26年了。和很多老兵一样，我见证了很多技术趋势起起落落，但有一点是永恒不变的，那就是最快、最灵活地满足业务目标。

阅读上一篇：《从CAP定理看NoSQL数据库选型》

一致性还是可用性？

然而，该CAP模型是不完整的。如果你仔细想想，CA系统真正为您提供的保障是什么?它声称在牺牲了网络分区能力的基础上，为您提供一致性和可用性。但是，当发生网络中断时，那会发生什么?要么必须牺牲一致性(这意味着你允许数据差异出现)，要么必须牺牲可用性(这意味着允许数据库关闭)。鉴于这点，我认为应该定义一个更简单的CAP定理，就是在网络分区上，分布式系统必须在一致性和可用性中做出选择。

考虑到在现实世界网络中断的情况,我没有看到其他的结论:

只有两种实用的分布式持久性系统:一致性系统和可用性系统

选择其中之一

现在考虑牺牲可用性的真正意义是什么。如果您的持久性分布式系统位于一个单独的数据中心之上，并且具备一个真正可靠的、高速的、稳定的网络，那么你可以选择一致性而不是可用性。你的赌注在于你认为一致性的好处远远超过了网络失败的可能性。而且对于大多数数据中心来说，这可能是一个非常合理的赌注。

然而,如果你的分布式持久性系统处于不可靠的网络,或者如果您计划未来建立一个跨数据中心系统，那么你除了放弃一致性、支持可用性之外别无选择。

对于分布式数据库来说，这是必要的折衷。如果你的业务允许你在同一全球数据中心为所有客户服务,并且永远不需要你改变拓扑结构,那么你很幸运。你可以选择一致性或是可用性。而对其余人来说，我们真的别无选择,只能放弃一致性,这样我们才能有合理数量的可用性。老实说:

从长远来看,一致性是十分必要的。

随着互联网变得更大，世界变得越来越小，全球的可扩展性也将日益普遍。同理，一个全球分布的数据库不需要具备一致性。但现在，如果你的应用程序不要求这种规模，那么无论如何都请使用一致性数据库。

可用数据库扩展

接下来要谈一下我对于产品的立场。我唯一真正感兴趣的NoSQL数据库是那些线性向外扩展的数据库。或许你有其他的需要,但我的需要是NoSQL扩展定义的问题。让我们通过可扩展性的程度来看看各种NoSQL数据库的表现吧。

首先,我认为在NoSQL数据库中,如使用任何形式的主从复制、或集群中节点的概念等等，比其他观点更为重要。按照这些线路构成的可扩展性反模式来说，我相信有很多人会认为我错了。鉴于MongoDB的流行,但不可否认的是,这些类型的系统并不成线性比例。

其次，我认为NoSQL数据库在本地网和广域网之间有些概念上的不同是至关重要的。本地网络往往具有惊人的可靠性，并倾向于提供让人意想不到的带宽。吉比特以太网现在是每个数据中心的标准，甚至更快的网络也会变得越来越常见。然而，广域网典型地提供较少的带宽，并且一般是不可靠的。到目前为止，最符合成本效益的广域网是通过公用网络本身的隧道VPN，但这种连接并不像公共网络那么可靠，往往有很多的瞬态问题。专用线路则比VPN更可靠，但其带宽是相当昂贵的。因此，如果你的可扩展方程包括对于广域网的需求，你需要在区分差异的基础上考虑一致性系统。

这才有了下面的分析，以产品受欢迎程度排序：

(我写到Dbase就停止了，因为我不相信人们仍使用比它更古老的数据库!)

在任何情况下,我的结论非常简单。目前,只有三种NoSQL数据库可以满足我对于可扩展性的定义,在于它们的线性向外扩展性和处理本地和广域网络之间的差异的能力: Cassandra ,Couchbase, 和 Riak . MongoDB明显不是在名单之列。

数据多样性问题

到目前为止需要注意的是，我还没有提到图形数据库、文件数据库、柱状数据库、键值存储等事情。这是故意的，因为我不认为那些五花八门的数据库之间的差异与NoSQL数据库质量定义有关。在我看来，有关一致性和可用性的比例问题，是推动NoSQL发展的基础性问题。正如它们所说，有时候你真的持有一些十分特别的数据类型，并不适合向外扩展的分布式数据库。

在这些理论中，最常见的需要就是分析数据，这些数据往往是被附加上的,但不会被修改。庞大的数据就是在这样的情况下产生的，当然已经存在很多可以迎接这种挑战的NoSQL系统。我不是一个数据科学家，所以不打算在权衡各种产品的相对优势。鉴于存在很多的选择，如果有这方面的需求的话，你应该深入调查一下。

或者，也许你会在一个简单的模式下存储用户的会话信息，但这会因为读写容量而破坏关系型数据库服务器。在这种情况下，也许你应该调查一个键值存储或分布式缓存/数据网格的解决方案。

也许你需要一个具有搜索大数据、不经常变动的能力的数据库。也许你需要能够通过语言感知进行启发式/模糊搜索。在这些情况下，你可能需要一个具备倒排索引的搜索引擎。

有时侯，你可能有一个仍在关系数据库里存储着的事务性数据类型。也许对于Facebook和这些疯狂的人之间的关系曲线图来说,关系数据库可以建模但并不支持高交易量。在这种情况下,也许你应该调查一下图形数据库。也许你有一些珍贵的二进制数据, 过快地填满关系数据库那昂贵的固态磁盘。对于大型二进制对象来讲，也许你应该考虑使用键值存储优化。

因此，的确是这样，确实有一些特定数据类型必须使用NoSQL数据库。但我觉得这些往往是例外。我在网上看了许多各种各样的文章，例如有关文档数据库是你应该关心的一件事、所有其他数据库模型已经过时，而我所能做的就是擦亮自己的眼睛。我认为了解键值型数据库和庞大关系型数据库之间的差异是十分重要的，老实说，我并没有真正搞清楚,它们有相对的优点和缺点，这些差异看似微小但在规模和分布方面却十分重要。在技术上所有的东西都一样，我认为我们应该专注于真正重要的新技术属性，而忽略那些我们很快忘记、却又不可避免会成为流行语的闪亮部分。

因此，我最后的一点建议是：

不要因为一种数据模型所谓的好处而选择使用NoSQL。

你可以因为可扩展性的需求，或者真的需要一个并不适合关系数据库的使用场景来使用它。

结论

最近，许多人有关于NoSQL的很多意见，我当然也不例外。我认为这篇文章与我最近阅读的其它文章略有不同，它往往侧重于数据模型和有趣的、无关大局的、具备其它功能的NoSQL产品。希望你们可以赞成我的观点。

几年前，在我第一次开始调查NoSQL产品的时候，发现有多少选择、几个标准，我已经将这些建议都写在了这篇文章中。当然它帮助我避免一些早期的错误，我希望你发现它同样有价值。