title

text

Руслан Рангулов
Руслан Рангулов ПАО «Софтлайн» Инженер отдела Премьер Сервисов по бизнес-приложениям
18:30 01 октября
40 мин

Проверка на прочность. Утилиты для анализа и оптимизации PostgreSQL

Внедрение и эксплуатация PostgreSQL могут быть сложными задачами, особенно когда речь идет о поддержании здоровья и производительности базы данных. Однако, использование специализированных утилит для проверки состояния системы позволяет облегчить их решение. В ходе выступления мы поговорим об инструментах, которые помогают администраторам и разработчикам эффективно конфигурировать и искать проблемы PostgreSQL, рассмотрим утилиты проверки баз данных, такие как postgresqltuner, postgres-checkup, pgdsat, PG Collector, а также поделимся собственным опытом и подходами к поиску проблем, возникающих при внедрении и эксплуатации PostgreSQL.

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

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

  • Евгений Александров
    Евгений Александров ООО ТЦР Системный инженер
    40 мин

    Generic plan и потребление памяти запросов к секционированным таблицам

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

  • Валерий Попов
    Валерий Попов Postgres Professional Руководитель отдела ИБ
    40 мин

    Безопасность отрасли СУБД-строения в России на примере PostgreSQL

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

  • Андрей Бородин
    Андрей Бородин Yandex Cloud Postgres Hacker
    40 мин

    Необычные возможности системы резервного копирования WAL-G

    Типичный рабочий процесс любого решения для резервного копирования относительно прост: настройте архив для восстановления на определенный момент времени, создайте расписание ротации резервных копий и время от времени проверяйте процесс восстановления. Однако WAL-G предоставляет несколько полезных функций, которые могут пригодиться администраторам баз данных в критической ситуации:
    1. Настройка троттлинга для изменения обычного режима "дешевое резервное копирование - быстрое восстановление".
    2. Расширенные возможности мониторинга согласованности для обеспечения надёжности резервных копий.
    3. Catchup для быстроого сокращения лага и другие функции кластера высокой доступности.
    4. Различные методы извлечения набора изменений для инкрементного резервного копирования. Кроме того, я расскажу о планах на будущее, включая создание согласованных резервных копий для шардированных кластеров и использование расширенных возможностей S3.

  • Алена Рыбакина
    Алена Рыбакина Postgres Professional разработчик
    40 мин

    Адаптивный исполнитель запросов

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