Mongo-读取偏好设计策略

Question

我有一个应用程序，我的任务是设计一个mongo支持的数据存储。

应用程序的目标是以最快的加载时间提供最新数据（无陈旧数据）。

数据大小约为数百万，应用程序写入量很大。

在选择给定3节点副本集（1个主副本集、1个辅助副本集、1个仲裁服务器）的读取策略时，我遇到了两种不同的策略来确定从哪里读取源-

>

从次级读取以减少主级的负载。使用Write关注=REPLICA_SAFE，从而确保写入在主级和次级上都完成。设置读取首选项。到次要首选项。

总是从小学开始读。但在读取之前，请确保数据处于原始状态。所以设置writeConcern=SAFE。读取首选项为默认值-primaryPreferred。

在选择其中一个选项之前，需要考虑哪些事情。

Answer 1

根据留档REPLICA_SAFE是一个不建议使用的术语，应该用REPLICA_ACKNOWLEDGED替换。这里的另一个问题是这里的w值似乎是这个常量的2。

这是您的配置的问题，因为您有主节点和只有一个辅助节点，并结合了一个仲裁器。如果节点出现故障或无法访问，级别设置为这样，它希望确认来自2个节点的所有写入，其中没有2个节点可用。您可以通过这种方式保留写入操作。

对于您的配置来说，最好的情况是多数，因为无论节点的数量如何，它都将确保写入主节点和“多数”辅助节点。但在您的情况下，如果一个节点关闭或不可用，任何涉及超过主节点的写问题都将阻止所有写操作，因为您必须至少有两个辅助节点可用，以便仍有“大多数”节点确认写操作。或者放弃仲裁器，拥有两个辅助节点。

因此，您必须坚持默认的w=1，其中所有写入都被确认给PRIMARY，除非您可以在一个SECONDARY出现故障时处理写入失败。

您可以将读取首选项设置为secondary preferred，只要您接受可以“可能”“是否读取过时数据的最新表示形式，因为唯一真正的保证是对主节点的写入。一般的复制注意事项仍然存在，即节点的处理能力应该在一定程度上相等，否则这可能会由于查询操作而导致延迟或总体性能下降。”。

请记住，复制是为了冗余而实现的，而不是提高性能的系统。如果您正在寻找性能，那么也许可以考虑扩展您的系统硬件或实现分片以分配负载。