при создании таблицы указать другой путь зукипера

если не удалилось

Не понял вопрос :).
Я накатил миграции, где из-за неправильно конфигурации Кафки сервер упал и не может стартануть. Для этого пришлось чистить директории. Но насколько я понимаю, для distributed таблиц в зукипере созданы пути, которые читсить очень неудобно. Вопрос мой сейчас в том что если не менять пути в зукипере - даст ли КХ пересоздать эти же самые таблицы после старта сервера. Потому что их пути основаны на названии базы и таблиц вроде как. А названия хочется оставить теми же самыми

distirbuted таблицы не используют ZK
вы с ReplicatedMergeTree не попутали?

попутал, да)

Привет.

Меня зовут Денис и я работаю в ООО Топвизор. Публикую здесь это объявление с разрешения администратора этого чата. Нам необходим функционал, которого сейчас нет в ClickHouse. К сожалению, кастомная разработка требует саппорта уровня Essential. Вход туда стоит 22 000 000 миллиона рублей в год. Думаю, что разработка может стоить намного порядков дешевле. Уверен, функционал будет полезен не только нам, но и сообществу.



Итак, мы используем ClickHouse и нам не хватает такого функционала:



В MySQL есть понятия UDF - пользовательские функции, написанные на Си
Разыскивается специалист, который сможет добавить такие функции в CH.

Необходимо разработать программу, которая при запуске смотрит в папку и подключает необходимые классы. А в самой программе будет подобный код:

callUDF('filename', 'args')

==

Мы не знаем точно, сколько может стоить такая работа. По поводу сроков выполнения тоже нет определенного понимания. Если вы готовы взяться за эту работу, пожалуйста, напишите мне в личку или на почту den@topvisor.com для обсуждения сроков и стоимости работы.

Спасибо.

если у вас есть в ZK path Такая штука как {uuid} то это будут новые пути при создании новой таблицы ReplicatedMergeTree с тем же именем

Нет такого, я бы не спрашивал будь пути с некой генерацией имени)

попробуйте с китайцем пообщаться из этой презентации?
https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/udf.pptx

тогда страдать

Добрый день.
Есть смысл использования индекса minmax по дате?
Или все и так по ключу партиционирования хорошо выбирает?
Или вариант просто пробовать и проверять?

Попробую, спасибо

партицирование это еще один min_max индекс но гораздо БОЛЬШИХ диапозонов
по нему ищется в первую очередь если ваше поле есть в PARTITION BY
только выражение PARTITION BY должно по типу совпадать с полем таблицы...
то есть toYYYYMM это на самом деле Integer а не дата
и искать по дате тогда тоже надо через WHERE toYYYYMM() чтобы партиции быстро отсекать

а вот toStartOfDate это дата и тогда поиск по date BETWEEN .. AND будет по партициям сначала использоваться без конвертации

=) если ваша дата есть в ORDER BY
или PRIMARY KEY
и
то это итак фактически и есть min_max индекс и по нему собственно говоря и ищутся нужные куски данных

понял, спасибо
да, дата есть ключе сортировки

тогда CREATE INDEX не нужен

спасибо)

По поводу второго это относится только ко вставкам из buffer, правильно? Или при вставке из того же rabbitmq ожидать такого же поведения?

rabbitmq по другому работает.

buffer пересортировывает инсерты которые вы повторяете с клиента, а повторяете по причине timeout / сетевой проблемы.

rabbitmq engine выбирает из очереди, собирает блок, и делает инсерты сам, и повторяет сам внутри до успеха.

а он при этом ack посылает в очередь что обработал ДО INSERT или после?
и где он блок хранит? на диске?

Если я правильно понимаю, мне достаточно добавить к buffer таблице  уникальное поле например с uuid чтобы такого не случилось, а в репликатед таблице это поле не обязательно должно быть