11238
Обсуждаем ClickHouse
EXLAIN
сравните для разных версий clickhouse-server
и ProfileEvents в mege('system', '^query_log') если старые логи не удалили после апргрейда
https://azat.sh/presentations/2022-know-your-clickhouse/#/21
и SETTINGS allow_experimental_analyzer=0 в конец добавьте к оригинальному запросу
Вставка идет в один поток? В сколько партиций? Что делает вставляльщик если получает ошибку?
Ну и вобще это очень мутная и хрупкая штука получается. Нет транзакций - будут потери или дубликаты.
есть смысл если их 30, если их 3 или 2 то нету смысла
Читать полностью…
Да, мерджи мы уже отключили на s3 диске, мы это активно мониторим на всякий случай
Читать полностью…
То есть нет смысла мерджить до талого парты до отправки в s3 диск?
Читать полностью…
если парты десятки гигабайт, то нет...
Читать полностью…
сильно большие парты тоже плохо... 30-50Gb вполне достаточный размер...
с таким размером просто легче живется... файл в 100 гигов все таки дольше обрабатывать всегда имеются ввиду какие нибудь админские задачи... а не SELECT
парты могут по итогу сильно большими получиться... и мержи могут память отожрать
Читать полностью…
"Наличие двух consumer groups означает, что каждая группа читает топик независимо, и при этом каждая группа получает все данные топика. " - почему у меня не так?
Читать полностью…
это не очень много на самом деле. 60К строк в час это 1000 в минуту всего.
Читать полностью…
Такая же примерно ерунда была, это вручную не лечится. По идеологии клика это нормально, если беспокоит - отключить заливку можно на те ноды где больше и оно дольется постепенно на новые.
Читать полностью…
всем привет.
может кто подскажет. есть кластер кафка (kafka_2.13-3.9.1) из 3-х нод сконфигурированный через KRaft. есть продюсер в виде скрипта, который читает json файлы и отправляет в топик кафки.
есть 2 консьюмера в виде кластеров clickhouse.
проблема в том, что таблица на одном кластере имеет больше записей чем во втором.
ACKS=all на продюсере. для каждого консьюмера есть своя consume_group.
для ясности обзову кластера clickhouse 1 и 2. кластер 1 был настроен давно и у него в таблице почти 50млн строк имеется. кластер 2 посвежей и соответственно имеет меньше записей в таблице. и 1
кластер писал больше строк, чем кластер 2. сверял по ежечасной группировке.
в топике 50 партиций.
вроде не ставил отдельных фильтров для чтения из топика.
часть таблицы консьюмера: ENGINE = Kafka
SETTINGS kafka_broker_list = 'kafka1:9092,
kafka2:9092,
kafka3:9092',
kafka_topic_list = 'slowrequeststopic',
kafka_group_name = 'clickhouse_slow_requests_group',
kafka_format = 'JSONEachRow',
kafka_num_consumers = 2,
kafka_max_block_size = 65536,
kafka_skip_broken_messages = 100,
kafka_commit_every_batch = 1,
kafka_thread_per_consumer = 1;
пробовал играться с consume_group изначально на обоих кластерах clickhouse были одинаковые. после некоторых манипуляций (все точно не вспомню) кластер 2 сейчас пишет больше, чем кластер 1.
помогите разобраться.
А их же нельзя на уровне таблицы, только в конфиге <kafka>. Только с растартом, получается
Читать полностью…
если на уровне таблицы это делать
то по идее надо
https://clickhouse.com/docs/integrations/kafka/kafka-table-engine#modify-kafka-engine-settings
если менять <kafka> или через <named_collections> настройки задавать для librdkafka то оно без рестарта сервера должно по идее подгрузиться после DETACH TABLE / ATTACH TABLE у которой engine=Kafka
Вставка в один поток, одна партиция, приложение запомнит получается только то, что оно записало в таблицу-приемник.
По поводу мутной и хрупкой штуки согласен, хочется разобраться и сделать хорошо)
Добрый день.
Постигаем дзен Clickhouse и столкнулись с неожиданным поведением, наступает отчаяние, нужна помощь экспертов)
Есть таблица-приёмник на MergeTree и таблица-справочник на VersionedCollapsingMergeTree.
На таблицу-приёмник для записи в таблицу-справочник создано 2 инкрементальных MV, одно создаёт строки с sign=-1 на основании версии, записанной в БД, другое строки с sign = 1 на основании прилетевшего сообщения.
В большинстве случаев всё обрабатывается корректно, однако, есть около 1-2 % случаев, когда MV на генерацию строк с sign=-1 как будто не выполняется, что приводит к тому, что в БД оказывается 2 строки с sign=1 с разными версиями, но без строк удаления.
Стоит отметить также, что у нас стоит параметр min_age_to_force_merge_seconds=60. Было подозрение, что есть корреляция с частыми слияниями, когда вставка и слияние накладываются друг на друга, но прямых доказательств не выявлено.
Подскажите, пожалуйста, возможно есть какой-то опыт в возникновении подобных ситуаций?
Всем привет
У меня запрос с array join и с cte шками на 24 версии выполнялся секунды а на 25 отлетает по памяти или если отпимизировать то 4 минуты
И с чем это может быть связано?
ну вы проверьте какие у вас сейчас размеры партов которые по TTL MOVE TO DISK попадают через system.parts
если там 30 гигабайт и более то нет...
мы обычно вообще ставим prefer_not_to_merge для s3 volume в storage_configuration
чтобы лишний раз данные из s3 в память сервера при мержах не гонять...
там запросы с range заголовком делаются после того как PK в памяти уже...
Читать полностью…
Я просто переживаю, что при обращении к партам в s3 диске может быть больше запросов, если несколько партов будет. Хотя есть ощущение, что оно никак не повлияет
Читать полностью…
Ну да, мы эти риски принимаем, сейчас хотим протестировать, до какого размера парта нам будет комфортно мерджить старые данные, чтоб их потом в s3 отправить уже одним партом
Читать полностью…
всем привет
есть вопрос касательно 3 настроек MergeTree
хочу выставить для таблицы вот такой набор настроек
max_bytes_to_merge_at_max_space_in_pool=483183820800,
min_age_to_force_merge_on_partition_only=1,
min_age_to_force_merge_seconds=5184000
max_bytes_to_merge_at_max_space_in_pool выставил больше максимального размера партиции (просуммировал размеры партов).min_age_to_force_merge_seconds?
Читать полностью…
понимаю. слышал о больших объемах записи. отчасти видя малый объем данных и метрики серверов уверен, что это проблема в кафке.
Читать полностью…
данные постоянно льются. в пике с этого топика было около 700000 за 1 час. обычно в диапазоне 20-60 тысяч строк.
плюс по consume_group на кластере 1 есть лаг. до этого был на кластере 2.
наличие двух consumer groups и четного количества партиций в Kafka topic не гарантирует равномерное распределение чтения данных полностью само по себе
https://www.perplexity.ai/search/garantiruet-li-nalichie-dvukh-0FCiHgdiRJq42Xra_dGYRA#0
attach / detach тоже можно пробовать
Читать полностью…
Снимаю вопрос, ответ нашёл тут:
https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-server-config-files/
Подскажите, при изменении этих параметров нужен рестарт клика (для консумера Kafka)?max.poll.interval.mssession_timeout_ms
вероятно кто-то постоянно создает мелкие парты, либо сеть совсем плохая
смотрите part_log
select toStartOfTenMinutes(event_time) t, database, table, count() c, round(avg(rows))
from system.part_log
where event_date >= today()
and event_type = 'NewPart'
and event_time > now() - 3600
group by database, table, t
order by t
limit 1000