Postgresso №5 (54)

Beta!

Это PostgreSQL 16 Beta 1. После неё будут ещё беты, число которых заранее не известно - по обстоятельствам. После появится релиз-кандидат, скорее всего тоже не один. Официальный релиз выходит обычно осенью. Можно заглянуть в Beta Testing в случае заинтересованности.

Конечно, практически всё новое, что появилось в бете, уже обсудили. В прошлом выпуске - Postgresso #4 (53) - было много ссылок на серии статей, в которых разбирались новые фичи. Это серия Мишеля Пакье (Michael Paquier) - PostgreSQL 16 highlights (за месяц коллекция пополнилась предикатами - JSON predicates); Павло Голуба (Pavlo Golub), у которого нового о 16-й не прибавилось; Лоренца Альбе (Laurenz Albe) - без новостей по 16-й; Крис Трейверс (Chris Travers) - тоже ничего пока нового по этой части; и у Хуберта 'depesz' Любашевского (Hubert Lubaczewski) в Waiting for PostgreSQL 16 тоже ничего нового.

И, разумеется, напоминаем о статьях-обзорах PostgreSQL 16, коммитфесты: Части

• 5 (2023-03 - ru, en - только что появился),

• 4 (2023-01 - ru, en),

• 3 (2022-11 - ru, en),

• 2 ( 2022-09 - ru, en),

• 1 (2022-07 - ru, en).

Что же выделяют в релизе сами авторы сообщения? Первым идёт производительность. Там много о параллелизме. COPY, например, сможет работать в 3 раза быстрей. Оптимизировали оконные функции. И есть любопытные штуки, ускользнувшие, кажется, от многих, анализировавших новости: появилась поддержка SIMD-команд процессоров x86 и ARM, которая ускоряет работу со строками ASCII и JSON, с массивами и поиск в подтранзакциях. Появилась балансировка нагрузки на уровне libpq.

Есть там целый раздел о логической репликации.

