NOSQL数据模型和CAP原理

标签: nosql 数据模型 cap | 发表时间:2014-03-01 20:35 | 作者:zwllxs
出处:http://www.iteye.com
我本来一直觉得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) ;


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [nosql 数据模型 cap] 推荐:

NOSQL数据模型和CAP原理

- - 数据库 - ITeye博客
我本来一直觉得NoSQL其实很容易理解的,我本身也已经对NoSQL有了非常深入的研究,但是在最近准备YunTable的Chart的时候,发现NoSQL不仅非常博大精深,而且我个人对NoSQL的理解也只是皮毛而已,但我还算是一个“知耻而后勇”的人,所以经过一段时间的学习之后,从本系列第六篇开始,就将和大家聊聊NoSQL,而本篇将主要给大家做一下NoSQL数据库的综述.

论NoSQL的数据模型

- - NoSQLFan
本文内容是对《 NoSQL Data Modeling Techniques》一文的简单概述,原文对NoSQL的几种 数据模型进行了详细深入的讨论. 是了解NoSQL数据模型不过错过的全面资料. NoSQL的一些非功能性的特性,比如扩展性、性能以及一致性的讨论,目前已经有很多. 而对于NoSQL产品内部数据模型相关的知识一直比较欠缺,本文就希望能够系统地对NoSQL数据模型进行一些探讨.

NoSQL 数据模型资料小全

- medal - NoSQLfan
在 Linkedin 的 NoSQL Group 上,有一位同学求 NoSQL 底层实现方面的资料,于是回复就变成了各种资料聚集地了. 本站将资料整理在下面,希望对大家有用. Cloudera’s 关于 HBase 的文章:. 下面是10gen团队发的一篇文章,论述MongoDB 的数据模型:. 关于Amazon Dynamo的一篇文章:.

谈NoSQL数据模型-转载

- - 人月神话的BLOG
原文: http://blog.nosqlfan.com/html/3689.html. 本文内容是对《NoSQL Data Modeling Techniques》一文的简单概述,原文对NoSQL的几种数据模型进行了详细深入的讨论. 是了解NoSQL数据模型不过错过的全面资料. NoSQL的一些非功能性的特性,比如扩展性、性能以及一致性的讨论,目前已经有很多.

NoSQL聚合数据模型 - 大CC

- - 博客园_首页
聚合数据模型的特点就是把经常访问的数据放在一起(聚合在一块);. 这样带来的好处很明显,对于某个查询请求,能够在与数据库一次交互中将所有数据都取出来;. 当然,以这种方式存储不可避免的会有重复,重复是为了更少的交互;. 聚合结构对某些交互有利,却阻碍另一些交互;. 比如:以学生学号聚合学生信息(含学生姓名、班级、年龄、等信息,甚至英语学科成绩),通过学号查询时,能够在一次交互中查询出该学生的所有信息,但如果想通过学生姓名来查询,就很困难;.

CAP 理论

- - 忘我的追寻
CAP理论被很多人拿来作为分布式系统设计的金律,然而感觉大家对CAP这三个属性的认识却存在不少误区. 从CAP的证明中可以看出来,这个理论的成立是需要很明确的对C、A、P三个概念进行界定的前提下的. 在本文中笔者希望可以对论文和一些参考资料进行总结并附带一些思考. CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的.

Oracle MySQL Or NoSQL续

- - Sky.Jian 朝阳的天空
接前面一篇,这里再将之前在“中国系统架构师大会”5周年的时候发布的纪念册“IT架构实录”上的一篇文章发出来,也算是前面博文中PPT的一个文字版解读吧. Oracle,MySQL 还是 NoSQL. 随着阿里系的“去IOE”运动在社区的宣传声越来越大,国内正在掀起一股“去xxx”的技术潮. 不仅仅是互联网企业,包括运营商以及金融机构都已经开始加入到这个潮流之中.

[译]如何“打败”CAP定理

- hikerlive - Fang Jian&#39;s Personal Blog
昨天看到了Nathan Marz这篇《How to beat the CAP theorem》觉得写得很有想法,所以决定把这篇文章翻译成中文,希望能够被更多的人看到,翻译可能不是很准确,如有错误之处欢迎指出. CAP定理指出一个数据库不可能同时满足:一致性(Consistency)、可用性(Availability)和分区容错性(Partition-Tolerance).

令人迷惑的CAP与ACID用语

- - 数据库 - ITeye博客
令人迷惑的CAP与ACID用语. CAP和ACID共享相同的词汇表:原子性(Atomic)、一致性(Consistent),诸如此类. 但内有玄机:这些词语虽一样,但它们的意思是完全不同的东西. CAP来自分布式系统理论,而ACID属于数据库系统. 分布式数据库既使用CAP词汇,也使用ACID词汇,这显然造成许多混淆.