, Апошняя версія "Лепшай у свеце рэляцыйнай базы дадзеных з адкрытым зыходным кодам", выходзіць праз пару-тройку тыдняў (калі ўсё пойдзе па плане). Гэта адпавядае звычайнаму раскладу - новая версія з плоймай новых магчымасцяў выходзіць раз у год, і, сапраўды кажучы, гэта ўражвае. Таму я і стаў актыўным чальцом супольнасці PostgreSQL.
Па-мойму, у адрозненне ад мінулых выпускаў, PostgreSQL 12 не ўтрымоўвае адной-двух рэвалюцыйных функцый (як, напрыклад, секцыянаванне ці паралелізм запытаў). Я неяк пажартаваў, што галоўная фішка PostgreSQL 12 – у большай стабільнасці. А няўжо не гэта трэба, калі вы кіруеце крытычна важнымі дадзенымі вашага бізнэсу?
Але PostgreSQL 12 гэтым не абмяжоўваецца: з новымі магчымасцямі і ўдасканаленнямі прыкладанні будуць працаваць лепш, а ад вас усяго толькі патрабуецца зрабіць апгрэйд!
(Ну, можа, яшчэ азначнікі перабудаваць, але ў гэтым рэлізе гэта не так страшна, як мы абвыклі.)
Вось будзе выдатна - апгрэйднуць PostgreSQL і адразу атрымліваць асалоду ад значнымі паляпшэннямі без лішніх рухаў цела. Некалькі гадоў таму я аналізаваў абнаўленне з PostgreSQL 9.4 да PostgreSQL 10 і ўбачыў, як паскорылася дадатак дзякуючы палепшанаму паралелізму запытаў у PostgreSQL 10. І, галоўнае, ад мяне амаль нічога не патрабавалася (усяго-то задаць параметр канфігурацыі max_parallel_workers).
Пагадзіцеся, зручна, калі адразу пасля апгрэйду прыкладанні працуюць лепш. А мы вельмі імкнемся цешыць карыстачоў, бо ў PostgreSQL іх усё больш.
І як жа просты апгрэйд да PostgreSQL 12 зробіць вас шчаслівым? Зараз раскажу.
Сур'ёзныя паляпшэнні індэксавання
Без індэксавання база даных далёка не з'едзе. А як яшчэ хутка шукаць інфармацыю? Фундаментальная сістэма індэксавання PostgreSQL называецца . Гэты тып індэкса аптымізаваны для сістэм захоўвання.
Мы проста выкарыстоўваем аператар CREATE INDEX ON some_table (some_column), а PostgreSQL прарабляе вялікую працу, каб падтрымліваць актуальнасць азначніка, пакуль мы стала ўстаўляемы, абнаўляемы і выдаляны значэнні. Усё працуе само па сабе, як па чараўніцтве.
Але ў індэксаў PostgreSQL ёсць адна праблема – яны і займаюць лішняе месца на дыску, а прадукцыйнасць вымання і абнаўленні дадзеных змяншаецца. Пад «раздзіманнем» я маю на ўвазе неэфектыўнае падтрыманне індэкснай структуры. Гэта можа быць - а можа і не быць - звязана са смеццевымі картэжамі, якія выдаляе (дзякуй за інфармацыю Піцеру Гейгану ()). Раздзіманне індэкса асабліва прыкметна ў працоўных нагрузках, дзе індэкс актыўна змяняецца.
PostgreSQL 12 сур'ёзна паляпшае працу азначнікаў B-дрэва, і эксперыменты з тэстамі тыпу TPC-C паказалі, што месцы зараз выкарыстоўваецца, у сярэднім, на 40% менш. Цяпер мы трацім менш часу не толькі на абслугоўванне індэксаў B-дрэва (гэта значыць на аперацыі запісы), але і на атрыманне дадзеных, бо індэксы сталі значна менш.
Прыкладанні, якія актыўна абнаўляюць свае табліцы - звычайна гэта OLTP-прыкладанні () - будуць значна больш эфектыўна выкарыстоўваць дыск і апрацоўваць запыты. Чым больш на дыску месца, тым больш у базы дадзеных прасторы для росту без апгрэйду інфраструктуры.
Некаторыя стратэгіі апгрэйду патрабуюць перабудаваць індэксы B-дрэва, каб скарыстацца гэтымі перавагамі (напрыклад, не перабудуе індэксы аўтаматычна). У папярэдніх версіях PostgreSQL перабудова вялікіх азначнікаў у табліцах прыводзіла да значнага прастою, бо ў гэты час нельга было ўносіць змены. Але ў PostgreSQL 12 ёсць яшчэ адна класная фішка: зараз можна перабудоўваць азначнікі раўналежна камандай , Каб зусім пазбегнуць прастою.
У 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 у табліцах са мноствам секцый.
Запіс дадзеных з дапамогай - дарэчы, гэта выдатны спосаб і вось прыклад - У секцыянаванага табліцы ў PostgreSQL 12 таксама стала больш эфектыўна. З COPY і так усё было хутка, а ў PostgreSQL 12 зусім лётае.
Дзякуючы гэтым перавагам у PostgreSQL можна захоўваць наборы дадзеных яшчэ большага памеру, а здабываць іх стала прасцей. І ніякіх намаганняў з вашага боку. Калі ў дадатку шмат секцый, напрыклад, яно запісвае дадзеныя часовых шэрагаў, просты апгрэйд значна палепшыць яго прадукцыйнасць.
І хоць гэтае паляпшэнне не зусім з катэгорыі «апгрэйднулі і цешымся», у PostgreSQL 12 можна ствараць вонкавыя ключы, якія спасылаюцца на секцыянаваныя табліцы, каб праца з секцыянаваннем прыносіла адно задавальненне.
Запыты WITH сталі значна лепш
Калі (яны ж CTE, яны ж запыты WITH), мне не цярпелася напісаць артыкул аб тым, . Гэта адна з тых фіч, якія паскораць дадатак. Калі, вядома, вы карыстаецеся CTE.
Я часта заўважаю, што пачаткоўцы ў SQL кахаюць выкарыстоўваць CTE: калі напісаць іх вызначанай выявай, прама адчуваеш, што пішаш імператыўную праграму. Асабіста я любіў перапісваць гэтыя запыты, каб абысціся без CTE і павялічыць прадукцыйнасць. Цяпер усё інакш.
PostgreSQL 12 дазваляе ўбудоўваць пэўны тып CTE без пабочных эфектаў (SELECT), які выкарыстоўваецца толькі адзін раз бліжэй да канца запыту. Калі б я вёў статыстыку запытаў з CTE, якія я перапісваў, большасць з іх патрапілі б у гэтую катэгорыю. Гэта дапамагае распрацоўнікам пісаць зразумелы код, які зараз яшчэ і хутка працуе.
Больш за тое, PostgreSQL 12 аптымізуе выкананне SQL сам, вам не давядзецца нічога рабіць. І хоць зараз, мусіць, мне не трэба будзе аптымізаваць такія запыты, выдатна, што PostgreSQL працягвае працаваць над аптымізацыяй запытаў.
Just-in-Time (JIT) - зараз па змаўчанні
У сістэмах PostgreSQL 12 з падтрымкай 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