我的问题可能听起来太笼统，但我已准备好提供任何缺失的数据。
我们制作类似社交网络的东西。为了更好地提高读取性能并简化主实例的生命，我们设置了
readPreference=secondaryPreferred
在我们的replicaSet中。但是有了这个，不能保证在你从那里读取数据之前将数据写入辅助实例，所以我们必须设置
w=3
选项。 到目前为止，一切似乎都在工作，但我本地replicaSet上的测量显示以下插入统计信息。
Inserting 300 objects:
w=1 - 0.10s
w=3 - 1.31s
Insertion 5000 objects:
w=1 - 0.6s
w=3 - 14.6s
问题是，这是预期的差异，还是我做错了什么？
答案 0 :(得分：2)
性能上的差异是预期的，因为w = 3意味着除了来自主服务器的确认（w = 1）之外，您还要等待确认数据已成功复制到至少两个辅助服务器。
为清楚起见，w = 1只表示您希望主要确认操作已完成。如果发生重复密钥错误或网络错误等任何错误，将作为确认的一部分进行报告。
http://docs.mongodb.org/manual/reference/write-concern/
请参阅上面的链接，您可以看到有较低的写入问题，可让您以较低的延迟交易安全性。
如果您想要更高级别的耐久性或安全性，那么您可以使用j = 1等待确认您的操作已写入日志（允许从故障中恢复）。 w> N通过等待来自＆gt;的确认来增加安全性。 N个副本成员，以确保您的操作已成功复制到其他成员。 所以要明确，w＆gt; 1没有必要指示驱动程序写入副本。如果您决定使用w = N，请注意，如果副本集成员失败并且低于N，则可以使自己陷入困境。 =多数是一种更灵活的选择。
最后，您可能需要重新评估为什么要阅读辅助语言。当MongoDB使用异步复制时，辅助数据最终是一致的。如果您期望读取一致，那么从主要读取更有意义。如果您从辅助节点读取的原因是缩放，则应考虑分片，因为这是向外扩展的主要机制。在辅助节点上分配负载很少会提高可伸缩性。操作被复制到副本，因此您从较低的写入负载中获得的收益并不高。有时，分发不同类型的工作负载是有意义的（可能会带来更好的内存利用率）。例如，在辅助服务器上运行MR作业可能有意义。副本集主要用于高可用性 - 容错，提供自动故障转移和网络分区问题。