Ванила и энтерпрайз

PostgreSQL 15.2

Главное в PostgreSQL 15.2: залатали дыру в безопасности, связанную с механизмом шифрования Kerberos. Во время аутентификации модифицированный сервер при установлении шифрования транспорта может послать строку без терминального символа. libpq может выдать сообщение об ошибке, содержащее байты из буфера, которые теоретически могут оказаться чувствительной информацией, доступной злоумышленнику. Подробней и точней об этом можно узнать в описании CVE-2022-41862. Эта дыра существовала в версиях PostgreSQL 12-15. Вышли, соответственно, и версии 14.7, 13.10 и 12.14. А также и 11.19. Во всех этих версиях исправлено с полсотни багов.

Postgres Pro Enterprise 15.1.1

Выход Postgres Pro Enterprise 15.1.1 - это событие. Его собрат - Postgres Pro Standard 15.1.1 - вышел с отставанием всего всего в пару недель от выхода ванильного PostgreSQL 15.1. Но в Enterprise 15.1.1, вышедшем 1-го февраля, много нового: и того, чего нет в Standard, и чего не было в предыдущих Enterprise. О некоторых немного расскажем. Прежде всего это:

Облегчение миграции с Oracle: Пакеты.

Добавлена поддержка пакетов, которые по существу представляют собой расширенные схемы, помогающие организовать взаимосвязанные именованные объекты. Эта функциональность, знакомая пользователям Oracle, расширяет возможности PL/pgSQL, где появились новые модификаторы функций и соглашения, а также новые команды CREATE PACKAGE и DROP PACKAGE.

Маскирование данных — pgpro_anonymizer.

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

Типичные режимы работы анонимайзеров в нём реализованы:

• Выгрузка анонимизированных данных (Anonymous dumps): простое экспортирование замаскированных данных в файл SQL.

• Статическое маскирование (Static masking): удаление персональных данных в соответствии с правилами.

• Динамическое маскирование (Dynamic masking): скрытие персональных данных только от недоверенных пользователей.

  Доступны функции методов маскирования: рандомизации (randomization), фальсификации (faking), частичного скрытия (partial scrambling), перестановки (shuffling) и искажения (noise). Пользователи могут также разрабатывать свои функции. Но кроме этого есть и ещё один подход, который называется обобщение (generalization) и полезен для сбора статистики и анализа данных.

  От себя добавим, что существует PostgreSQL Anonymizer, который пожертвован сообществу компанией Dalibo. Там есть, конечно, эти способы маскирования. Но, по понятным соображениям, в такой чувствительной области как маскирование, многим и многим компаниям хочется иметь анонимизатор здешней разработки.

Кроме того обновились утилиты и расширения. pg_probackup Enterprise-версии сильно отличается от pg_probackup, вошедшего в Standard 15.1.1: прежде всего тем, что в Enterprise появилась поддержка протокола S3. А также совместимости с CFS при инкрементальном копировании, поддержка LZ4 и ZSTD.

Теперь официально поддерживаются процессоры Эльбрус, а Windows - наоборот.

Об этом событии уже написали на Cnews:

Создатели главной российской СУБД выпустили версию для легкой миграции с Oracle

Чтобы не повторять вышерассказанное, даю цитату:

Помимо вышеупомянутых новшеств и ряда оптимизаций для работы с крупными и высоконагруженными базами данных, Postgres Pro Enterprise 15.1.1 взяла от Postgres Pro Standard 15 новые функции обработки JSON из стандарта SQL:2016 в дополнение к ранее реализованному языку JSONPATH. Была реализована готовность к работе с расширением TimescaleDB (после официального объявления по поддержке его разработчиком PostgreSQL 15), добавлен модуль tds_fdw для упрощения миграции с MS SQL Server.

Коммитфесты

PostgreSQL 16: Часть 4 или Коммитфест 2023-01

Статья-обзор Павла Лузанова: новинки PostgreSQL 16 в "январском" (закрылся в начале февраля) коммитфесте. Одна из них, может, и не самая важная, но самая трогательная:

Прощай postmaster

«При старте сервера запускается процесс, традиционно называемый postmaster...» С похожей фразы начинаются многие учебные материалы, посвященные архитектуре PostgreSQL. Но имя процесса postmaster уже 15 лет как считается устаревшим, а реальное имя ― postgres. Упоминания о postmaster можно найти в документации, а в каталоге bin есть файл postmaster с символьной ссылкой на postgres. В 16-й версии пришла пора окончательно попрощаться с postmaster. Все упоминания о нем удалены.

