MongoDB 提升效能的18原則(開發設計階段)

東山絮柳仔發表於2018-09-11

MongoDB 是高效能資料,但是在使用的過程中,大家偶爾還會碰到一些效能問題。MongoDB和其它關係型資料庫相比,例如 SQL Server 、MySQL 、Oracle 相比來說,相對較新,很多人對其不是很熟悉,所以很多開發、DBA往往是注重功能的實現,而忽視了效能的要求。其實,MongoDB和 SQL Server 、MySQL 、Oracle 一樣,一個 資料庫物件的設計調整、索引的建立、語句的優化,都會對效能產生巨大的影響。

為了充分挖掘MongoDB效能,現簡單總計了以下18條,歡迎大家一起來持續總結完善。

 

(1)  文件中的_id鍵推薦使用預設值,禁止向_id中儲存自定義的值。

    解讀:MongoDB文件中都會有一個“_id”鍵,預設是個ObjectID物件(識別符號中包含時間戳、機器ID、程式ID和計數器)。MongoDB在指定_id與不指定_id插入時      速度相差很大,指定_id會減慢插入的速率。

 

(2)  推薦使用短欄位名。

           解讀:與關係型資料庫不同,MongoDB集合中的每一個文件都需要儲存欄位名,長欄位名會需要更多的儲存空間。

 

(3)  MongoDB索引可以提高文件的查詢、更新、刪除、排序操作,所以結合業務需求,適當建立索引。

 

(4)  每個索引都會佔用一些空間,並且導致插入操作的資源消耗,因此,建議每個集合的索引數儘量控制在5個以內。

 

(5)  對於包含多個鍵的查詢,建立包含這些鍵的複合索引是個不錯的解決方案。複合索引的鍵值順序很重要,理解索引最左字首原則。

 

解讀:例如在test集合上建立組合索引{a:1,b:1,c:1}。執行以下7個查詢語句:

  1. db.test.find({a:”hello”})
  2. db.test.find({b:”sogo”, a:”hello”})
  3. db.test.find({a:”hello”,b:”sogo”, c:”666”})
  4. db.test.find({c:”666”, a:”hello”})
  5. db.test.find({b:”sogo”, c:”666”})
  6. db.test.find({b:”sogo” })
  7. db.test.find({c:”666”})
  • 以上查詢語句可能走索引的是1、2、3、4
  • 查詢應包含最左索引欄位,以索引建立順序為準,與查詢欄位順序無關。
  •  最少索引覆蓋最多查詢。

 

(6) TTL 索引(time-to-live index,具有生命週期的索引),使用TTL索引可以將超時時間的文件老化,一個文件到達老化的程度之後就會被刪除。

解讀:建立TTL的索引必須是日期型別。TTL索引是一種單欄位索引,不能是複合索引。TTL刪除文件後臺執行緒每60s移除失效文件。不支援定長集合。

 

(7) 需要在集合中某欄位建立索引,但集合中大量的文件不包含此鍵值時,建議建立稀疏索引。

解讀:索引預設是密集型的,這意味著,即使文件的索引欄位缺失,在索引中也存在著一個對應關係。在稀疏索引中,只有包含了索引鍵值的文件才會出現。

 

(8)  建立文字索引時欄位指定text,而不是1或者-1。每個集合只有一個文字索引,但是它可以為任意多個欄位建立索引。

解讀:文字搜尋速度快很多,推薦使用文字索引替代對集合文件的多欄位的低效查詢。

 

(9)  使用findOne在資料庫中查詢匹配多個專案,它就會在自然排序檔案集合中返回第一個專案。如果需要返回多個文件,則使用find方法。

 

(10) 如果查詢無需返回整個文件或只是用來判斷鍵值是否存在,可以通過投影(對映)來限制返回欄位,減少網路流量和客戶端的記憶體使用。

解讀:既可以通過設定{key:1}來顯式指定返回的欄位,也可以設定{key:0}指定需要排除的欄位。

 

(11)  除了字首樣式查詢,正規表示式查詢不能使用索引,執行的時間比大多數選擇器更長,應節制性地使用它們。

 

(12) 在聚合運算中,$match 要在 $ group前面,通過 $match 前置,可以減少$ group 操作符要處理的文件數量。

 

(13) 通過操作符對文件進行修改,通常可以獲得更好的效能,因為,不需要往返伺服器來獲取並修改文件資料,可以在序列化和傳輸資料上花費更少的時間。

 

(14) 批量插入(batchInsert)可以減少資料向伺服器的提交次數,提高效能。但是批量提交的BSON Size不超過48MB。

 

(15) 禁止一次取出太多的資料進行排序,MongoDB目前支援對32M以內的結果集進行排序。如果需要排序,請儘量限制結果集中的資料量。

 

(16) 查詢中的某些$操作符可能會導致效能低下,如$ne,$not,$exists,$nin,$or,儘量在業務中不要使用。

a)   $exist:因為鬆散的文件結構導致查詢必須遍歷每一個文件;

b)   $ne:如果當取反的值為大多數,則會掃描整個索引;

c)   $not:可能會導致查詢優化器不知道應當使用哪個索引,所以會經常退化為全表掃描;

d)   $nin:全表掃描;

e)   $or:有多個條件就會查詢多少次,最後合併結果集,應該考慮裝換為$in。

 

(17) 固定集合可以用於記錄日誌,其插入資料更快,可以實現在插入資料時,淘汰最早的資料。需求分析和設計時,可考慮此特性,即提高了效能,有省去了刪除動作。

     解讀:固定集合需要顯式建立,指定Size的大小,還能夠指定文件的數量。集合不管先達到哪一個限制,之後插入的新文件都會把最老的文件移出。

 

(18) 集合中文件的資料量會影響查詢效能,為保持適量,需要定期歸檔。

 

本文版權歸作者所有,未經作者同意不得轉載,謝謝配合!!!

相關文章