16 - 高性能NoSQL.docx

《16 - 高性能NoSQL.docx》由会员分享，可在线阅读，更多相关《16 - 高性能NoSQL.docx（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、16 | 高性能NoSQL 关系数据库经过几十年的发展后已经特别成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各种各样的系统中，但这并不意味着关系数据库是完备的，关系数据库存在如下缺点。 关系数据库存储的是行记录，无法存储数据结构 以微博的关注关系为例，我关注的人是一个用户 ID 列表，运用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法干脆存储一个列表。 关系数据库的 schema 扩展很不便利 关系数据库的表结构 schema 是强约束，操作不存在的列会报错，业务改变时扩充列也比较麻烦，须要执行 DDL（data definition language，

2、如 CREATE、ALTER、DROP 等）语句修改，而且修改时可能会长时间锁表（例如，MySQL 可能将表锁住 1 个小时）。 关系数据库在大数据场景下 I/O 较高 假如对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高，因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。 关系数据库的全文搜寻功能比较弱 关系数据库的全文搜寻只能运用 like 进行整表扫描匹配，性能特别低，在互联网这种搜寻困难的场景下无法满意业务要求。 针对上述问题，分别诞生了不同的 NoSQL 解决方案，这些方案与关系数据库相比，在某些应用场景下表现更好。但世上没有的午餐，No

3、SQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性，因此我们不能盲目地迷信 NoSQL 是银弹，而应当将 NoSQL 作为 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。 常见的 NoSQL 方案分为 4 类。 K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。 全文搜寻引擎：解决关系数据库的全文搜寻性能问题，以 Elasti

4、csearch 为代表。 今日，我来介绍一下各种高性能 NoSQL 方案的典型特征和应用场景。 K-V 存储 K-V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含义一样，Value 就是详细的数据。 Redis 是 K-V 存储的典型代表，它是一款开源（基于 BSD 许可）的高性能 K-V 缓存和存储系统。Redis 的 Value 是详细的数据结构，包括 string、hash、list、set、sorted set、bitmap 和 hyperloglog，所以经常被称为数据结构服务器。 以 List 数据结构为例，Redis 供应了下面这些典

5、型的操作（更多请参考链接： LPOP key 从队列的左边出队一个元素。 LINDEX key index 获得一个元素，通过其索引列表。 LLEN key 获得队列（List）的长度。 RPOP key 从队列的右边出队一个元素。 以上这些功能，假如用关系数据库来实现，就会变得很困难。例如，LPOP 操作是移除并返回 key 对应的 list 的第一个元素。假如用关系数据库来存储，为了达到同样目的，须要进行下面的操作： 每条数据除了数据编号（例如，行 ID），还要有位置编号，否则没有方法推断哪条数据是第一条。留意这里不能用行 ID 作为位置编号，因为我们会往列表头部插入数据。 查询出第一条数

6、据。 删除第一条数据。 更新从其次条起先的全部数据的位置编号。 可以看出关系数据库的实现很麻烦，而且须要进行多次 SQL 操作，性能很低。 Redis 的缺点主要体现在并不支持完整的 ACID 事务，Redis 虽然供应事务功能，但 Redis 的事务和关系数据库的事务不行相提并论，Redis 的事务只能保证隔离性和一样性（I 和 C），无法保证原子性和长久性（A 和 D）。 虽然 Redis 并没有严格遵循 ACID 原则，但事实上大部分业务也不须要严格遵循 ACID 原则。以上面的微博关注操作为例，即使系统没有将 A 加入 B 的粉丝列表，其实业务影响也特别小，因此我们在设计方案时，须要依

7、据业务特性和要求来确定是否可以用 Redis，而不能因为 Redis 不遵循 ACID 原则就干脆放弃。 文档数据库 为了解决关系数据库 schema 带来的问题，文档数据库应运而生。文档数据库最大的特点就是 no-schema，可以存储和读取随意的数据。目前绝大部分文档数据库存储的数据格式是 JSON（或者 BSON），因为 JSON 数据是自描述的，无须在运用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。 文档数据库的 no-schema 特性，给业务开发带来了几个明显的优势。 1. 新增字段简洁 业务上增加新的字段，无须再像关系数据库一样要先执行 DD

8、L 语句修改表结构，程序代码干脆读写即可。 2. 历史数据不会出错 对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。 3. 可以很简单存储困难数据 JSON 是一种强大的描述语言，能够描述困难的数据结构。例如，我们设计一个用户管理系统，用户的信息有 ID、姓名、性别、爱好、邮箱、地址、学历信息。其中爱好是列表（因为可以有多个爱好）；地址是一个结构，包括省市区楼盘地址；学历包括学校、专业、入学毕业年份信息等。假如我们用关系数据库来存储，须要设计多张表，包括基本信息（列：ID、姓名、性别、邮箱）、爱好（列：ID、爱好）、地址（列：省、市、区、具体地址）、学

