Актуализация за мързеливите: как PostgreSQL 12 повишава производителността

PostgreSQL 12, последната версия на „най-добрата в света релационна база данни с отворен код“ ще излезе след няколко седмици (ако всичко върви по план). Това съответства на обичайния график — нова версия с множество нови възможности се публикува веднъж годишно и, честно казано, това е впечатляващо. Затова и станах активен член на общността PostgreSQL.

Според мен, за разлика от предишните версии, PostgreSQL 12 не съдържа една-две революционни функции (например, секциониране или паралелизъм на заявките). Шегувах се, че основната характеристика на PostgreSQL 12 е в по-голямата стабилност. А нали това е важно, когато управлявате критично важни данни на вашия бизнес?

Но PostgreSQL 12 не се ограничава само до това: с новите възможности и подобрения приложенията ще работят по-добре, а от вас се иска просто да направите ъпгрейд!

(Може би ще трябва и да реконструирате индексите, но в това издание това не е толкова страшно, колкото сме свикнали.)

Ще бъде чудесно — да ъпгрейднете PostgreSQL и веднага да се насладите на значителни подобрения без излишни усилия. Преди няколко години анализирах обновлението от PostgreSQL 9.4 до PostgreSQL 10 и видях как приложението се ускори благодарение на подобрения паралелизъм на заявките в PostgreSQL 10. И, най-важното, от мен почти не се изискваше нищо (само да задам параметър за конфигурация, max_parallel_workers).

Съгласете се, приятно е, когато веднага след ъпгрейда приложенията работят по-добре. А ние много се стараем да радим потребителите, защото PostgreSQL има все повече от тях.

И как простият ъпгрейд до PostgreSQL 12 ще ви направи щастливи? Сега ще разкажа.

Сериозни подобрения в индексите

Без индексирането, базата данни няма да постигне много. А как иначе да се намира информация бързо? Основната система за индексиране на PostgreSQL се нарича B- дърво. Този тип индекс е оптимизиран за системи за съхранение.

Просто използваме оператора CREATE INDEX ON some_table (some_column), а PostgreSQL извършва голямата работа, за да поддържа актуалността на индекса, докато постоянно вмъкваме, обновяваме и изтриваме стойности. Всичко работи само по себе си, като по чудо.

Но индексирането на PostgreSQL има един проблем — те нарастват и заемат излишно място на диска, а производителността на извличане и актуализиране на данни намалява. Под "раздуване" имам предвид неефективното поддържане на индексната структура. Това може да бъде — а може и да не бъде — свързано с излишни кортежи, които се изтриват VACUUM (благодаря за информацията на Питър Гейган (Peter Geoghegan)). Раздуването на индекса е особено забележимо в работни натоварвания, където индексът активно се променя.

PostgreSQL 12 значително подобрява работата на B-деревните индекси, а експериментите с тестове от типа TPC-C показаха, че пространството сега се използва, в средно, с 40% по-малко. Сега харчим по-малко време не само за поддръжка на B-деревните индекси (тоест операции за запис), но и за извличане на данни, тъй като индексите са станали много по-малки.

Приложения, които активно актуализират своите таблици — обикновено това са OLTP-приложения (обработка на транзакции в реално време) — ще използват диска много по-ефективно и ще обработват запитвания. Колкото повече място има на диска, толкова повече пространство има базата данни за растеж без нужда от обновление на инфраструктурата.

Някои стратегии за обновление изискват преизграждане на B-деревните индекси, за да се възползват от тези предимства (например, pg_upgrade не преизгражда индексите автоматично). В предишни версии на PostgreSQL преизграждането на големи индекси в таблиците водеше до значителен престой, тъй като в това време не беше възможно да се правят промени. Но в PostgreSQL 12 има още една чудесна функция: сега може да се преизграждат индексите паралелно, за да се избегне напълно престой. REINDEX CONCURRENTLYВ PostgreSQL 12 има и други подобрения на инфраструктурата за индексиране. Още една отметка, където не се мина без магия, —

журнал за предварително записване , известен и като WAL (write-ahead log). Журналът за предварително записване записва всяка транзакция в PostgreSQL за случай на срив и репликация. Приложенията го използват за архивиране ивъзстановяване в определен момент . Разбира се, журналът за предварително записване се записва на диска, което може да повлияе на производителността.. Конечно, журнал упреждающей записи записывается на диск, а это может отразиться на производительности.

