это странно, а если перед инсертом сделать set max_block_size=100000; set max_insert_block_size=100000;

это странно, а если перед инсертом сделать set max_block_size=100000; set max_insert_block_size=100000;

это странно, а если перед инсертом сделать set max_block_size=100000; set max_insert_block_size=100000;

попробовать? ?

Само собой, просто интересны бест практис оптимизации

Группировка по хэшу будет быстрее, будет нужно меньше памяти, но могут быть коллизии. Если group by вылетает по памяти значит скорее всего не включена группировка с использованием диска. Про best practices и нехватках памяти при group by есть хорошая презентация Алексея Миловидова.

Вопрос: для populate MV вы делаете group by по тем же колонкам, которые являются PK в вашем AggregatingMergeTree? Если да - то просто не надо делать один огромный group by при populate, а разбить его на несколько insert ... select. Если нет - то скорее всего ваш MV будет заполняться неправильно.

Группировка по хэшу будет быстрее, будет нужно меньше памяти, но могут быть коллизии. Если group by вылетает по памяти значит скорее всего не включена группировка с использованием диска. Про best practices и нехватках памяти при group by есть хорошая презентация Алексея Миловидова.

Точно нельзя ему как-то сказать "не надо мёржить, если прошло меньше xx минут со вставки"?

Другими словами - если решение задачи подразумевает создание десятков тысяч партиций в КХ, то это решение нормально работать не будет. Точка.

Много партиций использовать можно, если по ним по всем не запускать запрос. Например если даже десять тысяч партиций и запрос только по двум, то вполне себе все будет работать. Если запрос будет по всем данным, то вот тут уже будет проблемка.

Поделитесь результатами. У меня аггрегация по хешу от строки в 64 байта не давала ничего, вроде бы

Я несколько раз слышал краем уха, что КХ делает автоматический дедуп и является exactly-once решением на запись, но я не совсем понимаю контекст. Означает ли это что если я послал INSERT с миллионом строк и соединение оборвалось то я могу его еще раз послать, и, если в прошлый раз все уже вставилось, то второй раз ничего не вставится? Могу ли я вставить одну и ту же строку два раза и получить на выходе всего одну строку например в МТ, или как-то сделать чтоб в SummingMT счетчик не инкрементился для дупликатов?

Во-первых это работает только с реплицируемыми таблицами, во-вторых это работает с одинаковыми блоками данных. Например вы делаете два инсерта по 100 одинаковых строк, то будет всего 100 строк, а не 200. А вот если первый раз вы вставили 100, а потом эти же 100 + 1 строку, то будет дубль.

В ReplicatedMergeTree

понял, интересно, то есть проверяется уникальность именно набора всех данных, ну и, наверное, когда я второй раз вставляю те же 100 строк, они должны идти в том же порядке, чтоб скипнулись? Но, правильно я понимаю, что я могу вставлять не в режиме master-master, а даже всегда на первичную реплику, чтоб вторая порция данных скипалась?

master-master репликации кстати нет в ch

Да, данные в дубле должны быть идентичны и в таком же порядке

master-master репликации кстати нет в ch

У КХ и мастеров нет как таковых )

Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу партишнинг по (дата, группа), где группа - это 1000 числовых значений (можно считать, что это client_id mod 1000). Задача в том, чтобы эффективно использовать 1ТБ диск, удаляя слишком большие группы чаще, чем маленькие. То есть если в группе записей на 1МБ, она может жить и год (365 партиций для неё), а если 300ГБ, то, скажем, один или два дня только. Данные поступают из 10-15 источников, почти отсортироваными по группам и времени, но в кажом источнике есть почти все группы. Каждый источник вствляет по 50-100МБ за раз раз в 20-30 секунд. Раз в несколько минут бывают маленькие вставки в несколько мегабайт или даже меньше. Проблема на дефолтном конфиге - Too many parts. Если увеличить max_replicated_merges_in_queue, то всё какое-то время работает, но старые неактивные партиции не успевают удалятся и на файловой системе через какое-то время кончаются inodes. Если взять ФС без inodes, всё равно всё будет плохо ибо новые parts всё равно появляются быстрее, чем удаляются старые (пробовал также разные разные значения *_lifteme). А уж если перезагрузить сервер, кликхаус не запустится примено никогда (Loading parts...). Буферные таблицы не помогают, хотя сильно с ними не экспериментировал. Такое ощущение, что нужно разрешить кликхаусу не мёржить parts как можно дольше - типа делать это только раз в час или около того. Решение, которое сейчас приодит в голову - сделать две таблицы, одну с партицированием только по времени (типа каждый час, без группы), а другую - по дате и группе. Ну, и рукаи брать всё, что из предыдущего часа и раньше, INSERT ... SELECT * FROM partitioned_by_time ORDER BY time, mod_group и предыдущие партиции из такой псевдо-буферной таблицы удалять. Но выглядит как страшный костыль и могу представить слишком много мест, где это может поломаться. Может есть какие-то ещё параметры, которые стоит попробовать подкрутить под этот юзкейс?

