图解NoSQL的江湖称霸之路-51CTO.COM

[[419647]]

1.迷茫的小黑

小黑最近有点郁闷。

手头的工作不是特别喜欢，技术退步有点严重，于是想出去看看机会。

小黑通过朋友内推，前几天去一家名叫宇节蹦跶的公司面试，被一些问题三连击直接跪掉了。

大白安抚小黑说："黑哥，你要知道没有好工作，只有好工人，其实哪儿都差不多，都是打工!"

小黑说："那咋能一样，工具人么得意思，咱的目标是架构师!"

小黑把大白数落了一顿，毕竟不想当架构师的后端不算好的程序员，然后开始说他碰到的问题，原来事情是这样的：

小黑开场白介绍完自己之后，面试官问他喜欢哪个领域，小黑说分布式存储。

面试官附和道："确实是个不错的领域，那问你几个存储相关的问题吧!"

小黑窃喜以为问题在自己知识射程范围内，于是面试官抛出了几个问题：

a. 在实际工作中用到过哪些NoSQL?

b. SQL相比MySQL有什么优缺点?

c. WAL和LSM这些底层机制了解吗?

d. 设计一个NoSQL需要考虑些什么?

听完这几个问题，小黑慌得一批，东扯西扯了几句后，面试官也看出小黑关于存储的知识边界了，很有礼貌地不再追问了。

出于友好礼节，问了几个小黑简历上的东西，最后结束了这场面试。

大白听完也有点慌，毕竟自己也不会，于是故作镇定说:"黑哥，你这几个问题都比较典型，周末写一篇文章，给你讲讲这块东西。"

小黑笑道："哈哈哈，就等你这个呢，上周恰烧烤了，这周恰个火锅呗"

[[419648]]

大白和小黑真是吃喝二人组啊，言归正传，开始NoSQL之旅吧!

2.大器晚成NoSQL

NoSQL一词最早出现于1998年，受限于当时的技术场景和应用情况，并没有折腾出什么大浪，但是在2009年NoSQL再次被提出，这一次出场有点炸裂，颇有明日之星的赶脚。

一般来说，这事行不行往往和口号有很大关系，像我大白的口号就是:人生实苦，早点退休。

2009年在亚特兰大的一次重要会议上对NoSQL提出了个文雅&响亮&略有挑衅的口号：

select fun, profit from real_world where relational=false;

本质上NoSQL是一类数据库的泛称，具体的可以分为以下几种：

本文只介绍键值对key-value型数据库，先看下NoSQL名字的来源和含义的几种解读吧：

解读一

NoSQL 意为"No SQL" 翻译为SQL已死。潜台词是这类数据库没有SQL语句，摒弃了老大哥MySQL的路子，让它退休。嚯，好家伙，口气不小，事实证明，这种"SQL已死"的自信确实有点扯犊子了。

解读二

NoSQL 意为"Not Only SQL"，显然没有那么嚣张了，倒添了几分谦虚，不仅仅是SQL，除了继承了老大哥MySQL的一些功能，还增加了新东西，听起来还不错的样子。

解读三

NoSQL本质上是非关系型数据库，我们都知道关系型数据库一般缩写为RDS或者RDB，所以有人觉得NoSQL应该称为"No Relational Database"，简称"没关系数据库"。

综上，我们更倾向于NoSQL为"Not Only SQL"，作为关系型数据库的补充而存在的一种新形式的数据库。

3.给NoSQL一首歌的时间

工欲善其事必先利其器，大家都这么忙，必须要给个学习NoSQL的理由。

我们试想几种熟悉的场景：

场景一

Leader大熊给小黑一个需求，这个需求在几千万行的MySQL中加个字段，由于是生产环境需要找DBA手动执行，好家伙排队大半天才给执行，给小黑气的，太耽误事了太不方便了。

场景二

Leader大熊又给了小黑一个需求，让他存储一个数据包，数据包其实是Json的串，里面有很多字段，但是现在也不明确PM要怎么用，字段是否会调整，所以用MySQL存储的话，字段还不能确定，于是小黑加了个extra字段来存储后续的扩展，暂时解决了。

场景三

Leader大熊让小黑设计一个并发访问大一些的服务，来完成用户账号体系查询，目前差不多有4亿账号ID，大熊搞了C++服务&存储选择了MySQL，性能怎么也提不上去，真是一筹莫展。

