В эти предновогодние дни перегружать вас техническими деталями не будем. И даже не всё в этом выпуске будет вертеться вокруг СУБД и SQL. Начнём, впрочем, с такой вот серьёзной новости:

Postgres Pro Enterprise 16.1.1

В этом релизе очень много нового. Разработчики говорят: в нём, пожалуй, самые значимые изменения лет за 5.

  • BiHA (Build-in High Availability): много говорили про "биху", много где демонстрировали на конференциях и вебинарах. И вот она в релизе. Встроенный отказоустойчивый кластер с физической репликацией, с синхронной и асинхронной репликацией узлов, с встроенным, аварийным переключением (built-in failover) и многим другим.

  • Администратор без доступа к данным - Администратор БД или даже Администратор СУБД не смогут ни модифицировать, ни читать конфиденциальные данные. Всемогущего суперпользователя postgres больше нет - разделение властей.

  • Приоритизация ресурсов (pgpro_rp) - возможность создавать планы управления ресурсами и переключаться между ними, настраивая для сеансов приоритеты использования процессора и операций ввода/вывода.

  • Системные пакеты-аналоги Oracle - существенно упрощают миграцию.

  • Появился новый составной тип - bfile. Он поддерживается расширением pgpro_bfile. Это нужно для доступа к внешнему файлу или S3 в технике, подобной оракловой.

  • Модуль aqo 2.0 сильно отличается от предшественников. Обновили sr_plan и pg_hint_plan.

  • То же можно сказать о pg_probackup 2.7.0 Enterprise и, соответственно, PTRACK Enterprise (и раньше в Pro Standard/Enterprise был один и тот же pg_probackup и PTRACK).

HR-задачки

Моя любимая задача для собеседований по программированию / My favorite coding question to give candidates (and why) - a coding interview question, from the viewpoint of an Google/Amazon/Microsoft interviewer

В блоге RUVDS.com перевод статьи Карлоса Аргуельеса (Carlos Arguelles). Карлос представляется так: за 25 лет работы в техгигантах (Big Tech) я провёл больше тысячи интервью (800 в Amazon в качестве Bar Raiser [то есть дающий финальное "добро"], пару сотен в Microsoft и около сотни в Google, где сейчас работаю.

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

Каждый раз, когда кто-то заходит на сайт, мы делаем запись в журнал, отмечая TimestampPageId и CustomerId. К концу дня у нас формируется большой файл со множеством подобных записей, и для каждого нового дня заводится новый такой файл.

Располагая двумя файлами журнала (для дня 1 и дня 2), мы хотим сгенерировать список «лояльных клиентов», отвечающих следующим критериям: (а) они посещали сайт в первый и второй день, (b) они посетили не менее двух уникальных страниц.

Моя любимая задачка по программированию для кодинг-интервью / My Simple Coding Interview Question

Вил Вен (Wil Wen), другой HR-щик из Google, провёл там в два раза больше интервью. Приводит и разбирает довольно любопытный пример, который интересен не столько сам по себе, сколько интересны способы извлечения из него сведений о претенденте. У перевода под 300 комментариев - ещё бы, эта тема очень волнует. Ну и даёт возможность поумничать :) К оригиналу при этом всего-то 2 комментария, зато в одном из них студент Пенсильванского Университета предлагает, пожалуй, более осмысленную формулировку задачи. В предыдущей статье 170 у перевода против 51 у оригинала, который просмотрели 5 тысяч.

Предновогодний Коммитфест

PostgreSQL 17: Часть 3 или Коммитфест 2023-11

На этот раз в статье-обзоре Павла Лузанова аж 21 пункт.

Появилась возможность создавать триггеры на события ON LOGIN и REINDEX - то есть на подключение к базе данных и при переиндексировании.

3 патча анализа статистики: pg_stat_statements: отслеживание времени появления оператора и сброс min/max статистики; pg_stat_checkpointer: статистика процесса контрольной точки и pg_stats: статистика столбцов диапазонных типов.

Планировщику тоже достались 3 патча: исключение лишних соединений таблицы самой с собой; статистика материализованных CTE и доступ к таблице с несколькими условиями.

psql: отображение привилегий по умолчанию - Павел посвятил этому 2 с половиной экрана примеров - целая небольшая статья.

А вот эти 2 пункта отдают дань совместимости с SQL: Новая функция xmltext и Поддержка AT LOCAL.

Предыдущие статьи серии: 2023-072023-09.

Новая книга

Мониторинг PostgreSQL - книга Алексея Лесовского, опубликована на сайте postgrespro.ru. На этот раз помогало издательство Бумба. В печатном виде книга должна появиться где-то к февралю. Картинки будут цветными, а формат - чуть больше, чем обычно, чтобы вместить графики и примеры кода.

Timescale подглядывает

