前言
本文主要指導用戶如何測試云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就會影響延遲。