undefined

三、高性能NoSQL

关系型数据库存在的缺点

关系型数据库存储的是行记录，无法存储数据结构（例有序数组）
关系型数据库的 schema 扩展很不方便，表结构 schema 是强约束，操作不存在的列会保错；业务变化时扩充列比较麻烦，需要执行DDL（data definition language，如 CREATE、ALTER、DROP 等）语句修改，而且修改时间会长时间锁表（MySQL 可能锁表 1 个小时）
关系型数据库在大数据场景下 I/O 高。因为即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备读入内存
关系型数据库的全文搜索功能比较弱，使用 like 进行整表扫描，性能非常低。

NoSQL 本质上是牺牲 ACID 中某个或者某几个特性。因此应该将 NoSQL 作为 SQL 的一个有力补充。Not Only SQL

常见的 NoSQL 的方案：

K-V 存储，解决关系型数据库无法存储数据结构的问题。Redis
文档数据库，解决关系型数据库强 schema 约束的问题。 MongoDB
列式数据库，解决关系型数据库大数据场景下的 I/O 问题。HBase
全文搜索引擎，解决关系型数据库全文搜索性能问题。Elasticsearch

1. K-V 存储

Redis 的缺点：事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）

2. 文档数据库

最大特点是 no-schema，可以存储和读取任意的数据，绝大部分文档数据库存储的数据格式是 JSON（或者 BJSON），因为 JSON 数据都是自描述的，无须在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致像 SQL 那样的语法错误

优点：

新增字段简单。无须像关系型数据库一样要先执行 DDL 语言修改表结构，程序代码直接读写即可
历史数据不会出错，对于历史数据，即使没有新增字段，也不会导致错误，只会返回空值
可以容易存储复杂数据。比如用户的学历是入学时间、毕业时间、学校名称、专业等，地址是省市区等。如果用关系型数据库需要多张表存储，但是文档数据库，一个 JSON 即可全部描述

缺点：不支持事务；无法实现关系型数据库的 join 操作

3. 列式数据库

关系型数据库按照行来存储数据，有如下优势：

业务同时读取同一行的多个列数据时效率高，因为这些列都是按照行存储的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中
能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性；否则如果采用列存储，可能会出现某次写操作，有的列成功，有的列失败了，导致数据不一致

场景：

如果只需要某列数据做统计，行式数据库会把所有行数据都读取到内存，这时明显的浪费。而如果采用列式存储，只需要读取一列，比较节省 I/O
列式存储具备更高的存储压缩比，能够节省更多的存储空间。普通的行式数据库一般压缩率在 3:1 到 5:1 左右。而列式数据库的压缩率一般在 8:1 到 30:1 左右
一般列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要针对部分列单列进行操作，且数据写入后就无须再更新删除。

缺点：

如果频繁更新多个列，因为列式存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作。而行式存储时同一行多个列都存储在连续空间，一次磁盘写操作就可以完成，列式存储的随机写效率要远远低于行式存储的写效率。
列式存储高压缩率在更新场景下也会成为劣势，因为更新需要将存储数据解压后更新，然后在压缩，最后写入磁盘

4. 全文搜索引擎

关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，因为：

全文搜索的条件可以随意排列组成，如果通过索引来满足，则索引的数量会非常多
全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低

全文搜索基本原理：使用了倒排索引，建立单词到文档的索引。（正排索引是建立文档到单词的索引）
正排索引适用于根据文档名称来查询文档内容。倒排索引适用于根据关键词来查询文档内容。

Elastcisearch 是分布式的文档存储方式。它能存储和检索复杂的数据结构——序列化成为 JSON 文档——以实时的方式。在 Elasticsearch 中，每个字段的所有数据都是默认被索引的。即每个字段都有为了快速检索设置的专用倒排索引。而且，不像其他多数的数据库，它能在相同的查询中使用所有倒排索引，并以惊人的速度返回结果。