Меня зовут Михаил Гелемеев, я лидер команды сопровождения Platform V Pangolin в СберТехе.

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

В январе мы выпустили новую версию — Platform V Pangolin 6.1. В ней появились обновления для работы с большим объёмом данных. Если вкратце — работать с секциями стало проще и быстрее: дешевле доступ к данным в секционированных таблицах, и для них можно гибко создавать уникальные глобальные индексы. Теперь можно предотвратить высокое потребление CPU и RAM пользовательской сессией, это улучшает доступность сервиса. Мы также добавили инструмент диагностики текущей активности для детального понимания процессов сессии, так работа СУБД становится более прозрачной.

В статье подробнее расскажу о каждой из доработок. Их можно условно разделить на две части: для пользователей и для администраторов/инфраструктуры.

Обновления для пользователей

Начну с достоинств обновлённого продукта для наших пользователей.

Глобальные индексы для секционированных таблиц

Глобальные индексы для секционированных таблиц физически покрывают сразу множество подтаблиц и обеспечивают ограничение уникальности по набору атрибутов, не содержащих ключ секционирования.

Каждый, кто использовал секционированные таблицы, рано или поздно сталкивался с ограничениями реализации механизма секционирования, например:

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

• Индекс всегда секционирован, как и основная таблица. Это приводит к избыточным чтениям (примерно пропорционально количеству секций) в случаях, когда в запросе нет фильтра по ключу секционирования. Результат — много чтений на простых запросах и увеличенное время выполнения запроса.

В версии 6.1 мы добавили возможность создавать глобальные индексы. Эта функциональность снимает описанные ограничения:

• Позволяет создавать и использовать глобальные ограничения уникальности по полям секционированных таблиц, отличных от полей ключа секционирования.

• Значительно повышает эффективность поиска записей в секционированных таблицах по уникальному ключу, в том числе не содержащему ключ секционирования.

Важно, что при проектировании и разработке мы учитывали опыт эксплуатации решений западных коллег. Например, в Platform V Pangolin при отсоединении секции, то есть при вызове ALTER TABLE DETACH PARTITION,индекс остаётся доступным для пользования. Подробнее можно узнать из документации.

Увеличение битности идентификаторов транзакций (XID) до 64 бит 

Увеличение битности идентификаторов транзакций (XID) до 64 бит способствует снятию проблемы достижения XID wraparound и связанных с этим ограничений и нюансов эксплуатации.

Сейчас в ядре оригинального PostgreSQL под счётчик транзакций выделено 32 бита, которые покрывают всего 4 млрд транзакций (XID). Во избежание исчерпания номеров транзакций применяется закольцованная схема счётчика.

Много лет назад на этапе проектирования PostgreSQL 4 млрд транзакций было достаточно. Но сейчас в нагруженной системе вполне можно исчерпать счётчик за несколько дней. 64-битный счетчик транзакций практически никогда не переполнится. Даже при нагрузке 2^32 транзакций в день (~50 000 TPS) граница раздела между прошлым и будущим будет достигнута через 2^31 дней (5,9 млн лет). Преимущества такого счетчика следующие:

• Возможность избежать прекращения выполнения поступающих запросов на запись в условии высокой транзакционной нагрузки, если есть долгоживущая транзакция, удерживающая горизонт транзакций (xmin). Например, в случае 32-битного счетчика 13-часовой OLAP‑запрос спустя 12 часов стал бы причиной отказа в обслуживании OLTP‑запросов со скоростью 50 000 TPS. К этому моменту возраст очередной пишущей транзакции достиг бы 2^31 по отношению к горизонту транзакций, удерживаемому OLAP‑запросом. Горизонт транзакций не даёт автовакууму заморозить версии строк младше горизонта транзакций для продвижения счетчика. В результате новый номер для пишущей транзакции не выделяется, и Platform V Pangolin завершает OLTP‑запросы с ошибкой, чтобы не допустить потерю данных.

  64-битный счетчик снимает ограничение на предельный возраст новой транзакции 2^31 относительно горизонта, поэтому проблема не возникает.

• Возможность снизить риск деградации производительности при интенсивной транзакционной нагрузке с помощью настройки более редкого запуска процедуры заморозки и её планирования на период с меньшей нагрузкой.

Расширения plpgsql_check и pldebugger

Добавление расширений plpgsql_check и pldebugger помогает отладить и проконтролировать pl/pgsql-процедуры и функции.

