Хабрахабр

Time series данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL

Time series данные или временные ряды — это данные, которые изменяются во времени. Котировки валют, телеметрия перемещения транспорта, статистика обращения к серверу или нагрузки на CPU — это time series данные. Чтобы их хранить требуются специфичные инструменты — темпоральные базы данных. Инструментов — десятки, например, InfluxDB или ClickHouse. Но даже у самых лучших решений для хранения временных рядов есть недостатки. Все time series хранилища низкоуровневые, подходят только для time series данных, а обкатка и внедрение в текущий стек — дорого и больно.

Ставите себе два расширения TimescaleDB и PipelineDB и храните, обрабатываете и проводите аналитику time series данных прямо в экосистеме PostgreSQL. Но, если у вас стек PostgreSQL, то можете забыть о InfluxDB и всех остальных темпоральных БД. Что это за расширения, в чем их преимущества и возможности, расскажет Иван Муратов (binakot) — руководитель отдела разработки в «Первой Мониторинговой Компании».
Без внедрения сторонних решений, без недостатков темпоральных хранилищ и без проблем их обкатки.

Что такое time series данные или временные ряды?

Это данные о процессе, которые собраны в разные моменты его жизни.

Например, местоположение автомобиля: скорость, координаты, направление, или использование ресурсов на сервере с данными о нагрузке на CPU, используемой оперативной памяти и свободном месте на дисках.

Временные ряды имеют несколько особенностей.

  • Время фиксации. Любая time series запись имеет поле с меткой времени, в которое было зафиксировано значение.
  • Характеристики процесса, которые называются уровнями ряда: скорость, координаты, данные о нагрузке.
  • Практически всегда с такими данными работают в append-only режиме. Это значит, что новые данные не заменяют старые. Удаляются только устаревшие данные.
  • Записи не рассматриваются отдельно друг от друга. Данные используются только в совокупности по временным окнам, интервалам или периодам.

Популярные решения для хранения данных

На графике, который я взял с сайта db-engines.com, отображена популярность различных моделей хранения данных за последние два года.

Популярность специализированных хранилищ связана с интенсивным ростом интеграции информационных технологий: Big Data, социальные сети, IoT, мониторинг highload-инфраструктуры. Лидирующую позицию занимают time series хранилища, на втором месте — графовые БД, дальше — key-value и реляционные базы. Кроме полезных бизнес-данных, даже логи и метрики занимают огромное количество ресурсов.

Популярные решения для хранения time series данных

На графике показаны специализированные решения для хранения time series данных. Шкала логарифмическая.

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

PostgreSQL это не только хорошая БД, но и расширяемая платформа для разработки специализированных решений.

Postgres, Postgis и TimescaleDB

«Первая Мониторинговая Компания» следит за передвижением транспорта с помощью спутников. Мы отслеживаем 20 000 транспортных средств и храним данные о перемещениях за два года. Суммарно у нас 10 ТБ актуальных телеметрических данных. В среднем, каждое транспортное средство во время движения отправляет 5 телеметрических записей в минуту. Данные отправляются с помощью навигационного оборудования на наши телематические серверы. В секунду они принимают 500 навигационных пакетов.

Новую систему мы назвали Waliot, и она уже в продакшн — 90% всех транспортных средств переведена на нее. Некоторое время назад мы решили глобально модернизировать инфраструктуру и переехать с монолита на микросервисы.

Сейчас мы работаем на версии 10 и готовимся к переезду на 11. В инфраструктуре поменялось многое, но центральное звено осталось неизменным — это база данных PostgreSQL. Кроме PostgreSQL, как основного хранилища, в стеке мы используем PostGIS для геопространственных вычислений, и TimescaleDB для хранения большого массива time series данных.

Почему PostgreSQL?

Почему мы пытаемся использовать реляционную базу для хранения time series, а не ClickHouse специализированные решения для этого типа данных? Потому что на фоне накопленной экспертизы и впечатлений от работы с PostgreSQL, мы не хотим использовать в качестве основного хранилища неизвестное решение.

Переход на новое решение — это риски.

