Data bases

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Главное событие

EDB Completes Acquisition of 2ndQuadrant

EDB поглотила 2ndQuadrant. Теперь всё будет под брендом EDB. Руководить будет CEO EDB Эд Бойджан (Ed Boyajian), а великий и ужасный Саймон Риггс (Simon Riggs) из 2ndQuadrant получит титул PostgreSQL Fellow и будет PG-евангелистом и техническим стратегом.

Не будем считать деньги, а напомним о вкладе в сообщество от обеих уважаемых, почтенных компаний (EDB основана в 2004-м, 2ndQuadrant в 2001-м).
Если считать по участникам основных разработчиков PostgreSQL (core team), то счет 2:1 в пользу EDB: Bruce Momjian и Dave Page (PgAdmin) от EDB, против Peter Eisentraut от 2nd Quadrant. Брюс Момджан напомнил о неписанном правиле сообщества: в core team не должно быть больше половины разработчиков из одной компании. А в новом EDB 3 из 5.

Если считать по главным контрибуторам (major contributors) в код PostgreSQL, то маятник качнулся в другую сторону: 5: 3 в пользу 2ndQuadrant Andrew Dunstan, lvaro Herrera,
Petr Jelinek, Simon Riggs, Tomas Vondra против Devrim Gndz, Robert Haas, Amit Langote.
Но у 2ndQuadrant есть ещё и один Заслуженный хакер (hackers emeritus) Marc G. Fournier.

И ещё: Эд Байджан в своей статье на сайте 2ndQuadrant ссылается на COVID-19 как на силу, направляющую пользователей в сторону PostgreSQL, о чём говорится даже в некотором специальном исследовании.

Покупку уже успели обсудить на Postgres-вторниках Николая Самохвалова и Ильи Космодемьянского. Брюс Момджан оценил событие так: в целом положительно, но риски есть. Кроме изменений в core team ещё и минусы консолидации (меньше выбор, слабее конкуренция) и риск того, что процесс пойдёт и дальше: больше шанс, что какая-нибудь крупная компания может захотеть поглотить EDB.

PostgreSQL 13

Это произошло! Почти сразу после релиза-кандидата вышел и официальный релиз.

О том, что в нём будет, писали уже много, и мы здесь процитируем список новшеств вместе с соответствующими им статьями, который составили Postgres Weekly:

• Дедупликация индексов B-tree Deduplication in PostgreSQL V13 B-tree indexes (статья Cybertec)
• Параллельный VACUUM Parallelism comes to VACUUM (статья 2ndQuadrant, то есть уже EDB)
• Доверенные расширения An Overview of Trusted Extensions in PostgreSQL 13 (опять Cybertec).
• Для SELECT gen_random_uuid() теперь не нужно расширение.
• CREATE STATISTICS теперь помогает планированию при операциях IN/ANY. (официальная дока)
• postgres_fdw поддерживает аутентификацию с сертификатами.
• Улучшение работы с протоколом TLS TLS Related Updates in PostgreSQL 13 (статья High Go).
• Разное Hidden Gems of PostgreSQL 13 (статья Crunchy Data)

Там же, на Crunchy, есть и статья Грега Смита (Greg Smith) PostgreSQL 13 Upgrade and Performance Check on Ubuntu/Debian: 1.6GB/s random reads. Статья этого уважаемого автора собрала, однако, некоторые ложки дёгтя претензии к методу оценки производительности. В конце статьи мы видим медовый вывод: PostgreSQL 13 на Ubuntu совершенно прекрасен! Я проверил!

О релизе почитать здесь, загрузить отсюда, информация для бета-тестеров здесь.

Статьи

PostgreSQL, a community project

Питер Айзентраут (Peter Eisentraut, 2ndQuadrant то есть уже EDB) пишет внезапно не техническую статью, а предлагает мини-анализ Postgres Success Story он заметил, что после выхода 13-й версии, в блогах и на форумах больше говорили не о версии, а не могли нарадоваться устойчивости сообщества. Причина устойчивости по Айзентрауту такая: из 3 типов опенсорсных проектов

• ведомых одним человеком (или двумя не многими);
• ведомых компанией;
• ведомых сообществом

лишь третий тип устойчив. Причины неустойчивости первых двух переход из одной категории в другую часто бывает разрушителен.

Waiting for PostgreSQL 14 Support for OUT parameters in procedures

Депеш (Hubert 'depesz' Lubaczewski) пишет: Это большое дело! Процедуры появились в PostgreSQL 11 и они смогли реализовать логику базы, когда несколько транзакций в одной процедуре. Но вернуть данные они не могли, сделать SELECT по результатам было нельзя, разве что через RAISE NOTICE. А теперь можно. И демонстрирует на примерах.

До этого в серии ожиданий PostgreSQL 14:

Rename wal_keep_segments to wal_keep_size.

pg_stat_statements: track number of rows processed by some utility commands.

Improvements for handling large number of connections.

Ну и напоминаем ещё раз об Июльском разогреве Павла Лузанова.

Postgres и ИИ

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

На статью об ИИ-оптимизации мы недавно ссылались, сделаем это ещё раз: AQO адаптивная оптимизация запросов в PostgreSQL, автор Павел Толмачёв. Теперь об обработке и хранении данных ИИ.

Changing the Rules on MDM: Data Mastering at Scale [М.Стоунбрейкер]

Отец Postgres Майкл Стоунбрейкер выступил на DataMasters Summit конференции Tamr, что не удивительно: он со-основатель этой компании и её технический директор. Пока можно почитать статью Data Mastering at Scale, по мотивам которой, видимо, и сам доклад.

Он говорит о том, что за ETL (Extract, transform and load, извлечение, преобразование, загрузка) следует собственно Data Mastering (управление мастер-данными), где в данных, скажем, есть несколько Стоунбрейкеров (Майк, Майкл, М.), и надо понять, где настоящий Майкл Стоунбрейкер и оставить его единственную, золотую копию. Раньше соответствующий софт с этими задачами худо-бедно справлялся, но последние годы вместо нескольких источников данных может понадобиться 10 тыс. источников (как у Groupon), 250 баз на 40 языках (Toyota). И в этом случае считает не стареющий душой Майкл Стоунбрейкер на базе правил мастеринг
работать уже не будет, а нужно машинное обучение. Без человека всё равно не обойтись, но стюарты данных будут скорее спецами по выбору ML-моделей, по обучению их. И в заключение ссылается на концептуальную статью The Data Civilizer System, где описана MDM будущего.

Postgres and the Artificial Intelligence Landscape

Это PDF-презентация Брюса Момджана. Он говорит не об ИИ для оптимизации работы базы, а о собственно вычислениях машинного обучения, производимыми над данными, хранящимися в БД. Он приводит код на PL/Perl. То есть все ML-вычисления происходят именно внутри базы (гораздо чаще базу используют только для хранения, а вычисления выносят в приложения на Python или других языках). Вот почему Брюс предлагает использовать базу, и использовать её таким образом:

• для машинного обучения нужно много данных;
• бОльшая часть этих данных в вашей базе;
• почему бы не обучать там, где лежат данные, в базе?
• ведь возможен бесшовный доступ к актуальным данным;
• можно сразу что-то делать с результатами работы ИИ (например, коммитить транзакции, если ИИ не считает банковскую операцию мошеннической);
• ИИ выиграет от возможности транзакций, согласованности, бэкапа;
• можно использовать сложные типы данных, FTS, GIS, индексирование;
• Postgres может использовать GPU внутри базы.

Machine Learning with 2UDA

Серия из 7 статей о применении софта 2ndQuadrant 2UDA для машинного обучения. Он работает в среде Orange 3, то есть ориентирован на Python. То есть не внутри базы, используя не функции PL/Python(3)u, а внешние программы. Там есть, например, реализация K-NN тоже внешняя, хотя внутри штатного PostgreSQL есть конструкция GOUP BY "<->" LIMIT K, ускоряющая поиск (см. в этом выпуске статью Рамси о PgRouting и PostGIS)

Machine Learning in PostgreSQL part 1: KMeans Clustering

Герман Резницкий (Hernan Resnizky, Cybertec) рассказывал пару лет назад о KMeans (метод K-средних), реализованных внутри базы на PL/Python(3), расширение plpython(3)u. Модели грузятся как тип bytea. А предсказание K-среднего требует передачи в созданную питоновскую функцию массива массивов:

SELECT predict_kmeans('models','model',1,array[[0.5,0.5,0.5,0.5]]);

Данные брали из ML-репозитрия UCI Калифорнийского Университета в Ирвайне.

Postgres и ускорители

Мы решили в этом выпуске в двух словах рассказать о том, что нового делается в мире кремния о GPU, DPU, Arm-CPU.

Oracle Cloud Deepens HPC Embrace with Launch of A100 Instances, Plans for Arm, More

Эти новости не имеют прямого отношения к Postgres, но тенденции любопытные. У Oracle в облаках есть и база Oracle, и MySQL. Системы DGX A100 Nvidia, конечно, придут в облака прежде всего для ИИ, генерации речи, работы с мультимедиа. Но не только: DGX упоминают и в контексте баз данных: у DGX-1 более 1ТБ памяти, но мы её ещё удвоили. Не потому, что могли. А потому, что многие из наших клиентов обрабатывают огромные графы и должны быстро работать с экстремально большими базами данных, столько памяти им действительно нужно! Об этом же по-русски выжимка той статьи: Oracle Cloud расширяет портфель HPC-решений

DPU

Колумбийский университет ведёт исследовательский проект исследование архитектуры специализированных DPU-процессоров (Data Processing Unit) для повышения производительности и экономии энергии при обработке данных больших объемов. Эта исследовательская группа фокусируется на ускорении запросов к РСУБД. Первая разработанная ими архитектура нацелена на ускорение аналитических запросов к большим наборам данных.

