代码之家  ›  专栏  ›  技术社区  ›  Braintapper

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

  •  78
  • Braintapper  · 技术社区  · 16 年前

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

    我可以想出三种策略:

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

    我脑子里的声音在暗示我选择2。

    有什么想法和暗示吗?

    6 回复  |  直到 16 年前
        1
  •  48
  •   Paul    7 年前

    我有同样的问题要解决,同时也在考虑变化。 由于我有多年创建SaaS多租户应用程序的经验,我还打算根据我以前使用关系数据库的经验选择第二个选项。

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

    他们说要不惜任何代价避免第二种选择,据我所知,这并不是MongoDB特有的。我的印象是,由于数据库设计的特殊性,这适用于我研究的大多数nosql数据库(coachdb、cassandra、couchbase服务器等)。

    集合(或bucket,或者在不同的dbs中称之为bucket)与rdbms中的安全模式不同,尽管它们充当文档的容器,但它们对于应用良好的租户分离是无用的。我找不到可以基于集合应用安全限制的NoSQL数据库。

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

    我建议在下列情况下选择第一个选项:

    • 你有足够的时间和资源来处理 此方案的设计、实现和测试。
    • 如果你不打算在结构和 数据库中针对不同租户的功能。
    • 您的应用程序设计将只允许租户将 运行时自定义。
    • 如果您想优化空间并尽量减少硬件的使用 资源。
    • 如果你有成千上万的房客。
    • 如果你想快速并以合理的成本扩大规模。
    • 如果您不打算备份基于租户的数据(请保持单独 每个租户的备份)。即使在这种情况下也有可能做到 但这将是巨大的努力。

    如果出现以下情况,我会选择变体3:

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

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

        2
  •  8
  •   Braintapper    16 年前

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

    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.112MB等,向上 到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

        3
  •  2
  •   AJ.    16 年前

    a reasonable article on MSDN about multi-tenant data architecture 你可以参考一下。本文涉及的一些关键主题:

    • 经济考虑
    • 安全性
    • 租户注意事项
    • 监管(法律)
    • 技能设置关注点

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

    另外,值得一试的是 an interesting write-up from the SQL Anywhere guys .

    我个人的看法-除非你确定强制安全/信任,否则我会选择选项3,或者如果可伸缩性问题至少禁止回退到选项2。也就是说…我不支持MongoDB。我很紧张使用一个共享的“模式”-但我会很高兴遵从更有经验的从业者。

        4
  •  1
  •   TTT    16 年前

    我会选择2。

    但是,您可以设置mongod.exe命令行选项——smallfiles。这意味着一个数据块的最大文件大小将是0.5GB,而不是2GB。我用Mongo1.42测试了这个。因此,选择3并非不可能。

        5
  •  0
  •   Sumedh    9 年前

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

    我们的 use-case guide 浏览一个示例应用程序,涵盖模式和各种特定于多租户的功能。

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

        6
  •  0
  •   Osleynin Mambell Ramos    8 年前

    根据我在年的研究 MongoDB. Trucos y consejos. Aplicaciones multitenant. 如果您不知道可以拥有多少租户,则不建议使用该选项,因为可能有数千个租户,而且在分片时会很复杂,还可以想象在单个数据库中有数千个集合……因此,在您的情况下,建议使用选项一。现在如果你要有有限的用户数量,它已经是不同的,是的,你可以使用选项二,因为你认为。