面试官：说说你对NoSQL的了解，为何要有NoSQL

通常而言架构都是随着需求而改动的，以需求为导向。如今关系型数据库仍是主流，也是咱们系统中必不可少的一部分。

可是应对有些需求的时候，关系型数据库每每就撑不住了，须要非关系型数据库来补充它。关系型数据库会有哪些问题呢？

关系型数据库

行存储结构

如关系型数据库是行存储结构，因此当你只想拿一行里面的几列时，从硬盘读取到内存中的数据也会是整行的数据，当数据量很大的时候，IO就吃不消了。固然是能够经过垂直分表来解决这种状况，可是垂直分表也会带来复杂性，具体不展开能够看我写的这篇文章mysql分库分表

还有例如头条的关注列表，若是放在关系型数据库中，那确定就是你的id,你关注的人的id,这样一行数据保存着，而后关注的人有10个就会有10条这样的记录，而后你查看你关注的列表的时候，就须要从数据库里面查10行记录，而后组装起来返回给前端展现。

强结构

强结构的意思就是关系型数据库的表结构有很强的约束，必须按照这么个格式存储，就不够灵活。因此当有新需求须要加字段的时候就须要修改表的结构，若是表的数据不少的话修改表的结构可能会长时间锁表，而致使表的不可用。

没内存型数据库快

例如redis,人家在内存里，我们关系型数据库比不上它的速度。

全文检索能力弱

若是提供全文检索，通常关系型数据库只能like全表扫描，性能不好，虽然像mysql也有全文索引。可是我以为术业有专攻。由于数据库的这些厂商想扩张一下他们软件的广度，他们固然想本身软件支持全部的需求，而后让你们都来用它。若是效果然的这么好的话，像elasticsearch还活的下去嘛。例如mongodb4要支持acid事务等等这类。

一个软件基础的设计就决定了它在一方面是优的，一方面是欠缺的。**通常而言想实现原本就不属于它的领域的东西，要么会牺牲性能，要么会牺牲灵活性。**因此我以下讲的是针对每一个类型NoSQL的优点点，也就是它们的最强点。

NoSQL （not only sql）

NoSQL其实就是关系型数据库的补充，就目前而言咱们是不可能离开关系型数据库的，因此NoSQL就来弥补关系型数据库在某些状况下的不足。这里把常见的NoSQL分为4类：K-V类、文档型、列式存储型、全文搜索型

一、K-V类

全称Key-Value，这应该是咱们都熟悉就像Map同样。表明数据库就是redis,redis的value还分了不少结构，例如:list、set、sorted set、hash、string等。

它是存储在内存中的，因此速度快经常使用来做为缓存服务器。 并且由于它的结构致使有些操做比关系型数据库简单。

举个例子例如List的[LPUSHX key value]操做，将一个值插入到已存在的列表头部，列表是有序的，若是在关系型数据库中得怎么办，插入一条数据，而且将控制位置的那个字段例如叫index，设为1。那是否是还得修改原本的那些数据，把后面全部行的index值都加一，这样才能控制有序，以后删除哪条数据，还得维护修改index。操做是比较麻烦的。

可是它ACID事务只支持I和C也就是隔离性和一致性，不支持原子性和持久性。因此在一些对事务要求的状况下就不适合了。

二、文档型

这个类型它的结构没有约束，能够存储任意结构,由于是文档嘛。啥意思呢，就是例如关系型数据库中规定这个表字段就两个，一个id,一个name。若是你想存个sex字段你就得修改表结构。那文档型不用，由于文档型存储的数据格式通常都是Json,Json里面的字段我任意填，无拘无束。

{
 "id":"1",
 "name":"aa"
}
复制代码

我塞下一条我这样写

{
 "id":"2",
 "name":"bb",
 "sex":"man"
}
复制代码

并且这种类型的数据库容易存复杂的结构，由于Json是一种强大的描述语言，能够清楚的描述复杂的数据结构。若是复杂的数据结构放到关系型数据中那可能就得分不少表。例如我用户基本信息一个表、用户爱好的电影一个表，用户爱好的音乐一个表、用户爱好的游戏一个表，巴拉巴拉的，这些Json就能一次性搞定不须要分这么多表。

表明的数据库有MongoDB。3.2以前的版本不支持join操做，以后出了个lookup来实现join操做。4.0版本以前是不支持事务的，以后虽然说支持事务，可是业界仍是不多用它来保证事务的。

三、列式存储型

也就是按列来存储数据，关系型是按行存储。 按行存储的好处是业务能够简单的获取一行也就是多个列的数据，由于按行存储数据都是连续的，因此磁盘一次操做就读取全部列的数据。

可是按列的话，由于列的存储是不连续的，因此磁盘读取效率比行低

按行存储写若是操做也是一行一块儿的，保证的全部列的数据要么都成功写入，要么的失败 。 若是是按列的话就有可能有些列成功，有些列失败。

可是在大数据统计的时候，通常就统计某一列或者某几列的数据。若是这时候是按行存储的话，那么每次从磁盘读取到内存时都会读取整行数据致使IO过大和资源的浪费。

因此节省I/O就采用按列存储，这样每次只须要拿想要的列进行统计。

表明的数据库是HBase,多用于离线的大数据分析和统计。为啥离线？上面说了写的操做可能会有问题，而且整行读的效率低，因此通常都是线上数据拷过来弄成列数据库，专门用户数据分析。

四、全文检索型

这种型的数据库主要是用在传统关系型数据库在全文检索无力的状况下。由于搜索的条件不少，例如找对象在网站搜，女+170+杭州+爱吃辣+爱健身+爱旅游+28岁。来想一想关系型数据库得怎么建这个索引。。。就是搜索条件的排列组合太多了。因此关系型数据库吃不消。这时候记得引入全文检索型数据库。

全文检索引擎采用倒排索引，也就是每一个单词都是索引，创建单词到文档的索引，这样知足你搜索条件的当此的结果都会快速的显示出来。

表明的有Elasticsearch，分布式文档存储方式。使用方式就是咱们从关系数据库中导出数据，转换成Json格式而后将其输入Elasticsearch中创建索引而后使用。

具体Elasticsearch的东西这里不作深刻分析，否则就跑题了。有需本身查找相关资料。还有虽然Elasticsearch也是面向文档的，可是人家的重点在于全文检索，因此就这样分类。

总结

关系型数据库和非关系型数据库相辅相成，因此咱们要根据各自的优缺点和需求进行相应的架构。 没有最好只有最合适。

---

若是错误欢迎指正！ 我的公众号：yes的练级攻略