我有同样的问题要解决，同时也考虑了变量。由于我有多年创建saas多租户应用程序的经验，我还打算根据我以前使用关系数据库的经验选择第二个选项。
在进行研究的过程中，我在mongodb支持站点上发现了这篇文章（自从它消失后，我又添加了这篇文章）：https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html
这些家伙表示要不惜任何代价避免第二种选择，据我所知，这并不是mongodb所特有的。我的印象是，由于数据库设计的特殊性，这适用于我研究的大多数nosql数据库（coachdb、cassandra、couchbase服务器等）。
集合（或者bucket，或者在不同的dbs中如何称呼它）与rdbms中的安全模式不同，尽管它们的行为就像文档的容器，但它们对于应用良好的租户分离是无用的。我找不到可以基于集合应用安全限制的nosql数据库。
当然，您可以使用基于mongodb角色的安全性来限制对数据库/服务器级别的访问(http://docs.mongodb.org/manual/core/authorization/)
我建议在以下情况下选择第一种方案：
您有足够的时间和资源来处理此场景的设计、实现和测试的复杂性。
如果不同租户的数据库在结构和功能上没有太大差异。
您的应用程序设计将允许租户在运行时只进行最小的自定义。
如果您希望优化空间并最小化硬件资源的使用。
如果你有成千上万的房客。
如果您想快速且成本合理地扩展。
如果您不打算基于租户备份数据（为每个租户保留单独的备份）。即使在这种情况下也有可能做到这一点，但付出的努力将是巨大的。
我会选择变体3，如果：
你将有一个小的租户名单（几百个）。
业务的具体情况要求您能够支持不同租户在数据库结构上的巨大差异（例如，与第三方系统集成、数据导入导出）。
您的应用程序设计将允许客户（租户）在应用程序运行时进行重大更改（添加模块、自定义字段等）。
如果您有足够的资源快速扩展新的硬件节点。
如果需要为每个租户保留数据的版本/备份。恢复也将很容易。
法律/法规限制迫使您在不同的数据库（甚至数据中心）中保留不同的租户。
如果您想充分利用mongodb现成的安全特性，例如角色。
租户之间的规模差异很大（小租户很多，大租户很少）。
如果你发布更多关于你申请的细节，也许我可以给你更详细的建议。

我在这个链接的评论中找到了一个很好的答案：
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+大量+数量+集合

在msdn上有一篇关于多租户数据体系结构的合理文章，您可能希望参考。本文涉及的一些关键主题：
经济考虑
安全
租户注意事项
监管（法律）
技能集关注点
还涉及到软件即服务（saas）配置的一些模式。
此外，值得一看的是SQLAnywhere的一篇有趣的文章。
我个人的看法——除非您确定强制安全/信任，否则我会选择选项3，或者如果可伸缩性问题至少禁止回退到选项2。也就是说。。。我不是mongodb的Maven。使用共享的“模式”我会非常紧张，但我很乐意听从更有经验的从业者。

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

根据我在mongodb的研究。trucos y consejos。多租户aplicaciones。如果您不知道可以拥有多少租户，则不建议使用该选项，因为可能有数千个租户，而且在切分时会很复杂，也可以想象在一个数据库中有数千个集合。。。因此，在您的情况下，建议使用选项一。现在，如果用户数量有限，情况已经不同了，是的，您可以按照自己的想法使用选项二。

虽然这里讨论的是nosql，主要是mongodb，但我们citus正在使用postgresql并构建分布式/分片多租户数据库。
我们的用例指南介绍了一个示例应用程序，涵盖了模式和各种多租户特定功能。
对于更多非结构化数据，我们使用postgresql的jsonb列来存储此类数据和特定于租户的数据。