leveldb性能分析和表现

Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计。特别是LSM算法。

那么数据库最怕的的随机IO他是如何解决的呢？

先说随机写，它的写都是先记录到日志文件去的，在日志文件满之前只是简单的更新memtable,那么就把随机写转化成了顺序写。在日志满了后，把日志里面的数据排序写成sst表同时和之前的sst进行合并，这个动作也是顺序读和写。大家都知道传统磁盘raid的顺序读写吞吐量是很大的，100M左右是没有问题。在写日志文件的时候，用到是buffer IO，也就是说如果操作系统有足够的内存，这个读写全部由操作系统缓冲，效果非常好。即使是sync写模式，也是以数据累计到4K为一个单位写的，所以效率高。

那么随机读呢？这个它解决不了。但是ssd盘最擅长随机读了。这个硬件很自然的解决了这个问题。

所以leveldb的绝配是ssd盘的raid.

leveldb标准版本编译见这里，由于标准版本用到了c++ 0x的特性，在RHEL平台下没得到支持，所以为了移植性, basho见这里为它做了标准c++版本的port, 见目录c_src/leveldb. 他之所以用c++ 0x标准主要是用到里面的原子库，basho的port用了libatomicops搞定这个问题.

我们的测试采用的就是这个版本, 我们分别测试了1000万， 1亿，10亿数据量下的leveldb表现，发现随着数据集的变化性能变化不大。
由于leveldb默认的sst文件是2M, 在数据集达到100G的时候要占用几万个文件，我修改了：

让默认的文件变成32M,减少目录的压力。

我的测试环境是:

top说:

iostat说:

该测试中请注意snappy压缩没有打开，如果有压缩性能还会高很多，因为IO少了一半。
write_buffer_size=$((256*1024*1024))，log大小设成256M，这样减少切换日志的开销和减少数据合并的频率。

同时应该注意到db_bench是单线程程序，还有一个compact线程，所以最多的时候这个程序只能跑到200%的cpu, IO util也不是很高. 换句话说如果是多线程程序的话性能还要N倍的提高。

我们来看下实际的性能数字：

总结: Leveldb是个很好的kv库，重点解决了随机IO性能不好的问题，多线程更新的性能非常好.

玩得开心！