9、历（列：入学时间、毕业时间、学校名称、专业），而运用文档数据库，一个 JSON 就可以全部描述。 "id": 10000, "name": "James", "sex": "male", "hobbies": "football", "playing", "singing" , "email": "user", "address": "provin

10、ce": "GuangDong", "city": "GuangZhou", "district": "Tianhe", "detail": "PingYun Road 163" , "education": "begin": "2000-09-01", "end": "2023-07-01", "school": "

11、UESTC", "major": "Computer Science & Technology" , "begin": "2023-09-01", "end": "2023-07-01", "school": "SCUT", "major": "Computer Science & Technology" 复制代码 通过这个样例我们看到，运用 JSON 来描述数据，比运用

12、关系型数据库表来描述数据便利和简单得多，而且更加简单理解。 文档数据库的这个特点，特殊适合电商和嬉戏这类的业务场景。以电商为例，不同商品的属性差异很大。例如，冰箱的属性和笔记本电脑的属性差异特别大，如下图所示。 即使是同类商品也有不同的属性。例如，LCD 和 LED 显示器，两者有不同的参数指标。这种业务场景假如运用关系数据库来存储数据，就会很麻烦，而运用文档数据库，会简洁、便利很多，扩展新的属性也更加简单。 文档数据库 no-schema 的特性带来的这些优势也是有代价的，最主要的代价就是不支持事务。例如，运用 MongoDB 来存储商品库存，系统创建订单的时候首先须要减扣库存，然后再创建订

13、单。这是一个事务操作，用关系数据库来实现就很简洁，但假如用 MongoDB 来实现，就无法做到事务性。异样状况下可能出现库存被扣减了，但订单没有创建的状况。因此某些对事务要求严格的业务场景是不能运用文档数据库的。 文档数据库另外一个缺点就是无法实现关系数据库的 join 操作。例如，我们有一个用户信息表和一个订单表，订单表中有买家用户 id。假如要查询购买了苹果笔记本用户中的女性用户，用关系数据库来实现，一个简洁的 join 操作就搞定了；而用文档数据库是无法进行 join 查询的，须要查两次：一次查询订单表中购买了苹果笔记本的用户，然后再查询这些用户哪些是女性用户。 列式数据库 顾名思义，列

14、式数据库就是根据列来存储数据的数据库，与之对应的传统关系数据库被称为行式数据库，因为关系数据库是根据行来存储数据的。 关系数据库根据行式来存储数据，主要有以下几个优势： 业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中。 能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一样性；否则假如采纳列存储，可能会出现某次写操作，有的列胜利了，有的列失败了，导致数据不一样。 我们可以看到，行式存储的优势是在特定的业务场景下才能体现，假如不存在这样的业务场景，那么行式存储的优势也将不复存在，甚至成为劣势，典型的场景就是海

15、量数据进行统计。例如，计算某个城市体重超重的人员数据，事实上只须要读取每个人的体重这一列并进行统计即可，而行式存储即使最终只运用一列，也会将全部行数据都读取出来。假如单行用户信息有 1KB，其中体重只有 4 个字节，行式存储还是会将整行 1KB 数据全部读取到内存中，这是明显的奢侈。而假如采纳列式存储，每个用户只须要读取 4 字节的体重数据即可，I/O 将大大削减。 除了节约 I/O，列式存储还具备更高的存储压缩比，能够节约更多的存储空间。一般的行式数据库一般压缩率在 3:1 到 5:1 左右，而列式数据库的压缩率一般在 8:1 到 30:1 左右，因为单个列的数据相像度相比行来说更高，能够达

16、到更高的压缩率。 同样，假如场景发生改变，列式存储的优势又会变成劣势。典型的场景是须要频繁地更新多个列。因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作；而行式存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成，列式存储的随机写效率要远远低于行式存储的写效率。此外，列式存储高压缩率在更新场景下也会成为劣势，因为更新时须要将存储数据解压后更新，然后再压缩，最终写入磁盘。 基于上述列式存储的优缺点，一般将列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要是针对部分列单列进行操作，且数据写入后就无须再更新删除。 全文搜寻引擎 传统的关系型数据库通过

