MongoDB排序时内存大小限制与创建索引的注意事项详解-数据库

在数据量超大的情形下,任何数据库系统在创建索引时都是一个耗时的大工程,下面这篇文章主要给大家介绍了关于MongoDB排序时内存大小限制与创建索引的注意事项的相关资料,需要的朋友可以参考下

参数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控制。
正常的解决方式是添加索引，但是索引要包括全部参与排序的字段，且要遵循前缀匹配策略。

到此这篇关于MongoDB排序时内存大小限制与创建索引注意事项的文章就介绍到这了,更多相关MongoDB排序内存限制内容请搜索编程学习网以前的文章希望大家以后多多支持编程学习网！