LevelDB的边边角角之一
0, Varint64
变长数字,主要用于压缩数字,来源于protobuf。
1, Log 和Table的文件格式
Google recordio的文件格式
|
|
Checksum: 32bits;
Original Size: 64bits,数据的原始大小;
Compressed Size: 64bits压缩后的大小,如果不是压缩,就为0;
Data: 实际的数据
LevelDB memtable: Arena+SkipList
Arena,
所有的block都保存在一个vector<char*>中
1,当前block有freeSpace>size直接返回;
2,如果size大于blockSize/4则new_block返回,否则只new_block并用block其中的一部分(这样浪费了当前的block剩余空间);
SkipList,
LevelDB log文件格式
block := record* trailer
record :=
checksum: uint32 //crc32c of type and data[], little-endian
length: uint32 // little-endian?其实是uint16
type: uint8 // enum of { FULL, FIRST, MIDDLE, LAST}
data: uint[length]
下图为一个Block(32KB), log file由一连串block组成。
Record 1
|
Record 2... |
Record n |
Trailer
|
与recordio format的对比:
好处:可以直接跳过一个一个block
坏处:暂时对小的record没有packing,并没有压缩数据,但都可以通过添加type进行支持。
LevelDB table文件格式
immutable, 不可修改的。
k/v 对都是有序地按序写在data block中,data/index block均可以被压缩(状态位在?)
meta block就是下面的filter/stat meta block,也可以支持更多的。
每个block的大小?
index和footer放在文件最后是宜于生成文件,并方便open文件后重定位。
Data block 1 |
Data block 2 |
... |
Data block N |
Meta block 1 |
… |
Meta block K |
Meta Index block |
Index block |
Footer (fixed size: starts at file_size - sizeof(footer)) |
BlockHandle:
offset: varint64
size: varint64
相当于内部index到data的指针
metaindex
key name of meta block
value BlockHandle 指向meta block
index,每个data block一条记录
key string>=last_key
value BlockHandle指向data block
footer 这是定长的。
metaindex_handle: char[p], block handle for metaindex
index_handle: char[q], block handle for index
padding: char[40-p-q], 填充zeroed bytes
40==2*BlockHandle::kMaxEncodedLength
magic: fixed64
filter meta block
[TBD]
stat meta block
data size/ index size/ key size(uncompressed)/ value size(uncompressed)
number of entries/ number of data blocks
2, 从log file到合并 table file
log file,每个update都添加到log里,当大于(默认4MB)会转为sorted table,
内存中的影像是memtable。生成sst(young level-0)后,这个log就会给删掉,memtable?
sorted tables的compaction,sst分为一系列的levels,young level,也就是level-0,中的文件可能会有覆盖范围的key(overlapping key),而level-L(L>0)则每个文件的key范围都是没有互相覆盖的。
当level-L的所有文件总大小超过10^L(MB)时,会用其中一个level-L的文件File1+所有key范围与File1有覆盖的level-(L+1)的文件File2..k 合并成一个新的level-L+1文件。
这样做的好处?单条的读?bulk的批量读?
Manifest一个普通的log file,保存每个level下的所有sst, 并对应的key ranges,以及其他的meta data。
Current普通文本,里面就指向当前在用的Manifest文件。
其他的Lock文件和dbtmp等等,
A, Reference:
1) leveldb tutorial, http://leveldb.googlecode.com/svn/trunk/doc/index.html
2) leveldb brief of implements, http://leveldb.googlecode.com/svn/trunk/doc/impl.html
3) table file format, http://leveldb.googlecode.com/svn/trunk/doc/table_format.txt
4) log file format, http://leveldb.googlecode.com/svn/trunk/doc/log_format.txt
5) blog 很详细的一个分析 http://blog.csdn.net/sparkliang/article/category/1342001
相关推荐
leveldb是一个写性能十分优秀的存储引擎,是典型的LSM树(Log Structured-Merge Tree)实现。LSM树的核心思想就是放弃部分读的性能,换取最大的写入能力。
Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比Leveldb lmdb性能对比...
WPF下使用现有类库操作LevelDB数据库,且解析JSON字符串并显示;test_db目录为测试使用的LevelDB数据库,数据为JSON字符串。
自己编译的leveldb.so文件。 这是一个适用于arm32架构的php模块, leveldb数据库懂得都懂 下载文件中含一个压缩包(这是源码,同样含有编译样例) 一个 leveldb.so文件 这是我编译的自己用的leveldb模块,试过了...
linux下c++实现leveldb的添加数据,查询数据,对于学习理解leveldb很有帮助
这是leveldb在
免积分,最新的 leveldb-1.18 源码及leveldb实现解析
leveldb源码工程Windows版,使用vs2010编译通过。有问题可以参考根目录下的Windows文件(使用notepad打开)
LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
leveldb 1.70
levigo是LevelDB的一个 Go 包装
leveldb 源码,源于google 官方github 源码,解压缩即可
build->debug->lib build->release->lib lib路径 leveldb -->vs2015 版本
leveldb源码分析 比较全面讲解leveldb leveldb 是 Google 开源的持久化 KV 单机存储引擎,开源页面 http://code.google.com/p/leveldb/。 针对存储面对的普遍随机 IO 问题,leveldb 采用了 merge-dump 的方式,将...
leveldb源码分析
mnist-leveldb.7z 深度学习caffe mnist 数据集在windows上可以使用
C++ 开发的一个快速的键值对存储数据库 leveldb windows编译动态库
包含两个版本的levelDB,1.15.0和1.4.0
Leveldb是一个google实现的非常高效的kv数据库,资源为leveldb实现分析 pdf版本,内容清晰,简介,详实。
WPF下使用现有类库读取LevelDB数据库,且解析JSON字符串并显示 test_db 测试使用的LevelDB数据库 数据为JSON字符串