PGConf.Russia 2018

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

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

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

Администратор баз данных регулярно сталкивается с необходимостью поиска проблемных запросов в своих базах данных. Для оперативного поиска хорошо подходит PGCenter, но что делать если проблемы производительности наблюдались в прошлом? В этом докладе я хочу поделиться своим опытом разработки и применения инструментария, позволяющего производить ретроспективный анализ нагрузки запросов в базах данных PostgreSQL - pg_profile

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

В последнее время PostgreSQL все чаще используется для Enterprise. Наша компания Ingram Micro Cloud была одной из первых, кто сделал это. Мы уже много лет используем PostgreSQL в качестве основной СУБД для наших продуктов. В докладе мы хотим рассказать об эволюции нашего High Availability (HA) кластера PostgreSQL: как мы в сжатые сроки внедряли решение на pgpool-II, писали failover сценарии, тестировали Postgres-XL и придумывали необычные конфигурации Stolon. Немного поговорим о проблемах балансировки нагрузки, пуллинга соединений и бекапировании.