Pull to refresh
142.19
Postgres Professional
Разработчик СУБД Postgres Pro

Postgresso 34

Reading time 19 min
Views 3.9K


В ожидании PostgreSQL 15


PostgreSQL 15: Часть 1 или Коммитфест 2021-07

Думаю, вы следите за обзорами Павла Лузанова о новостях коммитфестов. Если нет, то задумайтесь, не стоит ли. Павел, между прочим, не перечисляет буквально все патчи, а отбирает значимые, обычно с SQL-примерами.

Название скромничает: в обзоре также и о PostgreSQL 14 — принятые доработки. Но больше о 15-й. Часто Павел даёт коротенький код, демонстрирующий изменения — в духе «вот так запрос работал в 14-й, а в 15-й уже вот так». Иногда заныривает и глубже в историю — в 13-ю, если это оправдано контекстом, как при анализе pg_dump и схема public, например.

Напоминаем, что самое интересное о 14 версии можно прочитать и в предыдущих статьях: 2020-07, 2020-09, 2020-11, 2021-01 и 2021-03.


Уже начинают появляться заметки «в ожиданиях PostgreSQL 15». Депеш — Hubert 'depesz' Lubaczewski — в первом ряду. В меню его сайта есть отдельный пункт Waiting for (аж со времён 8.4!), и вот в его вейтингах появился пункт меню 15, пока там одинокая заметка:

Waiting for PostgreSQL 15 – Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.

Это будет важное изменение: раньше не суперюзер по умолчанию мог создавать объекты в схеме public в базе, которой не владел. На то, вроде бы, она и public. Одних устраивало, другие считали это дырой в безопасности. В 15-й всё будет строго.

Права на public по умолчанию обсуждаются и в только что упомянутом обзоре Коммитфеста 2021-07 Павла Лузанова.

Задача о ранце. Теория? Fun? Бизнес?


Она же задача о рюкзаке, она же Knapsack problem. Одна из NP-полных задач. И то, и другое, и третье, конечно.

На этот микрообзор нас спровоцировала недавняя статья:

Solving the knapsack problem in PostgreSQL. Автор Франческо Тизьё (Francesco Tisiot, о нём известно, что он Developer Advocate (!) в финской компании Aiven). Цель вполне скромна: показать возможности программирования с рекурсивным CTE. А также проиллюстрировать, как написать ограничения. Больше ликбез и фан (сначала, до переименования статья называлась «PostgreSQL в помощь пакующим рюкзак для похода на каникулах» — всё же рюкзак, хоть и не backpack).

Но практическая польза задачи о ранце вовсе не скромна: компании вроде Google, Facebook, Amazon наверняка зададут вам на интервью какой-нибудь вопрос, связанный с этим алгоритмом — практичней не придумаешь!

Этим практическая ценность, конечно, не исчерпывается. По актуальности среди NP-полных задач Ренец уступает, разве что Коммивояжёру (дошло до того, что Amazon, не удовлетворённая производительностью доступных суперкомпьютеров с сотнями петафлопсов, проинвестировала в квантовый стартап, который готов ублажить Amazon квантовыми спецрешениями для их софтовых коммивояжёров; но там не до SQL).

Здесь мы не будем рассказывать об алгоритмической части, и о том, какие разновидности задачи о рюкзако-ранце существуют и в скольких измерениях.

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

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

Это отсюда: Будни автоматизации или «мне нужна программка для 3D упаковки».

Но почему в базе, а не в приложении?

он [внешний фреймворк] не очень хорошо приспособлен для задач с объемными вычислениями. Обычный цикл у нас выполняется гораздо дольше, чем в компилируемом языке. Поэтому простые, но массовые вычисления бывает удобнее делать на стороне сервера непосредственно на уровне СУБД. Для работы с базой данных у нас используется язык, очень похожий на T-SQL.

Читателям предлагается угадать, о каком языке говорит автор с «Инфософта». Это, мягко говоря, несложно. Она же опубликована и на самом Инфостарте. Это одна и та же статья — и не одна и та же одновременно: в инфостартовском варианте к ней подшиты ещё и комментарии числом 118, в которых — в том числе — автор расписывает детали проекта и обсуждает рациональность использования его решения, а не предложенных неравнодушных читателями альтернативных.

Далее:

Как мы подбирали грузы для перевозчиков

