發布一個參考ssdb，使用go類似的實現redis高效能nosql：ledisdb

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

起因

ledisdb是一個參考ssdb。採用go實現，底層基於leveldb，相似redis的高效能nosql資料庫，提供了kv，list，hash以及zset資料結構的支援。

我們如今的應用極大的依賴redis。但隨著我們使用者量越來越大，redis的記憶體越來越不夠用。而且replication可能還會導致逾時問題。

儘管興許我們能夠通過加入多台機器來解決。可是在現有機器配置以下。我們仍希望單台機器承載很多其它的使用者。另外，由於業務的特性，我們事實上並不須要將全部的資料放到記憶體。僅僅須要存放當前活躍使用者。

經過我們的調研，發現ssdb已經非常好的幫我們攻克了這個問題，它提供了跟redis一致的介面（當然有些地方還是略微不同）。可是底層採用leveldb進行儲存。

依據其官網的描寫敘述。效能已經接近甚至超越了redis。

本著造輪子的精神。我決定用go實現一個相似的db。取名為ledisdb。也就是level-redis-db，為啥不用現成的ssdb，我覺得有例如以下幾個原因：

• go語言開發的高速。這點毋庸置疑，儘管效能上面鐵定離c++的代碼有差距。可是我能夠高速的進行原型搭建並實驗。實際上，我在非常短的時間裡面就開發出了ledisdb。讓我興許繼續開發有了信心。

• leveldb的研究。我一直非常想將leveldb應用到我們的項目中，作為本機熱點資料的首選資料存放區方式。通過ledisdb，讓我對leveldb的使用有了非常多經驗。
• redis的熟悉，儘管我用了非常久的redis，可是非常多redis的命令仍然須要去查手冊。通過實現ledisdb，我更加熟悉了redis的命令，同一時候，由於要瞭解這個命令redis怎樣實現。對redis內部又又一次來了一次剖析。

在準備開發ledisdb的時候。我就在思索一個問題，我需不須要開發還有一個redis？事實上這是一個非常明白的問題，我不須要還有一個redis。

ledisdb儘管參考了redis，但為了實現簡單，有時候我做了非常多減法或者變更，譬如對於zset這樣的資料結構，我就僅僅支援int64類型的score。而redis的score是double類型的，詳細原因興許解說zset的時候詳細說明。

所以，我們能夠覺得，ledisdb是一個基於redis通訊協定，提供了多種進階資料結構的nosql資料庫。它並非還有一個redis。

編譯安裝

由於ledisdb是用go寫的，所以首先須要安裝go以及配置GOROOT，GOPATH。

mkdir $WORKSPACEcd $WORKSPACEgit clone git@github.com:siddontang/ledisdb.git src/github.com/siddontang/ledisdbcd src/github.com/siddontang/ledisdb#構建leveldb。假設已經安裝了，可忽略./build_leveldb.sh  #安裝ledisdb go依賴. ./bootstap.sh     #配置GOPATH等環境變數. ./dev.sh          go install ./... 

詳細的安裝說明，能夠查看代碼檔案夾以下的readme。

Example

使用ledisdb非常easy。僅僅須要執行：

./ledis-server -config=/etc/ledis.json

ledisdb的設定檔採用json格式。為啥選用json。我在使用json作為基本的配置格式裡面有過說明。

我們能夠使用不論什麼redisclient串連ledisdb，譬如redis-cli，例如以下：

127.0.0.1:6380> set a 1OK127.0.0.1:6380> get a"1"127.0.0.1:6380> incr a(integer) 2127.0.0.1:6380> mset b 2 c 3OK127.0.0.1:6380> mget a b c1) "2"2) "2"3) "3"

leveldb

由於leveldb是c++寫的，所以在go裡面須要使用，cgo是一種非常好的方式。

這裡，我直接使用了levigo這個庫。並在上面進行了封裝。詳見這裡。儘管有一個go-leveldb，無奈仍不能用。