А вообще архитекторы DPU мыслят их как часть триады CPU-GPU-DPU (в том числе и в Nvidia, разумеется.

Arms First 64-bit Cortex-R Chip Adds Computational Storage

Arm представила публике свой первый 64-битный процессор реального времени для хранения данных на уровне корпораций. В нём зашита поддержка микросервисов Linux. Он должен воплотить идею вычисления должны быть поближе к данным. Память в нём устроена так, что ОС может работать прямо в контроллере хранения данных. Процессор может адресоваться к памяти в 1ТБ DRAM. Предполагается, что он будет эффективно работать в том числе с Kubenetes и Docker.

Data processing more than billion rows per second [с GPU]

Кохей Кайгай (Kohei KaiGai, глава компании HeteroDB) повествует на вебинаре (видео пока недоступно) о том, как SSD-to-GPU Direct SQL (реализованный как расширение PostgreSQL) оптимизирует поток данных, несущийся по шине PCIe от хранения к процессорам. Цель ускорение аналитических запросов.

PostGIS

Using Postgres and pgRouting To Explore The Smooth Waves of Yacht Rock
Ещё один неожиданный поворот. Не потому, что речь в этой статье Джона Порвазника (John Porvaznik, Crunchy Data) не о яхтах и камнях, а о музыке для яхт (что-то вроде софт-рока, Beech Boys, видимо), а потому, что рассказывается о расширении pgRouting, которое требует установки PostGIS, и используется обычно для маршрутизации в самом буквальном смысле прокладывании маршрутов на карте. Но с его помощью можно и обходить графы (не используя функции PostGIS вообще). Автор строит замысловатый граф из данных о песнях и их исполнителях и натравливает на него алгоритм Краскала. Графы в статье очень красивы. Результат: лучший музыкант для яхтинга Джеф Паркаро (я не слушал: нет яхты).

Зато Пол Рамси (Paul Rumsey) занимается в майской статье Routing with PostgreSQL and Crunchy Spatial прокладыванием маршрутов по улицам Бостона. Но использует ещё и pg_tileserv и pg_featureserv гошные компоненты их пакета Crunchy Spatial. Кстати, пользуется и "<->" в конструкции ORDER BY, которая радикально ускоряет поиск ближайших соседей.

Для визуализации Рамси использует OpenLayers, а не QGIS, как многие сейчас. Геоданные берёт с Geofabrik.

Spatial analysis with PL/R

Серия из трёх статей ещё 2007 года, зато написанная автором расширения plr Джо Конвеем (Joe Conway, Crunchy Data). Он предлагает использовать R внутри базы во взаимодействии с функциями PostGIS. R пригодится для аналитики пространственных данных. Для примера он строит графики NDVI (Normalized Difference Vegetation Index вегитационный индекс) окрестностей Сан-Диего. R при этом работает с растровыми, а не векторными данными. Берёт их у United States Geologic Survey (USGS), а результаты визуализирует с помощью старинной R-библиотеки получается вполне симпатично.

Иван Муратов о PostgreSQL + PostGIS + TimescaleDB на SDCast #123

PostgreSQL + PostGIS + TimescaleDB хранилище для систем мониторинга транспорта доклад Ивана на PGConf.Russia 2019 (слайды и видео).

PostGIS vs. Geocoder in Rails

Лей Холлидей (Leigh Halliday), автор-гость в блоге pganalyze, разрабатывал приложения на Ruby on Rails и обходился без PostGIS, пользуясь Geocoder. Но овладел всё же PostGIS и теперь сравнивает. В примерах кода на Ruby используется сгенерённая демобаза со 100 тыс. домов и 100 школ. Лей по касательной задевает понятия SRID и измерения расстояний на сфере (о сфероиде речь не идёт), индексирования геоданных в Rails и в PostGIS. С задачей нахождения домов не дальше заданного расстояния от школы и с домами внутри прямоугольника рельсы и PostGIS справляются за примерно одно время. Но только PostGIS подходит для поиска домов внутри заданного многоугольника и в случае, когда добавляется условие на дом: только те, где можно арендовать квартиру недалеко от школы.

Облака

Announcing Crunchy Bridge: A modern Postgres as a service

Crunchy Bridge теперь доступен на AWS и Azure.

AWS Aurora PostgreSQL versions vanish from the mega-cloud for days, leaving customers in the dark

То был позитив. А вот негатив: Грег Клоу (Greg Clough), разработчик, использующий AWS, обнаружил, что некоторые версии AWS Aurora исчезали на прошлой неделе (то есть стали недоступны для разворачивания; уже существующие базы не пропали). Сейчас всё в порядке.

Diary of an Engineer: Delivering 45x faster percentiles using Postgres, Citus, & t-digest

Нильс Дийк (Nils Dijk, Microsoft) рассказывает, как проблема заказчика на analytics data in Hyperscale (Citus) on our Azure Database for PostgreSQL managed service была решена с помощью расширения t-digest Томаша Вондры.

Cloud Vendors as a Barrier

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

Через 3 дня Брюс продолжает тему в посте Cloud Vendor Monetization of Open Source. Тема пересекается с темой статьи Питера Айзентраута. Брюс акцентирует разницу между открыто разрабатываемым открытым кодом (как Postgres) и кодом открытым, но разрабатываемым в компании (как MySQL). Но ссылается он на другую статью: Dining Preferences of the Cloud and Open Source: Who Eats Who?. Там есть симпатичный фрагмент о софтовой пищевой цепочке:
ПО ест мир; открытый код ест ПО, облака едят открытый код, и самое актуальное мульти-облака едят облака. Через эту оптику в статье рассматриваются AWS, Hadoop, Pivotal, Red hat. Особенно нагляден, считает Брюс, пример Red Hat, оказавшейся в результате внутри IBM; но облачники могли бы для своего же блага умерить аппетиты и не съедать, а пасти (немного вольно интерпретируя Брюса) опенсорсные компании как дойных коров.

Миграция, апгрейд, интеграция

How we upgraded PostgreSQL at GitLab.com

Речь о масштабном проекте, в котором используются мощные машины с 96 ядер и 624 Гб памяти. 60К пользовательских коннектов к сайту в сек. держит каскад pgbouncer-ов. Приложения написаны на Ruby on Rails.

Using PostgreSQL to Offload Real-Time Reporting and Analytics from MongoDB

Неожиданный поворот: PostgreSQL предлагают использовать как базу с запросами для чтения как аналитическую. При этом база на MongoDB остаётся для пишущих OLTP-запросов. Данные постоянно копируются из MongoDB в Postgres средствами монговского oplog. Обосновывают такое решение тем, что сложные запросы с агрегацией, с многочисленными индексами и разнообразными джойнами в Postgres сочетаются с развитыми средствами работы с JSON.

Статья лежит на сайте Rockset, и в конце статьи говорится: если уж вы решили выгрузить аналитику и отчёты из MongoDB, но вам нужно серьёзное масштабирование, а данные слабо структурированы, то стоит подумать насчет бессхемных баз реального времени Elasticsearch и Rockset. Они умеют ускорять запросы индексами, а Rockset поддерживает полноценный SQL и умеет делать джойны.

Разное

Морской бой на PostgreSQL

Статья Владимира Турова aka Firemoon. Подробней не на Хабре, а здесь.

Для вывода используется оператор RAISE, который для psql выводит сообщение с префиксом уровня логирования. Избавиться от него не получится, но это не мешает игре.

К сожалению, в PostgreSQL нет планировщика, который бы запускал процедуру по расписанию. Так как проблема находится в серверной части игры, то ее можно решить написанием shell-скрипта, который каждую секунду будет вызывать хранимую процедуру загрузки логов.

Планировщик, вообще-то, есть: pgpro_schedeler в Postgres Pro Enterprise. Код самого боя лежит в репозитории.

Знакомство с pg_probackup. Вторая часть

Александр Никитин из БАРС Груп опубликовал продолжение. В первой части установили pg_probackup, создали и настроили экземпляр, сняли полный и инкрементный бэкапы, научились просматривать и изменять конфигурацию экземпляра. Получили список бэкапов, написали скрипт для резервного копирования кластера и отправки результатов последней операции по снятию бэкапа в систему мониторинга.

Темы второй части:
PITR как хранить копии журналов предварительной записи, чтобы иметь возможность восстановления на произвольный момент времени (Point-in-time recovery); рассматриваются режимы DELTA, PAGE и самый интересный PTRACK, когда создается карты измененных блоков в базе данных.

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

Следующая часть будет посвящена восстановлению из бэкапов: варианты восстановления, PITR, частичное и инкрементное восстановление.

Вебинары и митапы

Вебинар по JSONB Олега Бартунова



17-го сентября в новой студии Postgres Professional Олег Бартунов провёл вебинар Roadmap for JSON in PostgreSQL: What's Next? Вебинар был ориентирован на англоязычную аудиторию. Примерно треть эфирного времени пришлась на вопросы и ответы. Вопросов было очень много. Видео будет выложено позже.

Postgres-вторники

Теперь они будут не каждый вторник, а через один. Зато дополнятся англоязычными Postgres-Thursdays. Обещано, что в четвергах поучаствуют весьма известные персоны.
На YouTube;
в Zoom (ссылка теперь каждый раз новая);
планы, детали.

Релизы

dbForge: Data Compare for PostgreSQL v.3.3 и Schema Compare for PostgreSQL, v1.0

У Devart, известной dbForge Studio for PostgreSQL и Data Compare for PostgreSQL, появился новый продукт: Schema Compare for PostgreSQL v1.0. Пока он ориентирован больше на Amazon Redshift, умеет сравнивать схему PostgreSQL со схемой Redshift и помогает переезжать с первой СУБД на вторую (подробней здесь). В блоге Devart большое количество скриншотов, и сказано, что PostgreSQL, Amazon RDS, Azure PostgreSQL поддерживаются частично. Но обещано развитие в направлении PostgreSQL.

Параллельно вышел релиз новой версии dbForge Data Compare for PostgreSQL v.3.3 с поддержкой PostgreSQL 13 и с управлением скриптами предварительного и последующего выполнения (Pre & Post Script execution functionality).

pgtools

Этот инструмент дебагинга приложений, работающих с базами данных, в реальном времени показывает события базы данных, вызванные работой приложения. pgtools использует для перехвата событий базы триггеры и триггерные функции. Серверная часть написана на Python3, клиентская на vue.js. Пока находится ещё в стадии разработки, поэтому автору Лукасу Лёффлеру (Lukas Loeffler) нужна и важна реакция, советы и найденные ошибки.

PostgresDAC 3.9

PostgresDAC это набор компонентов для доступа из RAD Studio (Delphi и C++Builder)/FreePascal/Lazarus к разным Postgres-ам: PostgreSQL, EnterpriseDB, Amazon RDS, PostgresPro, и Heroku Postgres.

Главное в этой версии поддержка PostgreSQL 13 и RAD Studio 10.4.1: добавлены клиентские библиотеки v13 и библиотеки dump & restore v13 (pg_dump.dll, pg_restore.dll).

Загружать отсюда.

Pgpool-II 4.1.4

А точнее: 4.1.4, 4.0.11, 3.7.16, 3.6.23 и 3.5.27. О релизе можно почитать здесь, а скачать отсюда.

pg_probackup 2.4.4

Новое: появились пакеты для SUSE 15.2 и поддержка PostgreSQL 13. Если пропустили, то напоминаем, что в подразделе Разное раздела Статьи есть о второй части статьи из серии об этом пакете.

Конференции

HighLoad++

Должна состояться 9 и 10 ноября 2020 в Офлайн Сколково.
Конференция HighLoad++ НЕ будет перенесена в онлайн. В случае, если регулирующие органы не разрешат проводить конференцию 9 и 10 ноября, она будет перенесена со всеми обязательствами и партнёрствами на 1 и 2 марта 2021 года. Для тех, кто воспользуется бронью организаторов в гостинице в Сколково, бронь будет перенесена автоматически.

• Архитектура процессора Эльбрус 2000, того самого детища Бориса Арташесовича Бабаяна с архитектурой VLIW. Автор доклада, Дмитрий Завалишин (Digital Zone), говорит (вслед за Бабаяном) Близок к нему, пожалуй, только Интеловский Itanium, но он, по сути, является последователем Эльбруса.
• Трансформация Enterprise и Highload приложений в HPC Дмитрия Кирия (Техцентр Deutsche Bank). Как перенести высокие нагрузки на высокопроизводительные системы, как переписать приложения.
• SQL/JSON в PostgreSQL: настоящее и будущее Олега Бартунова (Postgres Professional)
• Алгоритмические зоны доставки ресторанов BigData и машинное обучение Константина Измайлова и Евгения Макина из Delivery Club, и ещё один от Delivery:
• Production Machine Learning в Delivery Club Андрея Завгороднего (вообще на этой конференции очень много докладов об ИИ. По этому докладу решение ещё не принято).
• Postgres 13 и высокие нагрузки Ивана Панченко (Postgres Professional).
• Обработка ошибок времени выполнения в PostgreSQL Ивана Фролкова (Postgres Professional).
• Подсистема I/O в PostgreSQL: архитектура, проблемы, обходные пути Артёма Сергиенко.
• Распространённые ошибки изменения схемы базы данных PostgreSQL Николая Самохвалова (Postgres.ai) хайлоуд случается и не от хорошей жизни, а из-за легкомысленного управления транзакциями, блокировками и настройками Постгреса.
  

---

Предыдущие выпуски:
#24, #23, #22, #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.


Пополнение в Core Team

Напоминаем о неписанном правиле сообщества: в Core Team не должно быть большинство из одной компании. После слияния-поглощения EDB 2ndQuadrant 3 из 5 участников Основной Команды оказались коллегами по EDB. К счастью, никого не сократили, а добавили двух достойных: Андреса Фройнда (Andres Freund, Microsoft, Citus) и Джонатана Каца (Jonathan Katz, Crunchy Data).

Любимые области Андреса Фройнда: репликация, производительность и масштабируемость (смотрите три недавние статьи на эту тему, ссылки в нашем разделе Статьи. Производительность), хранение.

Джонатан Кац (Jonathan Katz, Crunchy Data) занимался патчами и ревью, но больше концентрировался на разработке и поддержке сайта, выпуске релизов и прочей сопутствующей, но необходимой деятельности. Он вообще важный человек: председатель совета директоров Ассоциации PostgreSQL в США (United States PostgreSQL Association) и директор Ассоциации PostgreSQL-сообщества Канады (PostgreSQL Community Association of Canada), которая выступает как юридическое лицо сообщества.

Прекрасное, взвешенное решение. Впрочем, не все с этим согласны: Альваро Эрнандес (lvaro Hernndez Tortosa если полностью) поздравил новоизбранных (непонятно кем и непонятно как по его мнению) и предложил задуматься над следующими 10 проблемами управления сообществом:
Влияние компаний:

• 40% из Core Team были из одной компании, теперь 43%, 71% из двух;
• 100% из всего лишь 4 компаний.

Многообразие (diversity):

• 100% это белые мужчины;
• 100% из США или Европы;
• все кроме одного работают в американских компаниях.

Демократия:

• членов Core Team назначают члены Core Team;
• срок неограничен, четверо являются членами уже больше 15 лет.

Прозрачность:

• процессы выбора членов и кандидатов, критерии выбора и пр. суть большой секрет;
• заседания секретны;
• стратегии (policies) объявляются, а не обсуждаются в сообществе.

Альваро предлагает высказаться. И Ханс-Юрген Шёниг (Hans-Jrgen Schnig) высказывается:
Никогда не замечал и тени расизма при принятии патчей. Может и дальше будем продолжать как было думать о компетентности, а не о расе, гендере или о чём там? У нас с этим никогда не было проблем. Так зачем проблему создавать? Клаус Расмуссен (ClausRasmussen) ещё решительней: зачем нам этот crap с идентичностями? У нас технологическое сообщество, а не Liberal_arts_college. Желающие могут запастись попкорном и следить за дискуссией. Этот текст обсуждается также здесь.

Я опустил детали в обращении Альваро. Ещё одна из упомянутых им проблем (существующих с точки зрения Альваро): Core Team это центральный орган проекта. А юридически проект представляет Postgres Association of Canada, определяя в том числе интеллектуальную собственность: доменные имена, торговые марки и прочее. Как бы чего не вышло.

CF-новость

Анастасия Лубенникова из Postgres Professional стала распорядителем текущего коммитфеста. В этом ей помогает Георгиос Коколатос (Georgios Kokolatos).

Новости PG-этики

А ещё Анастасия входит в Комитет по этике (Code of Conduct Committee) сообщества (а Илья Космодемьянский вышел из комитета).

Кстати, благодаря то ли Альваро, то ли общему настроению, Комитет по этике объявил вакансии: нужны люди из разных стран и разных народов, чтобы отразить многообразие PostgreSQL-сообщества. Пишите на coc@postgresql.org

Документация к PostgreSQL 13.0

The PostgreSQL Global Development Group объявила о доступности русской документации к версии 13. Перевод на русский язык компания Postgres Professional. Официальная страница русскоязычной документации.

Обучение

DEV2: Разработка серверной части приложений PostgreSQL 12. Расширенный курс.

Новый курс продолжительностью 4 дня. В нём:

• понимание внутренней организации сервера;
• полное использование возможностей, предоставляемых PostgreSQL для реализации логики приложения;
• расширение возможностей СУБД для решения специальных задач.

Основная идея курса показать не просто базовые функции PostgreSQL, но и его расширяемость: возможность дополнить серверные механизмы собственным кодом, что позволяет использовать PostgreSQL для решения самых разнообразных задач.

Статьи

Масштабируемость и производительность

Measuring the Memory Overhead of a Postgres Connection

Андрес Фройнд (тот самый, кто только что обосновался в PostgreSQL Core Team) опубликовал серию из 3 статей о производительности PostgreSQL при большом числе соединений. Они дублируются в блоге Citus и в блоге Microsoft (пока 20 лайков, 2 подписчика).

В статье об издержках памяти начинается с популярного мотива а если бы треды, а не процессы? Спойлер Андреса: если аккуратно померить, то издержки меньше 2 мебибайта. А неаккуратно это при помощи top и ps.

Для более тонких замеров памяти Андрес использует системные /proc/$pid/status и /proc/$pid/smaps_rollup. Так можно увидеть значения VmRSS, VmRSS, RssAnon, RssFile, RssShmem если вы не знали, что это, то из статьи узнаете и поймёте, почему они важны. Чтобы не обмануться с причиной перерасхода памяти, он замеряет с включенным и отключенным huge_pages. Ещё: надо помнить о copy-on-write при форке процесса.

Analyzing the Limits of Connection Scalability in Postgres

Андрес исследует узкие места с тем, чтобы далее предложить путь их решения, и аргументирует не только из общих соображений, а с примерами и листингами. Раздувание кеша (cache bloat) тоже (как и оверхед при форке) не критично. Управление work_mem тоже удовлетворительно. А собака зарыта в куче снэпшотов: функция GetSnapshotData() дорогая и вызывается часто. Вывод: надо менять саму модель соединений (connection model), а может и модель исполнения запросов (query execution model). А от себя добавим: эта тема более, чем активно обсуждалась в рассылке hackers. Более того: в Postgres Professional давно ведутся разработки в этом направлении. Начиная с 12-й версии в Postgre Pro Enterprise Edition есть встроенный пул соединений. Это не совсем то, что сделал Андрес, но это тоже в тему масштабируемости клиентских соединений.

За диагностической 2-й статьёй следует 3-я конструктивная: предложения Андреса уже в форме патчей, которые должны войти в версию PostgreSQL 14:

Improving Postgres Connection Scalability: Snapshots

Пересказывать эту статью в паре абзацев, кажется, бессмысленно. Даём ссылки на серию патчей Андреса (все они начинаются с snapshot scalability: здесь опускаем):
Dont compute global horizons while building snapshots
Move PGXACT->xmin back to PGPROC
Introduce dense array of in-progress xids
Move PGXACT->vacuumFlags to ProcGlobal->vacuumFlags
Move subxact info to ProcGlobal, remove PGXACT.
cache snapshots using a xact completion counter
(Об этом также здесь)

Другую серию из 3 статей в жанре от 8.3 и до 13 опубликовал Томаш Вондра (Tomas Vondra, 2ndQuadrant то есть EDB).

OLTP performance since PostgreSQL 8.3

В этой статье Томаш сначала объясняет замысел серии: почему начал с 8.3, почему именно эти тесты, зачем ему тестировать полнотекстовый поиск, на какой машине тестировать. Он не ставит цели сверхкорректного сравнения, это скорее упражнение для лучшего понимания PostgreSQL. До 8.3 он уж слишком отличался от нынешнего, охват и так недурен: 12 лет. А машина обычный офисный компьютер.

В 1-й статье серии Томаш исследует производительность OLTP на bgbench, взятой из 13-й версии, scale 100 (1.6 ГБ), 1 000 (16 ГБ) и 10 000 (160 ГБ). Клиенты от 1 до 256. Хранение NVMe SSD / SATA RAID; режимы: read-only (pgbench -S) / read-write (pgbench -N)

Графики с NVMe SSD ведут себя прилично: производительность в основном монотонно растёт с номером версии. А вот с SATA творятся чудеса: c SATA RAID в режиме чтения некоторые флюктуации и, похоже, регресс в версии 9.6. А вот на записи-чтении грандиозное ускорение с версии 9.1 в 6 раз!

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

TPC-H performance since PostgreSQL 8.3

Для измерения производительности на аналитических нагрузках Томаш запускал бенчмарк TPC-H (его ещё называют бенчмарком принятия решений decision support), получал результаты, которые можно анализировать ещё очень долго, нарисовал красивые графики, и сделал свои выводы в меру отпущенного на это времени.

В TPC-H 22 запроса на 3 наборах данных: малом, среднем и большом. Томаш гоняет их на версиях от 8.3 до 13, да ещё и то включает, то отключает параллелизм. Коэффициенты масштабирования (scale factor) он выбирает такие: 1 (цель поместиться в shared-buffers), 10 (в память) и 75 (не поместиться в память). Комбинаций море, для анализа простор. Иногда автор действительно опускается до отдельных запросов и анализирует причины странного поведения. Кривая производительности немонотонно меняется с версией, а по отдельным запросам скачет совсем неожиданно. Причина простая: планировщик и оптимизатор умнеют с новыми версиями за счёт новых планов и/или за счет новых способов использования статистики, но оборотная сторона промахи: неверный выбор плана из-за плохой статистики, оценок стоимостей или других ошибок. Примерно то же и с параллелизмом: появляются новые планы, но если стоимости и оценки расходятся с реальностью, выбираются планы, хуже старых, последовательных.


Диаграмма из статьи TPC-H performance since PostgreSQL 8.3. Можно было поместить в наш раздел Прекрасное.

Full-text search since PostgreSQL 8.3

В преамбуле Томаш рассказывает историю FTS в PostgreSQL, которая началась с Олега Бартунова и Фёдора Сигаева лет за 20 до основания Postgres Professional. Далее Томаш сетует на отсутствие индустриальных стандартов тестирования полнотекстового поиска и обращается к собственным ресурсам ПО: в незапамятные времена он сочинил утилиту archie парочку питоновых скриптов, которые загружают архивы переписки PostgreSQL, превращая их в базу, которую можно индексировать, в которой можно искать тексты. Сейчас в таких архивах около миллиона строк 9.5 ГБ не считая индексов. В качестве тестовых запросов он взял 33 тыс. реальных поисковых запросов к архиву на сайте PostgreSQL.org.


Фёдор Сигаев и Олег Бартунов. Фотография из статьи Full-text search since PostgreSQL 8.3

Запросы были разного типа, но для статьи взял вот такие с tsvector, придуманным ещё Бартуновым и Сигаевым:

SELECT id, subject FROM messages WHERE body_tsvector @@ $1SELECT id, subject FROM messages WHERE body_tsvector @@ $1ORDER BY ts_rank(body_tsvector, $1) DESC LIMIT 100

Кроме того Томаш тестировал влияние индексов GIN и GiST. Оба запроса с использованием GIN дают огромный скачок в производительности в 4 с лишним раза! Томаш благодарит за это Александра Короткова и Хейкки Линнакангас (Heikki Linnakangas), придумавших патч Improve speed of multi-key GIN lookups. А вот если использовать GiST, то ничего хорошего вообще не будет. А будет плавная деградация. Почему ж никто не жаловался? вопрошает автор и предполагает, что вместе с апгрейдом версий многие апгрейдили и железо, и это маскировало эффект. Или просто не использовали GiST для текстового поиска.

Олег, Теодор [Фёдор] и их коллеги напоминает Томаш работали над более мощными вариантами GIN-индексов VODKA и RUM [примечание редакции: об индексах RUM, о том, чем они лучше GIN, о расширении rum можно почитать здесь. Про водку не будем :)]. Это как минимум поможет некоторым типам запросов. Особенно автор надеется на улучшение поддержки новых типов полнотекстовых запросов, так как новые типы индексов спроектированы для того, чтобы ускорить фразовый поиск (см. там же).

