 
       
                   
               11238
              11238
          
          Обсуждаем ClickHouse
 
                    ок, ломается на выключении query_plan_enable_optimizations
Читать полностью… 
                    логично, offset это сдвиг внутри окна рефреша, его смысл в том чтобы разнести нагрузку на ресурс если таких рефрешей много.
для такого расписания нужен кронтаб (но он в секунды не умеет)
 
                    https://clickhouse.com/docs/sql-reference/statements/create/view#refreshable-materialized-view
хотел настроить refreshable view чтобы срабатывала каждые 10 секунд ежедневно с 12:00 до 00:00
EVERY 10 SECONDS OFFSET 12 HOURS
так не работает, offset ожидается меньше чем every
 
                    там где-то можно посмотреть версию 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 мб это пер колонка, но надо читать описание параметра
Читать полностью… 
                    у меня селект с лимитом, как вариант думаю добавить условие select ... limit if(toHour(now) >= 12, 10000, 0)
будет срабатывать каждые 10 секунд, но данные достанет только после 12:00
 
                    в 25.3.7 последней сломали pruning? :) 
(в моменте ремонта)
 
                    Вроде последний (из их списка). Возможно сама версия шторма еще как то влияет
Читать полностью… 
                    Есть смысл озадачить этим разрабов. Это же их продукт. Тем более, что и, наверняка, еще и купленный
Читать полностью… 
                    Как и все остальные. Джет брейну бы добавить возможность отправлять сырые запросы, было бы здорово. А так в целом вполне удобная адекватная тулза.
Читать полностью… 
                    Джет брейновские Иде (про другие не знаю), существенно запаздывают в поддержке синтаксиса и функций клика
Читать полностью… 
                    Да, интересно. Я сейчас с другой машины сижу, и на ней работает. А на другой было пусто. Возможно разные версии шторма или драйвера.
Читать полностью… 
                    тогда нет решения, да и 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