图解NoSQL的江湖称霸之路

1.迷茫的小黑

小黑最近有点郁闷。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.大器晚成NoSQL

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

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

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

selectfun,profitfromreal_worldwhererelational=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的读写过程和上述的整体架构关系密切，先内存后磁盘，一层层读取搜索数据。

5.2 脸书出品RocksDB

青出于蓝而胜于蓝。

RocksDB在LevelDB的基础上进行了改进和优化，也成为后续很多NoSQL所选择的存储引擎。RocksDB仍然是采用C++开发的，并且完全向后兼容了LevelDB的接口，可以说是个平滑升级。

5.2.1 RocksDB提升点

来看看RocksDB做了哪些优化和提升：

• RocksDB支持一次获取多个Key，还支持Key范围查找，LevelDB只能获取单个Key。
• RocksDB支持多线程合并，而LevelDB是单线程合并的，多核时代前者效率更高。
• RocksDB增加了合并时过滤器，对不符合条件的Key进行丢弃。
• RocksDB可采用多种压缩算法，除了LevelDB用的snappy，还有zlib、bzip2。
• RocksDB支持增量备份和全量备份。
• RocksDB支持管道式的Memtable，使用多个Memtable，LevelDB只有一个Memtable。

5.2.2 RocksDB整体架构

Rocksdb中引入了Column Family 列族的概念，所谓列族也就是一系列kv组成的数据集，所有的读写操作都需要先指定列族。

每个ColumnFamily有自己的Memtable， SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。

如果说LevelDB是个平民版的NoSQL存储引擎，那么RocksDB绝对是尊享版，所以很多优秀的NoSQL成品都是基于RocksDB来封装上层协议和代理支持完成的。

5.3 ideawu的SSDB

SSDB是基于SSD作为底层存储介质的类Redis数据库。

Redis过于迷人和好用，但是又太昂贵了，所以我们幻想着有一款支持Redis数据结构且容量没限制的数据库。

这种数据库将Redis的数据结构优势和廉价磁盘介质联合起来，着实让人着迷。

没错，SSDB就是这样一款NoSQL数据库。

目前SSDB的维护者并不是特别多，并且在集群化等方面还存在一些问题，不过也算是非常优秀的开源NoSQL了。

来简单看下SSDB的基本架构：

简单来说，SSDB在LevelDB和Redis协议之间做了一层转换，从而实现命令和数据的切换，这就是使用存储引擎之前封装附加部分，从而形成完整的NoSQL。

5.4 360出品Pika

其实SSDB和Pika很有渊源，SSDB的作者曾经在360工作，并且SSDB当时在360的生产环境中使用广泛，Pika数据库是360基于RocksDB开发的集群化高性能NoSQL。

Pika是360DBA团队和基础架构团队使用C++语言联合开发的类Redis存储系统，所以完全支持Redis协议。

Pika是一个可持久化的大容量Redis存储服务，解决Redis由于存储数据量巨大而导致内存不够用的容量瓶颈，并且支持全同步和部分同步。

Pika还提供了迁移工具，实现Redis数据到Pika的平滑迁移，Pika的定位目标并不是取代redis, 而是作为redis的补充，在性能上肯定会低于Redis。

从整体架构可知，Pika是多线程实现的，因此对多核使用效率更高，虽然单线程性能不如Redis，但是多个线程一起上性能也还不错。

Pika目前在360内部使用非常广泛，在一些其他的互联网公司也有使用。

说到底NoSQL是一个实践类的项目，本文也不能讲述太多，否则很空洞，意义不大。

5.5 其他NoSQL

基本上很多互联网公司都会基于LevelDB或者RocksDB开发一款自己的Key-Vaule数据库，有的只支持简单的string结构，有的完全兼容Redis协议和客户端。

大都是解析Redis协议、使用Redis的客户端、增加一层命令解析和数据格式解析层、再有可能有多线程支持&主从化&集群化等。

自己开发一款简单的NoSQL，可以极大提升自己对于NoSQL的理解，在github上有很多这样的项目，可以参考学习下。

6.本文小结

本文粗浅阐述了NoSQL的一些相关知识点，以及一些笔者实践过的NoSQL。

大致原理本质上差不多，但是要打造一款高性能&高可用的工业级NoSQL是非常困难的。