一、概述
Reveldb 是個人在空余時間和周末完成(應該說還遠遠未完善)的一個基於 google leveldb 的 NoSQL 數據服務器，網絡連接采用了 libevent 的 HTTP 接口，因此 reveldb 天生就適合處理 HTTP 請求。但更確切地說，reveldb 並沒有直接采用 libevent 的 HTTP 接口，而是使用了另外一個基於 libevent 的網絡連接庫 libevhtp(https://github.com/ellzey/libevhtp)，並對它做了適當的修改，使之成為 reveldb 的底層組件 evhttpx(https://github.com/forhappy/reveldb/tree/master/src/evhttpx), evhttpx 為 reveldb 提供了 HTTP 和 HTTPS 支持，因此，reveldb 除了能夠處理 HTTP 請求外，也能夠處理 HTTPS 請求，這一特性是 Kyoto Tycoon 沒有的，如果它有，請您告訴我 :-)
Kyoto Tycoon（以下簡稱KT）是Tokyo Tyrant 的作者Mikio Hirabayashi 的系列作品之一，KT 是一個數據庫網絡層服務。Reveldb 定位與 KT 類似，也是一個數據庫網絡層的服務，具體一點就是 Leveldb 的網絡層接口(因為 leveldb 本身只是一個程序庫，並沒有服務器/客戶端的概念)，reveldb 封裝了 leveldb 的絕大部分操作，如 Snapshot, Writebatch, Iterator 等等，並且在此基礎之上擴展了很多命令，比如 string 的 append, prepend, insert，Key-Value 的 mset, mget, mdel, seize, mseize，此外還有 range query, 基於編輯距離的查找，正則式 regex 匹配查找；同時還提供了一些數據庫管理的命令，如compact, repair, destroy 等；另外，reveldb 支持打開多個數據庫，底層使用了紅黑樹緩存各個客戶端已經打開的 leveldb 實例。
Reveldb 同時支持 HTTP RPC 和 REST 訪問方式(其中 REST 還未完成)，HTTP RPC 命令現在已經基本可用，文檔見：GITHUB。Reveldb 支持多線程，加上 libevent 本身在網絡處理方面的高性能以及 leveldb 在存儲方面的速度，所以 reveldb 在性能上也有相當很好的表現，本文將之前做的測試進行一個簡單的總結。
二、測試准備
測試工作是一台相當老（可以追溯至 2007 年 12 月份）配置比較低的筆記本上進行的，具體配置如下：
| 硬件環境 | 軟件環境 | ||
| CPU | Intel Core Duo CPU T5250 1.5GHz | 操作系統 | Ubuntu 12.04 |
| 內存容量 | 2 GB | 內核版本 | Linux 3.2.0-35-generic-pae |
| 硬盤容量 | 160 GB | GCC 版本 | 4.6.3 |
另外，測試對象如下，Reveldb 版本：5124b1, Kyoto Tycoon：0.9.56，Tyoto Cabinet： 1.2.76。
三、測試步驟
- 准備測試數據，使用 cpy-leveldb(個人寫的 leveldb 的 python 綁定)生成800萬條 Key-Value 對
-
import leveldb db = leveldb.LevelDB("/tmp/reveldb/default") batch = leveldb.WriteBatch(); for i in xrange(1000): batch.Put(str(i), "%d%d%d%d%d hello, hello, hello string %s" %(i, i, i, i, i, i)) db.Write(batch)
- 使用 kchashtest 也同樣生成800萬條測試數據。
- 使用 ab 進行測試，測試包括了 get, set 等命令，每組參數測試 5 次，取平均結果，如。
- Kyoto Tycoon測試: ab -n 10000 -c 30 http:127.0.0.1:1978/rpc/get?key=12345
- Reveldb 測試: ab -n 10000 -c 30 http:127.0.0.1:8088/rpc/get?key=12345
- 即測試參數為-c 30 (30個並發) 和 -n 10000(請求10000次)，測試5次，然后取平均結果作為最終的結果。
- 測試指標選取為“測試總時長”，“每秒的請求數目”，“每秒數據傳輸率”
四、測試結果
請求10000次，並發數從 50 開始，每次遞增 50，直到並發達到1000，測試結果如下：
五、測試總結
可以看出，reveldb 的性能和穩定性遠遠好於 Kyoto Tycoon，在較小的並發請求的情況下，比如 30 個並發請求，reveldb 完成 10000 次請求用時耗時1.126秒，每秒完成的請求數為 8882個，Kyoto Tycoon 耗時2.307秒，每秒完成的請求數為4334個，此時 reveldb 的性能是 Kyoto Tycoon 的兩倍；而當並發增大時，比如當並發達到 1000 時，reveldb 完成 10000 次請求用時耗時 1.296 秒，每秒完成的請求數為 7716 個，Kyoto Tycoon 耗時 6.167 秒，每秒完成的請求數才1641 個，此時 reveldb 的性能接近 Kyoto Tycoon 的五倍(4.7倍)；
所以，當並發請求變大時，reveldb 依然能夠很好的處理大量的並發請求並且性能下降很小，而 Kyoto Tycoon 的在大並發的情況下性能下降地比較快( 每秒完成的請求數從 4334 下降為 1641，下降了 62.14%)；在測試中發現的另外一個問題是 Kyoto Tycoon 的穩定性似乎並不好，在不同的並發下測試性能抖動厲害，而 reveldb 在不同程度的並發條件下依然表現穩定，雖然性能也會下降，但是下降地幅度遠遠小於 Kyoto Tycoon(從並發 30 的情況下每秒完成的請求數從 8882 下降到並發 1000 的 7716，下降 13.13%)。
六、存在的問題
Reveldb 目前雖然已完成了基本功能，但還遠遠不夠，仍然還有很大的進步空間，下一步將完善 reveldb 的 REST 接口，優化代碼，提升性能，支持備份(Master-Master 和 Master-Slave)，支持集群(可能會采用 Zookeeper)，完善文檔以及相應的工具和客戶端 API。
如果你希望和我一起完善 Reveldb，就在 GitHub 上面 Fork 一下吧，歡迎提交 Patch :-)