實現(xiàn)一個開源KV數(shù)據(jù)庫的想法來源于對目前項目中所使用的K-V數(shù)據(jù)庫使用情況的不滿意。
先介紹一下我們的目前項目，作為本文的背景：
較為底層的分布式運行平臺，使用C/C++實現(xiàn)的Actor模型（異步消息傳遞系統(tǒng)）
數(shù)據(jù)schema簡單靈活，使用key-value能夠很好表示。
數(shù)據(jù)庫有大量的讀寫請求，有事務(wù)需求，數(shù)據(jù)丟失容忍度很低。
當(dāng)前，從眾多的KV和NOSQL存儲產(chǎn)品中，我們使用了Berkeley DB作為底層的存儲引擎。
為什么選擇BDB呢？
1.與傳統(tǒng)的RDBMS相比，簡單K-V存儲的Berkeley DB（再加入“嵌入式”直接庫鏈接的特性）有著優(yōu)越的性能，容易滿足我們大量讀寫（尤其是大量寫）的需求。
2.作為一個嵌入式的K-V數(shù)據(jù)庫，Berkeley DB歷史悠久（目前由Oracle所有），穩(wěn)定且久經(jīng)考驗，文檔豐富，輔助工具全面。這是我們之所以在眾多的開源K-V(Nosql)數(shù)據(jù)庫中選擇BDB的首要原因：靠譜。
3.第三個選擇BDB的原因是事務(wù)支持：作為為數(shù)不多的能夠提供ACID事務(wù)支持的K-V數(shù)據(jù)庫，BDB對事務(wù)支持提供了豐富的支持：從不同的隔離級別、不同的持久化保證以及分布式事務(wù)2PC的prepare模型等，可配置程度很高。
BDB哪些方面不能達(dá)到我們的需求？
1.仍然是性能。作為K-V數(shù)據(jù)庫，BDB的性能依然達(dá)不到我們的目標(biāo)：由于有足夠大的內(nèi)存作為緩存，讀操作的性能基本沒問題，但寫操作（尤其是大量應(yīng)用的事務(wù)寫）的性能堪憂。
使用Auto-commit（每條寫作為一個獨立的事務(wù)），一條記錄的寫延時接近于1~10ms。
顯示開啟事務(wù)后，寫操作有了極大改善：10~100us（因為不需要即時sync到硬盤），但事務(wù)提交操作依然極為耗時。
有人可能會說，你可以調(diào)節(jié)BDB事務(wù)的持久化保證的程度，比如在提交時設(shè)置：
DB_TXN_WRITE_NO_SYNC，在提交時只寫log到硬盤，不sync（只有OS Crash才會丟數(shù)據(jù)）
或者更快一些，使用DB_TXN_NOSYNC，連同步調(diào)syscall write的開銷都省下來（但App crash可能會丟數(shù)據(jù)）