Этот номер объективно совсем не юбилейный. А субъективно он очень даже юбилейный: это моя 100-я публикация на хабре :)

Aurora DSQL

Эта Аврора наделала шуму. Откликов на анонс много. Люди говорят о сомнительной (но громко заявленной) совместимости с Postgres. Официальный анонс был такой:

AWS Announces New Database Capabilities Including Amazon Aurora DSQL- the Fastest Distributed SQL Database

Мэт Гарман (Matt Garman), гендир AWS, объявил на сборище re:Invent в Лос-Анджелесе в присутствии 60 тыс. очных и 400 тыс (это ж почти полмиллиона!) онлайновых гостей о принципиально новой, геораспределённый СУБД Aurora DSQL. Более того: это была его инаугурационная гендирская речь. Так что ставки высоки. Видео есть на сайте re:Invent. Документация Aurora DSQL здесь.

Это гео‑распределённая SQL‑база с доступностью 99.999%, практически неограниченной масштабируемостью, строгой согласованностью и нулевыми заботами об управлении инфраструктрой.

Главная целевая аудитория — те, у кого приложения, обслуживающие миллионы клиентов по всему Земному Шару.

У СУБД архитектура active‑active (т. е. примерно мультимастер), и все транзакции, записанные в одном регионе, согласованно отображаются на другие регионы. И вообще утверждается, что удалось избавиться от компромиссов «или‑или» (trade‑offs): она И быстрая, И надёжная. Для этого пришлось «переизобрести» архитектуру — отвязать обработку транзакций от хранения. Обещано, что чтение и запись будут в 4 раза быстрее, чем у конкурентов.

Aurora DSQL при синхронизации узлов использует Amazon Time Sync Service на каждом экземпляре Amazon Elastic Compute Cloud (EC2), а там всё привязано к атомным часам, связь с которыми через спутники. Этот же механизм используется для работы глобальных таблиц DynamoDB.

DSQL Vignette: Aurora DSQL, and A Personal Story

В своём блоге Марк Брукер (Marc Brooker), он работает в AWS в Сиэттле, пишет, что, мол, да, DSQL совместима с PostgreSQL, но в том смысле, что предоставляет солидное подмножество постгресового SQL. Он напоминает, что у DSQL бессерверная (serverless) архитектура. И над бессерверным вариантом Марк как раз работал, начиная с 2020. Об этом можно почитать в документе Resource management in Aurora Serverless, об этом он писал и в своём блоге. А в обещанной персональной истории Марк рассказывает немало интересных технических деталей: понемногу и об Aurora Postgres, об Aurora Limitless Database, о синхронизации, о MemoryDB.

В Aurora DSQL изоляция на уровне снепшотов. В DSQL меж-региональное согласование происходит по COMMIT, не по отдельным SELECT, UPDATE или INSERT.

Завершается статья большим количеством интересных ссылок.

Amazon explains absence of familiar features in 'PostgreSQL compatible' Aurora DSQL

Тим Андерсон (Tim Anderson) представляет сайт DevClass, где их команда публикует аналитические статьи с уклоном в том числе в бессерверные технологии. Он пишет, что, Aurora DSQL не монолитна, а состоит из фронт-энда, процессора запросов, журнала и adjudicator-а. DSQL считает транзакцию завершённой не когда данные записаны на диск, а когда появилась запись в журнале.

От имени DevClass он говорил с G2 Кришнамурти (sic! странные у них нынче в Индии имена или прозвища: то просто C, то вот G2 — впрочем, иногда он фигурирует и как G.Krishnamoorthy). Это вице‑президент AWS Database Services. G2 сказал:

Системы хранения разные, это важно для оптимизации работы приложений, которые работают с гео‑распределёнными данными. Но мы, — сказал он, — будем дорабатывать API‑и с участием Postgres‑сообщества.
В PostgreSQL всё состояние определяется внутри одного процесса, поэтому инкрементальные счётчики распределённого SQL (т. е. DSQL) несовместимы с ним. Так во многих СУБД, где SQL распределённые, — пояснил G2.
Кроме того есть функциональность, которую просто не успели доделать. Внешние ключи, например, или поддержка хранимых процедур pgSQL. Мы просто должны их тщательно оттестировать — сказал G2.