cgo的效能開銷還是有的，這點在我做benchmark的時候就明顯感覺出來。只是興許最佳化的空間非常大。譬如將多個leveldb的調用邏輯該用c重寫。這樣僅僅須要一次cgo就能夠了。只是這個興許在考慮。

leveldb的一些參數在構建編譯的時候是須要調整的，這點我沒啥經驗，僅僅能google和參考ssdb。

譬如以下這幾個：

+ db/dbformat.h// static const int kL0_SlowdownWritesTrigger = 8;static const int kL0_SlowdownWritesTrigger = 16;// static const int kL0_StopWritesTrigger = 12;static const int kL0_StopWritesTrigger = 64;+ db/version_set.cc//static const int kTargetFileSize = 2 * 1048576;static const int kTargetFileSize = 32 * 1048576;//static const int64_t kMaxGrandParentOverlapBytes = 10 * kTargetFileSize;static const int64_t kMaxGrandParentOverlapBytes = 20 * kTargetFileSize;

相關參數的調優，僅僅能等我興許深入研究leveldb了在好好考慮。

效能測試

不論什麼一個服務端服務沒有效能測試報告那就是耍流氓。我如今僅僅是簡單的用了redis_benchmark進行測試，測試環境為一台快兩年的老爺mac air機器。

測試語句：

redis-benchmark -n 10000 -t set,incr,get,lpush,lpop,lrange,mset -q

redis-benchmark預設沒有hash以及zset的測試。興許我在自己加入。

leveldb配置：

compression       = falseblock_size        = 32KBwrite_buffer_size = 64MBcache_size        = 500MB

redis

SET: 42735.04 requests per secondGET: 45871.56 requests per secondINCR: 45248.87 requests per secondLPUSH: 45045.04 requests per secondLPOP: 43103.45 requests per secondLPUSH (needed to benchmark LRANGE): 44843.05 requests per secondLRANGE_100 (first 100 elements): 14727.54 requests per secondLRANGE_300 (first 300 elements): 6915.63 requests per secondLRANGE_500 (first 450 elements): 5042.86 requests per secondLRANGE_600 (first 600 elements): 3960.40 requests per secondMSET (10 keys): 33003.30 requests per second

ssdb

SET: 35971.22 requests per secondGET: 47393.37 requests per secondINCR: 36630.04 requests per secondLPUSH: 37174.72 requests per secondLPOP: 38167.94 requests per secondLPUSH (needed to benchmark LRANGE): 37593.98 requests per secondLRANGE_100 (first 100 elements): 905.55 requests per secondLRANGE_300 (first 300 elements): 327.78 requests per secondLRANGE_500 (first 450 elements): 222.36 requests per secondLRANGE_600 (first 600 elements): 165.30 requests per secondMSET (10 keys): 33112.59 requests per second

ledisdb

SET: 38759.69 requests per secondGET: 40160.64 requests per secondINCR: 36101.08 requests per secondLPUSH: 33003.30 requests per secondLPOP: 27624.31 requests per secondLPUSH (needed to benchmark LRANGE): 32894.74 requests per secondLRANGE_100 (first 100 elements): 7352.94 requests per secondLRANGE_300 (first 300 elements): 2867.79 requests per secondLRANGE_500 (first 450 elements): 1778.41 requests per secondLRANGE_600 (first 600 elements): 1590.33 requests per secondMSET (10 keys): 21881.84 requests per second

能夠看到，ledisdb的效能趕redis以及ssdb還是有差距的，但也不至於不可用。有些區別並不大。至於為啥lrange比ssdb高，我比較困惑。

興許的測試報告，我會不斷在benchmark檔案中面更新。

Todo。。

。

。。

。

ledisdb還是一個非常新的項目，比起ssdb已經在生產環境中用了非常久，還有非常多路要走，還有一些重要的功能須要實現，譬如replication等。

歡迎有興趣的童鞋一起參與進來，在漫漫程式開發路上有一些好基友可是非常幸運的。

著作權聲明：本文博主原創文章，部落格，未經同意不得轉載。