MongoDB 中多租户数据库的推荐方法是什么? [英] What is the recommended approach towards multi-tenant databases in MongoDB?

查看:20
本文介绍了MongoDB 中多租户数据库的推荐方法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在考虑使用 MongoDB 创建一个多租户应用程序.我不知道我有多少租户,但我希望能够扩展到数千个.

I'm thinking of creating a multi-tenant app using MongoDB. I don't have any guesses in terms of how many tenants I'd have yet, but I would like to be able to scale into the thousands.

我能想到三种策略:

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

我脑子里的声音暗示我选择选项 2.

The voice in my head is suggesting that I go with option 2.

想法和影响,有人吗?

推荐答案

我有同样的问题要解决,也在考虑变体.由于我有多年创建 SaaS 多租户应用程序的经验,因此我还打算根据我之前在关系数据库方面的经验选择第二个选项.

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

While making my research I found this article on mongodb support site (way back added since it's gone): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html

这些人表示要不惜一切代价避免第二个选项,据我所知,这并不是特别针对 mongodb.我的印象是,由于数据库设计的特殊性,这适用于我研究的大多数 NoSQL 数据库(CoachDB、Cassandra、CouchBase Server 等).

The guys stated to avoid 2nd options at any cost, which as I understand is not particularly specific to mongodb. My impression is that this is applicable for most of the NoSQL dbs I researched (CoachDB, Cassandra, CouchBase Server, etc.) due to the specifics of the database design.

集合(或桶或它们在不同数据库中的称呼)与 RDBMS 中的安全模式不同,尽管它们充当文档的容器,但它们对于应用良好的租户分离毫无用处.我找不到可以基于集合应用安全限制的 NoSQL 数据库.

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 角色的安全性来限制数据库/服务器级别的访问.(http://docs.mongodb.org/manual/core/authorization/)

Of course you can use mongodb role based security to restrict the access on database/server level. (http://docs.mongodb.org/manual/core/authorization/)

我会在以下情况下推荐第一个选项:

I would recommend 1st option when:

  • 您有足够的时间和资源来处理复杂的此场景的设计、实施和测试.
  • 如果您不打算在结构和数据库中针对不同租户的功能.
  • 您的应用程序设计将允许租户只做最少的在运行时进行自定义.
  • 如果您想优化空间并尽量减少硬件使用资源.
  • 如果您要拥有数以千计的租户.
  • 如果您想以合理的成本快速扩展.
  • 如果您不打算根据租户备份数据(保持分开每个租户的备份).即使在这种情况下也可以做到这一点场景,但付出的努力将是巨大的.

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

I would go for variant 3 if:

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

如果您发布有关您的应用程序的更多详细信息,也许我可以给您更详细的建议.

If you post additional details about your application, perhaps I can give you more detailed advice.

这篇关于MongoDB 中多租户数据库的推荐方法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