高性能NoSQL

一时失言乱红尘 2022-09-08 14:57 115阅读 0赞

**目录**

一、关系型数据库的特点

二、常见的NoSQL方案

1.K-V存储

2.文档数据库

3.列式数据库

4.全文搜索引擎

--------------------

# 一、关系型数据库的特点 #

关系型数据库由于其强大的 SQL 功能和 ACID 的属性，使得其在各式各样的系统中得到了广泛的应用。但世界上没有什么是"银弹"，关系型数据库同样也存在着一些问题，比如：

*  **关系数据库存储的是行记录，无法存储数据结构**

以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。

*  **关系数据库的 schema 扩展很不方便**

表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行 DDL语句修改，而且修改时可能会长时间锁表。

*  **关系数据库在大数据场景下 I/O 较高**

如果对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高，**因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。**

*  **关系数据库的全文搜索功能比较弱**

关系数据库的全文搜索只能使用 like 进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足业务要求。

互联网需求场景复杂多变，迭代迅猛，针对上面的问题，诞生了很多NoSQL解决方案，遵循架构设计的“合适”原则，选择合适自己业务需求的存储方案才是最明智的。

NoSQL在解决上述部分问题的同时，本质上是牺牲ACID中的某些特性，这里可以这样理解：NoSQL 是 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。

# 二、常见的NoSQL方案 #

主要分为4类：

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

## 1.K-V存储 ##

全称是Key-Value存储，其中Key是数据的标识，类似关系型数据库中的主键，Value是具体的数据。

Redis 是 K-V 存储的典型代表，它是一款开源（基于 BSD 许可）的高性能 K-V 缓存和存储系统。Redis 的 Value 是具体的数据结构，包括 **string、hash、list、set、sorted set、bitmap 和 hyperloglog**，所以常常被称为数据结构服务器。

有些操作在关系型数据库中会很麻烦，性能很低，比如redis中LPOP key 从队列的左边出队一个元素，但在关系型数据库中，需要多个操作：查询出第一条数据、删除第一条数据、更新从第二条开始的所有数据的位置编号等（位置编号和ID不一样）。

**Redis 的缺点主要体现在并不支持完整的 ACID 事务**，Redis 虽然提供事务功能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）。

虽然 Redis 并没有严格遵循 ACID 原则，但实际上大部分业务也不需要严格遵循 ACID 原则。以上面的微博关注操作为例，即使系统没有将 A 加入 B 的粉丝列表，其实业务影响也非常小，因此我们在设计方案时，需要根据业务特性和要求来确定是否可以用 Redis，而不能因为 Redis 不遵循 ACID 原则就直接放弃。

