Uuendus laiskadele: kuidas PostgreSQL 12 parandab jõudlust

PostgreSQL 12, viimane versioon «maailma parimast avatud lähtekoodiga relatiivsest andmebaasist» ilmub paar-kolm nädalat pärast (kui kõik läheb plaanipäraselt). See vastab tavapärasele ajakavale — uus versioon, mis pakub hulgaliselt uusi võimalusi, ilmub kord aastas ja, ausalt öeldes, see on muljetavaldav. Seetõttu olen ma aktiivne PostgreSQL kogukonna liige.

Minu arvates ei sisalda PostgreSQL 12, erinevalt varasematest versioonidest, ühtegi revolutsioonilist funktsiooni (nagu näiteks sektsioneerimine või päringute paralleelsus). Ma naljatasin, et PostgreSQL 12 peaesineja on suurem stabiilsus. Ja kas see ei ole see, mida vajate, kui haldate oma äri kriitilisi andmeid?

Kuid PostgreSQL 12 ei piirdu sellega: uute võimaluste ja täiustustega töötavad rakendused paremini, ja teie ainus ülesanne on teha uuendus!

(Noh, võib-olla tuleb indekseid ümber ehitada, kuid selles versioonis ei ole see nii hirmus, nagu oleme harjunud.)

See oleks suurepärane — uuendada PostgreSQL ja nautida kohe märkimisväärseid täiustusi ilma liigsete pingutusteta. Mõned aastad tagasi analüüsisin üleminekut PostgreSQL 9.4-lt PostgreSQL 10-le ja nägin, kuidas rakendus kiirenes tänu PostgreSQL 10 täiustatud päringute paralleelsusele. Ja mis kõige tähtsam, minult peaaegu ei olnud midagi vaja (ainult määrata konfiguratsiooni parameeter max_parallel_workers).

Olge nõus, et on mugav, kui kohe pärast uuendust töötavad rakendused paremini. Me pingutame palju, et meie kasutajad oleksid rahul, sest PostgreSQL kasutajate arv kasvab.

Ja kuidas teeb lihtne uuendus PostgreSQL 12 teid õnnelikuks? Räägin sellest kohe.

Olulised täiustused indekseerimises

Ilma indekseerimiseta ei vii andmebaas kaugele. Kuidas muidu kiiresti teavet leida? PostgreSQL põhindekseerimisüsteem on B-puu. See indeksi tüüp on optimeeritud salvestussüsteemide jaoks.

Me kasutame lihtsalt operaatorit CREATE INDEX ON some_table (some_column), ja PostgreSQL teeb suure töö indeksi ajakohasena hoidmiseks, kui me pidevalt lisame, uuendame ja kustutame väärtusi. Kõik töötab iseenesest, nagu maagia.

Kuid PostgreSQL indeksitel on üks probleem — nad paisuvad ja võtavad kettal liigse ruumi ning andmete väljavõtmise ja uuendamise jõudlus langeb. All "paisutamise" mõtlen ma ebaefektiivset indekstruktuuri hooldamist. See võib olla — või mitte olla — seotud prügi tuple’ite, mida eemaldatakse. VACUUM (tänud teabe eest Peter Geogheganile (Peter Geoghegan)). Indeksi paisutamine on eriti märgatav töökoormustes, kus indeksit muudetakse aktiivselt.

PostgreSQL 12 tõhustab B-puu indeksite toimimist oluliselt, ja TPC-C tüüpi testidega katsetamine on näidanud, et ruumi kasutatakse nüüd keskmiselt 40% vähem. Nüüd kulutame vähem aega mitte ainult B-puu indeksite hooldamiseks (st kirjete jaoks mõeldud toimingutele), vaid ka andmete väljavõtmiseks, kuna indeksid on nüüd palju väiksemad.

Rakendused, mis uuendavad oma tabeleid aktiivselt — tavaliselt OLTP rakendused (reaalaja tehingute töötlemine) — kasutavad ketast palju efektiivsemalt ja töötlevad päringuid. Mida rohkem kettal ruumi on, seda rohkem on andmebaasil kasvu ruumi ilma infrastruktuuri uuendamiseta.

Mõned uuendustegevuse strateegiad nõuavad B-puu indeksite taastamist nende eeliste kasutamiseks (näiteks, pg_upgrade ei taasta indekseid automaatselt). Varasemates PostgreSQL versioonides põhjustas suurte indexite taastamine tabelites märkimisväärse seisaku, kuna sel ajal ei saanud muudatusi teha. Kuid PostgreSQL 12-s on veel üks äge funktsioon: indekseid saab nüüd taastada paralleelselt käsuga REINDEX CONCURRENTLY, et täielikult vältida seisaku tekkimist.

PostgreSQL 12-s on ka teisi indekstruktuuri infrastruktuuri täiustusi. Veel üks asi, kus ei jäänud ilma võluta — ennustava kirjutamise žurnali, tuntud ka kui WAL (write-ahead log). Eelnevat kirje ajalugu registreerib iga tehingu PostgreSQL-is rikka tõrke- ja replikaatimise juhtimiseks. Rakendused kasutavad seda arhiivimiseks ja taastamiseks teatud hetkel. Loomulikult toimub eelneva kirje ajalugu kettale, mis võib mõjutada jõudlust.

