针对特定用例的MongoDB架构设计

Question

我正在为我的数据架构建模，我不确定我的思维过程是否有意义。所以我想我可能会问一些比较有经验的MongoDB人员：

---

让我们假设我的应用程序每天产生多达10.000个事件文档。我想以时间为基础访问。就像：“给我这三天的所有活动！”。

我在大学收集的RDBMS知识首先告诉我：“做一个事件收集并给每个文件提供事件的属性'日期'。完成。”

但后来我想到了每天收集的想法。然后我可以通过调用其相应的集合来获取一天中的所有事件，从而非常快速地访问这些事件。

这有意义吗？在不牺牲速度/性能的情况下，我可以拥有数百/数千个收藏吗？

---

感谢您的建议： - ）

Answer 1

每天10.000个文件不是很多。在一年的过程中，这是3.65m的文件。这当然不是一个非常小的集合，但我认为打破它们没有多大意义。

此特定情况的缺点是

• 以后很难更改您的查询模式。如果你突然需要小时精度，那你就麻烦了。如果要查找去年的所有事件，并将某个字段x设置为y，则必须查询365或366个集合。
• 您的查询模式会更复杂，因为您必须处理不同的集合名称。此外，您需要多次往返数据库。
• 国际化非常复杂，因为“日”并不是全球范围内定义明确的时间点。另一方面，使用UTC DateTime字段可以在不同的时区查询，如果需要的话。
• 管理大量的集合可能很乏味，使用shell会非常烦人。
• 通常在每个集合的基础上执行分片。如果您有许多较小的集合，则无法进行自动分片。

但是，使用大量集合是可能的，尽管有limits you should understand.正如文档所解释的那样，您可以拥有12,000个集合，每个集合都有一个索引，每个集合都有默认设置。有关详细信息，请参阅此处。

服务器密度博客论述了他们的方法，他们也使用了a lot of collections，但是他们嚼了6.5亿个文档，他们声称它在性能方面没有太大的区别。