Mongodb SaaS单数据库与多数据库

Question

我知道这个问题以前已经发过了，虽然没有得到彻底的回答。而且，我认为这仍然取决于问题的参数。假设您有一个SaaS服务，其中包含一个lot，但是每个客户的数据量相对较小，那么拥有一个数据库可能是有意义的。

如果你的客户长期不会在数千人的范围内发生什么事情(例如。100在一个非常好的场景中)，从5-6开始，但是这次每个客户都有大量的数据(例如。收集和处理大量数据的商业情报服务)。给您一个提示，25 -50 of的数据处理(分析和其他东西)每个客户最初，作为一个开始，然后增加约10 of每名客户。

如果您沿着单db的路径走下去，那么使用特定字段(当然是索引)将数据标记到客户，然后依赖于复制和分片系统，这非常简单，这要归功于mongo。我假设(还没有测试过，如果您有这种情况，请分享一些见解)，在一个针对索引字段的切分集合中，查询查找时间应该很快。但是，假设您现在添加另一个客户，另一个50 GBs (分布在8-10个集合中，因此有数百万项/集合)。你要么必须: 1)删除索引并重建它们(我想这是最糟糕的，因为系统实际上是无法使用的) 2)不要删除并插入索引(这将花费很长时间)，系统将响应3)，我认为在一个复制集中，删除一个节点，删除索引，与新客户更新，带回索引，然后让它加入复制集，以便它们可以开始同步。

另一方面，如果您的为每个客户一个db，则可以相对快速地完成添加或删除操作，因为系统实际上将其客户隔离开来，行仍在数百万的范围内，但不接近10亿，这是很好的，而且查找时间明显较快。无论您在这种情况下做什么，在实现方面都要容易得多，而且要快得多，这仅仅是因为您将始终使用一个相对较小的数字，而不是单个db。然而，当涉及到维护(复制和分片，因为您将继续为每个客户添加更多数据)时，这将是一个摩擦，在这种情况下，我可能会假设您必须在单独的机器/实例中物理隔离dbs，因为操作系统对打开文件的数量有限制，当然，由于多个dbs中的多个同时连接，会产生额外的开销。

如果我错过了什么，请给我一些启发，但我最感兴趣的是听取其他有关这方面的意见.

谢谢

Answer 1

如果你住在几百个低客户中，我建议你给每个客户一个数据库，如果你期望的客户更多的话，按客户收取。(每个数据库都有一些开销，您不希望为成千上万的DB所花费。)

请注意，您的想法是：“我认为在复制集中删除一个节点，删除索引，使用新客户进行更新，带回索引，然后让它加入副本集，以便它们可以开始同步。”不会运行，因为在副本集中，只有主服务器才能进行写操作。