Внимание вопрос: упёрся в max_bytes_to_merge_at_max_space_in_pool, я вообще только недавно узнал про

Question

Внимание вопрос: упёрся в max_bytes_to_merge_at_max_space_in_pool, я вообще только недавно узнал про

его существование. в общем не мёржатся и я решил поменять схему таблицы пока не сильно поздно. сейчас такая схема:
create table entites
(
t DateTime64(6) DEFAULT now64(6),
entity String,
profile_id UInt64,
...
) Engine = ReplacingMergeTree(t)
ORDER BY (entity, profile_id, uuid);
хочу добавить
PARTITION BY (entity, round(profile_id/1000000))
обычно советуют что-то типа profile_id%10 , но есть ощущение, что через какое-то время опять упрусь в размер парта, а при моём подходе новые партиции будут создаваться на каждый миллион пользователей (сейчас их 10). и в принципе то на то и выходит, только в моей схеме заложен рост.
в общем какие подводные камни могут быть?

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

0

01.09.2021

4 ответов

15 просмотров

Vladimir Goncharov Автор вопроса

Konstantin Ilchenko
а entity много уникальных у вас?

нет. 5 штук

0

01.09.2021

Denny [Altinity]

Слишком мелкое партиционирование приведет к полной жопе намного быстрее

0

01.09.2021

Vladimir Goncharov Автор вопроса

Denny [Altinity]
Слишком мелкое партиционирование приведет к полной...

ну вот, стараюсь, чтобы было не слишком мелкое, но и чтобы в 150гб на партицию уложиться. да и по идее последние пользователи более активны чем предыдущие, значит большинство вставок будет в последнюю партицию. а при остатке от деления практически гарантировано, что будет писать во все 10.

0

01.09.2021

Konstantin Ilchenko · Accepted Answer

Konstantin Ilchenko

а entity много уникальных у вас?

0

01.09.2021

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

Внимание вопрос: упёрся в max_bytes_to_merge_at_max_space_in_pool, я вообще только недавно узнал про

4 ответов

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