Специализированных решений для хранения и обработки time series данных множество. Документации не всегда достаточно, а большой выбор решений не всегда хорошо. Кажется, что разработчики каждого нового продукта хотят писать все с нуля, потому что в предыдущем решении что-то не понравилось. Чтобы понять, что именно не понравилось, придется искать информацию, анализировать и сравнивать. Огромное разнообразие топов, рейтингов и сравнений скорее пугает, чем мотивирует что-то попробовать. Придется тратить много времени, чтобы перепробовать все решения на себе. Мы не можем себе позволить адаптацию только одного решения в течении нескольких месяцев. Это сложная задача, а потраченное время никогда не окупится. Поэтому мы выбрали расширения для PostgreSQL.

Но когда наткнулись на TimescaleDB и провели над ним тесты, вопросов о выборе не осталось. На этапе разработки инфраструктуры Waliot мы рассматривали в качестве основного хранилища телеметрических данных InfluxDB. Нам не нужно вытаскивать данные, трансформировать, проводить аналитику и перебрасывать их по сети. PostgreSQL с расширением TimescaleDB, позволяет использовать в рамках одного хранилища PostGIS или PipelineDB и другие расширения. Все вычисления выполняются на одном уровне. Все лежит на одном сервере или в кластерной системе — данные не нужно перетаскивать.

Пять из шести авторов статьи участвуют в разработке различных продуктов Apache и работают с потоковой обработкой. Недавно Николай Самохвалов, автора аккаунта postgresmen, опубликовал ссылку на интересную статью на тему использования SQL для потоковой обработки данных. Поэтому в статье упоминаются Apache Spark, Apache Flink, Apache Beam, Apache Calcite и KSQL от компании Confluent.

Автор топика пишет, что на основе статьи, реализовал почти все идеи на базе PostgreSQL 11. Но интересна не сама статья, а топик на Hacker News, в котором её обсуждают. Еще он использует несколько Foreign Data Wrappers. Он использовал расширения CitusDB для горизонтального масштабирования и шардирования, PipelineDB для потоковых вычислений и материализованных представлений, TimescaleDB для хранения time series данных и секционирования.

Сумасшедшая смесь из PostgreSQL и расширений к нему еще раз подтверждает, что PostgreSQL не просто СУБД — это платформа.

А когда завезут pluggable storage… Ухх!

Как думаете, что она делает? Иронично, что исследуя решения, мы нашли Outflux — разработку команды TimescaleDB, которую они опубликовали 1 апреля. Это утилита для миграции из InfluxDB в TimescaleDB в одну команду…

Postgres hype!

Нельзя недооценивать силу хайпа! Мы часто шутим, что «разработку двигает хайп», потому что он оказывает влияние на наше восприятия тулинга и инфраструктурных компонентов. На HighLoad++ мы много обсуждаем PostgreSQL, ClickHouse, Tarantool — это хайповые разработки. Только не говорите, что это не влияет на ваши предпочтения и выбор решений для инфраструктуры… Конечно, это не основной фактор, но ведь эффект есть?

Мне нравится это решение. Я работаю с PostgreSQL 5 лет. Каждый раз, когда у меня что-то с этой базой шло не так, были виноваты мои кривые руки. Практически все мои задачи он решает на ура. Поэтому выбор был предопределен.

TimescaleDB VS PipelineDB

Перейдем к расширениям TimescaleDB и PipelineDB. Что говорят о расширениях их создатели?

TimescaleDB — это time series база данных с открытым исходным кодом, которая оптимизирована для быстрой вставки и сложных запросов.

PipelineDB — это высокопроизводительное расширение, которое разработано для выполнения непрерывных SQL-запросов для time series данных.

Компания Timescale основана в 2015 году, а Pipeline в 2013. Кроме работы с time series данными, у них похожа история. По два года потребовалось командам, чтобы выпустить минимальную функциональность. Первые рабочие версии появились в 2017 и 2015, соответственно. Видимо, торопились друг за другом. Продакшн релизы обоих расширений прошли в октябре прошлого года с разницей в одну неделю.

Так устроен Open Source, ничего не поделаешь. В GitHub куча звезд и форков, в которых как обычно ни одного коммита. Но звезд много, у TimescaleDB больше, чем у PipelineDB, и даже больше, чем у самого PostgreSQL.

