多公司 Web 应用程序的 Mongodb 策略答案

【问题标题】：Mongodb strategy for Multi-Company web app多公司 Web 应用程序的 Mongodb 策略
【发布时间】：2015-10-15 12:56:04
【问题描述】：

我正在使用 Mongo 在 Meteor 中开发一个 Web 应用程序，它将在云上运行。每个用户必须属于一个公司。每个公司只能访问自己的数据。每个用户都可以访问自己的数据以及与同一公司的其他用户共享的一些数据。想象一下 1.000 家公司和每家公司 100 个用户，如果我为整个应用程序使用 1 个 Mongodb 数据库，它的性能和安全性可能会变得非常糟糕。

所以，因为 Mongo 是“无架构和无数据库”，我想我可以定义 1.000 dbs，比如说 db_0001、db_0002、...命名集合，比如任务、消息、...，这样应用程序就可以更高效、更安全（每个公司的代码相同，数据隔离）。

另外，在托管方面（例如使用 Digital Ocean），我认为如果数据库已经原子化，则更容易分发。

这是一个好方法吗？还是我应该不用担心，让托管来完成这项工作？

欢迎提出任何想法。

【问题讨论】：

Mongo 在 10 万用户时仍能发挥出色的性能，1000 个数据库实例听起来有点矫枉过正，对我来说扩展性不强。
这不是你扩展 Mongodb 的方式；你将为自己创造一个巨大的毛球。首先阅读mongodb.com/mongodb-scale 和那里的链接。有很多关于扩展 Mongo 的优秀在线案例研究。

标签： performance mongodb security meteor digital-ocean

【解决方案1】：

您目前只看到硬币的一面。开始就好了。

考虑一下您将如何显示该数据以及将其转换为什么查询。对所有潜在的查询进行彻底的尽职调查。例如，多久会调用一次 user/getbyid 以及您必须多久向用户显示他们的信息以及他们与其他用户的关系。除了用户信息之外，还需要哪些其他元数据，您是否必须执行联接才能获取该数据？还是将其存储为嵌入式文档？您将最多搜索和排序哪些字段？哪些类型的数据写入繁重，哪些数据读取繁重？

现在让我们回到您的数据库着色方法。很高兴您在这方面提前考虑，而不必稍后重写您的组件。数据量/存储在这里并不让我担心。有多少并发用户将在应用程序中使用以及主要用例是什么应该是考虑规模的首要考虑因素。

此外，您需要了解业务和项目增长的性质。它像 Instragram 类型的超增长吗？还是更可预测。一个大的 Mongo 集群可以处理数以千计的并发读/写请求（假设您的设计和查询已经过优化），所以这不会打扰我。如果你想保持它的灵活性，MongoDB 有一个分片机制，你可以在一个键上分片，它会为你处理所有花哨的东西。

如果您启用从辅助设备读取并且您拥有大量业务关键应用程序，则 MongoDB 具有最终一致性（查找 MongoDB CAP 定理），您需要小心，因为您可能会读取过时的结果。

就托管而言，DO 很好，但始终在另一个区域进行备份以保持地理冗余，因此如果某个区域出现故障（您好 AWS！），您有一些可以依靠的东西。

祝你的项目好运！

【讨论】：

非常感谢卡拉根！以下是我将用于我的设计的简短列表：1）在每个集合中包含一个 company_id 并在该字段上包含一个索引，2）大量使用的属性的冗余（即 user_id user_name + user_url_pic 始终存储），3 ）加入具有不同含义或数量的集合（即项目和会议），4）每个字段的数据字典（避免两个具有相同名称和不同含义的字段），5）如果可能（而不是“动物”）单独的集合（用于性能） '，更喜欢'狮子'，'狗'，...）。如果没有进一步的 cmets，我会将其发布为答案。