Postgresso #5 (42)

ИТ-инфраструктура — это как водопровод, без неё жизнь уже почти невозможна. И мы продолжаем выпускать Postgresso.

---

PostgreSQL 14.4

Экстренный релиз, исправляющий баг при индексировании в PostgreSQL 14. Незадолго до этого был даже специальный анонс:

PostgreSQL 14 out-of-cycle release coming June 16, 2022

Сразу после выхода первой же версии PG14 стало известно, что при выполнении команд CREATE INDEX CONCURRENTLY и REINDEX CONCURRENTLY могут незаметно попортиться индексы. Наконец, в 14.4 уже не нужно осторожничать, выполняя эти команды или проверять индексы при помощи команды pg_amcheck с флагом --heapallindexed (которая, к тому же, проверяет только btree-индексы).

Но этим исправления в PostgreSQL 14 отнюдь не исчерпываются. Список их в release notes не слишком короткий.


Notes On Updating To PostgreSQL 14.3, 13.7, 12.11, 11.16, And 10.21

Это фактически предыстория экстренного выпуска PostgreSQL. Джонатан Кац (Jonathan Katz) рассказывает о проблемах с CREATE INDEX CONCURRENTLY и REINDEX CONCURRENTLY. Он поясняет: баги вылезли, когда ещё в версии GA PostgreSQL 14 (14.0) появилась оптимизация VACUUM для этих команд. Сообщество решило откатить эту оптимизацию, посчитав риск незаметной порчи индексов серьёзным. И пообещал, что в 14.4 проблема будет решена.

Ещё в PostgreSQL 14.3 и соответствующих перечисленных версиях закрыли дыру, которая существовала очень давно, даже в уже не поддерживаемых версиях (то есть PostgreSQL 9.6 и старше). Непривилегированный пользователь (но уже имеющий PG-эккаунт) мог написать злонамеренный SQL-запрос и, запустив некоторые команды (Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER и pg_amcheck), получить при этом привилегии суперпользователя. Это было особенно опасно для Web-приложений и для систем с несколькими арендаторами (multi-tenant).

Джонатан поясняет, что именно починили в PostgreSQL 14.3, и советует, когда обновляться, когда не стоит, а когда проще приложить патч.
 
 

Конференции

PGConf.Russia 2022

PGConf.Russia состоится 20 и 21 июня 2022 года в Москве, в бизнес-центре гостиницы «Рэдиссон Славянская». Доклады и мастер-классы будут проходить в два потока в течение двух дней, в гибридном формате (онлайн и офлайн), но прежде всего очно — акцент на живом общении участников конференции.

Опубликовано расписание, есть отдельная страничка докладов.

Обещано участие Брюса Момджана (Bruce Momjian, EDB), с докладом Возможности PostgreSQL 15 (подробности пока не известны).

От нашего отдела образования Postgres Professional будут на этот раз целых 3 доклада:
Павел Толмачёв расскажет о своём исследовании работы оптимизатора при большом количестве таблиц, участвующих в JOIN (Коллапс в планах запросов. Достигаем и управляем),
Егор Рогов — о своей книге (Изнанка «PostgreSQL изнутри»),
Павел Лузанов — о новом в PostgreSQL 15 (PostgreSQL 15: на финишной прямой).

Темы очень разнообразны. Чтобы меньше пересекаться со следующим разделом (PGCon 2022), выберем здесь, скажем, такие доклады:

Как Patroni решает проблему потери слотов логической репликации? — Александр Кукушкин из Zalando расскажет, как Patroni решает эту проблему, используя исключительно возможности PostgreSQL.

Темпоральные типы и их использование — Иван Фролков (Postgres Professional, в этом выпуске ниже его же статья о триггерах): я часто встречал некоторый разнобой в обработке дат и времени: то у сторон не сходились отчеты за месяц, то суточные отчеты получались разные в Москве и Сан-Франциско, то еще чего-нибудь в таком же роде.

Ускорение баз данных нетрадиционными методами — Михаил Цветков обещает рассказать про новый, Storage-центричный подход к аппаратному ускорению дисковых баз данных.

