Обе конференции - PGConf.СПб 2024 и PGConf.Academy 2024 - прошли в октябре. Они очень разные, но мы решили их объединить - может, как раз поэтому. Разница между ними не географическая. Даже наоборот, вышел парадокс: питерского уклона в составе докладчиков на PGConf.СПб 2024 в глаза не бросались, зато представители СПб (особенно представительницы) были более, чем заметны на московской образовательной конференции.

PGConf.СПб 2024

Прошла 1 октября. Однодневная, но в два потока уместила 18 докладов. Приятно, что открывал её доклад Павла Лузанова, а закрывал - доклад Егора Рогова - оба мои коллеги по Отделу Образования Postgres Professional.

Эта статья открывает цикл о новостях будущей, 18-ой, версии PostgreSQL. Рассмотрим следующие возможности попавшие в июльский коммитфест.

Планировщик: поддержка правого полусоединения хешированием
Планировщик: материализация внутреннего набора строк для соединения вложенными циклами в параллельном плане
Вспомогательные функции планировщика для generate_series
EXPLAIN (analyze): статистика рабочих процессов узла Parallel Bitmap Heap Scan
Функции min и max для составных типов
Имена параметров для функций regexp*
Режим отладки в pgbench
pg_get_backend_memory_contexts: столбец path вместо parent и новый столбец type
Функция pg_get_acl
pg_upgrade: оптимизация работы pg_dump
Предопределенная роль pg_signal_autovacuum_worker

PostgreSQL: PostgreSQL 17 Released!

Новшества давно известны (в том числе из обзоров Павла Лузанова PostgreSQL 17: Часть 5, 4, 3, 2, 1), но интересно, что выбрали в сообществе как самое-самое важное. Выбрали вот что:

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

переработанное управление памятью (overhauled memory management) при вакууме,

оптимизация доступа к хранению и улучшение работы при параллельных нагрузках (high concurrency workloads),

ускорение при массовой загрузке и экспорте,

улучшения работы с индексами.

Работа с новыми типами нагрузок:

реализация SQL/JSON JSON_TABLE .

Для высококритичных систем:

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

А вот что привлекло внимание сразу нескольких комментаторов: изменения в оформлении самих пресс-релизов:

More Release Note Details

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

Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.

А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.

Чтобы объяснить, что есть Postgres Pre-Commitfest party и зачем мы в это ввязались, для начала нужно объяснить, как идёт разработка ванильного постгреса. Процесс принятия новых фичей и патчей в код разделён на так называемые коммифтесты (сокращённо CF), расписание которых всегда можно посмотреть на сайте https://commitfest.postgresql.org/. Когда разработчик предлагает свой код (неважно, будь это новая фича или багофикс), для того чтобы он был рассмотрен в рамках CF, он предварительно должен пройти процедуру ревью и быть одобрен для рассмотрения. Конечно, это совершенно не гарантирует, что код будет принят на этом CFили даже следующем, но сейчас не про это.

Найти ревьюера для своего кода зачастую задача более сложная, чем написать сам код. Человека надо погрузить в решаемую проблему, объяснить, что именно ты предлагаешь изменить, почему так, а не иначе и так далее. Прямо сейчас, в статусе Needs review, находится 29 патчей. Со свойственным нам желанием помогать, мы решили кинуть клич среди коммитеров и собрать всех желающих под одной крышей, чтобы они могли представить свои патчи, обсудить их и, возможно, найти желающего провести ревью.

Так получилось, что собрались мы в рамках проходившего Highload++ в Санкт-Петербурге. Поскольку Open Source — дело добровольное, мы просто разослали всем контактам, которые у нас были, предложение примерно следующего содержания: зовём всех неравнодушных постгресистов собраться в шатре, рассказать про свои патчи, обсудить их и хорошо провести время.

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

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

Конференции

PGConf.СПб 2024

Появилось расписание [проверить!!]

