Mugandused laiskadele: kuidas PostgreSQL 12 tõstab jõudlust

PostgreSQL 12, viimane versioon "parimast avatud lähtekoodiga relatsioonilisest andmebaasist maailmas" ilmub paar nädalat (kui kõik läheb plaanipäraselt). See vastab tavapärasele graafikule — uus versioon, kus on hulgaliselt uusi võimalusi, ilmub kord aastas, ja ausalt öeldes, see on muljetavaldav. Seetõttu olen mina ka aktiivne PostgreSQL kogukonna liige.

Minu arvates, erinevalt eelmiste väljaannetest, ei sisalda PostgreSQL 12 ühtegi revolutsioonilist funktsiooni (nagu näiteks sektsioonimine või päringute paralleelne töötlemine). Ma naljatasin kunagi, et PostgreSQL 12 peamine eelis on suurem stabiilsus. Kas just seda ei vajata, kui hallatakse teie äri kriitilisi andmeid?

Aga PostgreSQL 12 ei piirdu sellega: uute võimaluste ja täiustustega töötavad rakendused paremini, ja teie peate lihtsalt uuendama!

(Noh, võib-olla tuleb veel indeksid uuesti üles ehitada, kuid käesolevas väljalaskes ei ole see nii hirmutav, kui oleme harjunud.)

Oleks, et oleks suurepärane — uuendada PostgreSQL-i ja nautida kohe märkimisväärseid parandusi ilma liigsete pingutusteta. Mõned aastad tagasi analüüsisin värskendust PostgreSQL 9.4 versioonilt PostgreSQL 10-le ning nägin, kui palju kiirus paraneb tänu parematele päringute paralleelsusele PostgreSQL 10-s. Ja mis kõige tähtsam, see ei nõudnud minult peaaegu midagi (sain lihtsalt määrata konfiguratsiooniparametri max_parallel_workers).

Olge nõus, et on mugav, kui rakendused hakkavad pärast värskendamist kohe paremini toimima. Me pingutame tõeliselt, et kasutajaid rõõmustada, sest PostgreSQL-i kasutajad kasvavad järjest rohkem.

Ja kuidas lihtne uuendus PostgreSQL 12-le teid õnnelikuks teeb? Selgitan nüüd.

Olulised edusammud indekseerimises

Ilma indekseerimiseta ei pääse andmebaas kaugele. Kuidas muidu kiiresti teavet leida? PostgreSQL-i põhistatistika süsteem on B-puu. See indeksitüüp on optimeeritud salvestussüsteemide jaoks.

Kasutame lihtsalt käsku CREATE INDEX ON some_table (some_column), ja PostgreSQL teeb suure osa tööst, et indeks oleks ajakohane, kui me pidevalt väärtusi sisestame, uuendame ja eemaldame. Kõik toimib iseeneslikult, justkui nõia väel.

Entretanto, PostgreSQL indeksid on üks probleem — need paisuvad ning võtavad kõvakettal liigset ruumi, mis vähendab andmete väljatoomise ja värskendamise jõudlust. „Paisumise” all mõistan ma indeksistruktuuri mitteefektiivset hoidmist. See võib olla — või ei pruugi — seotud rämpskandidaatidega, mida eemaldab VACUUM (tänu Peter Geogheganile (Peter Geoghegan)). Indeksi paisumine on eriti silmatorkav töökoormustes, kus indeks muutub aktiivselt.

PostgreSQL 12 parandab oluliselt B-puu indeksite toimimist ning TPC-C testide eksperimendid on näidanud, et ruumi kasutatakse nüüd keskmiselt 40% vähem. Kulutame nüüd vähem aega mitte ainult B-puu indeksite hooldamiseks (st kirjutamisoperatsioonideks), vaid ka andmete väljatoomiseks, kuna indeksid on oluliselt väiksemad.

Rakendused, mis aktiivselt uuendavad oma tabeleid — tavaliselt OLTP rakendused (reaalajas tehingute töötlemine) — kasutavad ketast palju tõhusamalt ja töötlevad päringud. Mida rohkem on kettal ruumi, seda rohkem on andmebaasil kasvuruumi ilma infrastruktuuri uuendamata.

Mõned uuendamisstrateegiad vajavad B-puu indeksite ümberkujundamist, et neid eeliseid maksimaalselt ära kasutada (näiteks, pg_upgrade ei ehita indekseid automaatselt). Varasemates PostgreSQL versioonides suurte indeksite ümbertegemine tabelites põhjustas suure üldseisaku, kuna sel ajal ei saanud andmeid muuta. Kuid PostgreSQL 12-l on veel üks suurepärane omadus: nüüd saab indekseid üheaegselt uuendada käsuga REINDEX CONCURRENTLY, et täielikult vältida seisakut.

PostgreSQL 12-l on ka teisi indekseerimise infrastruktuuri täiustusi. Veel üks asi, kus ei saanud ilma võlujõuta, on eelmise kirje päevik, tuntud ka kui WAL (write-ahead log). Eelmise kirje päevik salvestab iga tehingu PostgreSQL-is, et ette valmistada tõrke ja taastumise korral. Rakendused kasutavad seda arhiveerimiseks ja teatud hetke taastamiseks. Loomulikult kirjutatakse eelmise kirje päevik kettale, mis võib mõjutada jõudlust.

