Всем привет! Подскажите, пожалуйста, производительность Clickhouse напрямую зависит от количества партиций в таблице, если я правильно понимаю? Например, при слишком большом количестве для отдельных таблиц сервер запускается медленнее, стал замечать. Какое оптимальное количество партиций для таблицы? Тут просто компромисс между быстротой/оптимальностью поисков и производительностью Clickhouse... с одной стороны в ключе партиционирования я указал поля, которые чаще всего будут использоваться при фильтрации (where/prewhere), чтобы сократить объём данных, который Clickhouse будет прочесывать при запросах, но с другой стороны получается большое число партиций..

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

Точно, для фильтрации ORDER BY (я также указал как и для партиций). А вот ключ партиционирования нужно выбрать с точки зрения удобства манипуляции отдельными партициями (drop, freeze и так далее?)..  на что ещё нужно обращать внимание при выборе ключа партицилнирования? Понимаю, что вопрос очень базовый, но я начинаю путаться, поэтому прошу помощи :)

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

партиционируют обычно по дате, если данные постоянно вставляются

Понял, сталкивался с проблемой при инсертах, поэтому задумываюсь о пересмотре ключа партиционирования для таблицы. Также есть подозрение, что сервер долго стартует из-за большого числа партиций в отдельных таблицах (много времени наверно тратится, чтобы приаттачить всё)

С датой понятно, а в каких случаях добавлять в ключ дополнительные колонки?

имхо оно больше для удобства управлением. лучше всего чтоб один инсерт делил данные на наименьшее число партиций

Спасибо! 🙂

КХ изначально родился с партициями по месяцам, соответственно 12 партиций в год, и партов будет ну максимум 120. Предположим храним данные 5 лет, получится 720 партов, < 1000 как написано в доке. Если партов будет 5000-10000 начинаются проблемы, не работают альтеры, мутации,  медленный старт.

Спасибо! Числа подкрепляют тот факт, что у меня неправильный подход в определении таблицы)

но все зависит от ваших условий, я например не следую этому правилу, и партиционирую и по дням и по месяцу+тенант (100 тенантов, 100 партиций в месяц, и даже по часу, но я отлично разбираюсь, и например знаю что блоки в зукипере остаются навсегда и надо чистить руками в зукипере после дропа партиций, если у меня часовые партиции и я храню их 3 дня.

select uid, arrayFilter( x-> x.1 < arr.1[indexOf(arr.2, 'Y)] , (arraySort( x -> x.1, groupArray( tuple(ts,event) as arr) )  from 
events
group by uid

Спасибо! Разобрался

всем привет. ЗК refused КХ, все это дело запускаю в контейнерах. С КХ контейнера ping на ЗК есть все ок. Куда можно капнуть

сами ЗК настроины вот так

видимо в том что порт 2181 не прописан в конфиге

Добрый день коллеги! Подскажите может кто знает когда будет следующий после 20.3 релиз с длительной поддержкой LTS?

Long Term Support versions are introduced for big enterprise customers who don't like to update often. LTS version is released twice a year with limited support during one year. Limited support includes backports of bugfixes (only fixes that were easy to backport or that were required by customer).

На мой вопрос все рано нет ответа))

Скорее всего в середину осени думаю.