title

text

Андрей Лепихов
Андрей Лепихов Postgres Professional Программист
15:00 01 марта
22 мин

Постгрессовый планнер с памятью

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

Видео

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

  • Иван Фролков
    Иван Фролков Postgres Professional инженер-консультант
    22 мин

    Constraints или о том, как попытаться спокойно жить

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

  • Андрей Фефелов
    Андрей Фефелов Mastery.pro Технический директор
    22 мин

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

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

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

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

  • Álvaro Hernández
    Álvaro Hernández OnGres Founder
    Fabrízio Mello
    Fabrízio Mello OnGres Inc Разработчик PostgreSQL
    45 мин

    Сетевой фильтр PostgreSQL для EnvoyProxy

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

    В OnGres мы стараемся сделать СУБД PostgreSQL более прозрачной для мониторинга. Поэтому мы вместе с командой Tetrate работали над Сетевым фильтром Envoy для PostgreSQL, расширением, призванным обеспечить и улучшить прозрачность для мониторинга входящего трафика в кластерной инфраструктуре. Это бесплатное расширение с открытым исходным кодом доступно для всех участников сообщества. Вы можете использовать его везде, где пользуетесь Envoy. Оно позволит вам автоматически собирать статистику и устранять проблемы сетевого трафика. Данный доклад обеспечит глубокое погружение в декодирование протокола PostgreSQL и прокси-фильтры Envoy. В рамках этого выступления также будут рассмотрены все возможности сетевого фильтра, его развёртывание и использование в любом окружении.

    Полезные ссылки:

  • Amit Kapila
    Amit Kapila Fujitsu Senior Director
    45 мин

    Как будет развиваться логическая репликация?

    Логическая репликация в PostgreSQL доступна начиная с версии 10.0, и с каждым новым релизом она улучшается. Мы начнём доклад с обсуждения базовой архитектуры логической репликации в PostgreSQL, а затем перейдём к различным способам её использования.

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

    Мы также остановимся на других крупных разработках в области логической репликации, которые позволят осуществлять потоковую передачу транзакций в заранее заданное время. Это позволит реализовать логическую репликацию без конфликтов. Это также можно будет использовать для масштабирования чтения. Благодаря протоколу 2PC мы сможем убедиться, что реплики получили все данные, закоммиченные на мастере. Теперь мы можем спроектировать систему, где определённые узлы являются владельцами некоторого набора таблиц. Так мы всегда сможем получить данные этих таблиц с этих узлов, а также установить некий внешний процесс для учитывающей это маршрутизации для операций чтения.

    В конце доклада мы перечислим новые улучшения, связанные с логической репликацией и вошедшие в недавние релизы PostgreSQL.