, "maailman parhaan avoimen lähdekoodin relaatiotietokannan" uusin versio ilmestyy muutaman viikon kuluttua (jos kaikki menee suunnitelmien mukaan). Tämä noudattaa tavallista aikataulua, jossa kerran vuodessa julkaistaan uusi versio, jossa on paljon uusia ominaisuuksia, ja suoraan sanottuna se on vaikuttavaa. Siksi minusta tuli aktiivinen jäsen PostgreSQL-yhteisössä.
Mielestäni, toisin kuin aikaisemmissa julkaisuissa, PostgreSQL 12 ei sisällä yhtä tai kahta vallankumouksellista ominaisuutta (kuten osiointi tai kyselyn rinnakkaisuus). Vitsailin kerran, että PostgreSQL 12:n pääominaisuus on suurempi vakaus. Eikö se ole se, mitä tarvitset, kun hallitset yrityksesi kriittisiä tietoja?
Mutta PostgreSQL 12 ei lopu tähän: uusien ominaisuuksien ja parannusten ansiosta sovellukset toimivat paremmin, ja sinun tarvitsee vain päivittää!
(No, ehkä rakentaa indeksit uudelleen, mutta tässä julkaisussa se ei ole niin pelottavaa kuin olemme tottuneet.)
On hienoa päivittää PostgreSQL ja nauttia välittömästi merkittävistä parannuksista ilman turhaa meteliä. Muutama vuosi sitten tarkistin päivityksen PostgreSQL 9.4:stä PostgreSQL 10:een ja näin, kuinka sovellus nopeutui PostgreSQL 10:n parannetun kyselyn rinnakkaisuuden ansiosta. Ja mikä tärkeintä, minulta ei vaadittu melkein mitään (asin vain määritysparametrin max_parallel_workers).
Hyväksy, se on kätevää, kun sovellukset toimivat paremmin heti päivityksen jälkeen. Ja yritämme kovasti miellyttää käyttäjiä, koska PostgreSQL:llä on niitä yhä enemmän.
Joten kuinka yksinkertainen päivitys PostgreSQL 12:een voi tehdä sinut onnelliseksi? Kerron sinulle nyt.
Merkittäviä indeksointiparannuksia
Ilman indeksointia tietokanta ei pääse pitkälle. Miten muuten löydät nopeasti tietoa? PostgreSQL:n perusindeksijärjestelmä on ns . Tämäntyyppinen indeksi on optimoitu tallennusjärjestelmille.
Käytämme vain operaattoria CREATE INDEX ON some_table (some_column), ja PostgreSQL tekee paljon työtä pitääkseen indeksin ajan tasalla, kun lisäämme, päivitämme ja poistamme jatkuvasti arvoja. Kaikki toimii itsestään, kuin taikuudesta.
Mutta PostgreSQL-indekseillä on yksi ongelma - ne ja vievät ylimääräistä levytilaa ja heikentävät tiedonhaun ja päivityksen suorituskykyä. "Paisuttamalla" tarkoitan indeksirakenteen tehotonta ylläpitämistä. Tämä voi - tai ei - liittyä roskakoriin, jotka se poistaa (kiitos Peter Gaghanille tiedosta))). Indeksin turvotus on erityisen havaittavissa työkuormissa, joissa indeksi muuttuu aktiivisesti.
PostgreSQL 12 parantaa huomattavasti B-puuindeksien suorituskykyä, ja kokeilut vertailuarvoilla, kuten TPC-C, ovat osoittaneet, että tilaa käytetään nyt keskimäärin 40 % vähemmän. Nyt käytämme vähemmän aikaa paitsi B-puu-indeksien ylläpitoon (eli kirjoitustoimintoihin), vaan myös tietojen hakemiseen, koska indeksit ovat paljon pienempiä.
Sovellukset, jotka päivittävät aktiivisesti taulukoitaan - tyypillisesti OLTP-sovellukset () - käyttää levyä ja käsittelee pyyntöjä paljon tehokkaammin. Mitä enemmän levytilaa, sitä enemmän tilaa tietokannassa on kasvaa ilman infrastruktuurin päivittämistä.
Jotkut päivitysstrategiat vaativat B-puun indeksien uudelleenrakentamisen näiden etujen hyödyntämiseksi (esim. ei rakenna indeksejä automaattisesti uudelleen). Aiemmissa PostgreSQL-versioissa suurten indeksien uudelleenrakentaminen taulukoihin johti merkittäviin seisokkeihin, koska muutoksia ei voitu tehdä sillä välin. Mutta PostgreSQL 12:ssa on toinen hieno ominaisuus: nyt voit rakentaa indeksejä uudelleen rinnakkain komennon kanssa seisokkien välttämiseksi kokonaan.
PostgreSQL 12:n indeksointiinfrastruktuuriin on muitakin parannuksia. Toinen asia, jossa oli taikuutta - , eli WAL (kirjoitettava loki). Eteenpäinkirjoitettava loki tallentaa kaikki PostgreSQL-tapahtumat epäonnistumisen ja replikoinnin varalta. Sovellukset käyttävät sitä arkistointiin ja . Tietenkin eteenpäinkirjoitusloki kirjoitetaan levylle, mikä voi vaikuttaa suorituskykyyn.
PostgreSQL 12 on vähentänyt GiST-, GIN- ja SP-GiST-indeksien luomien WAL-tietueiden lisäkustannuksia indeksin rakentamisen aikana. Tämä tarjoaa useita konkreettisia etuja: WAL-tietueet vievät vähemmän levytilaa ja tiedot toistetaan nopeammin, kuten katastrofipalautuksen tai ajankohtaisen palautuksen aikana. Jos käytät tällaisia indeksejä sovelluksissasi (esimerkiksi PostGIS-pohjaiset geospatiaaliset sovellukset käyttävät paljon GiST-indeksiä), tämä on toinen ominaisuus, joka parantaa käyttökokemusta merkittävästi ilman sinun vaivannäköäsi.
Osiointi – isompi, parempi, nopeampi
PostgreSQL 10 esitelty . PostgreSQL 11:ssä siitä on tullut paljon helpompi käyttää. PostgreSQL 12:ssa voit muuttaa osien mittakaavaa.
PostgreSQL 12:ssa osiointijärjestelmän suorituskyky on parantunut huomattavasti, varsinkin jos taulukossa on tuhansia osioita. Esimerkiksi, jos kysely vaikuttaa vain muutamaan osioon taulukossa, jossa on tuhansia niitä, se suoritetaan paljon nopeammin. Suorituskyky ei vain parane tämäntyyppisissä kyselyissä. Huomaat myös, kuinka nopeampia INSERT-toiminnot ovat taulukoissa, joissa on useita osioita.
Tietojen tallennus käyttämällä - Muuten, tämä on loistava tapa ja tässä esimerkki — Myös osioidut taulukot PostgreSQL 12:ssa ovat tehostuneet. COPY:lla kaikki oli jo nopeaa, mutta PostgreSQL 12:ssa se lentää ehdottomasti.
Näiden etujen ansiosta PostgreSQL mahdollistaa entistä suurempien tietojoukkojen tallentamisen ja helpottaa niiden hakemista. Eikä ponnistelujasi. Jos sovelluksessa on useita osioita, kuten aikasarjatietojen tallennus, yksinkertainen päivitys parantaa merkittävästi sen suorituskykyä.
Vaikka tämä ei olekaan "päivitä ja nauti" -parannuksesta, PostgreSQL 12:n avulla voit luoda vierasavaimia, jotka viittaavat osioituihin taulukoihin, mikä tekee osioista miellyttävän työskennellä.
KYSYMYKSIÄ parani juuri paljon
Kun (alias CTE, eli WITH kyselyt), en malttanut odottaa, että pääsen kirjoittamaan artikkelin aiheesta . Tämä on yksi niistä ominaisuuksista, jotka nopeuttavat sovellusta. Ellei tietenkään käytä CTE:tä.
Huomaan usein, että SQL-aloittelijat rakastavat CTE:iden käyttöä; jos kirjoitat ne tietyllä tavalla, tuntuu todella siltä, että kirjoitat pakollista ohjelmaa. Henkilökohtaisesti pidin näiden kyselyjen kirjoittamisesta uudelleen kiertääkseni без CTE ja lisää tuottavuutta. Nyt kaikki on toisin.
PostgreSQL 12 mahdollistaa tietyn tyyppisen CTE:n lisäämisen ilman sivuvaikutuksia (SELECT), jota käytetään vain kerran pyynnön lopussa. Jos seuraisin uudelleen kirjoittamiani CTE-kyselyitä, useimmat niistä kuuluisivat tähän luokkaan. Tämä auttaa kehittäjiä kirjoittamaan selkeää koodia, joka nyt myös toimii nopeasti.
Lisäksi PostgreSQL 12 optimoi SQL:n suorittamisen itse ilman, että sinun tarvitsee tehdä mitään. Ja vaikka minun ei luultavasti tarvitse optimoida tällaisia kyselyitä nyt, on hienoa, että PostgreSQL jatkaa kyselyn optimointia.
Just-in-Time (JIT) - nyt oletusarvo
PostgreSQL 12 -järjestelmissä tuella JIT-käännös on oletuksena käytössä. Ensinnäkin saat tukea Joillekin sisäisille operaatioille, ja toiseksi, kyselyt lausekkeilla (yksinkertaisin esimerkki on x + y) valintaluetteloissa (jotka sinulla on SELECT:n jälkeen), aggregaatit, lausekkeet WHERE-lauseilla ja muut voivat käyttää JIT:tä suorituskyvyn parantamiseen.
Koska JIT on oletuksena käytössä PostgreSQL 12:ssa, suorituskyky paranee itsestään, mutta suosittelen testaamaan sovelluksen PostgreSQL 11:ssä, joka esitteli JIT:n, jotta voit mitata kyselyn suorituskykyä ja tarkistaa, tarvitsetko virittää jotain.
Entä muut PostgreSQL 12:n uudet ominaisuudet?
PostgreSQL 12:ssa on paljon hienoja uusia ominaisuuksia, aina mahdollisuudesta tutkia JSON-tietoja tavallisten SQL/JSON-reittilausekkeiden avulla monitekijäiseen todennukseen parametrilla. clientcert=verify-full, loi sarakkeita ja paljon muuta. Riittää erilliseen postaukseen.
Kuten PostgreSQL 10, PostgreSQL 12 parantaa yleistä suorituskykyä välittömästi päivityksen jälkeen. Sinulla voi tietysti olla oma polkusi - testaa sovellusta samanlaisissa olosuhteissa tuotantojärjestelmässä ennen parannusten mahdollistamista, kuten tein PostgreSQL 10:n kanssa. Vaikka PostgreSQL 12 olisikin jo vakaampi kuin odotin, älä ole laiska testaamassa sovellukset perusteellisesti ennen niiden julkaisua tuotantoon.
Lähde: will.com