NoSQL概述

NoSQL是对非关系数据库的统称，它所采用的是类似键值、列族、文档等非关系模型。NoSQL数据库没有固定的表结构，通常也不存在连接操作，也没有严格遵守ACID约束。因此与关系数据库相比，NoSQL具有灵活的水平可扩展性，可以支持海量数据存储。

NoSQL数据库具有以下3个特点：

灵活的可扩展性

传统的关系数据库由于自身设计的局限性，通常很难实现“横向扩展”。当数据库负载大规模增加时，往往需要升级硬件来实现“纵向扩展”。由于硬件制造工艺的限制，性能提升的速度已经赶不上数据库系统负载的增加速度，且高性能配置价格不菲，因此，纵向扩展越来越不现实。相反“横向扩展”仅需非常普通且廉价的标准化刀片服务器，具有较高的性价比，提供了理论上近乎无限的扩展空间。NoSQL天生具有“横向扩展”能力。

灵活的数据模型

关系数据库模型是关系数据库的基石，它以完备的关系代数理论为基础，具有规范的定义，遵守各种严格的约束条件，无法满足各种新兴的业务需求。NoSQL采用键值、列族等非关系数据模型，允许在一个数据元素里存储不同类型的数据。

与云计算紧密融合

NoSQL数据库可凭借自身良好的横向扩展能力，充分利用云计算基础设施，很好地将数据库融入云计算环境中，构建基于NoSQL的云数据库服务。

NoSQL兴起的原因

关系数据库无法满足Web2.0的需求

无法满足海量数据的管理需求
无法满足数据高并发的需求
无法满足高扩展性和高可用性需求

关系数据库的主键特性在Web2.0时代成为“鸡肋”

Web2.0网站系统通常不要求严格的数据库事务
Web2.0并不要求严格的读写实时性
Web2.0通常不包含大量复杂的SQL查询

NoSQL与关系数据库的比较

对比指标	NoSQL	关系数据库	备注
数据库原理	部分支持	完全支持	关系数据库有关系代数理论作为基础 NoSQL没有统一的理论基础
数据规模	超大	大	关系数据库很难实现横向扩展，纵向扩展的空间也很有限，性能会随着数据规模的增大而降低 NoSQL可以很容易的通过添加更多设备来支持更大规模的数据
数据库模式	灵活	固定	关系数据库需要定义数据库模式，严格遵守数据定义和相关约束条件 NoSQL不存在数据库模式，可以自由、灵活地定义并存储各种不同类型的数据
查询效率	可以实现高效的简单查询，但是不具备高度结构化查询等特性，复杂查询的性能不尽如人意	快	关系数据库借助于索引机制可以实现快速查询（包括记录查询和范围查询）很多NoSQL数据库没有面向复杂查询的索引，虽然NoSQL可以使用MapReduce来加速查询，但是复杂查询方面的性能仍然不如关系数据库
一致性	弱一致性	强一致性	关系数据库严格遵守事务ACID模型，可以保证事务强一致性。很多NoSQL数据库放松了对事务ACID四性的要求，而是遵守BASE模型，只保证最终一致性
数据完整性	很难实现	容易实现	任何一个关系数据库都可以很容易实现数据完整性，如通过主键或者非空约束来实现实体完整性，通过主键、外键来实现参照完整性，通过约束或者触发器来实现用户自定义完整性，但是在NoSQL数据库无法实现
扩展性	好	一般	关系数据库很难实现横向扩展，纵向扩展的空间也很有限 NoSQL在设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备来实现扩展
可用性	很好	好	关系数据库在任何时候都以保证数据一致性为优先目标，其次才是优化系统性能。随着数据规模的增大，关系数据库为了保证严格的一致性，只能提供相对较弱的可用性。大多数NoSQL都能提供较高的可用性
标准化	否	是	关系数据库已经标准化（SQL） NoSQL还没有行业标准，不同的NoSQL数据库有不同的查询语言，很难规范应用程序接口
技术支持	低	高	关系数据库经过几十年的发展，已经的非常成熟，Oracle等大型厂商都可以提供很好的技术支持 NoSQL在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力的技术支持
可维护性	复杂	复杂	关系数据库需要专门的数据库管理员（DataBase Administrator,DBA）维护 NoSQL数据库虽然没有关系数据库复杂，但难以维护

NoSQL的四大类型

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