Илья Баштанов (разработчик в «Точка-Точка») и Татьяна Воронова (аналитик данных, «Центр 2М») предлагают реализации жадного алгоритма: на Java (не PL/Java, как я понял) и на PL/pgSQL (то есть опять внутри базы).

Задача отнюдь не демонстрационная: заказчик хотел эффективно загружать транспортные средства (и тем самым увеличить доход от перевозок) и доставлять грузы в приемлемые сроки (включая принцип FIFO).

Решения тестировались: в БД PostgreSQL была подготовлена тестовая таблица, содержащая 7000 грузов со случайными весами от 20 до 800 кг. Для тестирования использовался обычный pgbench, который в процессе теста выполнял 500 транзакций (10 соединений по 50 транзакций). Каждая транзакция делала один вызов алгоритма со случайными параметрами (ограничением на вес от 10 до 1000 кг и на количество грузов от 1 до 50 штук). Все случайные величины распределены равномерно. Интересно, что остановились на PL/pgSQL. Потому, что этот вариант масштабируется немного лучше, видимо, за счёт более скромных требований к оперативной памяти (для хранения промежуточных результатов используются временные таблицы БД). И он с незначительными переделками эксплуатируется заказчиком второй год.

Для разнообразия можно ещё глянуть, скажем, Задача о рюкзаке в контекстной рекламе для досок объявлений — пост на доработке, интересен постановкой задачи — реклама, маркетинг. Или, скажем, Алгоритм решения задачи о рюкзаке (версия 2, исправленная) — исправленная не до конца, но зато с обсуждением (в тексте и комментариях) преимущества и недостатков подходов с жадным алгоритмом (которым воспользовались в соседней статье) и динамического программирования (автор описывает свой подход как усложнение ЖА и упрощение ДП). Решение на псевдокоде. Для любителей зауми.

А вот, наоборот, простенький скрипт на SQL, но использует оракловые KEEP и RANK, которых нет (пока?) в PostgreSQL:
A Simple SQL Solution for the Knapsack Problem (SKP-1) — правда и рюкзак-то здесь 1-мерный (а вот здесь — M-мерный).

Но это лишь 1/1000 часть того, что можно найти о софтверных способах заталкивания в рюкзак различных материальных и нематериальных предметов.

Как устроен Postgres


Запросы в PostgreSQL: 1. Этапы выполнения

Стартовала новая серия Егора Рогова Запросы в PostgreSQL: началось она с этапов выполнения запросов.
За ней последовала статистика. Потом Последовательное сканирование и Индексное сканирование.
Запланированы:
5. соединение вложенным циклом;
6. соединение хешированием;
7. сортировку и соединение слиянием.

Вернёмся к Этапам. Егор подробно разбирает, что происходит по протоколу простых запросов. А затем и по расширенному протоколу — то есть с подготовленными запросами, привязкой значений параметров и уже затем планированием и выполнением.
Статистику Егор разбирает тоже подробно (все статьи довольно большого объёма):
  • Базовая статистика (неопределенные значения, уникальные значения, наиболее частые значения — MCV).
  • Гистограмма
  • Статистика для нескалярных типов данных
  • Средний размер поля
  • Корреляция
  • Статистика по выражению
  • Расширенная статистика по выражению
  • Статистика для индекса по выражению
  • Многовариантная статистика (функциональные зависимости между столбцами, многовариантное число различных значений, многовариантные списки частых значений).

В последовательном сканировании Егор с места в карьер устремляется в будущее PostgreSQL — в подключаемые движки хранения (pluggable storage). С оговоркой: пока доступен только вот этот:
SELECT amname, amhandler FROM pg_am WHERE amtype = 't';
amname |      amhandler 
−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−
 heap   | heap_tableam_handler

Среди некоторого количества разрабатываемых движков Егор выбирает для краткого упоминания два:
Zheap (реализует обновление версий строк на месте и выносит исторические данные, необходимые для построения снимка, в отдельное undo-хранилище -поддержка со стороны EDB).
Zedstore (реализует колоночное хранение — в основном усилиями GreenPlum).

