NoSQL数据库

NoSQL简介

“Not Only SQL”泛指非关系型的数据库区别于关系数据库它们不能保证关系数据的ACID特性。
NoSQL适用关系型数据库的时候就使用关系型数据库不适用的时候也没有必要非使用关系型数据库不可可以考虑使用更加合适的数据存储。

NoSQL不是一个工具而是由一些具有互补性和竞争性的工具组成的一个概念是一个生态圈。
NoSQL 系统舍弃了许多传统关系型数据库的方便之处而把一些通常由关系型数据库本身来完成的任务交给了应用层来完成。
NoSQL主要分为临时性键值存储memcached、Redis、永久性键值存储ROMA、Redis、面向文档的数据库MongoDB、CouchDB、面向列的数据库Cassandra、HBase每种NoSQL都有其特有的使用场景及优点。

NoSQL的两个核心思想

• Google的BigTable提出的数据模型将各列数据进行排序存储。
• Amazon的Dynamo使用的是另外一种分布式模型其数据分片模型有比较强的容灾性因此它实现的是相对松散的弱一致性最终一致性。

现实中这些思想都是混搭使用的。

NoSQL兴起的原因

• Web1.0
  — 以编辑为特征网站提供给用户的内容是网站编辑进行编辑处理后提供的用户阅读网站提供的内容。
  — 过程是网站到用户的单向行为。
  — web1.0时代的代表站点为新浪搜狐网易三大门户。
• Web2.0
  — 更注重用户的交互作用用户既是网站内容的消费者浏览者也是网站内容的制造者。
  — 以网站与用户之间的互动网站内容基于用户提供网站的诸多功能也由用户参与建设实现了网站与用户双向的交流与参与用户在web2.0网站系统内拥有自己的数据。并完全基于WEB所有功能都能通过浏览器完成。
  — web2.0时代的代表站点为Facebook、Twitter。

关系数据库已经无法满足Web2.0的需求主要表现在以下几个方面

• 无法满足海量数据的管理需求
• 无法满足数据高并发的需求
• 无法满足可扩展性和高可用性的需求
  关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是关系数据库引以为傲的两个关键特性到了Web2.0时代却成了鸡肋主要表现在以下几个方面
• Web2.0网站系统通常不要求严格的数据库事务。
• Web2.0并不要求严格的读写实时性。
• Web2.0通常不包含大量复杂的SQL查询去结构化存储空间换取更好的查询性能。

NoSQL与关系数据库的对比

比较标准	RDBMS	NoSQL	备注
数据库原理	完全支持	部分支持	NoSQL没有统一的理论基础
数据规模	大	超大	RDBMS的性能会随着数据规模的增大而降低NoSQL容易通过添加更多设备来支持更大规模的数据
数据库模式	固定	灵活	RDBMS需要定义数据库模式严格遵守数据定义和相关约束条件NoSQL不存在数据库模式可以自由灵活定义并存储各种不同类型的数据
查询效率	快	可以实现高效的简单查询复杂查询的性能不尽人意	RDBMS借助于索引机制可以实现快速查询很多NoSQL数据库没有面向复杂查询的索引
一致性	强一致性	弱一致性	RDBMS严格遵守事务ACID模型NoSQL数据库放松了对事务ACID四性的要求而是遵守BASE模型只能保证最终一致性
数据完整性	容易实现	很难实现	NoSQL数据库无法实现数据完整性
扩展性	一般	好	NoSQL很容易通过添加廉价设备实现扩展
可用性	好	很好	RDBMS为了保证严格的一致性只能提供相对较弱的可用性大多数NoSQL都能提供较高的可用性
标准化	是	否	RDBMS已经标准化SQLNoSQL缺乏统一查询语言
技术支持	高	低	NoSQL在技术支持方面仍然处于起步阶段还不成熟缺乏有力技术支持
可维护性	复杂	复杂	RDBMS需要专门的数据库管理员(DBA)维护NoSQL数据库虽然没有DBMS复杂也难以维护

注关系数据库和NoSQL数据库各有优缺点彼此无法取代

NoSQL的四大类型

NoSQL数据库虽然数量众多但是归结起来典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库。

键值数据库

• 这一类数据库主要会使用到一个散列表这个表中有一个特定的键和一个指针指向特定的数据。
• 键值模型对于IT系统来说其优势在于简单、易部署。
• 键值数据库可以按照键对数据进行定位还可以通过对键进行排序和分区以实现更快速的数据定位。
  
  注键值型系统中复杂的联合操作以及满足多个条件的取数据操作就不那么容易了需要我们换一种思维来建立和使用键名。如果一个程序员既想通过员工号查到员工信息又想通过部门号查到员工信息那么他必须建立两种类型的键值对。

