以您的方式更新时,您需要检索文档内容以检查它并进行此类修改。 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);
}
}
因此,与其为从查询中检索到的每个文档都向数据库发出请求,不如创建一个 List 的 WriteModel 操作。
一旦这个列表增长到一个合理的值(在这个例子中是 1000),你就可以在一个请求和所有批处理操作的响应中将写入操作提交给服务器。这里我们使用BulkWriteAsync。
如果您愿意,您可以创建大于 1000 的批次,但通常处理的数量是合理的。唯一真正的硬限制是 16MB 的 BSON 限制,因为所有请求实际上仍然是 BSON 文档,所以这仍然适用。无论如何,需要很多请求才能接近 16MB,但是在请求实际到达服务器时如何处理请求时,还需要考虑阻抗匹配,as documented:
"每组操作最多可以有1000个操作。如果一个组超过这个限制,MongoDB会将该组分成1000个或更少的更小的组。例如,如果批量操作列表包含2000个插入操作,MongoDB 创建 2 个组,每个组有 1000 个操作。”
因此,通过将请求大小保持在与服务器处理它的方式相同的级别,您还可以从yield 中受益,其中“多批次”实际上可以与服务器并行连接,而不是让服务器进行拆分和排队。
返回结果为BulkWriteResult,其中包含发送的一批操作中“匹配”和“修改”等的数量信息。
由于操作是“批量”的,因此在循环迭代结束时检查列表中是否存在更多“批量”操作是有意义的,然后当然以相同的方式提交。
还注意到IsOrdered = false 为BulkWriteOptions 意味着这批操作实际上并没有按串行顺序执行,这意味着服务器实际上可以“并行”运行任务。这可以在不需要承诺顺序的情况下进行“巨大”的速度改进。默认是“有序”提交,并按顺序提交。
这不是设置此选项所必需的,但如果您的订单不重要(在这种情况下不应该如此,因为这里没有其他操作请求取决于文档的先前修改),那么您获得的改进是值得的.
这就是“减少”向服务器发出的实际请求数。发送更新和等待响应需要时间,并且在大型操作中是一项非常昂贵的练习。这就是批量操作的目的,通过在一个请求中应用多个操作。
减少开销是“巨大”的性能提升。这就是你使用它的原因。