Комментарии 16
«Фреймворк для создания OLAP на триггерах»
1. может быть использован только создателем
2. совершенно бесполезен в конкурентной высоконагруженной системе
Чем вам обычный DDL не угодил, у вас так много таблиц, которые требуют агрегации и их число постоянно растет, чтобы разрабатывать для этого фреймворк? Даже в этом случае выгода сомнительно, поскольку предпоследний запрос в разы проще осмысления вызова 6-ти функций, для описания колонок. Сочувствую тому специалисту, который будет все это поддерживать после вас и будет вынужден использовать эти функции. Хотя думаю он свой велосипед напишет.
1. может быть использован только создателем
2. совершенно бесполезен в конкурентной высоконагруженной системе
Чем вам обычный DDL не угодил, у вас так много таблиц, которые требуют агрегации и их число постоянно растет, чтобы разрабатывать для этого фреймворк? Даже в этом случае выгода сомнительно, поскольку предпоследний запрос в разы проще осмысления вызова 6-ти функций, для описания колонок. Сочувствую тому специалисту, который будет все это поддерживать после вас и будет вынужден использовать эти функции. Хотя думаю он свой велосипед напишет.
0
Метод сбора агрегированных данных через хранимую процедуру НЕ ПОДХОДИТ при большой активности базы данных. Т.к. при этом возникает много блокировок и из-за них тормозятся запросы на изменение данных. Данные могут меняться параллельными запросами для разных записей. Тут все нормально. Но при этом они будут менять одни и те-же данные в агрегационной таблице. И тут точно будут блокировки.
Я с этим столкнулся на реальной задаче.
Я с этим столкнулся на реальной задаче.
+1
Буду иметь в виду. Но у меня очень специфичная задача. Думаю там все будет нормально.
0
Просто присматривайте за логом и обратите внимание на сообщения о блокировках в нем.
0
Конечно, но у меня идет массовая вставка с одной стороны и аналитика с другой. Сильно рассчитываю на версионность Postgress-а, а в дальнейшем вообще планирую разнести это на разные узлы
0
Массовая вставка в один поток? Если так — то это не страшно. Но если там параллельные запросы — обязательно наткнетесь на блокировки, которые будут эти вставки тормозить.
0
Мы это решили через преобразование параллельного потока в последовательный. А делали это через pgq — систему очередей для postgresql.
Правда, обрабатывать уже пришлось внешним приложением по крону. Хотя, думаю, так-же можно обрабатывать и хранимой процедурой (тоже по крону).
Правда, обрабатывать уже пришлось внешним приложением по крону. Хотя, думаю, так-же можно обрабатывать и хранимой процедурой (тоже по крону).
0
Приблизительно то-же самое будет делаться в приложении собирающем входные данные. Пока-что пишет одиночными insert-ами, параллельными сессиями. Кстати, мне не удалось обнаружить деградации производительности, вызванной триггерами, вплоть до 100 одновременных пишущих сессий. Масштабируется практически линейно.
0
Вам просто повезло. При наличии блокировки запрос, который на нее напарывается, делает паузу в 1 секунду (настройка по умолчанию postgresql). А при большой нагрузке одна секунда может легко превратиться в 10 (было в реальности) и т.д.
0
Если подождать 9.3, то будут MV: www.postgresql.org/docs/devel/static/sql-creatematerializedview.html
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Секционирование и «живые снимки» данных в PostgreSQL