从0开始学架构_17_16_高性能NoSQL
你好，我是华仔。
今天我和你分享的主题是高性能no. Sql关系数据库经过几十年的发展后，已经非常成熟，强大的c口功能和ACID的属性使得关系数据库广泛应用于各式各样的系统中。
但这并不意味着关系数据库是完美的。
关系数据库存在如下缺点，关系数据库存储的是行记录，无法存储数据结构。
以微博的关注关系为例，我关注的人是一个用户ID列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装无法直接存储一个列表，关系数据库的schema扩展很不方便。
关系数据库的表结构schema是强约束操作不存在的，列会报错。
业务变化时扩充列也比较麻烦，需要执行DDL语句修改，而且修改时可能会长时间锁表。
关系数据库在大数据场景下IO较高。
如果对一些大数据的表进行统计之类的运算，关系数据库的IO会很高。
因为即使针对其中某一列进行运算，关系数据库，也会将整行数据读取关系数据库的全文搜索功能比较弱，关系数据库的全文搜索只能使用like进行整表扫描，匹配性能非常低。
在互联网这种搜索复杂的场景下，无法满足业务要求。
针对上述问题，分别诞生了不同的no sql解决方案。
这些方案与关系数据库相比，在某些场景下表现更好，但世上没有免费的午餐。
No sql方案带来的优势，本质上是牺牲ACID中的某个或者某几个特性，因此我们不能盲目的迷信。
No sql是银弹，而应该将no sql作为CQ的一个有力补充。
No sql不等于no sql,而是not only sql.常见的no c口方案分为四类，KB存储解决关系数据库无法存储数据结构的问题。
以REDIS为代表文档数据库，解决关系数据库强schema约束的问题。
以蒙go DB为代表劣势数据库，解决关系数据库大数据场景下的IO问题。
以h base为代表全文，搜索引擎解决关系数据库的全文搜索性能问题。
以elastic search为代表，今天我来介绍一下各种高性能no c口方案的典型特征和应用场景。
Kb存储的全称是key value存储，其中key是数据的标识，和关系数据库中的主键含义一样，value就是具体的数据。
Redis是KV存储的典型代表，它是一款开源的高性能KV缓存和存储系统。
Redis的value是具体的数据结构，包括string、 hash、 list、 set、 sororted、 set bittermap和hyper loglog,所以常常被称为数据结构。
服务器。
以list数据结构为例，REDIS提供了下面这些典型的操作。
Air pop key从对立的左边出多一个元素，l index k index获取一个元素，通过其索引列表l lin key获得对立的长度。
R pop key从堆立的右边出堆一个元素。
以上这些功能，如果用关系数据库来实现，就会变得很复杂。
例如，air pop操作是移除并返回key对应的list的第一个元素。
如果用关系数据库来存储，为了达到同样目的，需要进行下面的操作。
每条数据除了数据编号，还有位置编号，否则没有办法判断哪条数据是第一条。
注意，这里不能用行ID作为位置编号，因为我们会往列表头部插入数据查询出第一条数据删除。
第一条数据更新，从第二条开始的所有数据的位置编号可以看出，关系数据库的实现很麻烦，而且需要进行多次c口操作，性能很低。
Redis的缺点主要体现在并不支持完整的ACID事务。
Redis虽然提供事务功能，但REDIS的事物和关系数据库的事物不可同日而语。
Redis的事务只能保证隔离性和一致性，无法保证原子性和持久性。
虽然REDIS并没有严格遵循ACID原则，但实际上大部分业务也不需要严格遵循ACID原则。
以上面的微博关注操作为例，即使系统没有将a加入b的粉丝列表，其实业务影响也非常小。
因此，我们在设计方案时，需要根据业务特性和要求来确定是否可以用REDIS,而而能因为REDIS不遵循ACID原则，就直接放弃。
为了解决关系数据库schema带来的问题，文档数据库应运而生。
文档数据库最大的特点就是no schema,可以存储和读取任意的数据。
目前绝大部分文档数据库存储的数据格式是jason,因为jason数据是自描述的，无需在使用前定义字段，读取一个jason中不存在的字段，也不会导致c口那样的语法错误。
文档数据库的noschemmer特性，给业务开发带来了几个明显的优势。
一、新增字段简单，业务上增加新的字段，无需再像关系数据库一样，要先执行DDR语句，修改表结构，程序代码直接读写即可。
二、历史数据不会出错，对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。
三、可以很容易存储复杂数据。
Jason是一种强大的描述语言，能够描述复杂的数据结构。
例如，我们设计一个用户管理系统，用户的信息有ID、姓名、性别、爱好、邮箱地址、学历、信息。
其中，爱好是列表，地址是一个结构，包括省市区、楼盘地址、学历，包括学校专业、入学、毕业、年份信息等。
如果我们用关系数据库来存储，需要设计多张表，包括基本信息、爱好地址、学历，而用文档数据库一个jason就可以全部描述。
通过文稿中的样例，我们看到使用jason来描述数据，比使用关系型数据库表来描述数据方便和容易的多，而且更加容易理解文档数据库这个特点呢特别适合电商和游戏这类的业务场景。
以电商为例，不同商品的属性差异很大，例如冰箱的属性和笔记本电脑的属性差异非常大。
你可以点击文稿，查看图片，即使是同类商品也有不同的属性，例如LCD和LED显示器，两者有不同的参数指标。
这种业务场景，如果使用关系数据库来存储数据就会很麻烦，而使用文档数据库会简单方便许多，扩展新的属性也更加容易。
文档数据库no schemme的特性带来的的这优势也是有代价的的，最主要的代价就是不支持事物。
例如用mongo DB来存储商品库存系统。
创建订单的时候，首先需要减扣库存，然后再创建订单。
这是一个事物操作，用惯性数据库来实现，就很简单。
但如果用蒙go DB来实现，就无法做到事务性异常情况下，可能出现库存被扣减了。
但订单没有创建的情况。
因此，某些对事务要求严格的业务场景是不能使用文档数据库的文档数据库。
另外一个缺点就是无法实现关联数据库的join操作。
例如，我们有一个用户信息表和一个订单表，订单表中有买家用户ID.如果要查询购买了苹果笔记本用户中的女性用户，用关系数据库来实现一个简单的join操作就搞定了。
而用文档数据库是无法进行join查询的，需要查两次一次查询订单表中购买了苹果笔记本的用户，然后再查询这些用户，哪些是女性用户。
顾名思义，列式数据库就是按照列来存储数据的数据库。
与之对应的传统关系数据库被称为行式数据库。
因为关系数据库是按照行来存储数据的，关系数据库按照行式来存储数据，主要有以下几个优势，业务同时读取多个列时效率高。
因为这些列都是按行存储在一起的一次磁盘操作，就能把一行数据中的各个列都读取到内存中，能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性。
否则，如果采用列存储，可能会出现某次写操作，有的列成功了，有的列失败了，导致数据不一致。
我们可以看到，行市存储的优势是在特定的业务场景下才能体现。
如果不存在这样的业务场景，那么行市存储的优势也将不复存在，甚至成为劣势。
典型的场景就是海量数据进行统计，例如计算某个城市体重超重的人员数据，实际上只需要读取每个人的体重这一列并进行统计即可。
而行式存储即使最终只使用一列，也会将所有行数据都读取出来。
如果单行用户信息有一KB,其中体重只有四个，字节行式存储，还是会将整行一KB数据全部读取到内存中，这是明显的浪费。
而如果采用列式存储，每个用户只需要读取四字节的体重数据，即可，IO将大大减少。
除了节省IO劣式存储，还具备更高的存储压缩比，能够节省更多的存储空间。
普通的行式数据库一般压缩率在三比一到五比一左右，而劣势数据库的压缩率一般在八比一到三十比一左右。
因为单个列的数据相似度相比行来说更高，能够达到更高的压缩率。
同样，如果场景发生变化，列势存储的优势又会变成劣势，典型的场景是需要频繁的更新多个列。
因为劣式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时，磁盘是随机写操作，而行式存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成。
劣式存储的随机写效率，要远远低于行式存储的写效率。
此外，劣势存储高压缩率在更新场景下也会成为劣势。
同为更新时，需要将存储数据解压后更新。
因为再压缩最后写入磁盘。
基于上述劣势，存储的优缺点，一般将劣势存储应用在离线的大数据分析和统计场景中。
因为这种场景主要是针对部分列单列进行操作，且数据写入后就无需再更新删除。
传统的关系型数据库，通过索引来达到快速查询的目的。
但是在全文搜索的业务场景下，索引也无能为力。
主要体现在全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。
全文搜索的模糊匹配方式索引无法满足，只能用like查询，而like查询是整表扫描效率非常低。
我举一个具体的例子来看看关系型数据库为何无法满足全文搜索的要求。
假设我们做一个婚恋网站，其主要目的是帮助程序员找朋友。
但模式与传统婚恋网站不同，是程序员发布自己的信息用户来搜索程序员程序员的信息表，请点击文稿查看。
我们来看一下这个简单业务的搜索场景。
美女一听说PHP是世界上最好的预言，那么PHP的程序员肯定是钱最多的，而且我妈一定要我找一个上海的。
美女。
一的搜索条件是性别加PHP加上海，其中PHP要用模糊匹配查询语言列。
上海要查询地点列，如果用索引支撑，则需要建立地点。
这个索引美女二，我好崇拜这些技术哥哥呀，要是能找一个鹅厂技术，哥哥陪我旅游就更好了。
美女二的搜索条件是性别加鹅厂加旅游，其中旅游要用模糊匹配查询爱好列，鹅厂需要查询单位列。
如果要用索引支撑，则需要建立单位索引。
美女三，我是一个女程序员，想在北京找一个猫场的技术专家。
美女三的搜索条件是性别加猫厂加北京加java加技术专家，其中猫厂加北京可以通过索引来查询，但java和技术专家都只能通过模糊匹配来查询。
帅哥四，程序员妹子有没有漂亮的呢？试试看看帅哥。
四的搜索条件是性别加美丽加美女，只能通过模糊匹配搜索自我介绍列。
以上呢只是简单举个例子，实际上搜索条件是无法列举完全的，各种排列组合非常多。
通过这个简单的样例，我们就可以看出关键数据库在支撑全文搜索时的不足。
一、全文搜索基本原理全文搜索引擎的技术原理被称为倒排索引，也常被称为反向索引。
置入档案或反向档案是一种索引方法，其基本原理是建立单词到文档的索引，之所以被称为倒排索引，是和正排索引相对的。
正牌索引的基本原理是建立文档到单词的索引。
我们通过一个简单的样例来说明这两种索引的差异。
假设我们有一个技术文章的网站里面收集了各种技术文章，用户呢可以在网站浏览或者搜索文章正排索引和倒排索引。
设例请点击文稿，查看正牌索引，适用于根据文档名称来查询文档内容。
例如，用户在网站上单击了面向对象。
葵花宝典是什么网站？根据文章标题查询文章的内容展示给用户倒排索引，适用于根据关键词来查询文档内容。
例如，用户只是想看设计相关的文章，网站需要将文章内容中包含设计一词的文章都搜索出来，展示给用户。
二、全文搜索的使用方式。
全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是建和行，两者的术语差异很大，不能简单的同等起来。
因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。
目前常用的转换方式是将关系型数据按照对象的形式转换为jason文档，然后将jjason文档输入全文搜索引擎进行搜索。
同样以程序员的基本信息表为例，看看如何转换将前面样例中的程序员表格转换为jason文档，可以得到三个程序员信息相关的文档。
我以程序员一为例，请点击文稿查看全文搜索引擎。
能够基于jason文档建立全文索引，然后快速进行全文搜索。
以ellistitic search为例，其索引基本原理如下。
Elastic search是分布式的文档存储方式，它能存储和检索复杂的数据结构序列化成为jason文档。
以实时的方式，在elasstic search中，每个字段的所有数据都是默认被索引的，即每个字段都有。
为了快速检索设置的专用倒排索引，而且不像其他多数的数据库，它能在相同的查询中使用所有倒排索引，并以惊人的速度返回结果。
今天呢我为你讲了，为了弥补关系型数据库缺陷而产生的no sql技术，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。
因为no sql的方案功能都很强大。
有人认为no sql等于no sql架构设计的时候，无需再使用关系数据库。
对此你怎么看呢？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。