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已经标准化（SQL）；NoSQL缺乏统一查询语言
技术支持	高	低	NoSQL在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力技术支持
可维护性	复杂	复杂	RDBMS需要专门的数据库管理员(DBA)维护，NoSQL数据库虽然没有DBMS复杂，也难以维护

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

NoSQL的四大类型

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

键值数据库

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

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

列族数据库

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

好处：

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

相关产品	BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
数据类型	列族
典型应用	分布式数据存储与管理；数据在地理上分布于多个数据中心的应用程序；可以容忍副本中存在短期不一致情况的应用程序；拥有动态字段的应用程序；拥有潜在大量数据的应用程序，大到几百TB的数据
优点	查找速度快、可扩展性强、容易进行分布式扩展、复杂性低
缺点	功能较少、大都不支持强事务一致性
不适用情形	需要ACID事务支持的情形，Cassandra等产品就不适用
使用者	Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、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 News（RavenDB）

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

图形数据库

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

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

不同类型数据库比较分析

Redis

• Redis（Remote Dictionary Server），即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
• Redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string（字符串）、list（链表）、set（集合）、zset（sorted 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是指：

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

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

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

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

BASE

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