Введение в СУБД для хранения временных рядов на примере InfluxDB

СУБД для хранения временных рядов (Time Series Databases, TSDB) — это система управления базами данных, которая предназначена в первую очередь для хранения данных, основанных на времени. В общем случае эти данные могут быть представлены в виде массивов, индексированных по временной метке (timestamp) или по временному периоду. Временной ряд — это измерение или событие, которое может быть отслежено, зафиксировано на протяжении некоторого времени.

Такие СУБД могут применяться для систем метрик, приложений по наблюдению за производительностью, сетевых данных, данных с сенсоров, событий, кликов, движений на рынке ценных бумаг и других аналитических данных. Главное отличие от остальных СУБД — каждый запрос к БД так или иначе зависит от временного параметра.

Отсюда вытекают множественные превосходства данного вида СУБД:

• •    рассчитаны под большое количество записи данных небольшого размера;

• •    специальные операции для выборки по временному параметру;

• •    эффективное использование дискового пространства.

В настоящее время рынок предоставляет большое количество таких TSDB: InfluxDB, Graphite, Druid, Prometheus и другие. Есть как и проприетарные системы, так и решения с открытым исходным кодом.

Для примера была выбрана InfluxDB, потому что эта система одна из наиболее быстро развивающихся среди свободно распространяющихся продуктов в данной категории. Также, InfluxDB занял первую строчку в исследовании портала db-engines [1]. Исследование проводилось по множественным критериям: количество упоминаний в поисковых системах, общий интерес публики, частота технических обсуждений в сообществе, количество вакансий, требующих знание системы.

Итак, данные в InfluxDB представлены в виде временных рядов, которые содержат измеряемые значения. Ряд представляет из себя набор точек “points”, которое отражает значение в определенный момент времени. Points структура имеет поля:

• •    time — временной штамп (timestamp)

• •    measurement — строковое обозначение ряда

• •    fields — непосредственное значение в формате «ключ-значение»

• •    tags — мета-данные о значении, формат тоже — «ключ-значение».

Проводя аналогию, можно сказать, что такие данные представляются в виде традиционной SQL-таблицы, где time выступает первичным ключом, tags и fields — столбцы, а measurement — название таблицы. Только в случае InfluxDB, количество таких «таблиц» может исчисляться миллионами. Также стоит заметить, что теги индексируются, а поля — нет, то есть все выборки желательно производить именно по тегам.

Формат такой структуры в строковом формате:

[,=...] =[,..] [unix-nano-timestamp]

Пример добавления данных в командной строке:

• >    INSERT positions,device=bus_23 latitude=80,longitude=31

При отсутствии последнего параметра, InfluxDB подставляет текущее время машины.

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

• >    SELECT "device", "latitude", “longitude” FROM "positions" name: cpu

time                      device     latitude    longitude

2018-04-21T19:28:07.580664347Z bus_23    80    31

2018-04-21T20:28:07.580664347Z bus_23    82    30

Значения поля fields могут иметь разные типы: string, float, integer, boolean, что удобно для организации различной структуры предметной области.

InfluxDB, как и любой другой инструмент, имеет свои минусы и плюсы [2]:

• •    Упрощенная система разрешения конфликтов дает прирост в производительности на запись данных. Как ограничение в этой СУБД нельзя хранить дублированные данные, и в некоторых случаях

возможна перезапись данных.

• •    Удаление данных, изменение данных должно быть редким ради прироста в скорости запросов, поэтому функциональность, связанная с этими методами, урезана.

• •    СУБД спроектирована с расчетом на то, что данные будут упорядочены по времени. Поэтому ситуация, когда у данных хаотичные временные метки, будет не так производительна в InfluxDB.

• •    InfluxDB вводит принцип — нет самой важной точки. Это значит, что СУБД хорошо управляется с агрегацией данных в больших количествах, но когда дело касается индивидуальных элементов, то функционал может оказаться скудным. Например, у точек даже нет первичных ключей.

• •    Данные не имеют схемы. Это черта всех NoSQL СУБД. С одной стороны, это позволяет быть гибким в вопросе реализации хранения, а с другой — отнимает полезные возможности реляционных СУБД, такие, как join по нескольким таблицам.

При сравнении с ElasticSearch — поисковой системой, работающей в реальном времени и способной использоваться в качестве нереляционной СУБД [3], InfluxDB показал хорошие результаты. По скорости обработки данных InfluxDB продемонстрировал феноменальный результат — 1400000 записанных единиц данных в секунду против 18000 у ElasticSearch. Также нагрузка на процессор была в несколько раз меньше (500% против 1200%), а записанные данные на диске заняли в десять раз меньше (145 Мб вместо 1.9 Гб). Однако, скорость чтения оказался ниже (820 операций в секунду вместо 1000) [4].

Подводя вывод, можно сказать, что СУБД для хранения временных рядов в целом и InfluxDB в частности — это сильный инструмент, который важно применять по назначению. Чтобы не совершить ошибку, заложив неправильное решение в архитектуру, нужно внимательно рассмотреть возможные случаи использовании системы, рассчитать потенциальную нагрузку, и только тогда принимать решение о целесообразности использования узкоспециализированных инструментов.