LINUX.ORG.RU

PostgreSQL 18

 , ,


0

2

25 сентября, после более года разработки, состоялся выпуск стабильной версии 18 свободной объектно-реляционной системы управления базами данных PostgreSQL.

PostgreSQL 18 повышает производительность для рабочих нагрузок любого масштаба благодаря новой подсистеме ввода-вывода, которая показала до 3× ускорение чтения из хранилища, а также увеличивает число запросов, которые могут использовать индексы. Этот релиз делает обновления мажорной версии менее разрушительными, ускоряет сам процесс обновления и сокращает время, необходимое, чтобы после обновления выйти на ожидаемую производительность. Разработчики также выигрывают от функций PostgreSQL 18 — например, виртуальных вычисляемых столбцов, которые рассчитывают значения во время выполнения запроса, и дружественной к СУБД функции uuidv7(), обеспечивающей более быстрые индексацию и чтение UUID. Кроме того, PostgreSQL 18 упрощает интеграцию с системами единого входа (SSO) благодаря поддержке аутентификации OAuth 2.0.

«Усилия глобального сообщества разработчиков ПО с открытым исходным кодом формируют каждый релиз PostgreSQL и помогают предоставлять функции, отвечающие потребностям пользователей там, где находятся их данные, — сказал Джонатан Кац (Jonathan Katz), член основной команды PostgreSQL. — PostgreSQL 18 опирается на долгую и богатую историю проекта по предоставлению надежного и эффективного управления данными, при этом продолжая расширять спектр поддерживаемых рабочих нагрузок.»

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

