раз в 10 минут на 5 объектах +- одновременно. Объекты относительно небольшие/различные от 50к записей до 100кк записей. Какие существуют workaround, в случае, если это плохая пратика?
ну если 100кк это 100 000 000 записей. то нет если максимум 100k записей в таблице то есть на 5 таблиц 500k записей... то терпимо. но зависит от того какие у вас диски, какая еще при этмо нагрузка идет и какие требования к latency запросов в момент когда идет OPTIMIZE это нагрузка на диски + CPU + ram (потому что для дедупликации строится хеш таблица) нормальная практика это сделать нормальный ORDER BY и ReplacingMergeTree и делать SELECT ... FROM table FINAL ..
Спасибо за ответ. Final же все равно не гарантирует уникальности? Мы тестили и если в разных партициях (вроде как) лежит одинаковый ключ, то он никогда не смерджится. Но я могу ошибаться.
FINAL как раз и ганартирует уникальность... жертвуя от 5 до 15% потерей скорости..
про разные партиции. это регулируется специальной настройкой do_not_merge_across_partitions_select_final https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-final-clause-speed/ https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-optimize-vs-optimize-final/ https://kb.altinity.com/engines/mergetree-table-engine-family/merge-performance-final-optimize-by/ https://kb.altinity.com/altinity-kb-setup-and-maintenance/timeouts-during-optimize-final/ https://kb.altinity.com/engines/mergetree-table-engine-family/collapsing-vs-replacing/
ага, спасибо большое
Могу ещё предложить, что у вас ключи шардирования не настроены
ключи шардирования вообще никакого отношения не имеют к SELECT ... FINAL ... это для Distributed таблицы... и они при SELECT вообще не используются, только при INSERT в engine=Distirbuted
Обсуждают сегодня