Кажется, что расширения похожи, но они позиционируют себя по-разному.

Расширение быстрее, чем InfluxDB, Cassandra, MongoDB или ванильный PostgreSQL. TimescaleDB заявляет, что у него вставка миллионов записей в секунду и хранение сотней миллиардов строк и десятков терабайт данных. TimescaleDB — это расширение, а не форк PostgreSQL. Поддерживает потоковую репликацию и средства резервного копирования.

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

TimescaleDB

Теперь подробно о расширениях. Начнем с TimescaleDB. С ним я работаю почти 2 года. Затащил его на продакшн еще до релизной версии. Рассмотрим на примерах, как его применять.

У нас есть метрики потребления ресурсов Docker-контейнеров, время фиксации метрик, идентификатор контейнера и поля с потреблением ресурсов, например, свободной памятью. Хранилище для метрик инфраструктуры. Запрос, который Вы видите решает данную задачу и TimescaleDB можно использовать в качестве хранилища для метрик инфраструктуры. Нам необходимо вывести статистику по всем контейнерам со средним количеством свободной памяти окнами по 10 секунд.

SELECT time_bucket(’10 seconds’, time) AS period,
container_id,
avg(free_mem)
FROM metrics
WHERE time > now() - interval ’10 minutes’
GROUP BY period, container_id
ORDER BY period DESC, container_id;

period | container_id | avg
-----------------------+--------------+---
2019-06-24 12:01:00+00 | 16 | 72202
2019-06-24 12:01:00+00 | 73 | 837725
2019-06-24 12:01:00+00 | 96 | 412237
2019-06-24 12:00:50+00 | 16 | 1173393
2019-06-24 12:00:50+00 | 73 | 90104
2019-06-24 12:00:50+00 | 96 | 784596

Для расчетов. Нам требуется рассчитать количество грузовых авто, которые покинули Краснодар и их общий тоннаж по дням.

SELECT time_bucket(’1 day’, time) AS day,
count(*) AS trucks_exiting,
sum(weight) / 1000 AS tonnage
FROM vehicles
INNER JOIN cities ON cities.name = ’Krasnodar’
WHERE ST_Within(last_location, ST_Polygon(cities.geom, 4326))
AND NOT ST_Within(current_location, ST_Polygon(cities.geom, 4326))
GROUP BY day
ORDER BY day DESC
LIMIT 3;

Здесь также используются функции из расширения PostGIS, чтобы вычислить транспорт, который именно покинул город, а не просто двигался в нем.

Третий пример о криптовалютах. Мониторинг курса валюты. Запрос позволяет отобразить, как менялась цена Эфириума относительно Биткоина и американского доллара за последние 2 недели по дням.

SELECT time_bucket(’14 days’, c.time) AS period,
last(c.closing_price, c.time) AS closing_price_btc,
last(c.closing_price, c.time) * last(b.closing_price, c.time)
filter (WHEREb.currency_code = ’USD’) AS closing_price_usd
FROM crypto_prices c
JOIN btc_prices b
ON time_bucket(’1 day’, c.time) = time_bucket(’1 day’, b.time)
WHERE c.currency_code = ’ETH’
GROUP BY period
ORDER BY period DESC;

Это все тот же понятный и удобный нам SQL.

Что такого крутого в TimescaleDB?

Почему не использовать встроенные средства секционирования таблиц? И зачем вообще разбивать таблицы? Очевидный ответ — это скорость вставки в такие базы. На графике отображены реальные замеры скорости вставки количества строк в секунду между обычной таблицей ванильного PostgreSQL 10 без секционирования, и гипертаблицей TimescaleDB.

Запись содержит время, идентификатор компонента инфраструктуры и 10 метрик. Этот бенчмарк записывает 1 миллиард строк на одной машине, имитируя сценарий сбора метрик с инфраструктуры. Вставка выполнялась пакетами по 10 тысяч записей. Бенчмарк выполнялся на Azure VM с 8 ядрами и 28 гигабайт оперативки, а также сетевыми SSD дисками.

