Основные моменты конференции Europe 2024 PostgreSQL

В этом году конференция премиум-класса по PostgreSQL проходила в Афинах, Греция, с 22 по 25 октября. Не говоря уже о хорошей афинской погоде и культурном аспекте, конференция также произвела фурор.

Конференция охватила широкий спектр тем, начиная от обсуждения внутренних аспектов под руководством ведущих разработчиков и заканчивая примерами из практики конечных пользователей как небольших компаний, так и крупных транснациональных корпораций и правительственных организаций, которые ведут свой бизнес на PostgreSQL. И все это в рамках 60 сессий, одного дня расширенного обучения, а также обычных коридорных и социальных треков.

Если вы пропустили мероприятие и его выступления, не волнуйтесь - теперь вы можете посмотреть все это по запросу. При таком количестве выступлений настоящая проблема - выбрать, что пропустить, поэтому мы немного покопались в памяти, чтобы выбрать, что лучше посмотреть в первую очередь.

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

Очень важной темой, которая не дает покоя пользователям, является то, как PostgreSQL назначает пользователей, роли и разрешения. Не бойтесь, так как статья «Распутывая паутину разрешений PostgreSQL»
поможет разобраться с ними.

PostgreSQL в производстве; всегда полезно проверить, как это делают крупные компании. В статье «Identity at Scale; How Okta uses Postgres» («Идентификация в масштабе; как Okta использует Postgres») компания Okta делает много выводов. Они раскрывают целый ряд операционных проблем, таких как:

• Операционные процедуры базы данных: резервное копирование/восстановление, управление версиями, сохранение данных и наблюдаемость для 650+ кластеров.
• Определение размера: когда и как увеличивать отдельные кластеры.
• Одна и та же база данных, разные сценарии использования: полнотекстовый поиск, базовый CRUD, управление трафиком с точки зрения базы данных и проблемы, с которыми мы сталкиваемся при решении непредсказуемых задач.
• Один и тот же движок базы данных, разные развертывания: тактика и практика развертывания, как работать с много- и одноарендными развертываниями, производительность и операционные последствия таких сценариев.
• Топология базы данных: как наши кластеры проектируются с учетом потребностей клиентов и отказоустойчивости.

Далее - «Окончательное руководство по обновлению вашей установки PostgreSQL». Хотя 17-я версия уже вышла, большинство пользователей Postgres не будут обновляться в ближайшее время. Большинство даже не будет работать с новыми версиями, и правда в том, что никто не стремится обновляться (ну, обновлять любое критически важное программное обеспечение, не только PostgreSQL), когда все работает гладко. Просто проверьте, сколько людей все еще используют Java версии 8, когда последняя версия уже 23. Так что это универсальная проблема, и основной страх, который останавливает людей от обновления, - это страх того, что в производстве все пойдет наперекосяк. В этой сессии рассказывается о том, почему нам нужна специальная процедура для обновления между основными версиями, как этого можно добиться и какие проблемы могут возникнуть.

pg_ivm - Расширение для быстрого обновления материализованного представления. pg_ivm - это модуль расширения, который быстро обновляет материализованное представление, используя технику под названием Incremental View Maintenance (IVM), которая вычисляет и применяет только инкрементные изменения к материализованному представлению без перестройки всего представления.

Мы рассказывали об этом расширении в статье «pg_ivm - Materialised Views On Steroids» еще в 2022 году. Вкратце суть его в том, что материализованные представления обновляются сразу после изменения базовой таблицы, что дает ответ на старую проблему, когда обновлять материализованное представление. Сессия рассказывает о том, как его настроить и использовать.

Наконец, «Проводной протокол». Проводной протокол Postgresql позволяет переносить код приложений, написанный для другой СУБД, в Postgres, как мы рассматривали в статье «Превратите свою базу данных SQLite в сервер». Там мы обнаружили, что:

libSQL «режим сервера» (sqld) обеспечивает доступ к базам данных на основе SQLite с помощью Postgres и сетевых протоколов HTTP, что позволяет разработчикам использовать базу данных SQLite в качестве сервера, и эта интеграция должна стать стимулом для SQLite.

В сочетании с

Babelfish, набор расширений, предоставляющих возможности T-SQL и порт-слушатель Tabular Data Stream (TDS) в качестве дополнения к PostgreSQL. Он поддерживает диалект SQLServer, T-SQL и такие важные функции, как точки сохранения, хранимые процедуры, вложенные транзакции и т. д.

и MangoDB (теперь FerretDb):

которая действует как прокси без статического состояния, используя протокол wire, который преобразует запросы протокола MongoDB в SQL, используя PostgreSQL в качестве движка базы данных. Он совместим с драйверами MongoDB и должен работать как замена MongoDB во многих случаях.

Сессия представляет собой экскурс по протоколу, начиная с основ аутентификации и выполнения запросов, заканчивая протоколом COPY, возможностями репликации и предполагаемым будущим развитием.

Этот список ни в коем случае не является исчерпывающим; есть еще много замечательных докладов. Так что не торопитесь и погрузитесь в конференцию, просмотрев его