в парты или в партишны?
Каких запросов? Точечных - в гранулы, массовых - в диски, фильтрация -- в CPU и так далее
в кол-во доступных IOPS, CPU и RAM оно будет упираться а не в то что вы перечислили partitions это логическая конструкция. физически это min max индекс в каждом парте, который позволяет сделать partition prunning то есть быстро отбросить парты не сканируя если есть WHERE поле_по_которому_сделан_partition_by parts это каталоги внутри которых файлы, главные из которых primari.idx (грузится в памяти) и *.bin (содержимое колонок) *.mrk (разметка колонок на гранулы в соответсвии со значениями primary key) есть такое понятие как адаптивная гранулярность гранулы это кусочки партов, соответсвующие значениям из primary key то есть если у вас плохой запрос который никак не задействует ни partition prunning и не содержит полей из primary key для быстрого сканирования партов и который в итоге читает \ фильтрует на CPU \ группирует и сортирует то упираться будет в то, чего больше чтения с диска, фильтрации на CPU (обычно не упирается) и группировки \ сортировки
имелась в виду единица масштабирования для потоков. Если у меня 1000 потоков, но 10 гранул, 5 партов, 1 партишн, во что упрется?
нет тредпулы конкретно по партам или по гранулам не масштабируются... это точно там по разному для каждого случая ... есть некоторый набор тредпулов специфичных, есть общий тредпул из которого берутся свободные треды... есть настройка max_threads ее можно как в профиле так и в запросе через SETTINGS задать
еще раз уточню, вот у меня 1000 потоков, все доступны, не суть из каких пулов, важно что их явно в избытке. У меня есть только 1 партиция, 5 партов в этом партишне, там 10 гранул суммарно. Вопрос, сколько потоков максимально будет задействовано? предполагаем что даже на короткое время.
такое легче через system.query_thread_log посмотреть https://clickhouse.com/docs/en/operations/system-tables/query_thread_log
Обсуждают сегодня