MongoDB 提升效能的18原則

MongoDB · 發表 2018-09-11 23:43:00

摘要：（1）文件中的_id鍵推薦使用預設值，禁止向_id中儲存自定義的值。解讀：MongoDB文件中都會有一個“_id”鍵，預設是個ObjectID物件（識別符號中包含時間戳、機器ID、程序ID和計數器）。MongoDB在指定_id與不指定_id插入時速度相差很大，指定_id會...

（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個查詢語句：

（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）集合中文件的資料量會影響查詢效能，為保持適量，需要定期歸檔。

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