Доброе утро 1. У меня есть таблица где очень много записей

Question

Доброе утро 1. У меня есть таблица где очень много записей

(статистика товара за каждый день)
2. Клиент выбирает произвольный период дат (от и до) и за весь период некоторые поля суммируются некоторые берутся среднее

Проблема:
Сейчас из за количества записей запрос выполняется слишком долго

Вопрос:
Как ускорить?

#backend #clickhouse #database #devops #programming #russian

0

13.12.2021

15 ответов

29 просмотров

Doniyor Valizhanov Автор вопроса

пример запроса

0

13.12.2021

Doniyor Valizhanov Автор вопроса

Roman Y
А ключ сортировки дату содержит?

да

0

13.12.2021

Boris

очень экстремально делать партиционирование по дням. Если вы храните 50 дней - это нормально, если год - нет. Что показывает select count() from system.parts where table = '...' and active? Возможно торможение именно тут. Если отсечка данных в ваших запросах преимущественно по дате, то её и ставьте на первое место, иначе индекс не работает - идет полное сканирование. Если вам помимо указанных аналитических запросов иногда надо делать выборки по product_id - добавляйте projection с order_by product_id. Или наоборот - оставьте основую как есть, но добавьте projection order by date. Но для начала решите вопрос с партиционированием. Партов не должно быть больше 1000

0

13.12.2021

Doniyor Valizhanov Автор вопроса

Boris
очень экстремально делать партиционирование по дня...

992 партиции уже оказывается

0

13.12.2021

Konstantin Ilchenko

Boris
очень экстремально делать партиционирование по дня...

Почему 1000 партов а не 5000 например?

0

13.12.2021

Boris

Konstantin Ilchenko
Почему 1000 партов а не 5000 например?

примерно. по мне и 1000 - уже много. Это же подкаталоги на одном уровне - файловая система уже притормаживать будет.

0

13.12.2021

Dmitry [Altinity] Titov

Boris
примерно. по мне и 1000 - уже много. Это же подка...

Ну, ext4 нормально жует такие кол-ва. В целом тысячи +-ок.

0

13.12.2021

Konstantin Sevastianov

Konstantin Ilchenko
Почему 1000 партов а не 5000 например?

потому что в доке так рекомендуется =) A merge only works for data parts that have the same value for the partitioning expression. This means you shouldn’t make overly granular partitions (more than about a thousand partitions). Otherwise, the SELECT query performs poorly because of an unreasonably large number of files in the file system and open file descriptors.

0

13.12.2021

Konstantin Ilchenko

Boris
примерно. по мне и 1000 - уже много. Это же подка...

сейчас 4000 дневных партов, тестим сейчас по сравнению с месячными, скорость плюс минус одниковая, только сжатие лучше на месячных

0

13.12.2021

Slach [altinity]

Doniyor Valizhanov

да

сколько записей в каждом дне? если меньше десяти миллионов, то лучше сделать toYYYYMM(date)

0

13.12.2021

Doniyor Valizhanov Автор вопроса

Slach [altinity]
сколько записей в каждом дне? если меньше десяти м...

Около 20-30 миллионов

0

13.12.2021

Slach [altinity]

Doniyor Valizhanov
Около 20-30 миллионов

ну не мало в целом, но и не так чтобы много, можно по неделям партицировать сколько ядер на машине?

0

13.12.2021

Slach [altinity]

Doniyor Valizhanov
Около 20-30 миллионов

SELECT uniq(product_id)/count() FROM table WHERE ... ? сколько уникальных продуктов ? возможно тормоза потому что уж очень большая группировка получается

0

13.12.2021

Denny [Altinity]

Boris
примерно. по мне и 1000 - уже много. Это же подка...

@unamedrus причина не файловой системе. Файловая система не создает оверхеда вообще. чтение 10000 файлов это 10000 seek. Представим себе что у нас нет фс. Но мы знаем откуда на диске надо читать, а надо читать из 10000 мест, это 10000 seek. А затем нам надо слить результаты из 10к стримов в 1.

0

14.12.2021

Roman Y · Accepted Answer

Roman Y

Doniyor Valizhanov

пример запроса

А ключ сортировки дату содержит?

0

13.12.2021

184 похожих чатов

Доброе утро 1. У меня есть таблица где очень много записей

15 ответов

Похожие вопросы