NoSQL產品測評：Cassandra、MongoDB、Couchbase和Aerospike

近日Thumbtack發佈了兩篇論文，分別為 超高性能NoSQL基準和 NoSQL容錯移轉特徵；前者是分析持久性和性能的權衡，後者則是關於Aerospike、Cassandra、 Couchbase和MongoDB幾個NoSQL的容錯移轉特徵。 兩個基準都嘗試測試「有高輸送量、低延時需求的面向使用者應用程式，這些應用程式的資料都可以使用鍵值形式進行存儲」。

Thumback使用的是YCSB（Yahoo! Cloud Serving Benchmark）的升級版，新的YCSB改變記錄在第一篇論文的文檔中。 在著眼新的基準測試之前我們首先看一下原YCSB上的一件趣事：

YCSB推出不久後（1年多以前），HyperDex使用這個基準對HyperDex、Redis和MongoDB幾個高效能資料庫進行測試，而得出的結果更是犀利無比 —— 輸送量秒殺風頭正勁的MongoDB與Cassandra， 趕超Redis。

為此有「熱心」的網友在Redis社區中發表了帖子 HyperDex vs. Redis，並得到了Redis之父Salvatore Sanfilippo大神「強有力」的回復：

事實並沒有聽起來那麼有趣，因為：

Redis和Memcached在單核心每秒查詢上具有或多或少的上限，Memcached允許自動的使用多核技術（這一點Redis在將來可能會實現），而使用Redis你需要多實例，並且這只能在網路伺服器中使用， 當然這些系統使用的都是記憶體處理形式，並且通過合理的優化。

我想說的是，我也可以修改Redis讓其返回的總是「foo」，從而達到單核心每秒15萬ops。 那麼真實情況應該是這樣的：

1. 基準E設計的非常粗糙，Redis並不支援，這樣的對比一點「營養」都沒有

2. 在所有其它的測試中，他們可能都是使用單核心Redis在對抗多核心HyperDex（或者是多節點HyperDex）。 舉個例子，Redis LPUSH每秒可以輕易的插入100萬個選項進入清單，然而如果你同時使用4個實例，每個核心每秒你可能都會得到3、4百萬寫操作。 然而這並不意味著我們需要在首頁上寫上「單核心每秒400萬次操作」！

3. 基準測試案例的資料集可能一直都儲存在記憶體中

4. 沒有公佈所有方法，這樣這個測試結果無任何價值

最後我認為，使用錯誤的引導去塑造產品同樣是不好的行為，前3個月可能會有所收穫，那麼之後會發生些什麼？

「任何企圖同時抓兩只兔子的人，最終將毫無收穫。 」

而之後Salvatore Sanfilippo更是對YCSB基準做出了如下的評論：

這是我在HackerNews上對這個基準YCSB發起的討論： 討論位址

根本上說YCSB在構造思路上犯了經典的錯誤，取代使用合適的用例來獲得不同資料庫的最佳性能，它使用一個層來給不同資料庫強制資料模型。 對於大多數的資料庫來說，使用的是本地資料模型，但是對於其它的（比如Redis）資料庫來說，只是在類比使用本地操作。

同樣這個基準對比的是單核心Redis和多核心Hyperdex之間的性能。

(責任編輯：蒙遺善)