в хорошем смысле: A Sneak Peek Into the State of PostgreSQL 2023

Появился отчёт Timescale по результатам их (почти) ежегодного опроса. Как всегда с красивой инфографикой.

Вышло 4 таких отчёта: в 2019, 2021, 2022, 2023 (2020 пропустили из-за ковида). На этой странице файлы со всеми четырьмя отчётами.

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

Из отчёта можно узнать, что 44% тех, кто имел дело с Postgres 15 и более лет, хотя бы раз становились контрибьюторами; что 67.8% никогда не посещали мероприятия сообщества даже виртуально; что 36.9% уже используют ИИ, но по-разному относятся к pgvector; что в пятёрку популярных языков разработки пробрался Go.

А вот список 10 самых популярных расширений этого года (вторая цифра - место в 2022):
1/1. postgis,
2/2. timescaledb,
3/3. pg_stat_statements,
4/7. uuid-ossp,
5/4. pgcrypto,
6/5. pg_trgm,
7/9. postgres_fdw,
8. pg_repack (новый, ушёл hstore),
9/8. pg_cron,
10/6. Citus.


В языках в пятёрке появился Go:
SQL 48.2%
Python 39%
JavaScript or TypeScript 24.5%
Java 20%
Go 17.3%

Языки: новые и суперстар

Будущее программирования: языки, зарплата и перспективы в 2024 году

В блоге Ланита Александр Николайчук как Artezio_team (руководит PR в Artezio) опрашивает представителей нескольких компаний:

  • Александр Тырышкин (AliExpress CIS),

  • Максим Сидоров (SberDevices),

  • Алексей Шарыпов (Playrix),

  • Илья Стешков (OZON),

  • Андрей Карсаков (Nau Engine),

  • Петр Туголуков (Xsolla),

  • Антон Мартынов (SimbirSoft).

Разговор был вовсе не о базах данных, но интересно же, что там на уме о разработчиков приложений. Много о новых языках. Я, например, мало чего слышал о Flutter/Dart. Но чаще всего звучат Go и Kotlin. Есть и статья по мотивам 1.5-часовой дискуссии, которую проводило Artezio: Программируй эффективно: как выбрать язык программирования под свои задачи?

Kotlite и Kotgres: генераторы SQL и JDBC кода на Kotlin для Sqlite и Postgresql

Макс Фарсиков в своей первой статье на хабре пишет в том числе о Kotgres - своей разработке для связывания Kotlin с PostgreSQL. Как минимум название красивое. Что-то на эту тему можно почерпнуть и из комментариев к этой статье.
Но вот что: PL/Kotlin никто, похоже не озадачился.

А вот plgo существует. Сейчас его поддерживает Владо Мадьяр (Vlado Magyar). Но не обновлялось расширение уже год. Сравните с другим прогрессивным языком:

plrust: A Rust procedural language handler for PostgreSQL

Тут всё свежее, поддерживается Technology Concepts & Design, Inc.

Но что, если вы сами собрались подключить некоторый полезный язык как процедурный в PostgreSQL? Как это сделать, рассказывает Марк Вон (Mark Wong, тогда ещё 2nd Quadrant, теперь EDB) на примере языка Julia:

Creating a PostgreSQL procedural language

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

А один из комментаторов напоминает, что учебный пример на эту тему уже был, но мало кто его уже помнит: PL/LOLCODE. Напоминает автор примера - Джошуа Толли (Joshua Tolley) aka eggyknap.

А вообще тем, кого интересует эта тема, я б посоветовал почитать и статью Ивана Панченко - она не об экзотических процедурных языках Postgres, но многое проясняет: PostgreSQL: Серверное программирование на «человеческом» языке (PL/Perl, PL/Python, PL/v8)

Python лёгкий. Go простой. Простой != лёгкий / Python is Easy. Go is Simple. Simple != Easy

Автор оригинала - Преслав Рачев (Preslav Rachev). Опять уже не удивляемся, что у оригинальной статьи 1 комментарий, у перевода на хабре - 43. В этой заметке не только "философские" соображения, но есть пример реализации на Python / Go простенькой задачи. Кроме этих двух упоминается - для контраста - и Rust.

А теперь обещанный superstar. Это COBOL:

Все деньги мира зависят от древнейшего языка программирования. Созданное на нем ПО ежедневно управляет триллионами долларов

Такие длинные заголовки сочиняют в CNews. Большая часть статьи предсказуема, но есть интересные подробности. Например, о создании сообщества коболистов. Финал статьи (как и кобола) тоже предсказуем, но подробности интересные:

IBM разработала программный инструмент на основе ИИ, который в автоматическом режиме переводит код COBOL на Java.