基本命令参考：[http://redis.cn/commands.html][http_redis.cn_commands.html]

## **2.文档数据库** ##

文档数据库的出现主要是想解决关系型数据库schema带来的问题，文档数据库最大的特点就是no-schema，可以存储和读取任意的数据。常见的数据格式是JSON（BSON），因为JSON是自描述的，无须在使用前定义字段。

文档数据库的no-schema特点，给业务开发快速迭代开发带来了很大的优势。

**1. 新增字段简单**

业务上增加新的字段，无须再像关系数据库一样要先执行 DDL 语句修改表结构，程序代码直接读写即可。

**2. 历史数据不会出错**

对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。

**3. 可以很容易存储复杂数据**

JSON 是一种强大的描述语言，能够描述复杂的数据结构。比如我们在设计1个用户管理系统时，仅用户基本信息，可能都需要设计多张表结构，但使用文档数据库，一个JSON就可以全部描述。因为使用 JSON 来描述数据，比使用关系型数据库表来描述数据方便和容易得多，而且更加容易理解。

文档数据库的这个特点，特别适合电商和游戏这类的业务场景。以电商为例，不同商品的属性差异很大。例如，冰箱的属性和笔记本电脑的属性差异非常大。

即使是同类商品也有不同的属性。例如，LCD 和 LED 显示器，两者有不同的参数指标。这种业务场景如果使用关系数据库来存储数据，就会很麻烦，而使用文档数据库，会简单、方便许多，扩展新的属性也更加容易。

文档数据库 no-schema 的特性带来的这些优势也是有代价的，最主要的代价就是不支持事务。例如，使用 MongoDB 来存储商品库存，系统创建订单的时候首先需要减扣库存，然后再创建订单。这是一个事务操作，用关系数据库来实现就很简单，但如果用 MongoDB 来实现，就无法做到事务性。异常情况下可能出现库存被扣减了，但订单没有创建的情况。因此某些对事务要求严格的业务场景是不能使用文档数据库的。

文档数据库另外一个缺点就是无法实现关系数据库的 join 操作。例如，我们有一个用户信息表和一个订单表，订单表中有买家用户 id。如果要查询“购买了苹果笔记本用户中的女性用户”，用关系数据库来实现，一个简单的 join 操作就搞定了；而用文档数据库是无法进行 join 查询的，需要查两次：一次查询订单表中购买了苹果笔记本的用户，然后再查询这些用户哪些是女性用户。

## 3.列式数据库 ##

列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，因为关系数据库是按照行来存储数据的。

关系数据库行式存储数据的优点：

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

可以看出，**行式存储的优势是在特定的业务场景下才能体现，如果不存在这样的业务场景，那么行式存储的优势也将不复存在，甚至成为劣势，典型的场景就是海量数据进行统计**。例如，计算某个城市体重超重的人员数据，实际上只需要读取每个人的体重这一列并进行统计即可，而行式存储即使最终只使用一列，也会将所有行数据都读取出来。如果单行用户信息有 1KB，其中体重只有 4 个字节，**行式存储还是会将整行 1KB 数据全部读取到内存中**，这是明显的浪费。而如果**采用列式存储，每个用户只需要读取 4 字节的体重数据即可，I/O 将大大减少**。

除了节省 I/O，列式存储还具备更高的存储压缩比，能够节省更多的存储空间。普通的行式数据库一般压缩率在 3:1 到 5:1 左右，而列式数据库的压缩率一般在 8:1 到 30:1 左右，**因为单个列的数据相似度相比行来说更高，能够达到更高的压缩率**。

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

基于上述列式存储的优缺点，**一般将列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要是针对部分列单列进行操作，且数据写入后就无须再更新删除**。（监控趋势图场景）

## **4.全文搜索引擎** ##

传统关系型数据库主要是根据索引来达到快速查询的目的，但在全文搜索的业务场景下，索引也不行，体现在：

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

**1. 全文搜索基本原理**

全文搜索引擎的技术原理被称为**“倒排索引”（Inverted index）**，也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。之所以被称为“倒排”索引，是和“正排“索引相对的，“正排索引”的基本原理是建立文档到单词的索引。我们通过一个简单的样例来说明这两种索引的差异。

假设我们有一个技术文章的网站，里面收集了各种技术文章，用户可以在网站浏览或者搜索文章。

**正排索引示例：**

![e1921ce07e67c8f46f76f9085260631c.png][]

正排索引适用于根据文档名称来查询文档内容。例如，用户在网站上单击了“面向对象葵花宝典是什么”，网站根据文章标题查询文章的内容展示给用户。

** 倒排索引示例：**

![b6844693e0cd607689d5e834c02e5130.png][]

倒排索引适用于根据关键词来查询文档内容。例如，用户只是想看“设计”相关的文章，网站需要将文章内容中包含“设计”一词的文章都搜索出来展示给用户。

**2. 全文搜索的使用方式**

全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行，两者的术语差异很大，不能简单地等同起来。因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。

目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜索引擎进行索引。

全文搜索引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜索。以 Elasticsearch 为例，其索引基本原理如下：

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

ES官方文档：[https://www.elastic.co/guide/cn/elasticsearch/guide/current/data-in-data-out.html][https_www.elastic.co_guide_cn_elasticsearch_guide_current_data-in-data-out.html]

参考：李运华老师**《从0开始学架构》**（极客时间）

[http_redis.cn_commands.html]: http://redis.cn/commands.html
[e1921ce07e67c8f46f76f9085260631c.png]: /images/20220829/2ffa471048dc4d97a5e699517d62a0f5.png
[b6844693e0cd607689d5e834c02e5130.png]: /images/20220829/88cf306e48c84c029bf3b121fe5d0e86.png
[https_www.elastic.co_guide_cn_elasticsearch_guide_current_data-in-data-out.html]: https://www.elastic.co/guide/cn/elasticsearch/guide/current/data-in-data-out.html