PgConf.Russia 2016

Изначально компания «БАРС Груп» была ориентирована на задействование в своих проектах СУБД Oracle, но появление PostgreSQL игнорировать не могла. На конференции мы расскажем, как пришли к использованию PostgreSQL и поделимся опытом перевода на эту СУБД большой медицинской информационной системы.

1. Опыт использования СУБД PostgreSQL и Oracle в проектах компании. Предпосылки и мотивация использования СУБД PostgreSQL.

2. Ход и результаты эксперимента миграции медицинской информационной системы:

   • разработка утилиты конвертации кода PL/SQL в PgSQL;
   • проблемы переноса сложных пакетов;
   • патчи к PostgreSQL как варианты решения этих проблем.

В корпоративных информационных системах от СУБД требуется поддержка кластеров, для обеспечения требуемого уровня масштабирования и надёжности. К сожалению, многочисленные попытки реализовать кластеры для Постгреса, такие как Postgres-XL/XC, так и не были доведены до коммерческого уровня и не были приняты сообществом. Другие существующие решения, например, pg_shard, plproxy не поддерживают глобальных ACID транзакций. Наша команда разработала менеджер распределённых транзакций (DTM) как расширение Постгреса, позволяющее достичь глобальной целостности для нескольких экземпляров Постгреса, объединённых в один кластер. DTM - это конструктор, позволяющий реализовать различные решения на его основе. В качестве демонстрации возможностей DTM мы интегрировали его в pg_shard и postgres_fdw. Мы надеемся, что наш подход с расширяемым менеджером транзакций будет включён в версию 9.6 Постгреса и позволит разрабатывать различные кластерные решения на его основе.

Резервное копирование это то, без чего не должна обходится эксплуатация PostgreSQL, поскольку позволяет восстановить систему в случае сбоя.

Мы обсудим, почему резервное копирование необходимо при грамотной эксплуатации PostgreSQL (хотя это и кажется очевидным), а также рассмотрим различные опции, доступные для формирования хорошей стратегии резервирования. На этой основе, поговорим о будущем резервного копирования, особенно в свете различных инструментов резервирания, набирающих популярность у пользователей с большими объемами данных.

Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями. Однако, средства расширяемости Postgres предоставляют разработчику широкие возможности, позволяющие обойти некоторые ограничения. В докладе будет рассказано, как внедрившись в код планировщика удалось оптимизировать время планирования запросов. Так метод бинарного поиска позволяет добиться логарифмического роста времени планирования для RANGE-секционированных таблиц. Поэтому использование даже тысяч секций не будет приводить к существенным накладным расходам. Также удалось реализовать HASH-секционирование с близким к константному времени планирования.