LINUX.ORG.RU

Релиз PostgreSQL 12

 


0

1

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

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

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

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

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

Улучшения производительности

PostgreSQL 12 включает существенные улучшения производительности и процедур обслуживания для систем индексирования и секционирования.

Индексы B-tree — стандартный тип индексирования в PostgreSQL, были оптимизированы в версии 12 для нагрузок, предполагающих частые модификации индексов. Использование эталонного теста TPC-C для PostgreSQL 12 продемонстрировало сокращение использования пространства в среднем на 40% и общий прирост производительности запросов.

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

В PostgreSQL 12 были произведены дополнительные усовершенствования в индексировании, которые влияют на общую производительность, включая:

  • снижение накладных расходов при генерации WAL для типов индексов GiST, GIN и SP-GiST;
  • возможность создавать так называемые покрывающие индексы (covering indexes, предложение INCLUDE) на GiST-индексы;
  • возможность выполнять запросы «ближайших соседей» (k-NN search) с помощью оператора расстояния (<->) и использованием индексов SP-GiST;
  • поддержку сбора статистики наиболее распространенных значений (most-common value, MCV) с помощью CREATE STATISTICS, что помогает получать лучшие планы выполнения запросов при использовании столбцов, значения для которых распределены неравномерно.

JIT-компиляция с использованием LLVM, появившаяся в PostgreSQL 11, теперь включена по умолчанию. JIT-компиляция позволяет повышать производительность при работе с выражениями в предложениях WHERE, целевых списках, агрегатах и некоторых внутренних операциях. Она доступна, если вы скомпилировали PostgreSQL с LLVM или используете пакет PostgreSQL, который был создан с включённым LLVM.

Улучшения возможностей языка SQL и совместимости со стандартом

В PostgreSQL 12 появилась возможность выполнять запросы к документам JSON с использованием выражений пути JSON, определенных в стандарте SQL/JSON. Такие запросы могут использовать существующие механизмы индексации для документов, хранящихся в формате JSONB, для эффективного извлечения данных.

Общие табличные выражения, также известные как запросы с WITH, в PostgreSQL 12 теперь могут автоматически исполняться с применением подстановки, что, в свою очередь, может помочь повысить производительность многих существующих запросов. В новой версии часть запроса WITH может выполняться с подстановкой, только если она не является рекурсивной, не имеет побочных эффектов и на неё ссылаются только один раз в последующей части запроса.

В PostgreSQL 12 появляется поддержка «генерируемых столбцов». Описанный в стандарте SQL, этот тип столбца вычисляет значение на основе содержимого других столбцов в той же таблице. В этой версии PostgreSQL поддерживает «хранимые генерируемые столбцы», где вычисленное значение хранится на диске.

Интернационализация

PostgreSQL 12 расширяет поддержку ICU-сопоставлений, разрешая пользователям определять «недетерминированные сопоставления», которые могут, например, позволять сравнения без учёта регистра или ударения.

Аутентификация

PostgreSQL расширяет свою поддержку надёжных методов аутентификации с помощью нескольких улучшений, которые обеспечивают дополнительную безопасность и функциональность. В этом выпуске представлено шифрование на стороне клиента и на стороне сервера для аутентификации через интерфейсы GSSAPI, а также возможность PostgreSQL обнаруживать серверы LDAP, если PostgreSQL скомпилирован с OpenLDAP.

Кроме того, PostgreSQL 12 теперь поддерживает вариант многофакторной аутентификации. Теперь сервер PostgreSQL может затребовать у клиента предоставление валидного SSL-сертификата с соответствующим именем пользователя с использованием clientcert=verify-full, и комбинировать это с отдельным требованием метода аутентификации (например, scram-sha-256).

Администрирование

В PostgreSQL 12 появилась возможность выполнять неблокирующее перестроение индексов с помощью команды REINDEX CONCURRENTLY. Это позволяет пользователям избегать простоя в работе СУБД при длительном перестроении индексов.

Кроме того, в PostgreSQL 12 можно включать или отключать контрольные суммы страниц в кластере, находящемся в выключенном состоянии, с помощью команды pg_checksums. Ранее контрольные суммы страниц — функцию, помогающую проверить целостность данных, хранящихся на диске, — можно было включить только в момент инициализации кластера PostgreSQL с помощью initdb.

>>> Источник

★★★★

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

Ответ на: комментарий от anonymous

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

