前言
本文主要指導使用者如何測試雲端Cassandra,以及給出一些我們基準測試的結果。隨著核心&雲環境不斷最佳化,基準測試結果可能不能代表最優的效能,會不時更新。如果你需要評估業務需要多大規模的Cassandra執行個體,可以依照本文提供的測試方法做一些基本測試。當然最好的方式還是類比業務在執行個體上實際跑一下,這比任何正式發行前小眾測試工具都準確。
測試載入器
使用業內標準測試載入器YCSB 0.15.0(當前最新release版本)https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra
測試環境
測試直接購買雲Cassandra進行測試。
網路:VPC內網,用戶端與伺服器同地區同可用性區域執行個體規模:1個DC,3節點執行個體容量:單節點400G SSD雲端硬碟(容量會適當影響效能)壓測用戶端: ecs.c6.2xlarge(8核16G)執行個體規格:當前雲Cassandra支援的所有規格
測試負載說明
因為不同業務負載不同(每列欄位數,每行資料量等),能達到的吞吐&延遲效果也不同。本文使用YCSB預設的workloada進行測試。使用者可以自行調整YCSB參數達到最匹配業務的效果。大部分Cassandra相關測試參數也是預設,詳見文檔:https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra
主要參數
每行10欄位 (預設)
每行1k (預設)
讀 : 寫 = 95 : 5
讀寫一致性層級:ONE(預設)
2副本 (因為是雲端硬碟,所以使用2副本)
壓測線程:根據規格動態調節,具體見測試結果
資料量(recordcount):也就是匯入多少行資料,根據規格動態調節,具體見測試結果
壓測操作次數(operationcount):壓測操作次數和資料量一致
需要注意的是調整一致性層級會影響效能,使用者可以根據實際業務情況自行調整。
測試步驟
1. 建立測試表
# cn-shanghai-g 替換成你購買的執行個體具體的 資料中心ID(DC Name), 在控制台可以找到
create keyspace ycsb WITH replication = {'class': 'NetworkTopologyStrategy', 'cn-shanghai-g': 2};
create table ycsb.usertable (y_id varchar primary key, field0 varchar, field1 varchar, field2 varchar, field3 varchar, field4 varchar, field5 varchar, field6 varchar, field7 varchar, field8 varchar, field9 varchar);
2. 安裝測試載入器
wget https://github.com/brianfrankcooper/YCSB/releases/download/0.15.0/ycsb-cassandra-binding-0.15.0.tar.gz
tar -zxf ycsb-cassandra-binding-0.15.0.tar.gz
3. 編輯workloads/workloada
加入下面3行
hosts=cds-xxxxxxxx-core-003.cassandra.rds.aliyuncs.com #資料庫連接點,控制台可查到
cassandra.username=cassandra #此帳號需要有許可權讀寫ycsb keyspace
cassandra.password=123456 #密碼忘記可以控制台修改
4. 資料準備階段(純寫入測試)
nohup ./bin/ycsb load cassandra2-cql -threads $THREAD_COUNT -P workloads/workloada -s > $LOG_FILE 2>&1 &
此測試結果可以觀測寫入吞吐上限。要想測試最大吞吐,得不斷增大$THREAD_COUNT看吞吐是否有增加,同時壓測用戶端的規格也不能太小。
5. 壓測階段(讀寫混合測試)
nohup ./bin/ycsb run cassandra2-cql -threads $THREAD_COUNT -P workloads/workloada -s > $LOG_FILE 2>&1 &
此測試結果可以觀測讀寫混合效能情況。
測試結果
測試結果僅供參考,不同負載情況下延遲吞吐效果也不同。使用者可以根據上文所述方法,嘗試用不同參數,不同的壓力,更巨量資料量(更長時間)去得到更符合業務情況的測試結果。注意用戶端規格也會影響測試結果,不要用共用型。
測試結果解釋
Load:資料準備階段(純寫入測試)。
Run:壓測階段(讀寫混合測試)。
OPS:每秒操作次數,也就是整個階段的吞吐。
WAVG:寫平均延遲,單位:微秒。
RAVG:讀平均延遲,單位:微秒。
RP999:99.9%分位讀延遲,單位:微秒。
線程:100/100,表示資料準備階段YCSB測試線程/壓測階段YCSB測試線程。
壓測階段分兩組,一組滿負載,一組正常負載。
CPU 80% 負載
規格 | 線程 | 資料量(萬行) | Load OPS | Load WAVG | Run OPS | Run WAVG | Run RAVG | Run RP95 | Run RP99 | Run RP999 |
---|---|---|---|---|---|---|---|---|---|---|
4核8G | 100/100 | 1600 | 32277 | 3071 | 29745 | 2846 | 3363 | 7795 | 23039 | 43999 |
CPU 60% 負載
規格 | 線程 | 資料量(萬行) | Load OPS | Load WAVG | Run OPS | Run WAVG | Run RAVG | Run RP95 | Run RP99 | Run RP999 |
---|---|---|---|---|---|---|---|---|---|---|
4核8G | 100/16 | 1600 | 32063 | 3093 | 16721 | 514 | 974 | 1879 | 3047 | 28063 |
本文只列了SSD雲端硬碟結果。因為高效雲端硬碟也擁有不錯的IOPS,在資料規模&執行個體規格較小的情況下,差距不明顯(磁碟不是瓶頸),不具備參考價值。使用者可以根據實際業務情況,類比相對真實的負載,實際測試一下。業務側實際能達到的效果還應結合業務應用實現,比如Java實現的應用可能用戶端側本身GC就會影響延遲。