, “maailma parima avatud lähtekoodiga relatsiooniandmebaasi” uusim versioon tuleb välja paari nädala pärast (kui kõik läheb plaanipäraselt). See järgib tavapärast ajakava, mille kohaselt antakse kord aastas välja palju uusi funktsioone sisaldav uus versioon, ja ausalt öeldes on see muljetavaldav. Seetõttu sai minust PostgreSQL kogukonna aktiivne liige.
Minu arvates, erinevalt eelmistest väljaannetest, ei sisalda PostgreSQL 12 üht või kahte revolutsioonilist funktsiooni (nt partitsioonide jaotamine või päringu paralleelsus). Kunagi tegin nalja, et PostgreSQL 12 peamine omadus on suurem stabiilsus. Kas pole see see, mida te ei vaja oma ettevõtte kriitiliste andmete haldamisel?
Kuid PostgreSQL 12 ei piirdu sellega: uute funktsioonide ja täiustustega töötavad rakendused paremini, ja kõik, mida pead tegema, on uuendada!
(Noh, võib-olla taastage indeksid, kuid selles versioonis pole see nii hirmutav, kui oleme harjunud.)
Tore on PostgreSQL-i uuendada ja nautida kohe olulisi täiustusi ilma tarbetu askeldamiseta. Mõned aastad tagasi vaatasin üle PostgreSQL 9.4 versiooniuuenduse versioonile PostgreSQL 10 ja nägin, kuidas rakendus tänu PostgreSQL 10 täiustatud päringute paralleelsusele kiirendas. Ja mis kõige tähtsam, minult ei nõutud peaaegu midagi (seadistasin lihtsalt konfiguratsiooniparameetri max_parallel_workers).
Nõus, see on mugav, kui rakendused töötavad paremini kohe pärast täiendamist. Ja me püüame väga kasutajatele meeldida, sest PostgreSQL-is on neid aina rohkem.
Kuidas saab lihtne PostgreSQL 12 versiooniuuendus teid õnnelikuks teha? ma ütlen sulle kohe.
Suured indekseerimise täiustused
Ilma indekseerimiseta ei jõua andmebaas kaugele. Kuidas muidu kiiresti teavet leida? PostgreSQL-i põhilist indekseerimissüsteemi nimetatakse . Seda tüüpi indeks on optimeeritud salvestussüsteemide jaoks.
Kasutame lihtsalt operaatorit CREATE INDEX ON some_table (some_column), ja PostgreSQL teeb palju tööd, et hoida indeks ajakohasena, samal ajal kui me pidevalt väärtusi sisestame, värskendame ja kustutame. Kõik toimib justkui võluväel iseenesest.
Kuid PostgreSQL-i indeksitel on üks probleem – nemad ja võtavad täiendavat kettaruumi ning vähendavad andmete otsimise ja värskendamise jõudlust. "Paistetuse" all pean silmas indeksi struktuuri ebaefektiivset säilitamist. See võib – aga ei pruugi – olla seotud prügikortsudega, mille see eemaldab (aitäh Peter Gaghanile teabe eest))). Indeksi paisumine on eriti märgatav töökoormustes, kus indeks on aktiivselt muutumas.
PostgreSQL 12 parandab oluliselt B-puu indeksite jõudlust ja katsed võrdlusalustega nagu TPC-C on näidanud, et praegu kasutatakse keskmiselt 40% vähem ruumi. Nüüd kulutame vähem aega mitte ainult B-puu indeksite hooldamisele (st kirjutamisoperatsioonidele), vaid ka andmete hankimisele, kuna indeksid on palju väiksemad.
Rakendused, mis värskendavad aktiivselt oma tabeleid – tavaliselt OLTP-rakendused () - kasutab ketast ja töötleb päringuid palju tõhusamalt. Mida rohkem kettaruumi, seda rohkem ruumi peab andmebaas ilma infrastruktuuri uuendamata kasvama.
Mõned uuendusstrateegiad nõuavad B-puu indeksite taastamist, et neid eeliseid kasutada (nt. ei taasta indekseid automaatselt). PostgreSQL-i eelmistes versioonides põhjustas tabelites suurte indeksite ümberehitamine märkimisväärse seisaku, kuna vahepeal ei saanud muudatusi teha. Kuid PostgreSQL 12-l on veel üks lahe funktsioon: nüüd saate käsuga paralleelselt indekseid uuesti üles ehitada seisakuid täielikult vältida.
PostgreSQL 12 indekseerimisinfrastruktuuris on muid täiustusi. Teine asi, kus oli maagiat - , ehk WAL (ette kirjutatav logi). Ettekirjutamise logi salvestab kõik PostgreSQL-i tehingud ebaõnnestumise ja replikatsiooni korral. Rakendused kasutavad seda arhiveerimiseks ja . Loomulikult kirjutatakse ettekirjutamise logi kettale, mis võib jõudlust mõjutada.
PostgreSQL 12 on vähendanud indeksi koostamise käigus GiST, GIN ja SP-GiST indeksite poolt loodud WAL-kirjete üldkulusid. See annab mitmeid käegakatsutavaid eeliseid: WAL-kirjed võtavad vähem kettaruumi ja andmeid taasesitatakse kiiremini, näiteks avariitaaste või ajakohase taastamise ajal. Kui kasutate oma rakendustes selliseid indekseid (näiteks PostGIS-põhised georuumilised rakendused kasutavad palju GiST-indeksit), on see veel üks funktsioon, mis parandab oluliselt kogemust ilma teiepoolse pingutuseta.
Partitsioneerimine – suurem, parem, kiirem
Tutvustatakse PostgreSQL 10 . PostgreSQL 11-s on selle kasutamine muutunud palju lihtsamaks. PostgreSQL 12-s saate sektsioonide skaalat muuta.
PostgreSQL 12-s on partitsioonisüsteemi jõudlus muutunud oluliselt paremaks, eriti kui tabelis on tuhandeid sektsioone. Näiteks kui päring mõjutab tuhandete partitsioonidega tabelis vaid mõnda partitsiooni, käivitub see palju kiiremini. Toimivus ei parane ainult seda tüüpi päringute puhul. Samuti märkate, kui kiiremad on INSERT-i toimingud mitme partitsiooniga tabelites.
Andmete salvestamine kasutades - muide, see on suurepärane viis ja siin on näide — ka PostgreSQL 12 partitsioonitabelid on muutunud tõhusamaks. COPY-ga oli kõik juba kiire, kuid PostgreSQL 12-s lendab see absoluutselt.
Tänu nendele eelistele võimaldab PostgreSQL salvestada veelgi suuremaid andmekogumeid ja hõlbustada nende hankimist. Ja ei mingit pingutust teie poolt. Kui rakendusel on palju sektsioone, näiteks aegridade andmete salvestamine, parandab lihtne täiendus selle jõudlust oluliselt.
Kuigi see pole just "täiendage ja nautige" täiustust, võimaldab PostgreSQL 12 teil luua võõrvõtmeid, mis viitavad partitsioonitud tabelitele, muutes partitsioonidega töötamise nauditavaks.
WITH päringutega läks just palju paremaks
Millal (teise nimega CTE, teise nimega WITH päringutega), ei jõudnud ma oodata, millal saan sellest artiklit kirjutada . See on üks funktsioonidest, mis kiirendab rakendust. Kui te muidugi CTE-d ei kasuta.
Ma avastan sageli, et SQL-i algajatele meeldib kasutada CTE-sid; kui kirjutate need teatud viisil, on tõesti tunne, et kirjutate hädavajalikku programmi. Mulle isiklikult meeldis neid päringuid ringi liikumiseks ümber kirjutada ilma CTE ja tõsta tootlikkust. Nüüd on kõik teisiti.
PostgreSQL 12 võimaldab teil lisada teatud tüüpi CTE-d ilma kõrvalmõjudeta (SELECT), mida kasutatakse päringu lõpus ainult üks kord. Kui ma jälgiksin CTE-päringuid, mille ümber kirjutasin, kuuluks enamik neist sellesse kategooriasse. See aitab arendajatel kirjutada selget koodi, mis nüüd ka kiiresti töötab.
Lisaks optimeerib PostgreSQL 12 SQL-i täitmist ise, ilma et peaksite midagi tegema. Ja kuigi ma ilmselt ei pea praegu selliseid päringuid optimeerima, on tore, et PostgreSQL jätkab tööd päringu optimeerimisega.
Just-in-Time (JIT) – nüüd vaikimisi
Toega PostgreSQL 12 süsteemides JIT-i koostamine on vaikimisi lubatud. Esiteks saate toetust mõnede sisemiste operatsioonide jaoks ja teiseks võivad JIT-i jõudluse parandamiseks kasutada avaldistega päringud (lihtsaim näide on x + y) valitud loendites (mis teil on pärast SELECT), agregaadid, WHERE-klausliga avaldised ja teised.
Kuna JIT on PostgreSQL 12-s vaikimisi lubatud, paraneb jõudlus iseenesest, kuid soovitan testida rakendust versioonis PostgreSQL 11, mis juurutas JIT-i, et mõõta päringu jõudlust ja näha, kas teil on vaja midagi häälestada.
Kuidas on lood PostgreSQL 12 ülejäänud uute funktsioonidega?
PostgreSQL 12-l on palju lahedaid uusi funktsioone, alates võimalusest uurida JSON-andmeid standardsete SQL/JSON-marsruudiavaldiste abil kuni mitmefaktorilise autentimiseni parameetriga clientcert=verify-full, loodud veerge ja palju muud. Aitab eraldi postituseks.
Nagu PostgreSQL 10, parandab PostgreSQL 12 üldist jõudlust kohe pärast täiendamist. Muidugi võib teil olla oma tee – testige rakendust tootmissüsteemis sarnastel tingimustel enne parenduste lubamist, nagu ma tegin PostgreSQL 10 puhul. Isegi kui PostgreSQL 12 on juba stabiilsem, kui ma eeldasin, ärge olge testimisel laisk rakendusi põhjalikult enne nende tootmisse laskmist.
Allikas: www.habr.com