Спасибо, согласен, column-oriented db может дать большой прирост производительности.
Cейчас мы используем foreign таблицы в Postgres в формате ORC, это колонко-ориентированный формат хранения данных, он уже дал нам большой прирост в производительности и пока что всем нас устраивает. Перейти с него на отдельную базу данных не так-то просто, аналитики привыкли к синтаксису Postgres и удобно, что можно в одной базе данных без DI-решений сделать сджоинить эту денормализованную таблицу с чем-то ещё.
В dimension1|dimension2|dimensionN мы уже добавили информацию по пользователю и его аккаунту за этот день.
Для простых запросов эту таблицу можно ни с чем не джоинить, все данные уже в ней есть.
Но денормализация не работает для данных, которые обновляются в прошлое или для спорных данных, которые зависят от контекста запроса. В таких случаях всё-таки приходится делать джоин.
Я думаю, что это не костыль, а попытка не смешивать мух с котлетами. Задача Webpack — объединять файлы и резолвить зависимости. Он может сообщать, что файл обновился, обновлять браузер, превращать Sass в Css и минифицировать его, но описание процесса сборки приложения — не его основная задача.
С другой стороны в Task Runner'ах (Gulp, Grunt и т.д.) основная возможность — описание процесса сборки проектов. В Gulp используют идеи Stream'ов, это значит, что можно задать процесс сборки приложения в таком виде: для всех файлов *.sass нужно применить такие-то плагины, если в процессе произошла ошибка нужно что-то залогировать (или к примеру откатиться до предыдущей версии), дальше нужно сохранить файл с расширением css в такую-то папку и обновить браузер. Так же можно писать операторы ветвления, то есть разделять на Production и Developer режим (или не собирать приложения после 3 часов ночи и говорить, что пора спать). В таком жизненном цикле Wepback — просто ещё одна утилита, учавствующая в процессе сборки.
Конечно, можно для всего этого использовать Webpack и это отличный подход для проектов с простым процессом сборки. Но использовать Webpack для сложного процесса сборки, включающего разлив на сервера, запуск тестов, статический анализ кода и другие плюшки, куда больший костыль.
Согласен, но в этом есть смысл. Скорее всего, эти технологии пришли из сложных проектов, где появились не просто так. А на таких простых проектах можно в них разобраться.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо, согласен, column-oriented db может дать большой прирост производительности.
Cейчас мы используем foreign таблицы в Postgres в формате ORC, это колонко-ориентированный формат хранения данных, он уже дал нам большой прирост в производительности и пока что всем нас устраивает. Перейти с него на отдельную базу данных не так-то просто, аналитики привыкли к синтаксису Postgres и удобно, что можно в одной базе данных без DI-решений сделать сджоинить эту денормализованную таблицу с чем-то ещё.
Как именно денормализовать?
В
dimension1|dimension2|dimensionNмы уже добавили информацию по пользователю и его аккаунту за этот день.Для простых запросов эту таблицу можно ни с чем не джоинить, все данные уже в ней есть.
Но денормализация не работает для данных, которые обновляются в прошлое или для спорных данных, которые зависят от контекста запроса. В таких случаях всё-таки приходится делать джоин.
С другой стороны в Task Runner'ах (Gulp, Grunt и т.д.) основная возможность — описание процесса сборки проектов. В Gulp используют идеи Stream'ов, это значит, что можно задать процесс сборки приложения в таком виде: для всех файлов *.sass нужно применить такие-то плагины, если в процессе произошла ошибка нужно что-то залогировать (или к примеру откатиться до предыдущей версии), дальше нужно сохранить файл с расширением css в такую-то папку и обновить браузер. Так же можно писать операторы ветвления, то есть разделять на Production и Developer режим (или не собирать приложения после 3 часов ночи и говорить, что пора спать). В таком жизненном цикле Wepback — просто ещё одна утилита, учавствующая в процессе сборки.
Конечно, можно для всего этого использовать Webpack и это отличный подход для проектов с простым процессом сборки. Но использовать Webpack для сложного процесса сборки, включающего разлив на сервера, запуск тестов, статический анализ кода и другие плюшки, куда больший костыль.