11238
Обсуждаем ClickHouse
Вроде последний (из их списка). Возможно сама версия шторма еще как то влияет
Читать полностью…
Есть смысл озадачить этим разрабов. Это же их продукт. Тем более, что и, наверняка, еще и купленный
Читать полностью…
Как и все остальные. Джет брейну бы добавить возможность отправлять сырые запросы, было бы здорово. А так в целом вполне удобная адекватная тулза.
Читать полностью…
Джет брейновские Иде (про другие не знаю), существенно запаздывают в поддержке синтаксиса и функций клика
Читать полностью…
Да, интересно. Я сейчас с другой машины сижу, и на ней работает. А на другой было пусто. Возможно разные версии шторма или драйвера.
Читать полностью…
тогда нет решения, да и 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
читайте все закрытые и все открытые иши
вы представляете как паркет устроен? что оттуда нельзя прочитать одну строку?
Читать полностью…
там где-то можно посмотреть версию jdbc драйвера кх
Читать полностью…
А на другой машине не работает.
Не появляется вкладка отображения.
Мастер нейроиллюстрации. Тариф Premium. (2025)
#Графика_дизайн
IT MEGA
здесь работает, здесь не работает. у меня самый свежий goland
Читать полностью…
Ну да, такое сработает если на одном сервере все парты помержились и больше не планируют, и надо это на реплики разлить. Считай то же, что и с нуля реплику налить... Тогда остановлюсь на полной переналивке "слабой" реплики. Спасибо за ответ ночью
Читать полностью…
Они и так помержены. При аттаче партов должны мержиться парты из 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 пустые
Читать полностью…