Потому что при вставке нужно обновлять еще и индексы таблиц. Откуда такая деградация производительности PostgreSQL? Секционирование решает эту проблему, если индексы секции, в которую мы вставляем данные, помещаются в оперативную память. Когда они не помещаются в кэш, мы начинаем нагружать диски.

Здесь сравнивается система декларативного секционирования встроенная в PostgreSQL 10 и гипер-таблица TimescaleDB. Посмотрим на следующий график. По горизонтальной оси количество секций.

Разработчики расширения заявляют, что прекрасно справляются с 10 000 секций в одном инстансе PostgreSQL. В TimescaleDB деградация незначительна при увеличении количества секций.

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

Но, мне кажется, что TimescaleDB все равно лучше. В 11 и 12 версиях PostgreSQL появится нативная поддержка секционирования и можно попробовать прогнать сравнительные тесты для time series данных с новыми версиями. Все бенчмарки от TimescaleDB можно найти у них на гитхабе и попробовать.

Основные возможности

Надеюсь, у вас уже появился интерес к расширению. Давайте пробежимся по основным возможностями TimescaleDB, чтобы закрепить это чувство.

TimescaleDB использует термин «гипертаблица» для таблиц, к которым была применена функция «create_hypertable()». Секционирование через гипертаблицы. Сама родительская таблица не будет содержать никаких данных, а будет точкой входа для всех запросов и шаблоном при автоматическом создании новых секций. После этого таблица станет родительской для всех наследуемых секций — чанков. Это удобно тем, что мы не видим тысячи этих секции в схеме данных. Все секции хранятся не в основной схеме ваших данных, а в специальной схеме.

Через специальные хуки в PostgreSQL, TimescaleDB понимает, когда обращаются к гипертаблице. Расширение интегрировано в планировщик и исполнитель запросов. Это позволяет распараллеливать работу с секциями во время извлечение значительного объема данных. TimescaleDB анализирует запрос и перенаправляет запросы только в нужные секции на основе указанных условий в самом SQL-вызове.

Свободно можно использовать объединения, агрегаты, оконные функции, CTE и дополнительные индексы. Расширение не накладывает ограничений на SQL. Если вы видели список ограничений для встроенной системы секционирования, вас это должно порадовать.

Дополнительные полезные функции, специфичные для time series данных:

  • «time_bucket» — «date_trunс» здорового человека;
  • гистограммы — заполнение пропущенных интервалов с помощью интерполяции или последнего известного значения;
  • background worker’s — службы, которые позволяют выполнять фоновые операции: очистку старых секций, переорганизацию.

TimescaleDB позволяет остаться в мощнейшей экосистеме PostgreSQL. Это расширение не ломает PostgreSQL, поэтому все High Availability решения, системы резервного копирования, средства мониторинга по-прежнему будут работать. TimescaleDB дружит с Grafana, Periscope, Prometheus, Telegraf, Zabbix, Kubernetes, Kafka, Seeq, JackDB.

Grafana понимает «из коробки», что в PostgreSQL стоит TimescaleDB. В Grafana уже встроена нативная поддержка TimescaleDB в качестве источника данных. Можно прямо из реляционной базы с этими time series функциями строить графики без гигантских запросов. Билдер запросов в Grafana на дашбордах понимает дополнительные функции TimescaleDB, такие как «time_bucket», «first», «last».

Используйте адаптер, чтобы не хранить в Prometheus данные годами. В Prometheus реализован адаптер, который позволяет сливать данные с него и использовать TimescaleDB в качестве надежного хранилища данных.

Решение позволяет вообще удалить Prometheus. Также есть Telegraf-плагин. Данные инфраструктуры сразу передаются в TimescaleDB и читаются через Telegraf.

Лицензии и новости

Не так давно компания перешла к новой модели лицензирования. Основная часть кода открыта под лицензией Apache 2.0. Небольшая часть бесплатна в использовании, но находится под собственной лицензией TSL.

Не пугайтесь, не все вкусняшки в Enterprise-версии. Есть Enterprise-версия с коммерческой лицензией. В основном там автоматизации типа автоматического удаления устаревших чанков, которые можно сделать через простой «cron» и подобные вещи.

