MongoDB中针对多租户数据库的推荐方法是什么？

Question

我正在考虑使用MongoDB创建一个多租户应用。关于我还有多少租户，我没有任何猜测，但我希望能够扩展到数千个。

我可以想到三个策略：

1. 同一集合中的所有租户，使用特定于租户的字段进行安全性
2. 1个共享数据库中每个租户的收集
3. 每个租户1个数据库

我头脑中的声音暗示我选择了选项2.

思想和影响，任何人？

Answer 1

我有同样的问题需要解决并考虑变种。 由于我有多年创建SaaS多租户应用程序的经验，我还将根据我以前使用关系数据库的经验选择第二个选项。

在进行我的研究时，我在mongodb支持网站上发现了这篇文章（因为它已经消失，所以回来了）： https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html

这些家伙声称不惜任何代价避免第二种选择，据我所知，这并不是特别针对mongodb。我的印象是，由于数据库设计的具体细节，这适用于我研究的大多数NoSQL dbs（CoachDB，Cassandra，CouchBase Server等）。

集合（或桶或者它们在不同的DB中调用它）与RDBMS中的安全模式不同，尽管它们表现为文档的容器，它们对于应用良好的租户分离是无用的。我找不到可以根据集合应用安全限制的NoSQL数据库。

当然，您可以使用基于mongodb角色的安全性来限制对数据库/服务器级别的访问。 （http://docs.mongodb.org/manual/core/authorization/）

我会建议第一个选项：

• 你有足够的时间和资源来处理复杂性 设计，实施和测试这种情况。
• 如果你不会在结构上有太大差异 数据库中针对不同租户的功能。
• 您的应用程序设计将允许租户尽量减少 在运行时自定义。
• 如果您想优化空间并最大限度地减少硬件使用 资源。
• 如果您将有数千名租户。
• 如果您想快速扩展并且成本很高。
• 如果您不打算根据租户备份数据（请保持独立 每个租户的备份）。即使在这方面也可以做到这一点 方案，但努力将是巨大的。

如果符合以下情况，我会选择变体3：

• 你将有一小部分租户（几百个）。
• 业务的细节要求您能够支持不同租户的数据库结构的巨大差异（例如，与第三方系统的集成，数据的导入导出）。
• 您的应用程序设计将允许客户（租户）在应用程序运行时进行重大更改（添加模块，自定义字段等）。
• 如果您有足够的资源可以快速扩展新的硬件节点。
• 如果您需要为每个租户保留数据的版本/备份。恢复也很容易。
• 有法律/监管限制迫使您将不同的租户留在不同的数据库（甚至是数据中心）。
• 如果您想充分利用mongodb的开箱即用安全功能，例如角色。
• 租户之间的规模差异很大（你有很多小租户，很少有很大的租户）。

如果您发布有关您的申请的其他详细信息，或许我可以给您更详细的建议。

Answer 2

我在这个链接的评论中找到了一个很好的答案：

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

基本上选项＃2似乎是最好的方式。

引自David Mytton的评论：

  

我们决定不再拥有数据库   客户因为MongoDB的方式   分配其数据文件。每   数据库使用它自己的文件集：

     

    

数据库的第一个文件是     dbname.0，然后是dbname.1，等等dbname.0     将是64MB，dbname.1 128MB等等     到2GB。一旦文件达到2GB     大小，每个连续的文件也是     2GB。

         

因此，如果存在的最后一个数据文件是     比方说，1GB，该文件可能是90％为空     如果它最近达到了。

  

     

来自手册。

     

当用户注册试用并给予时   随时随地，我们会越来越多   数据库至少2GB   大小，即使整个数据   文件没用。我们发现这用了一个   大量的磁盘空间比较   为所有人提供多个数据库   客户所在的磁盘空间   用来达到最高效率。

     

Sharding将在每个集合上   作为标准的基础提出了一个   问题集合永远不会   达到最小尺寸即可开始   分片，就像一个很好的情况一样   我们很少（例如收藏品   存储用户登录详细信息）。然而，   我们要求这也是   能够在每个数据库上完成   水平。看到   http://jira.mongodb.org/browse/SHARDING-41

     

没有性能权衡   使用大量的集合。看到   http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Answer 3

您可能希望引用a reasonable article on MSDN about multi-tenant data architecture。本文涉及的一些关键主题：

• 经济方面的考虑
• 安全
• 租户注意事项
• 监管（合法）
• 技能设置问题

还涉及软件即服务（SaaS）配置的一些模式。

此外，值得一眼的是an interesting write-up from the SQL Anywhere guys。

我自己的个人看法 - 除非您确定强制执行安全/信任，否则我会使用选项3，或者如果可伸缩性问题禁止至少回退到选项2。那就是说......我不是MongoDB的专家。使用共享的“架构”我感到非常紧张 - 但我很乐意接受更有经验的从业者。

Answer 4

我会选择选项2.

但是你可以设置mongod.exe命令行选项--smallfiles。这意味着扩展区的最大文件大小为0.5千兆字节而不是2千兆字节。我用mongo 1.42进行了测试。因此选项3并非不可能。

Answer 5

虽然这里的讨论是关于NoSQL而主要是MongoDB，但我们Citus正在使用PostgreSQL并构建分布式/分片多租户数据库。

我们的use-case guide遍历示例应用，涵盖架构和各种多租户特定功能。

对于更多非结构化数据，我们使用PostgreSQL的JSONB列来存储此类特定于租户的数据。

Answer 6

根据我在MongoDB. Trucos y consejos. Aplicaciones multitenant.的研究 如果您不知道有多少租户可以使用该选项，那么它可能是数千个并且在分片时会很复杂，也可以想象在一个数据库中拥有数千个集合......所以在您的情况下它建议使用选项一。现在，如果您将拥有有限数量的用户，那么它已经不同了，是的，您可以按照您的想法使用选项二。