точно НЕ второй вариант - аттачил на одной реплике только.
inactive партции когда-нибудь исчезнут?

в detached ничего само не исчезает. Вы взяли парты с одного шарда? Или с нескольких?
у вас номера блоков пересекались?

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

у меня один инстанс вообще был. на него всё писалось. после этого появилось две новые машинки, на них создал replicated таблицы. на той где были данные сделал по инструкции на сайте - переименовал обычную, создал репликейтед и данные из обычной в реплицируемую скопировал на файлухе в detached директорию. дальше тем скриптом из github issue прошёлся чтобы приаттачить

видимо это были inactive парты в старой MT

если все данные на месте, то просто удалите все из detached

будут вопросы, пишите =)
кстати пошарьте свой опыт потом, получилось или нет, это тоже очень интересно

ок, спасибо!

Да у меня больше дум, как это в CI обернуть, и как автоскейл красиво сделать

https://github.com/ClickHouse/ClickHouse/issues/18137

read_backoff_min_latency_ms=0

нет, вторичных индексов нету, не верьте

нету, никак не проверить БЫСТРО что запись уже существует.

в CI/CD это так примерно заворачивается
берете токен от вашего кубернетес кластера + endpoint от apiserver
и кладете в ~/.kubeconfig
делаете переменную KUBECONFIG=~/.kubeconfig
и в CI/CD где то вызываете kubectl apply

автоскейл чего? автоскейл kubernetes или автоскейл clickhouse в кубернетес?
автоскейла в кликхаусе нет, но можно мониторинг прикрутить + podAntiAffinity чтобы по одному поду внутри StatefulSet на ноду и прикрутить к этому autoscaling node groups для того провайдера Kubernetes который это поддерживает

у вас какой k8s? облачный? bare-metal?

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

Понятно, спасибо

ну вы попробуйте вставить в какой нибудь Postgres миллиард UUID записей с UNIQE index ;)
вместе поплачем над тем что надо до 9 чтений рандомных на каждую запись сделать

да, сразу не разобрался и полез в чат)
спасибо большое

то есть задача проверки "уникальности" для большого набора "произвольных данных", она сама по себе не тривиальна
и в OLTP базах более или менее решена только для случаев монотонно возрастающих числовых значений размерностью до UInt64 ;)

в OLTP базах в btree индексе random io небольшой из-за того что там логарифм получается с большим основанием, поэтому для млрд. будет 6 рандом чтений, а для 100млрд. будет 7. Даже если не монотонно возрастает. В КХ индекс не btree и еще и разреженный.
И еще внезапно КХ читает все марки в парте, поэтому надо проверить 1 строку, а КХ может 10ГБ одних марков вычитать с диска и еще в памяти это 10ГБ надо разложить.

Запрос выполняется по PK , выполняется около секунды, при этом с диска ничего не читает.

https://gist.github.com/den-crane/1f3143176c4333530ab6f73c3518adcb

секунда уходит на чтение из кеша линукса 6ГБ марков и раскладывание их в кеш.