實(shí)現(xiàn)一個開源KV數(shù)據(jù)庫的想法來源于對目前項(xiàng)目中所使用的K-V數(shù)據(jù)庫使用情況的不滿意。

先介紹一下我們的目前項(xiàng)目，作為本文的背景：

較為底層的分布式運(yùn)行平臺，使用C/C++實(shí)現(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)考驗(yàn)，文檔豐富，輔助工具全面。這是我們之所以在眾多的開源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（每條寫作為一個獨(dú)立的事務(wù)），一條記錄的寫延時接近于1~10ms。

顯示開啟事務(wù)后，寫操作有了極大改善：10~100us（因?yàn)椴恍枰磿rsync到硬盤），但事務(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ù)）

我們當(dāng)前的項(xiàng)目是一個底層的運(yùn)行時平臺，對數(shù)據(jù)丟失的敏感程度是很高的，不像一些常見的互聯(lián)網(wǎng)應(yīng)用。我們既需要事務(wù)的Durability支持，也需要高的寫性能。

2.我們的數(shù)據(jù)模型相對簡單：Key-Value存儲，需要事務(wù)的Atomicity支持批量修改，需要事務(wù)的Durability保證，可能需要Prepare語義支持分布式事務(wù)。

不需要對數(shù)據(jù)庫訪問的并發(fā)支持。當(dāng)前核心系統(tǒng)是一個基于線程池的異步系統(tǒng)，數(shù)據(jù)庫的寫操作和提交操作應(yīng)該由獨(dú)立線程來完成，不應(yīng)阻塞有限的池中線程。因此我們可以不需要并發(fā)支持而使用單獨(dú)線程操作數(shù)據(jù)庫。

至于事務(wù)的Consistency和Isolation以及各種復(fù)雜的鎖協(xié)議（尤其是BDB中惱人的page級別的鎖粒度），在不需要并發(fā)訪問的數(shù)據(jù)庫中也不需要。

這樣的需求，或許通過詳細(xì)的配置和tuning也能在BDB上實(shí)現(xiàn)，但BDB畢竟太大太復(fù)雜（一方面BDB為了通用的需求，實(shí)現(xiàn)復(fù)雜，難以了解內(nèi)部機(jī)理；一方面是配置復(fù)雜），以至于步履蹣跚。

與其繼續(xù)鉆研BDB的各種配置來適配當(dāng)前特殊的需求，不如輕裝上陣，自己實(shí)現(xiàn)一個項(xiàng)目特定的底端存儲，由于目標(biāo)和需求少兒明確，實(shí)現(xiàn)起來要簡單很多，預(yù)期能夠獲得比BDB更高的性能。

?

這個數(shù)據(jù)庫暫時取名為Simple DB，其主要需求和大致實(shí)現(xiàn)如下：

1.Key-Value存儲，使用Hash實(shí)現(xiàn)（可能需要使用linear hash)，不采用實(shí)現(xiàn)較為復(fù)雜的B+樹

2.嵌入式，通過鏈接方式直接使用，不適用其他IPC。只考慮Linux 2.6平臺，暫不考慮其他平臺。

3.主要支持get/set/traverse操作

（如果支持delete操作，也不會釋放或重新利用文件空間：重利用釋放的空間向來是一個復(fù)雜的問題，既要保證效率，又要避免碎片。最多提供一個database compress工具進(jìn)行文件的壓縮處理。）

4.每個數(shù)據(jù)庫包括：數(shù)據(jù)文件，索引文件和日志文件，不支持并發(fā)訪問。

5.支持事務(wù)，但只提供Atomicity和Durability語義。（使用write-ahead logging）

支持跨同一目錄下多個數(shù)據(jù)庫的事務(wù)，可能會提供事務(wù)的prepare語義。

6.暫不考慮replication支持，不支持shading（由應(yīng)用層自行完成）

?

希望數(shù)據(jù)庫如其名，簡單高效。

Keep it simple, stupid!

?

轉(zhuǎn)載于:https://www.cnblogs.com/promise6522/archive/2012/01/12/2321080.html

總結(jié)

以上是生活随笔為你收集整理的计划实现一个开源的KV数据库——Simple DB的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。