Большие значения в PostgreSQL — Фёдор Сигаев (Технический директор Postgres Professional Разработка): PostgreSQL может предложить несколько вариантов сохранения больших значений, но все они обладают теми или иными недостатками.
 
 
PGCon 2022 (Канада)

Почитав расписание, можно увидеть, что там выступило немало знакомых нам участников конференций. Мастер-классов в этом году не было. Некоторые доклады 26-27-го мая в трёх потоках:

stream1:
26-е, 13:00 — 13:45. Breaking away from FREEZE and Wraparound, Масахико Савада (Masahiko Sawada, EDB);
26-е, 14:00 — 14:45. Develop an Oracle-compatible database based on Postgres, Грант Джоу (Grant Zhou, HighGo Software);
26-е, 15:00 — 15:45. Advanced database testing in CI/CD pipelines, Николай Самохвалов (Postgres.ai).

27-е, 12:15 — 13:15. Cloning Postgres databases on Kubernetes: how we designed database forks in a managed database-as-a-service, Олексий Клюкин (Oleksii Kliukin, Timescale).

stream2:
27-е, 12:15 — 13:15. Practical use case for OrioleDB, Александр Коротков, Аляксей Раманаў (Aliaksei Ramanau, оба OrioleDB) — до этого мы слышали интереснейшие теоретические беседы. Теперь обещана практика.

stream3:
26-е, 10:00 — 10:45. Highly efficient interconnection for distributed PostgreSQL, Дмитрий Урсегов, Фёдор Сигаев (оба Postgres Professional) — О подходах к шардингу, чего не хватает в postgres_fdw, как из N*M соединений сделать N+M.
26-е, 12:00 — 12:45. CREATE INDEX CONCURRENTLY implementation details, Андрей Бородин (Yandex);
26-е, 13:00 — 13:45. Common DB schema change mistakes, Николай Самохвалов (Postgres.ai).

27-е, 12:15 — 13:15. New TOAST in Town. One TOAST FITS ALL, Олег Бартунов (Postgres Professional) — Олег развивает и продвигает тему TOAST API и реализацию — TOASTER.

Отдельно добавлю о PgCon 2022 Developer Unconference (25-го мая):

Unconference — популярный жанр. Он пользуется успехом и на PGConf.Russia, например. Это просто сессия коротких докладов, темы которых заявляют прямо во время конференции. Одна из тем — PostgreSQL vs the block size [impact of block size on performance] получила в сообществе продолжение в рассылке hackers. Томас Вондра (Tomas Vondra, EDB) представил а анкоференции результаты тестов в духе TPC-B и TPC-H с переменным размером блоков данных и WAL. Получилось, что выигрыш до 50% был при малых (4 КБ) страницах данных, хотя, казалось бы, должно быть наоборот. В обсуждение включились многие авторитеты Postgres. Версия Томаса: этот результат связан с переходом с HDD на SSD. Чтобы убедиться, он протестировал и HDD/SSD, выводы подтвердились. Подробности в переписке.
 
 
Postgres Professional на HighLoad++ Foundation 2022

Генеральный директор компании Олег Бартунов, технический директор Фёдор Сигаев и старший разработчик Никита Малахов рассказали о новых достижениях в работе над технологией TOAST (The Oversized-Attribute Storage Technique или методика хранения сверхбольших атрибутов).

Подробности проведенной работы можно узнать из доклада.

Павел Лузанов рассказал о самых интересных обновлениях версии PostgreSQL 15.

После завершения деловой программы первого дня Иван Панченко, заместитель гендиректора Postgres Professional и профессиональный астроном, провел для всех желающих интерактивную лекцию «Астроликбез 2.0. Звезды, их рождение, жизнь и ....».
 
 

POC-DB, превью-релизы и игрушечные DB

Introducing AlloyDB for PostgreSQL

Google I/O анонсировала превью своей облачной PostgreSQL-совместимой DBaaS AlloyDB (alloy переводится как сплав). Утверждают, что на тестах она в 4 раза быстрей PostgreSQL на транзакционных нагрузках и в 100 раз быстрей на аналитических. И в 2 раза быстрей DBaaS Amazon.

