6

为给定日期的数据创建每天集合是否是一个好主意（我们可以从每天开始，然后如果数据太多，则改为每小时）。我们可以在 mongodb 中创建的集合数量是否有限制，还是会导致性能损失（mongodb 维护这么多集合是否是一种开销）。大量的集合对性能有什么不利影响吗？

为了给您更多的上下文，这些数据将更像 facebook 提要，只有最新的数据（比如最近一周或一个月）对我们来说更重要。每天收集可以减少文档数量，并且可能会导致快速访问。即使我们需要旧数据，我们也可以回退到旧集合。这是有道理的，还是我走错了方向？

4

3 回答 3

4

是的，您可以进行的收藏数量是有限制的。从 Mongo 文档 Abhishek 引用：

命名空间数量的限制是命名空间文件的大小除以 628。

一个 16 兆字节的命名空间文件可以支持大约 24,000 个命名空间。每个索引也算作一个命名空间。

索引等包含在命名空间中，但即便如此，达到这个限制也需要大约 60 年的时间。

然而！您是否考虑过当您想要跨越集合的数据时会发生什么？换句话说，如果您想知道一周内有多少用户更新了供稿，那么您就有点困难了。跨集合查询并不容易/微不足道。

我建议改为创建一个集合来存储数据，并按照 Tamir 的建议定期将数据移出。您可以轻松地编写一个作业，每周或每月将数据移出集合。

于 2013-06-27T16:16:46.313 回答
4

您真正需要的是归档旧数据。我建议您在 mongodb 邮件列表中查看此线程：
https ://groups.google.com/forum/#!topic/mongodb -user/rsjQyF9Y2J4 Michael Dirolf (10gen) 的最后一篇文章说：

“操作系统将处理 LRUing 数据，因此，如果您的所有查询都触及应该保留在内存中的同一部分数据，而与集合的总大小无关。”

所以我想你可以继续使用单一的集合，好的索引就可以完成这项工作。
无论如何，如果集合太大，您可以随时运行手动存档过程。

于 2013-06-27T08:33:05.677 回答
0

创建集合的开销并不大，但开销比在集合中创建新文档要大。

您可以创建的集合数量有限制：“ http://docs.mongodb.org/manual/reference/limits/#Number of Namespaces ”

对我创建新集合不会有任何性能差异，因为在 RAM 中您只缓存您实际查询的那些数据。在您的情况下，它将是最近的提要等。

但是每天/每小时收集将帮助您非常轻松地获取旧数据。

于 2013-06-27T08:23:03.580 回答