我正在使用Mongo开发Meteor中的Web应用程序，该应用程序将在云上运行。每个用户必须属于公司。 每个公司只能访问自己的数据。 每个用户都可以访问自己的数据，并与同一公司的其他用户共享一些数据。 想象一下， 1.000公司和每个公司100个用户，如果我在整个应用程序中使用1个Mongodb数据库，它的性能和安全性会非常糟糕。
所以，因为Mongo是“Schema-less and Database-less”，我认为我可以定义1.000 dbs，假设 db_0001 ， db_0002 ，...名称集合，例如任务，消息，...，因此应用程序可以高效且更安全（每个公司的代码和数据隔离）。
此外，在主机端（例如，使用Digital Ocean），我认为如果已经雾化了它，则更容易分发dbs。
这是一个好方法吗？或者我不应该担心它并让主机做这个工作？
任何想法都很好。
答案 0 :(得分：1)
你目前只看硬币的一面。这很好。首先。
考虑一下如何显示该数据以及它将转换为哪些查询。对所有潜在的查询进行彻底的尽职调查。例如，调用user / getbyid的频率以及向用户显示其信息及其与其他用户的关系的频率。除了用户信息之外还需要哪些其他元数据，您是否必须执行连接才能获取该数据？或者它是作为嵌入文档存储的？您最常要搜索和排序的是哪些字段？哪些类型的数据写得很重，哪些读取重？
现在让我们回到您的数据库着色方法。很高兴您在这方面提前考虑，而不是稍后重写您的组件。数据量/存储在这里不用担心。在应用程序中将使用多少并发用户以及主要用例应该是考虑扩展的第一个考虑因素。
此外，您需要了解业务和项目增长的性质。它是否像Instragram类型的超级增长？还是更容易预测。一个大的Mongo集群可以处理数千个并发读/写请求（假设您的设计和查询已经过优化），这样就不会打扰我了。如果你想保持灵活性MongoDB有一个分片机制，你可以在一个键上进行分片，它会照顾你所有的花哨的东西。
MongoDB具有最终的一致性（查找MongoDB CAP定理），如果您启用了对辅助数据的读取，并且您有一个高容量业务关键应用程序，则需要小心，因为您可能正在读取过期结果。
就主机而言，DO很好，但总是在另一个地区有备份以保持地理冗余，以防万一地区出现故障（Hello AWS！），你有什么可以依靠。
祝你的项目好运！