Всё о безопасности PostgreSQL

В PostgreSQL реализованы различные уровни безопасности. Данный доклад посвящен всем доступным техникам обеспечения безопасности, используемым в PostgreSQL 13. Мы разберём, как обеспечить безопасность на стороне клиента (LibPq, JDBC) и на стороне сервера. В нем будут затронуты все поддерживаемые методы аутентификации, а также плюсы и минусы всех этих методов. Ниже приведены некоторые подтемы данного доклада:

• Введение в криптографию.
• SSL, TLS, GSSAPI и OpenSSL.
• Шифрование на стороне клиента.
• Обеспечение безопасной аутентификации.
• Защита данных на диске.
• Безопасность резервного копирования и базового резервного копирования.
• Обеспечение безопасности репликации.
• Роли и привилегии внутри базы данных.

Важно знать обо всех уровнях обеспечения безопасности, включая (1) безопасность на уровне сети (2) на уровне диска (3) на уровне строки, (4), на уровне столбца. В этом докладе мы поговорим обо всех вышеперечисленных аспектах обеспечения безопасности, а также обсудим конкретные кейсы и приведём несколько примеров из реальной практики.

Шардман - естественный подход к шардингу в PostgreSQL

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

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

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

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

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

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

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

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

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

NORM - фреймворк без ORM

Хорошо известно, что, хотя производительность базы данных велика и каждый запрос выполняется за миллисекунды, общее время отклика приложения может быть медленным, поэтому пользователи могут долго ждать ответа. Мы знаем, что проблема не в базе данных, а в том, как разработчики приложений с ней общаются. В частности, речь идет об ORM - Object-Relational Mappers. Разработчики баз данных ненавидят их, но разработчики приложений любят их, потому что они позволяют разрабатывать приложения без каких-либо знаний о внутреннем устройстве СУБД. В результате производительность системы часто оказывается неприемлемо низкой.

Единственный способ изменить это - предоставить разработчикам приложений такой же простой в использовании инструмент, как ORM, но позволяющий избежать распространенных ошибок ORM. Вот почему мы разработали NORM - No-ORM Framework. Во время этой презентации мы рассмотрим примеры кода из репозитория https://github.com/hettie-d/NORM и узнаем, как создавать «транспортные объекты» для эффективной передачи данных между приложениями и базами данных.