Python для PostgreSQL: как его использовать и преуспеть в этом?

В рамках данного мастер-класса мы посмотрим, как обеспечить бесперебойную связь между Python и PostgreSQL. На практических примерах мы разберём, как подключиться к серверу, обеспечить обмен данными, управлять уведомлениями и транзакциями, передавая параметры безопасно и в понятной форме.

Мы рассмотрим psycopg2, наиболее часто используемую библиотеку-адаптер PostgreSQL для Python, а также анонсируем предстоящий релиз psycopg3: что останется прежним, что изменится, как лучше реализовать программу на Python, чтобы использовать PostgreSQL по максимуму.

Жизнь DBA в онлайн-кинотеатре "OKKO"

Okko — один из самых больших легальных онлайн-кинотеатров в России. В нашем каталоге представлено 60 000 фильмов, мультфильмов и сериалов. С момента запуска сервис посетили более 20 млн пользователей. Ежемесячная аудитория составляет 2,8 млн человек Все эти цифры говорят о надежном высоконагруженном сервисе.

В своем докладе я, как DBA, буду говорить преимущественно о базах данных (PostgreSQL, Cassandra, Redis), которые используются в компании. Подробно рассмотрим PostgreSQL на темы высоких нагрузок, мониторинга, оптимизации, резервного копирования и восстановления.

Автоматическое инкрементальное обновление материализованных представлений

Материализованное представление служит для хранения результатов запросов определения представления в БД, чтобы добиться более быстрого ответа на запрос. Однако данные в представлении устаревают после изменения базовых таблиц. Следовательно, для поддержания актуальности содержимого необходимо обновлять представление. В PostgreSQL есть команда REFRESH MATERIALIZED VIEW для обновления материализованного представления, но эта команда вычисляет его содержимое с нуля, что неэффективно в случаях, когда изменяется только небольшая часть базовой таблицы.

Инкрементальное обновление представлений (IVM) - это метод эффективного обновления материализованных представлений, который вычисляет и применяет к материализованным представлениям только инкрементальные изменения вместо повторного вычисления. Эта функциональность требуется для быстрого обновления материализованных представлений, но еще не реализована в PostgreSQL.

Поэтому мы разработали IVM для PostgreSQL и предлагаем реализовать его в качестве основной функции. Патч сейчас обсуждается в списке рассылки hackers. Наша реализация делает возможным автоматическое инкрементальное обновление материализованных представлений при изменении базовой таблицы. Вам не нужно писать собственную триггерную процедуру для обновления представлений. После продолжительной работы нашей команды текущая реализация IVM поддерживает некоторые возможности аггрегации, подзапросы, соединение одной таблицы (self-join), внешние соединения (outer join) и CTE (предложения WITH) в запросе определения представления. Результат оценки производительности с использованием запросов TPC-H показывает, что наша реализация IVM может обновлять материализованное представление в 200+ раз быстрее, чем повторное вычисление с помощью команды REFRESH.

В данном докладе мы опишем нашу реализацию IVM и ее возможности.

Постгрессовый планнер с памятью

Постгрес умеет строить оптимальные планы запросов для большинства практических случаев. Однако иногда, по объективным причинам, для сложных запросов или из-за ошибок в самом планнере, он может ошибаться и выдавать неоптимальный план. Из-за этого, время выполнения такого запроса может возрастать в десятки раз. Если запрос выполняется часто, то из раза в раз этот запрос выполняется дольше, чем мог бы, и СУБД в целом выдает меньший TPS. Если планнер сможет фиксировать свои ошибки и учитывать их при последующем планировании того же запроса, то это позволит улучшать характеристики СУБД в процессе её эксплуатациии. Мы представляем результаты разработки расширения для СУБД PostgreSQL, которое хранит историю выполнения запросов и реализует рекомендательный механизм для планнера. Показываем, как знание о ранее выполнявшихся запросах позволяет улучшить выполнение последующих.