NoSQL基準(zhǔn)對(duì)比Aerospike、Cassandra、Couchbase和MongoDB

lemoncandy

為了查看Aerospike、Cassandra、Couchbase和MongoDB這些數(shù)據(jù)庫(kù)在處理插入吞吐量、最大吞吐量時(shí)的表現(xiàn)以及故障恢復(fù)期間的延遲時(shí)間和行為，最近的一個(gè)基準(zhǔn)集合對(duì)這些數(shù)據(jù)庫(kù)做了比較。
Thumbtack Technology發(fā)布了兩個(gè)基準(zhǔn)白皮書(shū)，其中包含了一些鍵—值存儲(chǔ)的比較結(jié)果：超高性能 NoSQL基準(zhǔn): 分析持久性和性能權(quán)衡 (PDF) 和 NoSQL故障恢復(fù)特性: Aerospike、Cassandra、Couchbase和MongoDB (PDF)。這兩個(gè)基準(zhǔn)都試圖檢測(cè)“直面客戶(hù)的應(yīng)用程序，它們需要非常高的吞吐量和低延遲時(shí)間，同時(shí)其信息又能夠使用鍵-值模式表示”。
Thumbtack使用了一個(gè)改善版本的Yahoo! 云服務(wù)基準(zhǔn) (YCSB) ，該基準(zhǔn)可以克服使用高容量多客戶(hù)端時(shí)遇到的一些限制。YCSB的變化已經(jīng)寫(xiě)入了第一個(gè)白皮書(shū)并且提交回了社區(qū)。
測(cè)試的NoSQL數(shù)據(jù)庫(kù)包括Aerospike、Cassandra、Couchbase （1.8 和2.0）和 MongoDB。第一個(gè)是商業(yè)化產(chǎn)品，最后一個(gè)是文檔數(shù)據(jù)存儲(chǔ)而不是鍵-值存儲(chǔ)，但是因?yàn)椤霸谖覀冇龅降目蛻?hù)端中經(jīng)�？紤]將它用于相似類(lèi)型的應(yīng)用程序中”，所以我們將之包含了進(jìn)來(lái)。所有的數(shù)據(jù)庫(kù)都使用其提供商提供的建議做了優(yōu)化。測(cè)試系統(tǒng)使用SSD存儲(chǔ)，而沒(méi)有使用旋轉(zhuǎn)磁盤(pán)。白皮書(shū)中詳細(xì)記錄了測(cè)試所使用的方法論、客戶(hù)端、工作量配置以及硬件配置等信息。
Thumbtack承認(rèn)它們和“Aerospike、Couchbase以及10gen有商業(yè)和（或）戰(zhàn)略合作關(guān)系”，同時(shí)使用的硬件也是從Aerospike租用的。
下面列出了一些測(cè)試的基準(zhǔn)結(jié)果。
插入吞吐量
數(shù)據(jù)庫(kù)通過(guò)YCSB的加載路由執(zhí)行了大量插入，載入了初始的工作集合。Couchbase在工作集合載入內(nèi)存中時(shí)結(jié)果很好，但是在工作集合載入SSD時(shí)遇到了問(wèn)題，Couchbase 1.8沒(méi)有完成操作，而對(duì)Couchbase 2.0而言則必須使用較小的集合和異步模式。圖中藍(lán)色圓柱表示的就是Couchbase，Aerospike處在第二位。
圖1：插入吞吐量

注意：對(duì)Couchbase 2.0而言，SSD吞吐量使用的樣本較小，同時(shí)是異步模式；而對(duì)Couchbase 1.8而言，即使減少數(shù)據(jù)集也不能加載。
最大吞吐量
該測(cè)試使用了一個(gè)“強(qiáng)持久性模型，在復(fù)制時(shí)使用了一個(gè)相對(duì)服務(wù)器的RAM而言非常大的數(shù)據(jù)集。該測(cè)試打算作為保證強(qiáng)持久性的事務(wù)型數(shù)據(jù)的使用典范”。
在這個(gè)圖表中并沒(méi)有Couchbase，因?yàn)槭褂猛�步�?fù)制時(shí)它無(wú)法完成測(cè)試。
圖2：最大吞吐量——SSD支持的數(shù)據(jù)集

在使用異步復(fù)制時(shí)，內(nèi)存中的結(jié)果如下：
圖3：最大吞吐量——內(nèi)存數(shù)據(jù)集

延遲時(shí)間/吞吐量
基準(zhǔn)還測(cè)量了在不同級(jí)別的傳輸下讀取和更新的延遲時(shí)間。下面的圖表包含了一個(gè)完整視圖和每個(gè)對(duì)應(yīng)的縮放視圖。
圖4a——4d：延遲時(shí)間/吞吐量結(jié)果（平衡負(fù)載）

故障恢復(fù)
Thumbtack還模擬了一個(gè)硬件錯(cuò)誤，以便查看在一個(gè)節(jié)點(diǎn)無(wú)法工作時(shí)會(huì)發(fā)生什么：

注意：以上結(jié)果依賴(lài)于使用的驅(qū)動(dòng)，像Hector這樣較新的驅(qū)動(dòng)能恢復(fù)到100%的吞吐量。同時(shí)假設(shè)監(jiān)控腳本完美。
基準(zhǔn)還測(cè)量了宕機(jī)時(shí)間，例如集群從發(fā)生錯(cuò)誤開(kāi)始到能夠響應(yīng)所需要的時(shí)間，所有數(shù)據(jù)庫(kù)顯示的值都合理：
圖6：宕機(jī)時(shí)間、異步復(fù)制和基于RAM的數(shù)據(jù)集

Thumbtack基準(zhǔn)還包含了很多其他不同情況下的不同結(jié)果，但是此處并沒(méi)有包含這些內(nèi)容。
另一個(gè)NoSQL基準(zhǔn)發(fā)布于2012年10月，其中對(duì)比了Cassandra、HBase、MongoDB和Rick。這些測(cè)試中還包含了MySQL，作為針對(duì)SQL技術(shù)的一個(gè)參考。
查看英文原文：NoSQL Benchmark Compares Aerospike, Cassandra, Couchbase and MongoDB