我们维护一个搜索服务，该服务提供来自 MongoDB 的数据。我们的 Mongo 生产实例分布在四台物理服务器上的 4 节点副本集中。
该数据库由几个小馆藏和一个大馆藏组成。大馆藏具有以下特点：
- 文档数量：3500万
- 平均文档大小：~4.2 kB
- 收藏大小：151 GB
- 存储大小：157 GB
我们预计，明年该馆藏的文件数量将增加一倍至约 7000 万份，馆藏规模也将扩大一倍。
我意识到“分片现有集合数据大小”部分Mongo 引用限制文件中规定，“对于包含文档的现有集合，MongoDB 支持对包含少于 256 GB 数据的任何集合启用分片。MongoDB 可能能够对包含多达 400 GB 数据的集合进行分片，具体取决于文档大小的分布“。因此，我们希望在达到 256 GB 的数据之前就进行分片。
我们的资源有限，目前还无法实现虚拟化。不过，我可以购买两台新服务器，这样生产机器总数就达到六台。
我的问题是，是否可以将 Mongo 拆分为两个分片，每个分片都是一个只有六台物理服务器的 3 服务器副本集？我意识到除了副本集之外，我们还需要三台config服务器和一台mongos服务器？
我们是否应该进行分片？我们当前的 RAM 使用率和连接数目前都在可接受的水平之内。我们是否可以采用其他策略来让我们的数据库在不涉及分片的情况下增长？
答案1
1) 为什么副本集需要 4 个节点？在副本集中使用偶数个节点可能会非常成问题，因为当发生故障转移时，节点之间会进行选举来决定哪个节点将成为主节点，请阅读此内容 ->http://docs.mongodb.org/manual/core/replica-set-elections/
3 个节点绰绰有余，2 个实际数据库节点和 1 个仅用于帮助选举的小型仲裁节点
2）关于分片集群->具有 2 个分片且每个分片的最小副本集的集群的物理服务器最小数量为 9(!)，拆分如下：分片 1（副本集）：2 个数据节点 + 1 个仲裁服务器（可以是微型实例）分片 2（副本集）：2 个数据节点 + 1 个仲裁服务器（可以是微型实例）3 个配置服务器（必须！！）-这些可以是相当小的机器 - 我们在亚马逊 AWS 上使用 t1.micro 实例。
您想要添加到集群的每个分片都将花费您如上所述的 3 个以上的物理节点。
mongos -> 这些是您的应用程序 mongo 驱动程序应该与之交互的客户端实例。您可以将它们部署为任何 Web 服务器的一部分，因此您不需要单独的机器。
请参阅此处了解更多信息 -http://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/