PostgreSQL 12-s vähendati WAL-salvestuste kulu, mida loomise indeksite GiST, GIN ja SP-GiST käigus tekitatakse. See pakub mitmeid märgatavaid eeliseid: WAL-salvestused võtavad vähem ketas ruumi ja andmete taastamine toimub kiiremini, näiteks tõrke taastamise või ajaprogrammi taastamise ajal. Kui kasutate neid indekseid oma rakendustes (näiteks geograafilised rakendused, mis põhinevad PostGIS-il, kasutavad GiST-indeksit laialdaselt), on see veel üks funktsioon, mis parandab teie töö efektiivsust ilma lisapingutusteta.

Sektsioonimine — rohkem, parem, kiirem

PostgreSQL 10-s lisandus deklaratiivne sektsioonimine. PostgreSQL 11-s on see palju lihtsam kasutada. PostgreSQL 12-s on võimalik sektsioonide skaalat muuta.

PostgreSQL 12-s suutlikkus sektsioonimise osas on oluliselt paranenud, eriti kui tabelis on tuhandeid sektsioone. Näiteks kui päring hõlmab vaid mõningaid sektsioone tabelis, kus neid on tuhandeid, täidetakse see palju kiiremini. Suutlikkuse parandus ei piirdu ainult selliste päringutega. Samuti märkate, kui kiireks on muutunud INSERT operatsioonid tabelites, kus on palju sektsioone.

Andmete salvestamine COPY — muide, see on suurepärane viis masstestimise jaoks ja siin on näide JSON vastuvõtust — sektsioneeritud tabelitesse PostgreSQL 12-s on samuti muutunud tõhusamaks. COPY meetodi kasutamine oli juba kiire, kuid PostgreSQL 12-s on see täiesti uskumatu.

Nende eeliste tõttu saavad PostgreSQL-s salvestada veelgi suuremaid andmekogumeid, samas kui nende väljavõtmine on muutunud lihtsamaks. Ja te ei pea selle nimel pingutama. Kui teie rakendusel on palju sektsioone, näiteks kui see salvestab ajarekke, siis lihtne uuendus parandab selle jõudlust oluliselt.

Kuigi see täiendus ei kuulu just kategooriasse „üles tõstetud ja rõõmustame”, võimaldab PostgreSQL 12 luua välistäiendusi, mis viitavad sektsioonitud tabelitele, et sektsioonimisega töötamine oleks tõeline nauding.

WITH päringud on saanud palju paremaks.

Kui töötati välja täiendav patch sisseehitatud üldiste tabelite väljendite jaoks (need on CTE-d, need on WITH päringud), siis ei saanud ma oodata, et kirjutada artikkel sellest, kui rõõmsad olid arendajad koos PostgreSQL-iga. See on üks neist funktsioonidest, mis kiirendavad rakendust. Kui, muidugi, kasutate CTE-d.

Ma olen sageli märganud, et SQL-i algajad armastavad CTE-sid kasutada: kui kirjutada need teatud viisil, tunned, et kirjutad imperatiivset programmi. Isiklikult meeldis mulle need päringud ümber kirjutada, et ilma jääda ilma CTE-dest ja suurendada jõudlust. Nüüd on kõik teisiti.

PostgreSQL 12 võimaldab mõningate CTE-de infrastruktuuri ilma kõrvalnähtudeta (SELECT), mida kasutatakse ainult üks kord päringu lõpus. Kui ma jälgiksin CTE päringute statistikat, siis enamik neist kuuluks sellesse kategooriasse. See aitab arendajatel kirjutada arusaadavat koodi, mis nüüd töötab veel kiiremini.

Lisaks sellele optimiseerib PostgreSQL 12 SQL-i teostust automaatselt, teil ei pea midagi tegema. Ja kuigi ilmselt ei pea ma enam selliseid päringuid optimeerima, on tore, et PostgreSQL jätkab päringute optimeerimisega töötamist.

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

PostgreSQL 12 süsteemides, mis toetavad LLVM JIT-kompileerimine on vaikimisi lubatud. Esiteks, te saate toe JIT mõnede sisemiste toimingute jaoks ning teiseks, väljenditega päringud (lihtsaim näide — x + y) valikuliste loendites (mis seisavad pärast SELECT), agregaatides, WHERE-haru väljendites ja muudes saavad JIT'i kasutada jõudluse parandamiseks.

Kui JIT on PostgreSQL 12 vaikimisi sisse lülitatud, paraneb jõudlus iseenesest, kuid soovitan testida rakendust PostgreSQL 11-s, kus JIT alles ilmus, et mõõta päringute jõudlust ja määrata, kas midagi vajab seadistamist.

Aga kuidas on teiste uute funktsioonidega PostgreSQL 12?

PostgreSQL 12-s on palju uusi lahedaid funktsioone - alates JSON andmete uurimise võimalusest standardsete SQL/JSON teekondade abil kuni mitme faktoriga autentimiseni parameetriga clientcert=verify-full, genereeritud veergude ja paljuga muuga. Selleks on vaja eraldi postitust.

Nagu PostgreSQL 10, tõstab PostgreSQL 12 ka pärast uuendust üldist jõudlust. Loomulikult võib teil olla oma lähenemine - testige rakendust sarnastes tingimustes tootmissüsteemis, enne kui lülitate sisse täiustused, nagu tegin mina PostgreSQL 10-ga. Isegi kui PostgreSQL 12 on juba praegu stabiilsem, kui ma eeldasin, ärge unustage kvalitatiivselt testida rakendusi, enne kui need tootmisse lähevad.

Allikas: habr.com