Reveldb 與 Kyoto Tycoon 性能對比(一)

1、概述

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 在性能上也有至關很好的表現，本文將以前作的測試進行一個簡單的總結。

2、測試準備

 測試工做是一臺至關老（能夠追溯至 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。

3、測試步驟

• 準備測試數據，使用 cpy-leveldb(我的寫的 leveldb 的 python 綁定)生成800萬條 Key-Value 對

1. 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次，而後取平均結果做爲最終的結果。
• 測試指標選取爲「測試總時長」，「每秒的請求數目」，「每秒數據傳輸率」

4、測試結果

請求10000次，併發數從 50 開始，每次遞增 50，直到併發達到1000，測試結果以下：

 

 

5、測試總結

能夠看出，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%)。

6、存在的問題

Reveldb 目前雖然已完成了基本功能，但還遠遠不夠，仍然還有很大的進步空間，下一步將完善 reveldb 的 REST 接口，優化代碼，提高性能，支持備份(Master-Master 和 Master-Slave)，支持集羣(可能會採用 Zookeeper)，完善文檔以及相應的工具和客戶端 API。

若是你但願和我一塊兒完善 Reveldb，就在 GitHub 上面 Fork 一下吧，歡迎提交 Patch :-)