Key-Value數據庫實現Part 2：使用已有的K-V數據庫作模型

這篇文章中，我會解釋爲何在項目中使用已有的模型而不是徹底從零開始。我會列出一系列選擇K-V數據庫模型的標準。最後會概述並選擇一些廣爲人知且符合所列標準的K-V數據庫。文章將會主要涵蓋：

1. 不要重複造輪子
2. 可供參考的模型和選擇標準
3. 被選中數據庫的概要

1.不要重複造輪子

　　K-V數據庫已經存在至少30多年了[1]。其中最有記念意義的項目是DBM，是於1979年由Kenneth Tompson爲Unix version 7編寫的最初的數據庫管理軟件[2]。工程師們面對這有關這些數據庫的種種情形

和問題，對其設計和數據結構或接納或反對。他們已經經過實際生產中遇到的問題獲得了不少經驗，不顧這些前驅們的工做從零開始會顯得很蠢，那樣只會重複他們已經犯過的錯誤。

Gall定律，由John Gall提出[3]

 　　一個能正常工做的複雜系統永遠都是從一個能工做的簡單系統演化而來的。反之同樣成立：一個從零開始設計的複雜系統歷來不能正常工做也沒法調試到正常工做。你得推倒重來，從一個能工做的簡

單系統開始。

　　這段引用給個人K-V數據庫項目奠基了兩個基調：

　　1.使用模型。我須要找一些已經存在了一段時間的K-V數據庫項目，更理想的狀況是找一些成功的K-V數據庫的後續項目。由於這些項目一般設計得很牢固，並且在屢次的迭代開發過程當中不斷完善。這些

K-V數據庫將會被用做我本身項目的模型。

　　2.從小作起。項目的第一個版本應該小巧而簡單，這樣方便測試和驗證。若是須要改進和額外的功能則應該在後續的版本中添加。

 

2.候選模型和選擇標準

　　在K-V數據庫和NoSQL數據庫方面作了一點功課後，我決定在下列數據庫裏面作更全面的選擇：

• DBM
• Berkeley DB
• Kyoto Cabinet
• Memcached 和 MemcacheDB
• LevelDB
• MongoDB
• Redis
• OpenLDAP
• SQLite

　　個人選擇標準以下：

• 我想用面向對象編程的方法來實現一個K-V數據庫，因此須要從OOP語言編寫的數據庫中得到靈感。
• 對於底層的數據結構，我想基於硬盤上的hash table實現，因此候選者們須要提供對硬盤進行讀寫的方法。
• 數據庫須要支持網絡訪問
• 不須要查詢引擎或者結構化訪問數據
• 不須要支持完整的ACID規範
• 鑑於項目須要我獨自完成，我想找一些小團隊的實現，一兩我的的最好

3.最後敲定的K-V數據庫的概述

　　最後的三大贏家是Berkeley DB，Kyoto Cabinet和LevelDB。Berkeley DB和Kyoto Cabinet都是DBM的繼任項目。除此以外，這二者都不是初始版本，而是其做者的第N個版本了。這一般意味着他們

比其餘初次完成的項目更可靠。LevelDB年代更近，底層數據結構基於LSM Tree而不是hash table。可是他的代碼是我見過全部代碼中最乾淨的。上述三個項目都是一或兩我的開發的，下面是他們的詳細信

息。

Berkeley DB

　　該項目始於1986年，距離我寫這篇文章已有26年之久了。Berkeley DB是DBM的後續項目，底層由hash table實現。第一個版本由Margo Seltzer[22]和Ozan Yigit[23]實現，他們當時還在UCB。其後由

Oracle接手並繼續開發。

　　Berkeley DB最初用C語言實現，至今仍然純C語言開發。整個開發過程逐步推動，每一個主要版本會添加一些新特性。如今已經支持concurrency, transaction, recovery和replication[4]. Berkeley DB已經

普遍的用於部署中[5]，證實了其架構的高度可靠。關於其設計的更多信息能夠參考「Berkeley DB Programmer's Reference Guide」[6]以及「The Architecture of Open Source Applications, Volume 1」[5]

Kyoto Cabinet

　　Kyoto Cabinet於2009年由Mikio Hirabayashi[24]發佈，如今仍然活躍。這個項目是做者發佈的Tokyo Cabinet (2007)和QDBM (2003)的後續項目。QDBM曾做爲高性能DBM的後續實現[7].。Kyoto Cabinet