Далее в статье читатель наблюдает этакий лингвистически парадоксальный поворот: разбирая последовательное сканирование уже во вполне привычном контексте, Егор обращается к параллельному последовательному сканированию — не параллельному vs последовательному, а именно так, парадокса на самом деле нет. В финале автор приближается к пределу параллелизма: не всё поддаётся распараллеливанию (например временные таблицы), а что-то и не хочет распараллеливаться, получая пометку PARALLEL RESTRICTED.

Ну а про индексное сканирование уж точно стоит почитать не в моём пересказе. Кроме видов индексного сканирования там есть про оценки стоимости, про INCLUDE-индексы, график сравнения методов доступа. Ну и, конечно, параллельные версии индексного сканирования.

Предыдущие серии Егора:
Изоляция
WAL
Блокировки
Индексы

Планировщики (в смысле шедулеры)


pg_dbms_job v1.0.1

Создал его неутомимый Жиль Дароль (Gilles Darold), который теперь работает в MigOps, и лежит оно на гитхабе компании (последнее время мы нередко ссылаемся на статьи от MigOps, в предыдущем выпускеДинеш Кумар о производительности Rocky Linux на тестах Phoronix). pg_dbms_job вошло в пакет Ora2Pg. Загружать можно отсюда.

Это новое расширение создано ради совместимости с оракловым шедулером DBMS_JOB. Совместимо со всеми Postgres, начиная с 9.1. Но это не только расширение: ещё запускается демон, имеющий доступ к базе, которую он обслуживает. Он может работать там же, а может и на другом хосте. Такая архитектура выбиралась сознательно. Авторы говорят:
мы выбрали архитектуру с внешним демоном потому, что запускать тысячи подпроцессов от фонового процесса это плохая идея (по умолчанию лимит одновременно работающих заданий 1000).

Сам Жиль Дароль рассказывает, что и зачем они сделали: Одному из наших заказчиков нужна была совместимость с оракловым пакетом DBMS_ERRLOG. Мы создали расширение: pg_dbms_errlog. А для другого заказчика — другое расширение: credcheck, усовершенствующее работу с логинами, правилами, политиками. Но мы рады, что не только заказчики, а пользователи PostgreSQL по всему свету смогут пользоваться свободами PostgreSQL.

Расширение pg_dbms_job можно использовать на DBaaS-платформах Amazon RDS, Aurora, Google Cloud SQL for PostgreSQL и Microsoft Azure Database for PostgreSQL.

Напомним, что в Postgres Pro Enterprise есть мощный pgpro_scheduler, но Enterprise — платная версия. Этот шедулер делался с самого начала без демона, а с фоновыми процессами (backgound workers). Это тоже был осознанный выбор. В документации этот выбор объяснён. По сравнению с внешними планировщиками pgpro_scheduler имеет следующие преимущества:
  • Любой пользователь может планировать задания независимо.
  • Планированием заданий можно управлять «на лету», не перезапуская базу данных.
  • pgpro_scheduler отличается очень лёгкой реализацией, так как для планирования и контроля заданий, а также для управления ими он использует фоновые рабочие процессы. И при этом pgpro_scheduler не задействует никакие клиентские подключения.
  • Для большей стабильности в каждой базе данных имеется собственный руководящий планировщик, а каждое запланированное задание выполняется в отдельном рабочем процессе.

А недавно Павло Голуб (pashagolub, Cybertec) опубликовал своё сравнение 4 шедулеров:
pg_timetable (Cybertec)
pg_cron (Citus Data)
pgagent (pgAdmin Development Team)
jpgAgent (GoSimple)

Павло сам и разрабатывает pg_timetable. К тому же Павло предлагает вспомнить предыдущие свои публикации на эту тему. Их много.

Статья, видимо, приурочена к выходу версий pg_timetable 4.x.

Только что вышла версия pg_timetable 4.1.0, но радикальные изменения произошли уже в pg_timetable 4.0.0 — настолько радикальные, что она обратно несовместима с версиями 3.x. По ссылке список очень большой, поэтому обещано детальное разъяснение, но на момент нашего обзора там картинка и подпись «этой страницы пока нет». Но можно глянуть документацию.

Ещё статьи


PostgreSQL Custom Dashboards Ported to Percona Monitoring and Management 2

Сергей Кузьмичёв из Percona демонстрирует, как портировать некоторые возможности PMM 1 (Percona Monitoring and Management) в PMM 2. Причем портировать рекомендуется в версию PMM 2.16.0 и выше, так как перконовский postgres_exporter там обновлён до версии 0.8.0 сообщества (о ней можно почитать и на хабре: Новые возможности postgres_exporter для мониторинга PostgreSQL. И, кстати, ещё об экспортерах: pgexporter 0.1.0).

