PgConf.Russia 2019

Иной раз есть большое желание вернуть базу данных в прошлое, на день, два или несколько дней. Причины самые разные, но чаще всего: посмотреть, что поменялось, приложение после обновления повело себя некорректно, повеление свыше сделать как вчера. Классический способ все знают - держим опорные резервные копии и наборы WAL-логов для возможности восстановления на произвольный момент. И такой способ - головная боль для DBA/администраторов и быстро не делается. Безусловно, есть способы несколько оптимизировать этот процесс, но без downtime это не обходится. PostgresPro предлагает новый способ - снапшоты или снимки состояния БД и возможность вернуться к ним.

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта. Доклад будет интересен разработчикам, которые хотят избежать проблем при работе с Postgres и полезен DBA, которые хотят узнать с какими трудностями сталкиваются клиенты их базы данных.

Доклад посвящен продолжению проекта по переводу нашей системы электронного документооборота «Приоритет» с MS SQL на Postgres. Будут затронуты технические решения и моменты переписывания с T-SQL на plpgsql, оптимизации результативного кода и переноса данных. Дополнительно рассмотрим аспекты тестирования производительности с точки зрения поиска «плохого кода» pgplsql как кандидата на оптимизацию. Основная задача презентации - ответить на вопрос: "У нас так на T-SQL - как это перенести на PG?". Доклад предназначается для начинающих разработчиков на Postgres и является продолжением предыдущего доклада сделанного на конференции в 2017 (https://youtu.be/v6_4Szr8t14).

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

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