MySQL横行江湖数十载，无人匹敌，尤其在事务、数据一致性、关联查询等场景具有绝对的统治力，确实是数据库蓝波万。

科技进步和新常用新形式的出现也让MySQL有些捉襟见肘，毕竟MySQL不是万金油，要保住地位必须与时俱进才行。

在很多场景中我们并不需要事务、强数据一致性、多表关联等特性，所以我们需要一类更轻快的数据库，它就是NoSQL。

4.MySQL vs NoSQL

我们有必要将MySQL和NoSQL进行一番对比，来加深印象：

MySQL是高度组织化结构化的数据存储，NoSQL无结构化存储
MySQL使用结构化查询语句，NoSQL无查询语言
MySQL需要定义字段和模式，NoSQL自由扩展
MySQL海量数据时读写性能劣于NoSQL
MySQL扩展性较差

上面这些好像全是diss老大哥MySQL的，但是并不是说MySQL很弱，相反是MySQL非常强悍。

高并发&高可用&高可扩展的新要求成就了NoSQL，NoSQL之所以可以应对这些新场景，和它的设计思想有很大的关系。

或许可以用葡萄来说明为啥NoSQL更适用于高并发场景。

NoSQL是一粒一粒的葡萄，存取都非常方便，读写速度快
MySQL是一串葡萄，每一粒都是相互关联的，存取较为麻烦，读写速度慢

两类数据库的对比就说这么多，我们来看看几款大白在实际工作中用过的NoSQL吧!

5.NoSQL明星项目

开源的NoSQL非常多，大白按照层次挑几个典型的代表来和大家分享一下。

NoSQL可以是单机的，也可以是分布式的，可以根据自己的目的来使用。

今天要介绍的几款数据库：Redis、Pika、SSDB、RocksDB、LevelDB。

其中LevelDB是谷歌开发的，RocksDB是Facebook在LevelDB的基础上增加新特性开发的，Redis则不用多说，SSDB和Pika则是国内开源的类Redis的数据库，也非常棒。

接下来看看这几款数据库的特点、联系、底层原理等有趣的东西。

5.1 谷歌出品LevelDB

LevelDB是谷歌的Sanjay Ghemawat和Jeff Dean使用C++开发的单进程/单机版持久化的key-value数据库，于2011年7月开源，可以说是重磅产品。

LevelDB支持了最基础的key-value操作：Get/Put/Delete，但是并没有封装其他的东西，严格意义上来说只是NoSQL存储引擎。

一般来说，机械磁盘最害怕的就是随机读写，磁盘呼噜噜转起来就意味着读写效率在下降。

LevelDB具有很高的随机写，顺序读/写性能，因此LevelDB很适合应用在写多读少的场景，真让人好奇高性能的随机写怎么做到的。

5.1.1 LSM树

很多数据在逻辑上相近，但是在物理存储上却可能相隔很远，这样就会造成大量的随机读写问题，从而降低性能。

LevelDB实现高性能随机写的秘密武器在于使用LSM树存储结构，LSM树又称为日志结构合并树(Log-Structured Merge-Tree)，它并不是具体的数据结构，而是一种设计思想。

LSM树对于每次写入操作，并不是直接将最新的数据驻留在磁盘中，而是将数据先放在内存。

当内存数据达到一定的阈值，再将这部分数据真正刷新到磁盘文件中，从而将磁盘随机写转换为内存顺序写，因而获得了极高的写性能，但是这种机制会降低读的性能，总体来说降低部分读性能来大幅提升写性能是值得的。

5.1.2 LevelDB整体架构

LevelDB 存储结构主要由六个部分组成：

MemTable：内存数据结构，使用SkipList实现，新的数据修改会首先在这里写入，并且有容量限制。
Immutable MemTable：待落盘的数据库内存结构，当 MemTable的大小达到设定的阈值时，会变成 Immutable MemTable，只接受读操作，不再接受写操作，后续会Flush到磁盘上。
SST Files：Sorted String Table Files，磁盘数据存储文件，分为 Level0 到 LevelN 多层，每一层包含多个 SST 文件，文件内数据有序。
Manifest Files：leveldb元信息清单文件。Manifest记录 SST 文件在不同 Level 的分布，相当于SST文件的索引。
Current File：当前正在使用的文件清单文件。

LevelDB的读写过程和上述的整体架构关系密切，先内存后磁盘，一层层读取搜索数据。