PGConf.Russia 2022

В архитектуре PostgreSQL есть ряд особенностей, которые стоит учитывать не только при эксплуатации БД, но и в процессе проектирования схемы данных. Опытным пользователям PostgreSQL хорошо известен такой механизм как очистка/заморозка(vacuum). На просторах интернета есть большое количество материалов на тему внутреннего устройства, настройки и мониторинга. Множество полезных докладов было сделано на конференциях. Тем не менее, все еще происходят случаи переполнения счетчика транзакций(xid), казалось бы, в достаточно небольших БД. В этом докладе я расскажу об одном интересном, на мой взгляд, случае у нашего клиента. Поделюсь тем, как череда ошибок на разных этапах жизненного цикла БД, однажды привела к ее полной остановке более чем на неделю, wraparound-у, битым блокам, проблемам с обслуживанием и бессонным ночам в поисках решения. Локальная победа была достигнута - БД удалось восстановить, но история еще не закончена. Тем она и интересна.

В докладе я расскажу о новом методе для быстрого создания GiST индекса в PostgreSQL 14, какие проблемы были выявлены при добавление поддержки нового метода в PostGIS и как они будут решены в будущем. Так же в докладе будет обзор нововведений PostGIS 3.2.

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

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