Первый доклад — Павла Лузанова, возглавляющего отдел образования в Postgres Professional — (новое в) PostgreSQL 17 (а пока можно почитать его PostgreSQL 17: Часть 5 или Коммитфест 2024–03).

Андрей Бородин (Yandex Cloud) представит Необычные возможности системы резервного копирования WAL‑G, а Дарья Лепихова и Алексей Дарвин (оба Postgres Professional) — Выбор репликационного протокола при разработке pg_probackup3 (напомним, что 3-я версия не очередная, это практически переписанный с нуля pg_probackup, в отличие от 2.х).

Cиквел и приквел: занимательная археология Егора Рогова — это исторический экскурс, новый (кажется) для Егора жанр, но не сомневаюсь, что это будет информативно и увлекательно: расскажу, как работали с базами данных до Кодда и что изменилось с изобретением реляционной теории; поговорим о зарождении первых реляционных систем — System R и Ingres; о том, как появился и завоевал популярность язык SQL; о людях, которые определили наше настоящее и в какой‑то степени будущее.

От редакции: Майкл Стоунбрейкер - один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло, недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.

В 1970-х годах известный программист Эдгар Кодд разработал математически выверенную теорию организации данных в виде таблиц (реляций). С тех пор утекло немало воды — появилось большое количество различных коммерческих и open-source реляционных систем управления базами данных (РСУБД). Скоро стало понятно, что эффективное получение данных из базы — задача далеко не тривиальная. Если говорить прямо, она нелинейная и в общем случае NP-сложная.

Когда SQL-запрос становится немного сложнее: SELECT * FROM table, у нас появляется огромная вариативность его исполнения внутри системы — и не всегда понятно, какой из возможных вариантов эффективнее как по памяти, так и по скорости. Чтобы сократить огромное количество вариантов до приемлемого, обычно используются так называемые эвристики — эмпирические правила, которые придуманы человеком для сокращения пространства поиска на несколько порядков. Понятное дело, эти правила могут отсечь и сам оптимальный план выполнения запроса, но позволяют получить хоть что-то приемлемое за адекватное время.

В последние годы в связи с активным развитием ML начали развиваться и нейронные оптимизаторы запросов —особенность которых в том, что они самостоятельно, без участия человека, находят необходимые закономерности в выполнении сложных планов исходя из обучения на огромном количестве данных. Тенденция началась приблизительно в 2017 году и продолжается до сих пор. Давайте посмотрим, что уже появилось в этой области в хронологическом порядке и какие перспективы нас ждут.

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

В этой статье рассказывается о патчах, принятых в ходе последнего мартовского коммитфеста. Предыдущие статьи о коммитфестах 17-й версии: 2023-07, 2023-09, 2023-11, 2024-01.

Все вместе они дают подробное представление о новой версии СУБД.

Из жизни малышей и гигантов

PGlite 0.2

Опенсорсный проект ElectricSQL явил маленькое чудо. Совсем маленькое: сервер PostgreSQL уместился в архив 3МБ.

Сервер сделан как клиентская библиотека TypeScript/JavaScript, PostgreSQL можно запускать в браузере, Node.js и Bun, ничего больше инсталлировать не надо, всё есть. Есть и некий API "live query", для реакции на изменения данных в таблицах. Утверждают, что обычные CRUD-запросы исполняются за 0.3 мс.

Ресурсы:

сайт;

репо;

доки

каталог расширений (22 расширения Postgres, в том числе pgvector, и 1 плагин для PGlite - live);

первые бенчмарки.

Более того: компания Supabase уже запустила сайт postgres.new, построенный поверх PGlite, мол, have fun.

В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

Случилось так, что этот выпуск никак не хотел укладываться в наши обычные разделы, скажем: Релизы/Конференции/Статьи ...

Что делать?

