, naujausia „geriausios pasaulyje atvirojo kodo reliacinės duomenų bazės“ versija pasirodys po poros savaičių (jei viskas vyks pagal planą). Tai vyksta pagal įprastą tvarkaraštį, kai kartą per metus išleidžiama nauja versija su daugybe naujų funkcijų, ir, tiesą sakant, tai įspūdinga. Štai kodėl tapau aktyviu PostgreSQL bendruomenės nariu.
Mano nuomone, skirtingai nuo ankstesnių leidimų, PostgreSQL 12 neturi vienos ar dviejų revoliucinių funkcijų (pvz., skaidymo ar užklausos lygiagretumo). Kažkada juokavau, kad pagrindinė PostgreSQL 12 savybė yra didesnis stabilumas. Ar ne to reikia, kai tvarkote svarbiausius savo verslo duomenis?
Tačiau PostgreSQL 12 tuo nesibaigia: su naujomis funkcijomis ir patobulinimais programos veiks geriau, ir viskas, ką jums reikia padaryti, tai atnaujinti!
(Na, galbūt perkurkite indeksus, bet šiame leidime tai nėra taip baisu, kaip mes įpratę.)
Bus puiku atnaujinti PostgreSQL ir iškart mėgautis reikšmingais patobulinimais be nereikalingo šurmulio. Prieš keletą metų peržiūrėjau PostgreSQL 9.4 naujinimą į PostgreSQL 10 ir pamačiau, kaip programa paspartėjo dėl patobulinto užklausų lygiagretumo PostgreSQL 10. Ir, svarbiausia, iš manęs beveik nieko nereikėjo (tiesiog nustatykite konfigūracijos parametrą max_parallel_workers).
Sutikite, patogu, kai programos veikia geriau iškart po atnaujinimo. Ir mes labai stengiamės įtikti vartotojams, nes PostgreSQL jų turi vis daugiau.
Taigi, kaip paprastas atnaujinimas į PostgreSQL 12 gali padaryti jus laimingus? Aš tau pasakysiu dabar.
Pagrindiniai indeksavimo patobulinimai
Be indeksavimo duomenų bazė toli nenueis. Kaip dar galite greitai rasti informaciją? Pagrindinė PostgreSQL indeksavimo sistema vadinama . Šis indekso tipas yra optimizuotas saugojimo sistemoms.
Mes tiesiog naudojame operatorių CREATE INDEX ON some_table (some_column), o „PostgreSQL“ atlieka daug darbo, kad indeksas būtų atnaujintas, kol nuolat įterpiame, atnaujiname ir ištriname reikšmes. Viskas veikia savaime, tarsi burtų keliu.
Tačiau PostgreSQL indeksai turi vieną problemą – jie ir užima papildomos vietos diske bei sumažina duomenų gavimo ir atnaujinimo našumą. Sakydamas „išpūstas“ turiu omenyje neefektyvų indekso struktūros palaikymą. Tai gali būti (arba gali ne) būti susijusi su šiukšlėmis, kurias jis pašalina (ačiū Peteriui Gaghanui už informaciją))). Indekso išpūtimas ypač pastebimas darbo krūviuose, kai indeksas aktyviai keičiasi.
PostgreSQL 12 labai pagerina B-medžio indeksų našumą, o eksperimentai su etalonais, tokiais kaip TPC-C, parodė, kad dabar naudojama vidutiniškai 40 % mažiau vietos. Dabar mažiau laiko skiriame ne tik B-medžio indeksų priežiūrai (tai yra rašymo operacijoms), bet ir duomenų gavimui, nes indeksai yra daug mažesni.
Programos, kurios aktyviai atnaujina savo lenteles – paprastai OLTP programos () – naudos diską ir apdoros užklausas daug efektyviau. Kuo daugiau vietos diske, tuo daugiau vietos turi didėti duomenų bazė neatnaujinant infrastruktūros.
Norint pasinaudoti kai kuriomis naujovinimo strategijomis, reikia atkurti B-medžio indeksus, kad būtų galima pasinaudoti šiais pranašumais (pvz., automatiškai neatkurs indeksų). Ankstesnėse „PostgreSQL“ versijose atkuriant didelius lentelių indeksus buvo daug prastovų, nes per tą laiką nebuvo galima atlikti pakeitimų. Tačiau „PostgreSQL 12“ turi dar vieną puikią funkciją: dabar lygiagrečiai su komanda galite atkurti indeksus visiškai išvengti prastovų.
Yra ir kitų PostgreSQL 12 indeksavimo infrastruktūros patobulinimų. Kitas dalykas, kuriame buvo magija - , dar žinomas kaip WAL (iš anksto rašomas žurnalas). Išankstinio įrašymo žurnale įrašomos visos PostgreSQL operacijos gedimo ir replikacijos atveju. Programos jį naudoja archyvavimui ir . Žinoma, įrašymo į priekį žurnalas įrašomas į diską, o tai gali turėti įtakos našumui.
PostgreSQL 12 sumažino WAL įrašų, kuriuos sukuria GiST, GIN ir SP-GiST indeksai indekso kūrimo metu, pridėtinę vertę. Tai suteikia keletą apčiuopiamų pranašumų: WAL įrašai užima mažiau vietos diske, o duomenys atkuriami greičiau, pvz., atkūrimo metu arba atkūrimo momentu metu. Jei naudojate tokius indeksus savo programose (pavyzdžiui, PostGIS pagrindu veikiančios geoerdvinės programos dažnai naudoja GiST indeksą), tai yra dar viena funkcija, kuri žymiai pagerins patirtį be jokių jūsų pastangų.
Skirstymas – didesnis, geresnis, greitesnis
Pristatyta PostgreSQL 10 . PostgreSQL 11 tapo daug lengviau naudoti. „PostgreSQL 12“ galite pakeisti sekcijų mastelį.
„PostgreSQL 12“ skaidymo sistemos našumas tapo žymiai geresnis, ypač jei lentelėje yra tūkstančiai skaidinių. Pavyzdžiui, jei užklausa paveikia tik keletą skaidinių lentelėje, kurioje jų yra tūkstančiai, ji bus vykdoma daug greičiau. Šių tipų užklausų našumas ne tik pagerintas. Taip pat pastebėsite, kaip greitesnės INSERT operacijos yra lentelėse su keliais skaidiniais.
Duomenų įrašymas naudojant – beje, tai puikus būdas ir čia yra pavyzdys — „PostgreSQL 12“ padalintos lentelės taip pat tapo efektyvesnės. Su COPY viskas jau buvo greita, bet PostgreSQL 12 tai absoliučiai sklando.
Dėl šių pranašumų PostgreSQL leidžia saugoti dar didesnius duomenų rinkinius ir palengvinti jų atkūrimą. Ir be jūsų pastangų. Jei programa turi daug skaidinių, pavyzdžiui, įrašinėja laiko eilučių duomenis, paprastas atnaujinimas žymiai pagerins jos veikimą.
Nors tai nėra visiškai „atnaujinkite ir mėgaukitės“ patobulinimu, „PostgreSQL 12“ leidžia kurti išorinius raktus, nurodančius skaidytas lenteles, todėl skaidymas yra malonumas.
SU užklausomis tapo daug geriau
Kai (dar žinomas kaip CTE, dar žinomas kaip WITH queries), nekantravau parašyti straipsnį apie . Tai viena iš tų funkcijų, kurios pagreitins programos veikimą. Nebent, žinoma, naudojate CTE.
Dažnai pastebiu, kad SQL naujokai mėgsta naudoti CTE; jei rašote juos tam tikru būdu, tikrai atrodo, kad rašote būtiną programą. Asmeniškai man patiko perrašyti šias užklausas, kad galėčiau apeiti be CTE ir padidinti našumą. Dabar viskas kitaip.
„PostgreSQL 12“ leidžia įtraukti tam tikro tipo CTE be šalutinio poveikio (SELECT), kuris naudojamas tik vieną kartą pasibaigus užklausai. Jei stebėčiau CTE užklausas, kurias perrašiau, dauguma jų patektų į šią kategoriją. Tai padeda kūrėjams parašyti aiškų kodą, kuris dabar taip pat veikia greitai.
Be to, „PostgreSQL 12“ optimizuoja patį SQL vykdymą, jums nieko nereikia daryti. Ir nors man tikriausiai dabar nereikės optimizuoti tokių užklausų, puiku, kad PostgreSQL ir toliau dirba optimizuojant užklausas.
„Just-in-Time“ (JIT) – dabar numatytasis
PostgreSQL 12 sistemose su palaikymu JIT kompiliavimas įjungtas pagal numatytuosius nustatymus. Visų pirma, jūs gaunate paramą kai kurioms vidinėms operacijoms, antra, užklausos su išraiškomis (paprasčiausias pavyzdys yra x + y) pasirinktuose sąrašuose (kuriuos turite po SELECT), agregatai, išraiškos su WHERE sąlygomis ir kitos gali naudoti JIT, kad pagerintų našumą.
Kadangi JIT yra įjungtas pagal numatytuosius nustatymus „PostgreSQL 12“, našumas pagerės savaime, tačiau rekomenduoju išbandyti programą „PostgreSQL 11“, kuri pristatė JIT, kad būtų galima įvertinti užklausos našumą ir sužinoti, ar reikia ką nors suderinti.
O kaip su kitomis naujomis „PostgreSQL 12“ funkcijomis?
„PostgreSQL 12“ turi daugybę puikių naujų funkcijų: nuo galimybės tyrinėti JSON duomenis naudojant standartines SQL / JSON maršruto išraiškas iki kelių veiksnių autentifikavimo naudojant parametrą. clientcert=verify-full, sukurtų stulpelių ir daug daugiau. Užteks atskiram įrašui.
Kaip ir PostgreSQL 10, PostgreSQL 12 pagerins bendrą našumą iškart po atnaujinimo. Žinoma, jūs galite turėti savo kelią – prieš įjungdami patobulinimus išbandykite programą panašiomis sąlygomis gamybinėje sistemoje, kaip aš dariau su PostgreSQL 10. Net jei PostgreSQL 12 jau yra stabilesnis nei tikėjausi, nepatingėkite testuoti prieš išleidžiant jas į gamybą.
Šaltinis: www.habr.com