我的应用程序写入非常低。因此，我对部署mongo安装感兴趣，该安装最大化了我拥有的硬件的读取吞吐量（在一个位置有3个数据库服务器）。我并不真正关心冗余（备份），但希望自动进行故障转移。另外，我对“最终一致性”很好，并且不介意是否返回不是最新数据的数据。
我已经查看了分片和副本集，据我所知，我并不需要使用分片，因为它的好处更适合具有许多写入的应用程序。 因此，我继续在我拥有的三台服务器上安装了一个副本集，然后我将读取首选项设置为“最近”，因为这样可以在任何服务器上进行读取。
问题是，我后来读到客户端是“粘性的”，基本上一旦它选择了“最近的”mongo服务器，它就不太可能改变它。此外，即使再次“检查最近的”，它也可能选择相同的一个。这几乎导致主动/被动配置，没有任何负载平衡。我有两个应用程序服务器，所以如果他们选择不同的mongo服务器，它可能会正常工作，但是我想在副本集中有超过3个mongo服务器，那么除了特定的两个服务器之外的任何服务器都是被动的。
基本上我的问题是，为部署进行主动/主动配置的最佳方法是什么？我想要的只是请求免费的mongo服务器而不是繁忙的服务器。
强制执行此操作的一种方法是创建三个分片群集（每个服务器参与所有三个群集），其中每个服务器都是其中一个群集中的主要群集 - 但这仍然不是最佳的，因为除了此配置中涉及的相对复杂性，这也不能保证完全负载平衡（例如，如果在给定时刻的所有请求碰巧转到一个特定的分片）。
实现我想要的正确方法是什么？如果用mongo无法实现这种负载均衡，你会建议我使用分片群集解决方案吗？
答案 0 :(得分：2)
正如您已经怀疑的那样，缩放读取不是“一刀切”的问题。一切都取决于您的数据，访问模式，您的要求以及您可以确定的其他一些事项。
简而言之，要考虑的主要问题是为什么单个服务器无法处理您的读取负载。如果是因为数据集的大小和索引的大小，那么在三个分片中分割数据将减少每个分片的RAM要求（或者换句话说它将为您提供所有三个系统的组合RAM） 。只要您选择一个好的分片密钥（一个可以在所有系统中大致均匀分配负载的密钥），您将获得几乎三倍于目标查询的吞吐量。
如果您的读取的主要要求是尽可能地减少读取数据的延迟，那么副本集可以很好地满足您的目的，因为从“最近”节点读取将减少网络往返时间而不会更改MongoDB服务器上的操作持续时间。这假设您的写入不经常发生，或者您的应用程序容忍可能过时的数据。