Во время джойна КХ всю правую таблицу загружает в память?

да

Всем привет.  
Коллеги у меня у меня такая задача.  Есть интернет магазин для которого хотим настроить сквозную аналитику для наведения прозрачности в маркетинговых расходах. Хотели попробовать уже имеющиеся сервисы,  но в рамках ресерча ничего толкового не нашли. В рамках интернет магазина мы используем следующий стек технологий:

Яндекс Метрика и Google Analytics,  сервис коллтрекинга, онлайн чат, CRM. 

В рамках диджитал маркетинга мы используем контекстную рекламу (Директ и гугл адс)  таргетированную рекламу (Фейсбук, Майтаргет), 
Маркетплейсы (Яндекс Маркет). 


В чем сложность?  Первоисточником данных я как исполнитель решил использовать logs API Яндекс Метрики причина банально простая,  есть доступ ко всем логам. Плюс ко всему можно спокойно извлекать данные о необходимых мне источниках напрямую из Метрики,  а извлеченные данные уже обогащать данными из коллтрекинга, онлайн чата и CRM.  

Проблема. 

Для хранения данных полученных из logs API  документация Яндекса советует использовать базу данных Clickhouse, так вот кликхауз является колончатой БД,  то есть данные организованы не по принципу строкового хранения как это устроено в реляционных БД. В связи с этим такой вопрос на сколько правильно использовать в моей задаче Кликхауз,  на сколько гиморно сводить данные из реляционной базы данных (СRM) в кликхауз?  


Еще важный момент наша компания планирует в дальнейшем расширять функционал  хранилища, в связи с чем вопрос становится еще более актуальным. Какие сложности,  плюсы и минусы использования за основу Кликхауза, стоит ли его использовать в моей задаче,  или данные из Метрики сводить в кликхауз, а все остальные данные сводить в какой-нибудь PostgreSql  и уже метчить данные из кликхауза с данными постгреса? Спасибо за ответы.  

я не про то.

У вас первичная заливка и вам надо перелить из PG разово?

да, разово

ну вот разово возможно стоит перелить в КХ кучкой таблиц, тогда PG будет без джойна быстро выгружать, а поджойнить один раз в КХ

хм

Интересная мысль, спасибо

ну или разбраться почему PG джойнит медленно, хотя без хинтов хрен его заставишь переключится на nested loop

Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.

[тут пауза в пол часа]

Received exception from server (version 19.15.3):
Code: 1000. DB::Exception: Received from ХХХ.ХХХ.ХХХ.ХХХ:9000. DB::Exception: Timeout. 
Query was cancelled.

0 rows in set. Elapsed: 1800.497 sec. 

anyone ? halp

>так вот кликхауз является колончатой БД,  то есть данные организованы не
>по принципу строкового хранения как это устроено в реляционных БД

для вас разница будет только в том что нельзя сделать update/delete, записанные данные неизменны.
брать КХ стоит только в крайнем случае, если PG / mysql не хватило, КХ слишком сложно/дорого сопровождать

запрос В кх чем выполняли?

Спасибо большое за ответ

в clickhouse-client

clickhouse-client --receive_timeout=600000

не поможет конечно, но чем могу

Доброго времени суток!
А есть где то кукбучек или мануал, как нужно правильно шардировать существующую таблицу в несколько десятков ТБ по 2м (и больше) нодам.

Спасибо, а почему не поможет?

несколько десятков TB в день?

берете шардируете по рандому, не понравилось, шардируете по визитору, не понравилось, шардируете но id транзакции, ....

ну за 11 часов тупо tcp сокеты позакрываются, у вас MSSQL запрос выполняет 11 часов или данные 11 часов отдает?

в день пара ТB

Существующая таблица просто как первый шард остается?