PGConf.Russia 2018

СУБД Постгрес успешно используется во многих OLTP приложениях, выполняющих большое число простых запросов. Но для аналитики, требующей обработки большого количества данных, Постгрес на порядки отстаёт от специализированных СУБД, оптимизированных для массовой обработки данных. Скорость работы Постгреса для OLAP запросов сдерживается следующими факторами:

• Большие накладные расходы на распаковку записей.
• Затраты на интерпретацию запроса (Постгрес интерпретирует план выполнения запроса)
• Поддержка работы с абстрактными типами
• Недостатки PULL модели выполнения запроса
• Издержки MVCC

Все эти проблемы могут быть в большой степени решены за счёт использования векторного исполнителя запросов, который за одну операцию в состоянии обработать целый блок (вектор) значений. В этом докладе описывается способ добавления векторных операций в Посгрес, с помощью стандартного механизма расширения Посгреса, без внесения изменений в ядро. Такие механизмы Посгреса как UDT (определяемые пользователем типы), FDW (абстракция внешнего поставщика данных), расширения исполнителя запросов позволяют реализовать в Постгресе вертикальный таблицы, с которыми можно работать как с обычными таблицами. Но на порядки быстрее благодаря использованию векторных операций.

В своем выступлении я расскажу о том, как группа сисадминов набила шишки, пытаясь реанимировать петабайтный кластер баз данных Elasticsearch, и в конце концов решила заменить его проверенными технологиями: PostgreSQL, Kafka, немного Redis, много клея, и типичное сисадминское упрямство. Результатом стал Bagger - ответ сисадмина на вызов больших данных. Быстрое, надежное, устойчивое к отказам хранилище, используемое в основном для логирования временных событий. Bagger получил свое имя по названию серии ковшовых экскаваторов, одних из крупнейших наземных транспортных средств, когда-либо производимых человеком. Как эти экскаваторы прокапывают тонны материала, так и наш Bagger способен прокопаться через тонны данных.

В 10-й версии постгреса появилось встроенное партицирование таблиц. Однако ставить точку на развитии этого функционала, начало работы над которым ведётся с августа 2015 года, пока рано. В новом 11-ом релизе ведутся несколько параллельных работ по преодолению ограничений встроенного партицирования (update ключа партицирования, вставка в foreign партиции, локальные и глобальные индексы) и внедрение оптимизаций (runtime partition pruning, parallel append нода и partition-wise aggregation/grouping), которые восполнят многолетний пробел в этой области.

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

В своём доклады мы постараемся рассказать про возможности каждого из решений, обрисовать нишу, сделав упор на разрабатываемые фичи в ванильном постгресе.

В докладе рассматриваются подходы и варианты реализации миграции клиент-серверного приложения Парус-Бюджет 8 с платформы Oracle Database на платформу PostgreSQL без изменения клиентского приложения для Desctop и Web. Предлагаемое решение позволяет осуществить прозрачный переход существующих пользовательских рабочих мест.