LINUX.ORG.RU

Официальный релиз TimescaleDB 1.0

 , ,


5

3

TimescaleDB 1.0 — это первая в мире открытая enterprise-ready темпоральная (time-series database) база данных, где ключи - временные метки, что используется для логирования событий с очень высокой скоростью. TimescaleDB является расширением СУБД PostgreSQL.

Релиз уже скачан более миллиона раз и используется в Comcast, Cray, Блумберг, Cree.

В этом релизе поддерживаются Windows, FreeBSD, и NetBSD и добавлена поддержка Prometheus.

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от Aceler

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

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

anonymous ()

Очередной энтерпрайз фантик для попила? Или нет и всё же в этом прикол есть? Пока что кроме маркетинговых слов ничего не видно. По ссылке какой то блог с картинками как установить psql на azure и ещё облаке каком то и это вся документация. Нет исходников, нет банальной загрузки. Что происходит я ничего не понимаю

FUNCTION ()
Ответ на: комментарий от Aceler

UTF8String (tag 12)? Это не rocket science - могли две строчки дописать в любую опенсорсную.

parihaaraka ()
Ответ на: комментарий от Bobby_

тебе же написали - 1 млн. событий в секунду. Если 100 клиентов пишут параллельно получается субмиллисекундый диапазон.

Можно пример таблицы, на которой почувствуется превосходство перед postgre?

madcore ★★★★★ ()

Может кто-нибудь ответить чем это лучше логирования по сокету в elasticsearch?

NoName ()

Судя по количеству озадаченых коментов никто не понимает чем это отличается от MySQL с ключем в виде timestamp. А зря. Тут все другое. Я не знаю как тут реализовано, но в голову приходят многие вещи, как бы это можно было ускорить. Во первых эта база может быть eventually consistent, значит данные не сразу доступны для запросов. Во вторых никто не говорит о latency, только о throughout. Значит на сервере условно говоря можно открыть одну здоровенную виртуальную транзакцию, накопить несколько тысяч записей от клиентов и сбросить блоб на диск. Если надо, то можно хоть целую секунду ждать, накапливая. Плюс здесь нету скорее всего uniqness constraints, потому что это никого не волнует и запросов по одному ключу никто не делает. Ещё БД может поддерживать режим вставки целого файла. Сформировал клиент файл, которые накапливал в течении получаса, можно его просто положить на диск по ssh/FTP/NFS, вызвать легковесный вызов и оно в БД. Может не сразу готово для запросов. Уже не говоря о автоматической материализации агрегированных данных по разным временным интервалам точности, которые легко делать налёту. И ещё гибкая retention чтобы хранить например последний день в памяти, а остальное только в хранилище.

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

Update Прочитал что оно на базе PostgreSQL. Не проблема, часть вышеперечисленного будет работать на PostgreSQL если ее использовать умно. Например не вызывать один insert на одну точку, а накапливать блобы

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 3)

темпоральная

темпанальная. time-series database это база данных временнЫх рядов.

anonymous ()
Ответ на: комментарий от vertexua

Чем timestamp отличается от другого целочисленного ключа? Более того, в общем случае он не будет уникальным.
А описанные оптимизации можно организовать на клиентской стороне с любой бд.
В общем, пока непонятно.

madcore ★★★★★ ()
Ответ на: комментарий от madcore

Что значит на клиентской? Тут оптимизация от многих клиентов вместе. Да, на клиент-сайде, но на прокси сервере, через который все пишут. Вроде это и делает эта БД

vertexua ★★★☆☆ ()
Ответ на: комментарий от anonymous

А быстрый sequantial scan - это именно то, что постгрес делать в принципе не способен.

Отсюда поподробнее плиз.

dimgel ★★ ()

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

anonymous ()

InfluxDB для метрик просто на удивление хорош.

shlag ()
Ответ на: комментарий от dimgel

Быстрый sequential scan ограничивается скоростью чтения с диска. Поэтому: 1) данные должны лежать на диске последовательно; 2) данные должны храниться в максимально сжатом виде; 3) данные надо хранить по столбцам, чтобы читать только нужные столбцы. И ещё 4) все вычисления, фильтрация и агрегация должны быть очень быстрыми, чтобы не быть медленнее скорости последовательного чтения с диска.

Дык в постгресе первых трёх пунктов не будет в принципе, а с четвёртым вот только в версии 11 начали что-то делать, но до реальной скорости там как до Москвы по стекловате. Ибо постгрес оптимизирован под point queries с использованием индексов, а для временных рядов и аналитики есть свои решения, и не надо натягивать ежа на кактус.

anonymous ()
Ответ на: комментарий от anonymous

Дык в постгресе первых трёх пунктов не будет в принципе,