SQL/JSON тоже уделили внимание. Хотя и не целый абзац. Появились конструкторы (напр. json_array(), json_arrayagg(), предикаты IS JSON и др. (identity functions). Появилась необычная (но она есть в стандарте SQL) функция any_value().

Для любителей psql (а кто не любитель) появилась полезная вещь: поддержка расширенного протокола запросов (extended query protocol), а это значит, что можно подставлять переменные в подготовленный запрос: сказать SELECT $1 + $2, а потом\bind и подставить нужные переменные.

• Скачать,

• бета-тестировщикам,

• Release Notes,

• проблемы,

• Feature Matrix,

• прислать баг.

PostgreSQL 15.3

Бета бетой, а вышли и очередные стабильные релизы: PostgreSQL 15.3, 14.8, 13.11, 12.15 и 11.20. Главное: устранены 2 уязвимости, на одну из них указал Александр Лахин. Они описаны здесь:

• Устранение уязвимости команды CREATE SCHEMA при внесении изменений в search_path (Александр Лахин)

  Злоумышленник, имея привилегию CREATE на базу данных, мог выполнять любой код с правами суперпользователя. Проект PostgreSQL благодарит Александра Лахина за сообщение об этой проблеме. (CVE-2023-2454)

• Исправление применения политик защиты на уровне строк после встраивания функции, возвращающей множества (Стивен Фрост, Том Лейн)

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

  Проект PostgreSQL благодарит Вольфганга Вальтера за сообщение об этой проблеме. (CVE-2023-2455)

Эти проблемы актуальны для версий 11-15. Неподдерживаемые версии не тестировались, с большой вероятностью проблемы существуют и там. Кроме того исправлено более 80 багов во всех ветках релизов. Загляните в Release Notes и/или в Замечаниях к выпуску 15.3.

Драмы и боги форков. OSS. Нефоркнутые.

Больше форков богу форков

Владимир Медейко, ни много ни мало директор НП "Викимедиа РУ" [UPD: уже ушёл, теперь руководит собственным проектом - "Рувики. Свободная энциклопедия"], а из текста узнаём и о том, что Владимир работал в команде СУБД-круг Громова 2022 над Исследованием русских СУБД-вендоров, российское ПО базы данных, о котором мы, конечно, писали в предыдущем выпуске.

Он старается не повторять общие слова и мысли, а рассказать что-то новое и не совсем мейнстримное. Он ссылается на Формулировку четырёх свобод, но подробно говорит о 4-й: свободе вносить в код изменения и улучшения - именно она люба и желанна Богу Форков. А в ней - на возможности создавать именно коммерческие форки. Оказывается, что главку об импортозамещении в этом исследовании писал Владимир. И приводит оттуда цитаты о Postgres Professional и Arenadata. Упоминает и Символ импортозамещения маршрутизатор Маяк.

Это не статья, а небольшая заметка. Зато в ней есть голосовалка с такими вариантами ответов:

1. Пусть делают, чего хотят (с соблюдением лицензии), на то она и свобода-свобода!

2. Очень здорово, это позволяет СПО лучше развиваться и более широко распространяться.

3. Если отдают свои наработки обратно — хорошо, а те, кто только берёт — бяки.

4. Если форк тоже полностью под свободной лицензией — хорошо, иначе — резко против.

5. Несимпатичны, но пусть живут.

Так что там можно самовыразиться и посоревноваться в (нон)конформизме.

Заодно на тему Open Source: героиня недавней шербаумской Недели - Флоор Дреес (Floor Drees, Нидерланды) в своём интервью настойчиво рекомендовала книгу:

Working in Public: The Making and Maintenance of Open Source Software

Эту книгу написала Надя Эгбал (Eghbal, Nadia), она же Надя Аспарухова (Nadia Asparouhova - видимо, болгарско-турецких корней). Надя пишет не только об открытом коде. Её интересуют и популярные сейчас (и спорные) социо-философские концепции: Эффективный Альтруизм и связанная с этим Машина Идей. Так что наверняка и в Working in Public немало философских рассуждений.

Теперь о драме форков.

Гендир MariaDB Майкл Ховард (Michael Howard) сделал на их конференции OpenWorks в Нью-Йорке заявление, которое произвело впечатление. В его докладе немало любопытного, да это и не доклад: он зовёт на сцену полдюжины коллег.

На 5:35 этого видео Майкл призывает на сцену Курта Коловсона (Curt Kolovson), который был в 80-е ни много ни мало в знаменитой команде под руководством самого Майкла Стоунбрейкера в Калифорнийском Университете в Беркли. Но если смотреть/слушать лень, можно найти и что почитать, хотя пока текстовая информация скудная.

В своём мариядэбэшном блоге - This is a Blog for PostgreSQL Lovers - Курт пишет: Saying “yes” to MariaDB Xpand doesn’t mean saying “no” to PostgreSQL. И нахваливает Postgres, заметив, что масштабируемость и высокодоступность остаются его слабостями. Это его команда в MariaDB, куда Курт перешёл из VMWare, и решила поправить, создав Xpand (а Ховард в своей речи упоминает X-Project, имея в виду, судя по контексту тот же Xpand).

Xpand for Postgres (а есть ещё и Expand for MariaDB) реализована как расширение Postgres, причём это нефоркнутый (unforked - под этим подразумевается Postgres с неизменённым, непатченным кодом). Масштабируемость у Xpand не только по читающим, но и по пишущим транзакциям - это такой своеобразный мультимастер. Если распределённый движок (видимо, на базе приобретённой Clustrix) не может сам эффективно обработать запросы с неродным постгресовым синтаксисом, он передаёт их (pushdown) в Postgres. Xpand for PostgreSQL можно будет попробовать на Xpand4All как сервис SkySQL.

А в своём личном блоге на Medium Курт постит единственную статью - Weighing the Pros and Cons of PostgreSQL, где о Xpand нет ни слова, зато он перечисляет недостатки Postgres, выкатывает список его важнейших возможностей, которые могут быть реализованы только через расширения третьих сторон, и разбирает, почему (из-за каких несовместимостей) AWS Aurora и RDS, YugabyteDB, CockroachDB связаны с Postgres разве что по имени.

Новость произвела впечатление на присутствовавших журналистов. Они откликнулись.

MariaDB sticks PostgreSQL front end on SkySQL DBaaS

Статья редакции DUK News (это просто новостной портал, аббревиатура расшифровывается как Daily UK News) рассказывает об этом, кажется, наиболее подробно. Она же появляется на The Register за подписью Линдзи Кларк (Lindsay Clark) и с куда более эффектным названием:

MariaDB's Xpand offers PostgreSQL compatibility without the forking drama

Там говорится, что, де, эта игра изничтожит CockroachDB и переманит к себе пользователей гипермасштабируемых DBaaS. Там цитируют Доменика Равита (Domenic Ravita), очередного "евангелиста" той самой Cockroach, которую не ровён час убьёт новый проект MariaDB:

Я считаю, что если бы Майкл Стоунбрейкер стал переписывать сейчас PostgreSQL, он бы следовал тем же принципам, что и мы. Построил бы изначально распределённое решение, облачное, способное работать с разными облаками (multi-cloud) и многими регионами (multi-region), но при этом совместимое с PostgreSQL.

Можно также почитать и ещё на тему:

Распределенный SQL: альтернатива шардированию баз данных. Это перевод статьи Алехандро Дуарте (Alejandro Duarte) Distributed SQL: An Alternative to Database Sharding. В этой большой статье с множеством наглядных схем в качестве примера такой базы как раз приводится MariaDB Xpand (ex Clustrix).

А мы от форков плавно переходим к миграции - сначала между форками.

Миграция

Migrate from Redshift (на Hydra)

И то, и другое - форки PostgreSQL, и в том, и в другом колоночное хранение. Опенсорсная Гидра поддерживает heap-таблицы Postgres, индексы и секционирование. В Redshift код Postgres изрядно переработан, но всё же это Postgres. Redshift - в отличие от Hydra - не поддерживает табличные функции и триггеры. Ограничения (constraints) там тоже поддерживаются не полностью. Как и индексы (вместо них там есть DISTKEYS и SORTKEYS). И даже роли. В общем, это какие-то другие миры - для тех, кто привык к PostgreSQL (и к Postgres Pro). Такие вот форки.

Subtle Art of Code Conversion in Oracle to PostgreSQL Migration. | Database and Migration Insights

Дипак Махто (Deepak Mahto) исходит из собственного опыта миграции и примеры приводит тоже из своей практики. Одно утверждение весьма концептуально: делайте своеобразный обратный инжениринг кода - не конвертируйте механически строчку за строчкой, а сначала попробуйте понять: зачем код был написан именно так.

В примере он берёт код с иерархическими запросами и функциями обработки строк и заменяет код другим, использующим постгресовые regexp_split_to_array и unnest.

Как перейти с MongoDB на Postgres без простоев и сократить расходы на 30% - в блоге Southbridge опубликовали перевод большой статьи с сайта компании Voucherify: How We Moved From MongoDB to Postgres Without Downtime?

Автор статьи, Адриан Вильчек (Adrian Wilczek), подробно рассказывает о переезде. Перебирались они с SaaS-платформы Compose на Amazon RDS, используя DMS (Database Migration Service от AWS). План был такой:

• проверка работоспособности данных в MongoDB;

• создание дочерних таблиц с помощью Postgres Inheritance;

• применение триггеров преобразования;

• запуск сценариев Amazon Database Migration Service;

• проверка работоспособности данных в дочерних таблицах;

• перемещение «удалённых» данных из дочерней в родительскую таблицу;

• переключение логики приложений на использование Postgres;

• выявление аномалий;

• перемещение «активных» данных из дочерней в родительскую таблицу;

• остановка и удаление задач DMS.

Каждый пункт автор поясняет - некоторые подробней, с кусками кода, некоторые бегло. Результатом все остались довольны.

Как великану из страны 1С пересесть на слона?

Помечена как tutorial, автор статьи назвался так: @1CUnlimited.Начинается туториал с цитаты из интервью 2022-го года Ивана Панченко Инфостарту - PostgreSQL совершенствуется, и 1С тоже идет навстречу:

Для прикладного разработчика совершенно не важно, с какой базой он работает. Все эти вопросы решаются на уровне платформы. Миграция выглядит так — выгрузил базу в dt‑ник, загрузил его обратно в другую базу. Вот и всё.

Автора не удовлетворяет это "вот и всё". Как будет это работать с большими базами? Вообще-то, ограничения dt-файла заоблачны для реальных задач, да и база, прямо скажем, не то, чтобы гигантская - 1.7ТБ. И всё же. Автор, кстати, любит говорить о базах хоть и больших, но 1С БодиПозитив. В конце этой довольно большой и подробной статьи, в которой описывается даже выбор дня для переезда, говорится о перспективах шардинга. Со ссылкой на План разработок Postgres Professional.

Начавшись с цитаты из Панченко, статья заканчивается цитатой из Гёте:

Мечтай по‑крупному, мелкие мечты не зажигают сердца.

Dbmate 2.3

Инструмент миграции для больших коллективов разработчиков и нескольких продакшн-серверов. Никаких красот - командная строка. Можно использовать с Go, Node.js, Python, Ruby, PHP и др. Поддерживает СУБД MySQL, PostgreSQL, SQLite и ClickHouse. В тексте есть матрица свойств разных платформ разработки в разделе Alternatives.

pg-online-schema-change / pg-osc 0.8.1

Придумано для изменений схемы на продакшн с минимальными блокировками. Идея в создании "теневой" таблицы, в которой происходят нужные манипуляции, потом ей подменяют исходную. При этом используются триггеры.

Образование: Postgres-олимпиада

Как сообщает организатор фестиваля Дарья Рисухина (Postgres Professional), с 26 по 29 мая в Сочи прошел финал олимпиады IT-Планета 2023, в котором приняли участие 14 студентов и специалистов.

В течение 9 часов участники решали логические и практические задачи, связанные с разработкой нестандартных SQL-запросов. В режиме реального времени они отправляли ответы на проверку в систему и набирали баллы в зависимости от качества запроса. Всего было 7 задач.