Книжечки

Кстати, о текстовых файлах и поиске в них. Вот 196640 книг (файлов) в текстовом формате. Их, скорее всего, будут использовать для обучения больших сетей, но можно их, скажем, использовать и в каких-нибудь тестах производительности текстового поиска или ещё каких-то манипуляций текстом. Собирали тексты энтузиасты с the-eye.eu (почему-то недоступного честному пользователю из РФ).

PostgreSQL 14: Часть 2 или в тени тринадцатой (Коммитфест 2020-09)

Эта статья Павла Лузанова из отдела образования Postgres Professional и о производительности тоже: постольку, поскольку патчи, принятые на этом коммитфесте, имели отношение к производительности (о патчах Андреса, которые он упоминал, там тоже есть). Это, как и Часть 1 (Коммитфест 2020-07), MUST READ для тех, кто следит за технологическими новшествами PostgreSQL без IMHO.

Жизнь в PostgreSQL

памяти Джона Хортона Конвея, умершего от COVID-19

Открывает эту мемориальную подборку ссылок недавняя статья Егора Рогова: Жизнь на PostgreSQL

Некто Сергей aka ildarovich делает это на языке запросов 1С, а точнее одним запросом: Игра Жизнь в одном запросе

А вот на C#: Как ускорить игру Жизнь в сто раз, в комментариях есть SQL-код.

На JS, огромная статья, очень красивая визуализация: Эволюционирующие клеточные автоматы

Кстати, о Конвее: Джо (Joe), однофамилец классика клеточных автоматов (в прошлом выпуске мы ссылались на статью 2007-го года про то, как использовать PL/R для GIS) теперь, в начале ноября 2020, пишет на тему сверх-актуальную:

Election Night Prediction Modeling using PL/R in Postgres

Он использует пакеты mvtnorm (3 алгоритма нормального распределения), politicaldata (специальные тулзы для сбора и анализа политических данных) и tidyverse (разные средства анализа данных). Для развлечения Джо предлагает разобраться в немалом количестве строк кода, создаёт свой тип данных и ещё предлагает придумать SQL-запросы в качестве упражнения.

Релизы

PostgreSQL 13.1

А также 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. В новых версиях исправлены обнаруженные баги, в том числе связанные с безопасностью. Сейчас мы не будем на них останавливаться. Они описаны на этой странице.

OpenGauss 1.0.1

Сотрудник Huawei Вадим Гусев сообщает на хабре о появлении openGauss: новая СУБД от Huawei для нагруженных enterprise-проектов прибавила в функциональности

Это форк PostgreSQL, опенсорсный вариант проприетарной GaussDB, который работает на x86 и китайских процессорах Kunpeng 920, у которых архитектура ARM64 (к слову: напоминаем, что ARM ltd куплена Nvidia), то есть мы можем предположить курс на китайское импортозамещение (в нише ARM у нас не Эльбрусы, а Байкалы).
Как утверждают создатели, у OpenGauss гибридная ориентация в духе HTAP, и она многое умеет :

• колоночное хранение;
• in-memory engine;
• развертывается решение как в контейнерах, так и на физических серверах;
• ИИ (глубокое обучение с подкреплением в сочетании с эвристическими алгоритмами) рекомендует параметры.;
• инкрементальное резервное копирование;
• Standby на удаленной площадке в синхронном или асинхронном режиме (до четырех реплик на физическом уровне).

В статье с длинным интернациональным списком авторов (фамилии от индийских до русских, китайцы в меньшинстве) оценивается производительность на TPC-C.

Database Lab 2.0

Николай Самохвалов и Артём Картасов из Postgres.ai (Артём делал бОльшую часть кода) на Постгрес-вторнике 3 ноября рассказали (за полтора часа) о Database Lab 2.0 новой, сильно отличающейся версии своей среды для тестирования и разработки с тонкими клонами (при клонировании копируются только измененные блоки).

Новое:

• поддержка RDS и других облачных Postgres-сервисов;
• физическое развертывание с нативной поддержкой WAL-G;
• декларативное развертывание;
• управление снэпшотами, политики снэпшотов;
• предобработка данных (анонимизация);
• time travel для диагностики, контроля изменений, быстрого точечного восстановления;
• оптимизация SQL на новом уровне: serverless EXPLAIN и бот-помощник для оптимизации;
• 100% покрытие миграций БД (изменение схемы) автоматическими тестами на полноразмерных копиях БД;
• регрессивные тесты;
• поддержка docker-имиджей для Postgres 9.6, 10, 11, 12 и 13; по умолчанию в них расширения Timescale, Citus, PoWA и много других, а также большинство расширений, поддерживаемых Amazon RDS;
• документация сильно расширена.
  

pg_statement_rollback 1.0

pg_statement_rollback это расширение Жиля Дароля (Gilles Darold), Жульена Руо (Julien Rouhaud) и Дэйва Шарпа (Dave Sharpe), которое реализует в PostgreSQL откат транзакции на уровне оператора (server side rollback at statement level for PostgreSQL) как в Oracle или DB2. Это значит, что при ошибке в выполнении оператора его результаты не видны как будто оператора и не было. При этом результаты операторов, выполненных в транзакции до этого, не теряются. В PostgreSQL это можно было сделать только на клиенте, в psql, например:

\set ON_ERROR_ROLLBACK on

Теперь всё будет работать на сервере таким образом, как будто для каждого оператора серверу посылаются

SAVEPOINT autosaveиRELEASE SAVEPOINT autosave

а такая роскошь раньше могла сказаться на производительности. Авторы дают результаты тестов TPS-B и честно рассказывают о проблемах.

pgbitmap 0.9.3

Бета-релиз расширения pgbitmap, доступно на pgxn и github.

Это расширение Марка Манро (Marc Munro) создаёт тип pgbitmap с полным набором функций, операторов и агрегатов. Он отличается от стандартных типов Postgres bit и bit varying тем, что строка не начинается с нулевого бита и тем, что набор операций намного богаче. Этот тип разрабатывался под Virtual Private Database для управления привилегиями. В этом релизе исправлены ошибки, он считается релизом-кандидатом. Сейчас открытых багов не осталось присылайте, если найдёте.
Документация здесь.

pgpool-II 4.2 beta1

В новой версии:

• улучшено и упрощено конфигурирование логирования;
• добавлен новый режим кластера: snapshot_isolation_mode, который гарантирует не только модификацию данных нескольким инстансам, но и согласованность по чтению;
• поддержка LDAP-аутентификации между клиентом и Pgpool-II;
• импорт SQL-парсера PostgreSQL 13.

и прочее, о чём можно прочитать в Release notes.

Загрузить можно отсюда.

pg_activity 1.6.2

pg_activity это интерфейс в стиле top для мониторинга бэкендов PostgreSQL в реальном времени. Поддерживается Бенуа Лабро (Benoit Lobrau, Dalibo Labs). В нём можно:

• настраивать частоту обновления;
• переключаться между тремя представлениями запросов: исполняющиеся/ждущие/блокирующие;
• сортировать по PostgreSQL-метрикам: READ/s, WRITE/s

Зависимостей теперь мало. Работает на Python 2.6+. Исходники здесь.

pgcenter 0.6.6

На гитхабе Алексея Лесовского (Data Egret) появилась новая версия. В ней:

• рейтинги запросов адаптированы к версии PostgreSQL 13;
• тайминги операторов адаптированы к версии 13;
• надо проапдейтить конфигурацию travic-ci: отключить skip_cleanup; проапгерйдить Go до версии 1.14.

pglogical 2.3.3

Появилась поддержка PostgreSQL 13. Загружать отсюда. Чейнджлог недоступен, за информацией велено обращаться к info@2ndQuadrant.com.

repmgr 5.2.0

Добавлена поддержка PostgreSQL 13. Из изменений:

• новая опция --verify-backup запускает утилиту pg_verifybackup после сканирования реплики, чтобы убедиться в консистентности скопированных данных (только для PostgreSQL 13 и позже);
• у failover_validation_command появились новые параметры и конфигурационная опция always_promote для управления промоутированием ноды в случае, когда метаданные repmgr уже неактуальны;
• поддержка PostgreSQL 9.3 прекращена.

Есть и другие изменения, о которых можно узнать здесь. Сорсы находятся здесь, а инструкции по инсталляции здесь.

Прекрасное

Популярность баз 2006 2020

Скриншоты не передадут гипнотической мощи этой динамической инфографики от DB weekly. Это кино увлекательно, познавательно воодушевляюще и даже чуть-чуть отрезвляюще в то же время.



а через 14 лет популярность PostgreSQL выросла более, чем в 2 раза:



Postgres Observability

Интерактивный шедевр наглядности & информативности (этот скриншот в подмётки не годится). Автор Алексей Лесовский из DataEgret.

Конференции

Highload++

Внимание: переносится! Новые даты конференции 17 и 18 февраля 2021 года!

Ибица 2020 зачеркнуто 2021

Одна из самых любимых PG-народом конференций Postgres Ibiza 2020 должна состояться в 2021 году 23-25-го июня (дата предварительная). Следите за новостями на pgibz.io или на сайте FUNDACIN POSTGRESQL сообщества с испаноязычным уклоном. Про Бали пока не слышно.

