问更新与替换的Mongodb含义

EN

我读过this related question，但下面的是不同的。mongodb驱动程序在document集合类上有一个ReplaceOne方法(&一个异步对应方法)，该方法可用于替换符合c#参数的文档的全部内容。另一种方法是使用UpdateOne或UpdateMany方法(或异步方法)，这需要构建UpdateDefinition<TDocument>。

我的问题与选择其中一种方法而不是另一种方法(replace vs update)的含义有关，在您有足够的输入数据的情况下，可以选择其中一种方法来实现相同的结果。换句话说，如果我拥有整个原始文档，并且只希望更新其中的一小部分内容。

我能想到的第一个因素是发送到数据库服务器的有效负载。虽然我没有阅读任何mongodb c#驱动程序源代码，也找不到任何文档来验证这一点，但似乎ReplaceOne必须在更新操作中发送更多字节，特别是对于较大的文档。Update...方法似乎可以通过只发送需要修改的文档片段的更新元数据(以及两种方法都必须发送的过滤条件)来避免较小的负载。有人能证实这是否是一个准确的假设吗？

一位同事提出的另一个因素是，方法的选择(更新与替换)也会影响文档索引。这里的假设是，使用ReplaceOne可能会导致数据库为要更新的文档重新构建所有索引，而Update...方法具有足够的更改元数据信息，以避免在不属于更新定义中元数据的字段上重新构建索引。是否有人可以验证mongodb是否会根据文档是否使用replace与update进行修改而在内部以不同的方式处理文档索引构建？

第三个因素已经出现过几次了，关于Update<TDefinition>类上的AddToSet和PullFilter方法。似乎Update...方法不允许您通过同时向文档中添加项目和从文档中删除项目来修改文档(如json数组)中的集合；这些操作必须单独发送，使用两个单独的Update...方法调用和单独的Update<TDefinition>实例(尽管具有相同的过滤器参数)。在这种情况下，ReplaceOne方法似乎是在单个“事务”中更改此类文档的唯一方法，至少在使用C#驱动程序时是这样。我们目前使用Update...而不是ReplaceOne，因为我们不确定替代方案是否会像上面提到的那样对索引产生负面影响。

除了这些之外，还有什么其他的含义可能导致人们从ReplaceOne系列方法中选择而不是Update...系列方法，反之亦然？同样，这是假设您有足够的输入数据(即所有文档数据)来使用这两种方法实现相同的结果，不介意直接改变状态(通过替换)，也不介意构建mongo定义(通过更新)。