Основные изменения:

  • Появление асинхронного ввода-вывода (AIO)
    • Ранее для ускорения доступа к данным PostgreSQL полагался на механизм опережающего чтения (readahead) операционной системы. Однако, поскольку операционные системы не понимают специфичных для баз данных паттернах доступа, они не всегда могут предсказать, какие данные потребуются, что приводит к неоптимальной производительности во многих рабочих нагрузках.
    • PostgreSQL 18 внедряет новую подсистему асинхронного ввода-вывода (AIO), разработанную для устранения этого ограничения. AIO позволяет PostgreSQL отправлять несколько запросов ввода-вывода (I/O) параллельно, не дожидаясь последовательного завершения каждого. Это дополняет существующий readahead и улучшает общую пропускную способность. В PostgreSQL 18 поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и вакуума. Сравнительное тестирование продемонстрировало прирост производительности до 3 раз в некоторых сценариях.
    • Новый параметр io_method позволяет выбирать между реализациями AIO, включая worker и io_uring, либо сохранить текущее поведение PostgreSQL с настройкой sync. При включении AIO появляется больше параметров, доступных для тонкой настройки — подробнее в документации.
  • Более быстрые обновления и улучшенная производительность после обновления
    • Ключевая особенность PostgreSQL — сбор и хранение статистики, которая помогает планировщику выбирать наиболее эффективный план запроса. До PostgreSQL 18 эта статистика не переносилась между экземплярами при обновлении мажорной версии, что могло вызывать заметную деградацию производительности запросов на нагруженных системах до завершения выполнения операции ANALYZE. В PostgreSQL 18 появилась возможность сохранять статистику планировщика при обновлении мажорной версии, что позволяет обновлённому кластеру быстрее выйти на ожидаемую производительность.
    • Кроме того, утилита pg_upgrade, предназначенная для обновления между мажорными версиями, получила ряд улучшений в PostgreSQL 18, включая более быстрые обновления, когда в базе много объектов, таких как таблицы и последовательности. Этот выпуск также позволяет pg_upgrade обрабатывать свои проверки параллельно в зависимости от настроек флага --jobs и добавляет флаг --swap, позволяющий менять местами каталоги обновления вместо копирования, клонирования или связывания файлов.
  • Улучшения производительности запросов и общие оптимизации
    • PostgreSQL 18 дополнительно повышает производительность запросов благодаря функциям, которые автоматически ускоряют выполнение рабочих нагрузок. В этом выпуске представлены функции поиска «skip scan» по многоколоночным индексам B-дерево, улучшающие время выполнения запросов, в которых отсутствует условие = для одной или нескольких первых колонок индекса. Также оптимизируются запросы с условиями OR в WHERE, позволяя использовать индекс и существенно сокращая время выполнения. Также внесены многочисленные улучшения в планирование и выполнение соединений таблиц PostgreSQL: от ускорения хеш-соединений (hash join) до возможности использования инкрементальных сортировок в соединениях слиянием (merge join). PostgreSQL 18 также поддерживает параллельное создание GIN-индексов, дополнив этим B-деревья и BRIN-индексы, которые уже поддерживали такую возможность.
    • Релиз также развивает поддержку аппаратного ускорения: добавлены инструкции ARM NEON и SVE центрального процессора для встроенной функции popcount, которую использует bit_count и другие внутренние механизмы.
  • Улучшение опыта разработчика
    • PostgreSQL 18 вводит виртуальные вычисляемые столбцы, значения которых вычисляются во время выполнения запроса вместо хранения на диске (это теперь поведение по умолчанию для вычисляемых столбцов). Кроме того, «хранимые» вычисляемые столбцы теперь поддерживаются в логической репликации.
    • В этой версии появилась возможность получать как прежние (OLD), так и текущие (NEW) значения в предложении RETURNING для команд INSERT, UPDATE, DELETE и MERGE. PostgreSQL 18 также добавляет генерацию UUIDv7 с помощью функции uuidv7(), позволяя создавать случайные UUID, упорядоченные по временной метке, что улучшает стратегии кэширования. Кроме того, в PostgreSQL 18 функция uuidv4() добавлена как псевдоним gen_random_uuid().
    • PostgreSQL 18 добавляет временные ограничения — ограничения по диапазонам — для PRIMARY KEY и UNIQUE с использованием конструкции WITHOUT OVERLAPS, а также для FOREIGN KEY с использованием PERIOD.
    • Наконец, стало проще создавать схему внешней таблицы на основе локальной: добавлена команда CREATE FOREIGN TABLE … LIKE.
  • Улучшенная обработка текста
    • PostgreSQL 18 упрощает и ускоряет работу со строками благодаря нескольким улучшениям. В этом выпуске добавлена сортировка PG_UNICODE_FAST, которая обеспечивает полноценную семантику Unicode для преобразования регистра, помогая ускорить многие сравнения. Это касается функций upper и lower, а также новой функции casefold для регистронезависимых сравнений. Кроме того, PostgreSQL 18 теперь поддерживает выполнение сравнений LIKE над текстом с недетерминированной сортировкой, что упрощает сложный поиск по шаблону. В этом релизе также изменено поведение полнотекстового поиска: теперь он использует поставщика сортировки по умолчанию для кластера вместо принудительного использования libc. Это может потребовать пересоздания всех индексов полнотекстового поиска и pg_trgm после выполнения pg_upgrade.
  • Аутентификация и безопасность
    • PostgreSQL 18 добавляет аутентификацию oauth, позволяющую пользователям проходить проверку подлинности с использованием механизмов OAuth 2.0, поддерживаемых через расширения PostgreSQL. Кроме того, PostgreSQL 18 добавляет проверку режима FIPS и новый параметр ssl_tls13_ciphers для настройки наборов шифров TLS v1.3 на стороне сервера.
    • В этом выпуске прекращена поддержка аутентификации по паролю md5 (будет удалена в одном из будущих релизов). Если вам требуется парольная аутентификация в PostgreSQL, используйте SCRAM-аутентификацию. PostgreSQL 18 также поддерживает сквозную аутентификацию SCRAM с помощью postgres_fdw и dblink для аутентификации на удалённых экземплярах PostgreSQL. Кроме того, pgcrypto теперь поддерживает шифрование паролей с использованием SHA-2.
  • Репликация
    • PostgreSQL 18 поддерживает регистрацию конфликтов записи при логической репликации в журналах и в представлении pg_stat_subscription_stats. Кроме того, теперь команда CREATE SUBSCRIPTION по умолчанию применяет транзакции в несколько параллельных потоков, что может повысить производительность. Утилита pg_createsubscriber получила флаг --all, позволяющий создавать логические реплики для всех баз данных в экземпляре одной командой. Также PostgreSQL 18 позволяет автоматически удалять неактивные слоты репликации, чтобы избежать избыточного накопления файлов журнала предзаписи (WAL) на стороне публикующего сервера.
  • Обслуживание и наблюдаемость
    • PostgreSQL 18 улучшает стратегию очистки, путём упреждающей заморозки большего количества страниц во время регулярной очистки, что снижает накладные расходы и помогает в ситуациях, требующих агрессивной очистки.
    • PostgreSQL 18 добавляет больше информации в EXPLAIN, который предоставляет информацию о выполнении плана запроса, и, начиная с этого выпуска, теперь автоматически показывает, сколько буферов (основной единицы хранения данных) используется при выполнении EXPLAIN ANALYZE. Кроме того, EXPLAIN ANALYZE показывает количество обращений к индексу при его сканировании, а EXPLAIN ANALYZE VERBOSE включает статистику использования процессора, WAL и средним временам чтения. В представлении pg_stat_all_tables появилась дополнительная информация о времени, затраченном на очистку и связанные с ней операции, а также статистику ввода-вывода и использования WAL по каждому соединению.
  • Прочие заметные изменения
    • Базы данных, инициализированные с помощью initdb в PostgreSQL 18, теперь по умолчанию создаются с включёнными контрольными суммами страниц. Это может повлиять на обновления с кластеров, где контрольные суммы выключены: при использовании pg_upgrade для обновления таких кластеров потребуется создать новый кластер PostgreSQL 18 с опцией --no-data-checksums.
    • Кроме того, PostgreSQL 18 представляет новую версию (3.2) протокола взаимодействия (wire protocol) PostgreSQL — первое обновление протокола с момента выхода PostgreSQL 7.4 (2003 год). При этом libpq по умолчанию по-прежнему использует версию 3.0, пока клиенты (например, драйверы, пулеры, прокси) не добавят поддержку новой версии протокола.
  • Дополнительные возможности
    • Множество других новых функций и улучшений также вошли в PostgreSQL 18 и могут оказаться полезными для ваших сценариев. Полный список новых и изменённых возможностей приведён в примечаниях к релизу.

