MongoDB：批量操作是否作为一个整体写入 oplog？

Question

当我在 MongoDB 3 中发出一个有序的批量操作时，是否将批量操作作为一个整体写入 oplog，以便在服务器崩溃后作为一个整体进行重播？

这个问题的基本原理如下：

我知道没有真正的事务，但我可以使用$isolated 关键字来获得一些读取一致性（在某些情况下）。 除了是否是良好的模式设计之外，让我们假设我必须一次更新可能不同集合中的多个文档，这将是 SQL 中的一个事务。我不关心数据在任何时候都处于不一致的状态，但是我确实要求数据最终是一致的。因此，虽然我可能不关心操作期间的错误和丢失的回滚，但我需要在某个时间点完全执行更新序列或根本不执行为了让它们在批量操作过程中遇到意外的服务器故障或关闭（例如，因为随机的 CoreOS 更新）。

Answer 1

我将带着一个一般性的警告进入这一点，我承认我什至没有看过结果，但基本原则似乎从一开始就对我有效。

您需要在这里考虑的是在一般调用中呈现的“漂亮的语法糖”的“幕后实际发生的事情”。这意味着基本上是查看您调用的操作的“命令形式”实际执行的操作。在这种情况下"update"。

因此，如果您已经查看过该链接，请考虑以下 "Bulk" 更新表单：

var bulk = db.collection.initializeOrdedBulkOp();

bulk.find({ "_id": 1 }).updateOne({ "$set": { "a": 1 } });
bulk.find({ "_id": 2 }).updateOne({ "$set": { "b": 2 } });

bulk.execute();

现在您已经知道这是作为 一个 请求发送到服务器的，但您可能没有考虑的是“幕后”发出的实际“请求”实际上是这样的：

db.runCommand({
    "update": "collection",
    "updates": [
        { "q": { "_id": 1 }, "u": { "$set": { "a": 1 } } },
        { "q": { "_id": 2 }, "u": { "$set": { "b": 2 } } }
    ],
    "ordered": true
})

因此，您在“更新”操作下的日志中实际看到的内容实际上类似于（从完整输出缩写为仅查询）：

{ "q": { "_id": 1 }, "u": { "$set": { "a": 1 } } }
{ "q": { "_id": 2 }, "u": { "$set": { "b": 2 } } }

因此，这意味着带有关联命令的每个操作都在 oplog 中，用于“重播”复制和/或您可能执行的其他操作，例如专门“重播”oplog 条目。

我可以确定这是实际发生的事情，甚至不用看，因为我知道驱动程序如何实现实际调用，并且每个调用都以这种方式保存在 oplog 中是有道理的。

因此“作为一个整体”，那么没有。这些不是“事务”，即使它们的提交和返回在单个请求中，它们也始终是不同的操作。但它们不是单一的操作，因此不会也不应该这样记录。