Архитектуры с Postgres в продакшне

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

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

Автоматическое инкрементальное обновление материализованных представлений

Материализованное представление служит для хранения результатов запросов определения представления в БД, чтобы добиться более быстрого ответа на запрос. Однако данные в представлении устаревают после изменения базовых таблиц. Следовательно, для поддержания актуальности содержимого необходимо обновлять представление. В PostgreSQL есть команда REFRESH MATERIALIZED VIEW для обновления материализованного представления, но эта команда вычисляет его содержимое с нуля, что неэффективно в случаях, когда изменяется только небольшая часть базовой таблицы.

Инкрементальное обновление представлений (IVM) - это метод эффективного обновления материализованных представлений, который вычисляет и применяет к материализованным представлениям только инкрементальные изменения вместо повторного вычисления. Эта функциональность требуется для быстрого обновления материализованных представлений, но еще не реализована в PostgreSQL.

Поэтому мы разработали IVM для PostgreSQL и предлагаем реализовать его в качестве основной функции. Патч сейчас обсуждается в списке рассылки hackers. Наша реализация делает возможным автоматическое инкрементальное обновление материализованных представлений при изменении базовой таблицы. Вам не нужно писать собственную триггерную процедуру для обновления представлений. После продолжительной работы нашей команды текущая реализация IVM поддерживает некоторые возможности аггрегации, подзапросы, соединение одной таблицы (self-join), внешние соединения (outer join) и CTE (предложения WITH) в запросе определения представления. Результат оценки производительности с использованием запросов TPC-H показывает, что наша реализация IVM может обновлять материализованное представление в 200+ раз быстрее, чем повторное вычисление с помощью команды REFRESH.

В данном докладе мы опишем нашу реализацию IVM и ее возможности.

Бесшовная оптимизация запросов PostgreSQL, версия 2.0

Существует два способа анализировать SQL-запросы:

1. На макроуровне: в этом случае мы анализируем рабочую нагрузку как единое целое (есть три основных подхода: использование метрик из pg_stat_statements или аналогичного модуля, анализ логов с помощью pgBadger или другого похожего решения и запрос выборки в представлении pg_stat_activity).

2. На микроуровне: в этом случае мы погружаемся в детали исполнения одного конкретного запроса (тут главную роль играет команда EXPLAIN).

Между этими двумя подходами есть немало "белых пятен", которые обнаруживаются с ростом нагрузки. Главные проблемы:

• Нужно переключаться между макро- и микроуровнем без больших накладных расходов.
• Требуется надёжная проверка гипотез относительно возможных оптимизаций.
• Есть необходимость минимизации рисков при развёртывании новой функциональности.

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

В рамках данного мастер-класса мы разберёмся, как можно настроить процесс беспроблемной и бесшовной оптимизации SQL-запросов в вашей организации: а) какие инструменты следует выбрать в вашем конкретном случае? б) как эффективно заполнить вышеупомянутые пробелы в сфере анализа запросов?

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

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

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

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