PgConf.Russia 2020

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

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

pg_repack является популярным инструментом для устранения bloat-a таблиц и индексов в постгресе. В большинстве случаев он отлично справляется с проблемой. Но как оказалось, в случае использования такой фичи постгреса как deferred ограничения, использование pg_repack либо сильно усложняется, либо становится невозможным. Я расскажу о том, как мы обнаружили эту проблему и опишу возможные способы ее решения - от встроенных средств постгреса до небольшого патча pg_repack.

PostgreSQL с момента старта Avito решает серьезные и важные задачи. Вокруг СУБД были построены основные компоненты архитектуры. За 10 лет проект активно развивался, изменилась архитектура и инфраструктура.

Как вступление, сделаю обзор: эволюции архитектуры и инфраструктуры PostgreSQL в Avito; успешно решенных вызовов.

В основной части расскажу о статусе PostgreSQL в Авито 2020: микросервисная архитектура; шардирование; проблемы коммуналок; DBaaS( Database discovery, управление доступом, failover, backup, archive, вопросы разделения ресурсов итд.); вопросы интеграции; эволюция команды.

В заключение поделюсь нашим wishlist/нерешенными вопросами.