• pldebugger — расширение, предоставляющее API для выполнения функций с возможностью остановки в заданной точке, пошаговым выполнением и просмотром значений переменных. Расширение интегрировано с решениями от pg_admin и dbeaver (утилиты предоставляют графический интерфейс для разработки с использованием возможностей расширения), а также позволяет использовать функции API прямо из psql, поскольку по факту это обычные SQL‑функции.

• plpgsql_check — это полноценный статический анализатор кода PL\pgSQL для PostgreSQL. Расширение предоставляет набор возможностей для анализа и профилирования функций и процедур, написанных на языке PL\pgSQL. Кроме того, он анализирует SQL внутри процедур и находит ошибки, которые обычно не обнаруживаются при выполнении команды CREATE PROCEDURE/FUNCTION. Можно контролировать уровни многих предупреждений и подсказок. Также можно добавить маркеры PRAGMA, чтобы отключить или включить многие аспекты, позволяющие скрывать уже известные сообщения. Или напоминать вернуться к ним для более глубокого анализа.

Расширение plsql-http

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

В подобных случаях может пригодиться расширение plsql-http — HTTP-клиент на уровне СУБД. Расширение позволяет обращаться к REST-сервисам из SQL-запросов.

Поддержка очередей сообщений

Поддержка очередей сообщений включает в себя расширения pgq, pgq-coop, демон pgqd. Очередь — это структура данных с последовательным доступом к объектам по методу «первым пришёл — первым ушёл». Чаще всего очереди сообщений используются для взаимодействия сервисов между собой, выполнения отложенных операций и т. д. Для организации очередей существуют специализированные решения: RabbitMQ, Platform V Synapse и другие.

Если у вас есть задача, для которой отлично подходит механизм очередей, но использовать отдельный сервис нет возможности, можно воспользоваться расширением pgq.

Обновления для администраторов/инфраструктуры

Посмотрим, что нового появилось для администраторов и инфраструктуры.

Возможность контролировать потребление вычислительных ресурсов (CPU, RAM)

Один из частых случаев в работе администратора баз данных — это когда неаккуратно написанный пользовательский запрос приводит к переполнению памяти на сервере и последующему перезапуску процессов экземпляра PostgreSQL из-за работы OOM Killer.

В версии Platform V Pangolin 6.1 появилась возможность контролировать потребление вычислительных ресурсов (CPU, RAM) клиентскими сессиями. Теперь при попытке выполнения неоптимально составленного запроса можно обеспечить защиту от недоступности или деградации функционирования при превышении ожидаемого потребления ресурсов СУБД каким-либо из процессов сессий.

Кроме того, теперь можно диагностировать случаи выполнения неоптимально составленных запросов не только по времени выполнения, но и по потреблению ресурсов.

Трассировка сессии

Каждый администратор СУБД сталкивался с необходимостью посмотреть, что же делает сессия.

Трассировка сессии — это удобный механизм включения/выключения отладочной информации, позволяющий без использования системного журнала и аудита точечно рассматривать приложение с максимальной детализацией взаимодействия с сервером СУБД. Инструмент позволяет получить необходимую для анализа информацию в зависимости от выбранного уровня детализации, например:

• выполняемые операторы;

• переменные привязки;

• блокировки, такие как LWLock и Lock;

• потребляемые всеми операциями ресурсы.

Отчёт о трассировке можно получить в понятном структурированном виде в формате текстового файла или гипертекста.

Адаптация инструмента миграции с оригинального PostgreSQL на Platform V Pangolin 6.1

Доработанная утилита pg_upgrade позволяет мигрировать с оригинального PostgreSQL на Platform V Pangolin. Доработка будет актуальна для решения задач перехода с оригинального PostgreSQL на Platform V Pangolin на существующих стендах, без переноса данных через сторонние средства. Другими словами — путём «конвертации» базы данных, что часто бывает необходимо в условиях ограниченности дисковых и серверных ресурсов.

Поддержка операционных систем Альт 10 и Astra Linux 1.7

Теперь полный список поддерживаемых ОС выглядит так:

• SberLinux 8;

• Альт 8 СП;

• Альт 9;

• Альт 10;

• РЕД ОС 7.3;

• Astra Linux 1.7;

• RHEL 7;

• RHEL 8.

Заключение

Мы рассмотрели основные обновления, которые появились в новой версии Platform V Pangolin. Они позволяют работать с большими объёмами данных ещё проще и удобнее. Начиная с релиза 6.1 продукт выпускается в различных редакциях (Enterprise, Standart, Trial). Подробнее об этом можно почитать тут.

И самое приятное — теперь пользователям не нужно платить за функциональность, которую они не используют. Дистрибутив можно приобрести с необходимым набором функциональности, в том числе и для целевого использования, например, совместно с 1С: Предприятие.