前面的話

本文將詳細(xì)介紹MongoDB數(shù)據(jù)庫(kù)索引構(gòu)建情況分析

概述

創(chuàng)建索引可以加快索引相關(guān)的查詢，但是會(huì)增加磁盤(pán)空間的消耗，降低寫(xiě)入性能。這時(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ù)庫(kù)突然變慢或者有其他問(wèn)題的話，首先就要考慮采用mongostat來(lái)查看mongo的狀態(tài)

mongostat是查看mongodb運(yùn)行狀態(tài)的程序，使用方式如下

mongostat -h ip:port

【字段說(shuō)明】

insert/s : 每秒插入數(shù)據(jù)庫(kù)的對(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， 通過(guò)計(jì)算兩個(gè)1之間的間隔時(shí)間，可以大致了解多長(zhǎng)時(shí)間flush一次。flush開(kāi)銷(xiāo)是很大的，如果頻繁的flush，可能就要找找原因了
vsize： 虛擬內(nèi)存使用量，單位MB 
res: 物理內(nèi)存使用量，單位MB。 res會(huì)慢慢的上升，如果res經(jīng)常突然下降，要查看下是否有別的程序狂吃內(nèi)存
qr: 客戶端等待從MongoDB實(shí)例讀數(shù)據(jù)的隊(duì)列長(zhǎng)度
qw：客戶端等待從MongoDB實(shí)例寫(xiě)入數(shù)據(jù)的隊(duì)列長(zhǎng)度
ar: 執(zhí)行讀操作的活躍客戶端數(shù)量
aw: 執(zhí)行寫(xiě)操作的活客戶端數(shù)量。如果ar或aw數(shù)值很大，那么就是DB被堵住了，DB的處理速度不及請(qǐng)求速度。查看是否有開(kāi)銷(xiāo)很大的慢查詢。如果查詢一切正常，確實(shí)是負(fù)載很大，就需要加機(jī)器了
netIn:MongoDB實(shí)例的網(wǎng)絡(luò)進(jìn)流量
netOut：MongoDB實(shí)例的網(wǎng)絡(luò)出流量
conn: 打開(kāi)連接的總數(shù)，是qr,qw,ar,aw的總和
time:當(dāng)前時(shí)間

【實(shí)例】

插入100000條數(shù)據(jù)，并打開(kāi)mongostat查詢mongodb運(yùn)行狀態(tài)

由下圖看出，插入值insert值在插入數(shù)據(jù)時(shí)大量增加，在插入完畢后變成0。flush兩個(gè)1之間的間隔時(shí)間很長(zhǎng)，說(shuō)明性能還不錯(cuò)；res在慢慢上升，沒(méi)有出現(xiàn)突然下降的情況，說(shuō)明沒(méi)有其他的程序大量占用內(nèi)容的情況；qrw及arw數(shù)據(jù)很小，說(shuō)明數(shù)據(jù)庫(kù)讀寫(xiě)狀態(tài)正常，負(fù)載較小?？傮w而言，mongodb數(shù)據(jù)庫(kù)運(yùn)行狀態(tài)良好

profile

mongodb可以通過(guò)profile來(lái)監(jiān)控?cái)?shù)據(jù)，進(jìn)行優(yōu)化

【級(jí)別】

首先，要查看當(dāng)前是否開(kāi)啟profile功能

使用下面的命令會(huì)返回level等級(jí)，值為0|1|2，0代表關(guān)閉，即不記錄任何操作；1代表記錄慢命令(默認(rèn)值為100ms)，即記錄運(yùn)行時(shí)間超過(guò)100ms的操作；2代表全部，即記錄任何操作

db.getProfilingLevel() 

使用下面的命令可以設(shè)置level等級(jí)

db.setProfilingLevel() 

如下圖所示，默認(rèn)地，profile關(guān)閉。使用setProfilingLevel()方法以50ms慢命令的方式開(kāi)啟profile

【狀態(tài)】

操作被記錄到system.profile集合中

通過(guò)db.system.profile.find() 查看當(dāng)前的監(jiān)控日志

op:操作類(lèi)型
ns:命名空間
query:查詢字符串
responseLength:返回長(zhǎng)度
ts:時(shí)間
mills:執(zhí)行耗時(shí)

【使用】

在系統(tǒng)中開(kāi)啟profile之后，如果profile記錄的數(shù)據(jù)非常大，會(huì)比較明顯的降低系統(tǒng)的性能。因此，profile的使用場(chǎng)景一般是新系統(tǒng)上線之前的測(cè)試階段，以及剛上線時(shí)的觀察階段，查看數(shù)據(jù)庫(kù)的設(shè)計(jì)及應(yīng)用程序的使用是否正常。如果profile記錄了大量的字段，需要調(diào)整系統(tǒng)附在、調(diào)整索引等，減小它的大小

日志

在配置日志文件時(shí)，可以使用verbose參數(shù)來(lái)配置日志詳細(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)如何使用索引來(lái)加快檢索，同時(shí)可以針對(duì)性優(yōu)化索引

explain有三種模式，分別是：queryPlanner、executionStats、allPlansExecution?，F(xiàn)實(shí)開(kāi)發(fā)中，常用的是executionStats模式

首先，插入10萬(wàn)條數(shù)據(jù)

在time字段上建立索引

接著，尋找time范圍在100和200之間的文檔，并使用explain()

結(jié)果分為queryPlanner、executionStats和serverInfo三個(gè)部分。接下來(lái)，將分別對(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: 用來(lái)描述子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: 掃描類(lèi)型

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類(lèi)型

stage的類(lèi)型列舉如下：

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)行跳過(guò)
IDHACK：針對(duì)_id進(jìn)行查詢
SHARDING_FILTER：通過(guò)mongos對(duì)分片數(shù)據(jù)進(jìn)行查詢
COUNT：利用db.coll.explain().count()之類(lèi)進(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但是無(wú)index)
不合理的SKIP
SUBPLA(未用到index的$or)
COUNTSCAN(不使用index進(jìn)行count)

以上這篇基于MongoDB數(shù)據(jù)庫(kù)索引構(gòu)建情況全面分析就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論