Mongo最终的一致性如何处理大量的数据写入？

我有这样的流程：我有一个工人正在处理一个“大”批处理（比如1M记录）并将结果存储在Mongo中。Mongo最终的一致性如何处理大量的数据写入？

批处理完成后，会向Publish发送一条通知消息，然后将所有记录从Mongo中提取出来以供最终发布。

假设Worker写入过程已完成，即它已通过驱动程序将所有1M记录发送到Mongo。 Mongo是“最终一致的”，所以我不能100％保证所有记录都在通知发布时写入物理存储。

当发布做一个'查找'并获得一个游标持有批记录的集合时，游标是否足够聪明以处理最终的一致性？

因此，在实际条件下，让我们想象一下750,000条记录实际上是由Mongo在Notify Publish发生并发布时发现的。光标是否会遍历750,000条记录并停止或将会阻止或以其他方式处理剩余的250,000条记录，因为它们最终会写入磁盘（推测在发布第一个750K时很可能会发生这种情况）？

来源

2015-11-08 Greg

您确实意识到“最终一致性”是指主节点和辅助节点之间的复制过程，也是为什么主读应该是首选的原因，除非应用程序可以“随意”读取可能不是最适合的数据日期。你似乎在谈论外部工作者流程，因此并没有真正相关。 –

你在mongo配置中使用shardind，复制或者两者兼有 – Moes

我对这些关系并不十分清楚。我们有复制但不分片。在我的使用案例中，我确实需要发布者读取整个批次。如果需要他可以阻止，但需要所有。我可以做主要读取。所以我想我理解这个意思是说，如果我读小学，那么我没有问题。 – Greg

由于@BlakesSeven在评论中已经指出的那样，“最终一致性”指的是一个事实，即在复制环境中，当写入正在主完成后，它只会被写入次级最终。您可以通过将write concern设置为> 1来降低写入性能，从而修改此行为。将其设置为“多数”基本上保证即使在故障切换的情况下写入操作也是持久的 - 尽管在某些情况下（在某些情况下）性能下降。

一般来说这里是当你做一个写（简体）与启用日志记录会发生什么：

的操作检查是语法正确。
查询优化器将启动并执行其操作。（与这个问题无关，所以我没有提到细节）。
写操作应用于数据集的内存表示，称为“私有视图”。
每commitIntervalMs，私人视图会同步到日志，中位数为15或50毫秒，具体取决于写入问题。
同步时，该操作将应用于共享视图。 Iirc，这是连接将与新数据一起提供的点。

因此，为了确保数据可以被新连接读取，只需将发布通知延迟commitIntervalMs + 1，由于您的批处理大小很难察觉。

来源

2015-11-08 11:57:04

Mongo最终的一致性如何处理大量的数据写入？

回答

相关问题