В русле политики, стимулирующей миграцию с Oracle, появился и Database Migration Service — тоже пока превью (миграция схемы Oracle -> PG на базе Ora2Pg).

База автоматически настраивается, технологии ИИ и машинного обучения используются для управления vacuum, хранения и управления памятью, ускорения аналитических запросов и расслоения данных (data tiering).

Из последовавшей статьи Шешадри Ранганата и Рави Мурти (Sheshadri Ranganath
Engineering Director, оба числятся как Engineering Director, AlloyDB for PostgreSQL) известно, что такое ускорение на аналитических запросах достигается благодаря вертикальному хранению (Columnar engine). Вертикальные операции появляются и в EXPLAIN:

         ->  Parallel Custom Scan (columnar scan) on lineorder  (cost=20.00..879.88 rows=49016 width=4) (actual time=0.220..8.205 rows=36230 loops=3)
               Filter: ((lo_discount = 1) AND (lo_quantity = 1))
               Rows Removed by Columnar Filter: 19959121
               Rows Aggregated by Columnar Scan: 21216
               CU quals: ((lo_quantity = 1) AND (lo_discount = 1))
               Columnar cache search mode: native

В статье есть некоторые технические детали и наглядные схемы. Можно попробовать бесплатно.

SELECT ’Hello, World’. Serverless Postgres built for the cloud (Neon)

CEO молодой компании Neon (ранее Zenith) Никита Шамгунов сам анонсирует новый бессерверный Postgres. Желающих попробовать пока ставят в список ожидающих, но Никита обещает, что скоро доступ откроют для всех.

Сооснователи компании — Хайкки Линнакангас (Heikki Linnakangas, коммитер PostgreSQL) и Стас Кельвич, в команде много знакомых фамилий российских разработчиков. Из западных звёзд — Питер Гайган (Peter Geoghegan, основной (major) контрибьютор и коммитер PostgreSQL).

В архитектуре Neon подчёркивается разделение хранения и вычислений. Это бессерверная база, то есть вычисления происходят только тогда, когда их запрашивают, в остальное время вычислительные ресурсы не потребляются (scales down to zero on inactivity); все настройки и планирование вычислительных ресурсов, необходимые для запуска кода по требованию или по событию, скрыты от пользователей и управляются облаком. Написано на Rust, код будет открытый.

Небольшое информационное отступление: бессерверная СУБД теперь не такая уж редкость. В комментариях к заметке о Neon на ycombinator перечисляют:
Firestore (Firebase, NoSQL),
DynamoDB (Amazon,NoSQL),
CosmosDB (MS Azure, NoSQL),
FaunaDB (транзакционная RDBMS с GraphQL),
MongoDB (NoSQL),
кроме того есть распределённые РСУБД NewSQL, такие как CockroachDB и Planetscale (совместима с MySQL), у которых есть бессерверные планы.

С бессерверной идеологией связывают очередную *aaS-аббревиатуру — FaaS (F — Function). И на всякий случай приведу слова одного разработчика-скептика: At the moment I cannot imagine a more misleading IT buzzword than #serverless.

Сервисы с концепцией (compute scale-to-zero) существуют уже несколько лет: Cloud Run (Google), AWS Lambda (Amazon), fly.io, а вот таких СУБД пока не было.

Let's build a distributed Postgres proof of concept

Для этой вполне работоспособной POC-базы из 600 строк кода Фил Итон (Phil Eaton) использует 4 внешних библиотеки:
для парсинга SQL,
работы с протоколом Postgres,
для Raft,
для хранения метаданных таблиц и самих записей.

И это не просто база, а ведущий сервер, который принимает пишущие CREATE TABLE, INSERT и читающие SELECT, и реплика, принимающая только читающие.

В эти 600 строк входит создание серверов Raft, HTTP-сервера. Для хранения и обработки запросов подключается база bbolt, написанная целиком на Go. При хранении записи преобразуются в JSON. Протокол Postgres реализован на jackc/pgproto3, тоже написанном на Go.

