что такое time series db
Что такое базы данных временных рядов (time series database)
Временные ряды – один из наиболее часто встречающихся в аналитической практике объектов. Временной ряд – это статистика серии наблюдений за одним и тем же явлением, параметром какого-либо процесса, на протяжении некоторого времени. Каждому результату наблюдения (измерению) соответствует время, когда это наблюдение было сделано, или его порядковый номер – опять же, по шкале времени. Таким образом, при анализе временных рядов учитываются не только базовые статистические закономерности, но и взаимосвязь измерений со временем.
Что такое базы данных временных рядов и почему потребовалось создавать специализированные БД, если есть достаточное количество серьезных промышленных систем управления базами данных: Oracle, MS SQL Server, Sybase и много других? Чтобы ответить на этот вопрос, необходимо понять, что составляет предмет этих БД.
Такого рода данные требуются и накапливаются при самых разных задачах и для самых разных нужд. Можно привести несколько примеров:
Иными словами, спрос на инструменты для хранения и обработки данных временных рядов достаточно высок (особенно со стороны финансового рынка). Однако пользователи крупных СУБД столкнулись с проблемой: универсальные монстры оказались слабо приспособлены для решения именно таких задач, и проблема вырастала из идеологии (модели данных) наиболее распространенных в то время реляционных баз данных, не позволяющей эффективно работать с упорядоченным множеством элементов временного ряда. Появились разработки специализированного программного обеспечения, оптимизированного под эти задачи.
Базы данных временных рядов (time series database) позволяют пользователям создавать, считать, обновлять и удалять различные временные ряды и организовывать их неким образом. Сервер часто поддерживает ряд основных вычислений, которые работают на ряды в целом, например, умножая, складывая или иным образом комбинируя различные временные ряды в новый временной ряд. Они могут также фильтровать по произвольным образцам, при этом значения одного ряда могу являться фильтром для другого. Простой синтаксис является залогом привлекательности специальных баз данных временных рядов.
Среди специальных TSBD преобладают продукты, основанные на свободной лицензии: Open TSDB, InfluxDB, Geras, Druid и пр. Некоторые из них «заточены» под относительно узкий спектр задач. Так, YAWNDB и SiteWhere позиционируются как инструмент для специалистов в области веб-технологий.
Реализация функционала базы данных временных рядов возможна в обычной реляционной БД на основе SQL при условии, что программное обеспечение базы данных поддерживает одновременно большие двоичные объекты (BLOB) и пользовательские функции. Но эффективность такой системы также будет невысока. Поэтому разработчики крупных баз данных пытаются развить реляционную модель данных до объектно-реляционной, обладающей частью свойств объектно-ориентированной БД, в частности, в поддержке концепции абстрактного типа данных. Например, IBM предлагает оптимизированный продуктом Informix Time Series.
Time Series, метрики и статистика: знакомство с InfluxDB
Введение
Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…
Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.
Для хранения временных рядов часто используются специализированные решения — так называемые time series (темпоральные) базы данных. Об их плюсах и минусах мы уже писали. Пытаясь исправить недостатки имеющихся решений, мы даже разработали собственный продукт — time series базу данных YAWNDB, которая используется в нашей системе мониторинга. Но все time series базы данных являются низкоуровневыми, а возможности их применения весьма ограничены. Во-первых, они не позволяют объединять временные ряды c данными других типов — например, со словарями. Во-вторых, они совершенно не рассчитаны на работу с большими объемами данных. В большинстве темпоральных БД даже нет языка запросов. Поэтому стандартная задача — запросить и получить нужную информацию в любой момент времени — становится очень сложной и нетривиальной. Конечно, её можно решить и без языка запросов, но это под силу только пользователям, обладающим специальными знаниями и недюжинными навыками программирования.
Для хранения временных рядов сегодня всё чаще используются так называемые NoSQL базы данных — как популярные HBase и Cassandra, так и более специализированные решения — например, OpenTSDB, KairosDB и Acunu. Возможно, в некоторых ситуациях такой вариант вполне оправдан, но для решения подавляющего большинства практических задач он вряд ли подойдёт. Все перечисленные выше БД работают на базе инфраструктуры Hadoop, и для их нормального функционирования требуется огромное количество зависимостей. Да и с производительностью у них не всё так гладко, как может показаться на первый взгляд (подробнее об этом см., например, здесь).
Как же решить проблему хранения временных рядов, метрик и статистики? Мы серьезно задумались над этим вопросом, когда подбирали вариант хранения информации о запросах к нашим NS-серверам.
Совершенно неожиданно в обсуждении нашего поста на Хабрахабре один из читателей порекомендовал NoSQL базу данных InfluxDB. Мы попробовали ее — и остались вполне довольны. Своим опытом работы с InfluxDB мы хотели бы поделитьcя в этой статье.
Общая информация
База данных InfluxDB (см. репозиторий на GitHub), написанная на языке Go — продукт новый: первый его релиз состоялся в октябре 2013 года. Она позиционируется как база данных для хранения временных рядов, метрик и информации о событиях.
B качестве низкоуровневого хранилища пар «ключ-значение» в InfluxDB используется база данных LevelDB. Для этой цели можно также использовать RocksDB (по утверждению разработчиков InfluxDB, именно это хранилище показывает наилучшую производительность — см. отчет о тестировании здесь), и LMDB.
Записывать данные в InfluxDB можно различными способами. Во-первых, данные в формате JSON можно передавать через HTTP API. Во-вторых, InfluxDB поддерживает протокол Carbon, используемый в инструменте для обработки и визуализации данных Graphite. В-третьих, данные можно отправлять по протоколу UDP.
InfluxDB может использоваться в качестве бэкенда для Graphite, и благодаря этому можно существенно повысить его производительность. Поддерживается также возможность работы с дашбордом для метрик Grafana (более подробно об этом речь ещё пойдёт ниже).
Несомненным плюсом InfluxDB являются и широкие возможности интеграции с другими программными продуктами — например, инструментом для обработки логов Fluentd, демонами для сбора статистики CollectD и и StatsD, фреймворками для мониторинга Sensu и Shinken.
Установка
Установим Influx DB и посмотрим, как её можно использовать на практике. Процедуры установки и настройки мы будем рассматривать на пример с OC Ubuntu; для других дистрибутивов Linux они могут отличаться (подробности см. в официальной документации).
Выполним следующую команду:
По завершении установки запустим InfluxDB:
По умолчанию InfluxDB использует порты 8083, 8086, 8090 и 8099. Можно использовать и другие порты — для этого потребуется внести соответствующие изменения в конфигурационный файл. Рассмотрим особенности конфигурирования InfluxDB более подробно.
Настройка и конфигурирование
Все настройки InfluxDB хранятся в конфигурационном файле /opt/influxdb/current/config.toml. Они делятся на следующие группы:
[logging] — параметры логгирования (указываются уровень логгирования и имя файла лога);
[admin] — настройки веб-интерфейса (порт, на котором работает внутренний веб-сервер, и путь к файлам веб-интерфейса);
[api] — настройки HTTP API;
[input_plugins] — настройки ввода данных из внешних источников (в InfluxDB можно передавать данные, предназначенные для отправки в Graphite; также в этом разделе можно настроить ввод данных по протоколу UDP).
[raft] — настройки протокола согласования RAFT;
[storage] — общие настройки хранения данных;
[cluster] — настройки работы в кластерном режиме (более подробно они будут описаны ниже;
[wal] — настройки опережающего введения журнала (Write Ahead Logging, WAL).
Создаём базу данных
По завершении установки откроем в браузере страницу localhost:8083. Мы увидим веб-интерфейс для работы с базами данных. Выглядит он так:
Введем теперь логин (root) и пароль (root) (начальные значения можно задать в конфигурационном файле до первого запуска), а затем нажмем на кнопку Connect. Откроется следующее окно:
Графический интерфейс InfluxDB прост и интуитивно понятен. Обратим внимание на некоторые важные моменты, которые следует учитывать при создании первой базы данных.
Чтобы упростить и ускорить чтение данных при запросе, базу лучше разделить на составные части небольшого объема — так называемые шарды (англ. shards) Совокупность шардов, формируемых на основе одного и того же принципа, называется шардовым пространством (англ. shard space).
Создавая базу, нужно указать, какие шардовые пространства будут входить в ее состав. Данные можно делить на шарды, во-первых, по временным отрезкам. Если, например, мы будем хранить в базе информацию о действиях пользователей, то ее удобнее разбивать на временные отрезки — например, данные за каждые 7 дней будут хранится в отдельном шарде. Длина временного отрезка указывается в разделе Duration. В графе Retention указывается срок хранения шарда.
При создании базы данных можно указывать и параметры для работы в кластере. В графе RF (эта аббревиатура означает Replication Factor — фактор репликации) указывается, на скольких узлах должна храниться копия каждого шарда в шардовом пространстве. В графе Split указывается, на сколько шардов нужно делить данные в для конкретного временного промежутка.
Чтобы каждый сервер в кластере был готов к записи «горячих» данных в любой момент времени, значение фактора репликации рекомендуется рассчитывать по следующей формуле:
(RF — фактор репликации, NoS — число серверов)
Алгоритм, лежащий в основе деления данных на шарды, включает следующие шаги:
1. Программа просматривает все шардовые пространства в базе.
2. Затем она проходит все шардовые пространства циклом и ищет пространство, которому соответствуют новые данные.
3. После этого просматриваются все шарды для заданного временного интервала;
4. Если шардов не существует, то будет создано N шардов (N — число, указанное в графе split).
5. Данные записываются в шард с использованием алгоритма hash(series_name) % N.
Рекомендуется устанавливать небольшие размеры шарда по времени (duration).
Если установить для времени хранения шарда (retention) значение inf (т.е. бесконечный), этот шард никогда не будет удалён.
Установив все необходимые настройки, нажмём на кнопку Create Database.
Работа в кластере
В режиме кластера несколько серверов InfluxDB образуют единую систему. Каждый узел кластера может принимать запросы на чтение и запись. Для организации работы в кластере используется протокол согласования RAFT. Понятное и наглядное объяснение принципа его работы представлено в этой презентации.
Согласно официальной документации, в текущем релизе работа в кластере поддерживается лишь в режиме тестирования. Полноценная реализация запланирована на одну из следующих версий (0.9 или 0.10).
В документации ничего не сказано о том, как прописываются настройки кластера в конфигурационном файле, поэтому мы подробно остановимся на этом моменте. Итак, чтобы настроить кластер, нужно:
1. Запустить первый узел InfluxDB со всеми нужными настройками, но без параметра seed-servers в конфигурационном файле (раздел cluster).
2. На втором и всех последующих узлах в качестве значения параметра seed-servers указывается IP-адрес первого сервера, который должен быть запущен самостоятельно:
Если сервер уже был запущен без установки параметра seed-servers, то перед добавлением в кластер нужно удалить с него все данные InfluxDB (путь к данным по умолчанию: /opt/influxdb/shared/data/).
При добавлении нового узла можно указывать IP-адрес любого сервера, уже входящего в состав кластера.
Порт указываем тот же, что и в разделе [raft] (по умолчанию — 8090).
Управление правами пользователей
Возможности управления правами пользователей через графический интерфейс очень ограничены: можно только выполнять простейшие операции добавления и удаления пользователей и разрешать полный (c правами администратора) доступ.
Более тонкие настройки доступа к данным можно устанавливать только через API. Доступ к метрикам реализован в виде регулярных выражений.
В схематичном виде структура запроса выглядит так:
Приведём пример команды для изменения настроек доступа:
Просмотреть текущие правила можно с помощью команды
Из полученного вывода видно, что пользователь grafana может читать все метрики (“*.”), но при этом не может ничего писать (“^$”).
Интеграция с Grafana
Grafana представляет собой удобный дашборд для выборки и визуализации метрик. На русском языке публикаций о нём почти нет, за исключением совсем небольшой заметки на Хабре.
Специально для желающих посмотреть, как работает InfluxDB в связке с Grafana, мы подготовили сценарий (playbook) для Ansible и разместили его на GitHub.
Чтобы осуществить тестовый запуск, клонируйте репозиторий по ссылке выше, в файле hosts укажите IP-адреса машин, которые будут входить в кластер, а затем запустите скрипт run.sh. Обратите внимание, что описание конфигурации Influxdb задаётся в «родном» для Ansible формате YAML, из которого затем генерируется файл в формате TOML.
Заключение
На основании собственного (пусть пока и не очень большого) опыта мы сделали вывод о том, что InfluxDB представляет собой интересное и перспективное решение, которое может быть рекомендовано к практическому использованию. Надеемся, что и у вас по прочтении нашей статьи возникнет желание познакомиться с InfluxDB поближе.
Если кто-то из вас уже использует InfluxDB — приглашаем поделиться опытом в комментариях.
Читателей, которые по тем или иным причинам не имеют возможности оставлять комментарии здесь, приглашаем в наш блог.
Как мы тестировали несколько баз данных временных рядов
За последние несколько лет базы данных временных рядов (Time-series databases) превратились из диковинной штуки (узкоспециализированно применяющейся либо в открытых системах мониторинга (и привязанной к конкретным решениям), либо в Big Data проектах) в «товар народного потребления». На территории РФ отдельное спасибо за это надо сказать Яндексу и ClickHouse’у. До этого момента, если вам было необходимо сохранить большое количество time-series данных, приходилось либо смириться с необходимостью поднять монструозный Hadoop-стэк и сопровождать его, либо общаться с протоколами, индивидуальными для каждый системы.
Может показаться, что в 2019-м году статья про то, какую TSDB стоит использовать, будет состоять лишь из одного предложения: «просто используйте ClickHouse». Но… есть нюансы.
Действительно, ClickHouse активно развивается, пользовательская база растет, а поддержка ведется очень активно, но не стали ли мы заложниками публичной успешности ClickHouse’а, которая затмила другие, возможно, более эффективные/надежные решения?
В начале прошлого года мы занялись переработкой нашей собственной системы мониторинга, в процессе которой встал вопрос о выборе подходящей базы для хранения данных. Об истории этого выбора я и хочу здесь рассказать.
Постановка задачи
Прежде всего — необходимое предисловие. Зачем нам вообще собственная система мониторинга и как она была устроена?
Мы начали оказывать услуги поддержки в 2008 году, и к 2010-му стало понятно, что агрегировать данные о происходящих в клиентской инфраструктуре процессах решениями, существовавшими на тот момент, стало сложно (мы говорим о, прости господи, Cacti, Zabbix-е и зарождающемся Graphite).
Основными нашими требованиями были:
Говоря о хранилище, требования были следующие:
Таким образом, мы добились выборки свежих двухнедельных данных, с детализацией до секунды за 200 мс до момента полной отрисовки данных, и жили в этой системе довольно долго.
Между тем, время шло и количество данных росло. К 2016-му году объемы данных достигали десятков терабайт, что в условиях арендуемых SSD-хранилищ было существенным расходом.
К этому моменту активное распространение получили колоночные базы данных, о которых мы стали активно думать: в колоночных БД данные хранятся, как это можно понять, колонками, и если посмотреть на наши данные, то легко увидеть большое количество дублей, которые можно было бы, в случае использовании колоночной БД, сжать компрессией.
Однако ключевая для работы компании система продолжала работать стабильно, и экспериментировать с переходом на что-то другое не хотелось.
В 2017-м году на конференции Percona Live в Сан-Хосе, наверное, впервые о себе заявили разработчики Clickhouse. На первый взгляд, система была production-ready (ну, Яндекс.Метрика — это суровый продакшн), поддержка была быстрой и простой, и, главное, эксплуатация была простой. С 2018-го года мы затеяли процесс перехода. Но к тому времени «взрослых» и проверенных временем систем TSDB стало много, и мы решили выделить значительное время и сравнить альтернативы, для того чтобы убедиться, что альтернативных Clickhouse-у решений, согласно нашим требованиям, нет.
В дополнении к уже указанным требованиям к хранилищу появились свежие:
Какие системы мы стали рассматривать
Apache Hive/Apache Impala
Старый проверенный боями Hadoop-стэк. По сути, это SQL-интерфейс, построенный поверх хранения данных в собственных форматах на HDFS.
Скорость достигается масштабированием числа вычислительных серверов. Проще говоря, если мы большая компания, занимаемся аналитикой и бизнесу критически важно максимально быстро агрегировать информацию (пусть даже ценой использования большого количества вычислительных ресурсов), — это может быть нашим выбором. Но мы не были готовы кратно увеличивать парк железа для скорости выполнения задач.
Уже гораздо больше про конкретно TSDB, однако опять же — Hadoop-стэк.
Если в нескольких словах: Druid/Pinot выглядят лучше Clickhouse’а в случаях, когда:
Зарубежная альтернатива ClickHouse’у. Из минусов: High Availability присутствует только в коммерческой версии, но надо сравнить.
Попадает в шорт-лист тестирования.
С одной стороны, мы знаем, что ее используют для хранения метрических таймсерий такие системы мониторинга, как, например, SignalFX или OkMeter. Однако есть специфика.
Cassandra не является колоночной базой данных в привычном ее понимании. Выглядит она больше как строчная, но в каждой строке может быть разное количество столбцов, за счет чего легко организовать колоночное представление. В этом смысле понятно, что при ограничении в 2 миллиарда столбцов можно хранить какие-то данные именно в столбцах (да те же временные ряды). Например, в MySQL стоит ограничение на 4096 столбцов и там легко наткнуться на ошибку с кодом 1117, если попытаться сделать тоже самое.
Движок Cassandra ориентирован на хранение больших объемов данных в распределенной системе без мастера, и в вышеупомянутой CAP-теореме Cassandra больше про AP, то есть про доступность данных и устойчивость к разделению партиций. Таким образом, этот инструмент может замечательно подойти, если нужно только писать в эту базу и достаточно редко из нее читать. И тут логично использовать Cassandra в качестве “холодного” хранилища. То есть в качестве долговременного надежного места хранения больших массивов исторических данных, которые редко требуются, но при необходимости их можно достать. Тем не менее, ради полноты картины, протестируем и ее. Но, как я ранее говорил, нет желания активно переписывать код под выбранное БД-решение, поэтому тестировать мы её будем несколько ограничено — без адаптации структуры базы под специфику Cassandra.
Ну, и уже из интереса мы решили протестировать производительность стораджа Prometheus — просто для того, чтобы понять, быстрее мы текущих решений или медленнее и насколько.
Методика и результаты тестирования
Итак, мы протестировали 5 баз данных в следующих 6 конфигурациях: ClickHouse (1 нода), ClickHouse (распределенная таблица на 3 ноды), InfluxDB, Mysql 8, Cassandra (3 ноды) и Prometheus. План тестирования такой:
Также, чтобы лучше понимать, как потом интерпретировать полученные данные, представим, что мы не просто шлём кучу метрик, а метрики организованы в серверы — по 125 метрик на сервер. Тут сервер просто виртуальная сущность — просто чтобы понимать, что, например, 10000 метрик соответствуют примерно 80 серверам.
И вот, с учетом этого всего, наши 6 режимов нагрузки базы на запись:
Тут есть два момента. Во-первых, для кассандры такие размеры батчей оказались слишком большими, там мы использовали значения 50 или 100. А во-вторых, поскольку прометеус работает строго в режиме pull, т.е. сам ходит и забирает данные с источников метрик (и даже pushgateway, несмотря на название, в корне ситуацию не меняет), соответствующие нагрузки были реализованы с помощью комбинации static configs.
Результаты тестирования такие:
Что стоит отметить: фантастически быстрые выборки из Prometheus’a, ужасающе медленные выборки из Cassandra, неприемлемо медленные выборки из InfluxDB; по скорости записи всех победил ClickHouse, а Prometheus в конкурсе не участвует, потому что он делает инсерты сам внутри себя и мы ничего не замеряем.
В итоге: лучше всех себя показали ClickHouse и InfluxDB, но кластер из Influx’а можно построить только на основе Enterprise-версии, которая стоит денег, а ClickHouse ничего не стоит и сделан в России. Логично, что в США выбор, пожалуй, в пользу inInfluxDB, а у нас — в пользу ClickHouse’а.
Time series-данные в реляционной СУБД
Предлагаем вашему вниманию краткий пересказ выступления Ивана Муратова, нашего преподавателя на курсе «Архитектор высоких нагрузок». Речь идёт о докладе, с которым Иван выступил на конференции HighLoad++ Siberia 2019 в Новосибирске. Тема доклада — «Time series-данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL». Полную запись выступления смотрите здесь.
Time series-данные — это данные о процессе, которые собраны в разные моменты жизни этого процесса. Если мы говорим об автомобиле, то это его скорость, направление, координаты. Если мы говорим об использовании ресурсов на сервере, то это оперативная память, свободное место на дисках, нагрузка на CPU и т. д.
Можно выделить следующие особенности time series-данных или, как их ещё называют, временных рядов: — время фиксации. Любая time series-запись имеет поле с меткой времени, в которое было зафиксировано значение; — почти всегда работа происходит в append-only режиме. Таким образом, новые данные не заменяют старые. Удалению подлежат только устаревшие данные; — характеристики процесса (скорость, данные о нагрузке, координаты и т. п.) — это уровни временного ряда; — time series-записи не рассматриваются отдельно друг от друга. Данные используются только в совокупности по временным окнам, периодам или интервалам.
Time series-хранилища сегодня в тренде!
Если говорить о популярных решениях для хранения данных, то можно с уверенностью сказать, что Time series-хранилища сегодня в тренде. Этот факт подтверждает, к примеру, график с сайта db-engines.com, где отображена популярность различных моделей хранения данных за последние 2 года:
Как мы видим, сегодня в лидерах time series-хранилища, на 2 месте — графовые БД, затем key-value и реляционные базы.
С чем связана такая популярность специализированных хранилищ? Одна из причин — интенсивный рост интеграции информационных технологий: Big Data, IoT, мониторинг highload-инфраструктуры, соцсети. Ведь, кроме полезных бизнес-данных, даже метрики и логи занимают очень много ресурсов.
Решения для хранения time series-данных
Рассмотрим очередной график, где отображены специализированные решения для хранения time series-данных:
Лидером является InfluxDB. Впрочем, это неудивительно, и все кто работал с time series-данными, про этот продукт знают. Но хотелось бы отметить 10-кратный рост у TimescaleDB. О нём и поговорим.
TimescaleDB
TimescaleDB — это расширение к реляционной СУБД с открытым исходным кодом, которое борется за место под солнцем среди продуктов, изначально разработанных под под time series. Расширение оптимизировано для быстрой вставки и сложных запросов.
Особенности TimescaleDB: — устойчивая скорость записи при росте объёма базы под большими нагрузками, а также при увеличении количества партиций; — возможность использования стандартных возможностей PostgreSQL, таких как SQL, репликация, восстановление, резервное копирование и др.; — неплохой набор интеграций, к примеру, с Prometheus, Grafana, Zabbix, Telegraf, Kubernetes; — есть бесплатная версия с открытым кодом.
В первую очередь, TimescaleDB создана для хранения данных, с чем она прекрасно справляется. Это мощная система секционирования с минимальными ограничениями, если сравнивать с нативными в PostgreSQL.
Теперь пришло время сказать несколько слов про PipelineDB.
PipelineDB
PipelineDB — высокопроизводительное расширение, разработанное для выполнения непрерывных SQL-запросов для данных time series.
Особенности: — непрерывная обработка поступающих данные c помощью SQL и помещение результата в таблицу; — SQL-интерфейс; — возможны интеграции с Apache Kafka и Amazon Kinesis; — есть выполнение хранимых процедур по условиям; — есть бесплатная версия с открытым кодом; — разработка заморожена на версии 1.0, сейчас выходят лишь багфиксы.
В первую очередь, расширение PipelineDB создано для высокопроизводительной потоковой обработки данных. PipelineDB позволяет выполнять вычисления на больших массивах данных, при этом отсутствует необходимость сохранять сами данные.
Совместное применение PipelineDB и TimescaleDB
С PostgreSQL и этими расширениями мы сможем хранить и обрабатывать большие массивы данных time series, а применений можно придумать очень много. Вот, к примеру, реальный кейс из сферы мониторинга транспорта:
Итак, TimescaleDB позволяет хранить большие объёмы благодаря «хитрому» партицированию, а PipelineDB предоставляет работу со стримами и интеграцию с очередями прямо в PostgreSQL. А для задач, где одновременно нужна реляционная СУБД, NoSQL и time series, вышеописанный вариант использования PipelineDB и TimescaleDB может быть весьма удобен.
Чтобы «потрогать» всё самостоятельно, смотрите демо на GitHub либо запустите Docker-образ, внутри которого вы найдёте сборку из последнего PostgreSQL, PipelineDB и TimescaleDB.