11238
Обсуждаем ClickHouse
Ну да, такое сработает если на одном сервере все парты помержились и больше не планируют, и надо это на реплики разлить. Считай то же, что и с нуля реплику налить... Тогда остановлюсь на полной переналивке "слабой" реплики. Спасибо за ответ ночью
Читать полностью…
Они и так помержены. При аттаче партов должны мержиться парты из non-replicated с партами в replicated же? В этих мержах проблема. Не мержить вовсе - не выйдет, вставки в таблицы продолжаются и рано или поздно лопнут из-за too many parts
Читать полностью…
Привет! Подскажи, а какой способ есть решить проблему из сообщения Сергея, помимо always_fetch_merged_part?
У нас кейс следующий:
- есть 3 replicated инстанса, 2 "сильных" сервера и один "слабый"
- на одном из сильным инстансов мы из non-replicated таблицы аттачим террабайты партов в replicated таблицу
- данные разливаются на реплики и начинают мержиться
И если на двух "сильных" серверах мержи проходят успешно, то на одной "слабой" реплике мержи работают в полку слишком продолжительное время. Хочется перетянуть смерженные парты с соседних реплик.
Мы используем версию 22.3.11, на которой, насколько я понял, нет опции always_fetch_merged_part. Из вариантов решения вижу только наливать "слабую" реплику с нуля, но мб есть менее радикальный способ?
не пока
в итоге я правильно понимаю вашу идею:
чтобы я сделал
max_threads=1 и max_block_size = 50000и дальше поднимать max_threads чтобы понимать сколько ядер можно утилизировать и при этом чтобы не выжирало всю память?
чтобы понять сколько памяти будет есть чтение паркетов на максимуме (memory_usage (system.query_log
)
https://clickhouse.com/docs/interfaces/formats/Parquet
о, щас сюда покопаю, спасибо
я бы подозревал что 16 мб это пер колонка, но надо читать описание параметра
Читать полностью…
щас
т.е. у нас есть паркет , у него есть блок
input_format_parquet_prefer_block_bytes прмерно 16 МБ
у нас есть 8 ядер
т.е. каждый блок развернется в памяти но ок на 160 мб
8* 160 мб = 1.6 гб запишется в кх. откуда там на 30 гб?
сорри если не так считаю
Объем всех паркетов за день =2 ГБ
Дак попробуйте, если поможет, то у вас не хватает памяти, чтобы обрабатывать файлы во все потоки
Читать полностью…
но у нас нет проекций, таблицы system.projection_parts system.projection_parts_columns system.projection пустые
Читать полностью…
так я не против ) я просто понять хочу из-за чего проблема с памятью
Читать полностью…
а что за файлы? а то у паркетов, там свой размер блока, через размер роугрупы
Читать полностью…
вот это то и не понятно )
т.е. он нормально читает с 1 до 20 файла, а на 22 условно падает
я делаю вывод, что где то накапление в памяти чего то идет
причем размер max_block_size роли не играет все равно на 20 падает
нет, в таком случае, остальне ядра будут проставить и будет долго грузиться же.
я размером блока же рулю объем обработки батчей
т.е. идея есть много маленькими порциями
в 1 дне: 25 файлов ( по часам)
сорри, я не понимаю связь
да даже если 8 потоков
у него max_block_size = 1
он же не будет пытаться все паркеты в памяти держать,
он прочитал 8 файликов = по 1 строке вставляет (8 строк)
тогда нет решения, да и always_fetch_merged_part , вот смержился парт в 300ГБ и что теперь фетчить его на другие реплики? сеть 10гбит?
в смысле много раз будет фетчится, и 50ГБ и 100 и 150
мержить пока они в non-replicated ?
уменьшить max_bytes_to_merge_at_max_space_in_pool чтобы вообще не мержилось в replicated
Немного дополняю
Получаю от человека данные с 1с в виде 9 штук xlsx
конвертирую их через python скрипт в 1 csv
загружаю csv в clickhouse cloud
хочу сделать кластер на яндексе (данные берутся для чартов datalens, так что яндекс удобен)
могу я подключить напрямую выгрузку к кластеру яндекса или кликхаус cloud?
Я думаю более перспективно крутить
input_format_parquet_enable_row_group_prefetch │ 1
input_format_parquet_max_block_size │ 65409
input_format_parquet_prefer_block_bytes │ 16744704
Первую выключить, вторую и третью уменьшать
вы кстати не пробовали settings input_format_parquet_use_native_reader_v3=1 ?
Читать полностью…
>Объем всех паркетов за день =2 ГБ
это смешно, в issues у КХ есть специально созданный паркет размером 1МБ чтобы прочитать его надо 400ГБ памяти и в КХ и в spark и в python
calc_time у вас в partition by ?
можете проверить например у mergeTree* таблиц в system.parts колонки min_time и max_time
implicit_projections это проекции созданные в памяти неявно из minmax индексов от partitionby и orderby
читайте как дебажат и воспроизводят иши https://github.com/ClickHouse/ClickHouse/issues?q=is%3Aissue%20state%3Aopen%20optimize_use_implicit_projections
читайте все закрытые и все открытые иши
вы представляете как паркет устроен? что оттуда нельзя прочитать одну строку?
Читать полностью…
Всем привет, столкнулся с проблемой, в КХ заливаются логи командой 'INSERT INTO db.table FORMAT JSONEachRow' в поле c типом String.Проблема: в поле ничего не записывается, вставки пустые, в err.log ошибки отсутствуют, в query.log в эту таблицу по цифрам есть вставка. Может кто-то знает куда копать?
Читать полностью…
input_format_parquet_enable_row_group_prefetch │ 1
input_format_parquet_max_block_size │ 65409
input_format_parquet_prefer_block_bytes │ 16744704
Понял. А чё тогда памяти то не хватает )
Читать полностью…
да, предлагаю. Память у вас улетает, потому что КХ пытается разом проглотить 10005000 файлов
Читать полностью…