PostgreSQL 12 vähendas WAL-kirjete kulusid, mida GiST-, GIN- ja SP-GiST-indeksite loomisel genereeritakse. See toob endaga kaasa mitu käegakatsutavat eelist: WAL-kirjed võtavad vähem ruumi kettal ning andmete taastamine, näiteks pärast tõrget või aegahetke taastamisel, on kiirem. Kui kasutate oma rakendustes selliseid indekseid (näiteks georuumilised rakendused, mis põhinevad PostGIS-il, kasutavad sageli GiST-indeksit), on see veel üks funktsioon, mis parandab oluliselt töö tõhusust teie pingutusteta.

Jaotamine – rohkem, parem, kiirem

PostgreSQL 10-s toodi sisse deklaratiivne jaotamine. PostgreSQL 11-s muutus selle kasutamine palju lihtsamaks. PostgreSQL 12-s on võimalik jaotuse mastaapi muuta.

PostgreSQL 12-s on jaotussüsteemi jõudlus märkimisväärselt paranenud, eriti kui tabelis on tuhandeid jaotusi. Näiteks, kui päring käsitleb vaid mõnda jaotust tabelis, kus neid on tuhandeid, siis täidetakse see palju kiiremini. Jõudlus on paranenud mitte ainult selliste päringute puhul. Samuti märkate, kui on kiirenetud INSERT-toimingud tabelites, kus on palju jaotusi.

Andmete salvestamine kasutades COPY — muide, see on suurepärane meetod massiliseks andmete laadimiseks ja siin on näide JSON-vastuvõtust — ja jaotatud tabelitesse PostgreSQL 12-s toimib see samuti tõhusamalt. COPY tegemine oli juba kiire, aga PostgreSQL 12-s on see täiesti lendav.

Nende eeliste tõttu saab PostgreSQL-s hoida veel suuremaid andmekogumeid ja nende väljavõtmine on muutunud lihtsamaks. Ja te ei pea selle nimel pingutama. Kui rakendusel on palju jaotusi, näiteks see salvestab ajareal põhinevaid andmeid, siis lihtne uuendus parandab oluliselt selle jõudlust.

Ja kuigi see täiustamine ei kuulu just kategooriasse „uuendame ja oleme õnnelikud“, on PostgreSQL 12-s võimalik luua välish võtmeid, mis viitavad jaotatud tabelitele, et jaotamisega tegelemine oleks nauditav.

WITH päringud on muutunud palju paremaks

Kui on rakendatud plaastri sisseehitatud üldiste tabelite väljenditele (need on CTE-d, Need on WITH päringud), ma ei jõudnud ära oodata, et kirjutada artikkel sellest, kui rõõmsad olid rakenduse arendajad PostgreSQL-i puhul. See on üks neist funktsioonidest, mis kiirendavad rakendust. Kui muidugi kasutate CTE-d.

Ma sageli märkan, et algajad SQL-is armastavad kasutada CTE-d: kui neid kirjutada kindlal viisil, tunned tõeliselt, et kirjutad imperatiivset programmi. Isiklikult meeldis mulle neid päringuid ümber kirjutada, et vähendada ilma CTE-d ja suurendada jõudlust. Praegu on olukord teine.

PostgreSQL 12 võimaldab teatud tüüpi CTE-d sisestada ilma kõrvaltoimeteta (SELECT), mida kasutatakse ainult korra, lähedal päringu lõpule. Kui ma oleksin pidanud statistikat CTE-päringute kohta, mida ma ümber kirjutasin, siis enamik neist kuuluks sellesse kategooriasse. See aitab arendajatel kirjutada arusaadavat koodi, mis nüüd töötab veel kiiremini.

Veelgi enam, PostgreSQL 12 optimeerib SQL-i täitmist automaatselt, te ei pea midagi tegema. Ja kuigi nüüd on ilmselt mul vaja neid päringuid optimeerida, on tore, et PostgreSQL jätkab päringute optimeerimise kallal töötamist.

Just-in-Time (JIT) — nüüd vaikimisi

PostgreSQL 12 süsteemides, kus on tugi LLVM JIT-kompileerimine on vaikimisi lubatud. Esiteks saate toe JIT teatud sisemiste operatsioonide jaoks, ja teiseks saavad väljendid päringutes (lihtsaim näide — x + y) valikuloendis (mis on teie SELECT-i järel), agregaatide, WHERE-lause väljendite ja muude jaoks kasutada JIT-i jõudluse suurendamiseks.

Kuna JIT on PostgreSQL 12-s vaikimisi lubatud, paranenud jõudlus, kuid soovitan testida rakendust PostgreSQL 11-s, kus JIT alles ilmus, et mõõta päringute jõudlust ja teada saada, kas midagi peab seadistama.

Aga mis on PostgreSQL 12 muud uued funktsioonid?

PostgreSQL 12-s on hulgaliselt uusi toredaid funktsioone — alates võimalusest uurida JSON-andmeid standardsete SQL/JSON marsruutimise väljendite abil kuni mitme teguri autentimiseni parameetriga clientcert=verify-full, genereeritud veergude ja muu hulga asjadeni. Sellega jätkub ühte postitust.

Nagu PostgreSQL 10, suurendab PostgreSQL 12 üldist jõudlust kohe pärast uuendamist. Teil võib loomulikult olla oma tee — testige rakendust sarnastes tingimustes tootmisüsteemis, enne kui aktiveerite täiustused, nagu tegin mina PostgreSQL 10-ga. Isegi kui PostgreSQL 12 on juba praegu stabiilsem, kui ma ette kujutasin, ärge laske laisel testida rakendusi kvaliteetselt, enne kui need tootmisse viia.

Allikas: habr.com