SSDB 是一個 C++ 開發的 NoSQL 存儲服務器, 支持 zset, map 數據結構, 可替代 Redis, 特別適合存儲集合數據. SSDB 被開發和開源出來後, 已經在生產環境經受了3個季度的考驗, 一直穩定運行.
在一個支撐數千萬用戶的列表數據(例如用戶的訂單歷史, 用戶的好友列表, 用戶的消息列表等)的實例上, SSDB 每天處理上億個讀寫請求, 仍然能保持 CPU 佔用在3%左右, 內存佔用爲 1G. 這種數據規模是我們原來使用的 Redis 所無法滿足的, 因爲 Redis 無法保存如此大量的數據, 物理內存的容量限制了 Redis 的能力. 根據我們的經驗, Redis在10G數據規模時比較適用, 數據規模再擴大時, Redis 就非常吃力, 而且幾乎無法擴展. 這時, 必須改用 SSDB.
SSDB 具有和 Redis 高度重合的 API, 而且對於 hash(map) 還是可分段遍歷的, 相比較, Redis 只能通過 hgetall 一次遍歷 hash 中的所有元素, 在大的 hash 中, 這個操作非常低效.
如果要列出幾條必須放棄 Redis, 改爲使用 SSDB 的觀點, 我相信這幾條非常有吸引力:
- 單個實例的存儲容量相當於 100 個 Redis 實例!
- 內存佔用只有 Redis 的一千分之一(最大設計容量時).
- 所有的數據集合(包括 KV)都是可分段(分頁)遍歷的.
- 特別適合存儲列表等集合數據.
案例分析：
在一個網站廣告系統中, 需要針對每一個用戶所接受的彈窗次數和點擊次數這兩個重要指標進行統計, 從而進行效果分析和精準投放的改進. 這兩個指標的統計算法其實非常簡單, 主要的難點在於大數據量. 廣告系統的涉及的用戶量達到數千萬人, 每天的日誌數據量是幾億條.
最開始的想法是使用 MySQL 數據庫, 不過這個方案馬上就被否, 因爲如此大量數據已經遠遠超過 MySQL 的存儲能力, 必定帶來許多無謂的問題.
第二個方案是使用 Redis. Redis 是內存存儲方案, 速度快, 而且 zset 數據結果存儲列表數據非常方便, 能直接地統計用戶的彈窗次數和點擊次數. 不過, Redis 本身的侷限就是它最多能存儲不超過內存容量的數據, 對於一臺 100G 內存的服務器, Redis 最好是存儲不超過 30G 的數據量. 因此, Redis 的方案在運行了短時間之後也被否定了.
第三個方案是使用 SSDB. SSDB 可以存儲 TB(1000GB) 級別的數據, 並且支持列表等集合數據結構, 有着和 Redis 高度兼容的 API, 所以, 當從 Redis 遷移到 SSDB 時, 改動非常小.
每一個用戶的彈窗歷史用一個 zset 來存儲, key 是時間戳, 對應的 score 也是時間戳, 因爲我們只關心用戶的彈窗歷史, 具體的彈窗信息會用 map 來存儲(時間戳作爲 key, 對應彈窗信息 value). SSDB 的 zset 支持根據 score 範圍來查詢, 所以只需要一條命令就能算出用戶在任意時間段內的彈窗次數.
用戶的點擊統計也是類似.
