114

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

我可以想到三个策略：

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

我脑海中的声音建议我选择选项 2。

想法和影响，有人吗？

4

6 回答 6

81

我有同样的问题要解决，还要考虑变体。由于我拥有多年创建 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：

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

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

于 2014-04-21T17:54:12.110 回答
10

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

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

于 2010-05-01T17:07:28.590 回答
3

MSDN 上有一篇关于多租户数据架构的合理文章，您可能希望参考。本文涉及的一些关键主题：

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

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

此外，值得一试的是SQL Anywhere 人员的一篇有趣的文章。

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

于 2010-05-01T04:02:00.843 回答
3

我会选择选项2。

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

于 2010-05-02T05:47:53.150 回答
0

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

于 2018-05-11T13:30:47.723 回答
-3

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

我们的用例指南介绍了一个示例应用程序，涵盖了架构和各种多租户特定功能。

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

于 2017-08-01T22:04:59.873 回答