Postgres Build 2020

Виртуальная европейская конференция по PostgreSQL, посещение бесплатное. Фокус на кейсы реальных клиентов. Пройдёт 8-9 декабря 2020 он-лайн. Twitter и LinkedIn: #postgresbuild.

Ну и год выдался! Подходит к концу. 21-му надо изрядно постараться, чтобы стать хуже. Но он надеемся стараться не будет. А жизнь продолжается. И мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Но сначала поделимся воспоминаниями: как проводил время на хабре отдел образования компании Postgres Professional:

• Начнём с того, что под рукой с Postgresso. Из фонового и иногда побочного занятия Postgresso сместился к центру, стал новостным каналом со стабильной периодичностью примерно месяц. Мы отказались от плоского формата большой простыни с большим списком релизов и статей по 3-5 строчек на каждую. В 21-м продолжим экспериментировать, но от периодичности не откажемся.
• Наш коллективный труд PostgreSQL 13. Чертова дюжина. Первый (задержка в 37 минут после заморозки) и самый полный обзор возможностей 13 версии. Далее последовали обзоры коммитфестов: Июльский, Сентябрьский и Ноябрьский Павла Лузанова. Эта практика 20-го года будет продолжена и в 21-м. Мы часто сами на них ссылаемся а как не сослаться? Они действительно информативны.
• Жизнь в PostgreSQL и в Postgresso 26 подборка других реализаций Жизни памяти Джона Хортона Конвея, умершего от COVID-19.
• Автор статьи Серверное программирование на человеческом языке, очень понравившейся хабр-читателям Иван Панченко. Мы помогали Ивану в подготовке статьи.
• Сотрудник нашего отдела образования Павел Толмачёв написал для хабра статью о модуле aqo. Тема непростая, а тема использование ИИ для оптимизации запросов актуальна, а станет ещё актуальней.
• К тому же бОльшая часть статей была переведена на английский (спасибо Елене Индрупской за титанический труд). Это серии очень глубоких погружений Егора Рогова Locks in PostgreSQL (ru), WAL in PostgreSQL (ru), MVCC in PostgreSQL (ru) и Indexes in PostgreSQL (ru). Кроме того переведён ещё десяток статей, наиболее интересных для англоязычной аудитории. Некоторые из этих статей попадали в англоязычные обзоры самых интересный статей.

Релизы

Вышла Postgres Pro Standard 13

18 декабря 2020 года компания Postgres Professional выпустила новый релиз Postgres Pro Standard 13.1.1. Это первый из тринадцатых релизов Postgres Pro.

Среди новых возможностей:

Новое расширение pgpro_pwr (или PWR, читается как power). Это расширение позволяет получать отчёты по нагрузке, полезные для выявления наиболее ресурсоёмких операций в базе данных. Оно умеет использовать данные расширения pgpro_stats, предназначенного для сбора статистики выполнения SQL-операторов и подсчёта статистики событий ожидания. pgpro_stats обновлено. В январе мы опубликуем на хабре отдельную статью о PWR.

Появилась поддержка операционной системы ОСнова 2.0. Также исправлены ошибки в PostgreSQL 13.1. Среди этих исправлений устранение уязвимостей CVE-2020-25694, CVE-2020-25695 и CVE-2020-25696 (6 патчей сотрудников Postgres Professional).

Postgres Operator v1.6.0

Релиз поддерживает последнюю PostgreSQL 13 и новый образ Spilo 13 (спило слон по-грузински), в котором имеется Patroni 2.0 (но последняя версия Patroni на сегодня 2.0.1). Апгрейд ещё не автоматический, но сильно упростился. Проще стало развертывание pgBouncer на репликах. Подробности в чейнджлоге и в доке.

Pgpool-II 4.2.0

Изменения:

• в этом релизе теперь во всех образцах файла pgpool.conf путь к сокетам /var/run/postgresql;
• Используется единственный сегмент разделяемой памяти для всех разделяемых переменных родительского процесса pgpool;
• при старте убиваются существовавшие до того файлы сокетов watchdog

Загрузить можно отсюда.

pg_timetable: Advanced PostgreSQL Scheduling

Это шедулер, написанный на Go разработчиками Cybertec и работающий как отдельное приложение (для сравнения: pgpro_scheduler выполнен как расширение). Он умеет выполнять задания, состоящие из нескольких разнородных действий, например:

• начать транзакцию;
• записать в лог;
• загрузить файл;
• импортировать файл;
• запустить агрегирование;
• закоммитить транзакцию.

pg_timetable на гитхабе.

Новый начальник Коммитфеста

Масахико Савада (Masahiko Sawada, NTT) стал распорядителем нового Коммитфеста (предыдущий координировала Анастасия Лубенникова)

Статьи

PostgreSQL 14: Часть 3 или ноябрьское затишье (Коммитфест 2020-11)

Это изменения после ноябрьского коммитфеста, последнего в 2020. Павел Лузанов сам предлагает обратить особое внимание на вопросы:

• Не пора ли увеличивать wal_buffers?
• Можно ли перегружать хранимые подпрограммы по OUT-параметрам?
• По умолчанию pg_stat_statements собирает данные о 5000 запросов. Как понять много это или мало?
• Что будет, если в операционной системе обновится библиотека libc?

Текст огромный, так как список изменений полный. Продолжение следует после январского коммитфеста.

Обзор операторов PostgreSQL для Kubernetes: Часть 1: наш выбор и опыт и Часть 2: дополнения и итоговое сравнение"

В первой части Николай Богданов в блоге компании Флант, советовал начать с доклада на Highload++ своего коллеги Дмитрия Столярова, где тот знакомит с общими принципами работы баз данных в Kubernetes (K8s). Николай же формулирует 6 основных требований со стороны K8s и рассматривает операторы:

• Stolon. Этот довольно популярный отказоустойчивый кластер интегрирован в K8s. Но Stolon не подошёл, так как первое же (деплой из Git и с Custom Resources) из тех кубернетовских требований не удовлетворено (нет Custom).
• Crunchy Data PostgreSQL Operator разработка нашего старого postgres-знакомого CrunchyData (автор называет молодым стартапом) богат фичами, но он оттолкнул несоответствием принятым в K8s стандартным возможностям работы с ресурсами.
• Zalando Postgres Operator понравился больше всего. И возможностей много, и развивается быстро, и соответствует look & feel в глазах истых кубернетчиков.

Дальше Николай начинает работать с Crunchy Data PostgreSQL Operator, делится впечатлениям. А они не столько радужны, как хотелось. Список проблем и их решений, а также план миграции прилагаются.
Во второй части обзора, вышедшей 13-го ноября, добавились ещё два K8s-оператора:
KubeDB и
StackGres.
В результате появилась сводная таблица матрица имеющихся возможностей этих 5 операторов. Но сердце автора уже прикипело к Zalando, он объявлен лучшим вариантом для тру кубернетчика.

What are table access methods, and what is their importance to PostgreSQL?

Статья Панкаджа Капура (Pankaj Kapoor, Fujitsu) этакое обозрение уже не такой уж короткой (4 года) истории попыток интегрировать вертикальное хранение в PostgreSQL. Автор наблюдал этот процесс не как посторонний: Fujitsu, где он работает, предлагала сообществу свой Vertical Clustered Index в 2016, одновременно с патчем подобной направленности, предложенным Альваро Эррера (lvaro Herrera, 2ndQuadrant, теперь EDB). Со стороны Fujitsu внедрением Vertical Clustered Index занимался Харибабу Коми (Haribabu Komi). Но сообщество пошло другим путём: сосредоточило усилия на универсальном решении на API методов доступа к таблицам, по образцу методов доступа к индексам.

Сейчас, на конец 2019-го через слой методов доступа идёт интеграция с таблицами альтернативного типа хранения, zheap, например. Но пока только с доступом на базе кортежей, то есть до интеграции вертикального хранилища (реальный претендент Zedstore) ещё далеко.

Автор предлагает заодно ознакомиться со своей презентацией на PGCon2019.

Напомним и о vops интересном расширении Postgres Professional, поддерживающем векторные операции. Данные там группируются по значениям столбцов и хранятся в виде плиток (паркета).

Insert-Only Data Modelling To Smooth Peaks On Slow Disks

Каарел Моппел (Kaarel Moppel, Cybertec) предлагает неожиданный и даже контринтуитивный способ сглаживания пиков: вместо UPDATE данных только INSERT на время пиков нагрузки, чтобы потом, в спокойные часы разобраться с данными, вставленными в экстремальной ситуации. Выигрыш в скорости INSERT vs UPDATE на тестовых данных Каарела (100 млн записей) получился раза в 3. Конечно, этот способ подходит отнюдь не во всех случаях, но Каарел говорит об опыте конкретной проблемы заказчика, у которого не было возможности или желания апгрейдить железо из-за пиков, в то время, как в обычных условиях система справлялась.

10 Things I Hate About PostgreSQL

Под Новый Год лучше бы уж не о ненависти, а о любви. Ну да ладно. Рик Бронсон (Rick Branson), работавший в том числе с петабайтного масштаба проектами, решил подытожить 2020-й десяткой самых ненавистных ему особенностей PostgreSQL (некоторые наши спойлеры курсивом):

#1: Wraparound, чреватый катастрофой
[скорее всего когда-то в будущем XID-ы станут 64-разрядными целыми (то есть как уже давно в Postgres Pro Enterprise)];
#2: При переключении кластера (failover) могут потеряться данные;
#3: Неэффективная репликация, распространяющая испорченные данные;
#4: Частая сборка мусора в СУБД типа MVCC проходит болезненно
[Вся надежда Рика на будущий zheap];
#5: Принцип по процессу на соединение мешает масштабируемости
[Рик рассказывает, как использовал 2 слоя pgbouncer-ов и как доходило в общей сложности до миллиона процессов; а также скучает про тред-на-соединение в MySQL];
#6: Индекс по Primary Key очень прожорлив по части ресурсов
[Рик предлагает использовать индекс-таблицы];
#7: Для апгрейда мажорных версий может потребоваться остановка СУБД
[Из-за несовместимости бинарных форматов хранения файлов на диске могут потребоваться часы простоя. Это при потоковой репликации. Переход на логическую может решить проблему в будущем];
#8: Неуклюжая настройка репликации;
#9: Странная догма Никаких-подсказок-планировщику;
#10: Отсутствие компрессии на уровне блоков.

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

Waiting for PostgreSQL 14 Multirange datatypes

Как всегда активен Депеш, он же Хуберт Любашевски (Hubert Lubaczewski). Здесь он пишет о патче Александра Короткова. Как можно догадаться, многодиапазонные типы собираются из непересекающихся диапазонов. Как и диапазоны, они строятся на базе integer, bigintint, numeric, timestamp without time zone, timestamp with time zone, date.

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

SELECT * FROM testWHERE ranges = '{[77.7909859996235,177.7909859996235],(1035.84122266822,1135.84122266822],(1000099.99954803,1000199.99954803]}';

How to install and configure PostgreSQL Debian/Ubuntu for developer use part 1

А здесь Депеш решил расписать шаги по установке PostgreSQL-13, настройке пользователей, редактировании pg_hba.conf и запуске PgAdmin под произвольным пользователем. Это азбука, но какие-то нюансы могут и пригодиться. Содержание следующих частей пока не анонсировано. На всякий случай напоминаем о существовании Малютки.

Waiting for PostgreSQL 14 pg_stat_statements: Track time at which all statistics were last reset.

Идёт постоянное усовершенствование pg_stat_statements. В 1-м и 3-м обзорах коммитфестов от Павла Лузанова уже было о некоторых коммитах. Депеш пишет о важном коммите Фуджи Масао (Fujii Masao): времени последнего ресета статистики. Информацию в pg_stat_statements время от времени очищают приложения и отдельные запросы:

SELECT pg_stat_statements_reset();

Теперь можно спросить у pg_stat_statements о времени последней чистки:

SELECT stats_reset FROM pg_stat_statements_info; dealloc |          stats_reset          ---------+-------------------------------       0 | 2020-12-20 12:06:02.099943+01

Postgres, PL/Python and SciPy/NumPy for Processing Images

Это продолжение статьи о сохранении картинок через Django-приложение в тип PostgreSQL bytea. На этот раз картинки ещё и обрабатывают фильтром.

Is Update The Same As Delete + Insert In PostgreSQL

Ответ: почти. И дальше Лоренц Альбе (Laurenz Albe) из Cybertec исследует это почти. Речь о блокировках при стандартном уровне изоляции: READ COMMITTED.

Session 1                     Session 2 BEGIN; UPDATE uptest SET id = 2   WHERE val = 42;                               SELECT id FROM uptest                                  WHERE val = 42                                  FOR UPDATE;  -- hangsCOMMIT;                               -- one row is returned

А в другой раз:

Session 1                     Session 2 BEGIN; DELETE FROM uptest   WHERE id = 1; INSERT INTO uptest VALUES (2, 42);                               SELECT id FROM uptest                                  WHERE val = 42                                  FOR UPDATE;  -- hangsCOMMIT;                               -- no row is returned

в первый раз возвращается 1 запись, во втором 0.
Дальше Лоренц исследует эту ситуацию, используя расширение pageinspect, да ещё и рассказывает о разнице поведения атрибутов infomask и infomask2 в этих двух случаях.

Конференции

Неопределённость сохраняется. Кто-то уже объявил о переформатировании в он-лайн.

PGCon 2021

В 2021-м пройдёт 28-го мая в сокращенном формате. От конференции осталась только Unconference, которая уместится в zoom. Записаться можно здесь.

Nordic PGDay 2021

Запланирована на 18 марта в Хельсинки. Об он-лайне пока ни слова. Год назад эта конференция была отменена из-за эпидемии.

Облака

Want more PostgreSQL? You just might like Babelfish

Этот проект откровенно ориентирован на тех, кто хочет беспроблемно мигрировать с MS SQL Server на PostgreSQL. Утверждается, что Bablefish это PostgreSQL, совместимый с SQL Server настолько, что приложения, под него написанные (в том числе с T-SQL и протоколом TDS), будут сразу работать.

Новости юриспруденции

Trademark Policy изменилась

Изменения касаются и Slonik-а то есть милой сердцам постгресистов картинки, и торговых марок.

Кто ты, бек-эндер?

Может ты бэкендер? Этот в высшей степени непростой вопрос разбирается в пространном исследовании Острые орфографические боли по всей длине слова и как от них избавиться на сайте ГЗОМ. Любители отгадывать зажмурьтесь: дальше ответы-спойлеры.