toyDB

По этому поводу грех не вспомнить проект Эрика Гринакера (Erik Grinaker), который так и называется: toyDB.

Это тоже распределённая SQL-база (на Rust), которая была написана в учебных целях. Нешуточная игрушка, хотя и ни в коем случае не предназначенная для эксплуатации в серьёзных проектах:

• движок обмена сообщениями с голосованием и консенсусом по алгоритму Raft;
• транзакционный ACID-движок с MVCC и изоляцией на уровне снэпшотов;
• подключаемое хранилище с индексами B+tree и серверной частью на базе логов (log-structured backends, видимо, имеется в виду что-то вроде LSM, но это нуждается в уточнении);
• итерационный движок исполнения и оптимизации запросов (эвристическая оптимизация) с поддержкой путешествий во времени (time-travel support);
• SQL-интерфейс с проекциями, фильтрами, соединениями (JOINs), агрегацией и транзакциями.

Игрушка прошла тысячи тестов проверки функциональности — серьёзней многих неигрушечных проектов.

Supabase

Это молодая СУБД, но уже отнюдь не POC и не превью. Supabase позиционируется как опенсорсная альтернатива Firebase, которую мы упоминали выше в связи с Neon.

Пользователь получает базу Postgres уже с разграничением доступа к данным на уровне записи — RLS, Row Level Security);
получает 3 API, которые генерятся сразу из схемы: это Rust, Realtime (о нём в статье ниже) и GraphQL (через pg_graphql, опенсорсное расширение PostgreSQL);
с набором серверных глобальных Typescript-функций;
внешним хранилищем для больших файлов;
мониторингом (пока что это анализ логов PostgreSQL и Cloudflare).

Realtime существует у них с 2019-го, но RLS к нему прикрутили в декабре прошлого года: Realtime Postgres RLS now available on Supabase. Realtime — сервер, который слушает изменения в базе PostgreSQL и широковещательно транслирует их клиентам через соединения websocket. Теперь изменения будут отсылаться только тем клиентам, которым положено их знать по политике RLS в базе.

Компания продвигает своё решение и статьями: Postgres Auditing in 150 lines of SQL

Оливер Райс (Oliver Rice, supabase) показывает, как эти 150 строк кода собирают и анализируют историческую информацию. Аудит включается соответствующей функцией:

SELECT audit.enable_tracking('public.members');

Для наглядности Оливер ввёл в свой пример колонки с JSONB, BRIN-индекс.

Надо сказать, это не совсем тот аудит, который требуется в случаях, когда отслеживание всех изменений критически важно. Здесь нет специфических для аудита технических приёмов на случай, когда, скажем, транзакция откатилась. Напомним, что есть на этот случай AUTONOMOUS TRANSACTIONS: такая транзакция, выполненная из основной, родительской транзакции, может фиксироваться или откатываться независимо от фиксирования/отката родительской. О том, как это работает, подробно было в Различия Postgres Pro Enterprise и PostgreSQL.

Malewicz (клиент)

Автор Малевича, Максим Грамин (см. ниже его страницу Awesome DB Tools) так говорит о своём проекте:

Malewicz это очередной графический клиент для БД, с помощью которого вы сможете навигироваться по схеме БД, строить диаграммы, следить за производительностью и общим состоянием БД. Но ключевая особенность заключается в том, что инструмент в первую очередь заточен на расширяемость — DBA, разработчики, перфомансеры, data people сами отлично знают, что им нужно и в каком виде, таки зачем им мешать? А Malewicz предоставляет всё необходимое для этого, остаётся только написать нужный запрос в отдельном sql-файле и jinja2-шаблон для визуализации.

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

Также на страничке проекта говорится, что Малевич супрематический: нужно только знание SQL и немного HTML, что быстрый AJAX-интерфейс написан на Turbo без единой строчки JavaScript. Можно собрать из исходников, доступно и в docker.

PostgreSQL HTTP Client

