前面的話
創(chuàng)新互聯(lián)建站歡迎咨詢:13518219792,為您提供成都網(wǎng)站建設(shè)網(wǎng)頁設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù),創(chuàng)新互聯(lián)建站網(wǎng)頁制作領(lǐng)域10多年,包括紙箱等多個(gè)行業(yè)擁有豐富建站經(jīng)驗(yàn),選擇創(chuàng)新互聯(lián)建站,為網(wǎng)站保駕護(hù)航!
本文將詳細(xì)介紹MongoDB數(shù)據(jù)庫索引構(gòu)建情況分析
概述
創(chuàng)建索引可以加快索引相關(guān)的查詢,但是會(huì)增加磁盤空間的消耗,降低寫入性能。這時(shí),就需要評(píng)判當(dāng)前索引的構(gòu)建情況是否合理。有4種方法可以使用
1、mongostat工具
2、profile集合介紹
3、日志
4、explain分析
mongostat
mongostat是mongodb自帶的狀態(tài)檢測(cè)工具,在命令行下使用。它會(huì)間隔固定時(shí)間獲取mongodb的當(dāng)前運(yùn)行狀態(tài),并輸出。如果發(fā)現(xiàn)數(shù)據(jù)庫突然變慢或者有其他問題的話,首先就要考慮采用mongostat來查看mongo的狀態(tài)
mongostat是查看mongodb運(yùn)行狀態(tài)的程序,使用方式如下
mongostat -h ip:port
【字段說明】
insert/s : 每秒插入數(shù)據(jù)庫的對(duì)象數(shù)量,如果是slave,則數(shù)值前有*,則表示復(fù)制集操作 query/s : 每秒的查詢操作次數(shù) update/s : 每秒的更新操作次數(shù) delete/s : 每秒的刪除操作次數(shù) getmore/s: 每秒查詢cursor(游標(biāo))時(shí)的getmore操作數(shù) command: 每秒執(zhí)行的命令數(shù),在主從系統(tǒng)中會(huì)顯示兩個(gè)值(例如 3|0),分別代表 本地|復(fù)制 命令 dirty: 臟數(shù)據(jù)字節(jié)的緩存百分比 used:正在使用中的緩存百分比 flushes:checkpoint的觸發(fā)次數(shù)在一個(gè)輪詢間隔期間。一般都是0,間斷性會(huì)是1, 通過計(jì)算兩個(gè)1之間的間隔時(shí)間,可以大致了解多長時(shí)間flush一次。flush開銷是很大的,如果頻繁的flush,可能就要找找原因了 vsize: 虛擬內(nèi)存使用量,單位MB res: 物理內(nèi)存使用量,單位MB。 res會(huì)慢慢的上升,如果res經(jīng)常突然下降,要查看下是否有別的程序狂吃內(nèi)存 qr: 客戶端等待從MongoDB實(shí)例讀數(shù)據(jù)的隊(duì)列長度 qw:客戶端等待從MongoDB實(shí)例寫入數(shù)據(jù)的隊(duì)列長度 ar: 執(zhí)行讀操作的活躍客戶端數(shù)量 aw: 執(zhí)行寫操作的活客戶端數(shù)量。如果ar或aw數(shù)值很大,那么就是DB被堵住了,DB的處理速度不及請(qǐng)求速度。查看是否有開銷很大的慢查詢。如果查詢一切正常,確實(shí)是負(fù)載很大,就需要加機(jī)器了 netIn:MongoDB實(shí)例的網(wǎng)絡(luò)進(jìn)流量 netOut:MongoDB實(shí)例的網(wǎng)絡(luò)出流量 conn: 打開連接的總數(shù),是qr,qw,ar,aw的總和 time:當(dāng)前時(shí)間
【實(shí)例】
插入100000條數(shù)據(jù),并打開mongostat查詢mongodb運(yùn)行狀態(tài)
由下圖看出,插入值insert值在插入數(shù)據(jù)時(shí)大量增加,在插入完畢后變成0。flush兩個(gè)1之間的間隔時(shí)間很長,說明性能還不錯(cuò);res在慢慢上升,沒有出現(xiàn)突然下降的情況,說明沒有其他的程序大量占用內(nèi)容的情況;qrw及arw數(shù)據(jù)很小,說明數(shù)據(jù)庫讀寫狀態(tài)正常,負(fù)載較小??傮w而言,mongodb數(shù)據(jù)庫運(yùn)行狀態(tài)良好
profile
mongodb可以通過profile來監(jiān)控?cái)?shù)據(jù),進(jìn)行優(yōu)化
【級(jí)別】
首先,要查看當(dāng)前是否開啟profile功能
使用下面的命令會(huì)返回level等級(jí),值為0|1|2,0代表關(guān)閉,即不記錄任何操作;1代表記錄慢命令(默認(rèn)值為100ms),即記錄運(yùn)行時(shí)間超過100ms的操作;2代表全部,即記錄任何操作
db.getProfilingLevel()
使用下面的命令可以設(shè)置level等級(jí)
db.setProfilingLevel()
如下圖所示,默認(rèn)地,profile關(guān)閉。使用setProfilingLevel()方法以50ms慢命令的方式開啟profile
【狀態(tài)】
操作被記錄到system.profile集合中
通過db.system.profile.find() 查看當(dāng)前的監(jiān)控日志
op:操作類型 ns:命名空間 query:查詢字符串 responseLength:返回長度 ts:時(shí)間 mills:執(zhí)行耗時(shí)
【使用】
在系統(tǒng)中開啟profile之后,如果profile記錄的數(shù)據(jù)非常大,會(huì)比較明顯的降低系統(tǒng)的性能。因此,profile的使用場(chǎng)景一般是新系統(tǒng)上線之前的測(cè)試階段,以及剛上線時(shí)的觀察階段,查看數(shù)據(jù)庫的設(shè)計(jì)及應(yīng)用程序的使用是否正常。如果profile記錄了大量的字段,需要調(diào)整系統(tǒng)附在、調(diào)整索引等,減小它的大小
日志
在配置日志文件時(shí),可以使用verbose參數(shù)來配置日志詳細(xì)程度,參數(shù)值從'v'到'vvvvv','v'越多,詳細(xì)度越高
日志會(huì)記錄mongodb的運(yùn)行狀態(tài),包括連接時(shí)間、當(dāng)前正在進(jìn)行的操作等
explain
MongoDB 提供了一個(gè) explain 命令讓我們獲知系統(tǒng)如何處理查詢請(qǐng)求。利用 explain 命令,可以很好地觀察系統(tǒng)如何使用索引來加快檢索,同時(shí)可以針對(duì)性優(yōu)化索引
explain有三種模式,分別是:queryPlanner、executionStats、allPlansExecution。現(xiàn)實(shí)開發(fā)中,常用的是executionStats模式
首先,插入10萬條數(shù)據(jù)
在time字段上建立索引
接著,尋找time范圍在100和200之間的文檔,并使用explain()
結(jié)果分為queryPlanner、executionStats和serverInfo三個(gè)部分。接下來,將分別對(duì)這三個(gè)部分的結(jié)果進(jìn)行詳細(xì)分析
【queryPlanner】
queryPlanner.plannerVersion: 版本
queryPlanner.namespace: 查詢的表
queryPlanner.indexFilterSet: 針對(duì)該query是否有indexfilter
queryPlanner.parsedQuery: 查詢條件
queryPlanner.winningPlan: 查詢優(yōu)化器針對(duì)該query所返回的最優(yōu)執(zhí)行計(jì)劃的詳細(xì)內(nèi)容
queryPlanner.winningPlan.stage: 最優(yōu)執(zhí)行計(jì)劃的stage
queryPlanner.winningPlan.inputStage: 用來描述子stage,并且為其父stage提供文檔和索引關(guān)鍵字。
queryPlanner.winningPlan.inputstage.stage,此處是IXSCAN,表示進(jìn)行的是index scanning
queryPlanner.winningPlan.inputstage.keyPattern: 索引鍵值對(duì)
queryPlanner.winningPlan.inputstage.indexName:索引名稱
queryPlanner.winningPlan.inputstage.isMultiKey: 是否是Multikey,此處返回是false,如果索引建立在array上,此處將是true
queryPlanner.winningPlan.inputstage.direction:查詢順序,此處是forward,如果用了.sort({time:-1})將顯示backward
queryPlanner.winningPlan.inputstage.indexBounds: 所掃描的索引范圍
queryPlanner.rejectedPlans:其他執(zhí)行計(jì)劃
【executionStats】
executionStats.executionSuccess: 是否成功
executionStats.nReturned: 查詢返回條目個(gè)數(shù)
executionStats.totalKeysExamined: 索引掃描條目個(gè)數(shù)
executionStats.totalDocsExamined: 文檔掃描條目個(gè)數(shù)
executionStats.executionStages.stage: 掃描類型
executionStats.executionTimeMillis: 整體查詢時(shí)間
executionStats.executionStages.executionTimeMillisEstimate: 根據(jù)索引檢索文檔獲得數(shù)據(jù)的時(shí)間
executionStats.executionStages.inputStage.executionTimeMillisEstimate: 掃描索引所用時(shí)間
【serverInfo】
serverInfo.host: 主機(jī)名
serverInfo.port: 端口
serverInfo.version: 版本
serverInfo.gitVersion: git版本
【性能分析】
1、執(zhí)行時(shí)間
executionTimeMillis值越小越好
2、條目數(shù)量
最理想的狀態(tài)是: nReturned=totalKeysExamined=totalDocsExamined
3、stage類型
stage的類型列舉如下:
COLLSCAN:全表掃描 IXSCAN:索引掃描 FETCH:根據(jù)索引去檢索指定document SHARD_MERGE:將各個(gè)分片返回?cái)?shù)據(jù)進(jìn)行merge SORT:表明在內(nèi)存中進(jìn)行了排序 LIMIT:使用limit限制返回?cái)?shù) SKIP:使用skip進(jìn)行跳過 IDHACK:針對(duì)_id進(jìn)行查詢 SHARDING_FILTER:通過mongos對(duì)分片數(shù)據(jù)進(jìn)行查詢 COUNT:利用db.coll.explain().count()之類進(jìn)行count運(yùn)算 COUNTSCAN:count不使用Index進(jìn)行count時(shí)的stage返回 COUNT_SCAN:count使用了Index進(jìn)行count時(shí)的stage返回 SUBPLA:未使用到索引的$or查詢的stage返回 TEXT:使用全文索引進(jìn)行查詢時(shí)候的stage返回 PROJECTION:限定返回字段時(shí)候stage的返回
不希望看到包含如下的stage:
COLLSCAN(全表掃描) SORT(使用sort但是無index) 不合理的SKIP SUBPLA(未用到index的$or) COUNTSCAN(不使用index進(jìn)行count)
以上這篇基于MongoDB數(shù)據(jù)庫索引構(gòu)建情況全面分析就是小編分享給大家的全部內(nèi)容了,希望能給大家一個(gè)參考,也希望大家多多支持創(chuàng)新互聯(lián)。