【LevelDB介绍】
LevelDB是一个Google开发的速度飞快的数据库键值存储引擎，可按照字符串键值顺序映射。2011年7月30日 Google宣布按照BSD许可 开源LevelDB。
LevelDB是一个C++库，可用于很多情况。比如用于一个网页浏览器存储最近存取网页的缓存，或用于操作系统存储安装包列表，或用于应用存储用户的设置参数。其实新版本的Chrome浏览器里部署的 IndexedDB HTML5
API就是基于LevelDB打造的。Google自己的数据库 Bigtable掌管着数百万数据表也是用LevelDB的。
LevelDB的性能不错， 你可以查看与SQLite和Kyoto
Cabinet的对比跑分。LevelDB与他们最大的不同在于优化了批量更新在间隔很大的键之间来修改键值，这对于高效的更新来说是非常重要的。
来源： http://www.guao.hk/tag/leveldb
【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的时候要占用几万个文件，我修改了：
version_set.cc：23 static const int kTargetFileSize
= 32 * 1048576; |
让默认的文件变成32M,减少目录的压力。
我的测试环境是:
#
10* SAS 300G raid卡，fusionIO 320G, Flashcache,内存96G, 24 * Intel(R) Xeon(R) CPU |
top说:
21782
root 18 0 1273m 1.1g 2012 R 85.3 1.2 1152:34 db_bench |
iostat说:
sdb1
0.40 0.00 3.40 0.00 30.40 0.00 8.94 0.02 4.65 4.65 1.58 |
fioa
0.00 0.00 2074.80 3.80 16598.40 30.40 8.00 0.00 0.13 0.00 0.00 |
dm-0
0.00 0.00 1600.00 0.00 16630.40 0.00 10.39 0.25 0.15 0.15 24.76 |
该测试中请注意snappy压缩没有打开，如果有压缩性能还会高很多，因为IO少了一半。
write_buffer_size=$((256*1024*1024))，log大小设成256M，这样减少切换日志的开销和减少数据合并的频率。
同时应该注意到db_bench是单线程程序，还有一个compact线程，所以最多的时候这个程序只能跑到200%的cpu, IO util也不是很高. 换句话说如果是多线程程序的话性能还要N倍的提高。
我们来看下实际的性能数字：
$ sudo ./db_bench
--num=10000000 --write_buffer_size=$((256*1024*1024)) |
Date:
Fri May 27 17:14:33 2011 |
CPU:
24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHz |
Values:
100 bytes each (50 bytes after compression) |
RawSize:
1106.3 MB (estimated) |
FileSize:
629.4 MB (estimated) |
write_buffer_size=268435456 |
WARNING:
Snappy compression is not enabled |
------------------------------------------------ |
fillseq
: 2.134 micros/ op ;
51.8 MB/s |
fillsync
: 70.722 micros/ op ;
1.6 MB/s (100000 ops) |
fillrandom
: 5.229 micros/ op ;
21.2 MB/s |
overwrite
: 5.396 micros/ op ;
20.5 MB/s |
readrandom
: 65.729 micros/ op ; |
readrandom
: 43.086 micros/ op ; |
readseq
: 0.882 micros/ op ;
125.4 MB/s |
readreverse
: 1.200 micros/ op ;
92.2 MB/s |
compact
: 24599514.008 micros/ op ; |
readrandom
: 12.663 micros/ op ; |
readseq
: 0.372 micros/ op ;
297.4 MB/s |
readreverse
: 0.559 micros/ op ;
198.0 MB/s |
fill100K
: 349.894 micros/ op ;
272.6 MB/s (10000 ops) |
crc32c
: 4.759 micros/ op ;
820.8 MB/s (4K per op ) |
snappycomp
: 3.099 micros/ op ;
(snappy failure) |
snappyuncomp
: 2.146 micros/ op ;
(snappy failure) |
$ sudo ./db_bench
--num=100000000 --write_buffer_size=$((256*1024*1024)) |
Date:
Fri May 27 17:39:19 2011 |
CPU:
24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHz |
Values:
100 bytes each (50 bytes after compression) |
RawSize:
11062.6 MB (estimated) |
FileSize:
6294.3 MB (estimated) |
write_buffer_size=268435456 |
WARNING:
Snappy compression is not enabled |
------------------------------------------------ |
fillseq
: 2.140 micros/ op ;
51.7 MB/s |
fillsync
: 70.592 micros/ op ;
1.6 MB/s (1000000 ops) |
fillrandom
: 6.033 micros/ op ;
18.3 MB/s |
overwrite
: 7.653 micros/ op ;
14.5 MB/s |
readrandom
: 44.833 micros/ op ; |
readrandom
: 43.963 micros/ op ; |
readseq
: 0.561 micros/ op ;
197.1 MB/s |
readreverse
: 0.809 micros/ op ;
136.8 MB/s |
compact
: 123458261.013 micros/ op ; |
readrandom
: 14.079 micros/ op ; |
readseq
: 0.378 micros/ op ;
292.5 MB/s |
readreverse
: 0.567 micros/ op ;
195.2 MB/s |
fill100K
: 1516.707 micros/ op ;
62.9 MB/s (100000 ops) |
crc32c
: 4.726 micros/ op ;
826.6 MB/s (4K per op ) |
snappycomp
: 1.907 micros/ op ;
(snappy failure) |
snappyuncomp
: 0.954 micros/ op ;
(snappy failure) |
$ sudo ./db_bench
--num=1000000000 --write_buffer_size=$((256*1024*1024)) |
Date:
Sun May 29 17:04:14 2011 |
CPU:
24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHz |
Values:
100 bytes each (50 bytes after compression) |
RawSize:
110626.2 MB (estimated) |
FileSize:
62942.5 MB (estimated) |
write_buffer_size=268435456 |
WARNING:
Snappy compression is not enabled |
------------------------------------------------ |
fillseq
: 2.126 micros/ op ;
52.0 MB/s |
fillsync
: 63.644 micros/ op ;
1.7 MB/s (10000000 ops) |
fillrandom
: 10.267 micros/ op ;
10.8 MB/s |
overwrite
: 14.339 micros/ op ;
7.7 MB/s |
总结: Leveldb是个很好的kv库，重点解决了随机IO性能不好的问题，多线程更新的性能非常好.
来源： http://blog.yufeng.info/archives/1327
【更多参考】
更多参考： http://blog.nosqlfan.com/tags/leveldb
LevelDB实现解析： http://rdc.taobao.com/blog/cs/wp-content/plugins/leveldb%E5%AE%9E%E7%8E%B0%E8%A7%A3%E6%9E%90.pdf
作者：heiyeshuwu 发表于2011-12-19 20:21:51
原文链接
