Представлен (https://blog.timescale.com/1-0-enterprise-production-ready-t...) первый стабильный выпуск СУБД TimescaleDB (https://ww.timescale.com), пригодный для широкого использования. СУБД TimescaleDB ориентирована на хранение и обработку данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений), свойственные для таких применений как системы мониторинга, торговые платформы, опросы состояния датчиков, сбор метрик. Проект TimescaleDB реализован в виде расширения к PostgreSQL и распространяется (https://github.com/timescale/timescaledb) под лицензией Apache 2.0.СУБД позволяет применять полноценные SQL-запросы для анализа накопленных данных, сочетая удобство работы, свойственное реляционным СУБД, с масштабированием и возможностями, присущими специализированным NoSQL-системам. Ключевой особенностью TimescaleDB является поддержка автоматического секционирования (партицирования) массива данных. Входной поток данных автоматически распределяется по секционированным таблицам. Секции создаются в зависимости от времени (в каждой секции хранятся данные за определённым промежуток времени) или в привязке к произвольному ключу (например, идентификатору устройства, местоположению и т.п.).
Структура хранения оптимизирована для обеспечения высокой скорости добавления данных. Поддерживается пакетное добавления наборов данных, использование размещаемых в оперативной памяти индексов, загрузка исторических срезов задним числом, применение транзакций. Для оптимизации производительности секционированные таблицы могут распределяться по разным дискам (в будущем ожидается поддержка кластеризации с разнесением хранилища на несколько хостов). В одной из следующих версий планируется предоставить возможность определения политики вытеснения устаревших данных, что позволяет хранить только актуальные данные и автоматически удалять, агрегировать в более крупные промежутки времени или архивировать устаревшие записи.Для запросов секционированная БД выглядит как одна большая таблица, именуемая гипертаблицей. Гипертаблица представляет собой виртуальное представление множества отдельных таблиц, в которых накапливаются поступающие данные. Гипертаблица используется не только для запросов и добавления данных, но и для таких операций, как создание индексов и изменение структуры ("ALTER TABLE"), скрывая от разработчика низкоуровневую сегментированную структуру БД. C гипертаблицей можно использовать любые агрегатные функции, подзапросы, операции слияния (JOIN) с обычными таблицами и оконные функции.
TimescaleDB может применяться в качестве хранилища для систем мониторинга и визуализации Grafana (https://grafana.com/) и Prometheus (https://prometheus.io/), в том числе с TimescaleDB может использоваться развиваемый проектом Grafana визуальный редактор запросов. Кроме того, TimescaleDB также можно использовать в любых системах, поддерживающих хранение данных в PostgreSQL, таких как Tableau, Kafka, Apache Spark, Zabbix, PostGIS и PowerBI.URL: https://blog.timescale.com/1-0-enterprise-production-ready-t...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49547
А могли взять nats, clickhouse, или кафку.
возможно оно таки оптимизирует данные? тогда в этом есть смысл.
Какой-то бессмысленый набор слов. Куда взять? Зачем?
Или rrdtool, у которого полторы зависимости и базы мелкие :D
Не, там всё ж есть особенности, которые помешают сделать запрос вида: "какой пиковый LA был у сервера frontend1 месяца три назад?". Ну то есть, можно при создании rrd это поправить, но всё же геморрой там бОльший, чем взять соответсвующие средства.
Впрочем, для случая, когда число метрик*серверов меньше пары тысяч - вполне сойдёт.
Поправьте 2-ю ссылку в новости с https://ww.timescale.com/ на https://www.timescale.com/
> 2k18
> использовать www в имени хоста совсем как в 80-ых-90-ых
> 2018
> заменять ноль на "k" совсем как в... да никаких
Это признак современности и, вообще, крутизны.
Чем она лучше rrdtool ?
> Чем она лучше rrdtool ?Что угодно лучше rrdtool
Офигенная аргументация - "чем грузины".
sql жеж.
а не нечеловеческий синтаксис.А рисовать (для чего была нужна большая часть того синтаксиса) - оне все равно графаной будут. Где никакой не нужен, нужно мышкой быстро-быстро клац-клац-клац.
> sql
> не нечеловеческий синтаксисНо ведь…
сразу видно человека, никогда не пользовавшегося rrdtool ;-)поменяв что-то в чужом несложном графичке (нарисовать свой каждый...э...ну почти каждый чукча-писатель может, ты вот чужую писанину разбери - или даже свою, через годик) сразу начнешь любить и обожать sql.
Даже вместе с оконными функциями и рекурсивными запросами, которые для timescaledb вряд ли придется использовать или разбираться в чужих.
rrdtool как и sqlite - localhost only
ух ты. т.е. я могу прикрутить ее к БД заббикса и у меня хранилище станет Time Series ?
как жаббикс попатчишь чтобы он вместо своих тайммарок использовал "хренилище" - так и сможешь.в целом не так и сложно - ломать не строить.
Это можно будет сделать изменив лишь немного схему базы данных для того, чтобы партиционирование было автоматическим.
О да одни костыли, как и TimescaleDB костыль.
Можно взять TokuDB/RocksDB и не мучатся с PgSQL клонами на SSD.
убийца InfluxDB
Вряд ли... Тут даже с clickhouse может быть конкуренция только по доступной сложности запросов.
Надо понимать, что это postgresql, и оптимизации хранения нет.
Что это значит? Значит 24 байта оверхеда на каждую метрику + полная стоимость имени метрики (длинна имени метрики), таймстампа (8 байт), значения метрики (8байт), и прочее, и без какой либо компрессии.
Правильно ли я понимаю, что это выльется только в бОльший объем данных хранимых на диске?
Это убивает SSD.
ФС со сжатием поможет.
Нет - наоборот размер БД будет меньше