А ещё он добавил: Мы портировали одно опенсорсное ERP-приложение с традиционного PostgreSQL на DSQL. Потребовался всего один день работы! Так что не такие уж они несовместимые.

Опять подглядывали:

A Sneak Peek Into the State of PostgreSQL 2024

Устроители подсматривания — Timescale — увидели 3 тенденции, не все приятные:

Новых пользователей PostgreSQL становится все меньше. Только 4,1% респондентов сообщили, что имеют опыт работы с PostgreSQL менее одного года, по сравнению с 8,1% в 2023 году.
ИИ‑инструменты на подъеме: их используют 55,3% (в прошлом году 36,9%). Это подчеркивает растущую роль ИИ в рабочих процессах разработчиков. В блоге есть статья State of PostgreSQL AI, там можно узнать о том, что пользователи PostgreSQL делают с помощью ИИ.
Универсальность в различных сферах применения: 60% респондентов используют PostgreSQL как для личных, так и для профессиональных проектов, что на 20% больше, чем в прошлом году.

В Европе‑БлижнемВостоке‑Африке (вот так уж они объединили территории) Postgres используют больше половины — 52.8%. В Северной Америке 25.1%, в Южной — 8.6%, на территории Азия‑ТихоокеанскийРегион Postgres обвалился с 20% до 12.9%.

В номинации Какие инструменты используете вместе с Postgres лидируют устроители:

TimescaleDB,
Redis,
PgBouncer,
Patroni,
AWS RDS,
PgAdmin,
PostGIS,
Grafana,
Barman,
Docker,
Kubernetes.

Но в номинации Расширения TimescaleDB не только не лидирует, а кроме PostGIS пропустила вперёд и pg_stat_statements. В прошлом году (и до того) TimescaleDB держала 2-е место, не пуская туда pg_stat_statements. Вообще вышло 5 отчётов — начиная с 2019 (с арифметикой всё нормально: 2020 пропустили по уважительной — Covidной причине). На этой странице лежат файлы со всеми отчётами, можно сравнивать. Можно заглянуть и в Postgresso 12 (61), где мы говорили о результатах прошлогоднего подглядывания.

Релизы

Postgres Pro Shardman 14.15.2

В этой версии интересные новшества. Добавлены, например, представления shardman.silk_state и shardman.silk_statinfo, функция shardman.silk_statinfo_reset() и параметр конфигурации shardman.silk_track_time, которые показывают состояние процессов мультиплексора. И ещё несколько пунктов с этим silk.

Добавлен новый параметр конфигурации track_xact_time, представление shardman.pg_stat_xact_time и глобальное представление shardman.gv_stat_xact_time для отображения статистики по времени, потраченному на транзакции.

Postgres Pro Enterprise 16.6.1

Много исправлений и улучшений существующего. Из нового:

Добавлена поддержка расширенного протокола запросов для перепланирования запросов в реальном времени.
Добавлена поддержка архитектуры ARM для РЕД ОС МУРОМ 8.

Обновлены многие модули/расширения/приложения:

Расширение biha обновлено до версии 1.4. Там много нового.
Приложение pg_probackup обновлено до версии 2.8.5 Enterprise.
Расширение pgpro_stats обновлено до версии 1.8, много изменений.
Модуль pgpro_pwr обновлён до версии 4.7, в которой улучшена производительность и добавлены новые возможности. Например, добавили механизм промежуточных выборок для сбора относительно быстро меняющихся данных.
Обновлён модуль aqo. Включены следующие исправления и усовершенствования: реализован режим «песочницы», позволяющий работать в изолированной среде, не затрагивая основную базу знаний aqo.
Приложение mamonsu обновлено до версии 3.5.9.
Расширение multimaster обновлено до версии 1.2.0.
Приложение pgpro_scheduler обновлено до версии 2.10.
Модуль pg_repack обновлён до версии 1.5.1.
Расширение PTRACK обновлено для предотвращения возможных проблем с резервными копиями PTRACK. Теперь при отключении PTRACK автоматически удаляется файл ptrack.map.
И ещё с десяток пунктов об обновлениях.

