так же зависит от среднего размера партишна после деления... иначе optimize final будет очень долгим...

@dj_mixer я думаю, optimize final при любом количестве партиций будет работать +/- одинаково по времени, т.к. суммарный объем данных во всех партициях одинаковый (здесь я не учитываю параллезацию выполнения optimize).

Интересно другое.

Рассмотрим пример. Есть диск, и на него залиты данные в объеме 60% от размера диска (40% на диске остаются свободными).  Далее два варианта: а) все данные лежат одной оптимизированной партицией и б) данные в 10 оптимизированных партициях. Для простоты, у нас только одна колонка, т.е. в варианте а) имеем один bin файл размера ~60% от диска, в варианте б) десять bin файлов, каждый по ~6% от диска. Вопрос, что будет если мы запустим optimize final?

Предположение. Что в варианте а) КХ откажется выполнять оперяцию при попытки резервирования места на диске. В варианте б) будет запущено 6 операций мерджа, резервируется 6 * 6% < 40% под результат, и далее по мере работы будут запускаться мерджи оставшихся партиций. В итоге операция завершится успешно.

Мое предположение основано только на теоритическом представлении о работе КХ. Пжл поправте меня, если я ошибаюсь.

>optimize final при любом количестве партиций будет работать +/- одинаково по времени
не совсем.
1. вы можете динамически проверять и делать его только на тех где реально были обновления (>1 парта).
2. у вас тупо парт может не влезть в память, а как КХ спиллит сам я не знаю. Но неспроста в КХ есть макс размер парта. Думается после какого-то размера парта будет просадка. Надо тестить.

в вашем примере:
первый вариант точно упадет, так как КХ хранит старые парты некоторое время, т.е. нужно место...
второй - может не упасть, потому что у КХ есть ограничение в background pool (но может и упасть если у вас всего несколько партишнов).

ну и вообще при более мелких партишнах, вы сможете  делать optimize final - (1) итеративно, (2) пропускать партишны которые не обновлялись (полный optimize final будет отрабатывать на всей таблице всегда, даже если по показаниям ничего делать не надо)...

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

резервируется для мержа размер парта*2.

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

озу мержам не нужно, мержи делаются именно слиянием, но кусками по merge_max_block_size, т.е. в памяти 8192 строки из каждого парта

если сделать 1000 партиций в такой таблице -- нужно думать как делать инсерты

optimize final мержит то что может, т.е. если партиций 10, а место на мерж есть только для одной, то смержит одну

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

Подскажите, пожалуйста, в какой момент вычисляются TTL выражения? При записи или во время слияний?

можно ли как-нибудь узнать сколько будут весить данные, которые отдаются КХ по запросу?

Посоветуйте, какой engine взять для небольшой (пара десятков записей) таблицы?

а что это за таблица то?

словарь?

типа справочника, да

тогда посмотри на external dictionary

для него надо чтобы данные где-то еще лежали, по мне так лишнее.

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

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

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

Dictionary источником которого сделать кх.

А в кх какой тип таблицы взять?

MergeTree.

без партиций?

Для пары десятков записей? Конечно без)