Секционирование и «живые снимки» данных в PostgreSQL

[mcshadow]

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

[GlukKazan]

Если Вам известна какая-либо бесплатная альтернатива, с удовольствием выслушаю ваш совет.

[UncleAndy]

Метод сбора агрегированных данных через хранимую процедуру НЕ ПОДХОДИТ при большой активности базы данных. Т.к. при этом возникает много блокировок и из-за них тормозятся запросы на изменение данных. Данные могут меняться параллельными запросами для разных записей. Тут все нормально. Но при этом они будут менять одни и те-же данные в агрегационной таблице. И тут точно будут блокировки.

Я с этим столкнулся на реальной задаче.

[GlukKazan]

Буду иметь в виду. Но у меня очень специфичная задача. Думаю там все будет нормально.

[UncleAndy]

Просто присматривайте за логом и обратите внимание на сообщения о блокировках в нем.

[GlukKazan]

Конечно, но у меня идет массовая вставка с одной стороны и аналитика с другой. Сильно рассчитываю на версионность Postgress-а, а в дальнейшем вообще планирую разнести это на разные узлы

[UncleAndy]

Массовая вставка в один поток? Если так — то это не страшно. Но если там параллельные запросы — обязательно наткнетесь на блокировки, которые будут эти вставки тормозить.

[GlukKazan]

Ответил ниже. Пока вставка из нескольких потоках. С одним снапшотом друг другу заметно не мешали. В идеале будет вставка из одного потока.

[UncleAndy]

Мы это решили через преобразование параллельного потока в последовательный. А делали это через pgq — систему очередей для postgresql.

Правда, обрабатывать уже пришлось внешним приложением по крону. Хотя, думаю, так-же можно обрабатывать и хранимой процедурой (тоже по крону).

[GlukKazan]

Приблизительно то-же самое будет делаться в приложении собирающем входные данные. Пока-что пишет одиночными insert-ами, параллельными сессиями. Кстати, мне не удалось обнаружить деградации производительности, вызванной триггерами, вплоть до 100 одновременных пишущих сессий. Масштабируется практически линейно.

[UncleAndy]

Вам просто повезло. При наличии блокировки запрос, который на нее напарывается, делает паузу в 1 секунду (настройка по умолчанию postgresql). А при большой нагрузке одна секунда может легко превратиться в 10 (было в реальности) и т.д.

[GlukKazan]

Вряд-ли везение здесь подходящее слово. Я все привык тестировать. Если это решение будет заметно просаживать производительность (в моей задаче), будем искать другое решение (например обновление снапшотов по расписанию). Но то что снапшоты понадобятся, совершенно очевидно.

[Biggo]

Если подождать 9.3, то будут MV: www.postgresql.org/docs/devel/static/sql-creatematerializedview.html

[GlukKazan]

Когда будут, перейдем на них. Если я скажу Заказчику, что надо чего-то ждать, меня сильно не поймут.

[GlukKazan]

Я уверен, что их будут дорабатывать. Просто ждать я этого не могу.