Сегодня нормативно:
Бэк-энд, бэк-энд-разработчик. В профессиональных текстах back-end-разработчик.

Соответствуют русской орфографии:
Бэкендер, бэк-эндовый.

Лет через семь могут возобладать:
Бэкенд, бэкендовый.

---

Предыдущие выпуски:
#26, #25, #24, #23, #22, #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1

Привет всем уже в 21-м году. Надеемся, он будет добрей к нам, чем прошлый. Жизнь продолжается. И мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL. Для разнообразия начну с конференций: этот жанр больше всего пострадал.

Конференции

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

Nordic PGDay 2021

Отменена. Рассчитывают на Хельсинки в марте 2022. Виртуального варианта не будет, но собираются сфокусироваться на PostgreSQL-треке FOSDEM 2021 в феврале. На сайте написано 2022, но имеется в виду, судя по всему FOSDEM 2021, о котором ниже.

А вот подход Highload++. Бескомпромиссный никакого онлайна:
Highload++ 2020 (2021)

Конференцию HighLoad++ не стали переносить в онлайн решили, что она для этого слишком масштабная. Но даты передвинули с 9-10 ноября 2020 г. на 20-21 мая 2021 года. Должна пройти в Москве в Крокус Экспо 3.

А вот полная противоположность:
FOSDEM 2021

Никакого Брюсселя, в 2021 только онлайн. Не только бесплатно, но и регистрации даже не требуется. Среди участников этой огромной конференции немало докладчиков, известных среди российских постгресистов: Олег Бартунов, Павел Борисов, Алексей Кондратов, Анастасия Лубенникова, Никита Глухов (Postgres Professional), Николай Самохвалов (Postgres.ai), Пётр Зайцев (Percona), Андрей Бородин (Yandex), Олег Иванов (Samsung AI Center, он автор плагина AQO в Postgres Pro Enterprise).
Расписание можно попробовать изучить здесь. Поток PostgreSQL здесь.

PGConf.Online 2021

Последняя в этом списке, компенсирую большим количеством знаков: у меня просто больше информации.
Здесь комбинация оф и он: офлайн-конференция PGConf.Russia 2021 запланирована на на конец мая начало июня 2021 года. А 1-3 марта будет проведена онлайн-конференция с соответствующим названием PGConf.Online 2021.

Темы конференции:

• Postgres на предприятии;
• Масштабируемость;
• Высокие нагрузки и очень большие базы данных;
• devops;
• Переход на Postgres.

Участие в онлайновой конференции бесплатное. Всем желающим участвовать нужно предварительно зарегистрироваться на сайте, трансляция докладов будет вестись из личных кабинетов. Если уже оплатили PGConf.Russia 2021, то регистрироваться повторно не нужно. Регистрация действительна для обоих событий PGConf.Online и ближайшего PGConf.Russia. Также можно отказаться от участия в PGConf.Russia и вернуть свои деньги. Для этого надо написать на info@pgconf.ru.

Доклады принимаются до 10 февраля в двух форматах: кратком (22 мин + вопросы) и полном (45 мин + вопросы) на русском и английском языках. Также приветствуются мастер-классы с практическими упражнениями и обучающие лекции по вопросам расширенной разработки и DBA. Мастер-классы могут длиться 90 или 180 минут.

На PGConf.Online 2021 возможны доклады как онлайн, так и предварительно записанные, по желанию. Планируется, что даже после записанного выступления докладчик будет онлайн отвечать на вопросы, которые будут собираться в чате модераторами.

Соревнования

PostgreSQL is the DBMS of the Year 2020

СУБД года! Это не рейтинг популярности, а рейтинг роста популярности. Из рейтингов на январь 2021 вычитаются рейтинги за январь 2020. А они вычисляются по методологии экспертов db-engines. По абсолютной, а не дифференциальной популярности postgreSQL по-прежнему на 4-м месте.
О соревновании x86 с ARM в облаках см. далее.

Облака

Тема ARM в облаках набирает обороты. Что не удивительно ARM наступает широким фронтом: суперкомпьютер на ARM взобрался на верхушку Top500; новые попытки Apple; процессор Whitechapel у Google; процессоры от Ampere Computing появятся в облаках Oracle; ну и, конечно, процессоры AWS Graviton2 с ядром Arm Neoverse в исполнении Amazon.

Вот две статьи: в одной Hosting Postgres on an AWS EC2 t4g Graviton2 ARM Instance рассказывается, как запустить и настроить инстансы t4g (но ещё и о выборе EC2 vs RDS); в другой PostgreSQL on ARM-based AWS EC2 Instances: Is It Any Good? исследуется производительность. Об этом чуть подробней: Жобин Аугустин (Jobin Augustine) и Сергей Кузьмичев (Sergey Kuzmichev) из Percona тестировали ARM vs. x86. ARM на инстансах m6gd.8xlarge на базе ARM-процессоров AWS Graviton2. Сам Amazon позиционирует их как обеспечивающий на 40 % лучшее соотношение цены и производительности по сравнению с показателями x86-инстансов M5 в тестах m5d.8xlarge. В обоих инстансах по 32 виртуальных процессора.

Для разминки прогнали на pgbench, ARM выиграл и на Read-Write и на Read-Only в районе 20%. При этом тестировщики не забывали отключать и включать проверку контрольных сумм мало ли что, архитектура разная. Затем перешли к основным перконовским тестам sysbench-tpcc. Размер базы подбирали так, чтобы она умещалась в память. Стали смотреть результаты на числе потоков от 16 до 128. Получилось, что на 16 примерно та же картина, как и на pgbench, а когда потоков больше, чем виртуальных процессоров, игра в ничью. Чтобы уж совсем не огорчать поклонников x86, авторы констатировали худшую производительность у ARM на тестах, оценивающих ввод-вывод. Но и то при 128 потоках. Подробности в статье и на гитхабе.

Теперь информация, связанных с апгрейдом в облаках Amazon:
Ensuring Consistent Performance After Version Upgrades with Amazon Aurora PostgreSQL Query Plan Management

Query Plan Management это расширение apg_plan_mgmt. В статье показано, как после апгрейда кластера Aurora PostgreSQL с 9.6.11 на 10.12 при помощи этого инструмента можно легко проверить, использует ли планировщик одобренный в предыдущей версии план запроса (планы могут получать статус Approved, Rejected, Unapproved, или Preferred).

Кстати, о версиях:
Amazon RDS for PostgreSQL Supports 12.5

RDS теперь поддерживает минорные версии: 12.5, 11.10, 10.15, 9.6.20 и 9.5.24.

Релизы

pgAdmin 4 v4.30

В этой версии появился (пока в статусе бета) новый инструмент: ERD диаграммы сущность-связь, то есть графическая репрезентация таблиц, столбцов и их взаимосвязей. Можно визуализировать уже существующие схемы БД, можно создавать мышью новые, а ERD сгенерит соответствующие SQL. Также появилась поддержка Kerberos.

PostgreSQL-плагин для Zabbix 5.2.4rc1

В новой версии появилась поддержка custom query для плагина PostgreSQL. Теперь можно создать файл .sql и положить его на свою машину. Далее в web-интерфейсе своего Zabbix-сервера в шаблоне для Zabbix-Agent2 находим элемент под названием pgsql.query.custom и в нем указываем макрос, который должен иметь значение имени sql файла с запросом (при этом в конфигурационном файле Zabbix-Agent2 нужно указать путь на машине к папке с sql файлом. И тогда агент сам выполняет запрос в sql файле и пришлет результат на Zabbix-сервер с остальными, дефолтными метриками. Автор плагина Дарья Вилкова, Postgres Professional.

Целая серия новых версий FDW:

sqlite_fdw 1.3.1
InfluxDB fdw 0.3
griddb_fdw 1.3

PostgresNIO 1.0

Это неблокирующий, event-driven клиент для Swift от Vapor, построенный на эппловской SwiftNIO. Этот клиент устанавливает соединение, авторизует и отправляет запрос на сервер, а результат обратно. Использует протокол PostgreSQL. Умеет создавать пул соединений. И ещё есть пакеты более высокого уровня поверх PostgresNIO postgres-kit.

PGMoon 12.0-1

pgmoon это клиентская библиотека, написанная на чистом Lua (MoonScript). pgmoon с самого начала была разработана для использования в OpenResty web-платформе на базе докрученного Nginx), чтобы можно было пользоваться API 100% неблокирующих cosockets для асинхронных запросов.

Ещё статьи

Расширение кластера PostgreSQL размером 5,7 ТБ и переход с версии 9.6 на 12.4

Статья в блоге Альфа-Банка, автор оригинала Томми Ли (Tommy Li, Coffee Meets Bagel приложение для романтических знакомств с системой курирования).

Базы работали на 6 серверах Postgres на инстансах i3.8xlarge в амазоновском облаке: одна главная нода, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL (Extract, Transform, Load) и Business Intelligence. Для поддержания реплик в актуальном состоянии использовалась потоковая репликация.

Надо было одновременно проапгрейдить Postgres и перейти с i3.8xlarge на i3.16xlarge при минимальной суммарной остановке 4 ч. (а вышло полчаса). Для миграции использовали pglogical. Также в статье из этого опыта извлекли уроки. Эта статья вызвала справедливые и несправедливые замечания в комментариях. Так что примечателен не только сам случай, но и реакция на него, да и тот факт, что перевод статьи появился не где-нибудь, а на хабр-блоге Альфа-Банка (до этого там о базах данных ничего, кажется, не было).

PostgreSQL Scaling Advice For 2021

Каарел Моппел (Kaarel Moppel, Cybertec), чьи статьи регулярно попадают в наши обзоры, дерзнул дать советы тем, кто озабочен будущим масштабированием своих систем. Каарел признаётся, что воодушевился роликом Distributed MySQL Architectures Past, Present, Future Петра Зайцева, основателя и гендира Percona, и приложил (так как, по его, Каарела, словам, MySQL и Postgres суть сводные братья) некоторые выводы Петра к родной PostgreSQL и добавил собственные.

Итого: что даёт обычный Postgres?

• один инстанс PostgreSQL легко выполняет сотни тысяч транзакций в секунду;
• одна нода обычно выполняет десятки тысяч пишущих транзакций в секунду;
• один инстанс Postgres легко справляется с десятками ТБ данных;
• один инстанс на одной ноде даёт буквально пуленепробиваемую надёжность при должной заботе о согласованности данных;
• в причинах сбоев легко разобраться, поэтому данные можно восстановить.

О чём не стоит забывать, когда озаботился масштабированием?

• не бойтесь заводить свои собственные (а не поддерживаемые в облаке) базы данных;
• старайтесь избегать архитектуры данных, у которой в основе одна большая таблица;
• убедитесь, что вы выбрали подходящий ключ разбиения при шардинге вашей таблицы/базы.

Агрегаты в БД

Кирилл Боровиков aka Kilor (компания Тензор) на этот раз обратился к агрегатам. Это мини-серия из двух статей: Агрегаты в БД зачем, как, а стоит ли? и продолжение Агрегаты в БД эффективная обработка потока фактов. В первой движение мысли от count(*) к подсчетам с парсингом EXPLAIN, к сбору агрегатов в отдельную таблицу, к хранению временных агрегатов в памяти процесса и даже к хранению их вообще в другой СУБД.

Во второй статье агрегация обретает бизнес-очертания: пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок. Цель: агрегаты по продажам в разрезе товар/день/кол-во. Разных товаров очень много и отгрузок много. Решение: конкурентная обработка очередей, чтение из курсора читайте подробности.

Образование

Чёрная Малютка

Вышла новая версия знаменитой книжки-малышки
Postgres: первое знакомство.



Книжечка проапгрейдилась до версии PostgreSQL 13. В бумажном виде она, как и раньше, будет раздаваться на конференциях, которые проходят с участием Postgres Professional. PDF можно скачать.

DEV2: Разработка серверной части приложений PostgreSQL 12. Расширенный курс.

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

Митапы и подкасты

Постгрес-вторник с Петром Зайцевым

Петра Зайцева, основателя Percona, Николай Самохвалов и Илья Космодемьянский зазывали на свои Вторники целый год. Свершилось. Был разговор о компании (из которого выяснилось, что сейчас в компании около 300 сотрудников, из них человек 50 постгресистов); о причинах дрейфа компании от MySQL и MongoDB в сторону PostgreSQL (не по любви, и не из-за технологических причин, а просто в это сторону двигались клиенты и потенциальные клиенты); о разной атмосфере в комьюнити MySQL, MongoBD и PostgreSQL (второе самое монополистическое, а третье самое открытое). Но гвоздь программы перконовская утилита мониторинга pg_stat_monitor.

Монитор опирается на расширении pg_stat_statements, но добавляет некоторую функциональность. Можно, например, посмотреть тексты запросов, отбирающих много ресурсов, сравнить прожорливость одного и того же запроса с разными планами; монитор знает название приложения, отправившего запрос. В этом контексте возник и разговор о новом расширении PWR (pgpro_pwr), вошедшем в Postgres Pro Standard и Enterprise 13. Это, кажется, обсудят на следующем Вторнике (мы же обещали статью о нём и обещание скоро сдержим).

Мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Конференция PGConf.Online 2021

Она начинается уже 1-го марта и закончится 3-го. О ней подробно написано в статье Ивана Панченко, зам. гендира Postgres Professional.

На этой конференции (которая не вместо, а кроме офлайновой, теплой-ламповой, она ожидается в конце весны) будет рекордное число иностранных гостей чему явно поспособствовал онлайн-формат. В том числе на этот раз поучаствует и Саймон Риггс (Simon Riggs). Доклады в 3 потока с 10 утра до 6 вечера. А также мастер-классы.

Статьи

PostgreSQL 14: Часть 4 или январское наступление (Коммитфест 2021-01)

Очередной must read Павла Лузанова. Крупные изменения после первых трех относительно скромных коммитфестов (июльский, сентябрьский, ноябрьский).

Вопросы для затравки, предложенные Павлом:

• Могут ли диапазоны содержать пропуски значений?
• Зачем нужна индексная нотация типу json?
• Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
• Сколько времени простаивали сеансы в idle_in_transaction?
• Как построить ER-диаграмму для таблиц системного каталога?

Deep PostgreSQL Thoughts: The Linux Assassin

Слово deep уже пугает: не про ИИ ли это. Но нет. Джо Конвей (Joe Conway, Crunchy Data) действительно копает вглубь. Даже не Постгреса, не своего же расширения plr. На этот раз тема Жуткий Убийца, являющийся из недр Linux OOM Killer.

Джо начинает с истории: первые дискуссии в Postgres-сообществе и первые патчи в 2003-м году как заставить киллера работать по понятиям Postgres. Далее Джо поясняет отношения киллера и Postgres на уровне хоста (oom_score и oom_score_adj) и на уровне CGroup, поясняет, почему так важно не допустить прихода киллера.

