我正在开发一个在Meteor上的web应用程序,它将在云上运行。每个用户必须属于一个公司。每个公司只能访问自己的数据。每个用户都可以访问自己的数据和与同一公司的其他用户共享的一些数据。假设有1.000家公司,每个公司有100个用户,如果我在整个应用程序中使用一个Mongodb数据库,它的性能和安全性可能会很差。
因此,由于Mongo是“模式少,数据库少”,我想我可以定义1.000 dbs,让我们说db_0001,db_0002,……使用相同的名称集合,比如tasks,messages,.,这样应用程序就可以更高效、更安全(每个公司的代码相同,数据隔离)。
另外,在主机端的(例如数字海洋)上,如果星展已经被原子化,我认为分发dbs就更容易了。
这样做好吗?或者我不应该担心它,让主持人做这份工作?
任何想法都是幸福的。
发布于 2015-10-15 16:06:40
你现在只看硬币的一面。一开始没问题。
考虑一下您将如何显示该数据,以及它将转换到什么查询。对所有可能的查询进行彻底的尽职调查。例如,调用user/getbyid的频率以及您必须向用户展示他们的信息以及他们与其他用户的关系的频率。除了用户信息之外,还需要哪些元数据,您是否需要执行连接才能获得该数据?还是将其存储为嵌入式文档?你最想搜索和排序的字段是什么?哪些类型的数据是写重的,哪些是读重的?
现在让我们回到您的数据库阴影方法。这是很好的,你是提前考虑在这方面,而不是必须重写您的组件以后。我不担心这里的数据量/存储量。应该首先考虑在应用程序中使用多少并发用户,以及主要用例是什么。
此外,您需要了解业务和项目增长的本质。它是否类似于Instragram式的超高速增长?还是更容易预测。一个大型的Mongo集群可以处理数千个并发的读/写请求(假设您的设计和查询是优化的),所以这不会困扰我。如果你想保持灵活性,MongoDB有一个切分机制,你可以在一个键上切分,它为你照顾所有花哨的东西。
MongoDB最终具有一致性(查找MongoDB CAP定理),如果您启用了从第二次访问的读取,并且您有一个大容量的业务关键应用程序,您需要小心,因为您可能正在读取过期的结果。
就托管而言,DO很好,但在另一个区域总是有一个备份,以保持地理冗余,以防某个区域崩溃(Hello!)你有什么可依靠的。
祝你的项目好运!
https://stackoverflow.com/questions/33149174
复制相似问题