用于监控/记录应用的mongodb数据模型，具有10'000个记录器

Question

我正在使用MongoDB存储定义监控/日志记录应用程序的数据模型。由于我是MongoDB的新手，我很感激你的一些建议。

应用程序写道：

我有10'000个记录器，对于我有的每个记录器：

• 不随时间变化的静态数据（每个记录器几千字节）
• 数据我必须每隔几秒钟从每个记录器连续记录

数据量为：

• 每个记录器每天1 MB或9000条消息

消除模式：

• 创建后30天，系统必须自动删除数据
• 60％的数据在30天之前被其他系统提取，并将在提取时删除

应用程序的内容如下：

• 如果数据被读取，则会立即读取所有从系统中删除的消息
• 数据在创建后最快1小时和最近30天读取。平均是14天。

平均：

• 我计算出数据存储的平均时间为14天，每个记录器提供40'000条消息或13MB
• db中存储的数据总量平均为130GB

我的问题：

• 您将使用哪种数据模型？
• 你会使用多少个分片？

我考虑了以下数据模型：

• embedded：每个记录器的文档，包含一系列消息;文档增长时因磁盘重定位而导致错误
• 每个记录器的上限集合;由于磁盘使用量大，而且数据被覆盖的时间不准确，这很糟糕
• 静态数据的记录器集合以及每个记录器的集合，用于使用TTL功能的消息;是10'000个收藏好吗？
• 静态数据的记录器集合以及使用TTL和复合索引（包括vehicle和messageId）的所有消息的单个集合;那个系列真的不大吗？
• 静态数据的记录器集合，包括具有id引用的预分配数组以及具有索引id的所有消息的集合;太复杂了？

您可以自由地提出其他数据模型

Answer 1

你的第四个选项听起来不错。不用担心集合有多大，您只需要确保选择了正确的分片键。

在这种情况下选择好的分片的关键取决于实际找到消息的方式。你有一个消息ID和读取它们的外部应用程序只是查询id吗？或者您正在对邮件进行全文搜索？外部应用程序是否知道记录器和放大器消息创建的日期时间？

考虑：

• 如果你将记录器作为分片键，那么你最终会得到太大而无法拆分的块
• 如果您将日期时间设为分片键，那么由于您的共享密钥，您最终会导致分发不佳
• 如果要通过消息ID搜索外部应用程序，则将散列消息ID作为分片键。这将确保良好的分配和可移动的块

不要担心为静态数据设置单独的集合。

就像我说的，设计这个的关键是澄清外部系统如何确切地找到日志消息。