LevelDB简介

我不是女神ヾ 2022-10-29 03:19 144阅读 0赞

### LevelDB ###

*  一、LevelDB
 *   *  1. 什么是LevelDB
     *   *  LevelDb 的特点
         *  LSM 基本原理
     *  2. 既生 Redis 何生 LevelDB ？
 *  二、参考

# 一、LevelDB #

官方github：https://github.com/google/leveldb

## 1. 什么是LevelDB ##

LevelDB是Google传奇工程师Jeff Dean和Sanjay Ghemawat开源的KV存储引擎。

Jeff Dean：Google大规模分布式平台Bigtable和MapReduce主要设计和实现者。  
Sanjay Ghemawat：Google大规模分布式平台GFS，Bigtable和MapReduce主要设计和实现工程师。

这二位是Bigtable的设计和实现者，分布式存储系统Bigtable有两个核心的部分：Master Server和Tablet Server。其中Master Server做一些管理数据的存储以及分布式调度工作，实际的分布式数据存储以及读写操作是由Tablet Server完成的，

Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计。是基于LSM（Log-Structured-Merge Tree）的典型实现。

LevelDb是能够处理十亿级别规模Key-Value型数据持久性存储的C++ 程序库。

### LevelDb 的特点 ###

*  是一个**持久化存储**的KV系统，和Redis这种内存型的KV系统不同，LevelDb不会像Redis一样狂吃内存，而是将大部分数据存储到磁盘上。
 *  key 和value都是任意长度的字节数组。
 *  entry（即一条K-V记录）默认**按照key的字典顺序存储**，可以重写这个排序函数。
 *  操作接口简单，基本操作包括写记录，读记录以及删除记录。也支持针对多条操作的原子批量操作。
 *  支持**数据快照**（snapshot）功能，使得读取操作不受写操作影响，可以在读操作过程中始终看到一致的数据。（即容许在快照中查找数据）
 *  支持**数据压缩**等操作，这对于减小存储空间以及增快IO效率都有直接的帮助。（自动使用Snappy压缩数据）

> LevelDb性能非常突出，官方网站报道其随机写性能达到40万条记录每秒，而随机读性能达到6万条记录每秒。总体来说，LevelDb的写操作要大大快于读操作，而顺序读写操作则大大快于随机读写操作。

### LSM 基本原理 ###

LSM 基本原理是：当读写数据库时，首先记录读写操作到log文件中，然后操作内存数据库，当达到checkpoint时，则写入磁盘，同时删除对应的log文件，然后重新生成新的内存文件和log文件。

LevelDB的数据是存储在磁盘上的，采用LSM-Tree的结构实现。LSM-Tree将磁盘的随机写转化为顺序写，从而大大提高了写速度。

为了做到这一点**LSM-Tree的思路是将索引树结构拆成一大一小两颗树，较小的一个常驻内存，较大的一个持久化到磁盘，他们共同维护一个有序的key空间。**

写入操作会首先操作内存中的树，随着内存中树的不断变大，会触发与磁盘中树的归并操作，而归并操作本身仅有顺序写。随着数据的不断写入，磁盘中的树会不断膨胀，为了避免每次参与归并操作的数据量过大，以及优化读操作的考虑，LevelDB将磁盘中的数据又拆分成多层，每一层的数据达到一定容量后会触发向下一层的归并操作，每一层的数据量比其上一层成倍增长。这也就是LevelDB的名称来源。

## 2. 既生 Redis 何生 LevelDB ？ ##

既生 Redis 何生 LevelDB ？  
参考URL: https://www.cnblogs.com/aksir/p/10183642.html

当我们将 Redis 拿来做缓存用时，背后肯定还有一个持久层数据库记录了全量的冷热数据。Redis 和持久层数据库之间的数据一致性是由应用程序自己来控制的。应用程序会优先去缓存中获取数据，当缓存中没有数据时，应用程序需要从持久层加载数据，然后再放进缓存中。当数据更新发生时，需要将缓存置为失效。

有过这方面开发经验的朋友们就知道写这样的代码还是挺繁琐的，所有的涉及到缓存的业务代码都需要加上这一部分逻辑。

在多进程高并发场合也会导致缓存不一致，比如一个进程对某个 userId 调用 getUser() 方法，因为缓存里没有，它需要从数据库里加载。结果刚刚加载出来，正准备要设置缓存，这时候发生了内存 fullgc 代码暂停了一会，而正在此时另一个进程调用了 updateUser 方法更新了数据库，将缓存置为失效（其实缓存里本来就没有数据）。然后前面那个进程终于 fullgc 结束要开始设置缓存了，这时候进缓存的就是过期的数据。

> LevelDB 将 Redis 缓存和持久层合二为一，一次性帮你搞定缓存和持久层。有了 LevelDB,你再也不用当心缓存一致性问题了。LevelDB 的数据更新要么成功要么不成功，不存在中间薛定谔状态。LevelDB 的内部已经内置了内存缓存和持久层的磁盘文件，用户完全不用操心内部是数据如何保持一致的。

# 二、参考 #

半小时学会LevelDB原理及应用  
参考URL: https://blog.csdn.net/qq\_26499321/article/details/78063856  
leveldb学习：leveldb实现原理  
参考URL: https://blog.csdn.net/guangyacyb/article/details/88133503  
\[推荐阅读\]庖丁解LevelDB之概览  
参考URL: https://www.jianshu.com/p/775407717343

LSM-Tree论文：The Log-Structured Merge-Tree  
http://www.cs.umb.edu/~poneil/lsmtree.pdf