leveldb原理和使用

朴灿烈づ我的快乐病毒、 2022-07-12 03:36 250阅读 0赞

LevelDB是一个基于本地文件的存储引擎，非分布式存储引擎，原理基于BigTable（LSM文件树），无索引机制，存储条目为Key-value。适用于保存数据缓存、日志存储、高速缓存等应用，主要是避免RPC请求带来的延迟问题。在存取模型上，顺序读取性能极高，但是对于随机读取的情况延迟较大（但性能也不是特别低），比较适合顺序写入（key），随机的key写入也不会带来问题。数据存量通常为物理内存的3~5倍，不建议存储过大的数据，在这个数据量级上，leveldb的性能比那些“分布式存储”要高（即本地磁盘存取延迟小于RPC网络延迟）。

1）如果你的log日志或者视频片段需要暂存在本地，稍后再批量发给远端的数据中心，那么这种需求非常适合使用leveldb做数据缓冲。（这些缓存的数据被切分成多个小的chunks，以key-value的方式保存在leveldb中）

2）如果你希望构建一个本地cache组件，但是cache的数据可能比内存容量要大，此时我们就可以使用leveldb做支撑，leveldb将一部分热区数据保存在内存，其他数据保存在磁盘上，可以并发的、随机读取key-value。但是数据不能太大，否则磁盘读取的延迟将很大，此时应该使用分布式缓存。（当然，分布式缓存是用于解决分布式环境中数据同步、一致性的问题，不仅仅是数据量过大的问题）

**一、原理**

**1、Files**

leveldb的实现类似于Bigtable中的一个tablet（Google），只不过底层的文件组织形式稍有不同。

每个Database有一系列本地文件组成，这些文件有不同的类型：

**Log文件**

log文件存储了一序列的最近更新操作，每个更新（update）都会append到当前log文件的尾部，当log文件的尺寸达到预设定的大小时，将会把此log文件转换成一个sorted table（.sst）文件，然后滚动创建一个新的log文件来保存此后的updates操作，主要是用于数据恢复。

当前log文件的数据copy被保存在一个内存结构中，称为memtable，任何update首先会被写入到memtable中，然后在写入log文件。每个read操作都会首先访问memtable，如果memtable中没有的话再触发磁盘检索（如果开启了cacheSize，则在磁盘检索之前会查看cache），因此这些update数据都可以在read操作中反应出来。

memtable中的数据按照key顺序存储，即有序存储（基于跳跃表实现）。默认memtable的大小为4M，由参数“writeBufferSize”决定，需要在leveldb打开db文件时指定。

**Sorted tables（简称SST）**

当memtable的数据量达到阀值时，则会被刷新写入到磁盘，生成一个Sorted table（.sst）文件，此文件存储了一序列按照key排序的entries，每个entry可以是key-value，或者是一个key的删除标记（marker），文件和memtable一样也是根据key排序的。（删除标记可以屏蔽掉先前sst文件中保存的较旧的数据，即如果一个key被标记为删除，那么先前的sst文件中关于此key的数据，将不会被read到）

Sorted tables按照层次（level）进行组织，由log文件生成的SST将会放置在一个特殊的young level中--即level-0，当young level中SST文件的个数超过一个阀值（4个），这些young文件将会与level-1中的那些有数据重叠的文件合并，并生成一序列新的level-1文件（每个新文件大小位2M）。

备注：“重叠”意义为key区间在两个文件中都存在。keys在SST文件中保存是严格排序的。同时需要注意，sst文件中还包含BloomFilter内容，bloomFilter可以快速判断key是否存在于此sst文件，有效的提高了read的效率。

young level中的文件可能包含重叠的keys，不过其他level中的SST文件只会包含不同的“非重叠”的keys区间。假如level-L，其中L >= 1，当level-L中SST文件的总大小达到(10^L)MB时（例如level-1位10MB，level-2位100MB），那么level-L中的一个文件，将会和level-(L+1)中那些有keys重叠（覆盖）的文件merged，并生成一组新的level-(L+1)文件。这些merge，只通过批量的文件读写操作，即可将最新的updates数据从young level迁移到最高的level。同一个level中，不会有key重叠的sst文件；但是不同level可能会有！

level的级别越低，数据新鲜程度越高。遍历数据时，从level 0开始向高level推进。

**Manifest（清单）**

manifest文件中列举了构成每个level的SST文件列表，以及相应的key区间，还包括一些重要的metadata。当database被reopened时，都会创建一个新的manifest文件（文件命中包含一个新的number序列号）。manifest文件的格式像log，“serving data”的变更（比如SST文件的创建、删除）操作都会被append到此log中。

**Current**

CURRENT文件是一个简单的文本文件，保存了当前最新的manifest文件的名称。

其他：略

**2、Level 0**

当log文件的尺寸增长到一定的大小（默认1M）：

*  创建一个新的memtable和log文件，用来保存此后的updates操作。
 *  在后台：将旧的memtable写入到文件生成新的SST文件，然后销毁此memtable。删除旧的log文件，然后将此新的SST文件添加到young level组织中。

