我知道这个问题之前已经发布过，但没有得到彻底的回答。另外我认为它仍然取决于问题参数。假设您有一个拥有大量客户的 SaaS 服务，但每个客户的数据量相对较少，因此拥有一个数据库可能是有意义的。
如果您的客户长期不在数千个范围内（例如，在非常好的场景中为 100 个）并且从 5 到 6 个开始，但这次您每个客户有大量数据（例如，商业智能服务），会发生什么情况它聚合和处理大量数据）。给你一个提示，最初每个客户需要处理 25-50GB 的数据（分析和其他东西），然后每个客户每年增加大约 10GB。
如果您沿着单个 db的路径前进，那么您将数据标记给具有特定字段（当然是索引）的客户，然后依赖复制和分片多亏了mongo，这个系统非常简单。我假设（尚未测试，如果您有这种情况，请分享一些见解）在针对索引字段的分片集合中查询查找时间应该很快。但是，假设您现在添加了另一个客户，另外 50 GB（分布在 8-10 个集合中，因此有数百万个项目/集合）。您要么必须：1）删除索引并重建它们（我想这是最糟糕的，因为系统实际上变得不可用）2）不要删除并插入索引（这将永远需要），系统将响应 3）我会认为副本集删除一个节点，删除索引，更新新客户，带回索引，然后让它加入副本集，以便他们可以开始同步。
另一方面，如果每个客户有一个数据库，则添加或删除可以相对快速地完成，因为系统实际上隔离了它的客户，行仍然在数百万但不接近十亿的范围内，这很好并且查找时间显然很快。无论您在这种情况下做什么，它在实现方面都更加容易和快捷，因为您将始终使用比单个 db 的情况相对较小的数量。但是，在维护方面（复制和分片，因为您将不断为每个客户添加更多数据），这将是一个摩擦当然，在这种情况下，我可能会假设您必须在单独的机器/实例中物理隔离数据库，因为操作系统对打开文件的数量有限制，当然，由于多个数据库中的多个同时连接会产生额外的开销.
如果我错过了什么，请做一些说明，但我最感兴趣的是听到关于此的其他意见......
谢谢