222 миллиона строк. В каждой есть колонка date с min(date)='2022-03-01' и max(date)='2022-04-01'.
Отличаются таблицы только в DDL.
Первая - Partition By date Order By tuple()
Вторая - Order By date
Третья - Partition by date Order By (date, userId, orderId)
Четвертая - без партиций и сортировки. Данные те же самые
Делаю запрос с указанием диапазона дат. И не вижу почти никакой разницы в usage_memory
Это норм? или не норм?
P.s. query_duration_ms и memory_usage должны коррелировать или нет?
Да так и должно быть вы добавили первым в ORDER BY с большой кардинальности
usage memory не должно меняться кх читает данные в потоке, обрабатывает по 65к строк за раз на 1 треде
Usage_memory разный. А таблицы одинаковые. Почему так?
А в чём тогда смысл Order By и Partition By если чтение таблицы с этими настройками и без них ничем не отличается? Или я не туда смотрю?
позволяет меньше прочитать с диска -> ускорить запрос это не значит что оперативной памяти надо будет пропорционально меньше
сделайте таблицу без order by и partition by, и увидите, что чтение с where по date без них очень даже отличается)
А как правильно оценить изменение скорости чтения? query_duration_ms в рамках одного и того же запроса - меняется
Нa MergeTree без order_by нельзя создать таблицу
без order by по date я имел в виду
Базовая идёт c tuple() и не отличается от остальных
включите send_logs_level = 'trace' и наблюдайте за изменением числа читаемых гранул с диска
1. explain estimate 2. system.query_log
Я и пользуюсь system.query_log
read_rows, read_bytes. Без партицирования будет больше
На скриншоте видно, что это не так.
так у нее партиционирование по date, этот ключ движок и использует
А вариант без order by и partition by?
Без партицирования. Я же описал условия. Втоаря таблица вообще без партиций, только Order by по date. Базовая таблица без партиций тоже, там order by tuple()
Там же есть. И в нём нет разницы.
может, я куда-то не туда смотрю, но тут написано, что во всех трех таблицах date либо в sorting key, либо в partition key
На скрине есть четвертая, generated_data. Там нет ни партиций ни сортировки P.s. Добавил описание
А 200 это ли не лимит dbeaver на количество загружаемых строк? Попробуйте вместо этого делать select count() ...
А смысл select count() если по факту он обратится к файлам не с данными, а с мета данными ?
это можно отключить прямо в рамках запроса
Да, лимит бобра. Делал лимит 300 000 и Select * разницы тоже не было. Полдня развлекаюсь.
Поймите, что Кликхаус не экономит память, он жрёт как можно больше при любых условиях.
Разницу все равно будет видно, в read_rows точно
Это ок, мне бы скорость выполнения запроса увеличить. Кликхайс же пипец какой быстрый=) Вот результат count(distinct date) для тех же таблиц
Ну вот вы берёте в ORDER BY добавляете те столбцы которые используется в WHERE
В 3 и 6 - да. Столбец даты есть в Order BY
Дата должна быть в конце
Ок,а если она единственное поле в order by?
у вас данные за какой период в таблице? вроде 100 мс. duration, куда быстрее? потоки выделяют память на каждую колонку на декомпрессию и на чтение и стримят если нет агрегации, поэтому можно уменьшать кол-во потоков, чтобы использовать меньше памяти
Обсуждают сегодня