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

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

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

А потом такой открываешь для себя ClickHouse...

И пишешь по одной строке пару млн раз в секунду, и он умирает на решарде. Он для батчей only, даже с буфером

agile scrum big data

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

Ну вот я и дописывал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данных по производительности 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 только в коммерческой версии, причём говорят работает не айс ) и бекапы

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

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

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

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

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

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

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

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

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

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

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

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

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

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