Привет, подскажите, пожалуйста, по "легковесному" удалению. Оно производится в два шага: -

удаляемые строки таблицы помечаются в дополнительной колонке _row_exists
- вызывается мутация по удалению строк с проставленной колонкой _row_exists

Можно ли как то сказать ClickHouse не запускать второй шаг (мутацию на удаление)?

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

а первый шаг это апдейт?

вот здесь описано

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

в 23.3 вроде бы уже не экспериментальное (вот первый пункт в changelog)

Стабильнее не стало, имхо прост для маркетинга изменили

понятно спасибо

Мутация и так сама по себе не запускается, Во время мержей строчки чистятся

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

Мержи отключать не надо, это нормальный процесс, не трогайте)

ну мам, я только посмотреть что будет)

мутацию можно запустить самому через alter delete, думал, что можно легковесно наметить много данных на удаление, а потом все удалить безвозвратно

> думал, что можно легковесно наметить много данных на удаление, а потом все удалить безвозвратно Ну +- так и будет, кх сам не будет запускать дорогую мутацию, ток если будет мерж может подчистить строчки

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

DELETE WHERE _row_exist=1

Кх не должен просто так запускать такие мутации, даже если было несколько LWD запросов, емнип

возможно, да, но проверять опасно) будем ждать обновлений по этой фиче, если они будут

https://docs.altinity.com/releasenotes/altinity-stable-release-notes/23.3/altinity-stable-23.3.8/ Вообще мы недавно ченджлог выкатили на 23.3

спасибо, удобно собрано

накопите лучше в приложении что нужно удалить... и удаляйте обычным мутациями как ALTER TABLE ... DELETE WHERE id IN ()

как вариант, да, можно придумать такую схему

просто lightweight deletes это такое wanna be production ready ... а на самом деле IMHO оно противоречит дизайну clickhouse https://github.com/ClickHouse/ClickHouse/issues/39870

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

Да не, сама по себе фича норм. Проблема с реализацией в кх, и тем как происходят мутации