项目	键值数据库	列族数据库	文档数据库	图数据库
相关产品	Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached	BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PUNTS	CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Persevere、Jackrabbit	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
数据模型	键值对	列族	版本化的文档	图结构
典型应用	内容缓存，如会话、配置文件、参数、购物车等	分布式数据存储与管理	存储、索引并管理面向文档的数据或者类似半结构化数据	应用于大量复杂、互连接、低结构化的图结构场合，如社交网络、推荐系统等
优点	扩展性好、灵活性好、大量写操作时性能高	查找速度快、可扩展性强、容易进行分布式扩展、复杂性底	性能好、灵活性高、复杂性底、数据结构灵活	灵活性高、支持复杂的图算法、可用于构建复杂的关系图谱
缺点	无法存储结构化信息、条件查询效率较低	功能较少，大都不支持强事务一致性	缺乏统一的查询语法	复杂性高、只能支持一定的数据规模
使用者	百度云数据库(Redis)、GitHub(Riak)、BestBuy(Riak)、StackOverFlow(Redis)、Instagram(Redis)	Ebay(Cassandra)、Instagram(Cassandra)	百度云数据库(MongoDB)、SAP(MongoDB)、Codecademy(MongoDB)、Foursquare(MongoDB)	Adobe(Neo4J)、Cisco(Neo4J)

键值数据库

键值数据库（Key-Value Database）会使用一个哈希表，包含Key和Value：

Key用来定位Value，即存储和检索具体的Value。

Value

一个指针指向的特定值

Value对数据库而言是透明不可见的，不能对Value进行索引和查询，只能通过Key进行查询。

Value可以用来存储任意类型的数据。

键值数据库分类：

内存键值数据库

内存键值数据库把数据保存在内存中，如Memcached和Redis；

持久化（Persistent）键值数据库

持久化键值数据库把数据保存在磁盘，如BerkeleyDB、Voldmort和Riak。

键值数据库的缺点：

条件查询就是键值数据库的弱项
应该尽量避免多表关联查询，可采用双向冗余存储关系来代替表关联，把操作分解成单表操作。
发生故障时不支持回滚操作，无法支持事务

列族数据库

采用列族数据模型
数据库由多个行构成
每行数据包含多个列族，不同的行可以具有不同数量的列族
同一列族的数据会被存放在一起
行通过行键来定位

文档数据库

文档是数据库的最小单位
通过键来定位文档
即可以根据链来构建索引，也可以基于文档内容来构建索引。

图数据库

图数据库以图论为基础
使用图作为数据模型来存储数据
专门用户处理具有高度相互关联的数据，可高效地处理实体之间的关系。
适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等

NoSQL的三大基石

NoSQL的三大基石包括CAP、BASE和最终一致性。

CAP

C（Consistency）：一致性。它是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的。

A（Availability）：可用性。它是指快速获取数据，且在确定的时间内返回操作结果。

P（Tolerance of Network Partition）：分区容忍性。它是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行。

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

CA：也就是强调一致性C和可用性A，放弃分区容忍性P。最简单的做法是把所有与事务相关的内容都放到同一台机器上。这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。传统的关系数据库MySQL、SQL Server和PostgreSQL都采用了这种设计原则，因此扩展性都比较差。

CP：也就是强调一致性C和分区容忍性P，放弃可用性A。当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。在数据一致性要求比较高的场合(如：ZooKeeper、HBase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。Neo4J、BigTable和HBase等NoSQL数据库都采用了CP设计原则。

AP：也就是强调可用性A和分区容忍性P，放弃一致性C。允许系统返回不一致的数据。这对于许多WEB2.0网站而言是可行的。当然，在采用AP设计时，也可以不完全放弃一致性，转而采用最终一致性。DynamoDB、Riak、CouchDB、Cassandra等NoSQL数据库就采用了AP设计原则。

BASE

（1）ACID

A（Atomicity）：原子性。

它是指事务必须是原子工作单元，对于其数据修改，要么全部执行，要么全都不执行。

C（Consistency）：一致性。

它是指事务在完成时，必须使所有的数据都保持一致状态。

I（Isolation）：隔离性。

它是指由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。

D（Durability）：持久性。

它是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致使的系统故障也将一直保持。

（2）BASE

BA（Basically Availble）：基本可用。

它是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。

S（Soft-state）：软状态。

它是与硬状态（Hard-state）相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。

E（Eventual consistency）：最终一致性。

一致性的类型包括强一致性和弱一致性，二者的主要区别在于在高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。最终一致性是弱一致性的特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，用户必须读到更新后的数据。

最终一致性

从服务端来看，一致性是指更新如何复制分布到整个系统，以保证数据最终一致。从客户端来看，一致性主要指的是在高并发的数据访问操作下，后续操作是否能够获取最新的数据。

如果一个操作OP往分布式存储系统中写入一个值，遵循最终一致性的系统可以保证，如果后续访问发生之前没有其他写操作去更新这个值，那么，最终所有后续的访问都可以读取操作OP写入的最新值。从OP操作完成到后续访问可以最终读取OP写入的最新值，这之间的时间间隔称为“不一致性窗口”。

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

因果一致性

如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得进程A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的一致性规则。

“读已之所写”一致性：可以视为因果一致性的特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值。
会话一致性：它把访问存储系统的进程放到会话的上下文中，只要会话还存在，系统就保证“读已之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。
单调读一致性

如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。