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

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

Сетевой фильтр 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/

Как переносить данные из Oracle в PostgreSQL и обратно

Использование PostgreSQL стало обычным делом во множестве организаций. В большинстве случаев PostgreSQL устанавливают в дополнение к уже имеющимся СУБД Oracle, и довольно скоро возникает закономерный вопрос: как перебрасывать данные из Oracle в PostgreSQL и наоборот? Давайте перенесёмся в прошлое, в март 2001, когда вышло новое расширение SQL стандарта, определившее общие принципы создания API для управления внешними данными: SQL/MED (ISO/IEC 9075-9:2008). Сообщество PostgreSQL довольно быстро создало фреймворк для использования рекомендаций стандарта в виде так называемых обёрток сторонних данных (foreign data wrappers). Это случилось в 2011 с выходом PostgreSQL 9.1. С тех пор число обёрток сторонних данных постоянно растёт. Сегодня благодаря им PostgreSQL может интегрировать данные почти из любого внешнего источника, будь то обычные файлы, другие реляционные СУБД или даже неструктурированные данные. В рамках этого доклада мы рассмотрим обёртку сторонних данных для Oracle и то, как её можно использовать для получения данных из Oracle в PostgreSQL. Однако обратное тоже верно: данные из PostgreSQL также можно отправить в Oracle, и это может быть важно для соблюдения требований. Обещаю, что в докладе будет две части: слайды и много демонстраций.

Повреждение данных: как его избежать, обнаружить и обеспечить восстановление

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