我是时间序列数据库设计的新手。
我读过的指导原则之一是避免有大量的时间序列(例如InfluxDb推荐(或短暂/消亡的时间序列。
作为一个练习，我尝试对github存储库的度量进行建模。我想跟踪由各种属性聚合的评论/提交/更改行的总数。我最初的想法是对每个请求推送度量，并通过查询进行所有聚合。
{
labels: {
pr: 1234,
repo: aRepo,
author: personA
}
values: {
commits: 5,
changed_files: 2,
comments: 0
status: Open
}
}
然而，这似乎违背了建议(拉取请求被关闭并变为常量(。另一种选择是在将聚合推送到数据库之前预先计算聚合。然而，这会导致数据粒度降低和数据丢失。
对于短暂时间序列的情况，这里的最佳策略是什么。
找出系列的经验法则；衡量数据集(系列(的考虑基数的标准是什么：
1(低基数(变量较小(的值会进入标签-这是您的分组/聚合道具
2(高基数(高度可变(值本身就是测量值-这就是您在上述组中聚合/进行计算的内容
根据这个规则，pr id进入值(它们是每个repo唯一的-高基数(，而status绝对是一个标签(您称之为标签(。
这样做，你的时间序列就会很好。