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

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

我可以想到三种策略：

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

我脑海里有声音建议我选择选项2。

思想和含义，有人吗？

我有相同的问题要解决，也要考虑变体。由于我拥有多年创建SaaS多租户应用程序的经验，因此我还将根据我以前在关系数据库方面的经验来选择第二个选项。

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

伙计们表示不惜一切代价避免使用第二种选择，据我了解，这并不是mongodb特有的。我的印象是，由于数据库设计的特殊性，这适用于我研究的大多数NoSQL数据库（CoachDB，Cassandra，CouchBase Server等）。

尽管集合（或存储桶，或者它们在不同的数据库中称呼它）在安全性架构上与RDBMS中的安全架构不同，但是它们充当文档的容器，它们对于应用良好的租户分离毫无用处。我找不到可以基于集合应用安全限制的NoSQL数据库。

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

在以下情况下，我建议使用第一种方法：

• 您有足够的时间和资源来处理此方案的设计，实现和测试的复杂性。
• 如果您不会为不同的租户在数据库的结构和功能上有很大的不同。
• 您的应用程序设计将允许租户在运行时仅进行最少的自定义。
• 如果要优化空间并最大程度地减少硬件资源的使用。
• 如果您要有成千上万的租户。
• 如果您想以高成本快速扩展。
• 如果您不打算基于租户备份数据（请为每个租户保留单独的备份）。即使在这种情况下也可以这样做，但是付出的努力将是巨大的。

如果满足以下条件，我会选择变式3：

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

如果您发布有关您的应用程序的其他详细信息，也许我可以为您提供更多详细的建议。

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

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的数据库。与为所有客户使用多个数据库以最大程度地利用磁盘空间相比，我们发现此磁盘使用了大量的磁盘空间。

分片将作为每个集合的标准，这会带来一个问题，即集合永远不会达到开始分片的最小大小，就像我们中许多集合的情况一样（例如，集合仅存储用户登录详细信息）。但是，我们要求也可以在每个数据库级别上完成此操作。参见 http://jira.mongodb.org/browse/SHARDING-41

使用大量集合时没有性能折衷。参见 http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

有大约多租户数据架构在MSDN上合理的文章，你不妨参考一下。本文涉及的一些关键主题：

• 经济考虑
• 安全
• 租户注意事项
• 监管（法律）
• 技能问题

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

另外，值得一提的是来自SQL Anywhere的一些有趣的文章。

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

我会选择选项2。

但是，您可以设置mongod.exe命令行选项--smallfiles。这意味着扩展区中的最大文件大小将是0.5 GB，而不是2 GB。我用mongo 1.42对此进行了测试。因此，选择3并非不可能。

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

尽管此处的讨论是针对NoSQL以及主要针对MongoDB的，但我们在Citus仍在使用PostgreSQL并构建分布式/分片多租户数据库。

我们的用例指南通过一个示例应用程序，涵盖模式和各种多租户特定功能。

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