Точно нельзя ему как-то сказать "не надо мёржить, если прошло меньше xx минут со вставки"?

Под мастером подразумевается возможность записи в реплику. Т.е. по факту писать можно в любую реплику и данные расползутся, а так да, у них нет никаких элекшенов вроде на мастера и пр.

Вы тут себе в ногу прострелить хотите, попробуйте просто сделать партиции по дате, причем не по дню, а, например, неделе или как дефолт месяцу, и, возможно, просто сжатие все порешает за вас, если очень сильно хочется то и дефолтное lz4 поменяйте на zstd (https://clickhouse.yandex/docs/ru/single/#compression). Если как советовали ниже использовать движок Merge то при наличии "меленьких" и "больших" таблиц под ней будут неэффективно расходоваться ресурсы (по дефолту N потоков на запрос и часть завершиться быстро, а часть будет разгребать ваши "большие" таблицы). Еще сделайте буфер перед вставкой и, возможно, все взлетит и так;)

Можно размеры кусков мин/макс покрутить, но у вас накопиться их много и все встанет колом

master-master репликации кстати нет в ch

Как? Мне при таком раскладе проще периодически вызывать OPTIMIZE ... FINAL, чтобы партиций оставалось порядка 20к (при таком количестве время запуска приемлемое)

Как это нет. Разве клик хаус не может работать в мультимастер кластере ?

да, это я ошибся. Однако все равно есть 1 leader который принимает решения когда мержи делать )

Так лидер то не клик хаус, а зукипер. Или я не прав ?

Не понимаю, в чём проблема. Да, всё описанное выше - верно. Да, добавление дисков и масштабирование возможны, как только оно станет оправдываться финансово, пока - нет.

Давайте так. Залейте 1 день данных без партиционирования по клиентам. Посчитайте сколько это заняло места. Если это заняло половину диска (такой вывод можно сделать из того что вы писали выше) то дальше обсуждать нечего, т.к. второй день писать уже некуда без удаления данных в первом.

А ALTER UPDATE существует? в каком состоянии?

Или, например, если я отказываюсь от партицирования по группам, могу ли я всё равно эффективно делать запросы типа WHERE mod_group = X? Или это будет считывание всего в задетых партициях?

И ещё - если я делаю Merge или Distributed (только с локальными партициями, на локальной машине) - будут ли условия в WHERE и PREWHERE в запросах ограничивать количество считываемых данных в подтаблицах?

А где в этом синтаксисе PrimaryKey? https://clickhouse.yandex/docs/en/operations/table_engines/custom_partitioning_key/

У нас задача плюс-минус похожа: метрики летят по стопицот штук в день, через три месяца мы будем их сворачивать, уменьшая у них точность: 60 минутных в одну часовую с суммированием всех цикверок. Я пока не делал этого (три месяца еще есть же! ха!), но смотрю в сторону сбора метрик в таблицу типа NULL, на которую натравлены несколько materialized view: метрики минутные, часовые, дневные, погруппированы в вьюхах по месяцам или как-то так. Чтобы онии и сворачивались автоматически, и можно было легко удалить старые метрики.

Кстати, а большая это проблема перенести данные из одной таблицы в другую? Например, в какой-то момент я захочу изменить двидок таблицы (ПК поменять, например). Понятно, что я создам новую таблицу и буду переносить данные из старой. Но select insert делать на миллионах записей не круто же. Вроде бы я видел гдето в доках, что КХ может "натрввить" таблицу на уже существующие данные

структура будет совпадать, но измениться, например, движок.

илии прям вообще всё идентичнодолжно быть?

А я правильно понимаю, что если удаляю партицию за определённую дату из таблицы (всё по умолчанию), удалятся только те данные, которые имеют отношение к месяцу удаляемой партиции? И таблица не повредится?

Коллеги, добрый день, опять я со словарями из postgresql :) На тесте обновили версию до 18.10.3 - сервер теперь запускается, но словарь не подгружается с ошибкой https://pastebin.com/2zMAkAyE (т.е. кх игнорируя все параметры хочет локально законнектиться?) isql DSN работает без проблем. в connection_string указан нужный dsn. Куда еще посмотреть?

запости odbc.ini что касаемо ПГ?