NoSQL数据库简介——《大数据技术原理与应用》课程学习总结
NoSql 数据库
- NoSql 简介
- NoSql 兴起的原因
- 关系数据库无法满足 Web 2.0 的需求
- 关系数据库的关键特性在 Web 2.0 时代优势不再明显
- Nosql 与关系数据库的比较
- NoSql 的四大类型
- 键值数据库
- 列族数据库
- 文档数据库
- 图数据库
- NoSQL 的三大基石
- CAP
- BASE
- 最终一致性
- 从 NoSQL 到 NewSQL 数据库
NoSql 简介
NoSql 是一种不同于关系数据库的数据库管理系统设计方式，是对非关系型数据库的统称。它所采用的数据模型并非关系数据库的关系模型，而是类似键/值、列族、文档等非关系模型。
当应用场合需要简单的数据模型、灵活性的 IT 系统、较高的数据库性能和较低的数据库一致性时，NoSql 数据库是一个很好的选择。NoSql 数据库通常有以下3个特点：
- 灵活的可扩展性。传统的关系型数据库由于自身设计机理的原因，通常很难实现“横向扩展”，在面对数据库负载大规模增加时，往往只能选择开销很大的“纵向扩展”。但是，对于 NoSql 数据库，“横向扩展”仅需要非常廉价的标准化刀片服务器，具有很高的性价比。NoSql 数据库在设计之初就是为了满足“横向扩展”的需求，因此天生具备良好的水平扩展能力。
- 灵活的数据模型。NoSql 数据库天生就旨在摆脱关系数据库的各种束缚条件，摒弃了流行多年的关系数据模型，转而采用键/值、列族等非关系模型，允许在一个数据元素中存储不同类型的数据。
- 与云计算紧密融合。云计算具有很好的水平扩展能力，可以根据资源使用情况进行自由伸缩，各种资源可以动态加入或退出，NoSql 数据库可以凭借自身良好的横向扩展能力，充分自由利用云计算基础设施，很好地融入到云计算环境中，构建基于 NoSql 的云数据库服务。
NoSql 兴起的原因
关系数据库无法满足 Web 2.0 的需求
- 无法满足海量数据的管理需求。
- 无法满足数据高并发的需求。Web 2.0 时代，各种用户都在不断地发生更新，购物记录、搜索记录、微博粉丝等信息都需要实时更新，动态页面静态化技术基本没有用武之地，所有信息都需要动态实时生成，这就会导致高并发的数据库访问，每秒产生大量的读写请求，对于很多关系数据库而言，难以承受其重。
- 无法满足高可扩展性和高可用性的需求。
关系数据库的关键特性在 Web 2.0 时代优势不再明显
- Web 2.0 网站系统通常不要求严格的数据库事务。
- Web 2.0 并不要求严格的读写实时性。
- Web 2.0 通常不包含大量复杂的 SQL 查询。
Nosql 与关系数据库的比较
| 比较标准 | 关系数据库 | NoSql | 备注 |
|---|---|---|---|
| 数据库原理 | 完全支持 | 部分支持 | 关系数据库有关系代数理论作为基础，但是 NoSql 没有统一的理论基础 |
| 数据规模 | 大 | 超大 | 关系数据库很难实现横向扩展，NoSql 可以很容易通过添加更多设备支持更大规模的数据 |
| 数据库模型 | 固定 | 灵活 | 关系数据库需要定义数据库模式，严格遵守数据定义和相关约束条件；NoSql 不存在数据库模式，可以灵活定义并存储各种不同类型的数据 |
| 查询效率 | 快 | 实现高效的简单查询，但是复杂查询的效率不尽人意 | 关系数据库借助索引机制可以实现快速查询；很多 NoSql 数据库没有面向复杂查询的索引，及时使用 MapReduce 加速查询，性能方面仍不如关系数据库 |
| 一致性 | 强一致性 | 弱一致性 | 关系数据库严格遵守事务 ACID 模型，保证事务的强一致性；很多 NoSql 数据库放松了对 ACID 四性的要求 |
| 数据完整性 | 容易实现 | 很难实现 | 任何一个数据库都可以实现数据完整性（包括实体完整性、参照完整性和自定义完整性），但是 NoSql 数据库无法实现 |
| 扩展性 | 一般 | 好 | 关系数据库很难实现横向扩展，纵向扩展的控制键也比较有限；NoSql 很容易实现横向扩展 |
| 可用性 | 好 | 很好 | \ |
| 标准化 | 是 | 否 | 关系数据库已经标准化（SQL）；NoSql 还没有行业标准 |
| 技术支持 | 高 | 低 | 关系数据库已经非常成熟，很多厂商可以提供很好的技术支持；NoSql 在技术支持方面还在起步阶段 |
| 可维护性 | 复杂 | 复杂 | 关系数据库需要专门的数据库管理员维护；NoSql 数据库虽然没有关系数据库复杂，但也难以维护 |
通过上述比较，可以看出两者都有各自的目标用户群体和市场空间，不存在一个完全取代另一个的问题。
NoSql 的四大类型
NoSql 数据库虽然数量众多，但是归结起来，典型的 NoSql 数据库通常包括简直数据库、列族数据库、文档数据库和图数数据库。
键值数据库
键值数据库会使用一个哈希表，这个表中有一个特定的 Key 和一个指针指向特定的 Value。key 可以用来定位 value，即存储和检索具体的 Value。Value 对数据库而言是透明不可见的，不能对 Value 进行索引和查询，只能通过 Key 进行查询。Value 可以用来存储任意类型的数据。
键值数据库可以进一步划分为 内存键值数据库 和 持久化键值数据库 。前者吧数据保存在内存中，后者吧数据保存在磁盘。
| 项目 | 描述 |
|---|---|
| 相关产品 | Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached |
| 数据模型 | 键/值对 |
| 典型应用 | 内容缓存，如会话、配置文件、参数、购物车等 |
| 优点 | 扩展性好、灵活性好、大量写操作时性能高 |
| 缺点 | 无法存储结构化信息、条件查询效率较低 |
| 使用者 | GitHub（Riak）、Twitter（Redis 和 Memcached）、StackOverFlow（Redis） |
列族数据库
列族数据库一般采用列族数据模型，数据库由多个行构成，每行数据包含多个列族，不同的行可以有不同的列族，属于同一列族的数据会被存放在一起。每行数据通过行键进行定位。
| 项目 | 描述 |
|---|---|
| 相关产品 | BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PUNTS |
| 数据模型 | 列族 |
| 典型应用 | 分布式数据库存储于管理 |
| 优点 | 查找速度快、可扩展行强、容易进行分布式扩展、复杂性低 |
| 缺点 | 功能较少，大都不支持强事务一致性 |
| 使用者 | NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、Yaho！（HBase） |
文档数据库
文档数据库中，文档是数据库的最小单位。虽然每一种文档数据库的部署都有所不同，但是大都假定文档以某种标准化格式封装并对数据进行加密，同时用多种格式进行解码。文芳数据库通过键来定位一个文档，可以看成键值数据库的衍生品，但是前者要比后者的查询效率高。
文档数据库既可以根据键（Key）来构建索引，也可以基于文档内容来构建索引（这是文档数据库不同于键值数据库的地方）。
| 项目 | 描述 |
|---|---|
| 相关产品 | CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit |
| 数据模型 | 版本化的文档 |
| 典型应用 | 存储、检索并管理面向文档的数据或者类似的半结构化数据 |
| 优点 | 性能好、灵活性高、复杂性低、数据结构灵活 |
| 缺点 | 缺乏统一的查询语法 |
| 使用者 | 百度云数据库（MongoDB）、SAP（MongoDB）、Codecademy（MongoDB）、NBC News（RavenDB） |
图数据库
图数据库以图论为基础，一个图是一个数学概念，用来表示一个对象集合，包括顶点以及连接顶点的边。图数据库使用图作为数据模型来存储数据，可以高效地存储不同顶点之间的关系。
图数据库专门用于处理具有高度相互关联关系的数据，可以高效地处理实体之间的关系，比较适合于社交网络、模式识别、依赖分析、推荐系统以及罗静寸照等问题。
| 项目 | 描述 |
|---|---|
| 相关产品 | Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB |
| 数据模型 | 图结构 |
| 典型应用 | 应用于大量复杂、互连接、低结构化的图数据结构场合 |
| 优点 | 灵活性高、支持复杂的图算法、可用于构建复杂的关系图谱 |
| 缺点 | 复杂性高、只能支持一定的数据规模 |
| 使用者 | Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J） |
NoSQL 的三大基石
CAP
所谓 CAP 指的是：
- C（Consistency）：一致性。它是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的。
- A（Availability）：可用性。它是指快速获取数据，可以在确定的数据内返回操作结果。
- P（Tolerance of Network Partition）：分区容忍性。它是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行。
从上图可以看出，一个分布式系统不可能同时满足三个需求，最多只能同时满足其中 2 个。
在处理 CAP 的问题时，可以有以下几个明显的选择：
- CA。强调一致性和可用性，放弃分区容忍性，最简单的做法是吧所有与事务有关的内容都放到同一台机器上。这种做法会严重过影响系统的可扩展性。
- CP。强调一致性和分区容忍性，放弃可用性。当出现网络分区的情况时，手影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。
- AP。强调可用性和分区容忍性，放弃一致性。允许系统返回不一致的数据。在采用 AP 设计时，也可以不完全放弃一致性，转而采用最终一致性。
BASE
首先先来回顾一下关系数据库的 ACID：
- A（Atomicity）：原子性
- C(Consistency)：一致性
- I(Isolation)：隔离性
- D(Durability)：持久性
关系数据库系统设计了复杂的事务管理机制来保证事务在执行过程中严格满足 ACID 四性要求。但是，NoSql 数据库通常应用于 Web 2.0 网站等场景中，对数据一致性的要求并不是很高，强调系统的高可用性，适当牺牲了一致性或分区容忍性。BASE 的基本思想就是在这个基础上发展起来的，它牺牲了高一致性，从而获得可用性或可靠性。
BASE 的基本含义是 基本可用、软状态 和 最终一致性。
1. 基本可用
基本可用是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。
2. 软状态
“软状态”是与“硬状态”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。
3. 最终一致性
一致性的类型包括强一致性和弱一致性，二者的主要区别在于宝并发的数据访问操作下，后续操作是否能够获取最新的数据。
对于强一致性而言，当执行完一次更新操作后，后续的其他读写操作就可以保证读到更新后的最新数据；
反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。
最终一致性时弱一致性的一种特例，允许后续访问操作可以暂时读不到更新后的数据，但是经过一段时间后，必须最终读到更细后的数据。
最终一致性
讨论一致性，需要从客户端和服务端两个角度来考虑。从服务端来看，一致性是指更新如果复制分布到整个系统，以保证数据最终一致。从客户端来看，一致性主要指的是高并发的数据访问操作下，后续操作是否能够获取到最新的数据。
最终一致性，只要经过一段时间后能够访问到更新后的数据即可。也就是说，如果一个操作 OP 往分布式存储系统中写入一个值，遵循最终一致性的系统可以保证：如果后续访问发生之前没有其他写操作去更新这个值的话，最终所有后续的访问都可以读取到操作 OP 写入的最新值。
从 OP 操作完成到后续访问可以最终读取到 OP 写入的最新值，这之间的时间间隔称为“不一致性窗口”
从 NoSQL 到 NewSQL 数据库
NoSQL 数据库提供了良好的扩展性和灵活性，很好地弥补了传统关系数据库的缺陷，但是它也存在自己的不足之处，不具备高度结构化查询等特性，查询效率尤其是复杂查询方面不如关系数据库，而且不支持事务 ACID 四性。
在这个背景下，NewSQL 数据库开始逐渐升温。NewSQL 是对各种新的可扩展、高性能数据库的简称，这列数据库不仅具有 NoSQL 对海量数据的存储管理能力，还保持了传统数据库支持 ACID 和 SQL 等特性。不同的 NewSQL 数据库的内部结构差异很大，但是它们有两个显著的共同特点：都支持关系数据模型；都使用 SQL 作为其主要的接口。