Как стать автором
Обновить

Комментарии 16

«Фреймворк для создания OLAP на триггерах»
1. может быть использован только создателем
2. совершенно бесполезен в конкурентной высоконагруженной системе
Чем вам обычный DDL не угодил, у вас так много таблиц, которые требуют агрегации и их число постоянно растет, чтобы разрабатывать для этого фреймворк? Даже в этом случае выгода сомнительно, поскольку предпоследний запрос в разы проще осмысления вызова 6-ти функций, для описания колонок. Сочувствую тому специалисту, который будет все это поддерживать после вас и будет вынужден использовать эти функции. Хотя думаю он свой велосипед напишет.
Если Вам известна какая-либо бесплатная альтернатива, с удовольствием выслушаю ваш совет.
Метод сбора агрегированных данных через хранимую процедуру НЕ ПОДХОДИТ при большой активности базы данных. Т.к. при этом возникает много блокировок и из-за них тормозятся запросы на изменение данных. Данные могут меняться параллельными запросами для разных записей. Тут все нормально. Но при этом они будут менять одни и те-же данные в агрегационной таблице. И тут точно будут блокировки.

Я с этим столкнулся на реальной задаче.
Буду иметь в виду. Но у меня очень специфичная задача. Думаю там все будет нормально.
Просто присматривайте за логом и обратите внимание на сообщения о блокировках в нем.
Конечно, но у меня идет массовая вставка с одной стороны и аналитика с другой. Сильно рассчитываю на версионность Postgress-а, а в дальнейшем вообще планирую разнести это на разные узлы
Массовая вставка в один поток? Если так — то это не страшно. Но если там параллельные запросы — обязательно наткнетесь на блокировки, которые будут эти вставки тормозить.
Ответил ниже. Пока вставка из нескольких потоках. С одним снапшотом друг другу заметно не мешали. В идеале будет вставка из одного потока.
Мы это решили через преобразование параллельного потока в последовательный. А делали это через pgq — систему очередей для postgresql.

Правда, обрабатывать уже пришлось внешним приложением по крону. Хотя, думаю, так-же можно обрабатывать и хранимой процедурой (тоже по крону).
Приблизительно то-же самое будет делаться в приложении собирающем входные данные. Пока-что пишет одиночными insert-ами, параллельными сессиями. Кстати, мне не удалось обнаружить деградации производительности, вызванной триггерами, вплоть до 100 одновременных пишущих сессий. Масштабируется практически линейно.
Вам просто повезло. При наличии блокировки запрос, который на нее напарывается, делает паузу в 1 секунду (настройка по умолчанию postgresql). А при большой нагрузке одна секунда может легко превратиться в 10 (было в реальности) и т.д.
Вряд-ли везение здесь подходящее слово. Я все привык тестировать. Если это решение будет заметно просаживать производительность (в моей задаче), будем искать другое решение (например обновление снапшотов по расписанию). Но то что снапшоты понадобятся, совершенно очевидно.
Когда будут, перейдем на них. Если я скажу Заказчику, что надо чего-то ждать, меня сильно не поймут.
НЛО прилетело и опубликовало эту надпись здесь
Я уверен, что их будут дорабатывать. Просто ждать я этого не могу.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории