概述：
我们正在比较两种不同架构的create / read / write / rw性能：单个数据库与多个数据库（15k-25k）。
我们更喜欢使用Multi-DB架构，因为这样可以更容易地将客户（客户= 1公司）分开。但是，由于性能下降，我们担心这可能不是一个好的解决方案。
服务器规范：
单实例MongoDB服务器; 64GB RAM; 16核心; SSD HD
测试结果：
两种测试方案都具有相同的文档总数（文档大小大致相同）。变量是数据库的数量，每个数据库的集合和每个集合的文档。
所有测试均使用50个客户端线程（单独的机器）并行进行，读取/写入除外，它使用100（50R / 50W）。 'directoryPerDB'已启用。 （每个doc操作的所有时间都以毫秒为单位）
Test Creation Read Write Read/Write Notes
25000 DB 4 Coll 250 Doc 23ms 1-10ms 1-4ms 2-10ms Max 1400% CPU, noticeable "pauses" (CPU drops to 100%)
15000 DB 4 Coll 420 Doc 23ms 0.7-4ms 0.9-4ms 2-9ms Max 1400% CPU, noticeable "pauses" (CPU drops to 100%)
1 DB 4 Coll 125000 Doc 0.8ms 0.6ms 0.8ms 1.2-1.6ms Max 600% CPU, no pauses
结论：
当DB计数非常高时，定期间隔似乎会出现明显的性能下降。这可能是由于文件数量太多（25000个DB * 4个Colls * 2个文件= 200k个文件）或其他一些瓶颈。
在单DB测试中，CPU保持在600％左右并保持这一直到完成。在多DB测试中，CPU（峰值性能）介于800-1400％之间，但CPU经常下降到100％并暂停所有操作。这可以通过观察mongo日志以及发出R / W命令的测试客户端的日志来验证。
如果不是因为这些暂停，Multi-DB架构将比Single-DB快2倍，但是看起来存在一些无法避免的全局争用。
我希望有人可能知道这个全球争论是什么，并且（如果可能的话）如何解决它。