Это расширение, которое называется просто http, написал Пол Рэмзи (Paul Ramsey). Свою цель он обозначил так:

Вам пригодился бы триггер, вызывающий web-сервис? Чтобы он мог вернуть результат запроса, либо просто дёрнул сервис, чтобы тот обновил состояние базы. Вот для этого и нужно расширение http.

Самая свежая версия — 1.5.0, собирать надо из исходников. Есть пакет для Windows, но автор его не поддерживает.

Zero-downtime schema migrations in Postgres using Reshape

Заодно POC-утилита миграции: Фабиан Линдфорс (Fabian Lindfors) рассказывает о своей экспериментальной (POC) разработке reshape, которая поможет мигрировать не 1:1, а меняя архитектуру таблиц: например, столбец массивов можно преобразовать в отдельную таблицу.

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

Пока что главное для автора — получить отзывы.
 
 

Всё о тостерах

New TOAST in town: the “pluggable TOAST API” concept and what it means for the community

На эту тему мы писали в том числе в предыдущем выпуске. Но в этой небольшой заметке Олег Бартунов, гендир Postgres Professional, подытоживает цели и текущие достижения в реализации TOAST API и — это новое — проговаривает коммерческие выгоды сообщества от будущего использования этого API. Идея в том, что разработчики смогут писать свои расширения под TOAST API, не дожидаясь от сообщества принятия нужных патчей. При этом они смогут лицензировать свои расширения (подобно тому, как это сделали недавно Elasticsearch, MariaDB и MongoDB, представив лицензию SSPL — Server Side Public License). Этим стимулируя облачных провайдеров не просто пользоваться плодами open source, но и делиться прибылью от новшеств.

Что касается технической стороны, то сейчас компания реализовала 3 тостера: default toaster для обратной совместимости, jsonb_toaster и bytea_toaster. В статье есть графики, демонстрирующие очень существенный выигрыш в производительности. К тому же в статье есть ключевые ссылки на презентации по этой теме. Собираем их здесь в одном месте:

One TOAST fits ALL: JSONB TOASTER

Об этом мы писали в прошлом выпуске, но повторим, так как отражает цели и средства:
На летний коммитфест ушёл предложенный Pluggable toaster. Это API для TOAST, продолжение идеи AM API для методов доступа. Если воспользоваться таким API, то можно сделать работу с TOAST для некоторых типов данных гораздо более эффективной, так как внутренняя структура такого TOAST предсказуема.

Pluggable TOAST or One TOAST fits ALL — доклад Олега Бартунова, Фёдора Сигаева и Никиты Малахова на Highload++ Foundation.

JSON(B) Roadmap — там есть о GSON (Generic JSON) API, важной части разработки. Можно будет работать с JSONB как с JSON, разница будет под капотом.

New TOAST in Town: One TOAST Fits All;
Pro JSONB на Стероидах;
Appendable bytea TOAST;
Understanding JSONB Performance;
Scaling JSONB;
Appendable bytea TOAST;
Pluggable toaster — на коммитфесте.
 
 

Рынок

Обзор IT-Weekly

Postgres Professional и Loginom Company (российский разработчик решений в области аналитики данных) заключили соглашение о технологическом партнерстве. Сотрудничество направлено на обеспечение совместимости продуктов и позволит предлагать комплексное решение по хранению, обработке и анализу данных, включающее функционал флагманских продуктов компаний – СУБД Postgres Pro и аналитической low-code платформы Loginom.

Диверсификация сертификации

Заместитель генерального директора Postgres Professional Иван Панченко представил несколько инициатив. Одна из них является аналогом Google Summer, откуда исключили российских участников. Целевая аудитория — студенты, также идет отбор менторов. Финансирование проекта будет проводиться за счет средств компаний-участников, в перспективе — и за счет грантовых программ. Официальный анонс этой инициативы состоится до конца июня текущего года.

Также Иван Панченко объявил об инициативе создания Школы системного программирования и компьютерных наук. Базой для нее станет или вуз, или консорциум компаний. Это является предметом переговоров, которые уже идут. Обучение будет ориентировано на решение практических задач, а преподавательские кадры будут рекрутироваться из индустрии. При этом задана очень высокая планка для отбора потенциальных учащихся.
 
 

