Кейсы использования логической репликации для восстановления данных в PostgreSQL 10

В Avito объявления хранятся в базах данных PostgreSQL. При этом уже на протяжении многих лет активно применяется логическая репликация. С помощью неё успешно решаются вопросы роста объема данных и количества запросов к ним, масштабирования и распределения нагрузки, доставки данных в DWH и поисковые подсистемы, межбазные и межсервисные синхронизации данных и пр.

Но ничего не бывает "бесплатно" - на выходе мы имеем сложную распределенную систему. Отказы оборудования - это норма, к ним нужно быть готовым. Можно найти много примеров конфигурации логической репликации и success stories ее использования, при этом практических примеров по восстановлению после аварий почти нет, не говоря уже про готовые инструменты. За годы эксплуатации репликации PgQ мы наработали обширный опыт, многое переосмыслили, реализовали собственные надстройки и расширения для восстановления и согласования данных после аварий в распределенных системах обработки данных.

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

Как мы распрощались с MongoDB и перешли на PostgreSQL

В своем докладе я поделюсь опытом переноса, конвертацией NoSQL-данных в реляционный вид и расскажу, как нам удалось ускорить приложение в 2 раза.

Изначально для хранения данных мы использовали PosgtgreSQL и MongoDB. На практике мы выяснили, что такое разделение крайне неудобно. Мы тратили уйму времени и внимания.

Расскажу, как с помощью mosql мы перенесли данные из MongoDB в PostgreSQL. Теперь все данные могут быть получены одним запросом, а схема таблиц обеспечивает консистентность данных.

Как сохранить статистику при мажорном обновлении, и что за это бывает

Ни для кого не секрет, что статистика не переносится при мажорном обновлении. Для небольших и не сильно нагруженных баз это не проблема, можно быстро собрать новую статистику. Но у нас есть базы объемом порядка 5ТБ и нагрузкой порядка 100k rps, для которых это стало большой проблемой: взлетая без статистики, реплики даже не могли накатывать WAL. В своем докладе расскажу, на какие хитрости мы пошли, чтобы произвести обновление этих баз в условиях требований 100% доступности read only, о том, какие ошибки допустили, и о том как эти ошибки мучительно исправляли. Результатом этих ошибок стало расширение pg_dirty_hands, в котором мы будем собирать различные хаки, которые можно назвать «фол последней надежды».

PostGIS и системы реального времени

PostGIS - расширение для Postgres, приносящее в него пространственные типы данных, методы их быстрой индексации и функции для выполнения геометрических операций над ними.

В типичном сценарии использования PostGIS применяют для выбора из большого массива статичных данных небольшого подмножества. В этом докладе будут рассмотрены проблемы, возникающие при необходимости работы с большими динамическими потоками данных, и подходы к их решению, на реальных примерах, встретившихся при разработке бекенда сервиса заказа такси Juno.