Возможно, оно попадет в Enterprise-версию. Сейчас компания активно работает над кластерным решением. Также есть облачная версия для стартапов, которые хотят успеть выйти на рынок, пока не кончились деньги инвесторов.

Из новостей:

  • один миллион загрузок за последние полтора года;
  • 31 млн долларов инвестиций;
  • активное сотрудничество с MS Azure по поводу IoT-решений.

Подытожим

Это мощная система секционирования с минимальными ограничениями, по сравнению с нативными в PostgreSQL. TimescaleDB создан для хранения time series данных.

К сожалению, пока расширение не имеет мультинодовой версии. Если захотите мультимастер или шардироваться, то придется поиграться, например, с CitusDB. Если хотите логическую репликацию, то будет больно. Но с ней всегда больно.

PipelineDB

Теперь поговорим про второе расширение. К сожалению, нам не удалось его как следуют опробовать в бою. Сейчас оно проходит стадию адаптации в нашей системе. Правда, есть одна проблема, о которой я скажу ближе к концу.

Так проще понять пользу от расширения и мотивацию его использовать. Как и в предыдущем случае, начнем с реальных примеров.

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

CREATE CONTINUOUS VIEW v AS
SELECT url::text,
count(*) AS total_count,
count(DISTINCT cookie::text) AS uniques,
percentile_cont(0.99)
WITHIN GROUP (ORDER BY latency::integer) AS p99_latency
FROM page_views
GROUP BY url;

url | total_count | uniques | p99_latency
-----------+-------------+---------+------------
some/url/0 | 633 | 51 | 178
some/url/1 | 688 | 37 | 139
some/url/2 | 508 | 88 | 121
some/url/3 | 848 | 36 | 59
some/url/4 | 126 | 64 | 159

На помощь приходит потоковая обработка данных и расширение PipelineDB. Расширение добавляет абстракцию «CONTINUES VIEW». В русском варианте это может звучать как «непрерывное представление». Это представление автоматически обновляется при вставке в таблицу с записями посещений, при этом только на основании новых данных, не читая уже записанные заранее.

PipelineDB не ограничивается только новым типом представления. Поток данных. Но мы не хотим хранить сами данные о действиях пользователя. Предположим, что мы проводим А/Б-тестирование и собираем аналитику в реальном времени об эффективности нового бизнес-решения. Нас интересует только результат — в какой группе больше конверсия.

PipelineDB вводит такую возможность. Чтобы избежать непосредственного хранения сырых данных для потоковых вычислений нам нужна такая абстракция как стримы — поток данных. Под капотом это будут «FOREIGN TABLE» на базе очереди ZeroMQ, которую незаметно от нас использует расширение. Вы можете создавать стримы как обычные таблицы. Данные поступают во внутреннюю очередь ZeroMQ и провоцируют обновление непрерывного представления.

CREATE STREAM ab_event_stream (
name text,
ab_group text,
event_type varchar(1),
cookie varchar(32)
); CREATE CONTINUOUS VIEW ab_test_monitor AS
SELECT name,
ab_group,
sum(CASE WHENevent_type = ’v’ THEN 1 ELSE 0 END) AS view_count,
sum(CASE WHENevent_type = ’c’ THEN 1 ELSE 0 END) AS conversion_count,
count(DISTINCT cookie) AS uniques
FROM ab_event_stream
GROUP BY name, ab_group;

Дальше мы создаем «CONTINUOUS VIEW» на основе данных из ранее созданного стрима. Когда данные будут поступать в стрим, представление будет обновлятся на основе этих данных. После этого данные будут просто отбрасываться, нигде не сохраняясь и не занимая место на дисках. Это позволяет строить аналитику на практически неограниченном количестве данных, загружая их в поток данных PipelineDB и читая результат вычислений из непрерывного представления.

После того, как мы создали поток данных и непрерывное представление, мы можем работать с потоковыми вычислениями. Потоковые вычисления. Это выглядит так.

INSERT INTO ab_event_stream (name, ab_group, event_type, cookie)
SELECT round(random() * 2) AS name,
round(random() * 4) AS ab_group,
(CASE WHENrandom() > 0.4 THEN ’v’ ELSE ’c’ END) AS event_type,
md5(random()::text) AS cookie
FROM generate_series(0, 100000); SELECT ab_group,
uniques
FROM ab_test_monitor; SELECT ab_group,
view_count * 100 / (conversion_count + view_count) AS conversion_rate
FROM ab_test_monitor;