17、索引来达到快速查询的目的，但是在全文搜寻的业务场景下，索引也无能为力，主要体现在： 全文搜寻的条件可以随意排列组合，假如通过索引来满意，则索引的数量会特别多。 全文搜寻的模糊匹配方式，索引无法满意，只能用 like 查询，而 like 查询是整表扫描，效率特别低。 我举一个详细的例子来看看关系型数据库为何无法满意全文搜寻的要求。假设我们做一个婚恋网站，其主要目的是帮助程序员找挚友，但模式与传统婚恋网站不同，是程序员发布自己的信息，用户来搜寻程序员。程序员的信息表设计如下： 我们来看一下这个简洁业务的搜寻场景： 美女 1：听说 PHP 是世界上最好的语言，那么 PHP 的程序员确定是钱最多的，而

18、且我妈肯定要我找一个上海的。 美女 1 的搜寻条件是性别 + PHP + 上海，其中PHP要用模糊匹配查询语言列，上海要查询地点列，假如用索引支撑，则须要建立地点这个索引。 美女 2：我好崇拜这些技术哥哥啊，要是能找一个鹅厂技术哥哥陪我旅游就更好了。 美女 2 的搜寻条件是性别 + 鹅厂 + 旅游，其中旅游要用模糊匹配查询爱好列，鹅厂须要查询单位列，假如要用索引支撑，则须要建立单位索引。 美女 3：我是一个女程序员，想在北京找一个猫厂的 Java 技术专家。 美女 3 的搜寻条件是性别 + 猫厂 + 北京 + Java + 技术专家，其中猫厂 + 北京可以通过索引来查询，但Java技术专家都只

19、能通过模糊匹配来查询。 帅哥 4：程序员妹子有没有美丽的呢？试试看看。 帅哥 4 的搜寻条件是性别 + 漂亮 + 美女，只能通过模糊匹配搜寻自我介绍列。 以上只是简洁举个例子，事实上搜寻条件是无法列举完全的，各种排列组合特别多，通过这个简洁的样例我们就可以看出关系数据库在支撑全文搜寻时的不足。 1. 全文搜寻基本原理 全文搜寻引擎的技术原理被称为倒排索引（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。之所以被称为倒排索引，是和正排索引相对的，正排索引的基本原理是建立文档到单词的索引。我们通过一个简洁的样例来说明这两种索

20、引的差异。 假设我们有一个技术文章的网站，里面收集了各种技术文章，用户可以在网站阅读或者搜寻文章。 正排索引示例： （注：文章内容仅为示范，文章内容事实上存储的是几千字的内容。） 正排索引适用于依据文档名称来查询文档内容。例如，用户在网站上单击了面对对象葵花宝典是什么，网站依据文章标题查询文章的内容展示给用户。 倒排索引示例： （注：表格仅为示范，不是完整的倒排索引表格，事实上的倒排索引有成千上万行，因为每个单词就是一个索引。） 倒排索引适用于依据关键词来查询文档内容。例如，用户只是想看设计相关的文章，网站须要将文章内容中包含设计一词的文章都搜寻出来展示给用户。 2. 全文搜寻的运用方式 全文

21、搜寻引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行，两者的术语差异很大，不能简洁地等同起来。因此，为了让全文搜寻引擎支持关系型数据的全文搜寻，须要做一些转换操作，即将关系型数据转换为文档数据。 目前常用的转换方式是将关系型数据根据对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜寻引擎进行索引。我同样以程序员的基本信息表为例，看看如何转换。 将前面样例中的程序员表格转换为 JSON 文档，可以得到 3 个程序员信息相关的文档，我以程序员 1 为例： "id": 1, " 姓名 ": " 多隆 ", &quo

22、t; 性别 ": " 男 ", " 地点 ": " 北京 ", " 单位 ": " 猫厂 ", " 爱好 ": " 写代码，旅游，马拉松 ", " 语言 ": "Java、C+、PHP", " 自我介绍 ": " 技术专家，简洁，为人热忱 " 复制代码 全文搜寻引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜寻。以 Elasticsearch 为例，其索引

23、基本原理如下： Elastcisearch 是分布式的文档存储方式。它能存储和检索困难的数据结构——序列化成为 JSON 文档——以实时的方式。 在 Elasticsearch 中，每个字段的全部数据都是默认被索引的。即每个字段都有为了快速检索设置的专用倒排索引。而且，不像其他多数的数据库，它能在相同的查询中运用全部倒排索引，并以惊人的速度返回结果。 （https:/www.elastic.co/guide/cn/elasticsearch/guide/current/data-in-data-out.html） 小结 今日我为你讲了为了弥补关系型数据库缺陷而产生的 NoSQL 技术，希望对你有所帮助。 这就是今日的全部内容，留一道思索题给你吧，因为 NoSQL 的方案功能都很强大，有人认为 NoSQL = No SQL，架构设计的时候无需再运用关系数据库，对此你怎么看？ 欢迎你把答案写到留言区，和我一起探讨。信任经过深度思索的回答，也会让你对学问的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）