Оптимизация производительности PostgreSQL

PostgreSQL - одна из лидирующих технологий среди СУБД с открытым исходным кодом. По умолчанию конфигурация PostgreSQL не подходит для конкретной рабочей нагрузки. Эта дефолтная конфигурация PostgreSQL рассчитана на то, чтобы пользователь мог запустить Postgres на любой системе, используя минимум ресурсов. Следовательно, установленный на высокопроизводительной машине экземпляр PostgreSQL в конфигурации по умолчанию не даст оптимальной производительности, потому что машина настроена так, чтобы использовать все доступные ресурсы. PostgreSQL предоставляет возможности для настройки СУБД под вашу рабочую нагрузку и характеристики вашего оборудования. Помимо PostgreSQL также можно настроить ядро Linux для оптимизации работы СУБД под нагрузкой. В рамках данного мастер-класса мы научимся настраивать некоторые параметры PostgreSQL и посмотрим, какой эффект даёт такая настройка. Однако основной акцент мы сделаем на том, как сконфигурировать Linux для улучшения производительности Postgres. Поскольку в ядре Linux так много параметров, которые можно настроить для более оптимальной работы PostgreSQL, я также поделюсь результатами сравнительного тестирования для разных значений некоторых параметров Linux.

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

• Как (не) работают оценки
• Как мы справились с миграцией выражений BULK COLLECT
• Почему мы избавились от выражений REF CURSOR
• Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
• Как мы справились с иерархическими запросами и детализацией иерархии

Над пропастью WAL-G

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

В докладе я расскажу историю построения системы снятия и верификации бэкапов в отдельно взятой компании. Обсудим вопросы выбора инструмента по работе с резервными копиями, адаптации к изменяющимся реалиям, проблемы облачных хранилищ и безграничные возможности open-source коллаборации.

Приглашаю вас в увлекательное путешествие длиной 2 года.

Сетевой фильтр PostgreSQL для EnvoyProxy

Как вы осуществляете мониторинг Postgres? Какую информацию вы собираете и насколько она помогает решать возникающие проблемы? Что если вам хочется или нужно логировать все запросы? Высоконагруженные базы данных могут выйти из строя при таком подходе.

В OnGres мы стараемся сделать СУБД PostgreSQL более прозрачной для мониторинга. Поэтому мы вместе с командой Tetrate работали над Сетевым фильтром Envoy для PostgreSQL, расширением, призванным обеспечить и улучшить прозрачность для мониторинга входящего трафика в кластерной инфраструктуре. Это бесплатное расширение с открытым исходным кодом доступно для всех участников сообщества. Вы можете использовать его везде, где пользуетесь Envoy. Оно позволит вам автоматически собирать статистику и устранять проблемы сетевого трафика. Данный доклад обеспечит глубокое погружение в декодирование протокола PostgreSQL и прокси-фильтры Envoy. В рамках этого выступления также будут рассмотрены все возможности сетевого фильтра, его развёртывание и использование в любом окружении.

Полезные ссылки:

• https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/postgres#arch-overview-postgres
• https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/