Книги, онлайн-справочники, жанр for dummies

Postgres Books

В списке Postgres Books 2 книги за 2022:

PostgreSQL — Architecture et notions avancées
Авторы — Гийом Леларж и хорошо известный у нас Жульен Руо (Guillaume Lelarge, Julien Rouhaud). На французском.

PostgreSQL 14 Administration Cookbook
Авторы — основатель и руководитель 2ndQuadrant (теперь внутри EDB) Саймон Риггс и Джанни Чиолли (Simon Riggs, Gianni Ciolli). Язык английский.

Ну а мы, конечно, добавим постгрес-хит этого года — PostgreSQL изнутри Егора Рогова. Уже появляются отсылки к ней в комментариям на хабре.

awesome

В февральском выпуске Postgresso мы давали ссылку на awesome-postgres — это список софта, библиотек, инструментов и ресурсов (следовали за awesome-mysql). Автор Малевича, Максим Грамин (см. выше) собрал ещё один awesome: Awesome DB Tools. О PostgreSQL там немало.

На всякий случай напоминаем о страничке русской версии postgres-wiki, где собрано немало ссылок, относящихся к PostgreSQL в России и на русском.

Jeremy Schneider: Latest PostgreSQL Happiness Hints

Джереми Шнайдер составил табличку (взята из его tweeter), которую назвал Latest PostgreSQL Happiness Hints: здесь я собрал коллекцию вещей, которые необходимы любому стеку PostgreSQL, готовому к эксплуатации. Большая часть из этих вещей общепризнана, но некоторые ближе к моим субъективным мнениям (например, масштабирование и динамический пул соединений). В основном идеи не оригинальны.


Postgres Constraints for Newbies

Статья Елизаветы Кристенсен (Elizabeth Christensen, Crunchy Data) действительно for newbies, 4 dummies, но она небесполезна и для вполне зрелых пользователей. Например, не сразу сообразишь, как посмотреть, какие вообще ограничения (то есть CONSTRAINTS) имеются в вашей базе. А здесь готовый запрос. Более подробная главка про ограничения исключения. И некоторые советы в конце. Для демонстрации Елизавета взяла процедуру бронирования номеров.

Заметим в скобках: об ограничениях недавно появилась статья Ивана Фролкова из Postgres Professional: Trying to gain peace of mind by using constraints in PostgreSQL

Это статья не для ньюбис, но, пожалуй, для всех — от ньюбис до специалистов с опытом многих и многих проектов. Большой опыт Ивана именно и подвигнул его на написание этой статьи (на английском, скоро появится русский вариант), это выстраданная статья. Цитата:

Однажды я был свидетелем того, как разработчик при вычислении курсов криптовалют сделал ошибку, которая привела к тому, что по некоторым платежам выслали $300,000 вместо $300. А была бы простейшая занудная проверка для пары отправитель/получатель, высланная сумма не должна превышать 1/10 от полученной, и много нервов сэкономили бы.

Почему паранойя это плюс для серьёзного бизнеса? Почему гибкость не всегда преимущество? Когда нужны экзотические ограничения? Ответы в статье.
 
 

Опросы

The 2022 State of PostgreSQL Survey Is Now Open!

Timescale опять опросили своих разработчиков (с этой странички можно добраться до статистики самих респондентов) и составили обзор (в прошлом году из-за ковида обзор пропустили — предыдущий был в 2019-м году). С ним эта небольшая заметка и сравнивает, показывая динамику. Например, за эти 2 года процент тех, кто пользуется Postgres чаще и намного чаще, вырос с 52% до 67%.

Интересные изменения происходят в облаках. В 2019-м 51% пользователей PostgreSQL разворачивали их в AWS, а 46% полагались на автоматическое управление ресурсами в ЦОД (self-managed data center). В 2021 автоматическое управление лидирует, но 36.4 % разворачивают PostgreQSL у себя, 35.3% — в частном ЦОДи 32.8% в публичном облаке.

