我尝试比较分片配置与分片和复制的配置。
分片配置由 8 个分片组成，每个分片运行在三台不同的机器上，因此总共构成 24 个分片。所有这 8 个分片都在每台机器上的同一个分区中运行。
分片和复制版本与普通分片一样，同样有 8 个分片，并且所有 8 个mongod分片都在每台机器的同一分区上运行。但除此之外，这三台机器现在都在另一个分区上运行额外的 16 个线程，这些线程作为mongod在其他机器上运行的 8 个分片的辅助线程。这是我准备分片和复制配置的方式，其中数据块的复制因子为 3。
需要注意的是，一旦数据被加载，就不会被修改。因此，在主服务器和辅助服务器同步后，从哪一个服务器读取数据就无关紧要了。
为了运行查询，我使用一台完全不同的机器（我们称之为配置）mongos，这台机器的唯一目的是接收查询并在集群上运行它们。
与我的预期相反，每台机器上 8 个线程的简单分片（总计 = 3 * 8 = 24）的查询性能比分片 + 复制配置更好。
我编写了一个脚本来执行查询。因此，为了计时脚本，我使用time ./testScript并查看结果。我尝试通过登录到 config 和 run 的 mongo 来更改复制集群的读取首选项db.getMongo().setReadPref('secondary')，然后退出 shell 并运行查询，如time ./testScript。
问题是：
- 我在复制中哪里出错了？为什么它比普通分片版本慢？
db.getMongo().ReadPref('secondary')当我离开 shell 并尝试执行查询时，该操作还会持续存在吗？
所有四台机器都运行 Linux，我已经将 ulimit -n 从初始值 1024 增加到 2048，以允许更多连接。集合分布合理，所有 s 的mongod块数均相等。不用说，两种配置中的索引都是相同的。
硬件规格 - 架构：AMD64 - RAM：64 GB - 核心数：32