(600 миллионов строк) и пришел к выводу что ни FINAL ни argMax ни другие варианты не дают адекватную скорость, ожидание по 4-8 секунды каждого запроса. На меньших объемах (<1кк строк) FINAL реально летает, а вот ближе к полу миллиарду все становится грустно.
Правильно ли я понимаю что это нормально, что с 600кк строк ни длинна order by ни настройки кх не помогут и надо менять бизнес логику?
Почему у вас запросы с final работают против 600млн? Так и задумано?
На 1кк строках FINAL практически не влияет на скорость. На 600кк строках - очень влияет
Прям вот же: https://clickhouse.com/docs/ru/sql-reference/statements/select/from#select-from-final
Обычно делают более интеллектуальное что-нибудь. Типа дневные партии. По ночам принудительно финализируют optimize. Запросы против старых данных гоняются без final. Против свежих сегодняшних с final. Но серьезные приложения типа метрики конечно не используют final для таблиц с ивентами. Все подобное делается в etl.
Благодарю 🙏
Где то был доклад как в метрики делали дедубликацию на YDB :)
а с обновлением данных? Похоже что ждать асинхронные мутации это лучшее решение на текущий момент, если FINAL отметаем, и argMax и тому подобные тоже
Нельзя делать UPDATE для одной строки
А ведь для N строк UPDATE нельзя сделать? Допустим мне надо поменять значения колонок в 10-20 колонках за раз... попробую посмотреть в сторону CollapsingMT, если не поможет похоже надо будет смотреть в сторону DELETE+INSERT
Можно, если предварительно запихнуть данные в словарь в памяти. Однако в ETL не нужно делать никаких мутаций. Только руками. Смотрите в сторону CollapsingMT и разных интересных схем сортировки и партиционирования таблицы, вместе с преобразованиями из одной таблицы в другую. Правильный путь где-то там. Но точно не в мутациях.
Обсуждают сегодня