**3、Compactions**

当level-L的尺寸达到了它的限制，我们将使用一个后台线程对它进行Compaction。压缩时，将会从level-L中选择一个文件，同时选择level-(L+1)中所有与此文件key有重叠的文件。如果level-L中一个文件只与level-(L+1)中某个文件的一部分重叠，那么level-(L+1)中的此文件作为压缩时的输入，在压缩结束后，此文件将被抛弃。不过，level-0比较特殊（文件中的keys可能互相重叠），对于level-0到level-1的压缩我们需要特殊处理：level-0中文件中互相重叠的话，那么将可能一次选择多个level-0的文件作为输入。

压缩将选择的文件内容重新输出到一序列新的level-(L+1)文件中（多路合并），当每个输出文件达到2M时将会切换一个新的文件，或者当新输出的文件中key区间覆盖了level-(L+2)中多于10个文件时，也会切换生成新文件；第二个规则保证此后level-(L+1)的压缩时无需选择太多的文件。

当level-(L+1)中的新文件加入到“serving state”时，那么旧的文件将会被删除（包括level-L和level-(L+1)）。

压缩时，将会抛弃那些“overwritten”的值；如果遇到删除标记，且对应的key在更高的level中不存在，也会直接抛弃。

**Timing**

level-0将会读取4个1M的文件（每个1M，level-0最多4个文件），最坏的情况是读取level-1的所有文件（10M），即我们读写各10MB。

和level-0不同，对于其他level-L，我们将读取2M的一个文件，最坏的情况是它与level-(L+1)中12文件有重叠（10个文件，同时还有2个处于边界的文件）；那么一次压缩将读写26MB数据。假定磁盘IO速率位100M/S，那么一次压缩耗时大约0.5秒。

如果我们对磁盘速率受限，比如10M/S，那么压缩可能耗时达到5秒。

**文件个数**

每个SST文件的大小为2M（level-0的除外），事实上我们可以通过增大此值（需要重新编译源文件），来减少文件的总数，不过这会导致压缩更加耗时（读取的文件尺寸更大，磁盘密集操作）；另外，我们可以将不同的文件放在多个目录中。

**4、数据恢复**

1）从CURRENT中读取最新的manifest文件的名字。

2）读取manifest文件。

3）清理那么过期的文件。

4）我们可以打开所有的SST文件，不过通常lazy更好。

5）将log存留文件转存成新的level-0中的SST文件。

6）引导write操作到新的log文件中。

7）回收垃圾文件。

每次压缩和recovery操作后，将会调用DeleteObsoleteFiles()：从database中查询出所有的file的名字，然后将当前log文件之外的其他log文件全出删除，删除那些所有level中都不包含的、以及压缩操作没有引用的SST文件。

**二、使用**

leveldb为一个本地化的K-V存储数据库，设计思想类似于Bigtable，将key按照顺序在底层文件中存储，同时为了加快读取操作，内存中有一个memtable来缓存数据。

根据leveldb官网的性能基准测试，我们大概得出其特性：

1）leveldb的顺序读（遍历）的效率极高，几乎接近文件系统的文件顺序读。比BTree数据库要快多倍。

2）其随机读性能较高，但和顺序读仍有几个量级上的差距。leveldb的随机读，和基于BTree的数据库仍有较大差距。（个人亲测，其随机读的效率并不像官网所说的如此之高，可能与cache的配置有关）随机读，要比BTree慢上一倍左右。

3）顺序写，性能极高（无强制sync），受限于磁盘速率；随机写，性能稍差，不过性能相对于其他DB而言，仍有极大的优势。无论是顺序写还是随机写，性能都比BTree要快多倍。

4）leveldb为K-V存储结构，字节存储。属于NoSql数据库的一种，不支持事务，只能通过KEY查询数据；支持批量读写操作。

5）leveldb中key和value数据尺寸不能太大，在KB级别，如果存储较大的key或者value，将对leveld的读写性能都有较大的影响。

6）leveldb本身没有提供索引机制，所以随机读性能稍差。它存储的key、value可以为任意字节数组。

因为leveldb本身尚不具备“分布式”集群架构能力，所以，我们将有限的数据基于leveldb存储（受限于本地磁盘）。

**案例推演：**

1）leveldb具备“cache + 磁盘持久存储”特性，且不支持RPC调用，那么leveldb需要和application部署在同一宿主机器上。类似于“嵌入式”K-V存储系统。

2）如果存储数据较少，3~5G，且“读写比”（R:W）较高，我们可以让leveldb作为本地cache来使用，比如Guava cache + leveldb，这种结合，可以实现类似于轻量级redis。即作为本地缓存使用。通常LevelDB存储的数据是内存大小的3~5倍（现代的操作系统配置），不建议用leveldb存储过大的数据，否则性能将下降很大。