Волны расходятся с тех пор, как Роберт Хаас (Robert Haas, EDB) издал в интернете крик души. Волны отразились от берегов: от одного берега пошла волна pre-commitfest, от другого вот что:

Robert Haas: Mentoring Program for Code Contributors

Роберт Хаас теперь сам участвует в менторской программе поддержки (потенциальных и действующих) контрибьюторов. Он кинул клич, можно подавать заявки. Формула проекта такая: 9 менторов-коммитеров-добровольцев курируют 9 контрибьюторов. В будущем - возможно - будет вовлечено больше коммитеров, и - возможно - каждый возьмёт больше, чем одного курируемого (mentee).

Другую волну оседлал (и правильно сделал) Андрей Бородин (Yandex Cloud), которого поддержало руководство Postgres Professional. Об этом мы писали в прошлом выпуске, но в будущем времени: На Saint HighLoad++ 2024 запланирован воркшоп Postgres Pre-Commitfest Party. Это была инициатива Андрея Бородина (Yandex Cloud) как путь разрешения проблем с коммитфестами, которые мы относительно подробно описали в предыдущем выпуске [то есть уже в пред-предыдущем - примечание редакции]. Андрей предложил обсуждать грядущие патчи сначала вне инфраструктуры коммитфестов.

Теперь можно сказать, что затея удалась. По подсчётам службы маркетинга на первом в России (да и в мире, зачем скромничать) публичном ревью патчей в PostgreSQL 18, было 100+ слушателей. Здесь фотографии.

Следим за целостностью данных в PostgreSQL. Мысль о возможной катастрофе неприятна, поэтому люди часто не принимают серьезных предупредительных мер.

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

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

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

На протяжении своего существования наша компания пытается отвечать на эти вызовы, для чего, например, были разработаны расширения AQO и sr_plan. Сообщество PostgreSQL также не стоит на месте: в ванильной версии появилась расширенная статистика и был введён ряд оптимизаций вроде инкрементальной сортировки и материализации промежуточных результатов выполнения запроса.

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

PostgreSQL: PostgreSQL 17 Beta 1 Released!

Вышла бета с 188 новшествами. Напомним, что Брюс Момджан недавно подчёркивал важность этого релиза из-за его некоторого уклона в оптимизацию, мол, большое число улучшений в оптимизации, это приятный сюрприз для меня.

В пояснительной записке к релизу тоже начинают с оптимизации. Первым делом рассказывают об изменениях в Vacuum. Там новая внутренняя структура, благодаря которой удалось сэкономить 20% памяти, а также сократить время самой очистки. Последний пункт касается редкой темы: в PostgreSQL 17 улучшена поддержка SIMD-инструкций.

Интересный, важный пункт - управление переключением при логической репликации (failover control for logical replication), важное для отказоустойчивых конфигураций.

В SQL/JSON появилась важнейшая вещь - JSON TABLE, это новый уровень работы с этим форматом. Также появились новые конструкторы и другие функции.

Или, точнее, задача, поскольку в этом году мы попробовали другой формат: задача была всего одна, но большая. Требовалось написать SQL-запрос, играющий в крестики-нолики «пять в ряд».

Джонатан Кац (Jonathan Katz) пишет:

PostgreSQL 17 Beta 1 запланирована на 23 мая. Пожалуйста, продолжайте тяжёлую работу по закрытию недоделанных пунктов (open items), все поправки намечено доделать к 18 мая. Всем спасибо! Это очень здорово, что мы подошли к этому этапу!

Release notes уже есть, Брюс Момджан о них:

В этом релизе пунктов, связанных с новшествами (feature count), будет 188. Приятный сюрприз для меня: большое число улучшений в оптимизации. Postgres 17 Beta 1 выйдет на днях, а окончательный релиз Postgres 17 запланирован на сентябрь/октябрь этого года.

PostgreSQL 16.3

А также 15.7, 14.12, 13.15 и 12.19. Ветку 12 больше поддерживать не будут.

Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом. 

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