SSDB: Redis 的替代？

SSDB 360 的 ideawu開發的 NOSQL 數據庫，其底層存儲引擎基於 LevelDB 實現，接口支持相似於 Redis，徹底兼容 Redis 的協議，支持 list, has, zset 等數據結構。

與 Redis 相比較，SSDB 利用持久化設備存儲，避免了純內存數據庫的容量問題，與 LevelDB 的關係是 SSDB 利用了 LevelDB 的高性能存儲實現，爲其實現了網絡和多數據結構支持。除此以外，多節點的主備、主主也是亮點之一。

以前做者就使用了 SSDB 存儲一些對數據一致性和持久性不是很敏感的監控數據，在「盲使用」(純粹瞭解接口)的狀況下，SSDB 仍是跑的很是順利的而且無痛點的。因爲其餘業務一樣須要一個持久化的高性能隊列、鍵值服務，所以最近簡單調研了一下 SSDB 實現和文檔，由於對 LevelDB 實現很是熟悉，所以關注點主要放在持久化和數據分發上，感受 SSDB 的缺陷仍是很明顯的。

Contents [hide]

• 單機持久化
• 多節點分發
• 隨機操做性能
• 小結

單機持久化

SSDB 利用 LevelDB 做爲存儲引擎，全部的接口實現上利用了 LevelDB 的 Get, Put 和 Iterator 操做，可是 LevelDB 的默認接口是緩存的，換句話說 LevelDB 的 Write 接口在實現上僅僅調用了 fwrite 系統接口寫入了日誌，可是並不會 sync 日誌文件，所以日誌文件的數據仍處於 Page Cache 中。LevelDB 的目的是上層須要根據業務狀況傳遞給 LevelDB 的句柄須要帶上 「sync=true」，以事務的方式去 sync 以前的操做。而 SSDB 由於提供的是 Redis 的接口，並不提供事務的接口，所以全部的寫操做都不可能去使用同步寫的方式，LevelDB 對於同步寫的實現實際上不太好，性能會比較低。

爲了驗證 SSDB 的持久性，經過啓動一臺 VM 運行 ssdb-server，而後不斷寫入數據，在中間 kill 這臺 VM。重啓 VM 後發現只持久化存儲了 500 個鍵值，而在客戶端側已經獲得了 7W 個成功存儲鍵值的迴應。

多節點分發

一樣考慮到 SSDB 支持多節點分發的特性，若是多臺 SSDB 服務器可以同步在內存中寫入，那麼持久性仍是能大大提升。簡單的瀏覽了 SSDB 的實現，發現主備或者是主主的模式下，客戶端的寫入操做僅僅在目標節點緩存，而分發到其餘複製節點的操做是異步的，也就是說寫操做會被塞入一個隊列中，一個分發線程會間隔將這些寫操做分發到其餘節點。那麼顯然在客戶端收到迴應後是可能存在一段時間發出的數據是並無被複制節點收到的，這使得在目標節點崩潰後，數據存在丟失的潛在可能。

隨機操做性能

LevelDB 是一個對於順序讀寫很是友好的數據庫實現，可是對於隨機讀的性能會比較糟糕。所以，SSDB 在面向隨機的鍵值讀取上會比較糟糕，它更適合一些批量讀寫操做，如監控數據的存儲，時間序列數據等等。

小結

總而言之，SSDB 是一款不錯的 NOSQL 數據庫實現，其豐富的接口和友好的使用對於特定使用場景很是不錯，可是由於持久性和存儲引擎自然的劣勢狀況下，並不適合對於持久性要求高或者隨機操做頻繁的業務。至於替代 Redis 的狀況，在多節點狀況下，Redis 的持久性更加好，而 Redis 的高性能更是 SSDB 沒法達到的，SSDB 替代 Redis 的場景應該不會太多。推薦將 SSDB 用於監控應用、非持久消息隊列和順序操做的緩存服務，也就是允許數據丟失或者陰影讀(shadow read)。