В статье портируются дэшборды PostgreSQL Tuple Statistics и PostgreSQL DB/Table Size Details (разработчик Вадим Яловец). Tuple Statistics кроме прочего показывает соотношение мертвых/живых записей и детали истории вакуумирования. Портируемая версия добавляет информацию о возрасте базы и о том, далеко ли до wraparound, не пора ли запускать вакууум. Диаграммы показывают самые востребованные объекты, опускаясь на уровень отдельных таблиц.

PostgreSQL DB/Table Size Details даёт просто размер таблицы и всей базы, а также скорость роста — очень полезно, когда не ясно, куда девается свободное место на диске.

postgres_fdw Enhancement in PostgreSQL 14

Ибрар Ахмед (Ibrar Ahmed, тоже Percona) демонстрирует достижения в PostgreSQL 14 по части FDW на примерах. И пишет о PostgreSQL FDW. Какой же это Foreign? Это же «свои». Но PosgreSQL FDW используют более, чем часто, на нём можно даже обустроить шардинг.

Иллюстрируя Parallel /Async Foreign Scans, Ибрар создаёт секции от родительской таблицы на 2 внешних серверах, потом вставляет данные в родительскую, и, действительно, мы видим, что в плане появились 2 ветки Async Foreign Scan. В предыдущих версиях они сканировались бы последовательно, а не параллельно. Но для этого опция async_capable, разрешающая параллельное планирование и исполнение ForeignScan, должна быть true.

Далее следует: Bulk Insert теперь работает и в PostgreSQL FDW. Автор (в другой статье) показывает, как это сказывается на времени вставки.

Кроме того Ибрар понемногу говорит и о других новых функциональных фичах:
  • TRUNCATE разрешено работать на внешних таблицах;
  • postgres_fdw теперь может импортировать секции, если они прописаны в IMPORT FOREIGN SCHEMA … LIMIT TO;
  • функция postgres_fdw_get_connections перечисляет открытые соединения по FDW и помечает их валидность;
  • новая опция keep_connections по умолчанию true, она держит соединения, чтобы последующие запросы могли ими воспользоваться, но когда она выключена, соединения вычищаются после завершения транзакций;
  • postgres_fdw теперь может, когда надо, восстанавливать соединения, если внешний сервер перезапустился.


PostgreSQL PL/Java – A How-To, Part 1 и 2

Цель у Чарли Батисты (Charly Batista, бразилец, живущий в Китае, а работающий — опять же — в Percona) скромная: он искал в интернете некоторые сведения по PL/Java и пришёл к выводу, что информации-то много, но она либо неполная, либо устаревшая, либо от неё одна путаница; поэтому и решил обобщить свои изыскания в HOWTO и показать, как установить и запустить PL/Java.

Для демонстрации Чарли использует:
  • PostgreSQL 12.7,
  • PL/Java 1.6.2,
  • OpenJDK 11,
  • Apache Maven 3.6.3

Установив всё, что нужно, Чарли заканчивает часть I кодом, который в качестве результата возвращает нам респа Робина Хейса, зачем-то помещённого Чарльзом в город Елец Липецкой Области. А вот обещанный total автор зажал: функция есть, а вызова её нет. Бог ему судия. Во всяком случае, проштудировав многочисленные примеры, читатель научится:
  • получать доступ к объектам;
  • крутить цикл по результатам;
  • упаковывать результаты в массивы и DataSet;
  • делать что-то с результатами до того, как они будут возвращены (в примере показано, как анонимизировать данные);
  • создавать триггер с PL/Java-функциями.

Это по сумме 1-й и 2-й частей. В 3-й, ещё не вышедшей части PL/Java будет обращаться к внешним источникам данных.

Продолжение серии о Empire ERP

В прошлом выпуске было о статьях начала серии Empire ERP. Занимательная бухгалтерия, в том числе Занимательная бухгалтерия: PostgreSQL. Сейчас в серии 4 статьи, и смотреть их удобней не на Хабре, а на Гитхабе: там и «содержание» — ссылки на все статьи (сейчас их 4). Там же и недавняя — Аналитический учет, ч.1. Виноват, уже 5: появилась 2-я часть.

