Некоторое время назад, занимаясь исследованиями, связанными с моей текущей работой, я наткнулся на эту прекрасную статью Барона Шварца на тему требований к базе данных временных рядов. Эта статья, на мой взгляд, является лучшей вещью в моем списке для чтения по этой теме, и в этом посте я попытаюсь изложить свое собственное мнение по этому вопросу, опираясь на нее.

Определение типа данных

Барон идентифицирует серию, используя два элемента: идентификатор источника и идентификатор метрики. Кажется, это используется в существующих продуктах, но, с моей точки зрения, это необходимо для целей организации, а не для идентификации серии. Для меня единственным жестким требованием в этом вопросе является то, что серия может быть однозначно идентифицирована. Поэтому достаточно одного идентификатора серии. Вы всегда можете обеспечить организацию, используя какое-то пространство имен над идентификаторами (рассмотрите следующие идентификаторы «source1.metric1» и «source1.metric2») или используя независимый компонент для построения отношений между сериями и другими элементами (группы, активы, источник, и т.д.). Последние открывают возможность для пользовательских организационных структур.

Меня интересует элемент, связанный с типом данных, — временное разрешение. Различные приложения могут иметь разные требования к времени. Поэтому база данных временных рядов должна иметь возможность устанавливать временное разрешение для каждого ряда.

Что касается типа значений измерения (числа с плавающей запятой для Барона), я не совсем в этом уверен. Для меня тип (и формат) значений измерения зависит от приложения (и серии). Возьмем, к примеру, серию писем с уведомлениями, отправленных клиенту. Это тоже временной ряд. Я знаю, что это обобщение может помешать реализации TSDB полностью применить принцип «отнести запрос к данным». Но, в конце концов, тип анализа, который можно выполнить с данными, также зависит от приложения, и поэтому реализация функций анализа на уровне запроса может повредить универсальности реализации TSDB.

С учетом этого для меня временной ряд можно определить следующим образом:

  • Серия идентифицируется с помощью уникального идентификатора. Этот UID может быть удобочитаемым или нет. Единственное требование состоит в том, чтобы быть уникальным для набора серий, хранящихся в TSDB.
  • Его можно охарактеризовать своим специфическим временным разрешением и форматом данных. Дополнительными характеристиками могут быть политика хранения данных и теги.
  • Серия состоит из последовательности измерений {timestamp, value}, упорядоченных по временной метке. Временная метка — это числовое значение, представляющее количество времени, выраженное с использованием временного разрешения конкретной серии, и значением является BLOB.

Характеристики рабочей нагрузки, производительность, характеристики масштабирования и эксплуатационные требования

Я полностью согласен с Бароном в отношении различных характеристик и целей оптимизации. В этом нет ничего другого.

Язык и/или дизайн API

Вот самая большая разница между подходом Барона и моим: роль базы данных временных рядов в отношении аналитики. Я ценю подход «отнести запрос к данным». Но, как я уже говорил, аналитика данных зависит от приложения. Поэтому для меня база данных временных рядов — это не место для общей аналитики, а только функции, связанные со временем (агрегация и т. д.).