ок, а если включить её когда в distributed папке есть бины, они допосылаются после рестарта? или руками надо будет перекинуть?

Это не знаю

Хотел так: события падают в мерджетрее таблицу. Но она не помещается на диск. Поэтому ее предагрегировать, и складывать предагрегированную события в другую таблицу. А первую подчищать

Я вам намекал уже на engine=Null

Да, но я тупой. Можно, как-то поразвернутей намекнуть, плиз

Вам первая таблица вообще нужна? Селекты из нее делаются? Или только агрегированная нужна?

MV это триигер и он получает данные от команды insert поэтому у первой таблицы можно сделать engine=Null и все будет работать.

Первая типа приемник, сама по себе не нужна

Ну вот замените ее движок просто на Null

Спасибо!

И можно использовать input  function будет тоже самое только текст агрегации можно вписать в insert и не создавать mv

И тогда инсертить прямо в агрегированную таблицу

Всем привет.
Регулярно возникает проблема с переименованием таблиц.

Есть CH версии 20.5.4. Есть таблица MergeTree. В неё каждый час загружается текущее состояние данных из mysql - таблица выгружается полностью, так как по ней в мускуле идёт большое количество апдейтов.
Чтобы для пользователей кликхауса таблица не моргала, скрипт перегрузки данных делает вот так:
1) Данные из TSV грузит в {table}_new;
2) Как только данные влились, делает рокировку: RENAME TABLE  {table} TO {table}_old, {table}_new TO {table};
3) DROP TABLE {table}_old;
Проблема в том, что по факту в 2/3 случаев получается очень плохо:
- целевая таблица мигает - исчезает на сотни секунд;
- иногда вообще валится ошибка WRITE locking attempt on "{table}_new" has timed out! (120000ms) Possible deadlock avoided. Client should retry. IN:RENAME TABLE {table} TO {table}_old, {table}_new TO {table}

Увеление lock_acquire_timeout ни к чему не привело - в большей части случаев RENAME всё равно не успевает выполниться, плюс целевая таблица оказывается невидна на время куполнения RENAME.
Судя по system.query_log у нас нет запросов, которые выполнялись бы более 30 секунд.
Сама по себе таблица, на которой происходит проблема - небольшая, буквально 20ГБ в Clickhouse.

Собственно вопросы:
1) Что можно еще попробовать, чтобы решить проблемы с а)  видимостью таблицы во время RENAME б) больщим временем выполнения RENAME?
2) Возможно, схема с RENAME  TABLE вообще не рабочая, и не надо пытаться сейчас реашать проблему из предыдущего пункта, а есть работающие устоявшиеся практики для полной перегрузки таблиц?

скажите пожалуйста, что значит
PARTITION BY tuple()

значит одну партицию на таблицу

спасибо!

попробуйте alter table ... replace partition ... from ...

https://gist.github.com/den-crane/521975b5333c5dc7059bed4030f62f94

до 19.14 rename был атомарный (с global lock) и ваша схема работала, но иногда это приводило к дедлоку с зависанием КХ, сейчас пилится Engine=Atomic, но видимо еще не готов.

Всем доброго дня, скажите а в чем циммес: при селектах UUID принимается нормально в where при инсертах, тоже, но вот при update надо toUUID это как ??? =)))

Полагаю toUUID https://clickhouse.tech/docs/en/sql-reference/functions/uuid-functions/amp/

скорее всего просто не доделано

Да, вероятно, ибо на гите есть об этом еще в 18году