Собственно по этим пунктам как раз и хотелось уточнений. Я хз как там у него устроено, но из общих соображений могу предположить только про неоптимальное хранение строк (в т.ч. char(n)), но здесь последовательное хранение данных противоречит их сжатости; ЕМНИП постгрес хранит строки как-то отдельно, т.е. с сжатостью должно быть всё ок, а с последовательным хранением данных — не очень. Хранение по столбцам — забавно, не приходило в голову, но это действительно круто противоречит любым запросам кроме seqscan: допустим, чтобы взять одну запись по ключу, придётся поднимать несколько страниц (по количеству столбцов) вместо одной; вообще непонятно, кому могут быть интересны такие радости.

(UPD: разве что обсуждающимся здесь спец.базам, но мне как-то больше про SQL-базы общего назначения интересно.)

dimgel ★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от anonymous

Дык в постгресе первых трёх пунктов не будет в принципе

а ничего, что именно postgresql и занимается всем этим низкоуровневым делом, а эта байда просто упрощает процесс для человека.

anonymous ()
Ответ на: комментарий от anonymous

Дык в сабже ничего этого и нет, это просто автоматический шардинг для постгреса. Как тормозил, так и тормозит.

anonymous ()
Ответ на: комментарий от NoName

Может кто-нибудь ответить чем это лучше логирования по сокету в elasticsearch?

Подавился кофе. Нельзя быть настолько труЪ

router ★★★★★ ()
Ответ на: комментарий от dyasny

Данных по производительности TimescaleDB пока не нашёл. Есть краткое сравнение

https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4...

Без привязки к сабжу, в общих чертах, TSDB это не СУБД, а специализированая база ( как nosql предназначен для хранения key-value, так tsdb для хранения метрик производительности ). Нет необходимости в связях между базами, запись - только дополнение, но не модификация и т.д.

За счёт таких жертв на своей задаче работают существенно быстрее, и существенно менее требовательны к ресурсам.

Ну и свой язык запросов, позволяющий выполнять операции над несколькими временными рядами ( например, построить график (a(t)+b(t))/c(t)*100 ). Есть правила, как поступать, когда данных по одной из time series за определённый timestamp нет. Есть свои операции над векторами

См. например https://prometheus.io/docs/prometheus/latest/querying/basics/

Опять же, это всё теория, и непосредственно timescaledb я не щупал. Т.к. я не разработчик и меня интересуют более-менее готовые к использованию игрушки, к которым уже есть примеры работы :)

TSDB используются в современных системах мониторинга ( prometheus, influxdb stack и т.д. ). Недавно в zabbix добавили поддержку, но пока не смотрел

Как timescaledb чувствует себя поверх универсальной СУБД не знаю. Но из плюсов можно назвать полноценную репликацию ( у influxdb только в коммерческой версии, причём говорят работает не айс ) и бекапы

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Спасибо за лекцию, но она не нужна. Я всего лишь сказал что миллион операций в секунду даже тормозная java based cassandra способна вытянуть

dyasny ★★★★★ ()
Последнее исправление: dyasny (всего исправлений: 1)
Ответ на: комментарий от dyasny

Вопрос в последующих запросах. Или Кассандра умеет в агрегацию [с приемлемой скоростью]?

AlexM ★★★★★ ()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

Я не рекламирую кассандру но да, она часто используется как бэкэнд для kairos например. А если взять scylla (на правах рекламы) то железа понадобится в разы меньше.

dyasny ★★★★★ ()
Ответ на: комментарий от dimgel

Хранение по столбцам — забавно, не приходило в голову, ...

Есть такая база SAP HANA, вот в ней всё хранится по столбцам. А сами данные держатся в ОП, то есть вся база в ОП. Насколько знаю, используется только для BI (DWH и тому подобные сокращения) - если коротко, то SAP :)

tomb ()

Ужасный перевод.

Не существует такого слова - темп-оральный! Это извращенная запись иностранного английского (латинского) слова кирилицей. Temporal - означает временный с точки зрения приходящий, переменный.

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

Сами по себе временные ряды это совсем другая сущность. Использовать для них SQL или интегировать с SQL сервером это все равно, что ставить лошадь впереди машины.

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

lefsha ()

А сами данные держатся в ОП, то есть вся база в ОП.

А прикольно. Так заморачиваться при хранении данных в RAM — разве что ради оптимизации использования кеша CPU при seqscan при выборке подмножества столбцов (особенно если сами столбцы небольшие, например числовые). Если угадал, то красавцы.

Ещё сто лет назад было шушушу про мемристоры, но чёт давно ничего не слышал; ежели эта тема вдруг когда-нить пойдёт в массы, то хранение по столбцам вполне может быть заюзано многими SQL-серверами.

dimgel ★★ ()

Щупал SAP HANA пару лет назад, и она сильно (минимум на порядок) уступала по скорости kdb+. kdb+ - маленькая (меньше мега) и помещается в кэш CPU. А HANA - монстр. Как и сабж, похоже.

alt-x ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.