線上服務的MongoDB中有一個很大的表,我查詢時使用了sort()根據某個欄位進行排序,結果報了下面這個錯誤:
[Error] Executor error during find command :: caused by :: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.
at line 0, column 0
這是個非常常見的MongoDB報錯了,因為MongoDB處理排序時,如果排序的欄位沒有建立索引,會把全表都丟到記憶體中處理,
If MongoDB cannot use an index or indexes to obtain the sort order, MongoDB must perform a blocking sort operation on the data. A blocking sort indicates that MongoDB must consume and process all input documents to the sort before returning results.
而記憶體的大小并不是無限使用的,MongoDB的默認設定是32MB,一旦資料量超過32MB,則會報錯,
引數internalQueryExecMaxBlockingSortBytes
32MB這個限制是在引數internalQueryExecMaxBlockingSortBytes中控制,你可以在MongoDB的客戶端上直接查看這個引數的值,執行以下陳述句:
db.runCommand({
getParameter: 1,
"internalQueryExecMaxBlockingSortBytes": 1
})
回傳如下結果:
// 1
{
"internalQueryExecMaxBlockingSortBytes": NumberInt("33554432"),
"ok": 1,
"operationTime": Timestamp(1651142670, 1),
"$clusterTime": {
"clusterTime": Timestamp(1651142670, 1),
"signature": {
"hash": BinData(0, "X09M2FBji5f+FOwaK/nLTv4+Ybs="),
"keyId": NumberLong("7080087363631710209")
}
}
}
所以解決排序時記憶體使用超過32MB的問題,有兩個方法:
- 給排序的欄位加索引,具體怎么加索引,會在后面細講,
- 修改internalQueryExecMaxBlockingSortBytes引數的大小,使用命令如下:
db.adminCommand({
setParameter: 1,
internalQueryExecMaxBlockingSortBytes: 104857600
})
MongoDB 4.3的internalQueryMaxBlockingSortMemoryUsageBytes
我準備在本地的MongoDB上復現這個問題,于是把這個表直接匯入到本地MongoDB中,結果發現排序時并沒有報錯,使用上面的命令查看internalQueryExecMaxBlockingSortBytes引數的值時,回傳如下結果:
[17][ProtocolError] no option found to get
Google了一下,發現了MongoDB的官方網站上的兩個相關JIRA,
第一個JIRA [SERVER-44053] Rename setParameter for maximum memory usage of blocking sort - MongoDB Jira里表示,在4.3.1版本時,因為引數命名描述不清楚,所以將引數internalQueryExecMaxBlockingSortBytes改為了internalQueryMaxBlockingSortMemoryUsageBytes,這解釋了為什么我執行查詢引數的陳述句時,沒有回傳結果,
第二個JIRA [SERVER-50767] internalQueryExecMaxBlockingSortBytes causing config exception on mongod load - Mongo中,Comments里提到了,新的internalQueryMaxBlockingSortMemoryUsageBytes引數,默認值從32MB改成了100MB,也許我的這個表使用100MB記憶體進行排序就夠用了,所以沒有報錯,

所以在4.3以上的版本(本機是5.0.4),執行以下命令:
db.runCommand({
getParameter: 1,
"internalQueryMaxBlockingSortMemoryUsageBytes": 1
})
可以看到查詢結果:
{
"internalQueryMaxBlockingSortMemoryUsageBytes": NumberInt("104857600"),
"ok": 1
}
而服務器上的MongoDB版本為4.0.3,因此是爆出來最上面的問題,
排序欄位如何加索引?
這是個很簡單的問題,你用哪個欄位排序,就對哪個欄位加索引就好了,比如我要根據A欄位進行排序,則增加A欄位的索引,
-- 加索引
db.bigMongoTable.createIndex({
"A": 1
});
-- 查詢
db.bigMongoTable.find({}).sort({
"A": 1
});
但是如果我改主意了,我要根據A、B兩個欄位做排序:
db.bigMongoTable.find({}).sort({
"A": 1,
"B": 1
});
那么熟悉的報錯就又回來了,
是的!機智的MongoDB并不會像我們想的那樣,先用上A的索引,從而省點力氣,他依舊會把全部的資料丟到記憶體里排序……
那我再加個B欄位的索引吧,畢竟在MongoDB查詢的時候,對兩個欄位分別建單鍵索引,靈活性比直接建一個復合索引要好一些,而且MongoDB的索引交集也可以讓這兩個單鍵索引實作和復合索引一樣的效果,
哦,不行喲,還是那個報錯,
所以,當多欄位排序時,你必須要建一個包含了這些欄位的復合索引,且要注意以下幾點:
- 查詢時參與排序的多個欄位的順序,要和創建的索引每個欄位的順序保持一致,比如你創建的索引是:
db.bigMongoTable.createIndex({"A":1,"B":1,"C":1});那么你的排序陳述句也要按照順序如下:sort({"A":1,"B":1,"C":1}),如果你調換A和B的順序,如下:sort({"B":1,"A":1,"C":1}),則索引不會生效, - 參與查詢的欄位少于索引的欄位,則要保證符合前綴匹配,還是第一點里的索引,如果排序陳述句是這樣:
sort({"A":1,"B":1}),則索引繼續生效,如果是這樣:sort({"A":1,"C":1}),則無法生效,這個你可以理解成和MySQL類似,索引都是按照最左匹配規則去觸發的,一條索引的中間部分跳過了就無效了, - 參與sort的欄位的排序方式,要和創建索引時的排序方式保持完全一致,或者完全相反,對于第一點里的索引,如果查詢
sort({"A":-1,"B":1})或者sort({"A":1,"B":-1}),索引則不會生效,只有在查詢sort({"A":1,"B":1})或者sort({"A":-1,"B":-1})時,索引才會生效,
總結
- MongoDB的查詢結果在進行排序時,如果排序欄位沒有添加索引,會將資料全部放到記憶體中計算,如果資料量過大,超過配置的記憶體大小,則會報錯,
- 4.3版本之前,使用記憶體的最大值通過引數internalQueryExecMaxBlockingSortBytes控制,默認為32MB,4.3版本之后,通過引數internalQueryMaxBlockingSortMemoryUsageBytes控制,
- 正常的解決方式是添加索引,但是索引要包括全部參與排序的欄位,且要遵循前綴匹配策略,
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/469866.html
標籤:其它
上一篇:【SDE】在ArcMap10.8.1、Oracle12102環境下配置SDE空間資料庫,并激活st_geometry