Также обновились 12.22.1, 13.18.1, 14.15.1, 15.10.1. Первая из них в последний раз.

Но самое интересное будет в Postgres Pro Enterprise 17. Её представят на новой конференции — PGProDay 2025, о которой ниже.

Autobase 2.1.0

Основатель и техдир Виталий Кухарик — vitabaks (Vitaliy Kukharik) — пишет, что в этой версии с не таким уж юбилейным номером даже лого поменялось: теперь там облачно со стрелами. Более того: само название Autobase (Автобаза). Это был проект postgresql_cluster — теперь у него статус форка от Autobase и лежит он на гитхабе уважаемых нами postgres‑ai. Сам Виталий даже присутствует на хабре, подписан на Postgres Professional и комментировал нашу с Михаилом Жилиным статью Битвы на территории ZFS.

Новое название определяет направление маркетинга и дальнейшей разработки: автоматизация и бесшовная настройка на нагрузки. Кстати, к термину DBaaS прирастили ещё одно A, и теперь компания предлагает DBA as a Service (DBAaaS). О новом в 2.1.0 почитать можно здесь. А о самом проекте ещё и на сайте autobase.tech.

Cloudberry Database отправилась в Apache Incubator

А вот проект Cloudberry Database теперь будет называться Apache Cloudberry (Incubating). Это наследник опенсорсной базы Greenplum Database с её MPP-архитектурой (Massively Parallel Processing). С улучшенной аналитикой. Её и создали родители Greenplum.

