PGConf.Russia 2022

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

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

Расширение plv8 очень недооценено, хотя оно позволяет значительно упростить разработку для ряда задач. Уже год как мы используем его в наших проектах. Но главная причина низкой популярности – сложность сборки расширения, к тому же требующей много трафика и места на диске для временных файлов. Поэтому мы решили собирать plv8 сами и поставлять готовые бинарники (не только поставлять нашим заказчикам, а вообще выложить в открытый доступ). Сначала просто выложили бинарные файлы на github. Потом сделали докер-образ Postgres с уже установленным plv8 на основе Debian. Образ получился тяжеловатым, поэтому стали смотреть в сторону alpine, но сборка под alpine оказалась сложнее, чем мы предполагали. Я расскажу, с какими трудностями мы столкнулись и как их преодолели. Так же кратко расскажу, для каких задач хорошо подходит plv8 и как сделать процесс разработки удобнее. И, конечно, поделюсь ссылками на наши докер-образы для последних версий Postgres 13 и 14, действительно компактные и открытые для любого использования.

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