нет базы данных лучше PostgreSQL. единственная база данных для всех применений. всякие новомодные глючные тормознутые поделочки типа тьфу не побоюсь этого слова mongodb обгоняет на задачах под которые они [говноподелки] якобы специально заточены.

узрите всю мощь PostgreSQL, несчастные юзеры говноподелок.

iluha16 ()
Ответ на: комментарий от iDesperado

В современом DB2 есть опции, которые помогают снизить количество блокировок. Масса факторов влияет, например, уровень изоляции транзакции, настройки СУБД и т.п.

Есть немало промышленных приложений, которые вполнет успешно работают с IBM DB2.

Кроме того DB2 давно уже поддерживает почти полностью синтаксис Oracle, что облегчает миграцию с Oracle на DB2.

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

У db2 нет undo дога, потому все те опции лишь градации грязного чтения. Я в курсе про read last committed, skip locked и прочее. Во времена когда даже mysql имеет полноценный undo и не ограничен 4 ядрами эти опции кажутся странными.

iDesperado ()
Ответ на: комментарий от spoonbob

Примеры из разряда выстрели себе в ногу. Лучше мне объясни следующее в постгресе:

database=> select unnest(ARRAY['oo','@o']) as x order by x;
 x  
----
 @o
 oo
(2 строки)

database=> select unnest(ARRAY['op','@p']) as x order by x;
 x  
----
 op
 @p
(2 строки)
turtle_bazon ★★★ ()
Ответ на: комментарий от iDesperado

У db2 нет undo дога, потому все те опции лишь градации грязного чтения.

2 - When CUR_COMMIT is enabled, and a transaction is trying to read the committed version of the row, and the log record(s) are no longer in the log buffer.

https://www.idug.org/p/fo/et/thread=47592

Во времена когда даже mysql ... не ограничен 4 ядрами эти опции кажутся странными

Разве DB2 Community C ограничен по ресурсам кроме размера базы в 100 гиг? Данные могут сжиматься автоматически и количество баз неограниченно.

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

anonymous ()
Ответ на: комментарий от iDesperado

У db2 нет undo дога

Речь о транзакционном логе? Active log & archive log?

Как вы себе представляете промышленную СУБД, коей DB2 является уже очень давно, без транзакционного лога?

потому все те опции лишь градации грязного чтения.

есть ли прямая зависимость между тем, что в эпоху DB2 до cur_commit (до 2009 год, т.е. 10 лет назад и более), были только грязные чтения для улучшения concurrency и наличием транзакционного лога, который появился намного раньше?

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

есть ли прямая зависимость между тем, что в эпоху DB2 до cur_commit (до 2009 год, т.е. 10 лет назад и более), были только грязные чтения для улучшения concurrency и наличием транзакционного лога, который появился намного раньше?

До cur_commit дб2 висел на блокировке и выдавал более согласованный набор. Т.е. cur_commit слабей обычного блокировочного read committed. Но это все мелочи, фигня в том cs уровень не возможно толком использовать. Представь читаем последнее заклмиченное значение записи из партиции1, пока читаем оставшиеся записи их партиции1, конкурирующая транзакция коммиттит и запись перезжает в партицию2. Теперь читающий запрос прочтет запись дважды.

iDesperado ()
Ответ на: комментарий от anonymous

С анонимусом вообще нет смысла спорить или обсуждать.

Но ввилу нападки на меня отмечаю, что никаких вялых попыток выдать не было. Я просто отметил, чтоинадо уметь пользоваться СУБД вообще и PostgreSQL в частности. В отм числе и скорость выполнения SELECT COUNT(*) зависит от умения. Если я вижу, что она мала, то я знаю, что надо подкрутить, чтобы это поправить. А вразумлять самоувреннных невежд мне лень.

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

До cur_commit дб2 висел на блокировке и выдавал более согласованный набор.

Так ведь и сейчас так можно, только висеть то не хочется на блокировке

Но это все мелочи, фигня в том cs уровень не возможно толком использовать. Представь читаем последнее заклмиченное значение записи из партиции1, пока читаем оставшиеся записи их партиции1, конкурирующая транзакция коммиттит и запись перезжает в партицию2. Теперь читающий запрос прочтет запись дважды.

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

anonymous ()
Ответ на: комментарий от iDesperado

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

Можно ссылки на пруфы?

Если это действительно так, и не фиксится какой-нибудь опцией DB2, то для чего тогда вообще может быть полезен движок DB2 в качестве универсальной СУБД? В PostgreSQL с этим лучше?

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

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

