WA
а колонок тоже?
11 колонок
Добрый день
Есть одна таблица из 200М записей с движком ReplacingMergeTree
Зависает запросе select * from tabname limit 1, но если добавить любое условие, то отрабатывает.
Кто-то с таким сталкивался? Куда копать?
Size: a a a
2020 July 25
WA
WAS AV
Может кому поможет в будущем, уменьшил кол-во партиций и проблема разрешилась.
WA
В КХ есть ограничения или рекомендации по кол-ву партиций?
AB
/report
D
WAS AV
В КХ есть ограничения или рекомендации по кол-ву партиций?
да, должно быть мало
D
Vladimir Mihailenco
Т.е. сейчас мой вопрос такой - можно как-то ускорить запрос с ORDER BY duration? чтобы работал примерно так же как и ORDER BY project_id
так же не будет, у вас project_id - первый ключ в PK
D
WAS AV
В КХ есть ограничения или рекомендации по кол-ву партиций?
ну и желательно, чтобы все запросы к партиционированным таблицам отсекали по partition-key
D
Vladimir Mihailenco
Еще заметил что оптимизация (MergingSortedTransform?) работает только если ORDER BY first_column_in_key . Если уже сортировать по 2ой колонке в ключе - то опять читает все данные. Так должно быть?
да, так и должно быть
D
Vladimir Mihailenco
Т.е. сейчас мой вопрос такой - можно как-то ускорить запрос с ORDER BY duration? чтобы работал примерно так же как и ORDER BY project_id
у вас фильтрация по project_id особо ничего и не фильтрует... миллион против двух...
попробуйте без оптимизации в prewhere добавить в гист
просто посмотреть на скорость.
+ судя по всему у вас очень широкие строки...
попробуйте без оптимизации в prewhere добавить в гист
set optimize_move_to_prewhere=0
SELECT data FROM uptrace_prod.spans_dist AS s PREWHERE (s.project_id = 2) ORDER BY "duration" desc NULLS LAST LIMIT 10
просто посмотреть на скорость.
+ судя по всему у вас очень широкие строки...
D
Vladimir Mihailenco
Т.е. сейчас мой вопрос такой - можно как-то ускорить запрос с ORDER BY duration? чтобы работал примерно так же как и ORDER BY project_id
select data from uptrace_prod.spans_dist as s where (project_id, type, time) INпопробуйте так, должно помочь (если я правильно понял как оно устроено у вас в данных)
(select project_id, type, time from uptrace_prod.spans_dist where project_id=2 order by duration desc NULLS LAST LIMIT 10)
LIMIT 10;
VM
я уже что-то подобное делаю - https://github.com/ClickHouse/ClickHouse/issues/12757
VM
только вручную 2 запроса пишу
VM
в самом деле помогает - раз в 10 быстрее
VM
во 2ом посте пример запроса
VM
ваш вариант в WHERE IN кстати работает - мой нет
спасибо
спасибо
Y
WAS AV
В КХ есть ограничения или рекомендации по кол-ву партиций?
Партиционирование в идеале должно быть таким, чтобы и при вставке и при выборке количество затронутых партиций было невелико (в идеале 1, но 2-5 тоже жить можно, если у Вас не SSD). Но общее количество партиций в целом может быть любым: например, если Вы хотите хранить логи (да, я как всегда думаю про этот сценарий в первую очередь) за много лет с партиционированием по дням и почти всегда выбирать логи за последние несколько дней, то ничего страшного, что у Вас на диске будут лежать тысячи партиций. В целом, в документации где-то отражено, что партиционирование нужно не для скорости вставки или выборки (обычно партиционирование в ClickHouse замедляет эти операции), а для удобства администрирования и переноса или удаления данных.
D
Партиционирование в идеале должно быть таким, чтобы и при вставке и при выборке количество затронутых партиций было невелико (в идеале 1, но 2-5 тоже жить можно, если у Вас не SSD). Но общее количество партиций в целом может быть любым: например, если Вы хотите хранить логи (да, я как всегда думаю про этот сценарий в первую очередь) за много лет с партиционированием по дням и почти всегда выбирать логи за последние несколько дней, то ничего страшного, что у Вас на диске будут лежать тысячи партиций. В целом, в документации где-то отражено, что партиционирование нужно не для скорости вставки или выборки (обычно партиционирование в ClickHouse замедляет эти операции), а для удобства администрирования и переноса или удаления данных.
Достаточно страшно будет при рестарте... Ждем минуты две )
Y
Достаточно страшно будет при рестарте... Ждем минуты две )
Не так страшен рестарт ClickHouse, как рестарт всего сервера :) (особенно неплановый)
D
Vladimir Mihailenco
ваш вариант в WHERE IN кстати работает - мой нет
спасибо
спасибо
Это рекомендованный вариант подобной оптимизации в КХ. Непонятно, что вы ожидаете в своем тикете - чтобы он магически трансформировал запрос? Кх не сможет сам догадаться плюс гарантий нет
D
Не так страшен рестарт ClickHouse, как рестарт всего сервера :) (особенно неплановый)
Не так страшен рестарт сервера как рестарт кластера