так у вас нет репликации, вы что пытаетесь сделать?

На самом деле всегда есть вариант. Можно запустить десяток тредов с использованием between по кускам PK и это будет в целом норм. Если не хочется думать и делать update в лоб, то да, но всегда есть workaround

пропускная способность диска, ниже чем clickhouse хочет прочитать \ написать

читает \ пишет clickhouse достаточно много...

по таблицам - хочу иметь таблицы на нодах 1-8 (в рамках кластера clickhouse1), и иметь для вставки distributed таблицу

по партициям - хочу по запросу

```SELECT * FROM system.parts
WHERE active and database = '<db>'
```
получать список всех партиций


ЧЯДНТ?)

весь список из 778 пунктов.

1. слишком мелкие инсерты слишком часто.
2.  какой-то баран запустил optimize final
3. кто-то использует мутации неправильно
4. один из дисков вышел из строя

да все делаете не так

в 19 версии видимо нет system.distribution_queue, btw

19 is out of support

Привет. Переливаем данные из одной бд в другую на регулярной основе Python-ом. Какие бест практис на эту тему, чем лучше пользоваться?

select * from remore()

optimize final нельзя никогда?

что-то никак не пойму, вы хотите заменять старые записи, но не хотите использовать движок ReplacingMergeTree, всё так?

очень редко, равносильно перезаписи всей бд

по-моему логично валить ошибку запроса если нехватает места

ммм а как правильно жать данные?

они и так жмутся правильно, когда алгоритм решит, что "надо" иначе алгоритм считает, что оно того не стоит и не жмёт.

если не жмет никогда без принудиловки тогда что не так? GraphiteMergeTree

про графит ничего не скажу, это специфичный движёк, такие нюансы лучше сразу в вопросе указывать

Для графит да. Надо использовать optimize in partition final . Есть специальное приложение которое умное и в курсе как делать.

я только начинаю изучать clickhouse, но мне кажется, что ReplacingMergeTree есть аналогом UPSERT. т.е. он либо заменит, либо добавит новые строки. если же в истории, которую надо предварительно удалить, была строка с primary key таким, которого нет в новой "коррекции" данных, которую и надо залить, то это строка останется. ReplacingMergeTree не очень подходит. буду изучать можно ли менять бизнес требования и можно ли их изменить