Вот сам обзор: 2021 State of PostgreSQL survey results. Как всегда шикарно оформлен, и, главное, вопросы интересные. Начинается с традиционного для них вопроса: как вы говорите/пишете? Постгрес или Постгрескюэл? Или ПиДжи? (Постгрес — 65%).
 
 

ARM

Не смотря на проблемы Байкал Электроникс с ARM, эта тема актуальна для российских разработчиков (ну а мы ведь делаем наши ежемесячные обзоры для всех русскочитающих постгресистов, живущих там, где им нравится).

Economical Comparison of AWS CPUs for MySQL (ARM vs Intel vs AMD)

Да, MySQL, а не PostgreSQL, но тема сравнения ARM с Intel (и AMD) интересна сама по себе. Ник Кричко (Nik Krichko) из Percona осенью прошлого года опубликовал серию тестов производительности: Comparing Graviton (ARM) Performance to Intel and AMD for MySQL (Part 1, 2, 3). Измеряли производительность при помощи перконовского PMM (Percona Monitoring and Management), который умеет работать MySQL, PostgreSQL и MongoDB. В двух словах: ARM проигрывает по производительности (иногда в 1.5 раза, но не больше), зато обходится дешевле. В этой статье автор решил остановиться на стоимости подробней.

В статье много красивых графиков. А совет автора такой: исходите из нагрузки. Сколько вам нужно запросов в секунду? По графикам выберите самый дешёвый вариант vCPU, обеспечивающий такую нагрузку.
 
 

Сюрпризы Linux

Is Your Linux Version Hiding Interrupt CPU Usage From You?

Статья написана больше года назад и прямого отношения к PostgreSQL не имеет. Но актуальность её доказана обращением к ней буквально на днях нашей службой поддержки. Если выключен параметр CONFIG_IRQ_TIME_ACCOUNTING, то аппаратные прерывания не видны. Мы можем видеть, что процессор почти всё время idle, а он на самом деле работает на пределе возможностей.

Introducing nodetop

Кстати об ОС: Фритс Хоогланд (Frits Hoogland) пишет в блоге YugabyteDB об утилите, которую он сделал для диагностики проблем с производительностью. Она использует расширение node_exporter для сбора статистики. Nodetop написана на Rust. Утилита собирает данные об использовании CPU, IO. Похоже на sar, iostat и dstat, но показывает всё это сразу и для нескольких серверов одновременно. Гранулирование по времени настраивается.
 
 

Оптимизация

Pipeline Mode For Better PostgreSQL Performance On Slow Networks

В PostgreSQL 14 появился режим конвейера (pipeline mode) для libpq C API. Это особенно полезно, когда надо выжать приличную производительность по сети с большими задержками. Задача для немалого числа людей и компаний очень актуальная. Особенно это важно для тех, у кого база в облаке.

В технологичной статье Лоренца Альбе (Laurenz Albe, Cybertec) есть объяснение протокола расширенных запросов (extended query protocol) и наглядные диаграммы, показывающие разницу между работой в конвейерном и обычном режиме; SQL-запросы и даже куски C-кода, результаты тестов.

Интересующимся расширенными запросами советуем посмотреть и объяснения Егора Рогова в статье Запросы в PostgreSQL: 1. Этапы выполнения.

Ну а Лоренц ссылается на статью своего коллеги Ханса-Юргена Шёнига (Hans-Jürgen Schönig) о задержках: PostgreSQL: Network Latancy Does Make A Big Difference.

А вот ещё одна его статья Лоренца: Help, I Cannot Cancel A PostgreSQL Query!

Что делать в случае, когда просто отменить запрос не получается. Как такое вообще может случиться? Лоренц разбирается с сигналами PostgreSQL, перечисляет причины, по которым запрос не может быть прерван. Советует не злоупотреблять kill -9, делать это только в крайних-крайних случаях. Предлагает пути завершения запроса, не желающего прерываться, показывает, как работать с дебаггером (gdb).

Postgres Query Optimization: LEFT JOIN vs UNION ALL

