我正在开发一个Meteor网络应用，使用Mongo，它将在云上运行。每个用户必须属于公司。 每个公司只能访问它自己的数据。 每个用户都可以访问自己的数据以及与同一家公司的其他用户共享的一些数据。 想象一下1.000公司和每个公司100个用户，如果我为整个应用程序使用1个Mongodb数据库，性能和安全性可能会很差。Mongodb多公司网络应用策略
如此，因为蒙戈是“无模式和数据库少”我想我可以定义1.000 DBS，可以说db_0001，db_0002，...具有相同名称的集合，可以说任务， 消息，...，因此该应用程序可以高效且更安全（每个公司的相同代码和数据隔离）。
此外，在托管端（比如说说数字海洋），我认为它更容易分配dbs，如果已经被雾化。
这是一个很好的方法吗？或者我不应该担心它，并让托管做这项工作？
任何想法都很好。
你目前只在看硬币的一面。这是很好的开始。
想想你将如何显示该数据以及它转化为什么查询。对所有潜在的查询进行彻底的尽职调查。例如，用户/ getbyid被多久调用一次，以及多久你需要向用户显示他们的信息以及他们与其他用户的关系。除了用户信息之外还需要其他什么元数据，您是否需要执行连接才能获取这些数据？还是将其作为嵌入式文档存储？你最想搜索和排序的领域是什么？哪些类型的数据写得很重，读取的是什么？
现在让我们回到您的数据库着色方法。能够在这方面提前思考，而不是稍后重写组件，这太好了。数据量/存储不担心我在这里。在应用程序中将使用多少个并发用户，以及什么是主要用例应该是首先考虑考虑规模的地方。
此外，您需要了解业务和项目增长的性质。这是否像Instragram类型的高增长？或者它更可预测。一个大型的Mongo集群可以处理数以千计的并发读/写请求（假设您的设计和查询已经过优化），以免打扰我。如果你想保持它的灵活性，MongoDB有一个分片机制，你可以在一个密钥上分割，并且把所有的花哨的东西都照顾到你。
如果您启用了从辅助数据库读取的数据，并且您拥有大量业务关键型应用程序，则需要小心，因为您可能会读取过期结果，因此，MongoDB具有最终一致性（查找MongoDB CAP定理）。
就托管而言，DO很好，但总是在另一个区域备份以保持地理冗余度，以防万一某个区域出现故障（您好AWS！），您有事可循。
祝您的项目顺利！
非常感谢卡拉根！以下是我将用于设计的一个简短列表：1）在每个集合中包含一个company_id，并在该字段中包含一个索引，2）用于很多属性的冗余（即user_id user_name + user_url_pic allways存储），3 ）加入具有不同含义或数量的集合（即项目和会议），4）每个字段的数据字典（避免2个字段具有相同的名称和不同的含义），5）如果可能的话， '，preffer'狮子'，'狗'，...）。如果没有进一步的评论，我会发布这个答案。 –
Mongo仍然会在100k用户表现，1000 db的实例听起来像是过度杀伤，而且对我来说不是很灵活。 – challett
这不是你如何扩展Mongodb;你会为自己创造一个巨大的毛球。首先阅读https://www.mongodb.com/mongodb-scale及其链接。有很多关于缩放Mongo的在线案例研究。 –