AG
а в чем проблема заливки данных в CH ?
в том же, в чём сейчас проблема в заливке в BQ, прочитайте начало
Size: a a a
2020 July 16
YS
Такое бывает. Когда в отчете для управленцев расходы на сотни миллионов, например, округляются до тысяч.
Округляется — это одно дело. Другое — это когда эти расходы просто исчезают (теряются процессом ETL) до внезапного неприятного пробуждения через N месяцев, когда выясняется, что всё это время они "летали по пачке «Беломора»". ;)
YB
Елена, а локально из шелла запрос с выводом в devnull сколько времени выполняется?
если я все правильно делаю то уже больше 15 минут прошло
select current_timestamp; \copy (SELECT o.platform, o.platform_order_id, o.platform_created_at, o.extended_money_status, o.money_status, extended_delivery_status, delivery_status, synced_at FROM public.tbl_order o) TO /dev/null (DELIMITER ','); select current_timestamp;
current_timestamp
-------------------------------
2020-07-16 14:05:35.487854+03
(1 row)AG
можно новые данные направить в КХ, тем самым снимется нагрузка с ПГ (insert/update). И уже забирать старые данные с ПГ и заливать в КХ
Тут можно услышать следующее: приложение дикий легаси/исправить не можем/и т.д., приходится работать с тем, что есть.
Сложно давать варианты решения, когда не знаешь что там вообще происходит.
Сложно давать варианты решения, когда не знаешь что там вообще происходит.
YS
а что конкретно вы тут имели в виду про дрянь?
То, что если процесс почему-то не запустится в этот час (или даже минуту) / "поедут" часы / есть слишком длинные транзакции и т.д. и т.п., в результатах получатся не те данные, которые на источнике (если сильно не повезёт / обновления редки — то надолго).
EM
в том же, в чём сейчас проблема в заливке в BQ, прочитайте начало
ну, надо конечно спроектировать правильную таблицу и обновления отдельно заливать. а не выгружать постоянно из постгреса весь объем (если я правильно понял весь тред)
YB
Yaroslav Schekin
То, что если процесс почему-то не запустится в этот час (или даже минуту) / "поедут" часы / есть слишком длинные транзакции и т.д. и т.п., в результатах получатся не те данные, которые на источнике (если сильно не повезёт / обновления редки — то надолго).
да. согласна. это был как пример чтобы понять о чем человек говорил
YS
если я все правильно делаю то уже больше 15 минут прошло
select current_timestamp; \copy (SELECT o.platform, o.platform_order_id, o.platform_created_at, o.extended_money_status, o.money_status, extended_delivery_status, delivery_status, synced_at FROM public.tbl_order o) TO /dev/null (DELIMITER ','); select current_timestamp;
current_timestamp
-------------------------------
2020-07-16 14:05:35.487854+03
(1 row)Есть же \timing в psql для этого, если что.
Но в этот и так сойдёт. И какое время это заняло?
Но в этот и так сойдёт. И какое время это заняло?
YB
Yaroslav Schekin
Есть же \timing в psql для этого, если что.
Но в этот и так сойдёт. И какое время это заняло?
Но в этот и так сойдёт. И какое время это заняло?
еще не завершилось
YB
то есть уже 35 минут
YS
я бы на месте Елены, вообще попробовал бы колоночную СУБД для этих целей. Тот же кликхаус. Там сразу есть и встроенные механизмы анализа
Так они же и используют BigQuery...
AG
ну, надо конечно спроектировать правильную таблицу и обновления отдельно заливать. а не выгружать постоянно из постгреса весь объем (если я правильно понял весь тред)
Бывает так, что и таблица спроектирована нормально, но процесс выстроен не так.
У меня есть опыт выгрузки финансов из SAP, где долго меня убедждали, что можно только за месяц вытащить по периоду, реалтайма нет и т.д. А по факту оказалось, что там только инсерты, да ещё и с таймстампом операции, по которому легко всё достаётся.
У меня есть опыт выгрузки финансов из SAP, где долго меня убедждали, что можно только за месяц вытащить по периоду, реалтайма нет и т.д. А по факту оказалось, что там только инсерты, да ещё и с таймстампом операции, по которому легко всё достаётся.
СГ
Yaroslav Schekin
Так они же и используют BigQuery...
я понимаю. Просто так сразу данные будут в том месте, где уже можно анализировать без необходимости заливать в BQ
A
то есть уже 35 минут
запрос с перенаправлением в /dev/null?
YB
запрос с перенаправлением в /dev/null?
TO /dev/nullYB
я понимаю. Просто так сразу данные будут в том месте, где уже можно анализировать без необходимости заливать в BQ
то есть постгрес заменить на кликхаус?)
СГ
хотя конечно мои предложения и предположения всего лишь на основании видения "только части слона"
YS
еще не завершилось
А, просмотрел первый "select current_timestamp;", подумал, что Вы результат последнего показали. :)
EM
Бывает так, что и таблица спроектирована нормально, но процесс выстроен не так.
У меня есть опыт выгрузки финансов из SAP, где долго меня убедждали, что можно только за месяц вытащить по периоду, реалтайма нет и т.д. А по факту оказалось, что там только инсерты, да ещё и с таймстампом операции, по которому легко всё достаётся.
У меня есть опыт выгрузки финансов из SAP, где долго меня убедждали, что можно только за месяц вытащить по периоду, реалтайма нет и т.д. А по факту оказалось, что там только инсерты, да ещё и с таймстампом операции, по которому легко всё достаётся.
имеется в виду кликхаусная таблица - там много разных движков под разные кейсы
СГ
то есть постгрес заменить на кликхаус?)
скорее BQ заменить на CH и заливать данные для анализа напрямую в КХ