Надстройка за мързеливите: как 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 имат един проблем - те подути и заемат допълнително дисково пространство и производителността на извличане и актуализиране на данни се намалява. Под „раздуване“ имам предвид неефективно поддържане на структурата на индекса. Това може или не може да е свързано с кортежите за боклук, които ВАКУУМ (благодарение на Peter Gagan за информацията)Питър Геохеган)). Раздуването на индекса е особено забележимо при работни натоварвания, при които индексът се променя активно.

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

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

Някои стратегии за надграждане изискват да изградите отново индексите на B-дърво, за да се възползвате от тези предимства (напр. pg_upgrade няма да възстановява индексите автоматично). В предишните версии на PostgreSQL повторното изграждане на големи индекси на таблици доведе до значителен престой, тъй като през това време не можеха да се правят промени. Но PostgreSQL 12 има друга страхотна функция: сега можете да възстановявате индекси паралелно с командата РЕИНДЕКС ЕДНОВРЕМЕННОза да избегнете напълно престой.

PostgreSQL 12 има други подобрения в инфраструктурата за индексиране. Друго нещо, в което имаше някаква магия - дневник за предварително записване, известен още като WAL (дневник за предварително записване). Регистърът за предварителен запис записва всяка транзакция в 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 queries), много ми се искаше да напиша статия за това как колко възхитени бяха разработчиците на приложения с PostgreSQL. Това е една от онези функции, които ще ускорят приложението. Освен ако, разбира се, не използвате CTE.

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

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

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

Точно навреме (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 вече е по-стабилен, отколкото очаквах, не бъдете мързеливи да тествате приложения добре, преди да ги пуснат в производство.

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