leveldb的价值
每一类组件,都有它特定擅长的应用场景。在leveldb出世之前,我们对于nosql下的kv存储,我们有redis方案存储。然而redis数据存储的上限,即是机器内存。内存在目前阶段,算是比较昂贵。而leveldb的出现,提供了一个可以以机器磁盘为容量上限,支持持久化的写操作的同时,做到写速度较快,读速度也不慢的一个解决方案。
leveldb如何解决问题
leveldb面对的问题
作为一个支持持久化KV系统,核心就这么几个。CURD
1)持久化
2)写操作
3)读操作
4)查找
5)删除
解决方案
方案一
需要支持持久化,则我们一般会用WAL技术,即是先写日志。只要日志写成功,那么数据就算持久化到磁盘中了。
这个方案能够满足1)持久化和2)写操作的要求
存在问题:
但是对于读操作不友好。只写日志需要比较好的查询。
方案二
基于上面的思路,我能否增加一块内存来缓存数据,即是我写完日志之后,我把数据在内存中写一份。内存中维护一份KV的内存表。
如果数据量在比较小的情况下,那这个方案能够比较好的满足以上要求。
但是,数据量大的时候无法工作。
存在问题:
当数据量比较大的时候,内存无法支撑时,需要到日志中去查找数据,读操作会显得力不所心。
方案三
方案二的问题,在于数据量较大的情况下。
1)如果查找数据在内存中,则直接返回数据。
2)如果查找数据不在内存中,而在磁盘中,则需要想办法解决这个场景的问题。
如果我们在磁盘中的日志,也能够存储的时候保证key有序,查找的时候,能够通过比较快的定位磁盘文件,并能够找到具体的文件来找具体的key,通过二分搜索,则能够比较快的完成查找工作。
基于上面的分析,leveldb的主体设计思路已经呈现出来。
leveldb解决方案
写操作
- WAL写到日志,再更新到memtable中。
- 如果memtable超过一定的size之后,则转换成imm memtable,imm内存块与磁盘中的sstable进行合并落盘。
- 磁盘中的sstable根据新旧进行分层。上层比下层要新,数据量要少。
读操作
- 在memtable中查找数据。
- 在imm内存块中查找数据。
- 在level0、level1、…levelN中进行查找数据
以上操作,每一步骤如果找到则返回,如果未找到则继续往下一步骤执行。
待续。。。