当我们被绑定到物理机器时，我们应该何时以及如何分割MongoDB？

Question

我们维护一个服务于MongoDB数据的搜索服务。我们的Mongo生产实例被安排在4个物理服务器上的4个节点副本集中。

数据库由几个小集合和一个大集合组成。大型收藏具有以下特点：

• 文件数量:3 500万份
• 平均文档大小：~4.2 kB
• 收藏大小: 151 GB
• storageSize: 157 GB

在今后一年里，我们预计这一收藏中的文件数量将增加一倍，达到7 000万，而且收集的文件数量将增加一倍。

我知道，在Mongo参考限文档的“对现有集合数据大小的切分”一节中，指定“对于保存文档的现有集合，MongoDB支持对包含小于256 as数据的任何集合进行分片。根据文档大小的分布，MongoDB可能能够分割多达400G的集合”。因此，我们希望在达到256千兆字节的数据之前将其分解。

我们在资源配置上有一些限制，而且我们还没有(还)处于虚拟化的地位。然而，我们处于这样一个位置，我可以购买两台新的服务器，使总数达到六台生产机器。

我的问题是，是否有可能将Mongo分割成两个碎片，其中每个都是一个3服务器副本集，只有6个物理服务器？我知道，除了复制集之外，我们还需要三个config服务器和一个mongos服务器？

我们应该切分吗？目前，我们的RAM使用量和连接数量都在可接受的范围内。我们是否可以采取其他不涉及切分的策略来实现数据库的增长呢？

Answer 1

1)为什么复制集需要4个节点？在复制集中使用偶数节点可能非常麻烦，因为当故障转移发生时，节点之间会进行选择，以决定哪些节点将成为主节点，请读取此-> http://docs.mongodb.org/manual/core/replica-set-elections/。

三个节点就足够了，两个实际的db节点和一个小套利来帮助选举。

2)对于碎片集群->，每片具有最小副本集的集群的最小物理服务器数为9(!)，拆分为: shard 1(复制集)：2个数据节点+1个仲裁器(可以是微实例)，碎片2(副本集)：2个数据节点+1个套利器(可以是微实例)、3个配置服务器(必须！！)--这些都可以是相当小的机器--我们在amazon上使用t1.microinstar。

想要添加到集群中的每个碎片都将花费更多的物理节点，如上面所示。

mongos -> --这些是应用程序mongo驱动程序应该与之交互的客户端实例。您可以将它们部署为任何web服务器的一部分，因此您不需要单独的机器。

有关更多信息，请参见此- http://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/