The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск СУБД TimescaleDB 2.0

24.12.2020 09:49

Опубликован выпуск СУБД TimescaleDB 2.0, предназначенной для хранения и обработки данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений). Подобная форма хранения оптимальна для таких применений как системы мониторинга, торговые платформы, системы сбора метрик и состояний датчиков. Предоставляются средства для интеграции с проектом Grafana и Prometheus. Проект TimescaleDB реализован в виде расширения к PostgreSQL и распространяется под лицензией Apache 2.0.

Часть кода с расширенными возможностями поставляется под отдельной проприетарной лицензией Timescale (TSL), изначально не допускавшей внесение изменений, запрещавшей использование кода в сторонних продуктах и не разрешавшей бесплатное использование в облачных БД (database-as-a-service). В версии 2.0 в лицензию TSL были добавлены изменения, предоставляющие пользователям больше прав и позволяющие бесплатно использовать все возможности enterprise-версии, включая сжатие, распределение хранилища на несколько узлов и непрерывное агрегирование. В лицензии убраны ограничения области применения Community-сборки, предоставлено право на внесение улучшений и изменений, убраны платные привязки. В Community-редакцию перенесены все возможности, ранее предлагавшиеся в TimescaleDB Enterprise.

Основные изменения в TimescaleDB 2.0:

  • Предложена новая реализация непрерывно выполняемых агрегатных функций, позволяющих производить агрегирование непрерывно поступающих данных в режиме реального времени (напоминают материализированные представления PostgreSQL, но отличаются тем, что обеспечивают автоматический расчёт результатов запроса в фоновом режиме по мере поступления или изменения данных). Новая реализация примечательна изменением API, который теперь явно разделяет функции и правила агрегирования, что позволяет реализовать такие возможности как ручное обновление определённого диапазона в агрегированном представлении (например, можно автоматически материализировать свежие данные, но оставить старые исторические данные для ручного обновления). Изменения также позволят в дальнейшем реализовать поддержку распределённых операций при работе с несколькими узлами.
  • Добавлена поддержка действий, определяемых пользователем (UDA, User-Defined Action), для запуска по расписанию функций и процедур, написанных на произвольных языках (SQL, PL/pgSQL, C, PL/Python, PL/Perl). Новая возможность походит для выполнения периодических задач, которые не подпадают под имеющиеся политики подключения обработчиков (чистка устаревших данных, сжатие и непрерывное агрегирование).
  • Добавлена поддержка распределённых гипертаблиц (hypertable), позволяющих разносить хранилище на несколько узлов c TimescaleDB. Кластерная конфигурация на базе TimescaleDB включает в себя узел доступа и несколько узлов для хранения данных. Все запросы к распределённой гипертаблице направляются на узел доступа, после распределяются по узлам хранения.
  • Добавлена поддержка новых информационных представлений (Informational views), позволяющих получать сведения о гипертаблицах, узлах кластера, цепочках, политиках и расписании запуска работ.

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

Ключевой особенностью TimescaleDB является поддержка автоматического секционирования (партицирования) массива данных. Входной поток данных автоматически распределяется по секционированным таблицам. Секции создаются в зависимости от времени (в каждой секции хранятся данные за определённый промежуток времени) или в привязке к произвольному ключу (например, идентификатору устройства, местоположению и т.п.). Для оптимизации производительности секционированные таблицы могут распределяться по разным дискам.