相关产品	Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
数据类型	键值对键是一个字符串对象值可以是任意类型的数据
典型应用	涉及频繁读写、拥有简单数据模型的应用内容缓存存储配置和用户数据信息的移动应用
优点	扩展性好灵活性好大量写操作时性能高
缺点	无法存储结构化信息条件查询效率较低
不适用情形	不是通过键而是通过值来查需要存储数据之间的关系需要事务的支持
使用者	百度云数据库Redis、GithubRiak、TwitterRedis和Memcached、YoutubeMemcached

列族数据库

• 列族数据库通常用来应对分布式存储的海量数据。
• 键仍然存在但是它们的特点是指向了多个列如图所示此列族数据库表中由两行组成每一行都有关键字Row Key每一行由多个列族组成即Column-Family-1和Column-Family-2而每个列族由多个列组成。
  

好处

• 查询时只有指定的列会被读取不会读取所有列
• 存储上节约空间Null值不会被存储一列中有时候会有很多重复数据这类数据可压缩
• 列数据被组织到一起一次磁盘IO可以将一列数据一次性读取到内存中

相关产品	BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
数据类型	列族
典型应用	分布式数据存储与管理数据在地理上分布于多个数据中心的应用程序可以容忍副本中存在短期不一致情况的应用程序拥有动态字段的应用程序拥有潜在大量数据的应用程序大到几百TB的数据
优点	查找速度快、可扩展性强、容易进行分布式扩展、复杂性低
缺点	功能较少、大都不支持强事务一致性
不适用情形	需要ACID事务支持的情形Cassandra等产品就不适用
使用者	EbayCassandra、InstagramCassandra、NASACassandra、TwitterCassandra and HBase、FacebookHBase、Yahoo!HBase

文档数据库

• 该类型的数据模型是版本化的文档文档以特定的格式存储如JSON。
• 文档数据库可以看作键值数据库的升级版允许之间嵌套键值。
• 文档数据库比键值数据库的查询效率高因为文档数据库不仅可以根据键创建索引同时还可以根据文档内容创建索引。如MongoDB。
• “文档”其实就是一个数据记录这个记录能够对包含的数据类型和内容进行“自我介绍”XML文档、HTML文档和JSON文档就属于这一类。
  

相关产品	MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
数据类型	键/值值value是版本化的文档
典型应用	存储、索引并管理面向文档的数据或者类似的半结构化数据比如用于后台具有大量读写数据操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
优点	性能好高并发灵活性高复杂性低数据结构灵活提供嵌入式文档功能将经常查询的数据存储在同一个文档中既可以根据键来构建索引也可以根据内容构建索引
缺点	缺乏统一的查询语法
不适用情形	在不同的文档上添加事务。文档数据库并不支持文档间的事务
使用者	百度云数据库MongoDB、SAP MongoDB、Codecademy MongoDB、Foursquare MongoDB、NBC NewsRavenDB

什么是文档型NoSQL
文档型NoSQL指的是将半结构化数据存储为文档的一种NoSQL文档型NoSQL通常以JSON或者XML格式存储数据因此文档型NoSQL是没有Schema关系型数据必须有schema信息才能理解数据的含义由于没有Schema的特性我们可以随意地存储与读取数据因此文档型NoSql的出现是解决关系型数据库结构扩展不方便的问题的。

图形数据库

• 图形数据库来源于图论中的拓扑学以节点、边及节点之间的关系来存储复杂网络中的数据。
• 这种拓扑结构类似E-R图但在图形模式中关系和节点本身就是数据而在E-R图中关系描述的是一种结构。
  

相关产品	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
数据类型	图结构
典型应用	专门用于处理具有高度相互关联关系的数据比较适合与社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
优点	灵活性高支持复杂的图形算法可用于构建复杂的关系图谱
缺点	缺乏统一的查询语法
不适用情形	在不同的文档上添加事务。文档数据库并不支持文档间的事务
使用者	AdobeNeo4J、CiscoNeo4J、T-MobileNeo4J

不同类型数据库比较分析

Redis

• RedisRemote Dictionary Server即远程字典服务是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库并提供多种语言的API。
• Redis是一个key-value存储系统。和Memcached类似它支持存储的value类型相对更多包括string字符串、list链表、set集合、zsetsorted set–有序集合和hash哈希类型。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作而且这些操作都是原子性的。
• Redis会周期性地把更新的数据写入磁盘或者把修改操作写入追加的记录文件并且在此基础上实现master-slave主从同步。

MongoDB

• MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
• MongoDB是一个介于关系数据库和非关系数据库之间的产品它支持的数据结构非常松散是类似json的bson格式因此可以存储比较复杂的数据类型。
• Mongo最大的特点是它支持的查询语言非常强大其语法有点类似于面向对象的查询语言几乎可以实现类似关系数据库单表查询的绝大部分功能而且还支持对数据建立索引。

Cassandra

