title

text

Александр Коротков
Александр Коротков Postgres Professional Руководитель разработки
: декабря
45 мин

Узкие места PostgreSQL

Хорошо, когда база работает предсказуемо. Если сервер не справляется с нагрузкой, то только знай добавляй процессорные ядра, терабайты оперативной памяти и миллионы IOPS'ов – всё станет хорошо. Гораздо неприятнее, когда у сервера куча свободных ресурсов, но база данных всё равно тормозит. И особенно обидно, когда при нагрузочном тестировании всё работало как часы, а при реальной нагрузке такого же объёма – встаёт колом.

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

Слайды

Видео

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

  • Julien Rouhaud
    Julien Rouhaud Разработчик
    45 мин

    HypoPG 2: поддержка гипотетического секционирования в PostgreSQL

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

  • Рустам Абдрахимов
    Рустам Абдрахимов ООО Форс-Телеком Главный эксперт
    Александр Любушкин
    Александр Любушкин ООО "ФОРС Телеком" Технический директор
    22 мин

    Live Universal Interface (LUI) - средство коллективной разработки WEB-интерфейса прикладных систем для Postgres

    В нашей компании разработан программный продукт Live Universal Interface (LUI), - инструмент для быстрого создания и изменения унифицированных экранных форм для WEB-браузеров без компиляции программного кода, при этом достаточно знать только SQL.

    LUI нацелен на сегменты В2В, В2G, G2C и B2C, и предназначен для использования в системах биллинга, управления финансами, учета и контроля производства, где необходимо решать, в первую очередь, функциональные задачи, а не демонстрировать излишние графические элементы.

    Коллективная разработка обеспечивается хранением всего объема наработок в базе данных, которая может располагаться как на корпоративном сервере, так и в «облаке» на сторонней площадке.

  • Андрей Бородин
    Андрей Бородин Яндекс Разработчик
    45 мин

    DIY индекс

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

  • T
    Tatsuro Yamada NTT Comware Ведущий специалист по базам данных
    22 мин

    Настройка автопланировщика с использованием цикла обратной связи

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

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

    Расширение содержит три фичи:

    1. Автоматическая оптимизация плана запроса за счет неоднократного возвращения информации о ходе выполнения запроса в планировщик.
    2. Сохранение всех выработанных при оптимизации планов запросов в таблицу истории.
    3. Создание и сохранение хинтов оптимизатора с тем, чтобы иметь возможность воспроизвести выработанные планы исполнения запросов в процессе настройки.

    Я верифицировал эффективность pg_plan_advsr путем запуска join order benchmark (JOB) на PG 10.4, в ходе чего наблюдалось сокращение времени исполнения запроса до 50% от первоначального. Таким образом, расширение будет полезно пользователям, который хотят настроить планировщик для OLAP и пакетной обработки данных.

    В ходе презентации я расскажу о следующие моментах:

    • Принципы построения и архитектура pg_plan_advsr.
    • Подробная информация о результатах тестирования JOB.
    • Направления улучшений в будущем.
    • Совместное использование расширений aqo и pg_plan_advsr together (экспериментальное).