1 測試目的
模擬生產環境，測試當前mongoDB的各項性能。mongodb
2 測試環境
2.1 軟件配置
2.2 硬件配置
3 測試工具
YCSB是雅虎開源的NoSQL測試工具，一般用來對noSQL數據庫進行性能，這裏咱們使用的是ycsb-mongodb-binding-0.15.0.tar.gz包。shell
須要新建配置文件，並調整參數，並利用load/run命令，加載數據進行性能測試。數據庫
3.1使用簡介
#ycsb包解壓後的目錄結構vim
#使用前,咱們要先了解命令結構後端
命令示例：緩存
#/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億條數據，觀察請求狀態 |
| 前置條件 |
一、mongoDB正常運行 |
| 步驟 |
一、根據需求測試項，指定mongodb分片，調整測試模型 二、準備數據 /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 三、測試數據 /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 四、記錄測試結果 五、調整線程數，繼續測試，並記錄結果 六、經過調整線程數，直到發現ops再也不增長而響應時間繼續增長。 |
| 獲取指標 |
一、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據準備要求 |
|
| 備註 |
在測試前，確保網絡暢通 |
5.2 用例2 update&read mongoDB測試庫
| 測試用例2：update&read mongoDB測試庫 |
|
| 測試目的 |
在測試庫90%更新和10%讀取測試1億條數據，觀察請求狀態 |
| 前置條件 |
一、mongoDB正常運行 |
| 步驟 |
一、根據需求測試項，指定mongodb分片，調整測試模型 二、預備數據 參照如上命令 3.測試數據 參照如上命令 四、記錄測試結果； 五、調整線程數，繼續測試，並記錄結果； 六、經過調整線程數，直到發現ops再也不增長而響應時間繼續增長。 |
| 獲取指標 |
一、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據準備要求 |
|
| 備註 |
在測試前，確保網絡暢通 |
5.3 用例3 read&insert&update mongoDB測試庫
| 測試用例3：update&read mongoDB測試庫 |
|
| 測試目的 |
在測試庫65%讀取，10%插入和25%更新測試1億條數據，觀察請求狀態 |
| 前置條件 |
一、mongoDB正常運行 |
| 步驟 |
一、根據需求測試項，指定mongodb分片，調整測試模型 二、預備數據 參照如上命令 3.測試數據 參照如上命令 四、記錄測試結果； 五、調整線程數，繼續測試，並記錄結果； 六、經過調整線程數，直到發現ops再也不增長而響應時間繼續增長。 |
| 獲取指標 |
一、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據準備要求 |
|
| 備註 |
在測試前，確保網絡暢通 |
5.4 用例4 read&update mongoDB測試庫
| 測試用例4：read&update mongoDB測試庫 |
|
| 測試目的 |
在測試庫50%讀取，50%更新測試1億條數據，觀察請求狀態 |
| 前置條件 |
一、mongoDB正常運行 |
| 步驟 |
一、根據需求測試項，指定mongodb分片，調整測試模型 二、預備數據 參照如上命令 3.測試數據 參照如上命令 四、記錄測試結果； 五、調整線程數，繼續測試，並記錄結果； 六、經過調整線程數，直到發現ops再也不增長而響應時間繼續增長。 |
| 獲取指標 |
一、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據準備要求 |
|
| 備註 |
在測試前，確保網絡暢通 |
5.5 用例5 read mongoDB測試庫
| 測試用例5：read mongoDB測試庫 |
|
| 測試目的 |
在測試庫100%讀取1億條數據，觀察請求狀態 |
| 前置條件 |
一、mongoDB正常運行 |
| 步驟 |
一、根據需求測試項，指定mongodb分片，調整測試模型 二、預備數據 參照如上命令 3.測試數據 參照如上命令 四、記錄測試結果； 五、調整線程數，繼續測試，並記錄結果； 六、經過調整線程數，直到發現ops再也不增長而響應時間繼續增長。 |
| 獲取指標 |
一、讀寫耗時、吞吐量、平均響應時間 |
| 參數化變量 |
|
| 數據準備要求 |
|
| 備註 |
在測試前，確保網絡暢通 |
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。
特別說明：測試結論只適用於本次測試；