由於其純正的DBM血統和做者超過12年的K-V數據庫開發經驗而格外讓人感興趣。在實現這三個K-V數據庫的這麼多年中，做者必然對須要的數據結構有了紮實的理解，更不用說對於性能瓶頸所在的直覺。

　　Kyoto Cabinet用C++實現，並實現了hash table，B+ Tree和一些比較深奧的數據結構。其提供了至關出色的性能表現[16]。雖然如此，他彷佛仍是存在一些初始化參數致使的性能問題。正如不少人反饋的

那樣，當數據量小於一個跟bucket array大小成比例的閾值(其由建立數據庫文件的初始化參數肯定)時，性能很好沒有問題。一旦超過閾值，性能將會急劇降低[18][19]。一樣的問題也在Tokyo Cabinet[20][21]

中出現。這意味着使用這二者時，一旦項目的需求發生了變更，可能會致使很嚴重的後果。你們也都懂軟件領域中真正不變的東西到底有多少......

LevelDB

　　LevelDB是一個由谷歌員工Jeffrey Dean (譯者：這位強到不是人）)[8]和Sanjay Ghemawat[9]實現，他們都曾參與Google的Mythical Infrastructure項目：MapReduce和BigTable。鑑於這兩位在Google工

做時遇到的大規模問題的經驗，他們很大程度上是清楚本身在作什麼的。LevelDB不一樣於其餘K-V數據庫的頗有趣的一點是他沒有用hash table或者B-Tree作底層數據結構，而是基於Log-Structured Merge Tree[12]。

LSM據稱對SSD作了優化[13]。你能夠在High Scalability blog上找到一堆關於LevelDB的資料[17].

　　LevelDB發佈於2011年，基於C++實現，並被設計爲更高層存儲系統的基礎模塊[10]。Chrome將來版本中的IndexedDB HTML5 API將會使用LevelDB[10][11]。根據做者提供的測試[14],其性能表如今必定

的數據量如下是炸裂級別的。然而，另外一項由Acunu的Andy Twigg在商用SSD上作的測試代表，當數據量超過1M並朝着1B的級別發展時，性能會劇烈降低[15]。因此對於真正對數據規模有要求的後端項目來講，

LevelDB可能不是最好的選擇。

　　但其實這不是什麼大問題，由於對於我來講LevelDB最好的部分不在於他的性能而在於它的架構。看看源代碼中各個部分的組織方式以後，你就會理解什麼叫純粹的美。全部東西都那麼清楚，簡潔，合理。接

觸LevelDB的源碼並用他作模型是一個絕佳的寫出好代碼的機會。

剩下那些落選的K-V數據庫怎麼辦？

　　事實上我沒選他們不表明我會把他們徹底拋掉。我可能偶爾會用到他們架構中的一些元素。可是他們不會像選中的那三個數據庫同樣對個人項目產生很大的影響。

引用

[1] http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html
[2] http://en.wikipedia.org/wiki/Dbm
[3] http://en.wikipedia.org/wiki/Systemantics
[4] http://en.wikipedia.org/wiki/Berkeley_DB#Origin
[5] http://www.aosabook.org/en/bdb.html
[6] http://docs.oracle.com/cd/E17076_02/html/programmer_reference/intro.html
[7] http://fallabs.com/qdbm/
[8] http://research.google.com/people/jeff/
[9] http://research.google.com/pubs/SanjayGhemawat.html
[10] http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
[11] http://www.w3.org/TR/IndexedDB/
[12] http://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/
[13] http://www.acunu.com/2/post/2011/04/log-file-systems-and-ssds-made-for-each-other.html
[14] http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
[15] http://www.acunu.com/2/post/2011/08/benchmarking-leveldb.html
[16] http://blog.creapptives.com/post/8330476086/leveldb-vs-kyoto-cabinet-my-findings
[17] http://highscalability.com/blog/2011/8/10/leveldb-fast-and-lightweight-keyvalue-database-from-the-auth.html
[18] http://stackoverflow.com/questions/13054852/kyoto-cabinet-berkeley-db-hash-table-size-limitations
[19] https://groups.google.com/forum/#!topic/tokyocabinet-users/Bzp4fLbmcDw/discussion
[20] http://stackoverflow.com/questions/1051847/why-does-tokyo-tyrant-slow-down-exponentially-even-after-adjusting-bnum
[21] https://groups.google.com/forum/#!topic/tokyocabinet-users/1E06DFQM8mI/discussion
[22] http://www.eecs.harvard.edu/margo/
[23] http://www.cse.yorku.ca/~oz/
[24] http://fallabs.com/mikio/profile.html