Comments 16
Весьма прикольные штуки, жаль вторая заморозилась.
Спасибо за подробный обзор!
Посмотрел в гугле сравнение TimescaleDB с ClickHouse. Кажется у последнего производительность повыше и места данные занимают значительно меньше.
Как раз стою перед выбором. Пока не могу понять, что лучше использовать.
Посмотрел в гугле сравнение TimescaleDB с ClickHouse. Кажется у последнего производительность повыше и места данные занимают значительно меньше.
Как раз стою перед выбором. Пока не могу понять, что лучше использовать.
Главный посыл доклада в том, что не стоит спешить с выбором систем, которые, либо еще сырые (для боевой среды), либо ограничены в функционале (тот же SQL), и в котором Вам еще предстоит разобраться (а это уже месяцы и даже годы изучения и практики, для проф уровня).
Т.е. если у Вас используется в инфраструктуре PostgreSQL и Вы хорошо его знаете, то расширение TimescaleDB это прекрасное дополнение к уже богатому функционалу PostgreSQL.
Очень многое зависит от данных, скорости вставки, периода хранения, и т.п.
Но, в большом количестве случаев, будет достаточно PostgreSQL (с расширением TimescaleDB если это Time series данные).
Т.е. если у Вас используется в инфраструктуре PostgreSQL и Вы хорошо его знаете, то расширение TimescaleDB это прекрасное дополнение к уже богатому функционалу PostgreSQL.
Очень многое зависит от данных, скорости вставки, периода хранения, и т.п.
Но, в большом количестве случаев, будет достаточно PostgreSQL (с расширением TimescaleDB если это Time series данные).
binakot Спасибо за доклад.
Вы смотрели в сторону VictoriaMetrics?
Высокая производительность и низкое потребление ресурсов по сравнению с конкурирующими системами. В некоторых тестах VictoriaMetrics опережает InfluxDB и TimescaleDB при выполнение операций вставки и выборки данных до 20 раз. При выполнении аналитических запросов выигрыш по сравнению с реляционными СУБД PostgreSQL и MySQL может составлять от 10 до 1000 раз.
Вы смотрели в сторону VictoriaMetrics?
Высокая производительность и низкое потребление ресурсов по сравнению с конкурирующими системами. В некоторых тестах VictoriaMetrics опережает InfluxDB и TimescaleDB при выполнение операций вставки и выборки данных до 20 раз. При выполнении аналитических запросов выигрыш по сравнению с реляционными СУБД PostgreSQL и MySQL может составлять от 10 до 1000 раз.
Около полугода назад выбирал хранилище для time series данных. Победил кликхаус. Понятно, что он еще сырой, и там есть свои ньюансы. Но таймскейл вообще не порадовал. Особенно грустно, что нету сжатия из коробки. Единственный вариант — это ZFS. Но это гораздо сложнее (ну для меня точно). Получается, что кликхаус из коробки дает 4-10х сжатие. + у кликхаус сжатие есть уже на уровне драйвера, чего насколько я знаю нету в TimescaleDB. То есть трафик по сети тоже будет 4-10х больше чем у кликхауса. Тоже самое касается и производительности.
Да, возможно понадобится использовать ZFS.
Но PostgreSQL(+ext. TimescaleDB) и не конкурируют (пока) с тем же ClickHouse по скорости выполнения аналитических запросов, и тем более по уровню сжатия.
Здесь немного про другое. Про возможность хранения данных (time series в данном примере) в реляционной БД. В той же БД, рядом с обычными таблицами.
При этом, остаётся полноценный SQL, все возможности PostgreSQL, и вся его экосистема.
Но PostgreSQL(+ext. TimescaleDB) и не конкурируют (пока) с тем же ClickHouse по скорости выполнения аналитических запросов, и тем более по уровню сжатия.
Здесь немного про другое. Про возможность хранения данных (time series в данном примере) в реляционной БД. В той же БД, рядом с обычными таблицами.
При этом, остаётся полноценный SQL, все возможности PostgreSQL, и вся его экосистема.
Да, я понимаю аргументы за. У нас как раз был такой кейс. У нас был постгрес и аналитика, которая агрегировалась на лету (постгрес отлично справлялся). И вот, понадобилось хроанить сырые данные. А сырых данных 100 ГБ в день. И вот получается, что если использовать постгрес, то надо платить за 3ТБ диски за месяц данных. А если килкхаус, то за 300 ГБ. Такие дела. То есть тут даже за аналитику речь еще не заходит. Просто харнить сырые тайм серии сами по себе в постгресе супер дорого выходит.
Если без сжатия, то да.
Я планирую попробовать ZFS с тем же LZ4 сжатием, и посмотреть результаты.
В будущей версии расширения TimescaleDB появится возможность переноса чанков старше N времени на отдельный tablespace. Т.е. к примеру, горячие данные у Вас на SSD, а более старые на более медленных SAS дисках с ZFS файловой системой (со сжатием).
Я планирую попробовать ZFS с тем же LZ4 сжатием, и посмотреть результаты.
В будущей версии расширения TimescaleDB появится возможность переноса чанков старше N времени на отдельный tablespace. Т.е. к примеру, горячие данные у Вас на SSD, а более старые на более медленных SAS дисках с ZFS файловой системой (со сжатием).
Подскажите, чем решение из топика лучше того же постгреса с табличкой из дататайм и необходимых параметров(координаты гпс, например)?
Автоматическое управление секциями/чанками (создание, удаление ...).
Оптимизация под Time series данные — более быстрая вставка. Интеграция с планировщиком запросов PG — оптимизация запросов. К примеру, на уровне планирования запроса отсекаются, и не сканируются ненужные чанки.
Посмотрите внимательнее запись этого доклада)
Почитайте статьи в блоге blog.timescale.com
Посмотрите записи докладов www.youtube.com/channel/UCPmHSkid9IOYbdN1Psh24lg
Почитайте доку docs.timescale.com/latest/main
Найдёте ответ.
Оптимизация под Time series данные — более быстрая вставка. Интеграция с планировщиком запросов PG — оптимизация запросов. К примеру, на уровне планирования запроса отсекаются, и не сканируются ненужные чанки.
Посмотрите внимательнее запись этого доклада)
Почитайте статьи в блоге blog.timescale.com
Посмотрите записи докладов www.youtube.com/channel/UCPmHSkid9IOYbdN1Psh24lg
Почитайте доку docs.timescale.com/latest/main
Найдёте ответ.
В статье об этом написано, стоит почитать, как минимум была речь про скорость вставки.
При выборе бд для временнЫх рядов руководствуюсь общим подходом к решению дилеммы Sql/NoSql. Если метаданные содержат исключительно независимую атомарную инфу, как то — метрики, логи, аналитика — берём NoSql. Даже если в фирме больше экспертизы по Sql. По факту того, что NoSql проще в деплое и зачастую проще для разработчиков. При этом выбор конкретной noSql субд носит второстепенный характер имхо, если конечно речь не идёт о мегахайлоаде.
Если же в одной из колонок есть бизнес данные, например, серийный номер конечного продукта, с которого снимается рабочий сигнал (а конечный продукт в моём кейсе имеет контролируемые параметры, привязан к партии аналогичных продуктов, в составе которой он выпускается в эксплуатацию и т.д.) — то строго Sql. Поскольку данные в измерении не атомарны, и поддерживать согласованность всё равно придётся так или иначе. Зачем согласовывать вручную, если для этого есть целый Sql — вопрос риторический
Если же в одной из колонок есть бизнес данные, например, серийный номер конечного продукта, с которого снимается рабочий сигнал (а конечный продукт в моём кейсе имеет контролируемые параметры, привязан к партии аналогичных продуктов, в составе которой он выпускается в эксплуатацию и т.д.) — то строго Sql. Поскольку данные в измерении не атомарны, и поддерживать согласованность всё равно придётся так или иначе. Зачем согласовывать вручную, если для этого есть целый Sql — вопрос риторический
Sign up to leave a comment.
Time series данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL