Как переносить данные из 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

PostgreSQL - зрелая реляционная СУБД, её история насчитывает более 30 лет. За последний год её оптимизатор запросов стал лучше, и обычно он создаёт хорошие планы выполнения запросов.

Но всегда ли эти планы выполнения запросов хороши? Чтобы оптимизировать процесс их создания, приходится пользоваться предположениями, чтобы планы выполнения запросов создавались достаточно быстро. Некоторые из этих предположений проверить довольно легко (например, актуальность статистики), другие сложнее (например, надо убедиться, что правильные индексы были созданы), а некоторые проверить почти невозможно (например, убедиться, что выборки достаточно репрезентативны даже для ассиметричного повторного секционирования данных). Сегодня из-за всех этих предположений администратор базы данных не всегда осознаёт, что он мог бы добиться значительного улучшения производительности.

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

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

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

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

Как обфусцировать базу в Postgres для задач нагрузочного тестирования веб-приложений

Postgres - отличная база данных для высоконагруженных веб-приложений. В свою очередь для таких веб-приложений периодически встает задача нагрузочного/стресс тестирования. Кроме очевидных сложностей: эмуляции рабочего окружения близкого к продуктовому и генерации трафика есть задача подготовки базы данных для тестового окружения. В эпоху борьбы за приватность персональных данных (152-ФЗ, GDPR, HIPAA) использование базы с прода выглядит плохой идеей. Выход один - обфусцировать данные.

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

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