ограничения по max_bytes_to_merge_at_max_space_in_pool и перестали сливаться. В таблицу ведется непрерывная запись с большим количеством дублей. Есть какой-то best practice что в таких случаях делать? OPTIMIZE FINAL как-то не очень хочется, так как получу парт ~1.5тб. Есть идея детачить парт и вручную проверять на наличие дублей переливая уникальные данные назад. Может есть более элегантное решение?
а зачем? кликхаус сам в фоне это сделает максимально эффективно. или у вас в новом непрерывном потоке идут уже только уникальные строки, которые никак не пересекаются со старыми данными и вам хочется и старые данные привести в консистентное состояние? иначе если новые данные продолжают пересекаться со старыми, то в консистентном состоянии после оптимайза оно у вас проживёт максимум минуту.
фоновые мержи прекращаются если суммарный размер кусков для слияния больше чем max_bytes_to_merge_at_max_space_in_pool получается со временем на старых партах мержи прекращаются совсем и к ним добавляются всё новые и новые
На мой взгляд, надеяться на ReplacingMT в таких больших таблицах - архитектурная ошибка. Все время придется перемерживать те 1.5 терабайта, мало кто этого хочет. Побейте на партиции может?
Спасибо, Татьяна. Не бьется к сожалению разумно ( Буду костылить.
так взять хеш % 20 от какого нибудь ключа из ORDER BY
неплохой совет 👍, проблема что чтение по всей таблице, но попробую...
Обсуждают сегодня