есть ощущение, что можно переделать запрос

еще разок

table1:
- userId (UUID)
- campaign

table2:
 - userId
 - os
 - code

и надо в такой форме данные получить:

userId : campaign : table2.os : table2.code

user_id уникальны? если нет, группировка, фильтр и джойн

уникальность не гарантирует кликхаус

в table1 не повторяются (гарантия кодом)

в table2 на один userId может быть множество записей

вам в table2 нужны все user_id?

если в правой таблице есть лишние user_id, фильтруем условием выше

в table2 нужны данные по всем userId из table1

есть, да

есть пример как сделать? или где прочитать?

можно добавить костыль в правую таблицу: Where user_id in (select user_id from table1 Where 1...)

скопируйте сюда запрос, будет проще

Всем привет, нужен совет, кто обновлял клихаус просто с краторным разрывом от текущей версии)) Есть база примерно 0.5T, кликхаус 1.1.54336. Обновляться сразу до последней, я боюсь. У меня есть вторая нода там сейчас 19.17.4.11, я перекинул данные просто копированиаем файлов на обновленную ноду, вроде все работает и проблем как таковых нет. Кто-то знает могут ли быть какието проблемы в дальнейшем и стоит ли так вообще перекидывать? Стопать продовскую ноду на долго не вариант

Дмитрий предложил вам ограничить набор из table2 , чтобы он поместился в оперативную память. Это можно сделать множеством способов. Например первый способ : select * from table1 all inner join (select * from table2 where field1 in (select distinct field1 from table1)) as a1 on a1.field1 = table1.field1

И второй способ - на мой взгляд более правильный. Дело в том что скорее всего вы будете в конечном рекордсете данные группировать, или фильтровать (если конечно речь не идет про батч загрузку данных в другой источник). Поэтому лучше сделать эту обработку непосредственно в подзапросе. Пример 2 : select * from table1 all inner join (select field1, max(field2) as f2 from table2 where field1 in (select distinct field1 from table1) group by field1) as a1 on a1.field1 = table1.field1

Второй вариант - предпочтительнее - он существенно ограничит расходование оперативной памяти. Просто примените нужную вам агрегатную функцию , или ограничьте подзапрос с помощью where

пол терабайта с гигабитной сеткой скопируют через командную строку (сlickHouse-client) в течении часа - двух без остановки продовской ноды. Может быть просто перекинуть данные через конвейер ? Есть и более модные варианты - например clickhouse-copier (https://clickhouse.yandex/docs/ru/operations/utils/clickhouse-copier/)

Я тоже думаю что по времени это много не займет. Спасибо, сейчас пощупаю clickhouse-copier)

Например - есть 2 одинаковые таблицы на 2-х серверах srv1(version1) и srv2(version 19) create table tab (col1 int) Engine = MergeTree order by col1. В командной строке второго сервера : $clickHouse-client -h srv1 -q "select col1 from tab format TSV" | clickHouse-client -h srv2 -q "insert into tab(col1) format TSV"

подскажите пожалуйста, если я делаю INSERT INTO lcal_table SELECT * FROM remote(...) и выборка будет большая, оно же не будет сначала в память все грузить? Или нужно селект на пачки разбить?

; )) Попробуйте сделать так как я буквально постом выше предложил. Будет быстрее скорее всего

Какой-то бред. Зачем насиловать все insert-ми, если можно просто скопировать файлы?