PGConf.Russia 2018

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

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

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

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

Я расскажу про то, как мы в Postgres Professional улучшили работу с индексами, а именно, добавили возможность использования параметров для их создания. В качестве примера, я расскажу про "умное" индексирование jsonb с помощью нашего расширения jsquery. "Умное" индексирование означает, что можно задавать подмножество jsonb для индексирование с помощью jspath,нового типа данных jsquery, который можно будет указывать в качестве параметра при создании индекса. Таким образом, индекс будет меньше,что положительно скажется на производительности запросов и лучшей конкурентности. Кроме того, параметры к оп классам позволят гибче работать с уже существующими индексами, а также помогут при индекскации jsonb с помощью jsonpath из ожидаемого SQL/JSON.

Как оптимизировать производительность запросов в PostgreSQL? Как это делать, если серверов - сотни, а баз - тысячи? В "Тензоре" мы разработали для этого отдельный инструмент - explain.sbis.ru: - для синхронного сбора и анализа запросов - для визуализации планов выполнения - для мониторинга ошибок в БД

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

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

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