Проект IBM получил название Watsonx Code Assistant. По словам Скайлы Лумис (Skyla Loomis), вице-президента IBM по программному обеспечению IBM Z, сервис позволяет транслировать 80-90% COBOL-кода в Java. Оставшееся должен делать программист в ручном режиме, но IBM работает над усовершенствованием Watsonx Code Assistant.

Кстати о COBOL и legacy:

PostgreSQL on s390x

Постгрес на мейнфреймах - экзотика, но не экзотика-экзотика. В реальной жизни мне недавно попадалось обсуждение такого вопроса.

Кристоф Берг (Christoph Berg, Cybertec) напоминает, что для IBM-овского железа уже есть Debian-ы amd64 (Intel/AMD x86_64), ppc64el (IBM POWER) и arm64 (Arm aarch64). Мейнфреймовую программную инфраструктуру (build machine) для сборки версии сначала выложил Маристский Колледж, в начале этого года процесс запустили, но потом её пришлось допиливать сообществу. Чем автор при поддержке своей компании и занимался.

Неоны

Vercel Postgres is now generally available for Hobby and Pro users

Облачная платформа Vercel предлагает побетатестировать их разработку за умеренные деньги. [ (made its Vercel Postgres offering generally available)] А под платформой - Neon: многие разработчики предпочитают хранить реляционные данные в PostgreSQL, мы же, в партнёрстве с Neon предлагаем вам Vercel Postgres - первую бессерверную СУБД в облаке для фронтэнд-разработчиков - можно прочитать здесь.

Это, похоже, становится нередким явлением. Вот тут тур по js-ORM, а Postgres под ними тоже Neon (1:12 на видео):

I tried 8 different Postgres ORMs

ИИ

На грани ИИ: пример поиска и обработки векторов в PostgreSQL + pgvector

Это статья Игоря Сухорукова, который чаще пишет о PostGIS и OpenStreetMap. И здесь тоже можно увидеть красивые картинки с узнаваемыми контурами Москвы реки, Бульварным и прочими кольцами. Неудивительно: данными для примера служат гистограммы числа объектов детской инфраструктуры в окрестностях жилых домов в Москве.

Цель статьи: показать, как хранить, кластеризовать векторы и искать по ним в базе данных. Кластеризуются они здесь алгоритмом DBSCAN (основанная на плотности пространственная кластеризация для приложений с шумами). В докере устанавливается расширение pgvector, в табличке с 30-ю тысячами записей появляется столбец со скромным типом 11-мерный vector. Но это же демонстрационный пример. Сама кластеризация на Java.

Accelerate HNSW indexing and searching with pgvector on Amazon Aurora PostgreSQL-compatible edition and Amazon RDS for PostgreSQL

Джонатан Кац (Jonathan Katz) протестировал pgvector 0.5.1 на Amazon RDS, сравнивая его с 0.5.0. Заявлено, что в 0.5.1 улучшена работа HNSW, что Джонатан и успешно демонстрирует.

Introducing the azure_ai extension to Azure Database for PostgreSQL

На Azure 0.5.1 тоже доступна. Но тут ещё и специальное расширение azure_ai для работы с Azure OpenAI. Оно же даёт доступ к сервисам Azure AI Language - обычный вызов функции из SQL.

Баг Баунти - с чем её едят

БагБаунти с АстраЛинус или то, что нужно знать о защищённости защищённой ОС

Не понял: Линус опечатка или авторская ирония. Илья Матвейчиков, у которого, как он пишет, богатый опыт ковыряния ядра, решил свой опыт слегка монетизировать, поучаствовав в конкурсе, который объявила Группа Астра: найдите уязвимость в ОС и получите за это деньги (это и есть баг-баунти). Дальше следует история, полная приключений. Не перескажешь, читайте, если корыстно или бескорыстно интересуетесь.

Среди 150 комментариев есть и от собственно AstraLinux_Group - спокойный, сдержанный и многообещающий:

Уважаемые хабровчане, мы очень внимательно относимся к задачам устранения уязвимостей и выражаем благодарность всем участникам нашей программы багбаунти. <...> Развернутый технический анализ ситуации в настоящее время готовим, и он будет опубликован позднее. Ждем ваших новых отчетов, спасибо!

Хэппи-энд

Praise, Criticism, and Dialogue

Великий и совсем не ужасный контрибьютер Роберт Хаас (Robert Haas) призывает пишущих в мейлинг-лист hackers быть добрей друг к другу. Он заметил, что отношение положительных и отрицательных реакций на его патчи когда он был начинающим постгресистом и сейчас изменилось в худшую сторону. Одно из объяснений: если пишет опытный, известный разработчик, то, когда всё хорошо, все молчат, чего, мол, просто так сотрясать воздух, а вот если что не так - откликаются критикой. Поскольку отрицательные отзывы сократить нельзя - они обычно по делу, то можно поработать над этой дробью, внося положительные эмоции. Идею поддержали два Андреаса: Шербаум (Andreas Scherbaum) и Кречмер (Andreas Kretschmer).

