PGConf.Russia 2022

Одной из задач современной базы данных является задача хранения больших значений. Само по себе хранение больших значений не представляет собой особых сложностей, но оперирование такими значениями или полями представляет собой нетривиальную задачу. PostgreSQL может предложить несколько вариантов сохранения больших значений, но все они обладают теми или иными недостатками. Как ответить на этот вызов? Наш ответ в докладе - как хранить большие и сложные значения и как с ними оперировать.

Мы ранее рассказывали про внутренне устройство Авито, где и как хранятся ваши объявления, как эти объявления попадают в поиск. За последние 3-4 года очень много изменилось в Авито, мы избавились от использования логической репликации, использования standby для читающей нагрузки, практически отказались от хранимых процедур, избавились от самописного failover решения, мигрировали все объявления в шардированную базу данных, практически "распилили" монолит и перешли на разработку в микросервисах. Расскажу о причинах такого развития, проблемах с которыми столкнулись, и текущем положении дел.

Поговорим про то как можно изменить записи в БД без апдейтов, спустимся на самый нижний из всех возможных уровней, посмотрим, что может случиться, если вносить изменения в файлы данных в разных режимах работы.

Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.