Альтернатива исчезающему временному ряду: моделирование базы данных временных рядов - PullRequest
Новая
       52

Альтернатива исчезающему временному ряду: моделирование базы данных временных рядов

0 голосов
/ 16 ноября 2018

Я новичок в проектировании баз данных временных рядов.

Один из руководящих принципов, которые я прочитал, состоял в том, чтобы избежать большого количества временных рядов (например, рекомендации InfluxDb ) или временных рядов, которые недолговечны / вымирают.

В качестве упражнения я пытаюсь смоделировать метрики репозиториев github.Я хочу отслеживать общее количество комментариев / коммитов / измененных строк, объединенных различными атрибутами.Моя первоначальная идея состояла в том, чтобы выдвигать метрики в запросе на одно нажатие и выполнять все агрегации посредством запросов.

{
   labels: {
      pr: 1234, 
      repo: aRepo, 
      author: personA
   }
   values: {
      commits: 5,
      changed_files: 2,
      comments: 0
      status: Open
   }
}

Однако, похоже, это идет вразрез с рекомендациями (запросы на включение закрываются и становятся постоянными).Альтернативой может быть предварительное вычисление агрегаций перед отправкой их в базу данных.Это, однако, приводит к менее детальным данным и потере данных.

Какова оптимальная стратегия для эфемерных временных рядов.

1 Ответ

0 голосов
/ 01 декабря 2018

Эмпирическое правило для определения того, что составляет ряд и что является мерой, учитывает количество элементов в наборе данных (серии):

1) значения низкой мощности (менее переменные)переходит к тегам - это ваши реквизиты для группировки / агрегирования

2) Значения высокой кардинальности (сильно изменяемые) сами являются значениями измерений - это то, что вы будете агрегировать / выполнять вычисления в вышеупомянутомgroups

По этому правилу pr id входит в значения (они уникальны для репо - высокая мощность), в то время как status определенно является тегом (вы назвали его меткой).

Сделайте это, и вы будете в порядке со своими сериями времени.

...