【編者按】盤點AWS生態(tài)圈，Netflix無疑是其最有價值用戶之一――在公布了大量基于AWS開源工具及調(diào)優(yōu)的同時，還發(fā)表了多個AWS環(huán)境下高價值的基準(zhǔn)測試。近日，Netflix在更貼近現(xiàn)在生產(chǎn)環(huán)境下重測了Cassandra性能。
免費訂閱“CSDN大數(shù)據(jù)”微信公眾號，實時了解最新的大數(shù)據(jù)進(jìn)展！
CSDN大數(shù)據(jù)，專注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺，大數(shù)據(jù)實踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。
以下為譯文：
在2011年11月發(fā)表的文章“ NetFlix測試Cassandra――每秒百萬次寫入”中我們展示了Cassandra （C*）如何在集群節(jié)點增加時實現(xiàn)性能線性增長。隨著新型EC2實例類型的產(chǎn)生，我們決定重做一次性能測試，與之前帖子不同，這次的重心不是C*可擴展性，而是量化這些新實例的性能指標(biāo)。下面是此次測試的詳細(xì)信息及結(jié)果。
此次測試的C*集群運行于Datastax 3.2.5企業(yè)版，C*版本為1.2.15.1，共有285個節(jié)點。實例類型為i2.xlarge器，運行于Heap為12GB的JVM 1.7.40_b43之上。使用的OS為Ubuntu 12.04 LTS。數(shù)據(jù)與日志使用相同的EXT3格式掛載文件。
盡管上次測試使用了較高規(guī)格的m1.xlarge服務(wù)器，此次測試的吞吐量結(jié)果依然與上次持平，而且選擇（支持SSD）i2.xlarge規(guī)格服務(wù)器更加貼近現(xiàn)實用例，能更好的展示其吞吐量與延遲。
完整的schema如下：
create keyspace Keyspace1
with placement_strategy = ‘NetworkTopologyStrategy’
and strategy_options = {us-east : 3
and durable_writes = true;
use Keyspace1;
create column family Standard1
with column_type = ‘Standard’
and comparator = ‘AsciiType’
and default_validation_class = ‘BytesType’
and key_validation_class = ‘BytesType’
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and populate_io_cache_on_flush = false
and gc_grace = 864000
and min_compaction_threshold = 999999
and max_compaction_threshold = 999999
and replicate_on_write = true
and compaction_strategy = ‘org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy’
and caching = ‘KEYS_ONLY’
and column_metadata = [
{column_name : 'C4',
validation_class : BytesType},
{column_name : 'C3',
validation_class : BytesType},
{column_name : 'C2',
validation_class : BytesType},
{column_name : 'C0',
validation_class : BytesType},
{column_name : 'C1',
validation_class : BytesType}]
and compression_options = {‘sstable_compression’ : ”};
請注意到這里的min_compaction_threshold和max_compaction_threshold值很高，盡管在實際產(chǎn)品中不可能使用完全一致的數(shù)據(jù)，但也能實際反映我們所想掌握的數(shù)據(jù)。
客戶端
客戶端應(yīng)用程序使用Cassandra Stress，有60個客戶端節(jié)點，實例類型為r3.xlarge，為之前m2.4xlarge規(guī)格實例數(shù)量的一半，價格也是之前的一半，但依然能夠推動所需負(fù)載（使用線程低于40%）并達(dá)到與之前相同的吞吐量。客戶端運行在基于Ubuntu 12.04 LTS系統(tǒng)的JVM 1.7.40_b43之上。
網(wǎng)絡(luò)拓?fù)?/b>
Netflix的Cassandra集群有3個副本，部署在3個不同的可用區(qū)域（Availability Zones，即AZ）。這樣，如果其中一個AZ斷電，余下的2個副本依然可以繼續(xù)工作。
之前帖子里所有的客戶端都部署同一個AZ中，這次的改變遵從實際產(chǎn)品都部署在三個不同AZ的真實應(yīng)用場景。客戶端請求一般交于相同AZ的C*節(jié)點，我們稱之為zone-aware連接，這一特征被構(gòu)建到Netflix C* Java客戶端Astyanax中。Astyanax客戶端通過查詢記錄信息向相應(yīng)實例服務(wù)端發(fā)送讀寫請求。盡管C*協(xié)調(diào)器能夠?qū)崿F(xiàn)所有請求，但當(dāng)實例不在副本集中的情況發(fā)生時，則需要一個額外的網(wǎng)絡(luò)躍點，即token-aware請求。
此次測試使用Cassandra Stress，因此不需要token-aware請求。而通過一些簡單的grep和awk-fu，我們可以得知此次測試屬于zone-aware連接范疇，是網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)里比較典型的實際產(chǎn)品案例。
延遲及吞吐量測量
我們已經(jīng)文檔化了使用Priam完成令牌任務(wù)、備份和存儲的方法。Priam內(nèi)部版本添加了一些額外功能，我們使用Priam協(xié)助收集C* JMX自動測量結(jié)果并發(fā)送到分析平臺Atlas, 此功能將在未來幾周添加至Priam 開源版本中。
以下是用于測量延遲與吞吐量的JMX屬性：
延遲
吞吐量
測試
我執(zhí)行了以下4組測試:
100%寫入
與原帖測試不同，此次測試展示了持久性大于每秒100萬次寫入的用例。現(xiàn)實中只寫入的應(yīng)用程序很少，這種類型的應(yīng)用要么是遙測系統(tǒng)要么是物聯(lián)網(wǎng)應(yīng)用，其相關(guān)測試數(shù)據(jù)被輸入BI系統(tǒng)進(jìn)行分析。
CL One
與原帖測試相似，此次測試運行在CL One上。其平均延遲略高于5毫秒，第95百分位為10毫秒
每個客戶節(jié)點都運行如下Cassandra Stress命令：
cassandra-stress -d [list of C* IPs] -t 120 -r -p 7102 -n 1000000000 -k -f [path to log] -o INSERT
CL LOCAL_QUORUM
為了保證用例讀入的高一致性，這次我們測試了運行于LOCAL_QUORUM CL上吞吐量大于每秒百萬次寫入的用例。每秒100萬次寫入吞吐量平均延遲低于6毫秒，第95百分位為17毫秒
每個客戶節(jié)點都運行如下Cassandra Stress命令：
cassandra-stress -d [list of C* IPs] -t 120 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o INSERT
綜合測試――10%寫入90%讀入
每秒100萬次寫入只是一個醒目的標(biāo)題，大多數(shù)應(yīng)用程序都是讀寫混合的。在對Netflix主要應(yīng)用程序調(diào)研之后，我決定做一個10%寫入90%讀入的綜合測試，這一混合測試占用總線程的10%用于寫入90%用于讀取。這雖然不是實際應(yīng)用程序的真實復(fù)現(xiàn)，但也能很好的測量數(shù)據(jù)擁塞時集群吞吐量及延遲
CL One
使用CL One配備時，C*實現(xiàn)了最高的吞吐量及可用性，開發(fā)人員需要接受其結(jié)果的一致性，并模仿這一范例設(shè)計他們的應(yīng)用程序。
每個客戶節(jié)點都運行如下Cassandra Stress命令：
cassandra-stress -d $cCassList -t 30 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o INSERT<br>cassandra-stress -d $cCassList -t 270 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o READ
CL LOCAL_QUORUM
大多數(shù)用C*開發(fā)的應(yīng)用程序都將默認(rèn)為CL Quorum讀寫，這為其相關(guān)開發(fā)人員進(jìn)入分布式數(shù)據(jù)庫系統(tǒng)提供了機會，也避免了解決應(yīng)用程序最終一致性的難題。
每個客戶節(jié)點都運行如下Cassandra Stress命令：
cassandra-stress -d $cCassList -t 30 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o INSERT<br>cassandra-stress -d $cCassList -t 270 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o READ
費用
這次測試的總開銷包括EC2實例費用和inter-zone網(wǎng)絡(luò)流量費用，我使用Boundary監(jiān)控C*網(wǎng)絡(luò)使用情況。
上圖顯示了可用服務(wù)區(qū)域間30Gbps的傳輸速度。
這里是執(zhí)行每秒100萬次寫入測試的費用：
|
Instance Type / Item |
Cost per Minute |
Count |
Total Price per Minute |
|
|
i2.xlarge |
$0.0142 |
285 |
$4.047 |
|
|
r3.xlarge |
$0.0058 |
60 |
$0.348 |
|
|
Inter-zone traffic |
$0.01 per GB |
3.75 GBps * 60 = 225GB per minute |
$2.25 |
|
|
Total Cost per minute |
$6.645 |
|||
|
Total Cost per half Hour |
$199.35 |
|||
|
Total Cost per Hour |
$398.7 |
結(jié)語
大多數(shù)企業(yè)可能不需要處理這么多數(shù)據(jù)，這項測試很好的展示了新型AWS i2和r3實例類型的花費、延遲及吞吐量。每一個應(yīng)用程序都是不一樣的，你的情況也會不盡相同。
這次測試耗費了我一周的空閑時間，并不是一個詳盡的性能研究，我也沒有對C*系統(tǒng)或JVM作深入調(diào)研，你有可能會比我做的更好。如果你有興趣研究大規(guī)模分布式數(shù)據(jù)庫及性能提升，歡迎加入Netflix CDE組。
原文鏈接：Revisiting 1 Million Writes per second（翻譯/應(yīng)玲 責(zé)編/仲浩）
程序員人生，我編程，我富裕，記住wfuyu網(wǎng)，php教程，php學(xué)習(xí)，php手冊，CMS模版制作
聲明：本站大部分內(nèi)容是作者原創(chuàng)，少部分收集于互聯(lián)網(wǎng)供大家一起學(xué)習(xí)，原版權(quán)很多不明，如有侵權(quán)請聯(lián)系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權(quán)所有
