а, я подумал сразу про второй кейс :))

В целом, мы обычно не рекомендуем использовать buffer таблицу, тк у нее есть свои неприятные моменты, на стороне приложения/кафка обычно гораздо лучше работает

Привет.
Предположим, есть таблица, партицированная по месяцам.
Она раскидана по 2м шардам(серверам) с одной репликой.
Есть ли способ добавить третий шард(сервер) так, чтоб новый месяц распределялся уже по 3м шардам, а предыдущие и текуший месяцы остались на 2х?

Я почитал доку, погуглил, посмотрел доклады, но не нашел упоминания об этом.

у вас так и получится - данные сами на новый шард не переедут, кх не размазывает их сам по всем доступным шардам

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

о, круто!
а это где-то описано?

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

тут речь про "Куски" или "Партиции"?
Т.е. даже если таблица не партицированна, то данные будут писаться в том числе и на новый шард?
И если обращаься к старым данным, то запрос пойдет в 3 сервера, просто один ничего не вернет, так?

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

Всем привет!
Подскажите плз, что можно попробовать сделать

Есть такой запрос

Select count() from table
prewhere (code, dt ) in ( select code, max(dt) from table group by code )

Работает за 400мс

В самой табле 23м
Выборка 119к

Сортировка по code, dt
Гранулярность 8192

Что тут сделано не так и как можно ускорить ?

Так вам достаточно просто сделать

SELECT count() from table group by code

code и dt
в ORDER BY стоят?

а вообще какой смысл запроса то вообще? что хотите получить?
кол-во уникальный code?
зачем max(dt) нужен?

Каунт вставлен для примера
На самом деле наверху куча логики
Но вот узкое место в преуере

select uniqExact(code) from table

так проблема у вас не в этом запросе…

ну PREWHERE просто говорит что "данный part можно скипнуть и не фильтровать по другим полям"

Просто не совсем понимаю почему так долго делает выборку
С учетом что сортировка по этим полям и гранулярность вроде адекватная

ну смотрите EXPLAIN
смотрите сколько партов читается ... и сколько данных с диска читается

стройте по system.trace_log  flamegraph запроса
будет больше конкретики

> тут речь про "Куски" или "Партиции"?
куски

> Т.е. даже если таблица не партицированна, то данные будут писаться в том числе и на новый шард?
да

> И если обращаься к старым данным, то запрос пойдет в 3 сервера, просто один ничего не вернет, так?
да (был ФР для пропуска шардов где нет данных, но это для перфоманса/эффективности)

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