The OpenNET Project / Index page

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

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

18.04.2020 09:25

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

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

Среди изменений в TimescaleDB 1.7:

  • Добавлена поддержка интеграции с СУБД PostgreSQL 12. Объявлена устаревшей поддержка PostgreSQL 9.6.x и 10.x (в Timescale 2.0 останется поддержка только PostgreSQL 11+).
  • Изменено поведение запросов с непрерывно выполняемыми агрегатными функциями (агрегирование непрерывно поступающих данных в режиме реального времени). Подобные запросы теперь комбинируют материализированные представления с недавно поступившими данными, которые ещё не материализированы (ранее агрегирование охватывало только уже материализированные данные). Новое поведение применяется для вновь создаваемых непрерывных агрегирований, для существующих представлений следует выставить параметр "timescaledb.materialized_only=false" через "ALTER VIEW".
  • В Community-версию из коммерческой редакции перенесены некоторые расширенные средства управления жизненным циклом данных, включая возможности по перегруппировке данных и обработке политик вытеснения устаревших данных (позволяют хранить только актуальные данные и автоматически удалять, агрегировать или архивировать устаревшие записи).

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

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

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


  1. Главная ссылка к новости (https://github.com/timescale/t...)
  2. OpenNews: Открыт код VictoriaMetrics, СУБД для временных рядов, совместимой с Prometheus
  3. OpenNews: Доступна СУБД TimescaleDB 1.0
  4. OpenNews: Удаление Эрика Рэймонда из списков рассылки OSI и этические вопросы в открытых лицензиях
  5. OpenNews: Выпуск СУБД TimescaleDB 1.2 с изменением модели лицензирования
  6. OpenNews: Выпуск документоориентированной СУБД Apache CouchDB 3.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52759-timescale
Ключевые слова: timescale, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:48, 18/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Годнота
     
     
  • 2.10, анонимчик (?), 12:38, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.
     
     
  • 3.16, Аноним (1), 13:44, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Подскажи тогда годноту, если ты такой эксперт
     
     
  • 4.17, Аноним (17), 14:01, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Victoriametrics.
     
     
  • 5.23, Аноним (1), 16:24, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если мне нужно не для метрик, а для исторических данных на десятки терабайт?
     
     
  • 6.27, нах. (?), 18:22, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А если мне нужно не для метрик, а для исторических данных на
    > десятки терабайт?

    а sql им зачем?

     
     
  • 7.31, Аноним (31), 20:40, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для запросов
     
     
  • 8.41, нах. (?), 10:00, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а теперь расскажи нам, как выглядит запрос к бд с метрикой, снимающеся раз в, до... текст свёрнут, показать
     
     
  • 9.46, Аноним (46), 19:51, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Скрытый экстремум сам придумал ... текст свёрнут, показать
     
     
  • 10.57, нах. (?), 22:41, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну просто намек, что очевидный алгоритм в лоб будет неверным - съест резкие ... текст свёрнут, показать
     
  • 7.56, DeadMustdie (??), 21:04, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а sql им зачем?

    Чтобы самим не писать вручную алгоритмы доступа к данным, включая миллионную в мире кривую реализацию Hash Merge.

    А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.

     
     
  • 8.58, нах. (?), 22:54, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    хренассе а точно-точно timescale это то, что подходит для подобных данных п... текст свёрнут, показать
     
     
  • 9.61, DeadMustdie (??), 23:35, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Агрегировать и фильтровать умеет, результат в виде таблицы выдаёт Дальше вопрос... текст свёрнут, показать
     
  • 6.29, Lex (??), 20:25, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    “ и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.“ ?

    Ви таки собрались изменять «исторические данные» задним числом ?

     
     
  • 7.37, funny.falcon (?), 09:24, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не вопрос. Подскажи что-нибудь для хранения исторических данных и разнообразных запросов к ним без возможности изменения.
     
     
  • 8.66, qsdg (ok), 17:35, 21/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Victoriametrics же выше сказали Отключай автоматический ретеншн, и будут твои д... текст свёрнут, показать
     
  • 7.38, funny.falcon (?), 09:26, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А друшой момент: бывают данные не срвсем исторические, но скорость изменения которых падает пропорционально их возрасту.
     
  • 7.42, Алексей Морозов (ok), 16:36, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не мы такие, жись такая.

    Вот идет поток, скажем, от GPS-трекера. И все бы хорошо, но время от времени этот чертов трекер начинает досылать данные, накопленные в своем черном ящике,

     
     
  • 8.59, нах. (?), 22:56, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а где тут изменение данных Просто добавление не синхронное же ... текст свёрнут, показать
     
  • 6.68, qsdg (ok), 17:45, 21/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А если мне нужно не для метрик, а для исторических данных на
    > десятки терабайт?

    В подходящей базе десятки терабайт превращаются в просто терабайты, а если повезёт, то и в гигабайты, за счёт data-aware компрессии.

    Для olap -- кликхаус. Для метрик -- victoriametrics.

    У таймскейла вообще никакая компрессия, всё время тормозит из-за IO.

     
  • 4.28, анонимчик (?), 19:15, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Подскажи тогда годноту, если ты такой эксперт

    кликхаус

     
     
  • 5.48, DeadMustdie (??), 20:47, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > кликхаус

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

     

  • 1.3, Аноним (3), 10:57, 18/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Скажите мне непросвещённому, чем оно лучше того же MySQL?
     
     
  • 2.15, Catwoolfii (ok), 13:24, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    mysql не поддерживает time series?
     
     
  • 3.34, Аноним (34), 21:38, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А разве на СУБД без подобных расширений нельзя хранить выборки через заданные промежутки времени? А то разработчики всяких там АИИС КУЭ и не знают.
     
     
  • 4.36, Аноним (36), 02:23, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можно, но mysql вряд ли сможет нормально работать с таблицей с триллионами записей на одном сервере, в то время как для специализированных БД для временных рядов - это детская нагрузка. https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/CaseStudies#adsterra
     
     
  • 5.40, нах. (?), 09:52, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    осталось понять, являются ли сопли и клей поверх postgres "специализированной бд для временных рядов", и насколько быстро тот постгрез лопнет.

     
     
  • 6.49, DeadMustdie (??), 20:50, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > являются ли сопли и клей поверх postgres

    В каких-то пределах являются.
    Разумной альтернативой является разве что Informix с его Time Series, концептуально история аналогично.
    И да, там только за деньги (не очень большие, правда), и ни разу не open source.

     
     
  • 7.60, нах. (?), 22:58, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это если хочется именно sql.

     
  • 2.30, Lex (??), 20:27, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Тем же, чем и блокчейн[ т.е ничем, но хомяки одобрят ]
     
     
  • 3.65, Аноним (65), 13:17, 20/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > одобрят

    Вы им не говорите, что данные менять нельзя, а то не одобрят.

     

  • 1.11, анонимчик (?), 12:39, 18/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    чем оно лучше кликхаус?
     
     
  • 2.20, Аноним (-), 15:19, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    чем анонимчик отличается от дегенерата?
     
     
  • 3.21, КО (?), 16:10, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ничем, duh...
    Аргументы пожалуйста
     
  • 2.22, Аноним (22), 16:14, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    тем что тормознутее, ибо pq не колоночная DB.
     
     
  • 3.51, DeadMustdie (??), 20:54, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > тем что тормознутее, ибо pq не колоночная DB.

    В subj для хранения временных рядов используются специфические структуры данных.
    Построчное хранение идентификационной информации по рядам не обязательно плохо влияет на производительность, там данных обычно на 3 копейки, особенно на фоне самих рядов.

     
  • 2.24, Аноним (24), 18:08, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А чем сабж лучше чем DB2?
     
     
  • 3.50, DeadMustdie (??), 20:52, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А чем сабж лучше чем DB2?

    Не совсем сравнимо. Скорее аналог - Informix Time Series, который проработан существенно лучше, но реализует ту же самую идею.

     
  • 2.32, Аноним (31), 20:43, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В clickhouse нет транзакций например.
     
     
  • 3.35, анонимчик (?), 21:41, 18/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то плюс для таймсериес
     
     
  • 4.52, DeadMustdie (??), 20:55, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > тем что тормознутее, ибо pq не колоночная DB.

    А вот не факт.
    Приложения разные бывают.

     
  • 4.63, Аноним (-), 10:56, 20/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    отсутствие транзакций никогда не является плюсом, это всегда компромис во имя чего-то другого
     

  • 1.33, Аноним (36), 21:35, 18/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, насколько хорошо timescaledb работает с триллионами строк? Victoriametrics нормально работает, судя по https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/CaseStudies#adsterra
     
     
  • 2.39, funny.falcon (?), 09:27, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Представьте себе: хранить нужно не только метртки.
     
     
  • 3.44, anonymous (??), 18:21, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.
     
     
  • 4.53, DeadMustdie (??), 20:56, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.

    Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica.

     
  • 4.54, DeadMustdie (??), 20:57, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В целом - жизнь немножко шире любых представлений о ней ;)
     

  • 1.43, анонимуслинус (?), 16:44, 19/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вот она база данных для научных вычислений и экспериментов. вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))
     
     
  • 2.55, DeadMustdie (??), 21:02, 19/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))

    Интересный вопрос.
    Когда я последний раз интересовался (довольно давно), самая здоровая единая реляционная БД в мире как раз обслуживала вроде бы ЦЕРН-овский, если не путаю, ускоритель. И сделана она была на DB2 в горизонтально масштабируемой конфигурации (Database Partitioning Feature = DPF, если быть точным).

    Но воды с тех пор немало утекло, так что рекордсмен наверное поменялся.

     
     
  • 3.62, Анончик (?), 06:01, 20/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.
     
     
  • 4.64, DeadMustdie (??), 11:31, 20/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.

    Не путаю, у Оракла встроенный "шардинг" лишь относительно недавно появился, и до сих пор довольно кривенький.

     
  • 2.67, qsdg (ok), 17:39, 21/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В коллайдере у них там несколько уровней предобработки данных перед записью, на каждом уровне по 99% данных выбрасываются за ненужностью. И только потом записываются. Иначе в мире дисков не хватит чтобы сырые данные с одного эксперимента записать.
     

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



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

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