监控服务MongoDB架构设计

Question

我在世界各地部署了1000多种流媒体音频设备。所有这些目前每15分钟检查一次工厂监控服务。我正在推出自己的监控服务，并将使用mongo存储状态更新。

问题：

什么是更好的设计架构：

1）一个名为device_updates的大型集合。所有状态更新文档都包含设备serial_number密钥？

2）1000多个集合，每个集合用设备序列号命名，即：65FE9，设备状态更新在他们自己的集合中。如果走这条路线，我会将集合限制在大约2000个状态更新文档。

两者都需要通过created_at日期键进行索引。

哪些想法会更好地表现？或者对什么是首选方法的想法？

谢谢！

Answer 1

我肯定会选择一个大型集合，因为所有文档都是相同的类型。

作为一般规则，将MongoDB中的集合视为一组同类文档。此外，只有一个集合，通过使用例如serial_number作为分片键，可以更容易地横向扩展（即，使用分片）。