Как обычно, Павел обозревает большинство принятых патчей - значимые. Их в этом обзоре 20. Среди них, например:

• Новый параметр: reserved_connections

• Новая функция bt_multi_page_stats

• pg_ident.conf: способы указания пользователя PostgreSQL

Six Interesting Patches From November's Commitfest

Крис Трейверс (Chris Travers) из Timescale решил обозреть 6 из новшеств Commitfest 2022-11. Да, об обзоре патчей этого коммитфеста от Павла Лузанова (англ. вариант тоже есть) мы успели рассказать в ноябрьском номере Postgresso, и там рассказано о 17, а не о 6. Но дело доброе - чем больше рассказывают, тем лучше. И есть серьёзное отличие: в статье Криса есть не принятые ещё патчи.

Например, патч 64-bit SLRU page numbers (independent part of 64-bit XIDs) даже в мартовском коммитфесте пребывает пока в статусе Waiting on Author. Или патч Support logical replication of DDL commands - он в мартовском ждёт ревью.

Это были 2 из 6. Вот ещё 4:

• Allowing the use of regular expressions for usernames in pg_hba.conf (принят)

• Allow grant and revoke of vacuum and analyze privileges on tables (принят)

• Transparent column encryption (ждёт ревью).

• Transparent Data Encryption key management patches (ждёт автора).

То есть Крис не скопировал подход Павла (что технически возможно: сейчас его обзоры сразу выходят и на английском), а развил по-своему. Тем лучше - больше поджанров хороших и разных.

Недавнее прошлое