Автор обещает и будущие софтверные приключения с питонным уклоном: сейчас рассматривается стэк технологий: PostgreSQL, SQLAlchemy, FastAPI, Svelte/Material. А разворачиваться на десктопы это будет с помощью Ansible.

Что такое Open Source, и с чем его едят в наше время

В этой статье зам. гендира Postgres Professional Ивана Панченко на tadviser нет ни одного вхождения слова PostgreSQL. Но прочитать её стоит. Так уж вышло, что в этом выпуске Иван выступает в трёх амплуа: специалиста по внутренностям Postgres, астронома (см. ниже) и — вот в этой статье — говорит об open source. Но не сладкие слова о свободном мире свободных разработчиков с их свободном кодом, а о разнице open source vs. free software; о хеллоуиновских документах; SSPL, по которой распространяются Mongo DB и Elasticsearch; что к 2021-му open source и коммерческое ПО — более не два разных враждующих лагеря, а два способа разработки, дополняющие друг друга и занимающие свои ниши. И даже предлагает новое понятие: open design — когда не только сами коды открыты, но и документы, объясняющие внутреннее устройство системы, обязательно присутствуют и тоже открыты. А в конце ещё и полемизирует с тезисами Минцифры.

Скандал в благородном семействе


Действительно благородном, без кавычек: участники его — с одной стороны Альваро Эрнандес (Álvaro Hernandez Tortosa, OnGres), с другой — всё сообщество PostgreSQL, представленное Core Team, то есть командой, которая де факто решает все важнейшие стратегические вопросы проекта.


Альваро Эрнандес (фото из материалов конференции PGConf.Russia)

Альваро знают как важного разработчика — он больше 20 лет занимается Postgres, разработчик JDBC-драйвера и многого другого, он часто выступает на постгресовых конференциях, в том числе на PG.Day и PGConf.Russia — с ним приятно и полезно побеседовать в кулуарах и/или на фуршете. Кроме того он основатель и президент Fundación PostgreSQL — НКО-ассоциации испаноязычных постгресистов, для которой он и старался.

У истории с попытками регистрации в ЕС и в США торговой марки PostgreSQL и Postgres, докатившейся аж до Российских СМИ, есть предыстория: Альваро — настоящий революционер. Почти год назад — когда EDB поглотила 2ndQuadrant — он призывал радикальным изменениям в руководящих структурах проекта, тогда же предложил разобраться с правовой основой торговых марок, а ещё озаботился гендерным и расовым балансом (мол, в руководстве слишком высок % белых ЦИС-гендерных мужчин, нужны квоты). Большинство было против хотя бы по последним пунктам по принципу «не буди лихо, пока оно тихо» (почитайте комментарии под воззванием Альваро). Но и по остальным пунктам мало кто был за изменения в механизме, где всё и так до сих пор неплохо работало. Воззвание начиналось со слов «Не пора ли..» — тогда было точно не пора. Мы этой ситуации посвятили полдюжины абзацев Постгрессо 26 (главка «Пополнение в Core Team»).

Альваро воспользовался тем, против чего он, пожалуй, боролся: зазором между формальной, юридической стороной управления копирайтами и торговыми марками (ими рулит юрлицо Postgres Association of Canada) и целой системой из неформальных, нигде не прописанных, подразумеваемых договорённостей, на которых во многом держится и движется вперёд всё сообщество во главе с PostgreSQL Core Team. В прошлом году Альваро вопрошал: а если PGAOC надоест подчиняться сообществу? В 2021 ему самому надоело подчиняться, и он просто начал регистрировать торговые марки сам. Начал с Испании, и это сошло с рук. Но (по его словам, которым лично я верю) всё не корысти ради, а дабы не уплыли они из-под сообщества, остались в надёжных руках идейного борца с централизованным и непрозрачным управлением интеллектуальной собственностью.

Стороны обменялись нетипично резкими заявлениями: Trademark Actions Against the PostgreSQL Community vs. Postgres Core Team launches unprecedented attack against the Postgres Community. После чего Альваро многословно оправдывался и объявил, что начал процесс передачи PGAOC всех торговых марок и доменных имён, связанных с PostgreSQL.

Релизы


