типа (id, currency, value)
запрос SELECT count() FROM table GROUP BY curreny выполняется 0.39с, прочитано 1 миллиард строк, 5 Гб, 2.5 миллиарда строк в секунду, 12.5 Гб/секунду
Добавляю row policy (https://kb.altinity.com/altinity-kb-queries-and-syntax/row_policy_using_dictionary) для нескольких ID и тот же запрос выполняется немного дольше (0.82с), кол-во прочитанных строк все так же 1 миллиард, а вот прочитанных данных становится 21 Гб (в 4 раза больше)
Причем такая картина наблюдается в любых формат row policy, и через словарь, и через subquery, и через условие id not in
А в примерах из статьи кол-во прочитанных данных не меняется
Все запросы и лог их результатов загрузил сюда (https://pastila.nl/?019fca78/ebb1ed99d01eb705d88b8f3bff661d55#59A40mEFT+bJS25wD1PFCQ==)
Наверное currency не первая в ключе сортировки и приходится всё читать. А id какое-то высокардинальное поле первое стоит
Но откуда появляется х4 прочитанных данных? Насколько я понимаю кликхаус читает данные с диска по выбранным условиям и в какой-то момент проверяет "а соответствует ли данная строчка row policy"
1. clickhouse — колоночная база 2. первому запросу — count() group by lowCardinality, достаточной прочитать одну колонку (currency). сделайте explain запроса и увидите. 3. второму надо уже подключать скан первой, чтобы отфильтровать а там тяжелые uuid. + судя по количеству просканированных строк, индекс по id особо и не помогает (скорее всего, из-за рандомного распределения высококардинальных значений)
Обсуждают сегодня