8S
В PROCESSLIST висит
| 24 | reader | adm-test-ch1.partner.ru:41276 | test | Sleep | 14337 | | NULL
| 24 | reader | adm-test-ch1.partner.ru:41276 | test | Sleep | 14337 | | NULL
Size: a a a
2021 February 05
T
Всем привет, подскажите пожалуйста за что отвечает ОСный процесс clickhouse-watchdog рядом с /usr/bin/clickhouse-server?
SB
Всем привет. Делал тут инсерт 10к записей раз пару секунд и словил такую ошибку
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
AK
Всем привет. Делал тут инсерт 10к записей раз пару секунд и словил такую ошибку
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
Ошибка про то, что ваш инсерт вставляет во много партиции разом, а не про много записей в одну
SB
Ошибка про то, что ваш инсерт вставляет во много партиции разом, а не про много записей в одну
а, хм. Тость наоборот там разные даты?
AK
а, хм. Тость наоборот там разные даты?
Да
M
Всем привет. Делал тут инсерт 10к записей раз пару секунд и словил такую ошибку
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
"Too many partitions for single INSERT block". Партиция у меня на дату по дням стоит и очевидно что в пачке из 10к будет куча одинаковых дат, так как пишу события по дням.
Нормально ли будет увеличить max_partitions_per_insert_block до 10к или это как-то скажется на скорости/ресурсах и так вообще неользя делать?
Скорость инсерта снизится, тк ваш батч затрагиваетт слишком много партиций -> больше файлов. Так же в будущем будут замедлятся селекты, которые имеют(в вашем примере) выборку больше дня, тк читать много файликов приходится. Так же это генерит невероятное количество партов. Сам сталкивался с такой проблемой - пришлоись репартиционировать таблицу.
SB
Скорость инсерта снизится, тк ваш батч затрагиваетт слишком много партиций -> больше файлов. Так же в будущем будут замедлятся селекты, которые имеют(в вашем примере) выборку больше дня, тк читать много файликов приходится. Так же это генерит невероятное количество партов. Сам сталкивался с такой проблемой - пришлоись репартиционировать таблицу.
А как? По месяцам?
M
А как? По месяцам?
Да, я пришел к выводу что это самое оптимальное значение.
Ну я переодически чатик читаю, многие приходят к такому выводу. Так же туторах для кх тоже советуют использовать именно так.
Конечно же, все депендс от вашей специфики и конкретных кейсов.
Ну я переодически чатик читаю, многие приходят к такому выводу. Так же туторах для кх тоже советуют использовать именно так.
Конечно же, все депендс от вашей специфики и конкретных кейсов.
SB
Да, я пришел к выводу что это самое оптимальное значение.
Ну я переодически чатик читаю, многие приходят к такому выводу. Так же туторах для кх тоже советуют использовать именно так.
Конечно же, все депендс от вашей специфики и конкретных кейсов.
Ну я переодически чатик читаю, многие приходят к такому выводу. Так же туторах для кх тоже советуют использовать именно так.
Конечно же, все депендс от вашей специфики и конкретных кейсов.
А если у меня таблица с примерно 300кк записями, как-то запросом можно определить, каких данных уникальных больше, чтобы например сделать репартицию например по какому-то типу. Например у меня есть тип события, там их всего штук 5 на все записи, а месцов очевидно больше и каждый раз будет больше. Имеет такое смысл? Или так же надо смотреть систему, какие вообще запросы и какие фильтры используются?
SC
А если у меня таблица с примерно 300кк записями, как-то запросом можно определить, каких данных уникальных больше, чтобы например сделать репартицию например по какому-то типу. Например у меня есть тип события, там их всего штук 5 на все записи, а месцов очевидно больше и каждый раз будет больше. Имеет такое смысл? Или так же надо смотреть систему, какие вообще запросы и какие фильтры используются?
count() и group by. Можно ещё uniq()
M
А если у меня таблица с примерно 300кк записями, как-то запросом можно определить, каких данных уникальных больше, чтобы например сделать репартицию например по какому-то типу. Например у меня есть тип события, там их всего штук 5 на все записи, а месцов очевидно больше и каждый раз будет больше. Имеет такое смысл? Или так же надо смотреть систему, какие вообще запросы и какие фильтры используются?
Посчитайте количество уникальных значений, что бы найти коррелирующее значение, которое будет оптимально балансировать паратиции в рамках вашей специфики.
SB
count() и group by. Можно ещё uniq()
Да, точно. Но у меня например в системе поумолчанию фильтр по датам стоит с большим промежутком, однако фильтр на тип стоит всегда поумолчанию 1. Тоесть мы можем смотреть данные одного типа по разным датам. Однако можно поставить фильтр на дргой тип и надо будет делать join. Мб имеет смысл репартицию сделать на тип все же?
SC
Да, точно. Но у меня например в системе поумолчанию фильтр по датам стоит с большим промежутком, однако фильтр на тип стоит всегда поумолчанию 1. Тоесть мы можем смотреть данные одного типа по разным датам. Однако можно поставить фильтр на дргой тип и надо будет делать join. Мб имеет смысл репартицию сделать на тип все же?
Партиции больше для удобства, так что оставьте по дате. А в индекс на первое место поставьте тип.
M
Да, точно. Но у меня например в системе поумолчанию фильтр по датам стоит с большим промежутком, однако фильтр на тип стоит всегда поумолчанию 1. Тоесть мы можем смотреть данные одного типа по разным датам. Однако можно поставить фильтр на дргой тип и надо будет делать join. Мб имеет смысл репартицию сделать на тип все же?
Так сделайте партиции по месяцу и в ключ оред бай поставьте колонку в начало с наибольшей кардинальностью - тип, в вашем примере.
SB
Понял, спасибо. А как делать репартицию?
SC
Понял, спасибо. А как делать репартицию?
Только перевставлять данные
M
Понял, спасибо. А как делать репартицию?
Создайте новоую таблицу и сделайте insert select
Потом можете посмотреть количество партов на примере двух этих таблиц и увидите колоссальную разницу
Потом можете посмотреть количество партов на примере двух этих таблиц и увидите колоссальную разницу
SB
Понял, хорошая идея, спасибо!
S
В PROCESSLIST висит
| 24 | reader | adm-test-ch1.partner.ru:41276 | test | Sleep | 14337 | | NULL
| 24 | reader | adm-test-ch1.partner.ru:41276 | test | Sleep | 14337 | | NULL
ну тогда видимо автору китайцу пишите issue на github