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.
我們的測試採用的就是這個版本, 我們分別測試了1000萬, 1億,10億資料量下的leveldb表現,發現隨著資料集的變化效能變化不大。
由於leveldb預設的sst檔案是2M, 在資料集達到100G的時候要佔用幾萬個檔案,我修改了:
version_set.cc:23 static const int kTargetFileSize = 32 * 1048576;
讓預設的檔案變成32M,減少目錄的壓力。
我的測試環境是:
$uname -r2.6.18-164.el5 #RHEL 5U4# 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說:
$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.58fioa 0.00 0.00 2074.80 3.80 16598.40 30.40 8.00 0.00 0.13 0.00 0.00dm-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倍的提高。
我們來看下實際的效能數字:
#1千萬條記錄$sudo ./db_bench --num=10000000 --write_buffer_size=$((256*1024*1024))LevelDB: version 1.2Date: Fri May 27 17:14:33 2011CPU: 24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHzCPUCache: 12288 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 10000000RawSize: 1106.3 MB (estimated)FileSize: 629.4 MB (estimated)write_buffer_size=268435456WARNING: Snappy compression is not enabled------------------------------------------------fillseq : 2.134 micros/op; 51.8 MB/sfillsync : 70.722 micros/op; 1.6 MB/s (100000 ops)fillrandom : 5.229 micros/op; 21.2 MB/soverwrite : 5.396 micros/op; 20.5 MB/sreadrandom : 65.729 micros/op;readrandom : 43.086 micros/op;readseq : 0.882 micros/op; 125.4 MB/sreadreverse : 1.200 micros/op; 92.2 MB/scompact : 24599514.008 micros/op;readrandom : 12.663 micros/op;readseq : 0.372 micros/op; 297.4 MB/sreadreverse : 0.559 micros/op; 198.0 MB/sfill100K : 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.2Date: Fri May 27 17:39:19 2011CPU: 24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHzCPUCache: 12288 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 100000000RawSize: 11062.6 MB (estimated)FileSize: 6294.3 MB (estimated)write_buffer_size=268435456WARNING: Snappy compression is not enabled------------------------------------------------fillseq : 2.140 micros/op; 51.7 MB/sfillsync : 70.592 micros/op; 1.6 MB/s (1000000 ops)fillrandom : 6.033 micros/op; 18.3 MB/soverwrite : 7.653 micros/op; 14.5 MB/sreadrandom : 44.833 micros/op;readrandom : 43.963 micros/op;readseq : 0.561 micros/op; 197.1 MB/sreadreverse : 0.809 micros/op; 136.8 MB/scompact : 123458261.013 micros/op;readrandom : 14.079 micros/op;readseq : 0.378 micros/op; 292.5 MB/sreadreverse : 0.567 micros/op; 195.2 MB/sfill100K : 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.2Date: Sun May 29 17:04:14 2011CPU: 24 * Intel(R) Xeon(R) CPU X5670 @ 2.93GHzCPUCache: 12288 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 1000000000RawSize: 110626.2 MB (estimated)FileSize: 62942.5 MB (estimated)write_buffer_size=268435456WARNING: Snappy compression is not enabled------------------------------------------------fillseq : 2.126 micros/op; 52.0 MB/sfillsync : 63.644 micros/op; 1.7 MB/s (10000000 ops)fillrandom : 10.267 micros/op; 10.8 MB/soverwrite : 14.339 micros/op; 7.7 MB/s...比較慢待補充
總結: Leveldb是個很好的kv庫,重點解決了隨機IO效能不好的問題,多線程更新的效能非常好.