我们维护一个从MongoDB提供数据的search服务。 我们的Mongo生产实例被安排在四个物理服务器上的一个4节点副本集中。
数据库由几个小集合和一个大集合组成。 大集合有以下特点：
在接下来的一年里，我们预计这个collections中的文献数量将增加一倍，达到7000万，collections量也会翻一番。
我意识到Mongo Reference Limits文档中的“Sharding Existing Collection Data Size”部分，它指定“ 对于保存文档的现有集合，MongoDB支持在任何包含小于256千兆字节数据的集合上启用分片，MongoDB可能是根据文档大小的分布，能够分割多达400千兆字节的集合 “。 因此，在达到256千兆字节的数据之前，我们希望能够碎片化。
我们在资源方面有一些限制，我们还没有（虚拟化）的位置。 但是，我们可以购买两台新服务器，总共可以生产六台生产机器。
我的问题是，是否有可能把Mongo分成两个分片，每个分片是一个只有六个物理服务器的三服务器复制集？ 我意识到，除了副本集，我们需要三个config服务器和一个mongos服务器？
我们是否应该分解？ 目前的内存使用量和连接数目目前都在可接受的水平之内。 有没有其他的策略可以使我们的数据库增长，而不涉及分片？
1）为什么你需要4个节点的副本集？ 在副本集中使用偶数个节点可能会非常成问题，因为发生故障转移时，节点之间会有一个select来决定哪个节点将成为主节点，请阅读http://docs.mongodb.org/manual /核心/副本集补选/
3个节点绰绰有余，2个实际的数据库节点和1个小的仲裁只是帮助选举
2）关于分片集群 – >具有2个分片的集群的物理服务器的最小数量，每个分片的最小副本集合为9（！），分割如下：分片1（副本集合）：2个数据节点+ 1仲裁（可以是微型实例）碎片2（副本集）：2个数据节点+ 1个仲裁（可以是微型实例）3个configuration服务器（必须!!） – 这些可以是相当小的机器 – 我们在亚马逊上使用t1.micro实例AWS。
要添加到群集中的每个分片将花费与上述相同的3个物理节点。
mongos – >这些是您的应用程序mongo驱动程序应该与之交互的客户端实例。 U可以将它们作为任何Web服务器的一部分部署，所以你不需要一个单独的机器。
看到这个更多的信息 – http://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/