小谈NoSQL

提纲

NoSQL简介
NoSQL兴起的原因
NoSQL与关系数据库的比较
NoSQL的四大类型
NoSQL的三大基石
从NoSQL到NewSQL数据库
文档数据库MongoDB

NoSQL简介

从最初表示的“反SQL”运动，用新型的非关系型数据库取代关系型数据库，发展为现在表示关系和非关系型数据库各有优缺点彼此都无法互相取代，即“Not only SQL”。

通常，NoSQL数据库具有以下特点：

灵活的可扩展性
灵活的数据模型
与云计算紧密融合

NoSQL兴起的原因

关系数据库已经无法满足Web2.0的需求。主要表现在：
- 无法满足海量数据的管理需求
- 无法满足数据高并发的需求
- 无法满足高可拓展性和高可用性的需求
MySQL集群存在的问题：
- 复杂性：部署、管理、配置很复杂
- 数据库复制：MySQL主备之间采用复制方式，只能是异步复制，当主库压力较大时可能产生较大延迟，主备切换会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便。
- 扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错。
- 动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到自动化。
“One size fits all”模式很难适用于截然不同的业务场景。比如Hadoop针对数据分析，强调高吞吐，而MongoDB、Redis等是针对在线业务，强调低延时，两者都抛弃了关系模型。
关系数据库引以为傲的关键特性——完善的事务机制和高效的查询机制到了Web2.0时代却成了鸡肋，主要表现在以下几个方面：
- Web2.0网站系统通常不要求严格的数据库事务
- Web2.0并不要求严格的读写实时性
- Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间更换更好的查询性能）

NoSQL与关系数据库的比较

关系数据库
- 优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持
- 劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等
- 应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性。
NoSQL数据库
- 优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等
- 劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等
- 应用场景：互联网企业、传统企业的非关键业务（比如数据分析）

当然也可以采用混合架构

NoSQL的四大类型

文档数据库：MarkLogic，Couchbase，mongoDB
- 数据模型：键/值
  
  值（value）是版本化的文档
- 典型应用：存储、索引并管理面向文档的数据或者类似的半结构化数据
  
  比如，用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
- 优点：性能好（高并发），灵活性高，复杂性低，数据结构灵活
  
  提供嵌入式文档功能，将经常查询的数据存储在同一个文档中
  
  既可以根据键来构建索引，也可以根据内容构建索引
- 缺点：缺乏统一的查询语法
- 不适用情形：在不同的文档上添加事务。文档数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案
图数据库：Neo4j，InfiniteGraph
- 数据模型：图结构
- 典型应用：专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
- 优点：灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱
- 缺点：复杂性高，只能支持一定的数据规模
键值数据库：redis、amazonDynameDB、riak、aerospike
- 数据模型：键/值对
  
  键是一个字符串对象
  
  值可以是任意类型的数据，比如整型、字符型、数组、列表、集合等
- 典型应用：涉及频繁读写、拥有简单数据模型的应用
  
  内容缓存，比如会话、配置文件、参数、购物车等
  
  存储配置和用户数据信息的移动应用
- 优点：扩展性好，灵活性好，大量写操作时性能高
- 缺点：无法存储结构化信息，条件查询效率较低
- 不适用情形：不是通过键而是通过值来查：键值数据库根本没有通过值查询的途径
  
  需要存储数据之间的关系：在键值数据库中，不能通过两个或两个以上的键来关联数据
  
  需要事务的支持：在一些键值数据库中，产生故障时，不可以回滚
列族数据库：accumulo、Hypertable、cassandra、HBase、Amazon SimipleDB
- 数据模型：列族
- 典型应用：分布式数据存储与管理
  
  数据在地理上分布于多个数据中心的应用程序
  
  可以容忍副本中存在短期不一致情况的应用程序
  
  拥有动态字段的应用程序
  
  拥有潜在大量数据的应用程序，大到几百TB的数据
- 优点：查找速度快，可扩展性强，容易进行分布式扩展，复杂性低
- 缺点：功能较少，大都不支持强事务一致性
- 不适用情形：需要ACID事务支持的情形，Cassandra等产品就不适用

NoSQL三大基石

CAP

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

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

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

CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差
CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务
AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据

BASE

一个数据库事务具有ACID四性：

A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行
C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态
I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持

BASE的基本含义是

基本可用（Basically Availble）：基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
软状态（Soft-state）：“软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性
最终一致性（Eventual consistency）：一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。