11016
Обсуждаем ClickHouse
Всем привет
У меня возникла проблема: при записи времени в clickhouse записывается UTC, можно ли как-то сделать , чтобы clickhouse автоматически при select выводил в установленной таймзоне ?
Подскажите пожалуйста, сколько весит LowCardinality(String)?byteSize от строки из 4 символов - 13
Профитно ли для такой короткой строки использовать LowCardinality(String)?
Для другой колонки LowCardinality(String) результат byteSize - 16.
Я правильно понимаю, что LowCardinality занимает 16 байт, и использовать его в таблицах, для колонок, где avg(byteSize(column_name)) < 16, нет смысла?
Дедуп работает внутри партиции. Мержи слияют парты только в партиции. Каждая партиция живёт своей отдельной жизнью. У вас оптимизация которая приводит к неверной логике и неверным результатам
Читать полностью…
https://pastila.nl/?002928f6/fb65885fd5a16188acb2103d15b9d991#vZ7D6Og2K91re/NkqwuCeQ==
Читать полностью…
так а КХ не запускается или что?
там можно киперу сказать rcvr
типа echo rcvr | nc ...
в общем у вас маленькие партиции, скорее всего нет смысла морочится
Читать полностью…
replicated базы поддерживают структуру таблиц, т.е. не нужен on cluster, таблицы сами создаются на всех нодах, алтерятся, etc.
replicated database был какое-то время экспериментальным, но потом его допилили, наверное в clickhouse.cloud он только и используется.
там рассчитано что оно будет создано в replicated database
и видимо надо создавать эту database где все ноды КХ реплики, тогда RVM выполнится только на одной
Привет!
Есть ли у кого-то советы по настройке refreshing MV, который работает с распределёнными таблицами?
Я использую REFRESH EVERY 10 SECOND APPEND TO {distributed_table} SELECT FROM {distributed_source_table} и столкнулся с проблемой: так как MV создаётся на каждой реплике, данные дублируются.
Целевая таблица — это DISTRIBUTED, за которой стоит ReplicatedReplacingMergeTree.
Как правильно настроить, чтобы избежать дублирования при обновлении MV?
https://github.com/ClickHouse/ClickHouse/issues/33056
Читать полностью…
однозначно ответить нельзя
тут надо знать хотя бы в начале или в конце orderby, это совсем разный подход,
причем например в первой попавшейся таблице
PRIMARY KEY (toStartOfHour(timestamp), httpStatusCode)
ORDER BY (toStartOfHour(timestamp), httpStatusCode, dc, physicalServerName, podName, timestamp)
и все это для достижения конкретных, разных целей
А зукипер пересоздавать нужно только для чека что все завелось? Так как в старом продовом CH были какие то апдейты? И нам надо опять сбросить всю мету, поставить прод в RO, досинкать новые данные, поднять ZK и restore replica ?
- в этом случае есть даунтайм, но не такой большой как в 3 варианте)
@den_crane
Спасибо за ответ!
Привет! Мы давно не обновляли свой продовый клик (с 2022го года :) ). Сейчас вынуждены переезжать в другой ДЦ и соответственно хотелось бы апнуться до последней 25 версии.
Версия текущего клика v22.2.2.1
Схема: 2 ноды, без шардирования (простая репликация)
Объем данных: ~ 15+ Tb
Репликатор: zookeeper
Как правильно отреплицировать данные в новый ДЦ?
1) Поднять в новом ДЦ старую версию клика с зукипером, дождаться репликации, апнуть версию с 22 до 25 (это реально итеративно или сразу большим шагом?)
2) Поднять в новом ДЦ сразу новую версию клика и натравить старый зук, понадеяться что проблем с репликацией не возникнет, переключиться с старого ДЦ на новый и возможно мигрироваться с зук на chkeeper (может ли в таком случае как то аффектнуть данные в текущем проде?)
3) Простой INSERT SELECT remote с жирным даунтаймом 😢
4) Пока не придумали
1-2 варианты можно протестировать в дев среде, но пока этого не сделали, может быть есть люди у которых был такой опыт?
Я про дедуп при мержах в первую очередь.
У вас же проблема даже в том что partition pruning работает самым первым и в final уже приходят неверные записи.
Если дедубликация работает внутри партиции, 2 эти записи в разных партициях, то после дедубликации должно 2 записи остаться
Читать полностью…
Это было сделано для оптимизации запросов к таблице wide_order, т.к часто запросы к этой таблице могут содержать фильтрацию по partner_name, при этом partner_name может меняться, поэтому он не содержится в ORDER BY:
https://clickhouse.com/docs/ru/partitions#query-optimization
Разве PARTITION BY влияет на дедубликацию? В поле partner_name различных значений не более 300, в перспективе не более 3 тыс.
забавно, только сейчас я понял
PARTITION BY partner_name
Ну в этом смысле в конечно, КХ не может определить какой инсерт последний. И такое не описано в документации.
Это экстремально необычно.
Теперь конечно вообще непонятно что вы хотели от такой таблицы.
Такое ощущение что PARTITION BY partner_name в таблице по ошибке
именно primary key ?
В кх проблема есть https://github.com/ClickHouse/ClickHouse/issues/33056
надо делать вот так
order by toDate(timestamp), kind, timestamp primary key toDate(timestamp), kind
покажите в следующий раз select *, _part from wide_order
т.е. иначе непонятно как вы узнаете какой инсерт был последним
https://pastila.nl/?01b5c534/faa110d40ba6fb90aa61a26d4a3fcf6c#VS+8pI2Eiq58o9cqzV6knQ==
Читать полностью…
Спасибо! Не знал что бывает Replicated движок для баз данных, думал только для таблиц
Читать полностью…
Так у вас реплейсинг, он и уберет. Однажды
Читать полностью…
Окей! в проблема описаная в issue конечно всё смешалось, кони и люди, но натолкнуло меня на мысли, спасибо!
Читать полностью…
а если это не NDA для какой цели описание как у вас?
Читать полностью…
Всем привет!
А подскажите пожалуйста есть смысл делать в order_bytoStartOfTheDay(created_at) или можно без прелюдий в виде toStartOfTheDay?
снова restore replica
таким образом можно добится даунтайм в пару секунд.
т.е. rsync делайте наживую
надо тестить на стейдже вашу приладу, возможно вообще не будет работать, или будет работать медленее.
2 не надо, 25я версия переделает все в зукипере и старый кластер встанет.
4. инкрементальный rsync файлов в новый кластер, несколько запусков, чтобы досинкать изменения, новый кластер смотрит в новый зукипер (кипер), поднимаем 25й кх, system restore replica, тестируем приложение, если все ОК, пересоздаем зукипер, останавливаем КХ, снова инкрементальный rsync изменений ...
примеры как делать rsync ищите в чате, там важны ключи, типа удаляй в приемнике файлы которых уже нет в источнике