监控服务MongoDB架构设计

Question

我在全球部署了1000多个流音频设备。 当前所有这些都大约每15分钟通过工厂监控服务进行一次检查。 我正在推出自己的监视服务，并将使用mongo存储状态更新。

题：

什么是更好的设计方案：

1）一个名为device_updates庞大集合。 所有状态更新文档将在哪里包含设备serial_number密钥？

2）1000多个集合，每个集合使用设备序列号命名，即： 65FE9 ，设备状态更新65FE9在其自己的集合中。如果按照这种方式，我会将集合的上限限制在2000个状态更新文档中。

两者都需要由created_at日期键索引。

有什么想法可以更好地提高性能吗？ 或对首选方法有任何想法？

谢谢！

Answer 1

我肯定会去收集大量的东西 ，因为所有文件都是同一类型 。

通常，将MongoDB中的集合视为一组同类文档 。 此外，仅使用一个集合，例如通过使用serial_number作为分片键，就可以更轻松地水平扩展（即，通过使用分片 ）。