官方github:https://github.com/google/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性能非常突出,官方网站报道其随机写性能达到40万条记录每秒,而随机读性能达到6万条记录每秒。总体来说,LevelDb的写操作要大大快于读操作,而顺序读写操作则大大快于随机读写操作。
LSM 基本原理是:当读写数据库时,首先记录读写操作到log文件中,然后操作内存数据库,当达到checkpoint时,则写入磁盘,同时删除对应的log文件,然后重新生成新的内存文件和log文件。
LevelDB的数据是存储在磁盘上的,采用LSM-Tree的结构实现。LSM-Tree将磁盘的随机写转化为顺序写,从而大大提高了写速度。
为了做到这一点LSM-Tree的思路是将索引树结构拆成一大一小两颗树,较小的一个常驻内存,较大的一个持久化到磁盘,他们共同维护一个有序的key空间。
写入操作会首先操作内存中的树,随着内存中树的不断变大,会触发与磁盘中树的归并操作,而归并操作本身仅有顺序写。随着数据的不断写入,磁盘中的树会不断膨胀,为了避免每次参与归并操作的数据量过大,以及优化读操作的考虑,LevelDB将磁盘中的数据又拆分成多层,每一层的数据达到一定容量后会触发向下一层的归并操作,每一层的数据量比其上一层成倍增长。这也就是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