MongoDB 中多租户数据库的推荐方法是什么？
我正在考虑使用 MongoDB 创建一个多租户应用程序。我还没有猜测我会有多少租户，但我希望能够扩展到数千个。
我可以想到三种策略：
- 所有租户都在同一个集合中，使用特定于租户的字段来确保安全性
- 1 每个租户在单个共享数据库中进行集合 每个
- 租户 1 个数据库
我脑海中的声音建议我选择选项 2
。影响，有人吗？
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.
I can think of three strategies:
- All tenants in the same collection, using tenant-specific fields for security
- 1 Collection per tenant in a single shared DB
- 1 Database per tenant
The voice in my head is suggesting that I go with option 2.
Thoughts and implications, anyone?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我有同样的问题需要解决，并且也在考虑变体。
由于我拥有多年创建 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：
如果您发布有关您的申请的更多详细信息，也许我可以为您提供更详细的建议。
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.
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
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.
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.
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:
design, implementation and testing of this scenario.
functionality in the database for different tenants.
customizations at runtime.
resources.
backups for each tenant). It is possible to do that even in this
scenario but the effort will be huge.
I would go for variant 3 if:
If you post additional details about your application, perhaps I can give you more detailed advice.
我在此链接的评论中找到了一个很好的答案：
http://blog.boxedice.com/2010/02/28/notes-from-a-development-mongodb-deployment/
基本上选项#2似乎是最好的方法。
引用 David Mytton 的评论：
I found a good answer in the comments in this link:
http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/
Basically option #2 seems to be the best way to go.
Quote from David Mytton's comment:
我会选择选项 2。
但是您可以设置 mongod.exe 命令行选项 --smallfiles。这意味着一个盘区的最大文件大小将为 0.5 GB，而不是 2 GB。我用 mongo 1.42 对此进行了测试。所以方案3也不是不可能。
I would go for option 2.
However you could set mongod.exe command line option --smallfiles. This means that the biggest file size of an extent will be 0.5 gigabyte and not 2 gigabyte. I tested this with mongo 1.42 . So option 3 is not impossible.
MSDN 上有一篇关于多租户数据架构的合理文章，其中你不妨参考一下。本文涉及的一些关键主题：
还涉及软件即服务 (SaaS) 配置的一些模式。
此外，值得一看的是 来自 SQL Anywhere 人员的有趣文章。
我个人的看法 - 除非您确信强制安全/信任，否则我会选择选项 3，或者如果可扩展性问题至少禁止回退到选项 2。也就是说...我不是 MongoDB 专业人士。我对使用共享的“模式”感到非常紧张 - 但我会很乐意遵循更有经验的从业者。
There is a reasonable article on MSDN about multi-tenant data architecture which you might wish to refer to. Some key topics touched on by this article:
Also touched upon are some patterns for Software as a Service (SaaS) configuration.
Additionally, worth a gander is an interesting write-up from the SQL Anywhere guys.
My own personal take - unless you are certain of enforced security / trust, I would go with option 3, or if scalability concerns prohibit fallback to option 2 at a minimum. That said... I'm no pro with MongoDB. I get pretty nervous using a shared "schema" - but I will happily defer to more experienced practitioners.
根据我对 MongoDB 的研究。 Trucos y consejos。多租户应用程序。
如果您不知道可以拥有多少个租户，则不建议使用该选项，它可能是数千个，并且在分片方面会很复杂，还可以想象在一个数据库中有数千个集合......所以在您的情况下建议使用选项一。现在，如果您的用户数量有限，那么情况已经不同了，是的，您可以按照您的想法使用选项二。
According to my research in MongoDB. Trucos y consejos. Aplicaciones multitenant.
that option is not recommended if you do not know how many tenants you can have, it could be thousands and it would be complicated when it comes to sharding, also imagine having thousands of collections in a single database ... So in your case it is recommended to use option one. Now if you are going to have a limited number of users, it is already different and yes, you could use option two as you thought.