Первый «SELECT» выдает группу «ab» и число уникальных посетителей. Второй — выдает соотношение между группами — конверсию. Вот и все А/Б-тестирование на пяти SQL-вызовах в реляционной базе.

Можно не ждать обработки всего массива данных, а читать промежуточные результаты, которые уже были обработаны. Представление обновляется динамически. Вы также можете объединять представление с таблицами или даже другими представлениями. Представления читаются так же, как и обычные в PostgreSQL. Никаких ограничений нет.

Топология

В Kafka поступает телеметрия, топик в Kafka отправляет эти данные в PostgreSQL, и мы дальше их агрегируем. Например объединяем с какой-то обычной таблицей и перенаправляем данные в стрим. Дальше он провоцирует обновление соответствующего непрерывного представления, из которого клиенты базы уже могут читать готовые данные.

Схема позаимствована из презентации Дерека Нельсона. Пример топологии PipelineDB компонентов внутри PostgreSQL.

Это представление, но направленное на преобразование входящего потока данных в модифицированный выходящий. Кроме стримов и представлений, расширение предоставляет также абстракцию «transform» — преобразователи или мутаторы. Из мутатора это все попадает в представление «CONTINUOUS VIEW». С помощью этих мутаторов можно изменять представление данных или фильтровать его. Кто знаком с функциональным программированием должен понимать идею. В нем уже производим запросы для бизнеса.

При всех этих вычислениях мы нигде не храним сами сырые данные, на основе которых мы все это считаем. В PipelineDB мы можем повесить триггер на наши представления и выполнять действия, например, «alert». Ведь нас интересует только результат расчетов. Это могут быть терабайты, которые мы загружаем последовательно на сервер с диском в сотню гигабайт.

Основные возможности

Расширение PipelineDB сложнее для освоения, чем TimescaleDB. В TimescaleDB мы создаем таблицу, говорим ей, что она гипертаблица, и радуемся жизни, используя несколько дополнительных функций, которые предлагает расширение.

Задача потоковой обработки данных сложнее, чем секционирование с точки зрения интеграции и использования. PipelineDB решает проблему потоковых вычислений в реляционных БД. Зачем усложнять инфраструктуру, если есть PipelineDB? При этом не у всех есть огромные данные и миллиарды строк. Он также интегрируется в планировщик запросов и исполнитель запросов позволяет реализовать концепцию потоковых вычислений в реляционной БД. Расширение предоставляет собственные реализации представлений, стримов, преобразователей и агрегатов для потоковой обработки.

Есть несколько особенностей, например, нельзя объединять два стрима, но это и не нужно. Как и TimescaleDB, расширение PipelineDB не накладывает ограничений на SQL в PostgreSQL.

Расширение использует «Фильтр Блума» для «SELECT DISTINCT», HyperLogLog для «COUNT (DISTINCT)», и T-Digest для «percentile_count()» прямо в SQL. Поддержка вероятностных структур данных и алгоритмов. Это повышает производительность.

Расширение позволяет работать с привычными High Availability решениями, средствами мониторинга и всем остальным, что привычно в PostgreSQL. Экосистема.

Так как PipelineDB это больше не форк, а расширение, то и интеграция с остальным зоопарком тоже должна быть «из коробки». Учитывая специфику потоковых вычислений, у PipelineDB есть интеграции с Apache Kafka, и с Amazon Kinesis — сервисом аналитики в реальном времени. Должна, но мы живем не в идеальном мире, и все стоит проверять.

Лицензии и новости

Весь код под лицензией Apache 2.0. Есть платная подписка на суппорт разных тиров, а также кластерная версия с коммерческой лицензией. На базе PipelineDB компания предоставляет сервис аналитики Stride.

