NOSQL数据模型和CAP原理

NOSQL数据模型和CAP原理

http://blog.sina.com.cn/s/blog_7800d9210100t33v.html

我原本一直以为NoSQL其实很容易理解的，我自己也已经对NoSQL有了很是深刻的研究，可是在最近准备YunTable的Chart的时候，发现NoSQL不只很是博大精深，并且我我的对NoSQL的理解也只是皮毛而已，但我还算是一个“知耻然后勇”的人，因此通过一段时间的学习以后，从本系列第六篇开始，就将和你们聊聊NoSQL，而本篇将主要给你们作一下NoSQL数据库的综述。

首先将和你们聊聊为何NoSQL会在关系型数据库已经很是普及的状况下异军突起?

诞生的缘由

随着互联网的不断发展，各类类型的应用层出不穷，因此致使在这个云计算的时代，对技术提出了更多的需求，主要体如今下面这四个方面：

1. 低延迟的读写速度：应用快速地反应能极大地提高用户的满意度;
2. 支撑海量的数据和流量：对于搜索这样大型应用而言，须要利用PB级别的数据和能应对百万级的流量;
3. 大规模集群的管理：系统管理员但愿分布式应用能更简单的部署和管理;
4. 庞大运营成本的考量：IT经理们但愿在硬件成本、软件成本和人力成本可以有大幅度地下降;

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位，可是因为其天生的几个限制，使其很难知足上面这几个需求：

1. 扩展困难：因为存在相似Join这样多表查询机制，使得数据库在扩展方面很艰难;
2. 读写慢：这种状况主要发生在数据量达到必定规模时因为关系型数据库的系统逻辑很是复杂，使得其很是容易发生死锁等的并发问题，因此致使其读写速度下滑很是严重;
3. 成本高：企业级数据库的License价格很惊人，而且随着系统的规模，而不断上升;
4. 有限的支撑容量：现有关系型解决方案还没法支撑Google这样海量的数据存储;

业界为了解决上面提到的几个需求，推出了多款新类型的数据库，而且因为它们在设计上和传统的NoSQL数据库相比有很大的不一样，因此被统称为 “NoSQL”系列数据库。总的来讲，在设计上，它们很是关注对数据高并发地读写和对海量数据的存储等，与关系型数据库相比，它们在架构和数据模型方量面作了“减法”，而在扩展和并发等方面作了“加法”。如今主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、 CouchDB、MongoDB和Redis等。接下来，将关注NoSQL数据库到底存在哪些优缺点。

优缺点

在优点方面，主要体如今下面这三点：

1. 简单的扩展：典型例子是Cassandra，因为其架构是相似于经典的P2P，因此能经过轻松地添加新的节点来扩展这个集群;

2. 快速的读写：主要例子有Redis，因为其逻辑简单，并且纯内存操做，使得其性能很是出色，单节点每秒能够处理超过10万次读写操做;
3. 低廉的成本：这是大多数分布式数据库共有的特色，由于主要都是开源软件，没有昂贵的License成本;

但瑕不掩瑜，NoSQL数据库还存在着不少的不足，常见主要有下面这几个：

1. 不提供对SQL的支持：若是不支持SQL这样的工业标准，将会对用户产生必定的学习和应用迁移成本;
2. 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各类附加功能，好比BI和报表等;
3. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语;

上面NoSQL产品的优缺点都是些比较共通的，在实际状况下，每一个产品都会根据本身所听从的数据模型和CAP理念而有所不一样，接下来，将给你们介绍NoSQL两个最重要的概念：数据模型和CAP理念，并在本文最后，对主流的NoSQL数据库进行分类。

数据模型

传统的数据库在数据模型方面，主要是关系型，它的特点是对Join类操做和ACID事务的支持。在NoSQL领域，主要有三种主流的数据模型：

Column-oriented(列式)

列式也主要使用Table这样的模型，可是它并不支持相似Join这样多表的操做，它的主要特色是在存储数据时，主要围绕着“列(Column)”，而不是像传统的关系型数据库那样根据“行(Row)”进行存储，也就是说，属于同一列的数据会尽量地存储在硬盘同一个页(Page)中，而不是将属于同一个行的数据存放在一块儿，这样作的好处是，对于不少相似数据仓库(Data Warehouse)的应用，虽然每次查询都会处理不少数据，可是每次所涉及的列并无不少，这样若是使用列式数据库的话，将会节省大量I/O，而且大多数列式数据库都支持Column Family这个特性，经过这个特性能将多个Column并为一个小组，这样作好处是能将类似Column放在一块儿存储，这样能提升这些Column的存储和查询效率。整体而言，这种数据模型的优势是比较适合汇总(Aggregation)和数据仓库这类应用。.

