我正在设计一个使用 MongoDb(64 位版本)的系统来处理大量用户(大约 100,000),每个用户将拥有大量数据(大约 100 万条记录)。
最好的设计策略是什么?
转储单个集合中的所有记录
为每个用户创建一个集合
为每个用户建立一个数据库。
非常感谢,
我正在设计一个使用 MongoDb(64 位版本)的系统来处理大量用户(大约 100,000),每个用户将拥有大量数据(大约 100 万条记录)。
最好的设计策略是什么?
转储单个集合中的所有记录
为每个用户创建一个集合
为每个用户建立一个数据库。
非常感谢,
因此,您正在查看大约 1000 亿条记录(100 万条记录 * 100,000 个用户)的区域。
处理大量数据的首选方法是创建一个分片集群,将数据拆分到多个服务器上,这些服务器通过 mongo 客户端呈现为单个逻辑单元。
因此,您的问题的答案是将所有记录放在一个分片集合中。
集群所需的分片数量和配置与数据的大小以及读写的数量和分布等其他因素有关。这些问题的答案可能非常适合您的独特情况,因此我不会尝试猜测它们。
我可能会首先确定您有多少分片以及有多少机器可用于在这么多机器的集群上设置和测试系统。根据其性能,您可以决定在集群中是否需要更多或更少的分片
因此,您正在为 10 万用户寻找总共 100,000,000 条详细记录?
很多人似乎不明白的是,MongoDB 擅长水平扩展。水平扩展通常被归类为跨大型集群中的许多(许多)服务器扩展巨大的单个数据集合。
因此,如果您对公共数据使用单个集合(即一个集合称为一个集合user
)detail
,那么您已经适合 MongoDB 的核心目的和构建。
正如其他人所提到的,MongoDB 并不擅长在许多集合中垂直扩展。它一开始就有一个 nssize 限制,即使由于索引大小在现实中估计了 12K 初始集合,您的数据库中也可以只有 5K 集合。
因此,每个用户的集合根本不可行。它将违背其核心原则使用 MongoDB。
每个用户拥有一个数据库涉及到相同的问题,也许更多,就像每个用户拥有一个单一的集合一样。
我从来没有遇到过有人无法在优化的设置上将 MongoDB 扩展到数十亿甚至接近 100 亿(或更多),但是,我不明白为什么它不能;毕竟 Facebook 能够使 MySQL 扩展到每个用户的 1000 亿(跨越 32K+ 分片),并且两个数据库之间的分片概念是相似的。
所以这样做的理论和可能性是存在的。这一切都是关于选择正确的模式和分片概念和密钥(以及服务器和网络等等等)。
If you were to witness problems you could go for splitting archive collections, or deleted items away from the main collection but I think that is overkill, instead you want to make sure that MongoDB knows where each segment of your huge dataset is at any given point in time on the master and ensure that this data is always hot, that way queries that don't do a global and scatter OP should be quite fast.
关于每个用户的集合:
默认配置下,MongoDB 限制为 12k 个集合。您可以使用--nssize增加它的大小,但它不是无限的。而且您必须将索引计入这 12k 中。(检查 mongo 文档中的“命名空间”概念)。
关于每个用户的数据库:
从模型的角度来看,这非常奇怪。对于技术,对 mongo 没有限制,但您可能对文件描述符有限制(来自您的操作系统/设置的限制)。
所以正如@Rohit 所说,最后两个不好。也许你应该更多地解释你的情况。也许您可以将用户分成不同的集合(例如:每个名称的第一个字母等,或公司的每个服务......)。而且,当然使用sharding。
编辑:也许 MongoDb 不是您用例的最佳数据库。