Для запросов секционированная БД выглядит как одна большая таблица, именуемая гипертаблицей. Гипертаблица представляет собой виртуальное представление множества отдельных таблиц, в которых накапливаются поступающие данные. Гипертаблица используется не только для запросов и добавления данных, но и для таких операций, как создание индексов и изменение структуры ("ALTER TABLE"), скрывая от разработчика низкоуровневую сегментированную структуру БД. C гипертаблицей можно использовать любые агрегатные функции, подзапросы, операции слияния (JOIN) с обычными таблицами и оконные функции.

  1. Главная ссылка к новости (https://github.com/timescale/t...)
  2. OpenNews: Выпуск PipelineDB 1.0.0, надстройки к PostgreSQL для непрерывной обработки потоков
  3. OpenNews: Представлена СУБД InfluxDB 1.0
  4. OpenNews: Открыт код VictoriaMetrics, СУБД для временных рядов, совместимой с Prometheus
  5. OpenNews: Первый стабильный выпуск графо-ориентированной СУБД Nebula Graph
  6. OpenNews: Выпуск распределённой СУБД TiDB 4.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54308-timescaledb
Ключевые слова: timescaledb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:51, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Если бы как вариант движка для MySQL запилили - можно было бы щупать.
    А так - ну, есть...
     
     
  • 2.2, 1 (??), 10:52, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нда ...
    Заплати и сделают ... Хоть к sqlite
     
  • 2.11, Аноним (11), 12:02, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > MySQL
    > Time Series

    Так TimeSeries это про производительность, где очень много записей на единицу времени.

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

     
     
  • 3.12, mos87 (ok), 12:26, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    товарищ не довёл до логического гм конца - нужно не для MySQL, а на SQL Server Бызнес фор Энтерпрайзыс Идишн Экзекьютив Инсайтс фор БигДата

    только тогда труЪ

     

  • 1.3, Omnonm (?), 10:55, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Встречал только однажды как бд под немаленький заббикс, на замену штатному постгресу когда перевалило за полтерабайта.

    Где ещё оно имеет плюсы в использовании?

     
     
  • 2.8, Вшталик (?), 11:55, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Котировки тикетов
     
  • 2.10, Аноним (11), 11:58, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Где ещё оно имеет плюсы в использовании?

    Так любой кейс, где нужны TimeSeries - данные с датчиков (очень много предметных областей), метрики (same).

     
  • 2.13, Виталий (??), 12:41, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Любые данные где есть время и сами данные не должны меняться.
    аудит ( когда кто что сделал)
    финансовые операции (когда кто  что кому перевел)
    IOT (когда какой датчик что показал)

    Везде где таких данных ожидается много timescaledb сильно улучшает работу PostgeSQL и облегчает DBA работу.
    На небольших объемах (10 000 000 000) - очень удобно, даже на одном узле справляется,
    если нужно больше - то есть кластеризация (но ее сам не пробовал, она раньше платной была,
    да и у меня кейс простой, весь трафик муниципального транспорта одного региона хранить 3 месяца).

     
  • 2.15, valyala (?), 13:14, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Главный плюс TimescaleDB - она работает поверх Postgresql. Это значит, что пользователю доступны все плюшки postgresql при работе с TimescaleDB. Дальше идут одни минусы:

    - жрет disk IO быстро гробит SSD диски
    - тормозит на HDD
    - плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB
    - тормозит на больших объемах данных

    Поэтому лучше использовать VictoriaMetrics. https://valyala.medium.com/promscale-vs-victoriametrics-resource-usage-on-prod

     
     
  • 3.16, PetrG (ok), 14:05, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Впечатляет, но эти тесты показывают как оно работает из коробки под ваши задачи (например ACID и запросы вас не интересуют похоже).
    Я бы у Promscale поспрашивал что они по этому поводу думают - мне кажется что это можно настроить. Скорее всего всё равно медленнее будет (потому что TS сжимает с задержкой) но не настолько.
     
  • 3.17, Виталий (??), 14:06, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > жрет disk IO быстро гробит SSD диски

    Откуда такая информация?!

    >- тормозит на HDD

    Вообще-то оно ускоряет вставку в тот же postgresql
    (т.е если вы пишете в postgresql без timescaledb и с timescaledb - у вас результаты будут лучше с timescaledb)

    >- плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB

    Опять странная информация, откуда она?
    На голом postgesql у меня набор данных занимал 307GB, после сжатия стало 41GB - это очень "не плохо".

    > тормозит на больших объемах данных

    Он предназначен для работы в PostgreSQL - на объемах для postgresql - вообще не тормозит, на оборот, ускоряет работу PostgreSQL.

    >Поэтому лучше использовать VictoriaMetrics

    Чем лучше? Как там у VictoriaMetrics c Geospacial данными или хотя бы транзакциями?

    PS Нету лучшей и худшей БД, нужно всегда смотреть что лучше подходит под конкретную задачу.

     
     
  • 4.22, valyala (?), 16:54, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Из статьи, на которую приведена ссылка в предыдущем комментарии TimescaleDB поз... большой текст свёрнут, показать
     
     
  • 5.25, Аноним (11), 10:00, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому лучше использовать VictoriaMetrics

    Насчёт плюсов и минусов Вы правы (ну, почти).

    Только насчёт "лучше использовать мою разработку" - спорное утверждение. TimesclaeDB для малых и средних компаний обойдётся дешевле в поддержке (человекочасы как минимум) и развёртывании, аиспользовать VictoriaMetrics - оверинжиниринг, развёртывание ради развёртывания (или закладывание на годы/десятилетия, на случай роста). Не у всех есть DBA, но у всех есть бэкендер и фронтендер или хотя бы один фуллстек, а учить и прикручивать интеграции фуллстеку - ну такое, у заказчика всегда есть задачи посрочнее, чем трата времени на ещё одну технологию, у которой своя экасистема и свои потребности в изучении, развёртывании и обслуживании, бизнесу далеко не всегда такое объяснишь с первого раза.

    А если у компании есть объёмы больше терабайта, то да - Ваш продукт именно в этом сценарии лучше. То есть у компании при таких объёмах и доступных ресурсов должно быть больше (а не полтора разраба, как это часто бывает).

    > быстро выполнять запросы по недавно вставленным данным для всяких алертов

    В приведённых Вами статьях не использовались Continuous Aggregates, что показывает, что вы даже не разбирвались в тестируемом продукте, ибо это упоминается на главной же (даже не документации) странице TimescleDB. То есть Вы сделали тест ради тестов, зная как пользоваться только своей разработкой, не удосужившись даже открыть документацию конкурента. Любой, кто хотя бы это сделает (в отличие от Вас) поймёт, что тесты сделаны чисто в маркетинговых целях. При этом Вы называете себя Core Developer, а не PR-менеджером.

     
     
  • 6.29, RNZ (ok), 21:25, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Что-ты несёшь???"

    Континиус агрегаты - это как раз костыль что-бы компенсировать низкую производительность и в рантайме выполнять приращения. И чисто технически ничего не мешает разработчику victoriametrics запилить такую же функциональность в каком-нибудь из релизов на манер как это сделано для snapshot'ов
    http://<victoriametrics-addr>:8428/aggregate/create
    и в data правила агрегации.

     
     
  • 7.32, Аноним (11), 10:55, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так раз ты PR-щик VictoriaMetrics, скажи менеджерам, чтобы разрабы реализовали. А пока, не надо фичу, которой нет у твоего продукта, называть костылём.

    Или любые View и Materialized View, хранимые функции и процедуры - костыли?

    Если так, иди и скажи это миру РСУБД.

     
     
  • 8.35, RNZ (ok), 18:41, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Никакого отношения к victoriametrics не имею Так что мимо И как не называй, ко... текст свёрнут, показать
     
  • 5.28, Yilativs (?), 20:30, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> жрет disk IO быстро гробит SSD диски
    >> Откуда такая информация?!
    >Из статьи, на которую приведена ссылка в предыдущем комментарии.

    Там нет никакой информации о том, как был настроен postgresql -
    Вы верите статье на статьям производителя о конкурентах?
    А сами не пробовали тест воспроизвести?
    Может они как timescaledb - еще и тесты в github выкладывают, что бы можно было на своем железе потестить?

    >Geo-spatial функции пока планируются.

    Тогда в огромном классе задач связаных с IoT  и позиционированием они бесполезны.  

    >Транзакции для типичных задач, решаемых с помощью time series БД, не нужны

    Учет финансовых операций - типичная задача для time series баз данных и они часто ходят парой, т.е с одного счета списали, на другой записали.
    Расскажите, как это сделать бес транзакций?

    >Типичные требования под задачи для TSDB:
    > записывать постоянный поток данных со скоростями в миллионы строк в секунду

    Сотни или миллиарды уже не TS?
    Опеределение TS - вообще не связано с объемом.


    > быстро выполнять запросы по определенным рядам на определенных интервалах времени для построения всяких дашбордов в Grafana

    TS вообще ничего не знают про Grafana- картинки, это частный случай.

    TS базы данных - это базы, которые  сохраняют данные в которых присутствует  время, при этом данные не меняются после записи(append only) и добавляются в конец (recent).
    Классы задач под это:
    Аудит, мониторинг, финансовые транзакции, geo tracking

    Меньше верьте рекламным статьям, Сэр )

     
     
  • 6.30, RNZ (ok), 21:34, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>Geo-spatial функции пока планируются.
    >Тогда в огромном классе задач связаных с IoT  и позиционированием они бесполезны.

    Да ладно? Посчитать на apps религия не позволяет? И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis.

     
     
  • 7.31, Аноним (11), 10:53, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis.

    Вот ведь открытие! Так об этом и речь, что обычными SQL-запросами можно и TimeSeries, и GeoSpatial сохранять/обрабатывать/считывать. И никакого DSL не нужно, никаких сторонних библиотек, никакого допиливания драйвров/коннекторов.

    То есть Вы даже не спрашиваете, в каких случая и и как будет применяться инструмент, а просто набрасываетесь на аргументы? Просто потому что VictoraMetrics не умеет?

    Что, у VictoriaMetrics настолько плохо с маркетингом?

     
     
  • 8.36, RNZ (ok), 18:49, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У кого-то воображение разыгралось Я не набрасывался на аргументы, а возразил на... текст свёрнут, показать
     
  • 7.33, Аноним (11), 10:59, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    1. Вы когда-нибудь бэкенд-разработкой занимались?
    2. Вы когда-нибудь высоконагруженный сервис поддерживали?

    Если ответ на оба вопроса - да, то расскажите, пожалуйста, в каких случаях расчёты TimeSeries и GeoSpatial происходят "на apps"? А то мы, бедненькие бэкендеры, оказывается, не знаем как правильно, следим за потреблением памяти приложения, чтобы оно за гигабайты не сильно выходило, а вон оно как - надо базугнать в приложение и уже там ворочать данными, SQL не нужен, GeoSpatial не нужен, материалиованные представления не нужны, всё надо в памяти при каждом запросе считать.

     
     
  • 8.37, RNZ (ok), 19:37, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да 80G-100G в сутки с realtime детектированием пересечения геолокаций и 180млн ... текст свёрнут, показать
     
     
  • 9.38, Аноним (11), 09:26, 29/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не ответили на вопрос - в каких случаях 1 При запросах 2000 в секунду - как... текст свёрнут, показать
     
     
  • 10.40, RNZ (ok), 16:41, 29/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А я не стремился приводить все случаи, одного примера достаточно При минимуме и... текст свёрнут, показать
     
  • 9.39, Аноним (11), 09:30, 29/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А, тогда выступите с докладом на Highload , там Вы хоть от вопросов не увернёте... текст свёрнут, показать
     
     
  • 10.41, RNZ (ok), 16:45, 29/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну во первых выступление мне не нужно нет такой потребности , во вторых утвержд... текст свёрнут, показать
     
  • 6.34, Аноним (11), 11:06, 28/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Меньше верьте рекламным статьям, Сэр )

    Так он их и пишет, вот и продвигает свой продукт - он PR-менеджер.

    А судя по его аргументам, использовать оба продукта под реальной нагрузкой на проде никогда не пробовал.

     

  • 1.4, lockywolf (ok), 11:06, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем оно лучше rrdtool?
     
     
  • 2.5, 1 (??), 11:09, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    наверное тем, что хранит все данные.
     
     
  • 3.6, lockywolf (ok), 11:15, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > наверное тем, что хранит все данные.

    можно по-длиннее rrdtool

     
  • 2.7, Богдан Помазан (?), 11:54, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как вариант БД для логирования и трекинга транспорта можно использовать
     
  • 2.9, Аноним (11), 11:56, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >  Чем оно лучше rrdtool?

    Тем, что не нужно учить очередной DSL.

    Плюс нет нужды в написании или поиске отдельного драйвера для своего ЯП - любую нормальную ORM можно использовать для запросов к Time-series данным, что позволяет вообще писать на своём бекенд языке (речь не о JavaScript).

    Другие преимущества в этой новости перечислены, читайте внимательнее)

     
  • 2.24, Аноним (24), 08:40, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Один из явных минусов rrdtool это GPLv2. И не надо ляля про локалхост-поделки.
     

  • 1.14, Аноним12345 (?), 13:11, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Базы данных становятся все более мощными и более безумными
     
  • 1.18, Аноним (18), 14:06, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не нужно, есть influxdb и clickhouse.
     
     
  • 2.21, Аноним (11), 15:34, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не в каждой компании есть время и ресурсы, чтобы учить дополнительные DSL и развёртывать дополнительные сервисы с накручиванием дополниьтельной интеграции.

    TimescaleDB хорош как раз для случаев малых и средних компаний - не нужно искать/писать дополнительный драйвер (все полноценные ORM дружат с TimeScaleDB), не надо тратить время на изучение как с этим общаться, как развёртывать и как поддерживать ещё один сервис докучи - тот же Postgres, только немного по-другому обрабатывающий определённую табличку. Ничего от него не ломается, все джоины и прочие запросы могут выполняться между time-series и обычными данными.

    А так, для крупных предприятий с многомиллионными бюджетами на человекочасы, лицензии и железо - да, InfluxDB и ClickHouse.

     
  • 2.23, Аноним (23), 17:02, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно, есть TimescaleDB.
     
  • 2.26, Аноним12345 (?), 15:40, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У меня тоже первая мысль была - это же про кликхаус !
    Теплый и ламповый ...
     
  • 2.27, йо (?), 18:40, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Clickhouse не конкурент, не самое лучшее решение для timeseries (хотя идеальное для эвентов и логов). Influx конкурент, да, но, во-первых, не open source, поэтому оффтопик на этом сайте, во-вторых жрет памяти в 10 раз больше, и диска в 2 раза больше, в третьих -- язык запросов не PromQL с расширениями, как у Victoria metrics.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру