Сообщение Re[3]: Оптимизация работы с sql от 03.01.2024 18:01
Изменено 03.01.2024 18:10 Gt_
Re[3]: Оптимизация работы с sql
MVK>У меня сейчас другая задача.
MVK>Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения.
MVK>Максимум — это питонячий скрипт, который потом докручивает аналитику или ML.
MVK>С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей.
MVK>Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному.
MVK>Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. там полчучиться в цикле добавление к датафрейму колонок с метриками, новая метрика наследуется там от чего-то. как бонус сумашедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
MVK>Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения.
MVK>Максимум — это питонячий скрипт, который потом докручивает аналитику или ML.
MVK>С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей.
MVK>Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному.
MVK>Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. там полчучиться в цикле добавление к датафрейму колонок с метриками, новая метрика наследуется там от чего-то. как бонус сумашедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
Re[3]: Оптимизация работы с sql
MVK>У меня сейчас другая задача.
MVK>Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения.
MVK>Максимум — это питонячий скрипт, который потом докручивает аналитику или ML.
MVK>С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей.
MVK>Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному.
MVK>Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. там получиться в цикле добавление к датафрейму колоноки с метриками, новая метрика наследуется там от чего-то. как бонус сумасшедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
MVK>Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения.
MVK>Максимум — это питонячий скрипт, который потом докручивает аналитику или ML.
MVK>С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей.
MVK>Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному.
MVK>Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. там получиться в цикле добавление к датафрейму колоноки с метриками, новая метрика наследуется там от чего-то. как бонус сумасшедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.