И дальше Джо Конвей переходит к специфическим проблемам OOM Killer в Kubernetes это, видимо, и был главный повод для написания этой статьи. Оказывается, что там, в K8s, разрушительная деятельность киллера может начаться даже при относительно благополучном состоянии памяти. В K8s своп по умолчанию выключен. До этого момента автор не трогал тему свопа, которая, вообще-то, очень даже обсуждается среди постгресистов-практиков.

Джо ссылается на обстоятельную статью Криса Дауна (Chris Down) In defence of swap: common misconceptions, причём есть и русский перевод (не автопереводчиком): В защиту свопа: распространенные заблуждения. О Postgres там нет речи, но может заинтересовать и постгресистов.

Также ссылается он на статью The weird interactions of cgroups and linux page cache in hypervisor environments в блоге компании StorPool, где в команде в основном болгарские фамилии.

Далее Джо Конвей плавно переходит к разработкам и усилиям Crunchy Data в треугольнике PostgreSQL Kubernetes ядро Linux.

??
Акула жуёт гугловый кабель (The Guardian??)

Things I Wished More Developers Knew About Databases

Статья не (только) о Postgres. Иногда полезно ещё разок глянуть на разные СУБД с птичьего полёта. Вот внушительный список тем, о которых стоит помнить разработчикам приложений. В статье Джоанна Доган (Jaana Dogan) не поленилась их разворачивать и развивать. Иногда в неожиданную сторону: в пункте #1 мы, например, узнаём, что гугловские кабели давеча покусали акулы. Немало SQL-примеров, схем и есть матрица PostgreSQL vs. MySQL.

• Если сеть доступна 99.999% времени, вам сильно повезло;
• ACID понимают по-разному;
• у каждой СУБД свои возможности поддержки согласованности и изоляции;
• оптимистические блокировки могут помочь, когда удерживать эксклюзивные блокировки нет возможности;
• есть аномалии кроме грязного чтения и потери данных;
• моя СУБД, в каком порядке хочу исполнять транзакции, в таком и исполняю;
• шардинг на уровне приложения не означает шардинг вне СУБД;
• AUTOINCREMENT может преподнести неприятные сюрпризы;
• устаревшие данные могут быть полезны и помогают обойтись без блокировок;
• рассогласования из-за часов;
• под задержками (latency) могут подразумевать разное;
• надо оценивать производительность не по усредненным показателям, а по критическим операциям/транзакциям;
• вложенные транзакции небезопасны;
• транзакции не должны поддерживать состояния приложений;
• планировщик поможет узнать многое о базе данных;
• миграции без останова сложны, но возможны;
• существенный рост базы данных увеличивает непредсказуемость.

Troubleshooting Performance Issues Due to Disk and RAM

Хамид Ахтар (Hamid Akhtar, HighGo, Китай) написал простенькую, но небесполезную памятку для тех, кто хочет быстро сузить круг подозреваемых при поиске проблем с железом. Начав с совсем очевидных top, free и df, он обращается к утилитам анализа производительности дисков, процессора и памяти, и предлагает полезные наборы их опций:
iostat (информация и о диске, и о процессоре), напр. iostat -dmx sda 1
sar (System Activity Report, часть пакета sysstat), напр. sar -f /var/log/sa/sa03 -b -s 02:00:00 -e 02:30:00 -r -S
dstat, напр. dstat -cdngy

А вот скриптик для анализа памяти:

#!/bin/bashgrep -A3 "MemTotal" /proc/meminfo  grep "Swap" /proc/meminfogrep -A1 "Dirty\|Active" /proc/meminfo

.

Starting with Pg where is the config?

Депеш (Хуберт Любашевски) в короткой заметке напоминает, как можно найти конфигурационные файлы, если они лежат в нестандартном месте. Способы, которыми он предлагает воспользоваться не сенсационны, но может быть полезен, скажем, удобный набор опций.
Например, так:
ps -fxao pid,command | grep -E 'post(gres|master)'
на выходе будет path. И отсюда:
sudo grep -E '(hba|ident)\.conf' <путь к postgresql.conf>
Или теперь танцуем от pid:
sudo cat /proc/<подставляем pid>/environ | tr '\0' '\n' | grep ^PG | sort
Или:
sudo lsof -p <подставляем pid> -a -d cwd
получаем каталог данных и сведения о нём.
Если такие советы не понадобились, можно порефлексировать на тему я бы сделал по-другому. Скажем, просто-напросто используя find, например.

Агрегаты в БД

Кирилл Боровиков aka kilor завершил мини-серию статей про агрегаты:

Зачем, как, а стоит ли?

как сделать отчеты быстрыми, способы их реализации и какие грабли встречаются на этом пути;

Эффективная обработка потока фактов

как обработать БОЛЬШОЕ (капслок kilor-а) количество записей и при этом особо никого не заблокировать, включая набегающий поток данных. Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок.

Многомерные суперагрегаты

иерархичные агрегаты в нескольких одновременных разрезах;

Прокси-таблицы

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

Облака

Babelfish: the Elephant in the Room?

Русский перевод названия этой статьи, появившейся на сайте фонда испаноговорящего сообщества FUNDACIN POSTGRESQL звучал бы так: "Вавилонская рыбка или слона-то я и не приметил?" Мы уже упоминали, что идея проекта сверхамбициозная: Bablefish это PostgreSQL, совместимый с SQL Server настолько, что приложения, под него написанные (в том числе с T-SQL и протоколом TDS), будут сразу работать, не зная, что работают с PostgreSQL.

Автор статьи Альваро Эрнандес (lvaro Hernndez Tortosa, OnGres) начинает с рыночной конъюнктуры, чтобы дальше предъявить гамлетовский вопрос, которым авторы Вавилонской Рыбки должны были задаться: форкать или не форкать?

Babelfish пока не может работать как расширение без доработки ядра PostgreSQL. Альваро напоминает, что 25-го января заслуженный и авторитетный в сообществе человек Ян Вик (Jan Wieck) предложил обсудить расширяемость протокола PostgreSQL: сделать такие хуки, которые позволят реализовать протокол SQL Server в виде расширения без изменений в ядре. Но это процесс небыстрый. Заодно решили обсудить и совместимость с MySQL. Но что делать AWS с Bablefish, если сообщество проигнорирует этот путь или интеграция пойдёт ни шатко, ни валко? Вероятней всего, считает Альваро, AWS будет развивать Bablefish как форк (так уже случилось с Aurora), как бы им не хотелось бы обойтись без форка. А если всё же придётся, то AWS это по силам.

Далее Альваро привлекает Дилемму инноватора. И задаёт ещё один интересный вопрос: хотим ли мы (то есть сообщество), чтобы Babelfish стала MariaDB у PostgreSQL?

Персона

Очередной PG-персоной недели стал Александр Сосна, живущий в небольшом городке на Нижнем Рейне и в свободное от работы в credativ время преподающий ИТ-безопасность в Нижнерейнском Университете. Он работает над довольно необычным расширением: pg_snakeoil. Это антивирус специально для PostgreSQL: он ищет вирусы в данных так, чтобы не мешать работе базы, что отнюдь не характерно для обычных антивирусов. Как замечает Александр, за вирусами охотятся не всегда из-за их вредоносности, иногда только потому, что этого требуют нормативные документы.

Релизы

PostgreSQL 13.2

Вышли PostgreSQL 13.2, 12.6, 11.11, 10.16, 9.6.21, 9.5.25 (последний выпуск ветки 9.5). В этих релизах одолели две проблемы безопасности:
в PostgreSQL 13 можно было, имея права на SELCT одного столбца, получить при помощи изощрённого запроса все столбцы таблицы;
вторая проблема касалась версий 11, 12 и 13. Если у пользователя есть права на UPDATE партицированной таблицы, но нет прав на SELECT некоторого столбца, он мог получить данные столбца из сообщений об ошибке.
Кроме того исправлено более 80 багов.

pg_probackup 2.4.9

Появился флаг --force для инкрементального режима. Теперь можно переписывать содержимое в каталоге, указанном в PGDATA, если system-identifier в целевом экземпляре и копии НЕ совпадают (раньше приходило сообщение об ошибке).


pgAdmin 4 v. 5.0

В версии 5.0 среди прочего появилась поддержка логической репликации; поддержка публикаций и подписок в Schema Diff.

Apache AGE 0.3.0

Apache AGE это расширение, добавляющее в PostgreSQL функциональность графовой базы данных. Цель проекта единое хранилище для реляционной и графовой моделей данных, чтобы пользователи могли использовать и стандартный SQL, и языки запросов к графовым базам openCypher и GQL.

Мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL. Этот выпуск получился с некоторым уклоном в средства диагностики. Нет, не только. Например:

Хардверные ускорители: FPGA

В небольшом сообщении Энди Эликотта (Andy Ellicott) в блоге Swarm64 3 hardware acceleration options Postgres users should know in 2020 рассказывается о трёх аппаратных ускорителях, не GPU, а FRGA, и все они в облаках. У автора свой интерес: у Swarm64 есть собственное решение на FPGA-ускорителе. Значимым сигналом он считает объявление Amazon об FPGA-ускорителе кэша (FPGA-powered caching layer) в Redshift AQUA (Advanced Query Accelerator) в Amazon, который убыстряет запросы на порядок. А вообще уже почти все облака (во всяком случае Amazon, Alibaba, и Azure) используют сейчас FPGA-ускорители, просвещает нас Энди.

Итак:

Swarm64 Data Accelerator (DA)
это расширение, которое умеет переписывать обычные SQL-запросы, чтобы распараллеливать вычисления на всех этапах их исполнения, а сотни читающих или пишущих процессов будут работать параллельно на FPGA. Кроме того, там реализованы индексы columnstore, как в MS SQL Server. Есть техническое описание в PDF, но именно про FPGA в нём ничего нет. Зато есть демонстрационное видео, показывающее, как можно легко и быстро развернуть Postgres на инстансе Amazon EC2 F1 с FPGA. Ещё есть результаты тестов TPC-H (а позиционируется эта комбинация с FPGA прежде всего как ускоритель для гибридных транзакционно-аналитических нагрузок HTAP), и там показывает выигрыш в 50 раз по скорости.

Другой вариант, который предлагает Энди: Intel Arria 10 GX FPGA в связке с NVM-памятью Intel Optane DC, SSD и PostgreSQL 11 с тем же расширением Swarm64 DA. Всё это собрано в демо, которое вбрасывает в PostgreSQL потоки биржевых котировок со скоростью 200 тыс инсертов в секунду, и дальше работает с ними с обычным SQL.

Третий вариант с Samsung SmartSSD, в которой внутри FPGA-чип от Xilinx. Испытания (с тем же свормовским расширением, как можно догадаться) дали выигрыш в 40 раз на TPC-H и в 10-15 раз на JOIN-ах.

С маркетинговой точки зрения эти усилия нацелены прежде всего против хардверных решений для WH вроде Netezza или Teradata.

Обещано, что будет и сравнение эффективности FPGA vs. GPU (в т. ч. и в контексте проекта PGStrom).

(спасибо Александру Смолину за наводку в FB-группе PostgreSQL в России)

Конференции

были:

PGConf.online

Теперь выложены все видео и презентации доступ через расписание.

FOSDEM 21

Поток PostgreSQL devroom тёк два дня 6-7 февраля с 10 утра до 6 вечера. Материалов конференции очень много. Вот имеется однобокая, зато систематизированная выборка доклады от Postgres Professional (глаголы будущего времени там надо поменять в уме на глаголы прошедшего).

будет:

Highload++

Объявлено, что состоится офлайн 17 -18 мая 2021 в Крокус-Экспо, Москва. Есть Расписание. Я бы обратил особое внимание на потоки
СУБД и системы хранения, тестирование в Зале 3, например:
Микросервисы с нуля, Семен Катаев (Авито);
Прокрустово ложе или испанский сапог мифы и реальность СУБД в Облаках, Александр Зайцев (Altinity)
и на
Архитектуры, масштабируемость, безопасность в Зал 4 (главном), например:
Архитектура процессора Эльбрус 2000, Дмитрий Завалишин (Digital Zone);
SQL/JSON в PostgreSQL: настоящее и будущее, Олег Бартунов (Postgres Professional);
Распространённые ошибки изменения схемы базы данных PostgreSQL, Николай Самохвалов (Postgres.ai).

Вебинары и митапы

RuPostgres-вторник s02e13 Андрей Зубков (PostgresPro) pg_profile, pgpro_pwr

Вторник, посвященный pg_profile / PWR, так заинтересовал устроителей, что с большой вероятностью в ближайшее время можно ожидать продолжения: разобрались не во всех тонкостях работы этого весьма практичного инструмента, ну а расширения pgpro_stats, которое используется в PWR, коснулись по касательной.

После это был ещё вторник с Александром Кукушкиным (Zalando). Тема риски апгрейда мажорных версий с фокусом на PG12 и PG13, а пособник апгрейда Spilo: как выяснилось, бесшовный апгрейд в контексте Patroni задача слишком амбициозная, а вот Spilo, то есть Docker-образ с PostgreSQL и Patroni, с задачей справляется. Но опасностей и нюансов при апгрейде остаётся немало. Говорилось о сюрпризах от VACUUM, ANALYZE, о параллелизме по умолчанию, о CTE и материализации, о JIT.

Database Delivery: The Big Problem

Это была презентация от Ростелеком-ИТ, которую провёл Роман Гордеев (в видео глюки, надо прокрутить первые 11 минут). Его пригласили на один из стримов Tver.io сообщества тверских айтишников (но мне удобней было смотреть этот же ролик на на youtube). Речь шла об инкрементальной стратегии миграции. Роман рассказывал о вещах, применимых к разным СУБД и средам разработки, но для примера был выбран переход с базы PostgreSQL на H2 в графическом DataGrip. Соответственно в реальном времени наблюдались и решались проблемы с постгресовым типом text и с последовательностями.

В качестве механизма, который контролирует миграцию, был взят плагин liquibase для среды gradle. О настройках для такой работы можно почитать на страничке liquibase gradle на гитхабе Гордеева. Кстати, Ростелеком Информационные Технологии компания с населением под 2 тыс. человек. На официальной странице есть информация об опенсорсной СУБД in-memory Reindexer собственной разработки. Больше о базах там ничего пока найти не удалось.

Обучение

Выложены в общий доступ видео:

• Разработка серверной части приложений PostgreSQL 12. Базовый курс.
• Разработка серверной части приложений PostgreSQL 12. Расширенный курс

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

