说起数据库，大多数人的第一反应估计就是Oracle 跟 MySQL这两个关系型数据库。这也不难理解，毕竟，自从1969年 IBM公司的研究员 E. F. Codd 提出关系数据模型以后，关系模型的概念就一直蓬勃发展并逐渐成为了主流数据库采用的模型，在工业界的统治地位根深蒂固。没图没真相，下面这张来自 DB-Engines 的最新数据库排名表就告诉了我们，它们是怎样无情地碾压对手的： 排名前10 的数据库在过去的一年里几乎没怎么改变过，这里面就有 7 个是关系型数据库。其中前 3 名全部都是关系型数据库，并且它们的分数遥遥领先于紧随在它们后面的所有数据库。 那么关系型数据库为什么那么好呢？在小编看来，主要有三宝： 相比于与关系模型同期出现的网状模型，层次模型等数据模型来说，关系模型的二维表结构非常贴近逻辑世界的概念，更容易理解。例如下图就展示了一个学生管理系统里面关于学生、课程以及选课情况的三张关系表。Students 表里面的每一行代表了一个学生，Courses 表里面的每一个代表了一个课程，而 Scores 表记录了每一个学生选修过的课程以及分数。 通用的标准化查询语言 SQL使得关系型数据库的数据操作变得非常方便，用户不需要理解底层的存储原理也能够简单实现数据的存取。例如对于前面的例子，如果用户希望查找学生“张三”所选过的课程以及成绩，只需要执行一个如下图所示的简单SQL语句就可以得到表格化的结果。 关系模型丰富的完整性约束以及一致性定义等功能大大降低了数据冗余和不一致性出现的概率。 如果说软件开发主要就是程序设计和数据存储，那么关系型数据库的演化以及成熟，把软件开发者们从数据存储这个复杂的问题中解放了出来，从而可以更专注于应用的功能逻辑实现。而所有的这一切，在互联网时代的到来之前是显得那么的美好，一派欣欣向荣。那么问题来了，之前可以做得那么好的关系型数据库为什么就出问题了呢？ 为了解答这个问题，我们从互联网企业带头大哥 Google 身上来看一下互联网时代的数据处理系统有什么样的特点。 Google 在 2013 年的一份报告指出，目前全球大概有 30 万亿个网页，为了索引这些页面，Google 的索引消耗了1亿 GB的存储。遥想1999年Google 刚刚成立的时候，它每天的搜索量大概在 1 万次左右；而到了今天，Google 每天的搜索量已经去到了 55 亿次，平均每秒钟接近 6.3 万次。 这意味着 Google 目前每秒钟处理的查询量都已经远远超过了当年它刚成立时每天的规模。这样的数据规模存储在一台机器上显然是不行的，必然需要分散到多台机器上进行处理。正是这种分布式的存储需求的出现，引发了数据存储领域的一场重大的革命NoSQL 的出现。 在我们介绍 NoSQL 之前，我们先来介绍一下分布式领域大名鼎鼎的 CAP 定理。不懂点 CAP 理论，你都不好意思说自己是做分布式存储的。 那么 CAP 定理到底是什么呢？CAP其实是Consistency、Availability以及 Partition (tolerance) 三个英文单词的首字母。2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。 2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。该理论断言，对于任何基于网络的分布式系统，最多只能满足数据一致性（C）、可用性（A）和分区容错性（P）三要素中的两个要素。 传统的关系型数据库一般采用了强一致性。还记得以前上数据库系统导论课，老师解释事务处理的时候一般都会举的从一个银行账户转账到另一个银行账户的例子吗？对的，就是它。对于涉及到钱财这样的操作在一致性方面根本不能有丝毫的让步，要不然银行账户上就会出现了凭空出现或者消失的钱了。另一方面，如果网络发生故障时，银行选择停止服务的话，这就是为了保证 CA 而舍弃了 P；如果选择只读不写的话，就是保证了 CP 而舍弃了 A。 为了保证强一致性，关系型数据库在一些操作上（例如二阶段提交等）的开销影响了其他功能的实现，例如，关系型数据库无法进行大规模的扩展。 尽管目前有很多的网络解决方案一定程度上改善了这个问题，但在网络中仍然无法动态的创建新的集群。因此，使用关系型数据库来作为大数据解决方案的底层框架将会变得异常昂贵。 如果说扩展性是关系型数据库的一个硬伤，那么下面的两个不足就是伤上加伤了： （1）互联网企业中大部分的数据都是半结构化和非结构化的（XML文档，语音图像数据等），关系型数据库并不能很好地处理这些类型的数据。 （2）基于关系型数据库的查询难以实现某些类型的数据操作（或者说代价高到难以接受），比如两点间的最短线路。 对于多数大型互联网应用的场景，数据量越来越大导致的主机数量，集群规模越来越大，节点故障、网络故障等已经成为了常态，在这种情况下要保证服务可用性达到N个9（即保证P和A）就只能舍弃C了（或者退而求其次保证最终一致性）。这样虽然某种程度上会影响客户体验，但这种结果是可以接受的。现在的NoSQL大多数采用了这种模式。 而为了解决前面提到的关系型数据库的另外两个不足之处，工业界学术界尝试了各种不同的数据模型。目前主流的NoSQL解决方案包括了 Key-value，Column Family，Document 以及 Graph 四种方案。 那么这些数据模型具体是怎么回事呢？我们将在下一篇文章里面做进一步的阐述。Stay tuned! 欢迎长按下图二维码关注我们的“一个比特”公众号，发现更多精彩。 关注一个比特 以专业态度解析大数据 以开放视角做大数据商业化 |
注册
登录
