图解：什么是高并发利器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来封装上层协议和代理支持完成的。