• Cassandra是一套开源分布式NoSQL数据库系统由于Cassandra良好的可扩展性被Digg、Twitter等知名Web 2.0网站所采纳成为了一种流行的分布式结构化数据存储方案。
• Cassandra是一个混合型的非关系的数据库类似于Google的BigTable。其主要功能比Dynamo 分布式的Key-Value存储系统更丰富但支持度却不如文档存储MongoDB介于关系数据库和非关系数据库之间的开源产品是非关系数据库当中功能最丰富最像关系数据库的。
• 支持的数据结构非常松散是类似json的bjson格式因此可以存储比较复杂的数据类型。

Neo4j

• Neo4j是一个高性能的NoSQL图形数据库它将结构化数据存储在网络上而不是表中。
• 它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎Neo4j也可以被看作是一个高性能的图引擎该引擎具有成熟数据库的所有特性。
• Neo4j提供了大规模可扩展性在一台机器上可以处理数十亿节点/关系/属性的图可以扩展到多台机器并行运行。

NoSQL三大基石

CAP

所谓的CAP是指

• CConsistency一致性是指任何一个操作总是能够读到之前完成的写操作的结果也就是在分布式环境中多点的数据是一致的或者说所有节点在同一时间具有相同的数据。
• AAvailability可用性是指快速获取数据可以在确定的时间内返回操作结果保证每个请求不管成功或者失败都有响应。
• PTolerance of Network Partition分区容忍性是指当出现网络分区的情况时即系统中的一部分节点无法和其他节点进行通信分离的系统也能够正常运行也就是说系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP理论告诉我们一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求最多只能同时满足其中两个。

当处理CAP的问题时可以有几个明显的选择

• CA强调一致性和可用性放弃分区容忍性最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然这种做法会严重影响系统的可扩展性。
• CP也就是强调一致性和分区容忍性放弃可用性当出现网络分区的情况时受影响的服务需要等待数据一致因此在等待期间就无法对外提供服务。
• AP也就是强调可用性和分区容忍性放弃一致性允许系统返回不一致的数据。
  不同产品在CAP理论下的不同设计原则
  

BASE

说到BASEBasically AvailableSoft-state、Eventual consistency不得不提到ACID。

ACID	BASE
原子性Atomicity	基本可用Basically Available
一致性Consistency	软状态/柔性事务Soft state
隔离性Isolation	最终一致性Eventual consistency
持久性Durable

BASE的基本含义是基本可用Basically Availble、软状态Soft-state和最终一致性Eventual consistency

• 基本可用是指一个分布式系统的一部分发生问题变得不可用时其他部分仍然可以正常使用也就是允许分区失败的情形出现
• 软状态“软状态soft-state”是与“硬状态hard-state”相对应的一种提法。数据库保存的数据是“硬状态”时可以保证数据一致性即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步具有一定的滞后性
• 最终一致性最终一致性只不过是弱一致性的一种特例允许后续的访问操作可以暂时读不到更新后的数据但是经过一段时间之后必须最终读到更新后的数据。最常见的实现最终一致性的系统是DNS域名系统。一个域名更新操作根据配置的形式被分发出去并结合有过期机制的缓存最终所有的客户端可以看到最新的值。

一致性的类型包括强一致性和弱一致性二者的主要区别在于高并发的数据访问操作下后续操作是否能够获取最新的数据。对于强一致性而言当执行完一次更新操作后后续的其他读操作就可以保证读到更新后的最新数据反之如果不能保证后续访问读到的都是更新后的最新数据那么就是弱一致性。

最终一致性

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同又可以区分为

• 因果一致性如果进程A通知进程B它已更新了一个数据项那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问仍然遵守一般的最终一致性规则。
• “读己之所写”一致性可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后它自己总是可以访问到更新过的值绝不会看到旧值。
• 单调读一致性如果进程已经看到过数据对象的某个值那么任何后续访问都不会返回在那个值之前的值。
• 会话一致性它把访问存储系统的进程放到会话session的上下文中只要会话还存在系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止就要建立新的会话而且系统保证不会延续到新的会话。
• 单调写一致性系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性否则就非常难以编程了。

如何实现各种类型的一致性
对于分布式数据系统

N	数据复制的份数
W	更新数据时需要保证写完成的节点数
R	读取数据的时候需要读取的节点数

如果W+R>N写的节点和读的节点重叠则是强一致性一般设定是RW = N + 1这是保证强一致性的最小设定。
如果W+R<=N则是弱一致性。
对于分布式系统为了保证高可用性一般设置N>=3。不同的N,W,R组合是在可用性和一致性之间取一个平衡以适应不同的应用场景。
如果N=WR=1任何一个写节点失效都会导致写失败因此可用性会降低但是由于数据分布的N个节点是同步写入的因此可以保证强一致性。
实例HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前写操作是不会返回成功的。也就是说它的WN而读操作只需要读到一个值即可也就是说它R1。