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