>>> Подробности на postgresql.org

★★★★★

Проверено: Dimez ()

Недопустимо создание, распространение и использовние программ, для работы которых требуется СУБД.

Причины можно назвать, например, такие:

  • СУБД — это лишняя внешняя зависимость, при том что вообще любые внешние зависимости суть хамство в отношении пользователей и мейнтейнеров;
  • СУБД требует трудозатрат на установку, настройку и дальнейшее администрирование;
  • СУБД способна упасть (и да, падает намного чаще, чем, скажем, тот же апач — вообще пока мои сайты жили на «традиционной» CMSке, именно СУБД была причиной всех случаев downtime моих сайтов, за исключением одного, когда на сервере физически осыпался жёсткий диск);
  • СУБД требует от пользователя постоянно обновлять навыки, которые, возможно, больше ни для чего не нужны;
  • СУБД хранит информацию пользователя в неочевидном для него виде; этим грешат не только СУБД, конечно, но СУБД мало того что хранят всё в бинарных файлах, которые без самой СУБД даже думать нечего разобрать, они ещё и вводят дополнительный слой хаотизации в виде схемы БД, провоцируя разработчиков софта на внедрение «решений», единственное «описание» которых остаётся в голове у автора;
  • СУБД требует изрядных вычислительных мощностей и крадёт (а вовсе не повышает, как почему-то многие уверены) производительность.
