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

最新推荐文章于 2023-03-13 16:51:37 发布

weixin_34088583

最新推荐文章于 2023-03-13 16:51:37 发布

阅读量1.2k

点赞数

文章标签：数据库面试 json

原文链接：https://juejin.im/post/5cbc13b06fb9a0685a3f014a

版权

一般而言架构都是随着需求而改动的，以需求为导向。现在关系型数据库还是主流，也是我们系统中必不可少的一部分。

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

关系型数据库

行存储结构

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

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

强结构

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

没内存型数据库快

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

全文检索能力弱

如果提供全文检索，一般关系型数据库只能like全表扫描，性能很差，虽然像mysql也有全文索引。但是我觉得术业有专攻。因为数据库的这些厂商想扩张一下他们软件的广度，他们当然想自己软件支持所有的需求，然后让大家都来用它。如果效果真的这么好的话，像elasticsearch还活的下去嘛。例如mongodb4要支持acid事务等等这类。

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

NoSQL （not only sql）

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

1、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也就是隔离性和一致性，不支持原子性和持久性。所以在一些对事务要求的情况下就不适合了。

2、文档型

这个类型它的结构没有约束，可以存储任意结构,因为是文档嘛。啥意思呢，就是例如关系型数据库中规定这个表字段就两个，一个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版本之前是不支持事务的，之后虽说支持事务，但是业界还是很少用它来保证事务的。