Тяжёлое и средней тяжести наследство
Бурное развитие нейросетевых способов разработки подсказывает вопрос:
В мире имеется огромный склад чемоданов без ручек. Это старьё, эта рухлядь, пусть они и милые сердцу и в них вложены труд и талант, их называют легаси. Это и софт (чаще), и железо. Руки программистов-старьёвщиков не доходят до них, до этих легасей, и уже вряд ли дойдут. Но вдруг дотянутся хищные лапищи нейросетей?
Почему бы нет: дело почти рутинное, архитектуры изобретать не надо. Просто переписать с минимумом ошибок. Нет, не просто. Проблемы есть.
-
Проблема тренировочных данных для легаси-языков:
-
современные LLM обучены преимущественно на публичных репозиториях (GitHub и др);
-
легаси-код (COBOL, RPG, SAS, PowerBuilder) часто закрыт, проприетарен или представляет собой «игрушечные примеры», не отражающие реальную бизнес-логику;
-
в результате: ИИ «знает синтаксис», но не понимает контекст корпоративных систем. Получается разорванный цикл обратной связи.
-
-
А цикл обратной связи в традиционной разработке таков: Код → Компилятор → Ошибка → Исправление → Повтор. А у легаси-платформы (скажем, AS/400, мейнфреймы): Код → ИИ-генерация → Нередко нет доступа к компилятору → Автоматически исправить скорее всего не получится. А без доступа к инструментам валидации ИИ не может «научиться на ошибках» в реальном времени.
-
Семантический разрыв между диалектами SQL. Чего уж там, про Oracle -> PostgreSQL у нас же нет иллюзий.
Пусть нам нет дела до проблем с AS/400, но легаси-то и у нас ещё прячется по тёмным углам. И какие легаси – интересные, а то и свои, уникальные.
Но попытки в мире делаются. Относительно успешные.
Вот ANZ Bank (Австралия): использовал инструменты IBM для миграции критических систем с мейнфрейма на облачную платформу (частично с использованием AI-ассистентов).
Mainframe – ANZ’s engine of trust – эти австралийские банкиры, точнее Дэвид Свайрз (David Squires), главный мэйнфрейм-инженер в ANZ, говорит:
Среда мейнфреймов не застаивается, она продолжает фокусироваться на модернизации приложений в гибридную облачную среду – на комбинации мейнфреймов и облака в гибкой, безопасной, масштабируемой экосистеме.
Мейнфреймы z16 предлагают адаптировать новейшие технологии и наращивать производительность.
Не перестаю удивляться: эти машины просто невероятны! Ну и как же приятно работать с лучшими специалистами отрасли, бьющимися за то, чтобы мейнфреймное железо оставалось в этом мире самым современным.
В этих словах не только маркетинг: в них (мне) слышна любовь к этим исчезающим большим и умным животным.
Агента зовут Боб. Его хвалит Артур Сковронски (Artur Skowronski), глава разработки Java & Kotlin: Боб – 1-й инструмент такого рода, для него Java – пассажир 1-го класса.
А вот и Ватсон. Когда-то Ватсон обыгрывал каких-то главных викторинщиков, а теперь вот занялся переписыванием легаси:
Напомню, что System Z – это мэйнфреймы, тех, что, в свою очередь, потомки IBM System/390. А переписывать надо в основном COBOL. Чаще на Java для тех же мэйнфреймов.
Да, говорят, что это всё же требует глубокой настройки под специфику и валидации 2-ногими экспертами.
Интересно ещё вот что: как пишут в Accelerated, Gen AI powered Mainframe App Modernization with IBM watsonx Code Assistant for Z, этот ассистент построен на собственном их IBM Granite, опенсорсной модели, обученной на 116 языков программирования.
А вот здесь даже не IBM-мэйнфреймы, а юнисисовские – для ещё более нешуточного клиента: Software Modernization Assured. Unysis Mainframe to AWS GovCloud – COBOL to Java, U.S. Air Force SBSS ILS-S Modernization (TSRI). – это, конечно, их опечатка: Unisys, а не Unysis, ср. с Мэйнфреймы фирмы UNISYS: от Burroughs до наших дней на сайте Открытых Систем.
Кстати, желающие применить ИИ к Air Force уже выстроились в очередь: вот компания Illumination Works, вместо того, чтобы заниматься иллюминацией, не только подготовила Agentic AI Natural Language Reasoning для них, но и позиционирует себя как поставщик замечательной аббревиатуры с 3 “а” подряд: DAaaS (Data Analytics). У них агенты на базе Mistral. Умеют работать с MS Word, MS Excel и PDF, с промышленным IoT (IIoT), умеют автоматически упорядочивать права доступа и многое другое.
Небезызвестный Wells Fargo modernizes thousands of applications faster with software intelligence – более 4500 приложений. Анализ с применением ИИ. А ING Bank модернизировал более 1,5 миллиона строк кода COBOL, включая CICS, DB2 и JCL – см. COBOL-to-Java Migration Case Study, – используя SoftwareMining для автоматизированного перевода на Java.
И тут на сцену выходит Google: Accelerate mainframe modernization with Google Cloud AI. Они пишут в блоге Google Cloud, что используют Gemini 3.
А что в России? Мало кобола, много тумана. Вот хабр, но всё же не российский опыт. Но с мэйнфремами и с ИИ. В блоге АльфаСтрахования: Как я мигрировал COBOL-код мейнфрейма на Java: разные подходы и почему ANTLR.
А вот сверхлаконично и гипертуманно, зато уже о наших рукастых носильщиках чемоданов без ручки: Поддержка Legacy-системы и как навести порядок в устаревших технологиях – упоминается и ритейл, и “жёлтый банк”.
Но хватит об этом. Ниже ещё напишем о миграции – с ещё не покрывшихся мхом систем на Postgres. А пока:
Релизы
Канадская компания HexaCluster.ai не без странностей: например, о новых релизах она оповещает из Антананариво (это столица Мадагаскара). О ней мы писали в Postgresso 2 (63). Тогда мы дивились, что один из самых продуктивных разработчиков во французской компании Dalibo, Жиль Дароль (Gilles Darold, самый известный его проект – Ora2Pg) стал техническим директором компании HexaCluster, тогда мало кому известной. Говорят, в 90-е он работал в Астрономической Лаборатории Calern в Ницце – почти бусидо основателей Postgres Professional.
Как бы то ни было, на сайте этой компании есть примечательный подзаголовок: Legacy to Modernized Applications & PostgreSQL Consulting. И нарисована схемка-отношение: были системы на Oracle, SQL Server, DB2 и Informix, стали – на PostgreSQL. По их словам – вплоть до 100% автоматизации. А между Oracle, SQL Server, MySQL, MariaDB и PostgreSQL у них кросс-платформенная миграция и репликация в реальном времени.
credcheck – опенсорсный проект (лицензия PostgreSQL) HexaCluster. Это утилита-расширение для настройки политик безопасности паролей (сложность, история, срок действия, блокировка при подборе). Там много настраиваемых параметров, таких как срок протухания пароля, его замысловатость и так далее. В этом минорном релизе ничего примечательного нет, более значительные в мажорном credcheck 4.0. Загрузить можно отсюда.
Ещё мадагаскарские новости: pg_dbms_job v2.0
Это даролеский аналог ораклового пакета DBMS_JOB. Планировщик в смысле шедулер. Вот документация, загружать можно отсюда. О таких утилитах можно, наверное, сказать: “скромненько, но со вкусом”.
Autobase задуман как опенсорсная замена облачной Amazon RDS. Половина названия – Auto – не предполагает автоматической настройки параметров, индексов и запросов как, скажем, у Postgres.ai, но особенность и не в этом.
Это вовсе не аналог облачных DBaaS, а их в некотором смысле противоположность: основатель компании говорит автору не слишком прозрачного блога:
Эра «Облако прежде всего» (Cloud First) переходит в эру «Контроль прежде всего»” (Control First). По мере роста затрат и повышения важности суверенитета данных инструменты вроде Autobase предоставляют ту золотую середину, которую так ждали.
И всячески подчёркивает много где, что преимущество в полном контроле за своей базой. И что Autobase может работать на “голых” (bare metal) серверах, без виртуализации.
Ну а имя Auto оправдано тем, что многие важные операции с кластерами автоматизированы (в основном скриптами Ansible): развертывание, failover, бэкапы, восстановление, апгрейды и масштабирование – создаётся сразу HA-кластер, готовый для продакшн.
Autobase Tech приписана к Испании, основатель Виталий Кухарик (Vitaliy Kukharik, из СПб) aka vitabaks. Сама Autobase сначала называлась postgresql_cluster, её тогда ещё хвалил Алексей Лесовский, ныне руководитель отдела разработки Postgres Professional.
В этом релизе изрядные изменения: как и обещали, заинтегрировали DBDesk Studio индийской компании Zexa Technologies. Это логично: у них контроль тоже любимая тема. В доке к минималистской DBDesk создатели хвалятся прежде всего его безопасностью: Local-First Security – данные не покидают локальный компьютер. И информация о соединении хранится исключительно локально.
DBLab (она начинала как Database Lab) – детище возглавляемой Николаем Самохваловым (Nikolay Samokhvalov) Postgres.ai. В этом релизе в том числе: временные лицензии на защиту (protection leases), поддержка Prometheus и Teleport.
Клон нельзя было удалить ни вручную, ни автоматически, пока защита не снималась явно. Это создавало риск: забытые защищённые клоны могли бесконечно занимать место на диске. Теперь после истечения заданного срока клон автоматически становится незащищённым. “Клоны убирают за собой” – как написано в блоге. Что такое клон в данном контексте – объяснять не будем: это центральное понятие Postgres.ai.
4.1 научился работать на ARM64 и Colima: теперь клоны будут размножаться и на маках.
Ещё любопытная возможность: в RDS/Aurora обновление данных (data refresh) не задевает продакшн. Речь вот о чём: запуск pg_dump напрямую на продакшен-инстансе RDS сопряжён с рисками: в процессе дампа удерживается горизонт xmin, что блокирует работу vacuum и приводит к накоплению «мертвечины» (к bloat). Вплоть до того, что на сильно нагруженных системах это создаёт риск краха счётчиков (transaction ID wraparound).
А в DBLab 4.1 появилась утилита rds-refresh – она:
-
находит последний автоматический снапшот RDS,
-
разворачивает из него временный RDS-инстанс,
-
направляет через DBLab обновления на этот временный инстанс,
-
автоматически удаляет временный инстанс по завершении.
В Q&A можно прочитать признания:
Мы ещё не полностью автономны. PostgresAI отслеживает состояние, ставит диагнозы и готовит pull request’ы. Но проверяете, утверждаете и сливаете изменения вы сами. Человек участвует в каждом изменении [human-in-the-loop – опять эти “люди в петле”].
Мы создаём Self-Driving Postgres. База данных сама следит за собой, диагностирует проблемы и предлагает исправления – улучшения производительности, патчи безопасности, обновления без простоя. Каждая рекомендация тестируется и проверяется на клоне ваших реальных данных.
А в роудмэпе можно прочитать:
2026 AUTOPILOT
Безопасные операции выполняются автоматически.
Рискованные изменения по-прежнему требуют одобрения.
Self-driving: первые версии — в конце 2026 года.
2027+ SELF-DRIVING
Полная автономность.
Postgres работает сам.
А вы занимаетесь развитием продукта.
Немного контекста. Есть и университетские проекты самонастраиваемых СУБД. На этот раз дадим ссылку на Пекинский Университет, где в лаборатории PKU-DAIR (Data and Intelligence Research) предлагают:
А, например, майкрософтовский Intelligent tuning умеет настраивать в том числе автовакуум.
Что касается клонов, то они прибывают из разных направлений: из Азербайджана, из его столицы – Баку:
Это опенсорсное расширение PostgreSQL, которое клонирует базы данных, схемы и объекты напрямую через SQL, используя кастомные воркеры.
В 4.0.0 важное изменение: когда вы говорите CREATE EXTENSION pgclone, схема pgclone создаётся автоматически, и все функции попадают в эту схему, а префикс pgclone_ удаляется. Настолько серьёзное, что надо грохнуть старое расширение и создать новое. Работает с PostgreSQL 14-18.
Конечно, это клоны совсем не того продвинутого типа, что у Postgres.ai. Но даже сам нейминг показателен.
В pgclone полная поддержка DDL (индексы, ограничения PK, UNIQUE, CHECK, FK, EXCLUDE, триггеры, представления и последовательности – без зависимостей от pg_dump, pg_restore или внешних shell-скриптов. Встроенное маскирование с автоматическим анализом и подсказками: какие колонки надо бы маскировать (анонимизировать).
Вот гитхаб, 4.0.0 Release Notes, PGXN, гайд, об асинхронных операциях, архитектура, тестирование.
Ведёт этот проект Валех Агаев (Valeh Agayev aka valehdba). В Азербайджане есть своя PUG. Но конференций, кажется, пока не устраивает.
А ещё есть такие вот:
Коллектив по-восточному загадочный. Контрибьюторы в основном сингапурцы с китайскими фамилиями. Пишут, что это не просто база данных с AI-функциями – это AI-native система данных, которая учится, адаптируется и оптимизирует себя в реальном времени.
-
AI-Native архитектура: AI и обработка данных глубоко интегрированы в движок БД, отсюда бесшовное обучение, инференс и управление моделями.
-
Intelligent Analytics: Встроенные AI-операторы позволяют запускать предиктивную и генеративную аналитику прямо в SQL, без внешних пайплайнов.
-
Autonomous Operation: Самонастраивающиеся, самомасштабирующиеся и самовосстанавливающиеся механизмы непрерывно оптимизируют производительность и использование ресурсов.
-
Unified AI & Data Platform: Единая система для управления данными и полного AI-цикла, обеспечивает безопасность, низкую задержку и упрощённые workflows.
В версии 0.5.0, номер которой вряд ли говорит о зрелости проекта, сказано о том, что улучшен метод доступа NRAM (NeurDB Access Method). К сожалению, этот релиз состоялся в конце 2025 года, так что пожелаем проекту здоровья, не повторить судьбу Эндипавловских Выдр.
pgEdge Launches AI DBA Workbench, an AI Co-Pilot for Database Administrators
Эта ссылка на сайт PostgreSQL.org, а вот и анонс на сайте компании: Your Postgres estate monitored, diagnosed, and under control. Introducing the pgEdge AI DBA Workbench.
pgEdge – Postgres-компания, позиционирующая себя как ведущий поставщик опенсорса уровня энтерпрайза. AI DBA Workbench for Postgres, соответственно, опенсорсная утилита для мониторинга и управления PostgreSQL. С ИИ-автоматизацией, но без претензий на автономность – она помощник админу, а не замена.
Умеет многое:
-
Собирать данные о производительности PostgreSQL.
-
Мониторить производительность запросов.
-
Отслеживать активность VACUUM.
-
Контролировать состояние подключений.
-
Измерять пропускную способность WAL.
-
Отслеживать задержку репликации.
-
Обнаруживать аномалии с помощью трёхуровневой системы.
-
Использовать статистические базовые показатели для анализа.
-
Сопоставлять с шаблонами через векторное сходство.
-
Классифицировать проблемы с помощью ИИ.
-
Выявлять проблемы до их перерастания в сбои.
-
Работать как классический инструмент наблюдаемости без ИИ и включать ИИ при необходимости.
Утилита не привязана к определённой LLM. Настраивается на разные, задаётся параметр. Будет работать хоть на Amazon RDS или Supabase, хоть дома.
Техдир pgEdge – Дейв Пейдж (Dave Page, в Core Team PostgreSQL, создатель pgAdmin, ранее вице-президент и главный архитектор EDB). Не могу забыть:
«В ноябре прошлого года, после почти двух десятилетий работы на моём предыдущем месте, я понял, что не хочу работать в компании, которая быстро становится ориентированной на искусственный интеллект. Я перешёл в pgEdge, где внимание и усилия сосредоточены на распределённом PostgreSQL.» см. Postgresso 7-8 за 2025 (80-81).
Но, чего уж, pgEdge действительно пока фанатически привержена open source, в отличие от EDB со смешанной бизнес-моделью.
Создатели этого опенсорсного (лицензия Postgres) расширения – Tiger Data, некогда Timescale. Их pg_textsearch поддерживает поиск Okapi BM25. Оно сочинено на C и работает напрямую со слоем хранения Postgres, добавляет свой оператор <@>, который можно использовать в SQL.
У ранжирования ts_rank в tsvector/tsquery есть недостатки, о которых они говорят в pg_textsearch 1.0: How We Built a BM25 Search Engine on Postgres Pages. BM25 помогает от них избавиться. Авторы поясняют схемами архитектуру своего решения.
Создатели сравнивают на тестах своё детище с ParadeDB v0.21.6, которая использует библиотеку Tantivy, которая, в свою очередь, вдохновлена Apache Lucene. Номер версии намекает на готовность к реальному, а не экспериментальному использованию. Вот гитхаб проекта.
Универсальная no-code платформа для анализа данных через ИИ, поддерживает PostgreSQL как один из источников, не специализируется на администрировании. Их штаб-квартира в Абу-Даби в ОАЭ, но и с офисом в Пало-Альто, США. Основатели – Рейчел Ху (Rachel Hu, CEO) и Кими Конг (Kimi Kong, CTO), команда с опытом в Google DeepMind, AWS, Stanford.
PostgreSQL: storage_engine 1.0.7 – columnar + row-compressed Table Access Methods for PostgreSQL 16-18, а также storage_engine: Two High-Performance Table Access Methods for PostgreSQL Analytics and HTAP Workloads
Сауло Жозе Бенвенутти (Saulo José Benvenutti, saulojb) из Порто Униаун (Porto União, это в Бразилии) наваял расширение, нескромно названное storage_engine. Оно даёт сразу 2 высокопроизводительных метода доступа к таблицам для аналитических и HTAP-нагрузок:
colcompress: колоночное сжатое хранилище с векторизованным выполнением, с обрезкой (pruning) min/max на уровне чанков, параллельным сканированием и сортировкой типа MergeTree.
rowcompress: строковое хранилище с параллельным сканированием, поддержкой DELETE/UPDATE через битовые маски удалённых записей и кэшем декомпрессии LRU.
Оба метода доступа к таблицам (AM) сосуществуют параллельно со стандартными heap-таблицами в одной базе данных. Все объекты каталога изолированы в схеме engine, что делает расширение безопасным для установки рядом с citus_columnar или любым другим колоночным расширением (все экспортируемые символы C имеют префикс se_, чтобы избежать конфликтов линковки).
Возникли не на ровном бразильском месте: storage_engine – форк Hydra Columnar (которая сама произошла от citus_columnar). При этом автор добавил: расширенный rowcompress, полную поддержку DELETE/UPDATE, обрезку min/max на уровне чанков и переработал параллельное сканирование. Опция orderby в стиле MergeTree и обрезка по зонам-картам напрямую вдохновлены ClickHouse – отдаёт должное Сауло Жозе.
Всё со значительной – подчёркивает автор – экономией места хранения и без существенного ущерба для производительности запросов по сравнению со стандартными heap-таблицами.
Совместима с PostgreSQL 16 и новей. Гитхаб, PGXN. В статье storage_engine: Two High-Performance Table Access Methods for PostgreSQL Analytics and HTAP Workloads Сауло довольно подробно объясняет, что он сделал и, в том числе, с чего бы два – казалось бы – совсем разных метода объединять в одном расширении.
Немного о наших (во всех смыслах) достижениях.
Скоростной софт для аналитики. С вертикальным хранением. В этой версии есть ключевые изменения:
-
Поддержано Hive-секционирование при создании аналитических таблиц с помощью процедуры metastore.add_table.
-
Обеспечено предотвращение удержания горизонта при аналитических запросах.
-
Сделаны доработки по обратной связи:
-
добавлена поддержка UNION операций,
-
улучшено взаимодействие с S3.
-
Эта версия только что вышла. Поддерживаемые ОС: ALT Linux 11, Astra Linux Smolensk 1.8. Но скоро добавятся: Debian 13, RedOS 8, Ubuntu 24.04, RHEL 10. Вот документация проекта.
Это важный для экосистемы элемент. Он полезен не только для традиционного занятия: миграции с Oracle на Postgres, его возможности много шире. О нём не надо забывать, когда вообще речь заходит о преобразовании самых разных данных (например, из Shardman; ну а Oracle может не только отдавать, но и принимать данные – см. список изменений). Но это особый разговор. В этой версии много изменений:
-
Обеспечена безопасность функционирования всех компонентов.
-
Добавлен интерфейс администратора Postgres ProGate.
-
Добавлена возможность управления проектами, которые включают трансферы данных и соединения.
-
Добавлена поддержка механизмов политики безопасности содержимого (Content Security Policy).
-
Добавлена поддержка PostgreSQL 9 утилитой procopy.
-
Добавлена базовая поддержка чтения изменений из Shardman.
-
Добавлена поддержка Oracle в качестве приёмника данных для репликации изменений.
-
Устранена зависимость проверки корректности переноса данных procheck от клиента Oracle.
-
Реализованы возможности аудита действий, выполняемых пользователем в приложениях командной строки. Приложения осуществляют сбор событий, связанных с изменением состояния выполнения задач миграции и репликации данных.
Самые свежие версии Shardman сегодня такие: Postgres Pro Shardman 18.3.3, а также 17.9.2 и 14.22.2. Там в основном исправление ошибок и ликвидация уязвимостей.
Postgres Pro Backup Enterprise 3.3.0
Да, он Pro и Enterprise, поддерживает Postgres Pro Enterprise, но и PostgresPro Standard, но и ванильный PostgreSQL тоже (поддерживаются версии Postgres: 15 и новее).
В этой версии немало новых параметров и возможностей. В замечаниях к релизу и в документации все подробности.
Postgres Pro Enterprise Manager 2.5.1
Исправлена ошибка миграции с версии PPEM 2.4 или 2.4.1 на версию 2.5, которая могла приводить к ошибке фоновой обработки узлов репликации. При обновлении на версию 2.5.1 дополнительных действий не требуется. Если у вас не развёрнуты кластеры репликации, обновление с версии 2.5 не требуется. Подробности здесь.
Наследство (продолжение – без мха и патины)
Продолжим тему, с которой начали, в менее экзотичном контексте: Teamfront Achieves a 10x Faster Database Migration to Amazon Aurora PostgreSQL with Caylent Accelerate
Мигрировали с SQL Server. И не просто в Аврору. Тут не обошлось без Babelfish (в переводе Вавилонская Рыбка-толмач, подразумевается её способность переводить). Амазон её создал и сразу – было это осенью 2021 – открыл код. Рыбка конвертирует запросы SQL Server в запросы к Aurora PostgreSQL: Goodbye Microsoft SQL Server, Hello Babelfish. Это, однако, привело к большому возбуждению в Postgres-сообществе. Мы об этом писали в Postgresso 36:
Альваро [Эрнандес (Álvaro Hernández Tortosa)] привлекает Дилемму инноватора и задаёт ещё один интересный вопрос: хотим ли мы (то есть сообщество), чтобы Babelfish стала “MariaDB у PostgreSQL”?
Как бы то ни было, компания Teamfront навострила своего ИИ-агента Caylent на миграцию. И докладывает о результатах.
-
Перенесли 2500+ хранимых процедур.
-
Сократили сроки миграции с планируемого ~1 года до 4 месяцев.
-
Caylent Accelerate автоматически выявил 1 850 мёртвых душ: неиспользуемых процедур. Их поганой метлой исключили из миграции.
-
Caylent Accelerate сам обработал 430 процедур за 3 часа.
-
2-ногие эксперты доработали 214 сложных процедур (с динамическим SQL, специфичными функциями SQL Server и пр.).
Итого:
-
70% процедур – авто-конверсия через ИИ.
-
20% – ИИ + human-in-the-loop (разработчик корректирует)
-
10% – ручная доработка.
Образование
Книги
PostgreSQL 16 Оптимизация запросов – Павел Толмачёв
Книга «Postgres 16. Оптимизация запросов» знакомит читателя с работой планировщика: в ней рассказывается о методах доступа к данным и способах соединения, учим читать планы выполнения запросов, говорим о важности статистики и рассматриваем основные приемы оптимизации.
Основой послужил учебный курс «QPT. Оптимизация запросов», материалы которого Павел Толмачёв переработал в формат небольшой книги, чтобы нужная информация всегда была под рукой. Эту книгу удобно читать в метро или даже на остановке, когда нет возможности открыть ноутбук и обстоятельно погрузиться в изучение и эксперименты. Можно скачать в формате PDF.
Соавтор книги – Вибхор Кумар пишет, что книга уже вышла. Предисловие Эда Бояджяна (Ed Boyajian, член совета директоров и бывший гендир EDB). Так и есть: вот, на Амазоне. Это вообще EDB-шная туса: Марк Линстер побывал техдиром EDB, а Вибхор сейчас там в качестве Customer Experience Technical Fellow (даже не хочется переводить такую красоту). Но это ладно, он соавтор книги PostgreSQL 16 Administration Cookbook вместе с в том числе покойным главой 2-nd Quadrant Саймоном Риггсом (Simon Riggs).
Курсы
Опубликован новый курс DBS. Основы безопасности PostgreSQL 16. Курс рассказывает про конфигурирование подключений клиентов к СУБД и про управление доступом внутри самой СУБД. Предназначен в первую очередь для администраторов, поскольку рассматривает вопросы настройки экземпляра, но может быть интересен и разработчикам, позволяя взглянуть с другой стороны – в контексте безопасности – на использование ролей и распределение данных по схемам и таблицам. За основу взят модуль “Управление доступом” курса DBA1-13, который в DBA1-16 заменён обзорной темой. Исходный материал был существенно переработан, дополнен новыми темами и новинками версий 14-16. Курс разработали Алексей Береснев, Илья Баштанов, Егор Рогов и Павел Лузанов. Авторы готовы принимать тест для преподавателей.
ИТ и ВУЗы
ИТ-компании обязали поддерживать вузы, но это не так просто, как может показаться. Взгляд из МФТИ, ч.1 и ч. 2
Вообще-то, крупные компании это делают вполне добровольно. В том же МФТИ профессор Александр Тормасов преподаёт и преподавал, будучи тогда, ещё в конце прошлого века, начальником отдела перспективных разработок SWsoft (которая потом стала Parallels) – а что, дело доброе, всем на пользу, но и отличный способ фильтровать и хантить талантливых студентов. Ну а в этой 2-частной тедвайзеровской статье действительно говорят о серьёзных проблемах.
Статьи
Нет, не статьи. Одна статья – чтобы не перегружать мозг на майские праздники (зато в этом выпуске было много релизов).
How moving one word can speed up a query 10–50x
Авторы – Николай Самохвалов, это его блог, и Максим Богук (Maxim Boguk), он работает в Цапле Данных – Data Egret, возглавляемой Ильёй Космодемьянским (Ilya Kosmodemiansky, с Самохваловым они вели незабываемые ruPostgres.Вторники).
Максим обратил внимание на то, что два логически эквивалентных запроса с AND EXISTS vs. AND NOT EXISTS и AND NOT deleted vs. AND deleted приводят к огромной разнице в производительности.
Дальше обсуждение весьма тонких эффектов и, конечно, тесты.
Конференции
Уже скоро: 19-22 мая в Ванкувере. Вот расписание. Программный комитет конференции:
-
Мелани Плейгман (Melanie Plageman, Microsoft),
-
Дилип Кумар (Dilip Kumar, Google),
-
Джонатан Кац (Jonathan Katz, Databricks),
-
Пол Рэмзи (Paul Ramsey, Snowflake),
-
Джейкоб Чемпион (Jacob Champion, EDB).
Но есть ещё и особый Вторничный Комитет (Tuesday Planning Committee). Зачем? Видимо, из-за перегрузок. Заявки на Community Discussions (CDS) подаются до 14 апреля. Времени мало. Вторничный Комитет именно ими и занимается, а общее расписание планируется заранее основным Программным Комитетом – в среду и в четверг будут “обычные” доклады в 3 потока. В пятницу – unconference. Итак, Вторничный:
-
Клэр Джордано (Claire Giordano, Microsoft),
-
Кори Ханкер (Corey Hunker, Apple),
-
Матиас ван де Меент (Matthias van de Meent, Databricks),
-
Пол Джангвирт (Paul Jungwirth, Illuminated Computing),
-
Роберт Хаас (Robert Haas, EDB).
А за сессию постеров отвечает Андрей Бородин (Andrey Borodin, Yandex Cloud).
Можно заметить, что корпоративный состав заметно изменился: 2 от Databricks (столько же от классиков жанра – EDB), Snowflake, Apple.
А вот эта ещё не скоро:
Пройдёт в Валенсии 20-23 октября. 16-я по счёту, предыдущая была в Риге. Community Events Day будет в пятницу 23-го. Расписания пока нет.
Только что прошёл в Ереване – 30 апреля. Ждём впечатлений. Прилетел ли Брюс Момджан или докладывал через эфир? Тема доклада, кстати, интересная: Postgres as an MCP Server.
Ещё, например, в программе: Choose Your Own Adventure: Postgres 18 Demos Роберта Трита (Robert Treat, гл. инженер баз данных в Amazon Web Services); разработчица Postgres Professional Влада Погожельская доложила о When the PostgreSQL Planner Gets Too Optimistic: Index Choice and Join Estimates.
Организатор конференции – Эмма Сароян (Emma Saroyan).
Большая конференция прошла 26 апреля в Екатеринбурге (устроители пишут: главная ИТ-конференция на Урале) и произвела на присутствовавших постгресистов большое впечатление. Особенно масштабом: более десятка параллельных секций. Вот программа.
Секция Backend – двойная, с 14 докладами. Вторая начиналась с воркшопов, но дальше тоже доклады. Вот некоторые, чтобы у вас было представление об этой находящейся на периферии постгресового сознания конференции:
-
Админы скрывали это от нас годами: Rust + PostgreSQL в реальном проде – Роман Китаев, разработчик в Точка Банке,
-
Chaos Engineering для тех, кто в гробу его видал – Лев Алимов, стафф-инженер в Т-Банка (напоминаем, что в прошлом выпуске мы рассказывали немного о китайских инженерах хаоса, даже о Chaos as a Service),
-
Как backend-разработчику понять ML – Степан Ляхов, старший инженер по Golang в Ad Platform Team, MAGNIT TECH,
-
Как мы разрабатывали плагин sql для платформы Giga IDE – Владимир Ярославский, главный эксперт по технологиям в Сбере,
-
Распределённые системы: проблема часов, датацентры, сеть – Илья Солтанов, техлид в Точка Банке. В описанию в анонсе ну прямо таки философская заумь: «Распределённые системы: проблема часов, датацентры, сеть»Разберём причинность образования множества осей времени и какое влияние оказывают на них високосные секунды, затронем синхронизацию систем, а также какие трудности возникают при работе со временем.
-
Что я узнал из разработки агентов – Алексей Лобанов, техлид в SberDevices.
Пока всё, хороших праздников.
Автор: Igor_Le
