近日， Christoph Rupp在highscalability.com上發(fā)表了一篇文章，介紹由他創(chuàng)建的分析型嵌入式鍵值數(shù)據(jù)庫hamsterdb。它用C/C++編寫，是一個速度非常快的輕量級NoSQL數(shù)據(jù)庫引擎，支持事務(wù)、數(shù)據(jù)庫游標(biāo)、內(nèi)存數(shù)據(jù)庫和遠(yuǎn)程網(wǎng)絡(luò)訪問，類似谷歌的leveldb和甲骨文的BerkeleyDB。

據(jù)作者介紹，hamsterdb并不是細(xì)分市場上的一個新晉競爭者。事實上，它已經(jīng)出現(xiàn)超過9年了。在這段時間里，它發(fā)展非常快，其重點已經(jīng)從單純的鍵值存儲轉(zhuǎn)向了分析型數(shù)據(jù)庫，提供類似列式存儲數(shù)據(jù)庫的功能。

hamsterdb是單線程、非分布式的，用戶通常直接將它鏈接到他們自己的應(yīng)用程序中。它提供了獨特的事務(wù)實現(xiàn)以及其它獨特的功能，非常適合于分析型工作負(fù)載。它可以在本地C/C++中使用，也有面向Erlang、Python、Java、 .NET，甚至是 Ada的綁定。它被用在嵌入式設(shè)備和本地應(yīng)用程序中，也可以為云實例提供緩存和索引服務(wù)，已經(jīng)有數(shù)以百萬計的部署。

hamsterdb有一個獨特的功能，它能識別模式信息。大多數(shù)鍵值存儲并不關(guān)心鍵的類型，而它支持兩種類型的鍵：二進(jìn)制鍵和數(shù)值鍵。hamsterdb數(shù)據(jù)庫是BTree索引，既可以存儲在文件中，也可以存儲在內(nèi)存中。而BTree的實現(xiàn)是它成為分析型數(shù)據(jù)庫的關(guān)鍵。其實現(xiàn)方式非常緊湊，減少了I/O，而且可以更好的利用CPU緩存。

另外，hamsterdb有與SQL命令COUNT、COUNT DISTINCT、SUM和AVERAGE等價的API，并支持可變長度的鍵，允許鍵重復(fù)，以及支持read-committed隔離級別的ACID事務(wù)。

按照Rupp的說法，hamsterdb最強(qiáng)力的特性是可測試性。數(shù)據(jù)庫的根本——甚至比性能都重要——就是不應(yīng)該丟失數(shù)據(jù)。在9年的開發(fā)過程中，他不斷地重寫部分代碼或者嘗試新的想法，但高測試覆蓋率給了他自信，認(rèn)為這些更改不會破壞任何東西。他有大約1800個單元測試和35000個驗收測試，以及一組模擬崩潰的測試，用于測試hamsterdb的可恢復(fù)性。這些測試都是高度自動化的。

Rupp還介紹了hamsterdb的商業(yè)版本hamsterdb pro。該版本提供了針對鍵、記錄、日志的重量級壓縮，AES加密，及針對葉節(jié)點查找的SIMD優(yōu)化。還有更多的壓縮算法正在進(jìn)行或規(guī)劃中。

在文章的最后，Rupp用谷歌的基準(zhǔn)測試將hamster 2.1.8與leveldb 1.15作了性能對比。他得出了下面的結(jié)論：

對于隨機(jī)讀，hamsterdb性能要好于leveldb。對于隨機(jī)寫的情況，只要數(shù)據(jù)量不是太大，hamsterdb就更快。而從1千萬鍵及以上開始，hamsterdb就會遭受BTree數(shù)據(jù)庫的傳統(tǒng)問題：大量的非序列性I/O和高磁盤尋道延遲。

作者認(rèn)為，這可以很好地說明hamsterdb的分析能力。尤其是，sum和count運算都可以很好地擴(kuò)展。序列性插入和掃描也是其亮點，不管數(shù)據(jù)量多大，它都可以非?？?。

有興趣的讀者可以下載查看全部的測試結(jié)果，以及從GitHub上下載hamsterdb的源代碼。