Настало время о нем рассказать. 1 мая 2019 команда PipelineDB анонсировала, что теперь входит в состав Confluent. Перед тем, как я начал рассказывать про расширение, я сказал, что есть одно «но». Сейчас там работает Виктор Гамов, со-основатель подкаста Разбор Полетов. Эта та компания, которая разрабатывает KSQL — движок для потоковой обработки данных в Kafka с SQL синтаксисом.

PipelineDB заморозили на версии 1. Что из этого следует? 0. 0. Вследствие поглощения ожидаем убер-интеграцию Kafka с PostgreSQL. Кроме исправления критических багов в нем ничего не планируется. Возможно, именно Confluent на базе pluggable storage сделают что-нибудь крутое.

Переходить в TimescaleDB. Что делать? Конечно, сейчас функциональность не такая крутая, как в PipelineDB, но это вопрос времени. В последней версии сделали свои «CONTINUOUS VIEW» с блэкджеком.

Подытожим

Он позволяет выполнять вычисления на больших массивах данных без необходимости сохранять сами данные. PipelineDB создан для высокопроизводительной потоковой обработки данных.

С PipelineDB, когда мы отправляем поток данных в PostgreSQL в стрим, то считаем их виртуальными. Мы не сохраняем данные, а агрегируем, вычисляем и отбрасываем. Можно создать сервер на 200 гигабайт и через стримы прогнать террабайты данных. Мы получим результат, но сами данные будут отброшены.

Это открытый проект под лицензией Apache. Если по каким-то причинам вам недостаточно «CONTINUOUS VIEW» из TimescaleDB — попробуйте PipelineDB. Но все может изменится, Confluent пока не писали о планах по поводу расширения. Он никуда не денется, хотя и активно больше не разрабатывается.

Применение TimescaleDB и PipelineDB

С PostgreSQL и двумя расширениями мы можем хранить и обрабатывать большие массивы time series данных. Применений можно придумать много. Давайте рассмотрим пример из моей предметной области — мониторинг транспорта.

Они парсят различные текстовые и бинарные протоколы в общий формат и отправляют данные в Kafka в специальный топик. Навигационное оборудование непрерывно отправляет телеметрические записи к нам на серверы. Этот поток обновляет представление для текущего состояния транспортных средств и общей аналитики автопарка, а на базе триггера провоцирует запись телеметрических записей в гипертаблицу TimescaleDB. Оттуда они попадают через интеграцию с PipelineDB в поток данных телеметрии внутри PostgreSQL.

С расширениями у нас есть три преимущества.

  • Аналитика в реальном времени.
  • Хранилище time series данных.
  • Снижение объема хранимой телеметрии. С помощью мутатора PipelineDB мы агрегируем данные, например, по одной минуте, вычисляя средние значения.

В Grafana есть встроенная поддержка функций TimescaleDB. Поэтому возможно строить графики по бизнес-метрикам прямо из-коробки, вплоть до треков на карте по координатам. Отдел аналитики будет счастлив.

Чтобы «потрогать» все самому, посмотрите демо на GitHub и запустите Docker-образ — внутри сборка из последнего PostgreSQL, TimescaleDB и PipelineDB.

Итого

PostgreSQL позволяет комбинировать различные расширения, а также добавлять свои типы данных и функции для решения конкретных задач. В нашем случае, использование расширений TimescaleDB и PostGIS практически полностью покрывают потребности в хранении time series данных и гео-пространственных расчетах. С расширением PipelineDB мы можем проводить непрерывные вычисления для различной аналитики и статистики, а использование JSONB-столбцов позволяет хранить в реляционной базе слабоструктурированные данные. Open Source решений хватает с головой — коммерческие решения не используем.

Нам не нужен MongoDB, если есть JSONB-столбцы, и не нужен InfluxDB, если есть TimescaleDB. Эти расширения практически не накладывают ограничения на экосистему вокруг PostgreSQL, такие как High Availability решения, системы резервного копирования, средства мониторинга и анализа логов.

Подавайте заявку до 7 сентября на HighLoad++ в Москве. Понравилась история от Ивана и хотите поделиться чем-то подобным? Кроме кейсов по БД, будут доклады по архитектуре, оптимизации и, конечно, высоким нагрузкам. Программа постепенно наполняется. Подавайте доклад до дедлайна, ждем вас среди докладчиков!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть