как понять, из-за чего кликхаус иногда перестаёт нормально функционировать, в консоли кроме запроса и query_id ничего не появляется, а драйвер отдаёт ошибку "bad connection"?

в какой консоли? и что такое драйвер?

что в логе КХ?

версия КХ?

а кстати у вас КХ далеко от заливалищика? сетевая летенси сколько?

В докерах на одной машине. Латенси минимальна, полагаю)

ясно, возможно что goшный компресс делает не совсем такой gzip как линуксовый gzip

Спасибо.

В последних версиях КХ умеет притворяться PostgreSQL, принимает запросы на postgresql_port

Всем, привет.
Помогите обстукать решение, мы только едем на кликхаус.

Такой кейс: есть 2 таблицы фактов из источников (на самом деле больше, но для простоты): таблица платежей из платежной системы и таблица платежей из нашей учетной системы. В 95% случаев операции соответствуют друг другу 1-к-1, в 5% случаев (свякие отмены, проведения двумя платежами, начисление бонусов и пр.) операции 1-ко-многим.

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

для начала надо попробовать join.

пробовали конечно, все затыкается, правая таблица не влазит в память

А в чем проблема сделать одну широкую? Уникальность в кх не требуется.

Вопрос как это сделать правильно, варианты:

1. Все сложить в одну широкую таблицу, ключевые поля объединить, с последующим SummingMergeTree числовых полей.

Минусы: записи схлопываться в фоновом режиме и мы при вычитке никогда не можем быть уверенны, что запись уже схлопнута.

2. Вообще ничего не объединять, все складывать в одну широкую таблицу, где каждая колонка сообветствует полю исходной таблицы, таким образом получаем струкруру примерно такого вида:
t1.x, t1.y, t1.z, NULL, NULL, NULL
NULL, NULL, NULL, t2.x, t2.y, t2.z
,а необходимые обогащения атрибутами по внешнему ключу дообогащать в соседних колонках на этапе E&L.

Минусы: усложнене E&L, отход от ELT

Еще был вариант:

3. Все сложить в одну узкую generic-таблицу, как описано здесь: https://habr.com/ru/company/badoo/blog/442616/ - и дальше играться с агрегирующими функциями и лямбдами

Минусы: не очень удобно с этим работать, громоздкие и не тривиальные запросы получаются.

Непонятны минусы первого варианта.   Ключевые поля объединяются, числовые поля разных таблиц становятся массивами (потому как в 5% случаев 1:N). Некоторые поля исходных таблиц возможно обойдутся и без превращения в массивы. Обычный MergeThree.  При агрегациях вылезет немного array функций или даже arrayjoin'ов, но в терпимых количествах.

спасибо за комментарий, правильно ли я понимаю, что структура для записей из двух таблиц:

t1:
a b c t2_id

и

t2:
id1 x1 y1 z1
id2 x2 y2 z2

должна получится широкая структура:

a b c t2_id [id1,id2] [x1,x2] [y1,y2] [z1,z2]

да, я бы подумал прежде всего о такой изначальной структуре.  дальше надо смотреть насколько сложными получатся arrayXXX запросы, в какой MV это имеет смысл преобразовать, можно ли какие-то исходные аттрибуты сразу превратить в скаляры, итд.

В чем проблема сделать одну таблицу с указанием источника?

вы имеете ввиду мой вариант 3?

извиняюсь за свою чайниковость, что есть MV? 🙄😅