0

我在 Linux 机器上安装了一个独立的 mongo。该数据库包含一个包含 1.81 亿个文档的集合。该集合是迄今为止数据库中最大的集合（大约 90%）。集合的大小目前为 3.5 TB。我正在运行 Mongo 版本 4.0.10 (Wired Tiger)

该集合有 2 个索引。

  • 身份证上的一个
  • 一对 2 字段，在删除文档时使用（请参阅下面的片段中的那些）。

在此集合上对批量删除进行基准测试时，我们使用了以下代码段

db.getCollection('Image').deleteMany(
{$and: [
{"CameraId" : 1}, 
{"SequenceNumber" : { $lt: 153000000 }}]})

为了查看删除操作的状态，我运行了一个删除 1000 个文档的简单测试，同时使用 currentOp() 查看操作。它显示以下内容。

"command" : {
                "q" : {
                    "$and" : [ 
                        {
                            "CameraId" : 1.0
                        }, 
                        {
                            "SequenceNumber" : {
                                "$lt" : 153040000.0
                            }
                        }
                    ]
                },
                "limit" : 0
            },
            "planSummary" : "IXSCAN { CameraId: 1, SequenceNumber: 1 }",
            "numYields" : 876,
            "locks" : {
                "Global" : "w",
                "Database" : "w",
                "Collection" : "w"
            },
            "waitingForLock" : false,
            "lockStats" : {
                "Global" : {
                    "acquireCount" : {
                        "r" : NumberLong(877),
                        "w" : NumberLong(877)
                    }
                },
                "Database" : {
                    "acquireCount" : {
                        "w" : NumberLong(877)
                    }
                },
                "Collection" : {
                    "acquireCount" : {
                        "w" : NumberLong(877)
                    }
                }
            }

它似乎使用了正确的索引，但锁的数量和类型让我担心。正如我所解释的那样，它为单个集合中的每个已删除文档获取 1 个全局锁。

使用这种方法时，它需要一个多星期的时间来删除 4000 万份文档。这是无法预期的表现。

我意识到存在其他设计，例如将文档打包成更大的块并使用 GridF 存储它们，但当前的设计就是这样，我想确保在更改我的设计或重组数据甚至考虑之前我看到的内容是预期的聚类等

关于如何提高批量删除性能的任何建议，或者这是预期的吗？

4

0 回答 0