Релизная группа (Эндрю Данстан (Andrew Duntan), Мишель Пакье (Michael Paquier) и Питер Гайген (Peter Geoghegan) — Release Management Team) разослала график выхода главных релизов:

PostgreSQL 14 релиз-кандидат (RC1) должен выйти 23 сентября.
UPDATE: Релиз-кандидат вышел. В нём выделили 4 пункта как самые важные:
— autovacuum, анализирующий секционированные таблицы отозван и не попадёт в PostgreSQL 14.
— EXPLAIN VERBOSE заработал в запросах с SEARCH BREADTH FIRST.
— CREATE STATISTICS теперь отказывается работать в выражениях с одной переменной.
— SELECT DISTINCT ROW больше не выдаёт ошибку.


Общедоступный (generally available) PostgreSQL 14 должен выйти 30-го сентября, если не будут обнаружены критичные баги. Говорят, особых проблем не предвидится.

pgBadger v11.6

В этой версии pgBadger, вышедшей после перерыва в полгода, есть некоторые (не слишком радикальные) усовершенствования. Например:
  • Автоматическое определение Query Id в log_line_prefix для PG14.
  • Более продвинутые регрессионные тесты с возможностью исключения заданной базы данных; с включённой опцией --explode. Компания MigOps помогла патчем (ещё бы: Жиль Дароль, автор pgBadger, там теперь работает).
  • Ещё один их патч: теперь можно использовать параллельные процессы при генерации отчёта, когда включена опция --explode.
  • Добавлена опция --iso-week-number в инкрементальном режиме. Теперь в календаре неделя сможет начинаться с понедельника! Номера недель теперь соответствуют ISO 8601 — от 1 до 53.
  • --iso-week-number скорее всего станет дефолтным в следующем мажорном релизе, а тогда --start-monday удалят за ненадобностью, и неделя [ура!] всегда будет начинаться с понедельника, с воскресеньями в начале недели будет покончено.
  • Теперь pgBadger стал совместим с лог-файлами Postgres Pro (в том числе номера записей и размеры в байтах после цифры продолжительности запроса).


Psycopg 3.0 beta 1

Прекрасная новость! В том числе потому, что приятно видеть «русский след» в софте, который вызывает немалый интерес у разработчиков. Ныне лондонский итальянец Даниэль Варраццо (Daniele Varrazzo), лидер проекта Psycopg 3 (он ещё и прекрасный фотограф — have fun) — выражает особенную благодарность Postgres Professional, Command Prompt (США) и многим другим компаниям и разработчикам-энтузиастам.

Полное имя — psycopg-pool 3.0b1. Psycopg 2 полностью переписали, оставив ту же архитектуру с обёртками для libpq (wrapper architecture) и интерфейсом DB-API, но добавили новые фичи, которые будут лучше работать с новыми версиями Python и PostgreSQL.

Со стороны Python новое, например, в том, что можно использовать параллельные и статические типы на базе асинхронного ввода-вывода — asyncio (а о connection pool в Psycopg 3 будет чуть ниже).

Со стороны PostgreSQL Psycopg 3 теперь может использовать серверные параметры, подготовленные запросы, двоичные параметры и отличную поддержку операций COPY. Ещё интересные подробности есть здесь и в блоге Даниэля: здесь и здесь.

Чтобы установить, зайдите сюда.

И вот статья о psycopg3 в блоге rustprooflabs: Psycopg3 Initial Review. Райан Лэмберт (Ryan Lambert, владелец и гендир RustProof Labs) особенно заинтересовался обещанным прогрессом в работе пула соединений (в Psycopg 3 за него отвечает опциональный пакет psycopg_pool) и решил его потестировать. Клиентское приложение на своём ноутбуке, а сам Postgres на ARM — Raspberry Pi 4 с данными на USB3 SSD-диске. Связь по бытовому WiFi. Нагрузка симулируется на Саранче — Locust. Он симулировал до 70 одновременных пользователей. На графиках видно, что при таком количестве пользователей с пулом производительность масштабируется, а без него — нет. Время ожидания сокращается в 3 раза. В статье выводов особых и нет: мы ждали улучшений, и дождались — даже в бете.

postgresql-wheel

Это сервер PostgreSQL, который весь умещается в пакете Python package уже в скомпилированном виде и устанавливается как один pip-файл:
$ pip install postgresql-wheel

