从CAP定理看NoSQL数据库选型

我猜测很多人在尝试接触NoSQL行业时会遇到困惑。让人眼花缭乱的产品、加上各种各样新奇的理念，经常会使那些只希望使用正确技术来完成特定工作的架构师更加迷惑。我当然能够理解, 因为这就是曾经的我所走过的路, 在这一路上我得到很多宝贵经验。

在这篇文章中，我希望和你们分享这些经验，并给出一些实用建议,如果以前有人给我这些建议,那我将少走很多弯路，现在让我们开始吧。
为什么要使用NoSQL？

如果因为它可能会是新趋势，或是因为你看到其他人正在使用它，亦或因为它是闪亮的新玩具，你才会考虑使用它，那么请马上停止。事实上，如果你并不打算解决一个关系数据库。那被称为关系数据库的古老技术才是你真正的朋友。因为它不会丢失你的数据、不会崩溃，就其所做的事情而言，它的表现已经足够完美。而且对于商务应用程序而言，许多人将它作为最直接的、持久的基础。就像家庭SUV，它并不迷人，却轻而易举就可以把你带到你想去的地方,并允许你存放各种各样的东西。

因此，这是我的第一条建议：

你只能在确实需要NoSQL数据库的时候使用它。

我很认真负责地说。
四个关键的问题

鉴于以上建议，你怎样知道你是不是真的需要它?在我的经验中, NoSQL最典型和突出的需求包括下列几点：


    我已经购买了世界上最快的机器，但我的数据库服务器仍然不堪重负, 那么,现在该做什么?
    我怎样才能够在另一个大陆上建立新的数据中心，并以某种方式实现与大洋彼岸的数据同步?
    我需要为数据分析提供大量的只读半结构化数据，并且极其不适合关系模型。我应该将它存储在哪里?
    我有一个十分奇异的的数据类型并且不适合关系模型。我该怎么做?


你可以沿着这些线路，想象许多类似的问题。但这个样本已经可以识别出NoSQL产品试图解决的各种关键问题：

本地规模的问题。“对于一台服务器来说，我的交易量太大，并且需要可以扩展的数据库”

大数据的问题。“对于单个服务器来说,我的数据量太大,而且需要跨多个服务器运行”

全球数据的问题。 “我不得不扩大规模以至于超出了单个数据中心,并且需要支持全球云的数据库”

数据的多样性问题。“我的数据需求有分歧，并且一个放之四海而皆准的方法已不再起作用。”

根据我的经验，没有一个NoSQL的产品很完美地解决了所有这些问题，尽管很多公司宣称他们可以做到。因此，你应该根据实际问题来选择适合的NoSQL产品，不要浪费时间去担心其它。如果你仔细想想这些，或许迫使你考虑NoSQL的商务问题将不再是其基本问题之一。

需要注意的是，这些问题都与成本没有任何关系。我猜测你或许认为转移到NoSQL可以节省成本，但事实是，从总数上计算你可能会花费更多。当然，在短期内你需要增加开发人员再培训的费用成本，等等。我故意省略了NoSQL的财务方面的任何讨论，因为我认为使用它的原因是基于技术的必要性，没有任何形式的成本节约或者收入加速。

还要注意的是，除了数据多样性的问题，所有的这些问题直接意味着需要某种分布式持久类型的系统。

CAP定理

如果我们不了解基本的上限定理，我们很难更近一步。我相信你已经听过 Eric Brewer提出的基本定理。当然，这个定理周围存在着很大的恐惧、不确定性和怀疑。让我们尽量将它变得简单一些：

其基本思路是，对于任何分布式数据系统来说，这里共有三种基本保障制度，在任何时刻你最多只能包括其中两个：

一致性：数据系统保证使用线程进行数据更新的一致性。例如隔离级别、事务等。

可用性：数据系统可以排除中断和故障，从而确保该系统连续运行。例如无单点故障等等。

分区兼容性：数据系统保证它可以兼容网络分区，而不会发生错误或数据丢失。例如现存网络中断等。

在这三种基本保障制度中，每一个数据系统将实现至少一个并争取实现两个。但在有人发明了时间机器之前(如果他们这样做了，我当然想跟那个人讨论一下)，其物理上并不可能保证实现所有三个。因此,CAP定理为任何持久性系统定义了关键的权衡，同时理解一个持久化系统如何与CAP定理相关联，这应该是你在评估任何持久性系统时的第一目标。