3）如果数据较多，通常为“顺序读”或者“顺序写”，我们可以将leveldb作为Hadoop HDFS的“微缩版”，可以用来缓存高峰期的消息、日志存储的缓冲区。比如我们将用户操作日志暂且存储在leveldb中，而不是直接将日志发送给remote端的Hadoop（因为每次都直接调用RPC，将会对系统的吞吐能力带来极大的影响），而是将这些频繁写入的日志数据存储在本地的leveldb中，然后使用后台线程以“均衡”的速度发送出去。起到了“Flow Control”（流量控制）的作用。

其中ActiveMQ即采用leveldb作为底层的消息数据存储，性能和容错能力很强。在很多情况下，leveldb可以作为本地log、IO缓冲文件的存储方案。

**三、API简析（JAVA版）**

原生leveldb是基于C++开发，java语言无法直接使用；iq80对leveldb使用JAVA语言进行了“逐句”重开发，经过很多大型项目的验证（比如ActiveMQ），iq80开发的JAVA版leveldb在性能上损失极少（10%）。对于JAVA开发人员来说，我们直接使用即可，无需额外的安装其他lib。

**1、pom.xml**

Java代码 ![收藏代码][icon_star.png]

1.  <dependency> 
2.   <groupId>org.iq80.leveldb</groupId> 
3.   <artifactId>leveldb</artifactId> 
4.   <version>0.7</version> 
5.  </dependency> 
6.  <dependency> 
7.   <groupId>org.iq80.leveldb</groupId> 
8.   <artifactId>leveldb-api</artifactId> 
9.   <version>0.7</version> 
10. </dependency>

2、代码样例

Java代码 ![收藏代码][icon_star.png]

1.  **boolean** cleanup = **true**; 
2.  Charset charset = Charset.forName("utf-8"); 
3.  String path = "/data/leveldb"; 
4.  
5.  //init
6.  DBFactory factory = Iq80DBFactory.factory; 
7.  File dir = **new** File(path); 
8.  //如果数据不需要reload，则每次重启，尝试清理磁盘中path下的旧数据。
9.  **if**(cleanup) \{ 
10.  factory.destroy(dir,**null**);//清除文件夹内的所有文件。
11. \} 
12. Options options = **new** Options().createIfMissing(**true**); 
13. //重新open新的db
14. DB db = factory.open(dir,options); 
15. 
16. //write
17. db.put("key-01".getBytes(charset),"value-01".getBytes(charset)); 
18. 
19. //write后立即进行磁盘同步写
20. WriteOptions writeOptions = **new** WriteOptions().sync(**true**);//线程安全
21. db.put("key-02".getBytes(charset),"value-02".getBytes(charset),writeOptions); 
22. 
23. 
24. //batch write；
25. WriteBatch writeBatch = db.createWriteBatch(); 
26. writeBatch.put("key-03".getBytes(charset),"value-03".getBytes(charset)); 
27. writeBatch.put("key-04".getBytes(charset),"value-04".getBytes(charset)); 
28. writeBatch.delete("key-01".getBytes(charset)); 
29. db.write(writeBatch); 
30. writeBatch.close(); 
31. 
32. //read
33. **byte**\[\] bv = db.get("key-02".getBytes(charset)); 
34. **if**(bv != **null** && bv.length > 0) \{ 
35.  String value = **new** String(bv,charset); 
36.  System.out.println(value); 
37. \} 
38. 
39. //iterator，遍历，顺序读
40. 
41. //读取当前snapshot，快照，读取期间数据的变更，不会反应出来
42. Snapshot snapshot = db.getSnapshot(); 
43. //读选项
44. ReadOptions readOptions = **new** ReadOptions(); 
45. readOptions.fillCache(**false**);//遍历中swap出来的数据，不应该保存在memtable中。
46. readOptions.snapshot(snapshot);//默认snapshot为当前。
47. DBIterator iterator = db.iterator(readOptions); 
48. **while** (iterator.hasNext()) \{ 
49.  Map.Entry<**byte**\[\],**byte**\[\]> item = iterator.next(); 
50.  String key = **new** String(item.getKey(),charset); 
51.  String value = **new** String(item.getValue(),charset);//null,check.
52.  System.out.println(key + ":" \+ value); 
53. \} 
54. iterator.close();//must be
55. 
56. //delete
57. db.delete("key-01".getBytes(charset)); 
58. 
59. //compaction，手动
60. 
61. db.compactRange("key-".getBytes(charset),**null**); 
62. 
63. //
64. db.close();

LevelDB是google的实现，官方只提供了C++版的客户端，java客户端比如上述的iq80（还有fusesource 项目的leveldbjni）是来自社区的。不过BigTable的设计思想和LevelDB的特性被社区延续了下去，比如相对比较完善和性能更加优秀的[RocksDB][]，我们建议在实际的开发工作中采用它**。**

**参考文献：**

1、LevelDB实现原理：http://leveldb.googlecode.com/git-history/1.17/doc/impl.html

2、LevelDB性能测试：http://leveldb.googlecode.com/git-history/1.17/doc/benchmark.html?r=1.17

[icon_star.png]: /images/20220711/acec8b1f71d54e70b8becb5c3f096ce0.png
[RocksDB]: http://rocksdb.org/overview/