【问题标题】:How to increase performance of the update operation in Mongo?如何提高 Mongo 更新操作的性能?
【发布时间】:2016-04-01 06:35:18
【问题描述】:
foreach (var doc in await records.Find(filter).ToListAsync())
{
    var query = Builders<JobInfoRecord>.Filter.Eq("JobTypeValue", doc.JobTypeValue);
    var updatedJobInfo = Regex.Replace(doc.SerializedBackgroundJobInfo, pattern, "<$1></$1>");
    var update = Builders<JobInfoRecord>.Update.Set("SerializedBackgroundJobInfo", updatedJobInfo);

    records.UpdateOneAsync(query, update).Wait();
}

这是更新文档的最佳方式(我已将名称中包含 password 的 xml 字符串中的标签值更改为空标签:​&lt;adminPassword&gt;&lt;/adminPassword&gt;demo )?我正在使用 Mongo 驱动程序 2.0.2

我有一个包含500 000 文档的集合,我每分钟(希望)大约执行一次更新。 3000 文件。

如何提高update 操作的性能?

【问题讨论】:

  • 那么如果不是 BSON,您认为正则表达式如何应用?换句话说,当您向服务器发送请求时,您的两个表达式实际上是完全相同的。 RegexReplace 当然是完全不同的事情,因为这只能发生在客户端。但是你应该以任何形式使用“bulkWrite”而不是UpdateOne,因为你可以在一个请求中发送1000个而不是一个发送等待一个响应,在一个循环中一遍又一遍。
  • 你能告诉我如何使用bulkWrite而不是UpdateOneAsync吗?
  • 为什么会更快?

标签: c# mongodb performance


【解决方案1】:

以您的方式更新时,您需要检索文档内容以检查它并进行此类修改。 MongoDB 没有以您想要的方式作用于现有值的原子操作,因此当然需要迭代。

在两个版本的语句之间如何匹配正则表达式的“查询”部分没有真正的区别。无论如何,内容在发送到服务器之前都会转换为 BSON,因此如果您使用标准表达式构建器或直接 BSON 文档,则影响不大。

但是关于可以进行的性能改进。

使用批量操作更新


如上所述,批量操作是您应该在此类列表迭代中更新的方式,并且您还“应该”使用游标而不是将所有结果转换为列表,因为它会节省内存。

避开所有特定的类型声明,只表示为BsonDocument(这可能会为您节省编组,但不需要),那么基本的示例过程将是:

var pattern = @"(?si)<([^\s<]*workUnit[^\s<]*)>.*?</\1>";
var filter = Builders<JobInfoRecord>.Filter.Regex(x => x.SerializedBackgroundJobInfo,
                                              new BsonRegularExpression(pattern, "i"));


var ops = new List<WriteModel<BsonDocument>>();
var writeOptions = new BulkWriteOptions() { IsOrdered = false };

using ( var cursor = await records.FindAsync<BsonDocument>(filter))
{
    while ( await cursor.MoveNextAsync())
    {
        foreach( var doc in cursor.Current )
        {
            // Replace inspected value
            var updatedJobInfo = Regex.Replace(doc.SerializedBackgroundJobInfo, pattern, "<$1></$1>");

            // Add WriteModel to list
            ops.Add(
                new UpdateOneModel<BsonDocument>(
                    Builders<BsonDocument>.Filter.Eq("JobTypeValue", doc.JobTypeValue),
                    Builders<BsonDocument>.Update.Set("SerializedBackgroundJobInfo", updatedJobInfo)
                )
            );

            // Execute once in every 1000 and clear list
            if (ops.Count == 1000)
            {
                BulkWriteResult<BsonDocument> result = await records.BulkWriteAsync(ops,writeOptions);
                ops = new List<WriteModel<BsonDocument>>();
            }
        }
    }

    // Clear any remaining
    if (ops.Count > 0 )
    {
        BulkWriteResult<BsonDocument> result = await records.BulkWriteAsync(ops,writeOptions);
    }

}

因此,与其为从查询中检索到的每个文档都向数据库发出请求,不如创建一个 ListWriteModel 操作。

一旦这个列表增长到一个合理的值(在这个例子中是 1000),你就可以在一个请求和所有批处理操作的响应中将写入操作提交给服务器。这里我们使用BulkWriteAsync

如果您愿意,您可以创建大于 1000 的批次,但通常处理的数量是合理的。唯一真正的硬限制是 16MB 的 BSON 限制,因为所有请求实际上仍然是 BSON 文档,所以这仍然适用。无论如何,需要很多请求才能接近 16MB,但是在请求实际到达服务器时如何处理请求时,还需要考虑阻抗匹配,as documented

"每组操作最多可以有1000个操作。如果一个组超过这个限制,MongoDB会将该组分成1000个或更少的更小的组。例如,如果批量操作列表包含2000个插入操作,MongoDB 创建 2 个组,每个组有 1000 个操作。”

因此,通过将请求大小保持在与服务器处理它的方式相同的级别,您还可以从yield 中受益,其中“多批次”实际上可以与服务器并行连接,而不是让服务器进行拆分和排队。

返回结果为BulkWriteResult,其中包含发送的一批操作中“匹配”和“修改”等的数量信息。

由于操作是“批量”的,因此在循环迭代结束时检查列表中是否存在更多“批量”操作是有意义的,然后当然以相同的方式提交。

还注意到IsOrdered = falseBulkWriteOptions 意味着这批操作实际上并没有按串行顺序执行,这意味着服务器实际上可以“并行”运行任务。这可以在不需要承诺顺序的情况下进行“巨大”的速度改进。默认是“有序”提交,并按顺序提交。

这不是设置此选项所必需的,但如果您的订单不重要(在这种情况下不应该如此,因为这里没有其他操作请求取决于文档的先前修改),那么您获得的改进是值得的.

这就是“减少”向服务器发出的实际请求数。发送更新和等待响应需要时间,并且在大型操作中是一项非常昂贵的练习。这就是批量操作的目的,通过在一个请求中应用多个操作。

减少开销是“巨大”的性能提升。这就是你使用它的原因。

【讨论】:

  • 你的意思是我需要在Builders中使用JobInfoRecord而不是BsonDocument
  • @Anatoly 它是可互换的,或者至少应该是可以互换的,所以您应该可以使用其中任何一个。不过,我的实际陈述是相反的,因为在我看来,将 BSON 编组为特定成本是有“成本”的,这似乎是合乎逻辑的。因此,出于“快速迭代”的目的,我怀疑至少在“光标”迭代器(可能还有其他地方)中的 BsonDocument 会为您节省一些 CPU 周期。像这样的事情加起来会出现在大型列表中。
  • 为什么在if (ops.Count == 1000) 中选择1000 元素?你对这个号码有什么建议吗?
  • @Anatoly 将解释添加到答案正文中。
猜你喜欢
  • 1970-01-01
  • 2019-10-29
  • 2016-11-01
  • 2018-04-06
  • 1970-01-01
  • 2021-11-10
  • 1970-01-01
  • 1970-01-01
  • 2023-03-13
相关资源
最近更新 更多