партиции не причем, просто на них проще всего увидеть. в мсскл это и в пределах одной партиции легко получить.

Можно ссылки на пруфы?

вечером посмотрю в закладках где то было достаточно развернуто разжевано на примере мсскл. пример вот тут можно глянуть https://blog.sqlxdetails.com/read-committed-sucks/

Если это действительно так, и не фиксится какой-нибудь опцией DB2, то для чего тогда вообще может быть полезен движок DB2 в качестве универсальной СУБД? В PostgreSQL с этим лучше?

постгрес пусть и фиговый, но версионник. он и на RC вернет консистентный набор на момент старта запроса.

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

постгрес пусть и фиговый, но версионник. он и на RC вернет консистентный набор на момент старта запроса.

MSSQL из всех СУБД наверно наиболее гибридный или по крайне мере может работать почти как версионник или почти как блокировочник в зависимости от настройки. В каком режиме с точки зрения версионности работал MSSQL, когда так вел себя?

anonymous ()
Ответ на: комментарий от Partisan

А потому что ты слишком категоричен в своих утверждениях. То select count(*) просто медленный, а теперь оказалось, что зависит от умения. Поэтому именно ты выглядишь самоуверенным невеждой.

anonymous ()
Ответ на: комментарий от Partisan

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

southern_sun ()

А «SELECT ... USE INDEX ...» в 12 версии случайно не появился? Нет? Ну тогда продолжаем мигрировать с такого хорошего и замечательного PostgreSQL на не такой офигенный MySQL... Задолбало.

xupypr ()

mysql galera или percona xtradb есть подобное? Если нет, продолжу игнорить, юзал pg на паре проектах (один был postgres+timescaledb - это было ок) Было неудобно админить, pgadmin стабильно кошмарен.

anonymous ()
Ответ на: комментарий от anonymous
http://www.postgresql.org/docs/9.1/static/storage-file-layout.html
                                                           55.1. Database File Layout

http://www.postgresql.org/docs/9.1/static/storage-fsm.html Chapter 55. Database Physical Storage 
                                                           55.3. Free Space Map

http://www.postgresql.org/docs/9.5/static/storage-fsm.html Chapter 63. Database Physical Storage
                                                           63.3. Free Space Map

http://www.postgresql.org/docs/9.5/static/storage.html     Chapter 63. Database Physical Storage

http://www.postgresql.org/docs/9.5/static/storage-page-layout.html  63.6. Database Page Layout

 Every table and index is stored as an array of pages of a fixed size (usually 8 kB, although a different page size can be selected when compiling the server). 

18.4. Resource Consumption                                 https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY

https://habrahabr.ru/company/okmeter/blog/324494/          Запись при чтении в postgresql: скандалы, интриги, расследования

https://habrahabr.ru/post/324264/                          Получаем список операторов PostgreSQL

https://habrahabr.ru/company/postgrespro/blog/326096/      Индексы в PostgreSQL — 1
https://habrahabr.ru/company/postgrespro/blog/326106/      Индексы в PostgreSQL — 2
https://habrahabr.ru/company/postgrespro/blog/328280/      Индексы в PostgreSQL — 3
https://habrahabr.ru/company/postgrespro/blog/330544/      Индексы в PostgreSQL — 4
https://habrahabr.ru/company/postgrespro/blog/333878/      Индексы в PostgreSQL — 5
https://habrahabr.ru/company/postgrespro/blog/337502/      Индексы в PostgreSQL — 6
https://habrahabr.ru/company/postgrespro/blog/340978/      Индексы в PostgreSQL — 7
https://habrahabr.ru/company/postgrespro/blog/343488/      Индексы в PostgreSQL — 8
https://habrahabr.ru/company/postgrespro/blog/346460/      Индексы в PostgreSQL — 9

https://habrahabr.ru/company/infowatch/blog/335644/        Партиционирование в postgres 9.x. Использование pg_pathman для оптимизации вставки и отсечения (pruning) партиций

https://habrahabr.ru/company/southbridge/blog/322624/      Uber — причины перехода с Postgres на MySQL

https://habrahabr.ru/post/339060/                          Про интервальные индексы

https://habrahabr.ru/company/postgrespro/blog/353472/      Секционирование в PostgreSQL 10 и не только

https://habrahabr.ru/company/devconf/blog/353682/          DevConf: переход Uber с PostgreSQL на MySQL
anonymous ()