title

text

Василий Бернштейн
Василий Бернштейн Postgres Professional Старший технический менеджер продукта
15:00 08 апреля
20 мин

Подход по ограничению прав доступа суперпользователя к чувствительным данным в реализации компании Postgres Pro

Требования к безопасности данных постоянно растут, и многие пользователи сегодня ищут способ ограничить доступ администраторов СУБД к конфиденциальным данным. Стандартным подходом в форках PostgreSQL является наложение дополнительных ограничений на postgres/superuser. Мы в Postgres Pro использовали принципиально другой подход.

Другие доклады

  • Александр Бурцев
    Александр Бурцев Skala^p Руководитель продукта Машина Баз Данных
    Алексей Власов
    Алексей Власов Skala-r Архитектор
    40 мин

    Аварийное восстановление Postgres Pro Enterprise в Машине Баз Данных Скала^р при помощи pg_probackup

    Мы поговорим об архитектурных решениях хранения резервных копий внутри Машины Базы Данных для Postgres (МБД.П). Сравним этот вариант СРК с реализацией подключения МБД.П к Машине Хранения Данных (МХД.О) c S3-интерфейсом. Расскажем о производительности двух этих решений и ограничениях. Обсудим функции, которые мы хотели бы видеть в Enterprise-версии pg_probackup для работы с СРК. Узнаем какие open-source-продукты уже реализуют часть этих функций, но проигрывают в деталях реализации и расскажем почему так происходит.

  • Леонид Борчук
    Леонид Борчук Яндекс Разработчик
    20 мин

    Планы выполнения в pg_stat_statements

    Есть много opensource (и еще больше проприетарных) форков pg_stat_statements, которые позволяют смотреть планы выполнения запросов:

    pg_stat_plans https://github.com/2ndQuadrant/pg_stat_plans
    pg_store_plans https://github.com/ossc-db/pg_store_plans
    pg_stat_monitor https://github.com/percona/pg_stat_monitor

    Все они мне чем-то не подошли и я написал свое https://github.com/postgredients/pg_stat_query_plans. Расскажу что и как сделал, и что хотелось бы добавить в оригинальный pg_stat_statements, чтобы мое расширение было не нужно

  • Владимир Ситников
    Владимир Ситников PostgreSQL JDBC maintainer Performance Engineer
    40 мин

    Механизм server-prepared statements в реализации PostgreSQL JDBC

    Доклад о базовых принципах serever-prepared statements, и о фактической реализации в PostgreSQL JDBC. Планируется рассмотреть как базовые механизмы, так и краевые случаи.

    Примерный список тем:

    1) Как задействовать server-prepared statements
    2) Какие настройки влияют на server-prepared
    3) server-prepared vs batch execution
    4) server-prepared vs concurrent executions (несолько разных подключений)
    5) server-prepared vs connection poolers
    6) Как понять, что server-prepared не работает
    7) binary/text parameter/result encoding
    8) server-prepared vs типы данных (грубо говоря, timestamptz vs timestamp vs text encoding)

  • Владимир Сердюк
    Владимир Сердюк Общество с ограниченной ответственностью «Кластерные технологии Софтпоинт» Ген. директор
    40 мин

    Распределение транзакционной нагрузки в кластере серверов СУБД

    Данный доклад представляет собой описание концепции и прототипа кластера СУБД, работающего по принципу Master-Master. Проблема синхронизации данных в таких системах ни в одном тиражном решении до сих пор не решена, поэтому масштабирование для OLTP-систем, где транзакционная нагрузка сильно превалирует над аналитической, решается до сих пор только усилением аппаратной части – добавить ядер/процессоров, добавить памяти, что зачастую бывает не самым рациональным решением. Напомню, что задача распределения аналитической нагрузки решается относительно просто с помощью создания дополнительных реплик и перенаправления запросов на чтение вне транзакций на другие реплики. В случае же транзакционной нагрузки, если применять аналогичный подход, возникают коллизии, например, типа «писатель-писатель», которые, если их не учитывать, могут привести к неверным данным в транзакциях. Концепция кластера распределённых вычислений на первый взгляд звучит просто: «Все запросы на изменение данных выполняются мгновенно на всех нодах (серверах кластера), а чтение выполняется локально». Специальный прокси-агент распарсивает запросы, и выполняет запросы на чтение локально, а запросы на изменение перенаправляются параллельно и асинхронно на все остальные ноды кластера. Все изменения выполняются в системе зеркальных распределённых транзакций , которыми управляет координатор распределённых транзакций. Несмотря на простоту концепции и формулировки, возникает множество технических проблем, которые нигде ранее не были решены. В случае высокого параллелизма и конкуренции ресурсов порядок запросов на разных серверах может изменяться, что, в свою очередь, может приводить к изменению состава данных и к распределенным взаимоблокировкам. Также возникают сложности с падением линейной скорости примитивных операций. И, не решив проблемы оптимизации, данное решение сразу не подойдет для большинства систем. Одними из целевых показателей промышленного решения будет являться подключение до 20-и серверов в кластер с линейной просадкой времени операций не более чем на 10 % .

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