Все серверы запускаются как локальные Python-процессы, ни root, ни sudo не нужно, и запускать можно в любом каталоге. И внешних зависимостей нет. Очень удобно для тестирования. Но есть пока только версии для основных Linux. Автор — Мишель Пеллетье (Michel Pelletier).

WAL-G 1.1

Новое, касающееся PostgreSQL:

wal-verify теперь можно запускать на реплике;
wal-verify теперь игнорирует постоянные бэкапы (permanent backups).

А также:

В релизы на GitHub включена библиотека шифрования libsodium. WAL-G должна быть скомпилирована с ней.
UserData теперь должна быть валидным JSON.
backup-list теперь сортирует бэкапы по астрономической дате завершения.

pgmoneta 0.5.0

Дэвид Феттер (David Fetter), почти коллега: составляет списки новостей. Он, вместе с Яспером Педерсеном (Jesper Pedersen) и
Уилом Линвебером (Will Leinweber) участник проекта pgmoneta. Это решение для резервного копирования / восстановления. По молодости своей оно не входит в список на PostgreSQL.org, но кое-что умеет.

В этой версии появились:
поддержка failover;
политики, где копий хранятся дольше, чем окно сохранения (retention window);
поддержка всех настроек recovery_target. Инструкции по установке и настройке есть на гитхабе.

PGSpider

Это расширение для конструирования высокопроизводительных кластеров распределённых больших данных. Может обращаться к разным источникам, работает через FDW. Возможно, заслуживает более подробного обсуждения в будущих выпусках Postgresso. Разрабатывают его в Toshiba Software Engineering & Technology Center.



Ещё о релизах — в 2 словах


PostGIS 3.1.4, 3.0.4

Исправлены баги. Эта версия работает с PostgreSQL 9.6-14. Загрузить можно отсюда.

AGE 0.5.0 и 0.6.0

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

pgagroal 1.3.0

Новое в этом пулере: дэшборд Grafana 8; новые метрики Prometheus в разделах клиент, пулинг и внутренние.

pg_dumpbinary-v25

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

set_user 2.0.1

Расширение, которое даёт возможность эскалировать привилегии с усовершенствованным логированием и управлением. Эта минорная версия закрывает дыру в безопасности.

pglogical 2.4.0

Исправлены баги. Загружать отсюда.

pg_msvc_generator 1.0.0 beta

Инструмент для создания версий для Windows у расширений. Представляет собой 2 перловых скрипта.

Crunchy PostgreSQL Operator 5.0.2

Поддержка новых версий PostgreSQL, TimescaleDB 2.4.0 (вышли и 2.4.1, и 2.4.2, но там исправлены баги), set_user 2.0.1. Главные изменения произошли до этого — в Crunchy PostgreSQL Operator 5.0.0.

pgAdmin 4 v5.6

Из изменений:
можно копировать SQL из главного окна в окошко запросов;
стало удобней просматривать, форматировать и редактировать JSON.

pgbouncer 1.16.0

Появилась, например, горячая перезагрузка конфигурации TLS. Загрузить можно отсюда.

dbForge Data Compare for PostgreSQL v3.4

В новой версии можно работать с IBM Cloud и с Amazon Aurora. Можно попробовать: доступна пробная 30-дневная версия.

pgdiff

Утилита, которая показывает, что изменилось в Postgres-базе между 2 заданными моментами времени.

PL/Julia

Расширение для языка Julia внутри PostgreSQL. Презентация Джулии.

Конференции, митапы, Вторники


SaintHighload++ 2021
Только что — 20-21 сентября — закончилась (Saint в данном случае не святой, а питерский Highload++). Были в том числе постгресовые доклады:
Анатолий Афиногенов (ВНИИЖТ) Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL: планирование, подготовка, переход и два года жизни с новой БД;
Олег Бартунов и Никита Глухов (оба Postgres Professional) Json or not Json. Плюсы и минусы использования Json в PostgreSQL;
Николай Ихалайнен (Percona) Симуляция боевой инсталляции MySQL/ MariaDB/ Postgresql/ MongoDB;
Алексей Лесовский (Data Egret) Что нового в плане мониторинга в PostgreSQL.
И на другие любопытные темы, например:
Егор Гришечко (Uber, изменившая Постгресу с MySQL) Stateful Deployment Platform или как Uber управляет сотнями тысяч баз данных Архитектуры, масштабируемость
Михаил Голубев (AWS) и Дмитрий Иванов (IPONWEB) Как (и зачем) переехать на архитектуру ARM в облаке?