Дэвид Кристинесен (David Christensen, Crunchy Data) рассказывает, не особенно вдаваясь в устройство оптимизатора, как можно получить выигрыш во времени отклика на порядок: 1мс против 2-3с в оригинальном запросе. Он рассматривает довольно специфический случай с несколькими нюансами, но случай представляет интерес.

Там в оригинальном варианте есть LEFT JOIN. В новом запросе он как бы разбивается на 2 части: в одной обычный (INNER JOIN), в другой UNION ALL.

Дэвид ссылается также на статью в блоге Crunchy Data: Query Optimization in Postgres with pg_stat_statements, которую, мол, полезно прочитать перед тем, как браться за оптимизацию. А мы посоветовали бы и ознакомиться с интересной и глубокой статьёй Павла Толмачёва Как работает оптимизатор PostgreSQL при большом количестве таблиц в запросе, которую представляли в предыдущем Postgresso.
 
 

Иерархии

Hierarchical Structures in PostgreSQL

В блоге Аны Хобден (Ana Hobden) консалтинговой микрокомпании Hoverbear (парящий, летающий медведь или медведица) появилась ещё в 2020, но тема интересная. Как отобразить и как работать со сложными иерархиями в неиерархической СУБД PostgreSQL. У Аны в примере команды в организации, многие из которых имеют родительские команды.

Первое решение: материализованное представление (Materialized View) и рекурсивные CTE. Другое, где меньше кода, — использование расширения ltree, специально созданного для более эффективной работы с иерархическими данными. Установив его, можно работать со специальным типом ltree.
 
 

pgAdmin 4

pgAdmin 4 Architecture

Не часто говорят об архитектуре этого популярного инструмента. Объясняет со схемками Йогешь Махаджан (Yogesh Mahajan, EDB). Кстати, недавно вышла версия 6.10: pgAdmin 4 v. 6.10. В этой версии радикальных изменений нет. Добавилась возможность менять ширину колонок в таблицах Dashboard.
 
 

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

PostgreSQL Anonymizer 1.0

Мы немного говорили об этом расширении Dalibo, но тогда оно было в экспериментальной фазе. Теперь готово (утверждают создатели) к промышленной эксплуатации.

PostgreSQL Anonymizer прячет или заменяет персональные данные (personally identifiable information — PII), или коммерческие данные в базах PostgreSQL. Поддерживает 3 стратегии анонимизации:

• динамическое маскирование (dynamic masking),
• статическое маскирование (static masking) и
• anonymous dumps (просто экспорт маскированных данных в SQL-файл).

Расширение предлагает набор функций маскирования, таких как
Substitution, Randomization, Faking, Pseudonymization, Partial Scrambling, Shuffling, Noise Addition and Generalization. Названия их говорят за себя, на этой страничке документации есть ссылки.

Вот последняя версия и CHANGELOG, анонимайзер на гитхабе, здесь инструкция по инсталляции.

WAL-G 2.0.0

В этом релизе с двумя нулями много нового. По дельта-бэкапам он обратно несовместим с предыдущими версиями: дельта-бэкапы новой версии нельзя восстановить версией 1.1 или более ранними.

По теме Postgres 12 новых пунктов. Например, поддержка восстановления бэкапов pgBackRest (beta), команды wal-restore и delete garbage, возврат настраиваемого кода ошибки, когда WAL-файл отсутствует.

Много пунктов касаются S3. В этом релизе появилась поддержка физических бэкапов Greenplum.

temBoard 7.11

Это инструмент мониторинга, оптимизации, можно конфигурировать сразу несколько инстансов PostgreSQL. Состоит из легких агентов и сервера, который управляет агентами, собирает метрики и визуализирует их через Web-интерфейс.

В новой версии появилась возможность передавать метрики в пакетном режиме, что сильно увеличило производительность; можно журналировать времена отклика на HTTP-запросы; ключ агента проверяется при регистрации. Для быстрого знакомства выложен docker-compose.yml-файл: можно опробовать temBoard на нескольких PostgreSQL-кластерах.

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