Уже в январе Авинаш Валларапу (Avinash Vallarapu) сделал подборку нового за 2022: A Short Summary of 2022 in the Postgres World. Мне она не показалась удачной. Но там, например, есть список расширений, появившихся в 2022. В декабре Дэвид Феттер (David Fetter) в своём онлайн-еженедельнике собрал свои лучшие публикации за год - The Best of Postgres Weekly in 2022. Кирилл Боровиков из Тензора собирал написанные им публикации за год (#3). Ну и мы, напомню, пытались в декабрьском номере собрать самое интересное за 2022.

Будущее: AI (?)

Adventures in Embedding Postgres Schemas in GPT

Уильям Прайд (William Pride, со-основатель и CTO в Canvas) пишет: сейчас все пытаются заинтегрировать GPT в свои продукты. Как и зачем - не важно, можно решить потом. Трудно не согласиться.

Уильям показывает, как запускает простенький питоновый скрипт и GraphQL, чтобы соединиться с GPT, а после этого честно и терпеливо пытается научить сеть писать SQL-запросы, уточняя контексты. И получает такие:

> "Get the three users from the US who have paid the most money since February 2022"
SELECT c.name, c.email, SUM(ch.amount) AS total_amount
        FROM STRIPE.CUSTOMER c
        INNER JOIN STRIPE.CHARGE ch
        ON c.id = ch.customer_id
        WHERE c.shipping_address_country = 'US'
        AND date_part(MONTH, CAST(ch.created AS DATE)) >= 2
        AND date_part(YEAR, CAST(ch.created AS DATE)) >= 2022
        GROUP BY c.name, C.email
        ORDER BY total_amount DESC
        LIMIT 3;

Мы живём в удивительное время - восклицает автор, - на свой туманный вопрос я получил моментальный и работающий ответ. Не будем придираться к нюансам SQL, Потрясающе!

M&A

В разделе Слияния & Поглощения у нас здесь пока не официальная информация, а слухи. Но о слухах пишет, воспользовавшись милитаризованной метафорой, Коммерсантъ:

«Росатом» штурмует «Эльбрус» – Газета Коммерсантъ

По данным “Ъ”, после длительных переговоров структуры «Росатома» покупают МЦСТ — разработчика процессоров «Эльбрус». Источники “Ъ” на рынке микроэлектроники считают, что госкорпорация действует по поручению правительства, которое намерено сохранить оказавшегося в сложной финансовой ситуации важного разработчика.

На момент написания этого обзора официальных подтверждений не было.

Wraparound и 64 xid

Transaction ID wraparound: a walk on the wild side

Лоренц Альбе (Laurenz Albe, Cybertec) в некотором роде успокаивает постгрессистов: не так страшен чёртов Wraparound, как его малюют. Говорит при этом он об опасности потери данных, которая не так уж велика. А чаще всего вы даже не заметите, когда он произошёл - этот самый wraparound - говорит Лоренц. Но на самом деле из статьи ясно, что этот чёрт, вообще-то, действительно страшен. Не потерей данных, а остановом базы и/или переходом в однопользовательский режим.

Чтобы продемонстрировать, как бороться с проблемами обнуления (зацикливания) счётчика транзакций (это и есть wraparound), Лоренц запускает подготовленную транзакцию, она исполняется с 2-фазной фиксацией (коммитом) - как наиболее опасную для этой ситуации. Вместо того, чтобы запустить 2 млрд. транзакций, ведущих к классическому wraparound-у, он использует pg_resetwal, обманом установив ID транзакции в 2**23 - 10 000 000. Обманывает он и pg_xact. Затем исполняет SELECT pg_current_xact_id(); и получает предупреждение о надвигающимся wraparound-е и рекомендацию: запустите VACUUM по всей базе, откатите долгоиграющие подготовленные транзакции.

Лоренц продолжает играть с огнём, продвигается к транзакци 2**23 - 1 000 000. На этот раз СУБД отвечает:

ERROR: database is not accepting commands to avoid wraparound data loss in database "template1"
HINT: Stop the postmaster and vacuum that database in single-user mode.
You might also need to commit or roll back old prepared transactions, or drop stale replication slots.

Вот теперь, - говорит Лоренц - game over. Не совсем, но для нормальной работы. Однако, - добавляет он - совет перейти в одно-пользовательский режим не совсем точен.

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

Но авантюрист Лоренц идёт дальше.

Красная Линия! Вот она. То есть вот он - wraparound. Лоренц продвигается (перезапуская сервер) к транзакции 725, откатывает 726 и 727 и фиксируюет висевшую всё это время подготовленную транзакцию 728. И гасит сервер при помощи Ctrl+D. И цитирует Пророка Исайу: "Оживут мертвецы Твои, восстанут мёртвые тела!"

Хорошо это или нет в данном случае, и что делать или не делать дальше - об этом вы узнаете из статьи.

С этим переходим к статье Максима Орлова, разработчика Postgres Professional:

Устройство 64-битных счётчиков транзакций в Postgres Pro Enterprise

В Postgres Professional 64-битные счётчики появились в Enterprise уже в самой первой версии (то есть в 9.6, которая давно не поддерживается), так как с самого начала по просьбе клиентов эти версии создавались под сильно нагруженные системы. Поэтому на эту тему писали немало, и не только мы. Об этом говорил, например, Кирилл Боровиков из Тензора в статье Чего «энтерпрайзу» в PostgreSQL не хватает:  патч Александр Коротков запустил еще в 2017 году. В ядро он тогда так и не был включен, зато попал в Postgres ProEnterprise, откуда рано или поздно доберется и до "ванильного" ядра. Ну что же: пока, увы, не добрался. Вот-вот.

Макс Орлов, приложивший руки к разработке, рассказывает в том числе о деталях реализации. Не все из тех, кто слышал о 64-битных xid, знают о том, что выбирали разработчики из 3 вариантов реализации:

• "честные 64-битные ксиды": замена всех счётчиков транзакций на 64-битные;

• "через метод доступа": изменить формат страниц для конкретных таблиц, для которых пользователь считает это нужным;

• "хранение базы": для каждой страницы хранить некоторое смещение,
  относительно которого все ксиды на страницы должны быть вычислены.

Выбрали 3-й вариант - со смещением (= с "эпохой"). Но как это делается, как и где размещается служебная информация, какие плюсы и минусы - обо всём этом рассказывает автор, залезая, когда надо, во внутренности с помощью расширения pageinspect.

Но эта статья интересна и для тех, кто не собирается использовать Postgres Pro Enterprise, и даже тех, для кого проблема с wraparound как Гималаи для подмосковного туриста. Ведь автор подробно разбирает архитектуру Postgres, в статье много наглядных поясняющих схем и исполнимого кода.

Можно ли обновить базу с PostgreSQL на Postgre Pro Enterprise, при том, что такое фундаментальное свойство, как разрядность счётчиков реализовано принципиально разными способами? Да. Но нужна утилита pg_upgrade. В статье есть и об особенностях обновления.

TOAST

5mins of Postgres E3: Postgres performance cliffs with large JSONB values and TOAST

Эта 5-минутка из огромной серии Лукаса Фиттля (Lukas Fittl, pganalyze) посвящена TOAST. На самом деле это фактически растолковывание публике доклада Олега Бартунова и Никиты Малахова JSON Or not JSON на PGConf 2021.

Но обратимся к свежей статье Никиты, рассказывающего о том, что сам и разрабатывал:

Жарим TOAST в PostgreSQL

Никита начинает, конечно, с объяснения того, зачем TOAST нужен и как устроен. Плюсы плюсами, а минусы расписываются в главке, лихо названной Проклятие TOAST. Проклятье состоит из 8 подпроклятий. Механизм разрабатывался во времена совсем других типичных нагрузок, когда не было и в помине огромных JSON-ов. И дело не только в неэффективности, проблема серьёзней: мало того, что много ограничений и они усложняют жизнь как пользователям, так и администраторам. Они могут привести к непредсказуемому поведению СУБД!

Пункт #8 проклятья звучит почти безнадёжно: TOAST является частью ядра PostgreSQL, что серьезно затрудняет его модификацию и делает его абсолютно не расширяемым. Но можно пойти путём, который придумали архитекторы Pluggable Storage - они тогда добавили API для подключения других движков хранения.

Подход, предложенный и реализованный Олегом Бартуновым и Никитой Малаховым позволяет решить основные проблемы, связанные с TOAST, описанные в части 3, так как он отвязывает сам механизм от жестко заданного формата тост-таблиц, и ограничений, связанных с единственной тост-таблицей на все колонки базовой.

8-ми пунктам Проклятья противостоят 8 пунктов конструктивных. 8-й звучит так:

API позволяет вынести TOAST как отдельный модуль, что значительно облегчает его расширение и модификацию. Неизменным остается только штатный механизм, используемый по умолчанию, если не был подключен другой.

Binary data performance in PostgreSQL

Вышло так, что Лоренц Альбе пишет почти синхронно с авторами из Postgres Professional и на тему TOAST. Тосты его тоже пугают. Он даже пишет в подзаголовке: Blob - ночной кошмар производительности двоичных данных. Ну хоть производительности, а не непредсказуемости, как в статье Никиты.

Лоренц исследует 3 варианта хранения:

• вне базы данных (то есть как файлы в файловой системе)

• как Large Objects (старинный способ в PostgreSQL)

• в типе bytea (то есть фактически в TOAST)

Конечно, Лоренц обсуждает плюсы и минусы каждого способа. А потом создаёт таблицы и тестирует производительность, написав код на Java. Large Object проигрывает всем, а из файловой системы стриминг на порядок быстрей, чем из bytea.

Adrien Nayrat: PostgreSQL: TOAST compression and toast_tuple_target

Статья годовалой давности от Адриен Нейра (Adrien Nayrat) по теме некоторой кривизны механизма TOAST. Характерно, что автор выбрал для демонстрации тип jsonb. У него получается, что запрос с агрегацией работает с jsonb в 4 раза медленней, чем с другими типами (тестовые данные те же, менялся только тип). И даёт свою версию, почему так происходит.

Также он объяняет, зачем нужны параметры toast_tuple_target, toast_tuple_threshold и default_toast_compression.

The Surprising Impact of Medium-Size Texts on PostgreSQL Performance

Два с половиной года назад Хаки Бенита (Haki Benita, hakibenita.com) написал об интересном эффекте: провале производительности при работе со средними объёмами текстовых данных.

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

Образование

Всероссийский конкурс open source проектов

Открыт прием заявок. Это конкурс для школьников и студентов, который второй год проводит Кружковое движение НТИ в партнерстве с Postgres Professional и другими российскими IT-компаниями.

Заявки принимаются до 24 марта по трем направлениям: участники могут опубликовать собственный проект, внести значительный вклад в развитие одной из существующих open source разработок или внедрить свое решение в образовательную организацию — школу, вуз или колледж.

Имена победителей станут известны в апреле. Авторов лучших проектов ждет Code Review от экспертов ведущих технологических компаний, подготовка к публикации статьи о проекте, а для школьников предусмотрены дополнительные баллы к ЕГЭ, которые помогут при поступлении в ведущие технологические вузы страны.

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

Mastering PostgreSQL 15: Advanced techniques to build and manage scalable, reliable, and fault-tolerant database applications

Вышло 5-е издание книги Ханса-Юргена Шёнига (Hans-Jürgen Schönig, Cybertec) Продаётся в электронной версии для Kindle за $40 и в бумажной за $50.

Малютка в продаже

Печатная версия легендарной книжки-малышки поступила в продажу на сайте издательства «ДМК Пресс». До этого её распространяли бесплатно на мероприятиях Postgres Professional. Раздавать будем бесплатно и впредь. Но по многочисленным просьбам издали и для продажи. Речь о Postgres: первое знакомство, обновлённой до 15-й версии PostgreSQL.

"Малютка" выходит с 2015 года, авторы — эксперты отдела образовательных программ Postgres Professional Павел Лузанов, Егор Рогов и Игорь Лёвшин. И по-прежнему можно скачать бесплатно электронную PDF-версию на сайте в разделе Образование.

Understanding Databases eBook (MySQL, MongoDB, Postgres)

Пособие Джастина Митчела (Justin Mitchel, Linode), основателя Coding for Entrepreneurs, автора и ведущего Try IaC (Infrastructure as Code) и соответствующих видео. Поскольку Linode (приобретённая Akamai) занимается облачными вычислениями, то уклон здесь в облака, рассказывается много о (мульти)облаках, Kubernetes, Docker и прочем.

Building a Postgres Wire Protocol Server

Гевин Рэй (Gavin Ray) говорит, что у его джавовского туториала две цели:

• Продемонстрировать, как реализовать Simple Query Protocol, он же Простой протокол запросов (поток сообщений) Postgres на Java.

• Показать практические примеры, как использовать самые новые фичи JDK 17, например:

  • Records

  • Sealed Types

  • Pattern Matching for Switch

  • Virtual Threads aka Project Loom

  • Foreign-Function & Memory API (FMM) aka Project Panama

How to JSON in Postgres

Франческо Тизьё (Francesco Tisiot) написал пару десятков небольших статей в стиле howto. Делал он это постепенно, для недописанных оставляя место. На момент выхода этого выпуска не хватало 2:

• How to load JSON data in PostgreSQL? и

• How does JSON path work in PostgreSQL?

Есть уже в том числе removing null values from objects и prettifying JSON output.

Игрушки

Boson — разработка СУБД «с нуля»

Да, мы любим рассказывать об игрушечных базах, самодельных базах для души. Булат Башеев (Basheyev) из Астаны развлекался написанием виртуальной машины и компилятора под неё, теперь переключился на СУБД. Назвал её Boson. Это, говорит автор, легкая, встраиваемая документоориентированная база данных на С/С++. Хранить она будет документы формата ключ/значение (JSON).

В 1-й части рассказано о:

• кэшировании файлового ввода/вывода (CachedFileIO)

• логике работы алгоритма LRU Cache при чтении

• логике алгоритма записи (Fetch-Before-Write)

Во 2-й части дело доходит до таких "взрослых" вещей, как проверка целостности данных. Здесь же уже реализация RecordFileIO. И в обеих частях автор - воздадим должное - отдаёт изрядную часть текста/кода тестированию.

Микросервисы и бессерверные базы

Микросервис головного мозга. Рецепты качества

В статье Глеба Михеева, технического директора холдинга Skillbox, не упоминается Postgres, да и вообще речь не о базах данных. Зато микросервисная архитектура разбирается довольно подробно. Статья на основе доклада на "бунинской" (Олега Бунина) конференции, но доклад там не Михеева, а Михаила Трифонова (Сloud).

Postgres in a Microservices World

В своей презентации о микросервисах рассказывает некогда частый гость России Брюс Момджан (Bruce Momjian). Много примеров, много SQL. В финале презентации он предлагает ознакомится с книжкой Сэма Ньюмана (Sam Newman) Monolith to Microservices издательства О`Reilly - можно читать 10-дневную бесплатную трайл-версию, можно заказать бумажную на Amazon.

Эволюция инфраструктуры БД: от базы и приложения на одном сервере до потоковой репликации

Антон Маркелов ака @strangeman в блоге United Traders рассказывает о том как они создавали решение с супернеполиткорректным названием Superslave: взяли отдельный сервер, настроили на нем по слейву для каждого продакшн сервера на разных портах и создали виртуальную базу данных, объединяющую в себе базы со слейвов через postgres_fdw (foreign data wrapper).

Monolith to Microservices: Refactoring Relational Databases

Гэрри Стаффорд (Garry Stafford, главный архитектор решений AWS) пишет о 5 подходах к превращению монолитной РСУБД в микросервисы:

• Единая схема.

• Несколько схем.

• Несколько БД.

• Несколько инстансов СУБД.

• Несколько движков СУБД.

Сначала он создал демонстрационную базу, затем довольно подробно, с кодом, расписывает, как можно реализовать в микросервисах. В конце рассказывает о программной архитектуре Command Query Responsibility Segregation (CQRS).

Serverless Database Research and Problems Everyone Wants to Solve

Кэри Хуан (Cary Huang, старший разработчик в канадском отделении High Go) сравнивает Neon и Cockroackdb с точки зрения горизонтального масштабирования, кластеризации и отказоустойчивости. Кажется, первый. Признаётся, что это пока только по поверхности, только начало.

Эти базы устроены совсем по-разному. Кэри пишет, что Neon (в отличие от Cockroachdb) не масштабируется горизонтально по записи. Объясняет в 2 словах, как по-разному поддерживается согласованность, как хранятся данные.

Миграция

MigOps усиленно предлагает свои услуги миграции. И выложили серию статей по миграции с Oracle на Postgres. Есть кое-что и по MS SQL -> Postgres. Вот два примера.

Migration of Synonyms from Oracle to PostgreSQL

Джагадиш Пануганти (Jagadeesh Panuganti) рассказывает, как бороться с проблемой переноса из Oracle в Postgres синонимов. Synonym в Оракле - это не просто термин, а концепт, который не поддерживается в Postgres. В Oracle это псевдоним (алиас) объекта. Там к объектам можно обращаться из разных схем данных, не уточняя их принадлежность к схеме. В PostgreSQL автор предлагает в этом случае создавать search_path. Другой путь - создавать представления (views). У каждого из способов свои преимущества и недостатки.

Row level and Column level Security - Oracle vs PostgreSQL

В Oracle RLS (Row Level Security) реализовано как частный случай Oracle Label Security (OLS) - Безопасность на основе меток - мандатный доступ). К защищаемой строке добавляется столбец меток безопасности, каждая метка содержит уровень секретности. Пользователям присваивается уровень безопасности. В Postgres RLS (защиту на уровне строк) можно организовать командой

ALTER TABLE <tablename> ENABLE ROW LEVEL SECURITY; задав потом политики безопасности. Как это делается, показано в статье.

Безопасность на уровне столбца в Oracle работает в Virtual Private database (PVD). В Postgres можно, по словам автора, это сделать тоже двумя способами: через прямой доступ к таблице (используя команду GRANT) и, опять же, используя представления.

external_file v1.1

Это расширение, которое создал Доминик Лежандр (Dominique Legendre, BRGM), а поддерживает и Жиль Дароль (Gilles Darold), работающий теперь в MigOps. Нужно оно для того, чтобы воспроизвести функциональность типа BFILE в Oracle.

Миграция с Oracle на PostgreSQL (postgres.men)

Postgres.men, представленный Сергеем Томулевичем aka phoinix (о себе: Немного DBA, немного DevOps, побольше BackEnd), занимается миграцией с Oracle на Postgres, в том числе миграцией 1С. На сайте есть серия статей о миграции, например об ACL:

PostgreSQL ACL Server - здесь речь о настройке и постгресовой pg_hba.conf, и юниксового /etc/hosts, и pgbouncer.

PostgreSQL ACL Object - во второй статье серии ACL автор даже признаётся в некотором хулиганстве с целью позлить классово чуждых - админов (будучи в амплуа разработчика - см. вышенаписанное о postgres.men). Но кроме этого есть, например, функция, которую он придумал для такого случая:

если схема данных разворачивается или обновляется приложением, что потребуется временно выставить владельцем пользователя приложения на время разворачивания или обновления. После чего вернуть все на место.

Рекомендации по раздаче и лишению привелегий довольно категоричные. Например, вот для схем данных:

• CREATE — возможность создавать объекты в схеме — DDL, отключаем;

• USAGE — возможность доступа к объектам схемы — да, выдаем.

Pressly Goose 3.9.0 и Liam Staskawitcz Goose

Эта пара гусей - инструменты миграции. Базу можно преобразовывать инкрементальными SQL или скриптами Go. Goose 3.9 pressly/goose - это форк liamstask/goose. Форк отличается тем, что в нём нет конфигурационных файлов, дальше см. список различий. А отличия версии 3.9.0 этого форка в нюансах Go, в которые мы не рискуем вдаваться - там есть список.

OLTP => OLAP

Artie Transfer: Sub-minute data transfer from Postgres to Snowflake

Artie Transfer придуман компанией Artie Labs для того, чтобы данные из OLTP-базы перекачивались в Data Ware House радикально быстрей. Написан на Go, работает поверх Kafka. Сейчас он умеет брать данные из PostgreSQL либо MongoDB (и то, и другое с Debezium), а перекачивать в Snowflake или BigQuery. В блоге рассказывается, что это и зачем. Вот их страничка на гитхабе.

Производительность

pg-lock-tracer: A BPF-Based Lock Tracer

Помогает отследить блокировки, выявить потери производительности и взаимные блокировки (deadlocks). Использует технологии BPF / eBPF (Extended Berkeley Packet Filter), поддерживает PostgreSQL 12-15.

• pg_lock_tracer - отслеживает блокировки в PostgreSQL.

• pg_lw_lock_tracer - отслеживает лёгкие блокировки (LWLocks).

• animate_lock_graph - строит динамические графы блокировок, собирая вывод pg_lock_tracer.

Как пользоваться pg_profile для анализа статистики в Postgres

- об этом на ресурсе tproger.ru рассказывает Александр Булгаков. Он объясняет, что к чему, как установить, какой параметр что отображает, что означают столбцы таблицы. А вот визуализирует планы он внешним среством - Tensor Explain.

Интересно, что Александр предлагает использовать расширение pgpro_stats, входящее в Postgres Pro Standard/Enterprise, но тогда уж почему не установить модуль PWR (pgpro_pwr) из тех же дистрибутивов? Андрей Зубков, автор pg_profile, перейдя в компанию Postgres Professional, развивал его уже как PWR, используя, конечно, возможности pgpro_stats.

Железо и ОС

Как ускорить работу PostgreSQL (на IBM Z)

Статья для тех, кто хорошо знаком с Linux, а с Postgres - желательно, но не обязательно. Дело в том, что настройки, о которых рассказывает в PostgreSQL: Experiences and tuning recommendations on Linux on IBM Z Марк Байерль (Marc Beyerle, IBM, перевод Southbridge), в основном линуксовые, либо постгресовые, но системные - касающиеся кэша и пр.

Интересно здесь особенно то, что Linux не на x86, а на IBM Z - об этом пишут не часто. Сам Linux это всего лишь Ubuntu 16.04.2, на которой установлен старичок PostgreSQL 9.5.7, а исследуют производительность с помощью HammerDB 2.23 (текущая версия 4.6). Поэтому автор регулярно напоминает: есть полезные советы по настройке Linux, но обратите внимание, возможно они полезны для x86, а для IBM Z вредны!

An Introduction to PostgreSQL Performance Tuning and Optimization / PostgreSQL: Настройка и оптимизация производительности

Основательная статья Вика Фиринга (Vik Fearing) - оригинал и перевод (в корпоративном блоге Southbridge). Перевод разбит на части 1 и 2. Это разумно: статья огромная. Посвящена способам повышения производительности PostgreSQL и EDB Postgres Advanced Server (EPAS) с 10 по 13 версии. Начинается с аппаратного обеспечения, дальше вверх по стеку, оставив напоследок SQL-запросы. Напоследок = во 2-й части. А в 1-й - выбор процессора, памяти, диска, сетевой карты; повышение производительности в виртуальных машинах (какие параметры стоит отключить), настройка демона tuned, оптимизация файловой системы, Huge pages - это только настройка ОС. В 1-ю часть попадают и параметры PostgreSQL. Можно было бы побить и не на 2 части, а на 3 или больше!

PostGIS

Колоночная база данных в PostgreSQL 15 и факты о территории России по данным OpenStreetMap

Это лишь одна из большой серии статей Игоря Сухорукова по PostGIS и геоданным вообще, да ещё и с использованием его собственного проекта openstreetmap_h3. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing - утверждает автор. Все (кажется) статьи переведены ещё и на английский.

Колоночная база в этой статье - это Citus. Опять цитирую: Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus.

Вот данные загружены, индексы (в том числе индекс h3) построены. Дальше идут аналитичесвкие запросы и прочее.

Названия статей у этого автора звучат интригующе:

Две беды: дороги и полнота данных. Считаем протяженность дорог родины по данным OpenStreetMap или

Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap, или

Как в Северной Америке с дорогами и плотностью застройки? Работаем с 100Гб OSM данных в PostgreSQL.

Если углубиться в статьи более ранние, ГИС растворяются, мелькают JVM, JSON/XML, Elasticsearch - тоже интересно.

Некоторые релизы

patroni 3.0.0

Произошли серьёзные изменения. В этой версии официально объявлено об окончании поддержки RAFT. Также грядёт уже в следующей версии отказ от поддержки Python 2.7, поддержка будет начинаться с Python 3.7. Зато 3.0.0 интегрирована с Citus. Он может работать в отказоустойчивом DCS-режиме.

А вот интересные языковые расширения:

PL/Haskell 2.0

Таким образом модный функциональный язык Haskell стал ещё одним процедурным языком Postgres. Это произошло не сейчас. Но сейчас, в 2.0 появилась возможность исполнять SQL-запросы внутри функций PL/Haskell. Упростились процедуры установки и сборки. Инструкции по PL/Haskell здесь.

PL/Haskell относится к TRUSTED-языкам, работать с ним может непревилегированный пользователь. Репозитории rpm/apt здесь.

PL/V8

Разработчики в Sibedge опять проявили расторопность и выпустили свои сборки PLV8 3.1.5 почти одновременно с PostgreSQL 15.2. Напоминаем, что у Sibedge есть сборка по умолчанию и сборка с поддержкой сериализации BigInt, причём рекомендуют использовать образ с bigint, поскольку при работе с версией по умолчанию все значения BigInt конвертируются в строки.

Ещё:

pgslice: Postgres Partitioning 'As Easy As Pie'

Автор Эндрю Кейн (Andrew Kane) предлагает использовать его инструмент, написанный на Ruby примерно так: создаёте промежуточную таблицу; закачиваете туда данные из основной, которую собираетесь секционировать, она будет секционированная; меняете местами, делаете бэкап. И всё это из командной строки делает - pgslice с различными опциями.

Aquameta 0.3

Кажется, это нечто удивительное: Aquameta - стэк веб-разработчика, который весь внутри базы данных. Зачем - см. здесь. Aquameta состоит из 7 расширений PostgreSQL, каждое из которых соответствует слою или инструменту, типичному и привычному для веб-разработки. С той лишь разницей, что всё это внутри базы. Лёгкий Golang-демон управляет соединениями к базе и веб-сервером. Всё построено в основном на PL/pgSQL.

Ещё одна мета:

postgres-meta 0.60

Это RESTful API для работы с Postgres. Представляет собой легкий пулер соединений. Поддерживает работу с многими хозяевами баз (multi-tenant). Спонсор разработки - Firebase.

Пятнецы

Проект Райана Буза (Ryan Booz) не увял. Очередные. В 5-й серии - PGSQL Phriday #005 - Райан Ламберт (Ryan Lambert) в блоге RustProof Labs предлагает тему Relational and Non-relational Data: PGSQL Phriday.

Конференции

PGConf.Russia 2023

Пройдёт 3-4-го апреля в Москве в бизнесцентре Рэдиссон-Славянская. Программа находится в разработке.Если вы хотите выступить с докладом, заявку можно подать до 1 марта 2023 года. На сайте расписана зависимость стоимости билета от даты подачи заявки на участие (для студентов и преподавателей бесплатно).

PGConf NYC 2022

Опубликованы 35 докладов с нью-йоркской PGConf 2022-го года. Открывает Пэт Райт (Pat Wright), о будущем Postgres говорит Брюс Момджан (Bruce Momjian), Илья Космодемьянский делится худшими практиками.

Серия конференций организованая PostgreSQL Europe:

Nordic PGDay 2023

Регистрация открыта. Конференция пройдёт в Стокгольме 21 марта. Выложено расписание.

Будут выступать постгрессисты, нередко упоминавшиеся и в наших обзорах: Летиция Авро (Lætitia AVROT, EDB), Франческо Тизьё (Francesco Tisiot, Aiven), Ханс-Юрген Шёниг (Hans-Jürgen Schönig, Cybertec). И неизвестные нам имена, будет, например доклад Борисса Мейаса (Boriss Mejias, EDB) JSON In PostgreSQL.

PGDay/MED

Пройдёт 13-го апреля на Мальте (!) в Сент Джулиане. Заявки принимаются.

PostgreSQL Conference Germany 2023

PGConf.de 2023 - очередная немецкоязычная (и англоязычная, конечно) конференция пройдёт в Эссене 27-го июня. Регистрация ещё не открыта, а вот заявки на доклады принимаются. Устроители напоминают, что конференция пройдёт за 2 дня до Swiss PGDay 2023, так что удобно будет перемещаться с одной на другую.

Swiss PGDay 2023

Состоится 29-го июня в Рапперсвиле (это недалеко от Цюрихского озера). Продлится потора дня.

Комьюнити

Core Team Report: January 2022 - December 2022

Кажется, ничего особо примечательного. Но пусть будет здесь.

---

На сегодня всё.