Leveldb是一個(gè)google實(shí)現(xiàn)的非常高效的kv數(shù)據(jù)庫(kù)，目前的版本1.2能夠支持billion級(jí)別的數(shù)據(jù)量了。 在這個(gè)數(shù)量級(jí)別下還有著非常高的性能，主要?dú)w功于它的良好的設(shè)計(jì)。特別是LSM算法。

那么數(shù)據(jù)庫(kù)最怕的的隨機(jī)IO他是如何解決的呢?

先說隨機(jī)寫，它的寫都是先記錄到日志文件去的，在日志文件滿之前只是簡(jiǎn)單的更新memtable,那么就把隨機(jī)寫轉(zhuǎn)化成了順序?qū)?。在日志滿了后，把日志里面的數(shù)據(jù)排序?qū)懗蓅st表同時(shí)和之前的sst進(jìn)行合并，這個(gè)動(dòng)作也是順序讀和寫。大家都知道傳統(tǒng)磁盤raid的順序讀寫吞吐量是很大的，100M左右是沒有問題。在寫日志文件的時(shí)候，用到是buffer IO，也就是說如果操作系統(tǒng)有足夠的內(nèi)存，這個(gè)讀寫全部由操作系統(tǒng)緩沖，效果非常好。即使是sync寫模式，也是以數(shù)據(jù)累計(jì)到4K為一個(gè)單位寫的，所以效率高。

那么隨機(jī)讀呢?這個(gè)它解決不了。但是ssd盤最擅長(zhǎng)隨機(jī)讀了。這個(gè)硬件很自然的解決了這個(gè)問題。

所以leveldb的絕配是ssd盤的raid.

leveldb標(biāo)準(zhǔn)版本編譯見淺談LevelDB在ubuntu 11.04下編譯失敗的問題，由于標(biāo)準(zhǔn)版本用到了c++ 0x的特性，在RHEL平臺(tái)下沒得到支持，所以為了移植性, basho為它做了標(biāo)準(zhǔn)c++版本的port, 見目錄c_src/leveldb. 他之所以用c++ 0x標(biāo)準(zhǔn)主要是用到里面的原子庫(kù)，basho的port用了libatomicops搞定這個(gè)問題.

我們的測(cè)試采用的就是這個(gè)版本, 我們分別測(cè)試了1000萬， 1億，10億數(shù)據(jù)量下的leveldb表現(xiàn)，發(fā)現(xiàn)隨著數(shù)據(jù)集的變化性能變化不大。

由于leveldb默認(rèn)的sst文件是2M, 在數(shù)據(jù)集達(dá)到100G的時(shí)候要占用幾萬個(gè)文件，我修改了：

version_set.cc：23 static const int kTargetFileSize = 32 * 1048576; 

讓默認(rèn)的文件變成32M,減少目錄的壓力。

我的測(cè)試環(huán)境是:

$uname -r    
2.6.18-164.el5 #RHEL 5U4    
# 10* SAS 300G raid卡，fusionIO 320G, Flashcache,內(nèi)存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說:

$iostat -dx 5    
...    
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    
...  

該測(cè)試中請(qǐng)注意snappy壓縮沒有打開，如果有壓縮性能還會(huì)高很多，因?yàn)镮O少了一半。

write_buffer_size=$((256*1024*1024))，log大小設(shè)成256M，這樣減少切換日志的開銷和減少數(shù)據(jù)合并的頻率。

同時(shí)應(yīng)該注意到db_bench是單線程程序，還有一個(gè)compact線程，所以最多的時(shí)候這個(gè)程序只能跑到200%的cpu, IO util也不是很高. 換句話說如果是多線程程序的話性能還要N倍的提高。

我們來看下實(shí)際的性能數(shù)字：

#1千萬條記錄    
$sudo ./db_bench --num=10000000 --write_buffer_size=$((256*1024*1024))    
LevelDB:    version 1.2    
Date:       Fri May 27 17:14:33 2011    
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
CPUCache:   12288 KB    
Keys:       16 bytes each    
Values:     100 bytes each (50 bytes after compression)    
Entries:    10000000    
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)    
 
#1億條記錄    
$sudo ./db_bench --num=100000000 --write_buffer_size=$((256*1024*1024))    
LevelDB:    version 1.2    
Date:       Fri May 27 17:39:19 2011    
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
CPUCache:   12288 KB    
Keys:       16 bytes each    
Values:     100 bytes each (50 bytes after compression)    
Entries:    100000000    
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)    
 
#10億條記錄    
$sudo ./db_bench --num=1000000000 --write_buffer_size=$((256*1024*1024))    
Password:    
LevelDB:    version 1.2    
Date:       Sun May 29 17:04:14 2011    
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
CPUCache:   12288 KB    
Keys:       16 bytes each    
Values:     100 bytes each (50 bytes after compression)    
Entries:    1000000000    
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    
...比較慢待補(bǔ)充  

總結(jié): Leveldb是個(gè)很好的kv庫(kù)，重點(diǎn)解決了隨機(jī)IO性能不好的問題，多線程更新的性能非常好.

原文鏈接：http://blog.yufeng.info/archives/1327

【編輯推薦】

1. LevelDB—一個(gè)超高性能的K/V數(shù)據(jù)庫(kù)
2. 淺談LevelDB在ubuntu 11.04下編譯失敗的問題