Updates on trademark actions against the PostgreSQL community

Милые бранятся только тешатся. Бранились из-за торговых марок милый Альваро Эрнандес (Álvaro Hernández Tortosa) & Fundación PostgreSQL с милым Советом Старейшин - Core Team. Мы за этой историей следили с 2021 потому, что это не о сутяжничестве, и не о рейдерах тем более.

Альваро более 20 лет занимается Postgres, разработчик JDBC-драйвера и многого другого, выступал на PG.Day и PGConf.Russia. В 2021 он призвал к радикальным изменениям в руководящих структурах проекта, прежде всего ему не нравилась непрозрачность решений Core Team. Тогда же предложил разобраться с правовой основой торговых марок, да ещё и озаботился гендерным и расовым балансом. И получил не слишком широкую поддержку сообщества. В этом деле много любопытных подробностей, даже к Postgres-конференции на Ибице это имеет отношение. У нас об этом больше всего в Postgresso 34 и в Postgresso №7 (56), там же можно найти ссылки на документы тех времён.

Дело прошлое, к счастью. Fundación PostgreSQL уступила все торговые марки PostgreSQL Community Association (Канада), которая и занимается постгресовыми правовыми вопросами.


Ну что же, до встречи в 2024!

Комментарии (5)


  1. CrushBy
    29.12.2023 07:44

    Подскажите, а BiHA (или какие-то другие механизмы Postgres Pro) поддерживает такой вариант использования ?

    Приложение создает соединение к БД (узлу-последователю), которое используется только для чтения, НО создает, модифицирует и использует временные таблицы в течении какого-то времени. Потом (когда пользователь нажал Сохранить), необходимо все эти временные таблицы перекинуть на узел-лидер и там начать транзакцию, которая уже будет править основные таблицы, используя данные из временных таблиц. Хотелось бы конечно, чтобы это делалось "прозрачно" самим кластером (например, по получению команды начать транзакцию), но даже если нет, чтобы можно было бы на уровне подключения указывать он read-only или нет, и иметь возможность перекидывать временные таблицы между соединениями.


  1. trukhachev
    29.12.2023 07:44

    Часто слышу от коллег на работе, что пока они не готовы перевезти BI с Oracle на Postgres Pro, в силу того, что на том же железе (правда оно у оракла свое - экзадата) близкий результат от postgres не получить. Будет интересно почитать профессиональный анализ текущего состояния обоих база данных. А так же чего не хватает postgres, чтобы серьезно подвинуть Oracle в крупных инсталляциях, например банках.


    1. CrushBy
      29.12.2023 07:44

      А причем здесь BI ? Для BI есть свои СУБД, оптимизированные под массивное чтение и bulk-запись. Или речь все-таки про OLTP системы ?

      Но тут у PostgreSQL все не так уж и плохо. У нас есть клиенты из розничной торговли с OLTP-системами на 3.000 одновременно работающих пользователей, с таблицами по миллиард записей и 6ТБ БД. И это все без какой-либо кластеризации на обычном двух-процессорном сервере (с 96 ядрами и 512ГБ памяти) и SSD. И это даже не Postgres Pro (а ванильный PostgreSQL).

      Конечно, все зависит от запросов, и мы занимаемся их оптимизацией. Но, если нормально использовать, то в очень большом количестве приложений можно заменить Oracle на PostgreSQL. Понятно, что процессинг транзакций в банках - это целая отдельная сфера применения СУБД, но в общем числе задач она не значительна. И в банках во многих задачах можно без проблем использовать PostgreSQL вместо Oracle.


      1. trukhachev
        29.12.2023 07:44
        +2

        Ситуация на данный момент такова, что абсолютное большинство (если не все 100%) банков и страховых в стране сидят на Oracle так плотно, насколько это только возможно. Включая сам ЦБ.

        Что касается железа, кластера измеряются сотнями ядер, про диски и память я даже писать не буду.

        Из того, что я знаю, а я не профессионал в этой области, там:

        • нет компиляции pg_sql, а только интерпретация

        • нет встроенного шедулера, предлагается использовать средства ОС

        • нет пакетов

        • нет автономных транзакций

        Я поэтому и спросил у компании Postgres Pro какие проблемы в миграции клиентов с Oracle они видят, в части возможностей самой СУБД и как их решают.


        1. CrushBy
          29.12.2023 07:44

          Я думаю, что главная проблема в логике клиентов. "Не трогай, пока работает". Понятно, что миграция в любом случае создаст проблемы. Вне зависимости от того, справится ли PostgreSQL с этими задачами или нет.

          И на SAP подавляющее большинство продолжает работать и будут дальше работать. Просто так исторически сложилось, а не из-за каких-то технических вопросов. Зачем что-то менять, пока петух не клюнул ?