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

Спасибо! 🙂

КХ изначально родился с партициями по месяцам, соответственно 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).

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

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

Это уже ближе к ответу, спасибо

Подскажите, если я храню данные за последние 60 дней, PARTITION BY toYYYYMM(date) для меня будет не очень оптимальным, я прав, ведь всего будет две партиции? Вопрос таков: можно ли сделать toDayOfYear(date)? Будет ли ClickHouse понимать нужные партиции при выборке ... WHERE date > '2020-07-15? И если такой ключ для партиционирования не очень оптимален, то какой лучше взять?

можно сделать просто PARTITION BY date
на самом деле там чуть хитрее и кликхаус хранит минимальные и максимальные значения столбца учавствующего в ключе партицирования, так что все будет ок

Спасибо. У меня вообще несколько вопросов накопилось. Правильно ли я понимаю, что если ключ партиционирования по дате, то в ORDER BY первым значением эту дату тоже полезно положить, особенно если в выборках эта дата почти всегда фигурирует? Правильно ли я понимаю исходя из этой иллюстрации, что порядок внутри ORDER BY имеет значение, верно? Где можно почитать про правильный выбор полей, которые нужно ложить в ORDER BY?

Допустим запрос WHERE date > '2020-07-05' AND user_id = 100, при PARTITION BY date ORDER BY (date, user_id) будет выполнятся максимально эффективно. А что делать с таким запросом: WHERE date > '2020-07-05' AND event_id = 200?

> Правильно ли я понимаю, что если ключ партиционирования по дате, то в ORDER BY первым значением эту дату тоже полезно положить,
если у вас партиционирование по дате, класть ее в ORDER BY нет никакого смысла.
> порядок внутри ORDER BY имеет значение, верно?
Да.
> Где можно почитать про правильный выбор полей, которые нужно ложить в ORDER BY?
Основное правило в начало идут низко кардинальные поля, по которым часто идет фильтрация

> если у вас партиционирование по дате, класть ее в ORDER BY нет никакого смысла.__
Подскажите, почему? Смотрю сейчас тестовые данные в туториале, там именно так и сделано