Добрый день! Вопрос по оптимальному применению clickhouse Есть проект, данные с

определённой периодичностью добавляются, а так же изменяются (сортировка по категориям, рассчёты на основе сырых данных), так же выполняются большие SELECT запросы для построения отчётов . Сейчас хранение данных организованно на PostgreSQL, но с увеличением количества данных увеличилось и время обработки 1 запроса.

При поиске более быстрого решения выбор пал на clickhouse(причина выбора в названии чата собственно описана очень лаконично). Но однако, встал вопрос обновления данных, насколько я понял привычного обновления данных в clickhouse нет, и прочтя доки пришёл к выводу, что есть 2 пути:
1. VersionedCollapsingMergeTree (изменения состояний объекта)
Эта штука подходит для точечного изменения и имеет недостаток в том что при построении запросов для сбора статистики надо будет указывать фильтры чтобы туда не попал левый sign
2. мутации ALTER UPDATE
Эта штука вроде как могёт в обновлении пачками, но во первых пугает вот эта строчка из документации: "Но после применения первой мутации формат данных таблицы становится несовместимым с предыдущими версиями и откатиться на предыдущую версию уже не получится." и вот этот "При этом атомарности нет — куски заменяются на помутированные по мере выполнения и запрос SELECT, заданный во время выполнения мутации, увидит данные как из измененных кусков, так и из кусков, которые еще не были изменены."


Собственно вопросы:
1. Правильно ли я всё понял и это действительно только 2 возможных варианта обновления?
2. Если я не прав, то какие есть варианты помимо?

даже не пробуйте второй вариант, убьете диски и не получите что хотите CollapsingMergeTree + SELECT ... FINAL вполне себе работает

1. Ещё есть ReplacingMergeTree если удалять не надо, только обновлять

Даже если есть потребность обновлять данные не точечно, а пачками?

А можно подробнее как именно обновлять записи используя этот движок?

CollapsingMergeTree в целом пофигу сколько вы обновляете на самом деле вы просто пишете UPDATE как DELETE (sign -1 / old values) + INSERT (sign +1 new values) и дальше всю работу делает SELECT ... FINAL и background merges когда данные из двух кусков сливаются. то что имеет одинаковые значения ORDER BY ... но разные sign -1и +1 просто схлапывается и не пишется в новый кусок..

Точно так же как VersionedCollapsing, только sign не надо. По ключу сортировки + поле с версией

Это примерно понятно, при обновлении получается так, что я запишу ещё раз страую версию строки, и новую. Но при этом старой версии дам sign -1 и когда нибудь оно схлопнется с новой.

А почему может быть проблема с дисками?

потому что мутация

потому что мутация полностью переписывает выбранные парты применяя к ним мутацию....

Все это читал, но все равно не очевидно при чем здесь ресурс дисков?

ну посчитайте у вас два парта по 10 гигайбайт вам нужно применить миграцию вам нужно прочитать 2*10 гигабайт и потом записать 2*10 гигабайт итого 40 гигов i/o ок. теперь посчитайте что вам надо это сделать 100 раз в секунду (ну или как вы там собрались часто мутации запускать) короче мутации не выход поймите что у clickhouse eventual consistency by design и в соответсвии с этим действуйте

Я вас понял, примерно так и предполагал, но хотел услышать точный ответ - 100 раз в секунду по 20Гб конечно не вариант), но если проводить мутации по расписанию раз в 10минут\час\день, и например изменения затрагивают не все парты, то возможно этот подход будет работать?

будет. как вам уже сказали, но в момент SELECT, часть партов изменена, часть нет... получаете то что получаете... materialized view + aggregatedmergetree или projection будет быстрее

Я просто сейчас пробую схему с мутациями, при этом новым данным, до проведения мутации я ставлю признак что они еще не актуальны. В процессе мутации признак изменяю на актуальный, а старые записи помечаю на удаление. Промежуток мутаций не чаще чем раз в 10-30 минут, и в любой момент времени данные консистентны - поскольку новые хоть и записаны, но до обработки в запросах не фигурируют, а старые данные пока не переведены на удаление.

ну посмотрите в system.part_log чтобы оценить сколько там читается и пишется по вашим мутациям

Спасибо, посмотрю