Mongodb效能調優

摘要

1. mongodb 適用場景簡介

2. mongodb 效能監控與分析

3. mongodb 效能優化建議

關於mongodb的幾個大事件

1.根據美國資料庫知識大全官網發布的db熱度排行，mongodb的熱度排名從2023年的第5名，在2023年躍公升為第4名，僅次於主流db（oracle、mysql、sqlserver）之後。

2.2015第六屆中國資料庫技術大會(dtcc)上，mongodb高調宣布收購開源引擎wiredtiger，效能在3.0版本上實現了7~10倍的提公升。

mongodb 適用場景簡介

適用場景

1. 實時的cru操作，如**、論壇等實時資料儲存

2. 高伸縮性，可以分布式集群，動態增刪節點

3. 儲存大尺寸、低價值資料

4. 快取

5. bson結構物件儲存

不適用場景

1. 高度事務性操作，如銀行或會計系統

2. 傳統商業智慧型應用，如提供高度優化的查詢方式

3. 需要sql的問題

4. 重要資料，關係型資料

mongodb 效能監控與分析

mongostat

1. faults/s：每秒訪問失敗數，即資料被交換出物理記憶體，放到swap。

若過高（一般超過100），則意味著記憶體不足。

si：每秒從磁碟讀入虛擬記憶體的大小，若大於0，表示物理記憶體不足。

so：每秒虛擬記憶體寫入磁碟的大小，若大於0，同上。

mongostat

2. idx miss %：btree 樹未命中的比例，即索引不命中所佔百分比。

若過高，則意味著索引建立或使用不合理。

db.serverstatus()

indexcounters」 :

mongostat

3. locked %：全域性寫入鎖占用了機器多少時間。當發生全域性寫入鎖時，所有查詢操作都將等待，直到寫入鎖解除。

若過高（一般超過50%），則意味著程式存在問題。

db.currentop()

mongostat

4. q r|w ：等待處理的查詢請求佇列大小。

若過高，則意味著查詢會過慢。

db.serverstatus()

「currentqueue」 :

mongostat

5. conn ：當前連線數。

高併發下，若連線數上不去，則意味著linux系統核心需要調優。

db.serverstatus()

「connections」 :

6.連線數使用記憶體過大

shell> cat /proc/$(pidof mongod)/limits | grep stack | awk -f 'size'
''

將連線數使用linux棧記憶體設小，預設為10mb（10240）

shell> ulimit -s 1024

優化器profile

db.setprofilinglevel(2);

0 – 不開啟

1 – 記錄慢命令 (預設為》100ms)

2 – 記錄所有命令

info: #本命令的詳細資訊

reslen: #返回結果集的大小

nscanned: #本次查詢掃瞄的記錄數

nreturned: #本次查詢實際返回的結果集

millis: #該命令執行耗時(毫秒)

表knowledgeanswer未建立有效索引（建議考慮使用組合索引）

存在大量慢查詢，均為表knowledgeanswer讀操作，且響應超過1秒

每次讀操作均為全表掃瞄，意味著耗用cpu(25% * 8核)

每次返回的記錄位元組數近1kb，建議過濾不必要的字段，提高傳輸效率

執行計畫explain

db.test.find().hint().explain();

cursor: 返回游標型別(basiccursor 或 btreecursor)

nscanned: 被掃瞄的文件數量

n: 返回的文件數量

millis: 耗時(毫秒)

indexbounds: 所使用的索引

在查詢條件、排序條件、統計條件的字段上選擇建立索引

db.student.ensureindex( , );

注意：

 最新或最近記錄查詢，結合業務需要正確使用索引方向：逆序或順序

 建議索引建立操作置於後台執行，降低影響

 實際應用過程中多考慮使用復合索引

 使用limit()限定返回結果集的大小，減少資料庫伺服器的資源消耗，以及網路傳輸的資料量

db.posts.find().sort().limit(10);

只查詢使用到的字段，而不查詢所有字段

db.posts.find().sort().limit(10);

基於mongodb分布式集群做資料分析時，mapreduce效能優於count、distinct、group等聚合函式

mongodb 3.0.x版本效能較mongodb 2.0.x有7-10倍提公升，引入wiredtiger新引擎，同時支援mmapv1記憶體對映引擎

注意：

 預設mmapv1，切換至wiredtiger：mongod –dbpath /usr/local/mongodb/data –storageengine wiredtiger

備註：若更換新引擎，則之前使用舊引擎建立的db資料庫無法使用。建議先通過mongodb的同步機制，將舊引擎建立的db資料同步到從庫，且從庫使用新引擎.

 選擇 windows 2008 r2 x64 或 linux x64，linux版本效能優於 windows，建議基於linux系統進行架構選型

 根據rhel版本號選擇mongodb相應linux版本

 mongodb driver 與 mongodb 版本一致

最後的建議

哪一種物理設計更適合mongodb：正規化化 & 反正規化化 & 業務 ?

 正規化化設計的思想是「完全分離」，存在關聯查詢，查詢效率低，但寫入、修改、刪除效能更高

 反正規化化設計的思想是「資料集中儲存」，查詢效率高，而mongodb對查詢機制支援較弱，看似成為一種互補

下面我們來看乙個圖書資訊db表設計案例：

示例1：正規化化設計

分析：更新效率高，因為不需要關聯表操作。比如更新作者年齡，只需要更新作者資訊1張表就可以了。而查詢效率低，因為需要關聯表操作。比如檢視某本圖書的作者簡介，需要先查圖書資訊表以獲取作者id，再根據id，在作者資訊表中查詢作者簡介資訊。

示例2：反正規化化設計

,,,
]}

分析：將作者簡介資訊嵌入到圖書資訊表中，這樣查詢效率高，不需要關聯表操作。依然是更新作者年齡，此時更新效率就顯得低，因為該作者出過多本書，需要修改多本圖書資訊記錄中該作者的年齡。

示例3：不完全正規化化設計

,,,
]}

分析：其實我們知道某本書的作者姓名是不會變化的，屬於靜態資料，又比如作者的年齡、收入、關注度等，均屬於動態資料，所以結合業務特點，圖書資訊表肯定是查詢頻率高、修改頻率低，故可以將一些作者的靜態資料嵌入到圖書資訊表中，做乙個折中處理，這樣效能更優。

總結：mongodb效能調優不是最終或最有效的手段，最高效的方法是做出好的物理設計。而什麼樣的物理設計適合mongodb，最後還是由當前業務及業務未來發展趨勢決定的。最後送給大家一句話「好的效能不是調出來的，更多是設計出來的」！

Mongodb效能調優

調優 Nginx效能調優

Spark效能調優 JVM調優

七 Spark效能調優 Shuffle 調優

Mongodb效能調優

調優 Nginx效能調優

Spark效能調優 JVM調優

七 Spark效能調優 Shuffle 調優

相關推薦