PGConf.NN

Нижегородская конференция-митап PGConf.NN состоится в оффлайне уже 30 сентября в нижегородском Технопарке «Анкудиновка». Организаторы – Postgres Professional и ассоциация IT-компаний iCluster.
В программе доклады о
хранении документов формата JSON в PostgreSQL,
обеспечении надёжного резервирования и хранения данных в Postgres и о
преимуществах SQL и NoSQL СУБД.

Параллельно с ней 30 сентября будет опробована выездная сертификация PostgreSQL DBA — выездное тестирование администраторов СУБД PostgreSQL с выдачей сертификата Программы профессиональной сертификации. Место проведения тестирования — коворкинг Vmeste (Ул Белинского 63, ТЦ «Этажи»,5 этаж, конференц-зал). Записаться на тестирование можно здесь, выбрав при записи площадку «Нижний Новгород». Начало в 10.00.

PGConf.Russia 2021

Состоится 25 – 26 октября в Москве, на этот раз в Первом МГМУ имени И. М. Сеченова. Регистрация и заявки на доклады принимаются, вот рекомендованные темы:
  • PostgreSQL на переднем крае: большие данные, интернет вещей, блокчейн.
  • новое в PostgreSQL и вокруг: развитие PostgreSQL и его экосистемы.
  • PostgreSQL в реальных системах: архитектура, миграция, эксплуатация.
  • Использование PostgreSQL в платформе 1С.
  • PostgreSQL в геоинформационных системах (GIS).


SECON 2021

Конференция состоялась 19-20 июня на территории базы отдыха «Арт-Пенза» и скульптурного парка «Легенда». Постгресовую тематику представлял Иван Панченко с докладом Использование JSON в PostgreSQL — о различных паттернах использования JSON и о средствах для работы с ним, предоставляемых PostgreSQL.

Это была немного облегчённая версия. Более углублённо, для более специализированной аудитории Иван делал примерно на эту тему мастер-класс на PGConf.Russia 2020. Он доступен в слайдах и в видео.

Но постгресовой тематикой Иван отнюдь не ограничился. Ещё один доклад назывался Астроликбез для айтишников — какие связи есть между айти и астрономией, авторская версия FAQ по астрономии:

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

Лекция пользовалась успехом, и Иван рассказал об ИТ-астрономии и на SaintHighload++. А ещё дарил самым активным участникам обсуждения книжку: Киричек, Панченко: Неизвестное Солнце. Расследование. Чудеса. Факты. Загадки

Вообще тематика конференции пёстрая. И бизнес, и технологии, и про гиперказуальные игры, и про ИИ, конечно. Был и такой, например, доклад: начальник отдела разработки в МЦСТ Сергей Юрлин посвятил в уровень и перспективы платформы Эльбрус. Показал типоряд микропроцессоров и вычислительных панелей платформы Эльбрус, кратко описал маршрут проектирования и варианты сотрудничества.

Теперь о Постгрес-ВТОРНИКАХ. В этом сезоне их было 3:

Постгрес-вторник 2021-09-14: «DIY OKметер»: netdata, pgwatch2 — открытые и перспективные системы мониторинга

Постгрес-вторник 2021-09-07: долгие запросы, длинные транзакции

Постгрес-вторник 2021-08-24: «Субтранзакции прокляты»

Ссылка на файл, где темы и планы на будущее.

Книги


Оптимизация запросов PostgreSQL

Книга Генриэтты Домбровской, Бориса Новикова и Анны Бейликовой. Книга выходит в ДМК Пресс. Это перевод, оригинал PostgreSQL Query Optimization. The Ultimate Guide to Building Efficient Queries был издан Apress в этом году. Авторы так предваряют книгу:

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

PostGIS in Action, Third Edition.

Книжка вышла в Manning Publications. У них есть и страничка в фейсбуке.

На сегодня, кажется, всё. До встречи примерно через месяц!
Tags:
Hubs:
+8
Comments 1
Comments Comments 1

Articles

Information

Website
www.postgrespro.ru
Registered
Founded
Employees
201–500 employees
Location
Россия
Representative
Иван Панченко