MaZy ★★★★★
()
Ответ на: комментарий от MaZy

Андрей Викторович, перелогиньтесь.

hobbit ★★★★★
()
Ответ на: комментарий от borisych

чтобы не тащить отдельным расширением.

а если между тобой и БД ещё и девопсы стоят - ещё и девопсов не уговаривать это расширение собирать/ставить.

хочется же

CREATE TABLE table_name (
	id_name uuid DEFAULT uuid_generate_v7() NOT NULL,
        ...
)
без мороки.

Toxo2 ★★★★
()
Последнее исправление: Toxo2 (всего исправлений: 1)

Хм, прикольно. 2 дня назад крячил ПГ в контейнер, была проблема с volume, долго не мог понять в чем дело. Поглядел а ПГ18, ну взял поменьше и все сразу заработало.

Я тогда даже не подумал что она только что вышла ;)

mx__ ★★★★★
()
Ответ на: комментарий от MaZy

Недопустимо создание, распространение и использовние программ, для работы которых требуется СУБД.

Извините а вы понимаете что такое СУБД и зачем оно нужно?

mx__ ★★★★★
()
Ответ на: комментарий от borisych

только зачем БД его генерировать…

Например если вставляешь запись руками или через текстовый скрипт - будет удобно. Ну и в целом в БД хватает функций генерации идентификаторов - sequence, uuidv4, теперь этот будет. В конце концов, почему бы и не генерировать id в БД. Кому-то так может быть удобней. В Java, например, UUIDv7 насколько я помню нет. Тянуть какие-то васянские либы или генерировать в БД - я бы выбрал второе.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от mx__

Это очень плохая идея - не указывать версию образа, для postgres. У него нет автоматических миграций, поэтому когда твой контейнер с postgres:latest внезапно пересоздастся через год с тем же каталогом data, но с версией n+1, может случится что-то непонятное. А оно по закону подлости так и случится, когда этого меньше всего ожидаешь.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)

А почему UUID вообще не забыто как чисто мастдайно-майкрософтная сущность и давно не похоронено в веках? Это же просто 128-битное число. Генерируй и записывай его как хочешь, если тебе зачем-то нужны 128-бит. Зачем привязываться к этому странному формату его записи? Какая-то там временная метка, версия, id узла и прочая фигня.

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от vbr

Это очень плохая идея - не указывать версию образа, для postgres.

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

mx__ ★★★★★
()
Ответ на: комментарий от lesopilorama

А почему UUID вообще не забыто как чисто мастдайно-майкрософтная сущность и давно не похоронено в веках?

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

Это же просто 128-битное число.

Всё твоё сообщение это просто 2500-битное число :)

Генерируй и записывай его как хочешь, если тебе зачем-то нужны 128-бит.

Если генерировать «как хочешь», то полезные свойства теряются. Надо генерировать как положено.

Зачем привязываться к этому странному формату его записи?

Что значит «привязываться»? В базе UUID хранится, как 16 байтов. При трансформации в строку - да, используется стандартный формат представления UUID. Почему бы и не использовать его, что в нём такого уж странного? Понятный всем формат.

Какая-то там временная метка, версия, id узла и прочая фигня.

Это как раз редко используется. По моему опыту в 99% случаев используется UUIDv4. Это просто 124 случайных бита и 4 фиксированных. Но UUIDv7, скорей всего, тоже будет набирать популярность, т.к. у UUIDv4 есть некоторые проблемы и неудобства, которые решены в UUIDv7, а серьёзных недостатков у UUIDv7 нет.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

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

Единственное я не понял нафиг нужно OAuth 2.0

YogSagot ★★☆
()
Ответ на: комментарий от MaZy

Бесплатный совет. Заменить в этом сообщении «СУБД» на «архитектура Фон Неймана» и перечитать.

tomb
()
Ответ на: комментарий от YogSagot

Отличная новость

Но не для логопефтов.

dataman ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.