Ссылки по теме: GitHub, Веб, рассылки dev@cloudberry.apache.org (чтобы подписаться, надо написать на dev-subscribe@cloudberry.apache.org , на Slack.

PostgreSQL Anonymizer 2.0.0-rc.2

Вот в этом номере — Postgresso 3 за 2023 (52) — мы писали об анонимайзерах и фейкерах. Тогда мы цитировали создателя pg‑anonymizer Рафаэля Юшэ (Raphaël Huchet aka rap2hpoutre): PostgreSQL Anonymizer — его трудно настраивать, да и вообще он неуклюжий для нехитрых задач. Но всё же это лучшее решение из существующих.

Но это было давно. Теперь у этого анонимайзера круглое число в версии: 2.0.0, хотя до официального релиза ещё на сегодняшний день не добрались. Но есть уже статья PostgreSQL Anonymizer 2.0 — Generating Fake Data Дамьяна Клошара (Damien Clochard) из Dalibo (он ещё и выпускающий редактор PG Magazine и президент French Speaking PostgreSQL Association).

Напомним, что в Postgres Pro Enterprise есть свой pgpro_anonymizer.

Статьи

Будущее PostgreSQL: как 64-битный счетчик транзакций решает проблему масштабирования

Статья Loxmatiymamont. В статье вот такие главки:

Что за счётчик такой?
И немного о многоверсионности в PostgreSQL.
Так исторически сложилось: история счётчика транзакций.
Тогда в чём суть проблемы?
Что мы сделали?
Появление 64-bit xid.
Итого.

Из Итого: «Идея получила должное внимание, но внедрение таких революционных изменений — дело небыстрое по многим причинам, не только техническим».

"мы уже накопили большой багаж историй успеха наших заказчиков, развернувших различные версии Postgres Pro на своих продакшн-системах. А поскольку новый счетчик транзакций там используется по дефолту, наша реализация доказала свою работоспособность."

В статье наглядные диаграммы.

Does anyone use client connectors for PostgreSQL?

Вот они (и количество строк кода, я упорядочил по языкам):

(C++) psqlodbc, 112 886,
(C#) npgsql, 74 944,
(Java) pgjdbc, 168 541,
(Java) pgjdbc-ng 67 104,
(Python) psycopg, 52 970,
(Python) py-postgres 23 576,
(Go) pgx, 52 905,
(Go) pg 12 625,
(Go) postgres-gorm 1 198
(Node.js) node-postgres 18 838,
(TypeScript) deno 10 392,
(Rust) rust-postgres 20 448,
(Ruby) ruby-pg 22 008,
(Crystal) crystal-pg 3 858.

В сумме больше полмиллиона строк. Это почти половина от количества строк самого Postgres. Дэйв Креймер (Dave Cramer) удивляется: почему ж труды тех, кто сочиняет коннекторы получают столь мало откликов и упоминаний в сообществе?

Asymmetric Join в PostgreSQL как эволюция Partitionwise Join

Появилась статья, авторства загадочной melanny20. Повод для статьи отличный: появился ещё один вид соединения, ещё один JOIN.

Оптимизация Asymmetric Join (AJ) — это новый подход к соединению секционированных (partitioned relation, PR) и несекционированных таблиц (non-partitioned relation, NR). Суть в том, что каждая секция присоединяется с помощью NR, а результаты объединяются с помощью APPEND. Всё это выглядит как эволюция техники Partitionwise Join (PWJ).

К счастью, текст сопровождают наглядные картинки — у статьи тег сложная. Есть список из 7 преимуществ, за которым следует 1 недостаток и 2 ограничения. А есть ещё и 3 нерешённых (неотвеченных) вопроса. Меллани20 глубоко копает, это точно.

Optimizing Postgres's Autovacuum for High-Churn Tables

В контексте вакуума Churn в названии статьи Адама Хенделя (Adam Hendel, Tembo) следует, наверное, перевести как оборотистые таблицы. Он рассказывает: мы создали скрипт для оборотистой таблицы, чтобы гонять её в pgbench: вставляем строку, читаем и обновляем её, а потом удаляем. Настоящая боль для вакуума, при этом число строк в ней небольшое.

Запустив pgbench, Адам начинает играться с параметрами: autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit, autovacuum_naptime . В статье много любопытных диаграмм производительности.

pg_incremental: Incremental Data Processing in Postgres

Марко Слот (Marco Slot) пишет в блоге Crunchy Data о новом опенсорсном расширении - pg_incremental, предназначенном для автоматической, инкрементальной, надёжной пакетной обработки (batch processing). Оно создаёт конвейеры для потоков данных append-only (нагрузки IoT, временные ряды, потоки событий).

Может пригодиться в случаях:

Создания и инкрементальной поддержки роллапов, агрегации, в т. ч. и агрегации интервалов.
Инкрементальной трансформации данных.
Периодического импорта и экспорта новых данных.

Он разбивает случаи на главки и проводит примеры, обычно с кодом. Вот список этих главок:

Shrinking a Postgres Table

Статья Джона Ньюнмейкера (John Nunemaker). Он работает в Box Out Sports, Very Good Software (хозяева Fireside.fm) и Fewer & Faster (создатели Flipper Cloud) как программист и как владелец. До этого работал в GitHub 7 лет "в самых тёмных уголках их кода, оптимизируя его.

Поэтому не так уж удивительно, что статья построена как беседа с гихабовским Copilot-ом. Например, вот какими репликами перекидывались Джон и Копилот:

Джон: Мой следующий вопрос: какая из таблиц заняла всё место?

Копилот:

SELECT table_name, pg_size_pretty(pg_total_relation_size(table_name)) AS total_size FROM information_schema.tables WHERE table_schema = 'public' ORDER BY pg_total_relation_size(table_name) DESC;

Не то, чтобы Джон доверил всё своему партнёру. Кое в чём он и сам разобрался. А вот когда понял, кто виноват, решил устроить с Копи мозговой штурм по поводу что делать.

Штурм успешный, читайте. Но этим Джон не ограничился. Он решил поштурмовать и с двуногими (чтоб не сказать с к. мешками). Они тоже недурно выступили, хотя и не так, - говорит Джон, — убедительно, как Копилот. Во всяком случае двое из них сказали: да, попробуй так, как советует твой новый коллега.

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

ИИ

Huge developer survey shows which AI assistants are most adopted – and trend towards coding with VR headsets

Статья там же на DevCLass, того же Тима Андерсона, что рассказывал об Aurora DSQL (см. выше). Исследование проводили JetBrains. И неспроста: они смотрели, как используют их JetBrains AI Assistent. По их данным очень даже неплохо: их Ассистент идёт после ChatGPT и GitHab Copilot, но опережая Клода и Близнецов (в девичестве Бард).

Полный обзор здесь. Есть диаграмма использования языков программирования. Там особых сенсаций не наблюдается. Понемногу всё глубже проседают PHP и Ruby, Понемногу набирают вес Rust и Lua, но они ещё 11% и 5%. Обидно за Kotlin (я не знаю этот язык, но уж больно название красивое): пошёл вниз.

Самое удивительное там не популярность ИИ, а то, что разработчики уже вовсю используют шлемы виртуальной реальности. Их опробовали уже 8% всех разработчиков, и половина из них хотят продолжить в них работать. Впрочем, 18% чувствовали физический дискомфорт или задумались о безопасности для здоровья в случае регулярного использования.

Пятнецы: вчера, сегодня, позавчера

PG Phriday: Kubernetes Killed the High Availability Star

Это статья на сайте Шона Томаса (Shaun M. Thomas) BonesMoses.org. Это тот самый Шон, который придумал рубрику PG-пятнецы (так мы переводим phridays).

А где ж - как казалось - более удачливый распорядитель пятнец? Я о Райане Бузе (Ryan Booz). У него немного другие пятнецы - не PG-, а PGSQL-пятнецы. Но - чего уж там - он молодец, придумал этакую игру, моб с переходящими от эксперта к эксперту приглашениями и с обобщениями их откликов постфактум.

С самим Райаном всё ок: он разъезжает по конференциям, пишет статьи. А вот пятнецы его завяли: на странице PGSQL Phriday последняя #017 разыгрывалась в июне.

Выходит: Райан - талантливый спринтер. Шон - марафонец.

Но вернёмся к статье Шона. Как же K8s убил HA *?

Я работаю целенаправленно над Postgres‑ами высокой доступности (High Availability) с 2011, — говорит Шон, — и я сделал свой первый доклад на эту тему на Postgres Open 2012, он назывался High Availability with PostgreSQL and Pacemaker. Этот же стек играл большую роль в первом издании моей книжки PostgreSQL High Availability Cookbook. Так было до её 3-го издания включительно. Если я продолжу эту серию, я удалю обе главы, посвященные этому стеку, и заменю их... ничем не заменю!

Далее он говорит о том, как много решений‑стеков расплодилось (перечисляет), что много пулеров и прокси, что много решений для бэкапа — тут уж перечислю, извините:

И всё это надо не только выбрать (парадокс выбора), но и настроить, а потом ещё и спать спокойно. Нет, это не сложнее, чем написать весь стек самому — говорит Шон, — но не сказать, чтобы легко и безопасно.

А убийца ещё не в кадре. Сначала Шон собирает некоторый HA-кластер на Patroni. Потом сетует: столько провозились. Потом ужасается: столько ещё не настроили. И вот тут появляется убийца.

Фактор автобуса

The bus factor problem

Я и не знал раньше, что есть такой термин — фактор автобуса. Определение довольно жуткое: это мера сосредоточения информации среди отдельных членов проекта; фактор показывает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

Риджина Оби (Regina O. Obe) пишет в блоге BostonGIS: одна из главных проблем опенсорсных проектов — фактор автобуса, и я много думала, как это соотносится с командами моих PostGIS, pgRouting и OSGeo System Administration (SAC).

Она думала, думала и придумала: нужна страховка. И даже набросала, что может стать страховкой для этих автобусов. А мы перетекаем в тему

PostGIS

Loading the World! OpenStreetMap Import In Under 4 Hours

Грег Смит (Greg Smith) в блоге Crunchy Data рассказывает, как импортировать ВЕСЬ МИР за 4 часа. Он рассказывает, что 2 года назад презентовал доклад (видео / слайды) об этих трудностях на PostGIS Day 2022. А на PostGIS Day 2024 он продемонстрировал некоторый бенчмарк уже на Postgres 17 и новейшем железе. И вот к каким выводам пришёл:

PostgreSQL всё лучше и лучше! Особенно в построении индексов.
Загрузчик osm2pgsql тоже стал работать лучше! И опять из-за индексов.
Железо всё лучше и лучше! За два годя произошли заметные изменения.

PostGIS Day 2024 Summary

Кому ещё подводить итоги, как не Полу Рэмзи (Paul Ramsey). Тоже в блоге Crunchy Data. Он обращается к истории баз данных и истории пространственных баз данных, с нами делится своим докладом History of Databases and Spatial Databases.

Дальше он предлагает послушать Брайана Таймони (Brian Timoney), который призывает: Simplify, simplify, simplify. Стив Паусти (Steve Pousty) выполнил обязательную программу - Mandatory AI-centric Talk, но не хайповал, а разъяснял практические аспекты и терминологию. Ещё был GeoParquet и другое полезное. Полный плейлист PostGIS Day 2024 доступен на Youtube-канале Crunchy Data.

Выходит, мы уже пересекли границу рубрики

Конференции

PGProDay 2025 — первая продуктовая конференция от Postgres Professional

Конференция пройдет 28 января офлайн в Цифровом деловом пространстве (ЦДП) в Москве на Покровке 47, также можно подключиться онлайн.

Отличие от PgConf.Russia понятно: эта конференция более остро сфокусирована на разработках Postgres Professional. Насколько много будет между ними пересечений - вот и увидим: это же первая конференция PGProDay. Известно, что на ней будут круглые столы. Но главное: Марк Ривкин, руководитель отдела технического консалтинга Postgres Professional, выступит с докладом про СУБД Postgres Pro Enterprise 17.

PGConf.Russia 2025

Объявлена early‑bird‑регистрация: участие со скидкой 25%. Сама конференция состоится 31 марта — 1 апреля в Бизнес‑центре World Trade Centr (да, они именно так пишут это слово). Будут мастер-классы, профессиональная сертификация по PostgreSQL (по предварительной записи).

Качество данных 2025

Конференция Открытых Систем. Пройдёт в московском Holiday Inn в Сокольниках 26 февраля. Нет, тема PostgreSQL там не заявлена, но наверня какачество данных какое-то подмножество постгресистов очень даже волнует.

FOSSASIA PGDay 2025

FOSSASIA PGDay 2025 так называется потому, что день с постгресовой тематикой вписан в конференцию FOSSASIA Summit с более широкой тематикой. В этом году он будет в Бангкоке - в гостеприимном Таиланде.

В прошлом номере мы писали о PGDay Jakarta 2024. До этого PGDay побывал в Ханое и Сингапуре.

Стоит поторопиться: заявки на доклады принимаются до 12 января. Если вдруг кто захочет спонсировать, то вам сюда.

PostgreSQL Conference Germany 2025

Пройдёт в Берлине 8-9 мая.

pgDay Paris 2025

Пройдёт 20 марта.

Состоявшиеся конференции

PGConf.EU 2024

Продолжает будоражить умы. Андреас Шербаум (Andreas 'ads' Scherbaum) в PGConf.EU 2024 Lightning Talks сделал обзор 12 коротких докладов — со ссылками на слайды и видео. Темы — Postgres Performance Farm, pg_duckdb, WAL-G и другие.

Highlights from PostgreSQL Conference 2024 in Seattle

Кэри Хуан (Cary Huang из канадского отделения Highgo Software) пишет о PostgreSQL Conference, состоявшейся 6–7 ноября Сиэттле как часть PASS Data Community Summit. Довольно компактная, но содержательная. Был Джо Конвей (Joe Conway), были доклады по миграции, например Overcoming Migration Challenges from Oracle to PostgreSQL Баджи Шаика и Самира Малика (Baji Shaik и Sameer Malik).

На сегодня всё. Но в этом году ещё увидимся: будет итоговый номер за 2024.

Postgresso #12 (73)