Тем, кто интересуется более пристально, советую прослушать доклад о курсах Егора Рогова на PGConf.online 2021.

Мониторинг

Monitoring PostgreSQL with Nagios and Checkmk

Пишет опять Хамид Ахтар (Hamid Akhtar, китайская компания High Go), на этот раз пишет о средствах мониторинга Nagios (рекурсивный акроним Nagios Ain't Gonna Insist On Sainthood Nagios не собирается настаивать на святости, в отличие от его предшественника NetSaint) и Checkmk. Публикация без претензий: как установить и настроить, не претендуя даже в этом на полноту.

Explaining Your Postgres Query Performance

Идём от простого к сложному. Пока URL подсказывает возможный подзаголовок статьи: Get Started with EXPLAIN ANALYZE. Кэт Бэтьюйгас (Kat Batuigas, Crunchy Data) действительно знакомит с самыми азами EXPLAIN, даже без опций. Жанр For dummies, и наглядно: показывает, как с помощью EXPLAIN ANALYZE можно наблюдать решения планировщика об (не)использовании индексов, и вообще что там происходит. Иллюстрируется это всё на базе Geonames.

Предыдущая её статья была о Query Optimization in Postgres with pg_stat_statements.

Вот ещё одна её статья: Three Easy Things To Remember About Postgres Indexes. В ней не только напоминания о том, что индекс занимает место на диске, но и, например, такие соображения:
Важен и тип запроса. Например, если в запросе есть знаки подстановки (wildcards)
wildcards, e.g. WHERE name LIKE 'Ma%',
то планировщик задействует по умолчанию индекс B-tree, но вам, возможно, стоит указать класс оператора, чтобы был выбран эффективный индекс.

Can auto_explain (with timing) Have Low Overhead?

Михаэль Христофидес (Michael Christofides) показывает работу расширения auto_explain с включённым и отключённым таймингом. Выводы:

Если задать ощутимый промежуток времени min_duration, издержки от auto_explain на небольшой транзакционной нагрузке )была меньше 1% с отключённым таймингом и ~2% с включённым. Семплинга не было, поэтому детали прослеживались для каждого запроса, но попадали в лог для медленных. А когда min_duration=0ms, и логировалось всё, издержки оказались больше 25%, даже без тайминга и ANALYZE. Видимо, издержки auto_explain связаны в основном с логированием.

Интерес у Михаэля не невинный он разработчик утилиты pgMustard, которая визуализирует планы. Она также расписывает, сколько тратится времени и сколько строк возвращает каждая операция (в т.ч. циклы; дочерние узлы планов subplans; CTE). Мало того, pgMustard умеет подсказывать. Например:

• (не)эффективность индексов;
• плохая оценка числа строк;
• неэффективность кэша;
• угроза распухания индекса (bloat);
• CTE-скан использовался только 1 раз.

How to create a system information function in PostgreSQL

Давид Ян (David Zhang, старший системный архитектор в той же High Go) делится опытом написания собственных информационных функций. Ему мало тех, что можно найти на вот этой странице. Например, его не устраивает, что txid_current() возвращает ему тот же идентификатор транзакции, что и было до SAVEPOINT.

Ссылаясь на страничку Исходные данные системных каталогов, Давид показывает, как выбрать OID для новой функции, чтобы он не конфликтовал с существующими. Потом приводит код своей функции, определяющей xtid после SAVEPOINT. Называется она txid_current_snapshot и написана на C. И тестирует её. Теперь идентификатор транзакции показывается корректно.

How The PostgreSQL Optimizer Works

Ханс-Юрген Шёниг (Hans-Jrgen Schnig, Crunchy Data) написал не то, чтобы концептуальную, но большую по объёму статью, в которой есть примеры, демонстрирующие:

обработку констант: почему

WHERE x = 7 + 1

для оптимизатора не то же, что

WHERE x - 1 = 7

встраивание функций (function inlining): умение оптимизатора встраивать функции зависит от языка, в SQL он как дома, но не в PL-ях.

как обрабатываются функции, если они VOLATILE/STABLE/IMMUTABLE. Например:

WHERE x = clock_timestamp()

против

WHERE x = now()

что способен понять PostgreSQL, задумавшись о том, что чему равно:
понять, что если x = y AND y = 4, то x = 4, а значит можно использовать индекс по x это он может.

что такое view inlining и subselect flattening:
как представление превращается во вложенные SELECT-ы, а они в обычный, плоский SELECT.

Ну и, конечно, центральный вопрос как оптимизатор расправляется с JOIN. Тут Ханс-Юрген рассказывает об очерёдности джойнов, о явных и неявных; об OUTER JOIN; автоматическом исключении (pruning) ненужных; об EXIST и анти-джойнах.

Случайности:

Они не случайны

Кирилл Боровиков ака kilor выступил в роли волшебника: он угадывает случайные числа! Он придумал волшебную функцию и даже назвал её magic(). В качестве аргумента она берёт только что сгенерённое функцией random() число и предсказывает следующее:

SELECT r random, magic(r) random_next FROM random() r;       random       |    random_next--------------------+-------------------- 0.3921143477755571 | 0.6377947747296489tst=# SELECT r random, magic(r) random_next FROM random() r;       random       |    random_next--------------------+-------------------- 0.6377947747296489 | 0.5727554063674667

Чтобы исследовать содержание внутренностей волшебной функции, автор предлагает разобраться в линейном конгруэнтном алгоритме, который используется в random(), залезает в код функции setseed() в файле float.c и там находит источник вдохновения для создания своей волшебной функции.

Итого, случайные числа random() не слишком случайны, о криптографии и речи не может быть. Но кое-какие альтернативы имеются: более безопасны функции в расширении pgcrypto.

Восстановление

Speeding up recovery & VACUUM in Postgres 14

Статья на сайте Citus, но речь не о Citus, а о патче в основную ветку PostgreSQL. Написана статья (и патч) Дэвидом Роули (David Rowley), работавшим над этим уже внутри Microsoft. Он переписал внутреннюю функцию compactify_tuples, которая используется, когда PostgreSQL стартует после внештатного (нечистого) шатдауна (crash recovery), и когда идёт восстановление standby-сервера проигрыванием WAL по их прибытии с primary-сервера; VACUUM.

Эти случаи Дэвид и расписывает, поясняя схемами. Новая версия функции избавляет от ненужной внутренней сортировки кортежей в heap, поэтому и работает быстрее. На pgbench выигрыш в 2.4 раза на восстановлении и на 25% при вакууме.

Соревнования

Performance differences between Postgres and MySQL

В сообществе Arctype очень интересуются сравнительной производительностью PostgreSQL и MySQL. Эта сумбурная статья с приятными выводами продолжение вот этой, где преимущества той и другой СУБД оценивали качественно, и пришли в том числе к выводам о преимуществах PostgreSQL. Он лучше когда:

• надо работать со сложно устроенными или объёмистыми данными;
• аналитические нагрузки;
• нужна транзакционная база общего назначения;
• требуется работа с геоданными.

А на этот раз решили померить, причём с уклоном в JSON, поскольку эта тема интересует в сообществе очень многих и очень сильно. Вот что было сделано:
создан проект, в котором использовались PostgreSQL и MySQL;
создали объект JSON для тестирования чтения и записи, размер объекта около14 МБ, около 200210 записей в базе данных.

И опять приятный вывод:
JSON-запросы быстрей в Postgres!

Кроме этого автор по касательной упоминает индексы по выражениям и прочие, особенности репликации, принципиальные отличия MVCC в InnoDB MySQL и в PostgreSQL.

PostGIS

Traveling Salesman Problem With PostGIS And pgRouting

У Флориана Надлера (Florian Nadler, Cybertec) проблемный коммивояжер странствует по окрестностям Гамбурга. Это продолжение статьи 'Catchment Areas' With PostgreSQL And PostGIS. Там собрали множества городов, ближайших к крупным аэропортам, разбросав их по диаграммам Вороного.

Теперь, надо решить, как лучше эти города обойти, для чего кроме PostGIS Флориан использует функции расширения pgRouting. Чтобы превратить множество точек в граф, он выбирает утилиту osm2po.

Дальше pgr_createverticestable функция из pgRouting превратит граф в таблицу. Эта таблица-граф накладывается как слой поверх слоёв OpenStreetMap. После этого Флориан, используя функцию pgr_dijkstraCostMatrix из pgRouting, решает эту знаменитую задачу оптимизации с помощью замысловатого запроса с CTE, учитывая стоимости/веса, присвоенные ещё osm2po.

Performance Improvements in GEOS

GEOS важнейшая для геовычислений библиотека (алгоритмы портированы на C из Java Topology Suite или JTS). Crunchy Data вкладывают в её развитие не меньше сил, чем в саму PostGIS.

Пол Рамси ( Paul Ramsey) рассказывает не просто о тестах производительности GEOS (довольно специфических), а взглядом историка GEOS иллюстрирует ими хронологию улучшений в этой библиотеке от релиза 3.6 к свежайшему 3.9. Вообще-то, о GEOS 3.9 Пол говорил и раньше в начале декабря в блоге Crunchy Data Waiting for PostGIS 3.1: GEOS 3.9 и в собственном. Там тоже есть роскошные иллюстрации, но нет графиков производительности.

А вот заметку Пола Рамси Dumping a ByteA with psql можно увидеть только в его блоге. Она короткая, но может оказаться полезной тем, кто:

• хранит двоичные файлы в столбцах базы, например изображения-ярлычки (thumbnails);
• хочет сформировать на выходе двоичный файл изображения, песни, protobuf или LIDAR-файл;
• использует двоичный формат для транзита двух разных типов.

Хранить в двоичном виде картинку можно, а вот посмотреть нельзя нужен файл. Вот скриптик, который берёт из базы ярлычок в типе bytea, через psql двоичное значение обертывается функцией encode и выгружается как обычное текстовое. Вывод psql перенаправляется в утилиту xxd, которая декодирует входной поток (ключ -r) обратно в двоичный вид и записывает в файл .png:

echo "SELECT encode(thumbnail, 'hex') FROM persons WHERE id = 12345" \  | psql --quiet --tuples-only -d dbname \  | xxd -r -p \  > thumbnail.png

Такой способ будет работать для любого поля bytea.

Активная жизнь в коммьюнити

How many engineers does it take to make subscripting work?

Дмитрий Долгов (Zalando) пишет в своём личном блоге в смешанном жанре: о довольно сложных и специальных технических проблемах самого патча, но и извлекает из истории их решения этакую мораль для писателей патчей. Таких, чтобы сообщество PostgreSQL было в состоянии принять их за время меньше бесконечности.

Патч добавляет subscripting в синтаксис функций JSONB то есть как у массивов, например:

SET jsonb_column['key'] = '"value"';

вместо

SET jsonb_column = jsonb_set(jsonb_column, '{"key"}', '"value"');

Началась история этого патча в 2015 году с беседы Дмитрия с Олегом Бартуновым и последовавшего простенького патча Долгова. Сообщество отнеслось к патчу сочувственно, но предложило переписать его в более универсальной манере, чтобы подобную функциональность можно было бы использовать и для других типов данных. Соответствующий патч Дмитрия был непрост, и ревюеры не торопились его разобрать и оценить. Ещё в истории этого патча фигурируют Том Лейн (Tom Lane), закоммитивший финальный патч Александр Коротков, Павел Стехуле (Pavel Stehule) и Никита Глухов.

Затрагиваются темы универсальности и, пожалуй, лучшее враг хорошего. Патч продвигался настолько вяло, что Дмитрий в отчаянии даже написал в комментарии к патчу: если вы дочитали до этой фразы и напишете рьвю, я выставлю бутылку пива на следующей PGConfEU (о судьбе бутылки из статьи мы не узнали).

В финале статьи 8 советов. Вот некоторые из них в моём вольном переводе, начиная с последнего Last but not least:

Сделать ревю патча требует существенных усилий, поэтому не стесняйтесь тратить усилия, делая ревю патчей ваших коллег.

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

Разбейте патч на несколько частей это всегда облегчает работу ревьюеров.

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

Облака и контейнеры

Running Postgres In Docker Why And How?

Каарел Моппел (Kaarel Moppel, Cybertec) задаёт себе вопрос можно и нужно ли использовать PostgreSQL в Docker в качестве продакшн, будет ли он вообще там работать? и отвечает: да, работать будет, если сильно постараться, и если для фана или для тестирования.

В статье несколько разделов, но начнём с предпоследнего Капли дёгтя в бочку мёда.

Докер-имиджи да и вся концепция контейнеров оптимизированы под моментальное разворачивание в стиле стартапов . По умолчанию там даже данные не разведены как следует по томам (persistent units). Если этого не сделать, затея может закончится катастрофой.

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

У вас будет относительно лёгкая жизнь только в том случае, если вы используете такой всеобъемлющий фреймворк, как Kubernetes плюс выбираете оператор (скорее всего от Zalando или Crunchy).

Поведение

The PostgreSQL Community Code of Conduct Committee Annual Report for 2020

Этот документ сообщества переводили на русский Анастасия Лубенникова, Александр Лахин и Анастасия Распопина (все из Postgres Professional), также участвовали Виктор Егоров и Валерия Каплан. Ещё он переведён с английского на японский и иврит.

Число жалоб увеличилось в 2020: 18 против 12 в прошлом году. Мужчины жалуются чаще: 15/3. Обычно от страны по жалобе. По 2 только от РФ, Аргентины, UK и US.

Автор Игорь Косенков, инженер postgres Professional

Привет всем! Сегодня речь пойдет о кластере. Да, снова об отказоустойчивом кластере на базе Corosync/Pacemaker. Только настраивать мы его будем не как обычно с помощью утилиты pcs, а с помощью мало используемой утилиты crm.

С точки зрения использования этих утилит (pcs и crm) весь мир Unix-like операционок делится на два вида:

• содержит пакеты утилиты pcs (RHEL, CentOS, Debian, Ubuntu);
• содержит пакеты утилиты crm (SLES, Opensuse, Elbrus, Leningrad и т.д.).

crm cluster resource manager специальная утилита, которая используется для создания и управления отказоустойчивым кластером. Она включена в пакет crmsh, который обычно не входит в состав самых распространенных дистрибутивов Linux.

Идея написать статью об этой утилите пришла однажды, когда я спросил у поисковика: Как настроить отказоустойчивый кластер с помощью crm. В ответ не получил ничего нужного и полезного, т.к. поисковик мне предложил много вариантов, никак не связанных с crm.

В то же время, если спросить у поисковика про утилиту настройки кластера pcs, которая является по функционалу такой же утилитой, как и crm, то информации будет много. Есть даже несколько статей на Хабре (в том числе и моя статья Кластер pacemaker/corosync без валидола).

