實現一個開源KV數據庫的想法來源於對目前項目中所使用的K-V數據庫使用情況的不滿意。
先介紹一下我們的目前項目，作為本文的背景：
較為底層的分布式運行平台，使用C/C++實現的Actor模型（異步消息傳遞系統）
數據schema簡單靈活，使用key-value能夠很好表示。
數據庫有大量的讀寫請求，有事務需求，數據丟失容忍度很低。
當前，從眾多的KV和NOSQL存儲產品中，我們使用了Berkeley DB作為底層的存儲引擎。
為什么選擇BDB呢？
1.與傳統的RDBMS相比，簡單K-V存儲的Berkeley DB（再加入“嵌入式”直接庫鏈接的特性）有着優越的性能，容易滿足我們大量讀寫（尤其是大量寫）的需求。
2.作為一個嵌入式的K-V數據庫，Berkeley DB歷史悠久（目前由Oracle所有），穩定且久經考驗，文檔豐富，輔助工具全面。這是我們之所以在眾多的開源K-V(Nosql)數據庫中選擇BDB的首要原因：靠譜。
3.第三個選擇BDB的原因是事務支持：作為為數不多的能夠提供ACID事務支持的K-V數據庫，BDB對事務支持提供了豐富的支持：從不同的隔離級別、不同的持久化保證以及分布式事務2PC的prepare模型等，可配置程度很高。
BDB哪些方面不能達到我們的需求？
1.仍然是性能。作為K-V數據庫，BDB的性能依然達不到我們的目標：由於有足夠大的內存作為緩存，讀操作的性能基本沒問題，但寫操作（尤其是大量應用的事務寫）的性能堪憂。
使用Auto-commit（每條寫作為一個獨立的事務），一條記錄的寫延時接近於1~10ms。
顯示開啟事務后，寫操作有了極大改善：10~100us（因為不需要即時sync到硬盤），但事務提交操作依然極為耗時。
有人可能會說，你可以調節BDB事務的持久化保證的程度，比如在提交時設置：
DB_TXN_WRITE_NO_SYNC，在提交時只寫log到硬盤，不sync（只有OS Crash才會丟數據）
或者更快一些，使用DB_TXN_NOSYNC，連同步調syscall write的開銷都省下來（但App crash可能會丟數據）
我們當前的項目是一個底層的運行時平台，對數據丟失的敏感程度是很高的，不像一些常見的互聯網應用。我們既需要事務的Durability支持，也需要高的寫性能。
2.我們的數據模型相對簡單：Key-Value存儲，需要事務的Atomicity支持批量修改，需要事務的Durability保證，可能需要Prepare語義支持分布式事務。
不需要對數據庫訪問的並發支持。當前核心系統是一個基於線程池的異步系統，數據庫的寫操作和提交操作應該由獨立線程來完成，不應阻塞有限的池中線程。因此我們可以不需要並發支持而使用單獨線程操作數據庫。
至於事務的Consistency和Isolation以及各種復雜的鎖協議（尤其是BDB中惱人的page級別的鎖粒度），在不需要並發訪問的數據庫中也不需要。
這樣的需求，或許通過詳細的配置和tuning也能在BDB上實現，但BDB畢竟太大太復雜（一方面BDB為了通用的需求，實現復雜，難以了解內部機理；一方面是配置復雜），以至於步履蹣跚。
與其繼續鑽研BDB的各種配置來適配當前特殊的需求，不如輕裝上陣，自己實現一個項目特定的底端存儲，由於目標和需求少兒明確，實現起來要簡單很多，預期能夠獲得比BDB更高的性能。
這個數據庫暫時取名為Simple DB，其主要需求和大致實現如下：
1.Key-Value存儲，使用Hash實現（可能需要使用linear hash)，不采用實現較為復雜的B+樹
2.嵌入式，通過鏈接方式直接使用，不適用其他IPC。只考慮Linux 2.6平台，暫不考慮其他平台。
3.主要支持get/set/traverse操作
（如果支持delete操作，也不會釋放或重新利用文件空間：重利用釋放的空間向來是一個復雜的問題，既要保證效率，又要避免碎片。最多提供一個database compress工具進行文件的壓縮處理。）
4.每個數據庫包括：數據文件，索引文件和日志文件，不支持並發訪問。
5.支持事務，但只提供Atomicity和Durability語義。（使用write-ahead logging）
支持跨同一目錄下多個數據庫的事務，可能會提供事務的prepare語義。
6.暫不考慮replication支持，不支持shading（由應用層自行完成）
希望數據庫如其名，簡單高效。
Keep it simple, stupid!