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

我正在考虑使用 MongoDB 创建一个多租户应用程序。我不知道我会有多少房客，但我希望能够扩大到几千人。

我能想到三种策略:

  1. All tenants in the same collection, using tenant-specific fields for security
  2. 一个共享数据库中的每个租户1个集合
  3. 每个租户1个数据库

我脑子里的声音建议我选择第二种。

有人有什么想法吗？

46642 次浏览
小开

这里有一个 一篇关于 MSDN 多租户数据体系结构的文章，你可以参考一下。这篇文章中提到的一些关键主题:

  • 经济上的考虑
  • 保安
  • 对租户的考虑
  • 规管(法律)
  • 关注技能组合

还涉及到软件即服务(SaaS)配置的一些模式。

此外，值得一看的是 来自 SQLAnywhere 的一篇有趣的文章。

我个人的看法是——除非您确定强制安全/信任，否则我会选择选项3，或者如果可伸缩性问题至少禁止退回到选项2。也就是说... 我不是 MongoDB 的专家。使用共享的“模式”会让我非常紧张——但我很乐意听从更有经验的实践者。

小开

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

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

基本上，选项2似乎是最好的方法。

引自 David Mytton 的评论:

我们决定不在每个 客户因为 MongoDB 的方式 分配其数据文件 数据库使用它自己的一组文件:

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

因此，如果存在的最后一个数据文件是 比如说，1GB，那个文件可能有90% 是空的 如果是最近到达的。

from the manual.

As users sign up to the trial and give 如果一切顺利，我们会得到越来越多 databases that were at least 2GB in size, even if the whole of the data 文件没有用，我们发现这个用了一个 大量的磁盘空间 为所有人建立几个数据库 客户的磁盘空间可以 used to maximum efficiency.

Sharding will be on a per collection 基准作为标准，提出了一个 问题是收藏从来没有 达到起始的最小尺寸 sharding, as is the case for quite a 我们的收藏品(例如: 存储用户登录详细信息), 我们已经要求，这也将 be able to be done on a per database 水平，看 Http://jira.mongodb.org/browse/sharding-41

没有性能权衡 using lots of collections. See Http://www.mongodb.org/display/docs/using+a+large+number+of+collections

小开

I would go for option 2.

然而，您可以设置 mongod.exe 命令行选项—— small files。这意味着一个区的最大文件大小将是0.5 GB，而不是2 GB。我用 mongo 1.42测试过。所以选项3并非不可能。

小开
最佳答案

I have the same problem to solve and also considering variants. As I have years of experience creating SaaS multi-tenant applicatios I also was going to select the second option based on my previous experience with the relational databases.

在做研究的时候，我在 mongodb 支持站点上发现了这篇文章(自从它消失之后又重新添加了) : https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html

他们说不惜一切代价避免第二种选择，据我所知，这种选择并不特别适用于蒙哥布。我的印象是，由于数据库设计的特殊性，这适用于我研究的大多数 NoSQL 数据库(CoachDB、 Cassandra、 CouchBase Server 等)。

Collections (or buckets or however they call it in different DBs) are not the same thing as security schemas in RDBMS despite they behave as container for documents they are useless for applying good tenant separation. I couldn't find NoSQL database that can apply security restrictions based on collections.

当然，您可以使用基于 mongodb 角色的安全性来限制对数据库/服务器级别的访问

I would recommend 1st option when:

  • 您有足够的时间和资源来处理 design, implementation and testing of this scenario.
  • 如果你不打算有很大的结构和差异 为不同的租户提供数据库中的功能。
  • 您的应用程序设计将允许承租者只进行最小化 运行时自定义。
  • 如果您希望优化空间并尽量减少硬件的使用 资源。
  • 如果你有成千上万的房客。
  • 如果你想快速扩大规模，并以良好的成本。
  • 如果你不打算备份基于租户的数据(保持独立 即使在这种情况下也可以做到这一点 但需要付出巨大的努力。

如果有以下情况，我会选择变体3:

  • 你将会有一个小的租户名单(几百个)。
  • 业务的特殊性要求您能够支持不同租户的数据库结构的巨大差异(例如，与第三方系统的集成、数据的导入-导出)。
  • Your application design will allow customers (tenants) to make significant changes in the application runtime (adding modules, customizing the fields etc.).
  • 如果您有足够的资源来快速扩展新的硬件节点。
  • If you are required to keep versions/backups of data per tenant. Also the restore will be easy.
  • 法律/法规限制迫使您将不同的租户保留在不同的数据库(甚至数据中心)中。
  • 如果您希望充分利用 mongodb 的开箱即用的安全特性，比如角色。
  • 租户之间在规模上有很大的差异(你有很多小租户，很少有大租户)。

如果你发布更多关于你的申请的细节，也许我可以给你更详细的建议。

小开

虽然这里讨论的是 NoSQL 和主要是 MongoDB，但我们在 西塔斯使用 PostgreSQL 并构建一个分布式/分片多租户数据库。

我们的 用例指南用例指南介绍了一个示例应用程序，包括模式和各种特定于多租户的特性。

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

小开

根据我在《蒙古民族数据库》(MongoDB)中的研究，蒙古民族数据库(Trucos y consejos。 如果你不知道你可以拥有多少租户，那么不推荐使用这个选项，它可能是成千上万个，而且在进行分片时会很复杂，还可以想象在一个数据库中有成千上万个集合... ... 所以在你的情况下，建议使用选项1。现在，如果您将有一个有限的用户数量，它已经是不同的，是的，您可以使用选项2，因为您认为。


提交答案