Утилита crm такая же мощная и гибкая, как и pcs, но незаслуженно обделена вниманием.

Решено было исправить этот пробел и написать статью.

Причины, по которым те или иные разработчики дистрибутивов предпочитают кто crm, а кто pcs, мне неизвестны. Могу предположить, что все дело в зависимостях. Например, если сравнить количество зависимостей у pcs и crm, то получается такая картина:

$ sudo rpm -qpR crmsh-3.0.1-1.el7.centos.noarch.rpm | wc -l19$ sudo rpm -qpR pcs-0.9.169-3.el7.centos.x86_64.rpm | wc -l50

Сторонники минимализма, скорей всего, предпочтут crmsh. А если еще учесть, что pcs тянет за собой ruby, openssl, pam и python, а crmsh только python, то выбор в некоторых случаях будет однозначно на стороне crm. В каких случаях? Ну, например, при сертификации ОС есть некоторые трудности с пакетом ruby. Также известны случаи, когда в банковских структурах служба безопасности не разрешает установку нерегламентированного ПО.

Сходства и различия

У утилиты crm есть как сходства, так и различия с известной всем утилитой pcs.
Сходства утилит приведены в таблице 1:



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



Различия начинаются с самого начала с момента инициализации кластера. Инициализировать кластер с помощью crm можно одной командой, а у pcs это происходит в два этапа авторизация и инициализация.

Удалить кластер (разобрать) у pcs можно одной командой сразу, а у crm необходимо удалять по одному узлу до тех пор, пока их не останется в кластере.

Чтобы изменить параметры ресурса, который мы уже создали в кластере, у pcs есть опция update. У crm такой опции нет, но есть команда configure edit, которая позволяет менять любые настройки кластера налету и мгновенно. Даже больше мы можем за один прием отредактировать любое количество параметров и ресурсов, и в конце редактирования применить все изменения сразу. Удобно? Думаю, да.

Еще различие у pcs есть веб-интерфейс, с помощью которого можно выполнить различные действия запустить, остановить, создать какой-нибудь ресурс с помощью любого браузера.

У crm в стандартной поставке нет веб-инструмента, но зато он есть в коммерческой версии SUSE HAWK.

Подготовка к настройке отказоустойчивого кластера

Лучший способ узнать и познакомиться с crm это настроить отказоустойчивый кластер.

Чем мы сейчас и займемся. Для примера возьмем ОС CentOS 7.9.

Для создания отказоустойчивого кластера PostgreSQL нам понадобится стенд, состоящий из 3-х узлов node1, node2, node3. На каждом узле установлена ОС CentOS 7.9 и пакеты corosync, pacemaker, fence-agents* (агенты фенсинга).

В качестве СУБД будем использовать Postgres Pro Standard v.11, но вы можете с таким же успехом использовать ванильную версию PostgreSQL. В нашей системе установлены необходимые пакеты postgrespro-std-11-server, postgrespro-std-11-libs, postgrespro-std-11-contrib, postgrespro-std-11-client.

Настройки СУБД (postgresql.conf) и доступа к ней (pg_hba.conf) не рассматриваются в данной статье, информации об этом достаточно в интернете. На одном из узлов (например, node1) необходимо инициализировать базу данных с помощью initdb, а на двух других узлах с помощью pg_basebackup скопировать базу данных с node1.

Кроме того, в будущем кластере должны быть настроены синхронизация времени на узлах и разрешение имен узлов в кластере с помощью файла /etc/hosts.

ПРИМЕЧАНИЕ:
В этом разделе все команды необходимо выполнить на всех узлах кластера.
Поскольку пакет crmsh не входит в состав дистрибутива ОС, то необходимо подключить репозиторий Extra OKay Packages for Enterprise Linux с этим пакетом.

node1,2,3$ sudo rpm -ivh http://repo.okay.com.mx/centos/7/x86_64/release/okay-release-1-5.el7.noarch.rpm

Нам также понадобится репозитарий EPEL:

node1,2,3$ sudo yum install epel-releasenode1,2,3$ sudo yum update

Устанавливаем пакет crmsh:

node1,2,3$ sudo yum install crmsh

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

Разработчики crmsh вставили код вызова этой кластерной утилиты для удобства настройки. Можно, конечно, обойтись и без csync2, но в таком случае будет больше ручной работы с конфигурационными файлами на каждом узле.

ОТСТУПЛЕНИЕ:
Сервис csync2 может использоваться не только для создания отказоустойчивого кластера Corosync/Pacemaker. Например, если есть несколько серверов, у которых меняются конфигурационные файлы и эти файлы периодически нужно синхронизировать по критерию самый свежий файл.

Итак, устанавливаем csync2 и простейшую базу данных для хранения мета-данных (sqlite).

$ sudo yum install csync2 libsqlite3x-devel

Тут нас поджидает подводный камень.

Поскольку csync2 и crmsh не являются родными для CentOS, то без дополнительных танцев сразу после установки они не заработают. Вызов crm влечет вызов утилиты csync2, которой в свою очередь не хватает парочки systemd-юнитов. Почему этих файлов нет в пакете csync2 для CentOS мне неизвестно. Замечу, что в коммерческом дистрибутиве SLES (crmsh там родной) все необходимые файлы есть, все работает из коробки сразу после установки пакетов.
Итак, создадим и добавим недостающие systemd-юниты.
Первый называется csync2.socket и содержит:

[Socket]ListenStream=30865Accept=yes[Install]WantedBy=sockets.target

Второй называется csync2@.service с таким содержимым:

[Unit]Description=csync2 connection handlerAfter=syslog.target[Service]ExecStart=-/usr/sbin/csync2 -i -vStandardInput=socketStandardOutput=socket

Оба файла нужно разместить в стандартной папке systemd /usr/lib/systemd/system.

Юнит, относящийся к сокету, нужно активировать и установить в автозапуск при загрузке ОС:

node1,2,3$ sudo systemctl enable --now csync2.socket

Примечание. Все настройки выполнялись для ОС CentOS, но есть подозрение, что эти действия также понадобятся и для других систем, например, для Debian или Ubuntu.

Теперь у нас все готово к началу работ по настройке кластера.

Настройка кластера с помощью crm

Настройка кластера производится в 2 этапа инициализация, затем создание и добавление ресурсов. Инициализация кластера с настроенным сервисом синхронизации конфигураций csync2 производится на одном узле.

Если по каким-то причинам вам не удалось победить этот сервис, то это не беда, в конце статьи я расскажу, как обойтись без csync2.

На всякий случай сначала удалим кластер (на всех узлах) с помощью такого набора команд:

node1,2,3$ sudo systemctl stop corosync;sudo find /var/lib/pacemaker/cib/ -type f -delete; sudo find -f /etc/corosync/ -type f -delete

Далее надо выполнить команду инициализации кластера:

node1$ sudo crm cluster init --name demo-cluster --nodes "node1 node2 node3" --yes

где demo-cluster название нашего кластера.

По этой команде создаются необходимые файлы в папке /etc/corosync: corosync.conf, ключ авторизации authkey, а также прописываются ssh-ключи для беспарольной авторизации и выполнения команд в кластере с привилегиями суперпользователя root (на всех трех узлах кластера).

По умолчанию инициализация кластера выполняется в режиме multicast. Но есть также возможность проинициализировать кластер в режиме unicast:

node1$ sudo crm cluster init --unicast --name demo-cluster --nodes "node1 node2 node3" --yes

Кластер проинициализирован и запущен.
Проверить работоспособность можно с помощью консольного монитора состояния кластера crm_mon:

node1$ sudo crm_mon -Afr

Далее можно приступать к созданию ресурсов в кластере.

Создание ресурсов в кластере

Для начала поменяем некоторые значению по умолчанию. Например, порог миграции ресурсов migration-threshold по умолчанию равен 0. Меняем на 1, чтобы после первого сбоя ресурсы мигрировали на другой узел.

node1$ sudo crm configure rsc_defaults rsc-options: migration-threshold=1 resource-stickiness=INFINITY

По умолчанию, кластер запускается в симметричном режиме.

Чем отличается симметричный кластер от несимметричного? В симметричном кластере любой созданный ресурс будет запускаться на любом узле, если не установлены дополнительные правила размещения или старта.

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

Зачем это нужно? Ну, например, в ситуации, когда в кластере ресурсы запускаются не на всех узлах, т.е. узлы неравноценны по ресурсам и назначению.

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

node1$ sudo crm configure property symmetric-cluster=false

Мы оставим этот параметр без изменения.

Включаем механизм stonith:

node1$ sudo crm configure property stonith-enabled=yes

Создадим и добавим ресурс виртуальный IP адрес:

node1$ sudo crm configure primitive master-vip IPaddr2 op start timeout=20s interval=0 op stop timeout=20s interval=0 op monitor timeout=20s interval=10s params ip=<virtual IP> nic=eth0

где <virtual IP> виртуальный IP-адрес в кластере.

С помощью монитора состояния кластера crm_mon можно убедиться в том, что ресурс успешно создан и запущен на первом попавшемся узле:

node1$ sudo crm_mon -Afr

Создадим ресурс postgresql и назовем его pg:

node1$ sudo crm configure primitive pg pgsql op start interval=0 timeout=120s op stop interval=0 timeout=120s op monitor interval=30s timeout=30s op monitor interval=29s role=Master timeout=30s params pgctl="/opt/pgpro/std-11/bin/pg_ctl" psql="/opt/pgpro/std-11/bin/psql" pgdata="/var/lib/pgpro/std-11/data" pgport="5432" repuser=postgres master_ip=<virtual IP> rep_mode=sync node_list="node1 node2 node3"

ПРИМЕЧАНИЕ:
В данном примере пути расположения бинарников и БД указаны по умолчанию для версии Postgres Pro Std 11. Также для упрощения указан пользователь для репликации postgres. Но ничто не мешает вам изменить умолчательные пути и пользователя репликации на свои.

Хочу обратить внимание на параметр rep_mode: он задан sync. Это означает, что в отказоустойчивом кластере хотя бы одна реплика будет синхронной. Синхронность реплики в кластере обеспечивает RPO=0 (кластер без потерь данных в случае сбоя).

Зададим тип ресурса Master-Standby (ms):

node1$ sudo crm configure ms mspg pg meta target-role=Master clone-max="3"

Нам нужно, чтобы ресурсы vip-master и mspg в режиме мастер запускались на одном узле:

node1$ sudo crm configure colocation pgsql-colocation inf: master-vip:Started mspg:Master

Указываем порядок запуска ресурсов сначала СУБД в режиме мастер, потом виртуальный IP:

node1$ sudo crm configure order order-promote-pgsql Mandatory: mspg:promote master-vip:start

Таким образом, мы создали 2 необходимых ресурса виртуальный IP адрес и ресурс postgresql.

Теперь можно переходить к настройке фенсинга в отказоустойчивом кластере.

Фенсинг узлов

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

Для начала можно ознакомиться со списком всех агентов фенсинга:

node1$ sudo crm ra list stonith

На моем стенде node1, node2, node3 это виртуальные машины, которые запущены и управляются с помощью гипервизора KVM. Соответственно, ресурс-агент фенсинга для KVM называется fence_virsh.

Вывести полную информацию о fence_virsh:

node1$ sudo crm ra info stonith:fence_virsh

Прежде чем создавать ресурс фенсинга, рекомендую проверить работоспособность всей цепочки от ОС виртуалки до гипервизора.

Проверка работоспособности фенсинга для узла node1 выглядит так:

node1$ fence_virsh -a <hypervisor IP> -l <username>-p <password> -n node1 -x --use-sudo -o status

где username & password учетная запись на хосте гипервизора.

Фенсинг для node1 настраивается так:

node1$ sudo crm configure primitive fence-node1 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node1 sudo=1 op monitor interval=60s

ПРИМЕЧАНИЕ:
Ресурсы фенсинга не должны запускаться на своих узлах, иначе фенсинг может не сработать.
Следующее правило расположения запретит ресурсу фенсинга для узла node1 располагаться на этом узле:

node1$ sudo crm configure location l_fence_node1 fence-node1 -inf: node1

Для node2:

node1$ sudo crm configure primitive fence-node2 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node2 sudo=1 op monitor interval=60snode1$ sudo crm configure location l_fence_node2 fence-node2 -inf: node2

Для node3:

node1$ sudo crm configure primitive fence-node3 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node3 sudo=1 op monitor interval=60snode1$ sudo crm configure location l_fence_node3 fence-node3 -inf: node3

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

Инициализация кластера с помощью crm без csync2

Как обещал выше, расскажу про вариант инициализации кластера без установки и настройки csync2 (если по каким-то причинам вам не удалось его настроить).

Сначала вариант с использованием multicast.

Все команды выполняются на одном узле, например, на node1.

node1$ sudo crm cluster init --name demo-cluster --nodes "node1" --yes

По этой команде создаются необходимые файлы в папке /etc/corosync: corosync.conf, ключ авторизации authkey.

Далее нужно скопировать авторизационный файл authkey и corosync.conf на узлы node2 и node3:

node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node2:/etc/corosync/node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node3:/etc/corosync/

На остальных узлах (на node1 кластер уже запущен) запустить кластер:

node2,3$ sudo crm cluster start<source>С помощью монитора crm_mon можно убедиться, что кластер проинициализирован и запущен:<source lang="sh">node1$ sudo crm_mon -Afr

В случае настройки кластера с использованием unicast действия и команды будут отличаться.

Все команды выполняются на одном узле, например, на node1.

node1$ sudo crm cluster init --unicast --name demo-cluster --nodes "node1" --yes

Открываем файл /etc/corosync/corosync.conf и добавляем строки в секцию nodelist:

node {ring0_addr: node2nodeid: 2}node {ring0_addr: node3nodeid: 3}

В секции quorum меняем число голосов:

expected_votes: 3

Далее необходим рестарт сервиса corosync на первом узле:

node1$ sudo systemctl restart corosync

Затем нужно скопировать файл authkey и отредактированный corosync.conf на узлы node2 и node3:

node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node2:/etc/corosync/node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node3:/etc/corosync/

На остальных узлах (на node1 кластер уже запущен) запустить кластер:

node2,3$ sudo crm cluster start

С помощью монитора crm_mon можно убедиться, что кластер проинициализирован и запущен:

node1$ sudo crm_mon -Afr

На этом инициализация кластера без csync2 закончена.

Вспомогательные команды crm

При работе с кластером могут пригодиться некоторые crm-команды.
Для удобства команды и пояснения сведены в таблицу 3:



На этом все. Буду рад, если статья поможет кому-то в создании и настройке отказоустойчивого кластера с помощью утилиты crm.