LevelDB是google開(kāi)發(fā)的盯拱、高效的鍵值存儲(chǔ)程序庫(kù)放典。之所以稱之為程序庫(kù)而非代碼庫(kù)是因?yàn)樗鼉H僅是一個(gè)library文件豆瘫，無(wú)法單獨(dú)運(yùn)行，宿主為leveldb使用者油宜。
1.1 特性
- key扛或、value可以是任意的byte數(shù)組
- 數(shù)據(jù)按key排序后存儲(chǔ)
- 使用者可提供自定義比較器以決定key的排序方式
- 基本操作包括Put(key,value), Get(key), Delete(key)
- 支持原子的批量修改操作
- 支持創(chuàng)建快照(用后需及時(shí)釋放)瘫析，獲取當(dāng)前的一致性數(shù)據(jù)
- 數(shù)據(jù)支持向前江醇、向后的迭代器
- 數(shù)據(jù)自動(dòng)壓縮，采用 Snappy compression library.
- 外部依賴(文件系統(tǒng)操作等)通過(guò)接口完成幌墓，用戶可定制實(shí)現(xiàn)但壮。
1.2 限制
- LevelDB不是SQL數(shù)據(jù)庫(kù)冀泻，不支持關(guān)系數(shù)據(jù)模型，不支持SQL查詢蜡饵，也不支持創(chuàng)建索引弹渔。
- 同時(shí)只能有一個(gè)進(jìn)程(允許多線程)訪問(wèn)數(shù)據(jù)庫(kù)。
- 不支持client-server模式溯祸，使用者可以基于該library構(gòu)建自己的服務(wù)器肢专。
1.3 性能
下面的性能測(cè)試報(bào)告基于db_bench程序，結(jié)果存在一定干擾焦辅，但做為性能評(píng)估是足夠的博杖。
1.3.1 驗(yàn)證場(chǎng)景
我們使用一個(gè)數(shù)百萬(wàn)記錄的數(shù)據(jù)庫(kù)，每條記錄的key大小為16字節(jié)氨鹏，value大小為100字節(jié)欧募⊙棺矗基準(zhǔn)測(cè)試的Value大小壓縮為原始大小的一半仆抵。
LevelDB: version 1.1
Date: Sun May 1 12:11:26 2011
CPU: 4 x Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
CPUCache: 4096 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
Raw Size: 110.6 MB (estimated)
File Size: 62.9 MB (estimated)
1.3.2 寫(xiě)性能
“填充”基準(zhǔn)測(cè)試以順序或隨機(jī)順序創(chuàng)建一個(gè)全新的數(shù)據(jù)庫(kù)。 每次操作后种冬，“fillsync”基準(zhǔn)將數(shù)據(jù)從操作系統(tǒng)刷新到磁盤(pán)(順序操作); 其他寫(xiě)入操作則利用操作系統(tǒng)緩沖區(qū)高速緩存中一段時(shí)間镣丑。 “覆蓋”基準(zhǔn)做隨機(jī)寫(xiě)入，更新數(shù)據(jù)庫(kù)中的現(xiàn)有key值記錄娱两。
fillseq : 1.765 micros/op; 62.7 MB/s; 56.6W+ OP/S
fillsync : 268.409 micros/op; 0.4 MB/s (10000 ops); 0.37W OP/S
fillrandom : 2.460 micros/op; 45.0 MB/s; 40W+ OP/S
overwrite : 2.380 micros/op; 46.5 MB/s; 42W+ OP/S
"op"是指一次寫(xiě)入一個(gè)key/value對(duì)莺匠。隨機(jī)寫(xiě)性能大約在40W op/s，“fillsync”操作時(shí)間(0.3 millisecond)甚至少于磁盤(pán)seek時(shí)間(典型時(shí)間為10millisecond)十兢。我們懷疑這可能是因?yàn)橛脖P(pán)自身存在緩存(memory)趣竣，并在數(shù)據(jù)真正落盤(pán)前進(jìn)行響應(yīng)。這樣做是否安全取決于出現(xiàn)電力故障時(shí)旱物，是否來(lái)得及將緩存中的數(shù)據(jù)寫(xiě)入磁盤(pán)遥缕。
1.3.3 讀性能
我們列出了正向和反向方向上順序讀取的性能，以及隨機(jī)查找的性能宵呛。 請(qǐng)注意单匣，基準(zhǔn)數(shù)據(jù)庫(kù)創(chuàng)建的數(shù)據(jù)庫(kù)相當(dāng)小， 報(bào)告中的leveldb性能數(shù)據(jù)基本是基于內(nèi)存操作的宝穗。 讀取操作系統(tǒng)高速緩沖區(qū)中不存在的數(shù)據(jù)時(shí)户秤，將額外執(zhí)行1-2次磁盤(pán)查找動(dòng)作。 寫(xiě)性能基本不受數(shù)據(jù)是否在內(nèi)存中的影響逮矛。
readrandom : 16.677 micros/op; (approximately 60,000 reads per second)
readseq : 0.476 micros/op; 232.3 MB/s; 210W+ op/s
readreverse : 0.724 micros/op; 152.9 MB/s; 138W+ op/s
LevelDB在后臺(tái)壓縮其底層存儲(chǔ)數(shù)據(jù)鸡号，以提高讀取性能。 上面列出的結(jié)果是在大量隨機(jī)寫(xiě)作之后立即進(jìn)行的须鼎。 壓縮后的結(jié)果（通常自動(dòng)觸發(fā)）更好鲸伴。
readrandom : 11.602 micros/op; (approximately 85,000 reads per second)
readseq : 0.423 micros/op; 261.8 MB/s; 236W+ op/s
readreverse : 0.663 micros/op; 166.9 MB/s; 150W+ op/s
其中堪藐，某些讀操作由于重復(fù)讀取磁盤(pán)并解壓縮以致耗時(shí)較長(zhǎng)。我們?yōu)閘eveldb提供足夠的緩存挑围，以便可以將未壓縮的塊保存在內(nèi)存中礁竞，則讀取性能再次提高：
readrandom : 9.775 micros/op; (approximately 100,000 reads per second before compaction)
readrandom : 5.215 micros/op; (approximately 190,000 reads per second after compaction)
對(duì)于典型的數(shù)據(jù)庫(kù)操作，基本為隨機(jī)讀杉辙、寫(xiě)模捂，整理下上述關(guān)鍵性能數(shù)據(jù)：
fillrandom : 2.460 micros/op; 45.0 MB/s; 40W+ OP/S
readrandom : 9.775 micros/op; (approximately 100,000 reads per second before compaction)
readrandom : 5.215 micros/op; (approximately 190,000 reads per second after compaction)
隨機(jī)寫(xiě)的性能大致為40W+ op/s，讀在數(shù)據(jù)壓縮完成后性能最佳為19W+ op/s蜘矢，運(yùn)行時(shí)的實(shí)時(shí)讀性能大約為10W+ op/s狂男。
1.4 總結(jié)
leveldb是一個(gè)鍵值數(shù)據(jù)庫(kù)，app嵌入該程序庫(kù)后可完成基于key的讀品腹、寫(xiě)操作岖食，其寫(xiě)操作性能極佳，甚至遠(yuǎn)高于讀性能舞吭。
leveldb總代碼9.6k泡垃，其中還包含了大量的測(cè)試程序，做為一個(gè)小巧的羡鸥，功能完備的鍵值數(shù)據(jù)庫(kù)蔑穴，非常具有研究?jī)r(jià)值。
leveldb內(nèi)部并未使用MVCC惧浴，而是使用了一種古老的LSM數(shù)據(jù)結(jié)構(gòu)存和。除此之外，還使用了skiplist簡(jiǎn)化處理邏輯衷旅，創(chuàng)建定制的內(nèi)存池提高程序性能捐腿，精巧的分層布局等等。
本系列文章將剖析leveldb設(shè)計(jì)柿顶、實(shí)現(xiàn)的各個(gè)細(xì)節(jié)茄袖，對(duì)其支持的各種特性、特別是性能優(yōu)化上做詳細(xì)分析九串。
本文基于leveldb 1.2版本分析绞佩。
注：本節(jié)大部分內(nèi)容來(lái)自leveldb git主頁(yè)(https://github.com/google/leveldb)。
轉(zhuǎn)載請(qǐng)注明：[隨安居士]http://www.reibang.com/p/9b5945cb6e70
