BB
Только % в начале мешает
Так и было сделано - 2 таблицы для поиска . Но хотят %value% сразу
Size: a a a
2020 July 25
D
Ну т.е делать pk на value и вешать ещё скип индекс ?
Есть заранее известный набор values которые будут встречатья часто?
BB
Есть заранее известный набор values которые будут встречатья часто?
Нет, абсолютный рандом.
E
Существует ли какой-нибудь параметр, который бы делал OPTIMIZE TABLE FINAL только по партициям, где больше одного парта, а там где только один ничего не трогал?
D
Нет, абсолютный рандом.
А какой кардиналити у value ожидается?
D
Нет, абсолютный рандом.
Вернет всегда одну строку? Или сколько угодно
DN
Партиционирование в идеале должно быть таким, чтобы и при вставке и при выборке количество затронутых партиций было невелико (в идеале 1, но 2-5 тоже жить можно, если у Вас не SSD). Но общее количество партиций в целом может быть любым: например, если Вы хотите хранить логи (да, я как всегда думаю про этот сценарий в первую очередь) за много лет с партиционированием по дням и почти всегда выбирать логи за последние несколько дней, то ничего страшного, что у Вас на диске будут лежать тысячи партиций. В целом, в документации где-то отражено, что партиционирование нужно не для скорости вставки или выборки (обычно партиционирование в ClickHouse замедляет эти операции), а для удобства администрирования и переноса или удаления данных.
Но тем не менее это влияет на производительность? Я всегда думал что партиции нужны чтобы отсекать кучу лишнего при селекете
Y
Но тем не менее это влияет на производительность? Я всегда думал что партиции нужны чтобы отсекать кучу лишнего при селекете
В документации как раз об этом говорится: первичный индекс справляется с отсечением нужных данных , партиционирование для этого не требуется
DN
В документации как раз об этом говорится: первичный индекс справляется с отсечением нужных данных , партиционирование для этого не требуется
Данные для разных партиций хранятся отдельно. Это позволяет оптимизировать работу с данными, так как при обработке запросов будет использоваться только необходимое подмножество из всевозможных данных. Например, при получении данных за определенный месяц, ClickHouse будет считывать данные только за этот месяц.
DN
Вот прям из доки копирнул
DN
Я просто думал всегда что партиции нужны чтобы как раз ьаки большие блоки данных отсекать
DN
Хз терь четдумать
D
Я просто думал всегда что партиции нужны чтобы как раз ьаки большие блоки данных отсекать
И то и то верно...
BB
Вернет всегда одну строку? Или сколько угодно
Сколько угодно, но не больше 1000
D
Мы используем и партиции и индексы для отсечения
D
Сколько угодно, но не больше 1000
Тогда, если итого миллиард стро а поиск совпадет с тысячей попробуйте токенбф скип индекс на рандомных данных.
BB
А какой кардиналити у value ожидается?
Сложно сказать, скорее высокая кардинальность . Но очень много повтором, поэтому использую аггрегаиинг мердж три. Обязательно нужно знать время первого появления и последнего .
DC
Хз терь четдумать
Партции позволяют отсечь и ускорить запрос, но это менее приоритетная цель. В первую очередь они для упрвления retention. Если партиции слишком мелкие и их много начинаются проблемы со вставками и вообще с работой кх.
DN
Партции позволяют отсечь и ускорить запрос, но это менее приоритетная цель. В первую очередь они для упрвления retention. Если партиции слишком мелкие и их много начинаются проблемы со вставками и вообще с работой кх.
Спасибо за разъяснение
D
Партции позволяют отсечь и ускорить запрос, но это менее приоритетная цель. В первую очередь они для упрвления retention. Если партиции слишком мелкие и их много начинаются проблемы со вставками и вообще с работой кх.
Еще для ддл, перерасчетов данных, ограничения скоупа мерджа или мутации... Ну и вообще много ддя чего