В PostgreSQL 12 разходите по записите WAL, създавани от индексите GiST, GIN и SP-GiST при построяване на индекс, намаляват. Това предлага няколко забележителни предимства: записите WAL заемат по-малко място на диска и данните по-бързо се възстановяват, например по време на възстановяване след срив или при възстановяване в конкретен момент. Ако използвате такива индекси в приложенията си (например, геопространствени приложения, базирани на PostGIS, много използват индекса GiST), това е още едно предимство, което значително подобрява работата без никакви усилия от ваша страна.

Секциониране — повече, по-добро, по-бързо

В PostgreSQL 10 беше въведено декларативно секциониране. В PostgreSQL 11 стана много по-лесно за използване. В PostgreSQL 12 може да се променя мащабът на секциите.

В PostgreSQL 12 производителността на системата за секциониране значително се подобри, особено ако таблицата има хиляди секции. Например, ако заявката засяга само няколко секции в таблица с хиляди, тя ще се изпълнява много по-бързо. Производителността е подобрена не само за такива типове заявки. Също така ще забележите, как операциите INSERT в таблици с много секции се ускориха.

Записването на данни чрез COPY — между другото, това е отличен начин за масова зареждане на данни и ето един пример за прием JSON — в секционирани таблици в PostgreSQL 12 също стана по-ефективно. С COPY и без това беше бързо, а в PostgreSQL 12 е направо бързо.

Благодарение на тези предимства в PostgreSQL можете да съхранявате набори от данни с още по-голям размер, а извличането им стана по-лесно. И без никакви усилия от ваша страна. Ако приложението ви има много секции, например записва данни от времеви редове, простата актуализация значително подобрява неговата производителност.

И макар това подобрение да не е точно от категорията „апгрейд и се радваш“, в PostgreSQL 12 можете да създадете външни ключове, които сочат към секционирани таблици, за да работата с секционирането да бъде удоволствие.

Запитванията WITH станаха много по-добри

Когато беше приложен пач за вградени обобщени таблицови изрази (те също са CTE, те също са запитвания WITH), нямам търпение да напиша статия за това, как разработчиците на приложения с PostgreSQL се зарадваха. Това е една от тези функции, които ще ускорят приложението. Ако, разбира се, използвате CTE.

Често забелязвам, че начинаещите в SQL обичат да използват CTE: ако ги напишеш по определен начин, наистина усещаш, че пишеш императивна програма. Лично аз обичах да пренаписвам тези заявки, за да се справя без с CTE и да увелича производителността. Сега всичко е различно.

PostgreSQL 12 позволява вграждането на определен тип CTE без странични ефекти (SELECT), който се използва само веднъж по-близо до края на заявката. Ако водех статистика на заявките с CTE, които пренаписвах, повечето от тях щяха да попаднат в тази категория. Това помага на разработчиците да пишат разбираем код, който сега работи и бързо.

Още повече, PostgreSQL 12 оптимизира изпълнението на SQL сам, няма да се налага да правите нищо. И макар че сега сигурно няма да ми се налага да оптимизирам такива заявки, е страхотно, че PostgreSQL продължава да работи над оптимизацията на заявките.

Just-in-Time (JIT) — сега по подразбиране

В системите PostgreSQL 12 с поддръжка на LLVM JIT компилацията е включена по подразбиране. Първо, получавате поддръжка за JIT за някои вътрешни операции, а второ, заявките с изрази (най-простият пример — x + y) в списъците за избор (които стоят след SELECT), агрегатите, изразите с условия WHERE и други могат да използват JIT за повишаване на производителността.

Тъй като JIT е включен в PostgreSQL 12 по подразбиране, производителността ще се подобри сама по себе си, но съветвам ви да тествате приложението в PostgreSQL 11, където JIT едва се появи, за да измерите производителността на заявките и да разберете дали трябва нещо да се настройва.

А какво ще кажете за другите нови функции на PostgreSQL 12?

В PostgreSQL 12 има много нови страхотни функции — от възможността да се изследват данни JSON с помощта на стандартни SQL/JSON изрази до многофакторна автентикация с параметъра clientcert=verify-full, виртуални колони и много други. Достатъчно е за отделен пост.

Както и PostgreSQL 10, PostgreSQL 12 ще увеличи общата производителност веднага след ъпгрейда. Разбира се, може да имате свой начин — тествайте приложението при сходни условия в работната система, преди да активирате подобренията, както направих аз с PostgreSQL 10. Дори да е стабилно PostgreSQL 12 сега по-добре, отколкото предполагах, не се колебайте да тествате качествено приложенията, преди да ги пуснете в продукция.

Източник: habr.com