Исходя из ваших комментариев, получается, что чтобы получить марты в

CH из данных в PG, неправильно тянуть сырые данные в CH и там их обрабатывать, лепить справочники и джойнить все это потом. Но как же тогда верно?

Опасная тропинка. Получите 150 гиг словарей в оперативке и уже не такая это будет и радость)

Ну я например всю логику закинул в Спарк. А CH только отдаёт. Хотя это спорный момент.. в любом случае все справочники, кроме самого здорового убрать в словари надо. Здоровый... Ну там надо смотреть..

Ну это зависит от данных основной таблицы и как словари сделать.

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

Ааа, расстраиваете) я только более-менее начал осваивать dbt, но если джойны таким образом делать нельзя, то он dbt отпадает(

16 гиг это пока дали поковыряться, потом будет побольше...64 гига хватит? Больше не дадут)

Можно. Куча людей использует dbt. Правда. У них железо мощное. Ну из тех что я знаю

Тогда я запутался. В dbt как-раз удобно делать снежинку, иметь справочники и факты. Но если, условно, как вы сказали, делать все это на Спарк, а в клик лить только для того ,чтобы он быстро отдавал, то где тут роль dbt? А иначе я никак не избегаю джойнов. Потому что я начинаю плясать от нормализованных данных.

в целом в документации рекомендуется от 32 но я бы включил логи в trace и посмотрел куда время уходит

Спасибо, почитаю, что это за логи и будем смотреть ☺️

Если данные из PG, то почему в нем же денормализацию и не сделать?

Пока что по двум причинам: 1) в PG у меня доступ только к реплике без возможности создания/изменения там чего-либо 2) в PG все эти джойны и группировки долго выполняются. Я тоже до этого читал, что CH не любит джойны и т.д., но на менее мощном железе CH все эти джойны делает быстрее, чем PG Я все еще ищу какой-то более оптимальный способ для организации всего этого, опыта особо нет в проектировании где и на каком этапе лучше делать обработку, поэтому буду благодарен за любые советы 😊 Думаю это частая задача, когда из нормализованной OLTP в CH нужно перенести вьюшки.

ну так сделайте к этой ПГ еще одну реплику ПГ :)) и делайте в ней что хотите )) в КХ можно совмещать миллионы записей и джойны, но для этого надо кропотливо работать Где-то словари, где-то сортировки и первичные ключи, где-то предагрегации бездумно поджойнить - это ПГ

еще одна причина) в CH таблицы весят гораздо меньше, в PG у меня нет столько памяти все это хранить >бездумно поджойнить - это ПГ у меня как раз бездумные джойн получаются быстрее более-менее осмысленных в PG)

а если я в CH на таблицы наложу ORDER BY на колонки, по которым идет джойн - станет быстрее?

нет, КХ не использует индексы и orderby для join

ненене - тут нету ответов из 2-3 пунктов )

а PRIMARY KEY?)

то есть они чисто для селектов?!

под индексом я подразумевал primary key

типа да. Но вообще в первую очередь они нужны чтобы данные сохранить, пожать и помержить

SELECT -- для простоты напишу просто все поля из всех таблиц -- но по факту прописываю отдельно все 60 полей в селекте isr.* , cal.* , d.* , dr.* , dd.* -- таблица фактов 170 млн.строк FROM int_so_regions AS isr -- справочник-календарь на 2132 строк LEFT JOIN dim_calendar AS cal ON isr."date_report" = cal."date" -- справочник препаратов на 440596 строк LEFT JOIN dim_drug_so AS d ON isr."drug_id" = d."id" -- справочник регионов на 87 строк LEFT JOIN dictionary_region AS dr ON isr.region_id = dr.id -- справочник округов на 12 строк LEFT JOIN dictionary_district AS dd ON dr.district_id = dd.id т.е. если я сделаю все поля для джойнов как PRIMARY KEY скорость должна увеличиться? или это фиговая практика, накладывать PRIMARY KEY только для ускорения джойнов?

не увеличится

мне сказали, что справочник на 440596 строк не залезет в словарь

Ну сожрет мегабайт 500

500 звучит немного) а в моем понимании словарь - это ключ-значение...а если мне из словаря надо для одного ключа получить 30 значений (разных колонок)?

Да нормально, ток используйте HASHED_ARRAYS лайоут, он как раз для такого подойдет

30 раз напишите getDict

Стикер

Не обязательно, словари имеют спец оптимизацию для join, И кстати dictGet может возвращать несколько аттрибутов как тапл

ну вот ваш коллега рекомендовал все же getDict

Поэтому стоит попробовать и то и то Для тапла синтакс как то так выглядит dictGet(name, 'col_1, col_2', ..)

потому что join со словорем автоматически транслируется в dictGet только если ключ словаря UInt64 и надо еше join_algorithm поставить=direct

я получил то на то а так как набор гетов уже написал, то так и оставил :))

как бы это прихранить 🙂

А это в какой версии появилось? Или изначально так было? Вроде бы раньше писали, что обращение к словарю без словарных функций типа dictGet/dictHas - это только для отладки.

Там была проблема в том, что один дикт гет достает за один раз а 30 дикт гет выполняется 30 раз, но вроде это хотели оптимизировать, но не помню статус этой хотелки

на данный момент 30 точно работает дольше, чем 1 🙂

в 20... что-то там я потому и рекомендую dictGet потому что вы никогда не узнаете что оно перестало работать, ну будете запросы переписывать после апгрейда. т.е. оно работало, потом перестало, потом стало работать если =direct

ну hashedArray оптимизирован под tuple, в хештаблицу один раз сходит

Ну можете переделать на тапл тогда, да

тапл и антапл не дало радости