PGConf.Russia 2022

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

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

Книга. Обычно читатель видит лишь конечный продукт — то, что напечатано на бумаге или открывается на экране монитора. А я предлагаю посмотреть изнанку своего недавно вышедшего труда «PostgreSQL изнутри». Приходите, если вам интересно, зачем автору писать скрипты, менять исходный код Постгреса и программировать картинки.

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