GlukKazan 30 апр 2013 в 12:53

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

19 мин

9.3K

PostgreSQL*

Туториал

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

mcshadow 30 апр 2013 в 14:29

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

GlukKazan 30 апр 2013 в 21:57

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

UncleAndy 30 апр 2013 в 15:01

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

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

GlukKazan 30 апр 2013 в 15:06

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

UncleAndy 30 апр 2013 в 15:11

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

GlukKazan 30 апр 2013 в 15:14

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

UncleAndy 30 апр 2013 в 15:50

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

GlukKazan 30 апр 2013 в 21:55

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

UncleAndy 30 апр 2013 в 15:53

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

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

GlukKazan 30 апр 2013 в 21:53

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

UncleAndy 30 апр 2013 в 22:43

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

GlukKazan 1 мая 2013 в 12:55

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