1 測試目的
模擬生產環境，測試當前mongoDB的各項性能。
2 測試環境
2.1 軟件配置
2.2 硬件配置
3 測試工具
YCSB是雅虎開源的NoSQL測試工具，通常用來對noSQL數據庫進行性能，這里我們使用的是ycsb-mongodb-binding-0.15.0.tar.gz包。
需要新建配置文件，並調整參數，並利用load/run命令，加載數據進行性能測試。
3.1使用簡介
#ycsb包解壓后的目錄結構
#使用前,我們要先了解命令結構
命令示例：
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 1 -P workloads/workloada -p fieldcount=1 -p fieldlength=1024 -p table=ycsb1 -p clientbuffering=true -p mongodb.url=mongodb://用戶:密碼@ip:port/test?authSource=admin
表1-4 命名參數說明
| 參數 |
含義 |
| bin/ycsb |
命令本身。 |
| load/run/shell |
指定這個命令的作用,分別代表加載數據/運行測試/交互界面。 |
| mongodb/hbase10/basic.. |
指定這次測試使用的驅動,也就是這次究竟測的是什么數據庫,有很多選項,可以ycsb --help看到所有。 |
| threads |
線程數，模擬客戶端數 |
| -P |
選擇加載的配置文件 |
| workloads/workloada |
指定測試的參數文件,默認有6種測試模板,加一個大模板； workloada:讀寫均衡型，50%/50%,Reads/Writes workloadb:讀多寫少型，95%/5%,Reads/Writes workloadc:只讀型，100%,Reads workloadd:讀最近寫入記錄型,95%/5%,Reads/insert workloade:掃描小區間型,95%/5%,scan/insert workloadf:讀寫入記錄均衡型,50%/50%,Reads/insert workload_template:參數列表模板 |
| -p fieldcount=1 |
單條記錄字段個數：1 |
| -p fieldlength=1024 |
每個字段的大小： 1024Bytes |
| -p table= |
自定義表名 |
| -p clientbuffering=true |
客戶端寫緩存 |
| -p mongodb.url= |
指定測試的數據庫的認證信息,賬號密碼，地址端口和庫名 |
3.2 YCSB測試參數解析
workloads目錄里面下包含自帶了6種壓力測試場景。 如下圖：
文件和相應場景的對應關系如下：
workloada:讀寫均衡型，50%/50%,Reads/Writes
workloadb:讀多寫少型，95%/5%,Reads/Writes
workloadc:只讀型，100%,Reads
workloadd:讀最近寫入記錄型,95%/5%,Reads/insert
workloade:掃描小區間型,95%/5%,scan/insert
workloadf:讀寫入記錄均衡型,50%/50%,Reads/insert
示例文件：
#vim workloads/workloada
表1-5 workload參數含義
| 參數 |
含義 |
| recordcount=1000
|
YCSB load(加載元數據)命令的參數，默認值1000表示默認加載的記錄條數，可以在命令行顯示修改該值。 |
| operationcount=1000
|
YCSB run(運行壓力測試)命令的參數，默認值1000表示默認選取數據庫中的1000條數據進行壓力測試。對於workloada這種測試場景，就意味着讀數據在500左右，寫數據也在500左右。 |
| workload=com.yahoo.ycsb.workloads.CoreWorkload
|
指定了workload的實現類為 com.yahoo.ycsb.workloads.CoreWorkload |
| readallfields=true |
表示查詢時是否讀取記錄的所有字段 |
| readproportion=0.5 |
表示讀操作的比例，該場景為0.5 |
| updateproportion=0.5 |
表示更新操作的比例，該場景為0.5 |
| scanproportion=0 |
表示掃描操作的比例 |
| insertproportion=0 |
表示插入操作的比例 |
| requestdistribution=zipfian
|
表示請求的分布模式，YCSB提供uniform, zipfian, latest三種分布模式, Uniform（等概率隨機選擇記錄）、Zipfian（隨機選擇記錄，存在熱紀錄）和Latest（近期寫入的記錄是熱記錄） |
3.3 YCSB測試工具命令
1.先為指定的庫和表指定hash分片
mongo ip:端口
>sh.enableSharding("test")
>sh.shardCollection("test.usertable", {_id:"hashed"})
2.修改業務模型
#cd /opt/ycsb-mongodb-binding-0.15.0/workloads
#只插入100萬條數據
#vi workload-s1
3.數據寫入
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1-p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://賬號:密碼@ip:端口,ip:端口,ip:端口/test?authSource=admin
4.查看插入的數據
#mongo ip:端口
>use test
>db.stats();
插入100萬條數據后，可以看到每個share上都有33萬多的objects,
5.結果參數說明
表1-6 ycsb運行結果說明
| 參數 |
說明 |
| RunTime(ms)： |
運行總時間（毫秒） |
| Throughput(ops/sec)： |
吞吐量，每秒操作數 |
| [TOTAL_GCS_PS_Scavenge], Count： |
Parallel Scavenge 回收次數 |
| [TOTAL_GC_TIME_PS_Scavenge], Time(ms)： |
Parallel Scavenge 回收時間 |
| [TOTAL_GC_TIME_%_PS_Scavenge], Time(%)： |
Parallel Scavenge 回收時間百分比 |
| [TOTAL_GCS_PS_MarkSweep], Count： |
PS MarkSweep 回收次數 |
| [TOTAL_GC_TIME_PS_MarkSweep], Time(ms)： |
PS MarkSweep 回收時間 |
| [TOTAL_GC_TIME_%_PS_MarkSweep], Time(%)： |
PS MarkSweep 回收時間百分比 |
| [TOTAL_GCs], Count： |
全局 GC 次數 |
| [TOTAL_GC_TIME], Time(ms)： |
全局 GC 時間 |
| [TOTAL_GC_TIME_%], Time(%)： |
全局 GC 時間百分比 |
| 不同操作類型:READ\UPDATE\INSERT\SCAN等; |
|
| Operations |
總操作數 |
| AverageLatency(us) |
平均延遲（微秒） |
| MinLatency(us) |
最小延遲（微秒） |
| MaxLatency(us) |
最大延遲（微秒） |
| 95thPercentileLatency(us) ： |
95%的樣本延遲低於該值 |
| 99thPercentileLatency(us) |
99%的樣本延遲低於該值 |
| Return=OK |
結果（正確），總操作數 |
4 測試方法
- 使用YCSB-mongoDB對測試環境下test庫進行各項測試。
4.1 測試環境
4.2測試模型
4.3測試指標
（1）OPS：Operator per Second，數據庫每秒執行的操作數。
（2）AverageLatency，平均響應時間。
（3）評判指標：直到發現ops不再增加而平均響應時間繼續增加；
4.4測試步驟
1.先為指定的庫和表指定hash分片
#mongo ip:端口
>sh.enableSharding("test")
>sh.shardCollection("test.ycsb1", {_id:"hashed"})
2.文檔模型：
修改YCSB配置，每個文檔大小約為1KB，默認“_id”索引。
3.配置workload文件。
按照表1-8業務模型所示的業務模型，配置workload中的“readproportion”、“insertproportion”、“updateproportion”等值。
4.以業務模型workload_s1為例，執行以下命令，准備數據。
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://賬號:密碼@ip:端口,ip:端口,ip:端口/test?authSource=admin
1>workload_s1_load.result 2> workload_s1_load.log
5.以業務模型workload_s1為例，執行以下命令，測試性能
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb run mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://賬號:密碼@ip:端口,ip:端口,ip:端口/test?authSource=admin
1>workload_s1_run.result 2> workload_s1_run.log
5 測試用例
5.1 用例1 insert mongoDB測試庫
| 測試用例1：插入mongoDB測試庫 |
|
| 測試目的 |
在測試庫100% 導入1億條數據，觀察請求狀態 |
| 前置條件 |
1、mongoDB正常運行 |
| 步驟 |
1、根據需求測試項，指定mongodb分片，調整測試模型 2、准備數據 /opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024 -p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://賬號:密碼@ip:端口,ip:端口,ip:端口/test?authSource=admin 1>workload_s1_load.result 2> workload_s1_load.log 3、測試數據 /opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb run mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024 -p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://賬號:密碼@ip:端口,ip:端口,ip:端口/test?authSource=admin 1>workload_s1_run.result 2> workload_s1_run.log 4、記錄測試結果 5、調整線程數，繼續測試，並記錄結果 6、通過調整線程數，直到發現ops不再增加而響應時間繼續增加。 |
| 獲取指標 |
1、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據准備要求 |
|
| 備注 |
在測試前，確保網絡暢通 |
5.2 用例2 update&read mongoDB測試庫
| 測試用例2：update&read mongoDB測試庫 |
|
| 測試目的 |
在測試庫90%更新和10%讀取測試1億條數據，觀察請求狀態 |
| 前置條件 |
1、mongoDB正常運行 |
| 步驟 |
1、根據需求測試項，指定mongodb分片，調整測試模型 2、預備數據 參照如上命令 3.測試數據 參照如上命令 4、記錄測試結果； 5、調整線程數，繼續測試，並記錄結果； 6、通過調整線程數，直到發現ops不再增加而響應時間繼續增加。 |
| 獲取指標 |
1、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據准備要求 |
|
| 備注 |
在測試前，確保網絡暢通 |
5.3 用例3 read&insert&update mongoDB測試庫
| 測試用例3：update&read mongoDB測試庫 |
|
| 測試目的 |
在測試庫65%讀取，10%插入和25%更新測試1億條數據，觀察請求狀態 |
| 前置條件 |
1、mongoDB正常運行 |
| 步驟 |
1、根據需求測試項，指定mongodb分片，調整測試模型 2、預備數據 參照如上命令 3.測試數據 參照如上命令 4、記錄測試結果； 5、調整線程數，繼續測試，並記錄結果； 6、通過調整線程數，直到發現ops不再增加而響應時間繼續增加。 |
| 獲取指標 |
1、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據准備要求 |
|
| 備注 |
在測試前，確保網絡暢通 |
5.4 用例4 read&update mongoDB測試庫
| 測試用例4：read&update mongoDB測試庫 |
|
| 測試目的 |
在測試庫50%讀取，50%更新測試1億條數據，觀察請求狀態 |
| 前置條件 |
1、mongoDB正常運行 |
| 步驟 |
1、根據需求測試項，指定mongodb分片，調整測試模型 2、預備數據 參照如上命令 3.測試數據 參照如上命令 4、記錄測試結果； 5、調整線程數，繼續測試，並記錄結果； 6、通過調整線程數，直到發現ops不再增加而響應時間繼續增加。 |
| 獲取指標 |
1、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據准備要求 |
|
| 備注 |
在測試前，確保網絡暢通 |
5.5 用例5 read mongoDB測試庫
| 測試用例5：read mongoDB測試庫 |
|
| 測試目的 |
在測試庫100%讀取1億條數據，觀察請求狀態 |
| 前置條件 |
1、mongoDB正常運行 |
| 步驟 |
1、根據需求測試項，指定mongodb分片，調整測試模型 2、預備數據 參照如上命令 3.測試數據 參照如上命令 4、記錄測試結果； 5、調整線程數，繼續測試，並記錄結果； 6、通過調整線程數，直到發現ops不再增加而響應時間繼續增加。 |
| 獲取指標 |
1、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據准備要求 |
|
| 備注 |
在測試前，確保網絡暢通 |
6 測試場景
| 測試類別 |
場景 |
場景的組織 |
場景的控制 |
| 用例 |
|||
| mongoDB性能測試 |
場景1 |
6.1插入性能測試 100% insert |
雲服務自帶監控 |
| mongoDB性能測試 |
場景2 |
6.2更新,讀取性能測試 90% update ,10% read |
雲服務自帶監控 |
| mongoDB性能測試 |
場景3 |
6.3讀取，插入，更新性能測試 65% read ,25% insert, 10% update |
雲服務自帶監控 |
| mongoDB性能測試 |
場景4 |
6.4 讀取，更新性能測試 50% read , 50% update |
雲服務自帶監控 |
| mongoDB性能測試 |
場景5 |
6.5 讀取性能測試 100% read |
雲服務自帶監控 |
7 測試結果分析
7.1 Intert性能測試
7.1.1 測試參數記錄
分片集群100% insert寫入測試記錄結果如下：
| 線程 |
類型 |
數據條數 |
runtime（ms） |
Ops/sec |
AverageLatency(us) |
操作執行數 |
| 50 |
分片-insert |
|
|
|
||
| 100 |
分片-insert |
|
|
|
|
|
| 200 |
分片-insert |
|
|
|
|
|
| 400 |
分片-insert |
|
|
|
7.1.2測試結果
繪制圖表
7.1.3 資源情況分析
Mongos是數據庫集群請求的入口，所有的請求都通過mongos進行協調，不需要在應用程序添加一個路由選擇器，
mongos自己就是一個請求分發中心，它負責把對應的數據請求請求轉發到對應的shard服務器上。
1.下圖100線程時，使用mongostat監測到mongos的情況；
參數解釋：
inserts 每秒插入次數
command 每秒的命令數
vsize 虛擬內存使用量
res 物理內存使用量
net_in/net_out 網絡進出流量
2.下圖為200線程時，mongos的cpu和帶寬使用情況；
Mongos的cpu使用率穩定在50%左右，輸入流量穩定在13MB/s;mongos進行協調請求，
再將數據進行轉發到后端;通過監控到mongos的cpu,內存，網絡帶寬一直處在穩定的狀態;
3.Config server，為配置服務器，存儲所有數據庫元信息（路由、分片）的配置。在生
產環境通常有多個 config server 配置服務器，因為它存儲了分片路由的元數據，防止數據丟失。
下圖為400線程下config的cpu和內存使用率；cpu穩定在20%以下，內存穩定在30%以下；
4.每個分片都是一個獨立的數據庫，所有的分片組合起來構成一個邏輯上的完整的數據庫。
分片機制降低了每個分片的數據操作量及需要存儲的數據量，達到多台服務器來應對不斷增加的負載和數據的效果。
下圖為400線程，share的cpu，內存和帶寬使用情況，看到cpu大部分時間已處於100%的狀態；內存使用率在60%以下，帶寬為16MB/s;
在雲環境上，后端為分布式存儲池，無法監控具體的磁盤寫入情況；
但每當內存中的數據累計到一定量(或者一定時間)，MongoDB會將內存數據flush到磁盤，
並清理臟頁數據，此時該shard的cpu使用率也會飆升，達到規格上限；
后續省略
。
。
。
8 測試結果總結
1.當前測試結果繪制圖表
2.當前瓶頸分析
Sharding cluster是一種可以水平擴展的模式,在數據量很大時特給力,實際大規模應用一般會采用這種架構去構建。
sharding分片很好的解決了單台服務器磁盤空間、內存、cpu等硬件資源的限制問題，把數據水平拆分出去，降低單節點的訪問壓力。
從以上測試記錄，當share的cpu達到100%時，插入，更新和讀取等操作性能有所下降，綜上，目前性能受限於分片的cpu。
特別說明：測試結論只適用於本次測試；