Key-value

虽然Key-value这种模型和传统的关系型相比较简单，有点相似常见的HashTable，一个Key对应一个Value，可是其能提供很是快的查询速度、大的数据存放量和高并发操做，并不是常适合经过主键对数据进行查询和修改等操做，虽然不支持复杂的操做，可是能够经过上层的开发来弥补这个缺陷。

Document(文档)

在结构上，Document和Key-value是很是类似的，也是一个Key对应一个Value，可是这个Value主要以JSON或者XML等格式的文档来进行存储，是有语义的，而且Document DB通常能够对Value来建立Secondary Index来方便上层的应用，而这点是普通Key-Value DB所没法支持的。

CAP理论

这个理论是由美国著名科学家，同时也是著名互联网企业Inktomi的创始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大会上提出的，后来Seth Gilbert 和 Nancy lynch两人也证实了CAP理论的正确性，虽然在后来近十年的时间不少人对CAP理论提出了不少异议，可是在NoSQL的世界中，它仍是很是有参考价值的。它的意思是，一个分布式系统不能同时知足一致性，可用性和分区容错性这三个需求，最多只能同时知足两个。

1. 一致性(Consistency)：任何一个读操做老是能读取到以前完成的写操做结果，也就是在分布式环境中，多点的数据是一致的;
2. 可用性(Availability)：每个操做老是可以在肯定的时间内返回，也就是系统随时都是可用的。
3. 分区容忍性(Partition Tolerance)： 在出现网络分区(好比断网)的状况下，分离的系统也能正常运行。

因为一致性、可用性和分区容忍性这三方面只能选择两个，因此大多数NoSQL系统都会根据本身的设计理念来进行相应的选择，但因为许多NoSQL数据库都以水平扩展著称，因此在CAP的选择上面，都倾向于坚持分区容忍性，而放弃一致性或者可用性，它们的作法主要是经过消减关系型和事务相关的功能。

具体分类

下面的具体分类是来自于Visual Guide to NoSQL Systems一文，虽然对于这块分类我我的以为还存在一些牵强的地方，好比将能支持多种CAP配置的Dynamo和其衍生产品Cassandra归类为 AP，可是整体而言，这个分类仍是至关不错，在现阶段很是具备参考价值，在每一个相关的数据库后面还会介绍对应的数据模型。

▲图1. NoSQL产品分类图(参考1)

关注一致性和可用性的 (CA)

这些数据库对于分区容忍性方面比较不感冒，主要采用复制(Replication)这种方式来保证数据的安全性，常见的CA系统有：

1. 传统关系型数据库，好比Postgres和MySQL等(Relational) ;
2. Vertica (Column-oriented) ;
3. Aster Data (Relational) ;
4. Greenplum (Relational) ;

关注一致性和分区容忍性的(CP)

这种系统将数据分布在多个网络分区的节点上，并保证这些数据的一致性，可是对于可用性的支持方面有问题，好比当集群出现问题的话，节点有可能因没法确保数据是一致性的而拒绝提供服务，主要的CP系统有：

1. BigTable (Column-oriented) ;2. Hypertable (Column-oriented);3. HBase (Column-oriented) ;4. MongoDB (Document) ;5. Terrastore (Document) ;6. Redis (Key-value) ;7. Scalaris (Key-value) ;8. MemcacheDB (Key-value) ;9. Berkeley DB (Key-value) ;关于可用性和分区容忍性的(AP)这类系统主要以实现"最终一致性(Eventual Consistency)"来确保可用性和分区容忍性，AP的系统有：1. Dynamo (Key-value);2. Voldemort (Key-value) ;3. Tokyo Cabinet (Key-value) ;4. KAI (Key-value) ;5. Cassandra (Column-oriented) ;6. CouchDB (Document-oriented) ;7. SimpleDB (Document-oriented) ;8. Riak (Document-oriented) ;