, die nuutste weergawe van "die wêreld se beste oopbron-relasionele databasis," kom oor 'n paar weke uit (as alles volgens plan verloop). Dit volg die gewone skedule van die vrystelling van 'n nuwe weergawe met 'n ton nuwe funksies een keer per jaar, en eerlik gesê, dit is indrukwekkend. Daarom het ek 'n aktiewe lid van die PostgreSQL-gemeenskap geword.
Na my mening, in teenstelling met vorige vrystellings, bevat PostgreSQL 12 nie een of twee revolusionêre kenmerke nie (soos partisionering of navraagparallellisme). Ek het eenkeer geskerts dat die hoofkenmerk van PostgreSQL 12 groter stabiliteit is. Is dit nie wat jy nodig het wanneer jy jou besigheid se kritieke data bestuur nie?
Maar PostgreSQL 12 stop nie daar nie: met nuwe kenmerke en verbeterings sal toepassings beter presteer, en al wat jy hoef te doen is om op te gradeer!
(Wel, herbou dalk die indekse, maar in hierdie uitgawe is dit nie so eng soos ons gewoond is nie.)
Dit sal wonderlik wees om PostgreSQL op te gradeer en onmiddellik aansienlike verbeterings te geniet sonder onnodige ophef. 'n Paar jaar gelede het ek 'n opgradering van PostgreSQL 9.4 na PostgreSQL 10 nagegaan en gesien hoe die toepassing versnel het danksy die verbeterde navraagparallelisme in PostgreSQL 10. En, die belangrikste, is amper niks van my vereis nie (stel net 'n konfigurasieparameter in max_parallel_workers).
Stem saam, dit is gerieflik wanneer toepassings onmiddellik na 'n opgradering beter werk. En ons probeer baie hard om gebruikers tevrede te stel, want PostgreSQL het meer en meer van hulle.
So hoe kan 'n eenvoudige opgradering na PostgreSQL 12 jou gelukkig maak? Ek sal jou nou vertel.
Groot indekseringsverbeterings
Sonder indeksering sal 'n databasis nie ver gaan nie. Hoe anders kan jy vinnig inligting vind? PostgreSQL se fundamentele indekseringstelsel word genoem . Hierdie tipe indeks is geoptimaliseer vir bergingstelsels.
Ons gebruik bloot die operateur CREATE INDEX ON some_table (some_column), en PostgreSQL doen baie werk om die indeks op datum te hou terwyl ons voortdurend waardes invoeg, opdateer en uitvee. Alles werk op sy eie, asof by towerkrag.
Maar PostgreSQL-indekse het een probleem - hulle en neem ekstra skyfspasie op en verminder die werkverrigting van dataherwinning en -opdatering. Met "opblaas" bedoel ek die oneffektiewe instandhouding van die indeksstruktuur. Dit kan - of mag nie - verband hou met die vullis-tupels wat dit verwyder (dankie aan Peter Gaghan vir die inligting))). Indeksopblaas is veral opvallend in werkladings waar die indeks aktief verander.
PostgreSQL 12 verbeter die werkverrigting van B-boom-indekse aansienlik, en eksperimente met maatstawwe soos TPC-C het getoon dat gemiddeld 40% minder spasie nou gebruik word. Nou spandeer ons minder tyd nie net aan die instandhouding van B-boom-indekse nie (dit wil sê aan skryfbewerkings), maar ook aan die herwinning van data, want die indekse is baie kleiner.
Toepassings wat hul tabelle aktief opdateer - tipies OLTP-toepassings () - sal skyf gebruik en versoeke baie meer doeltreffend verwerk. Hoe meer skyfspasie, hoe meer spasie het die databasis om te groei sonder om die infrastruktuur op te gradeer.
Sommige opgraderingstrategieë vereis die herbou van B-boom-indekse om voordeel te trek uit hierdie voordele (bv. sal nie indekse outomaties herbou nie). In vorige weergawes van PostgreSQL het die herbou van groot indekse op tabelle aansienlike stilstand tot gevolg gehad omdat veranderinge nie intussen aangebring kon word nie. Maar PostgreSQL 12 het nog 'n oulike kenmerk: nou kan u indekse parallel met die opdrag herbou om stilstand heeltemal te vermy.
Daar is ander verbeterings aan die indekseringsinfrastruktuur in PostgreSQL 12. Nog iets waar daar 'n bietjie magie was - , ook bekend as WAL (voorskryf-logboek). 'n Vooruitskryf-log teken elke transaksie in PostgreSQL aan in geval van mislukking en replikasie. Toepassings gebruik dit vir argivering en . Natuurlik word die voorskryf-logboek na skyf geskryf, wat prestasie kan beïnvloed.
PostgreSQL 12 het die bokoste van WAL-rekords wat deur die GiST-, GIN- en SP-GiST-indekse geskep word tydens indekskonstruksie verminder. Dit bied verskeie tasbare voordele: WAL-rekords neem minder skyfspasie op, en data word vinniger oorgespeel, soos tydens rampherstel of punt-in-tyd herstel. As jy sulke indekse in jou toepassings gebruik (byvoorbeeld, PostGIS-gebaseerde georuimtelike toepassings gebruik die GiST-indeks baie), is dit nog 'n kenmerk wat die ervaring aansienlik sal verbeter sonder enige moeite van jou kant.
Partisionering - groter, beter, vinniger
PostgreSQL 10 bekendgestel . In PostgreSQL 11 het dit baie makliker geword om te gebruik. In PostgreSQL 12 kan jy die skaal van afdelings verander.
In PostgreSQL 12 het die werkverrigting van die partisiestelsel aansienlik beter geword, veral as daar duisende partisies in die tabel is. Byvoorbeeld, as 'n navraag slegs 'n paar partisies in 'n tabel met duisende van hulle affekteer, sal dit baie vinniger uitgevoer word. Werkverrigting word nie net vir hierdie tipe navrae verbeter nie. Jy sal ook sien hoe vinniger INSERT-bewerkings is op tabelle met veelvuldige partisies.
Opname van data met behulp van - terloops, dit is 'n wonderlike manier en hier is 'n voorbeeld - gepartisioneerde tabelle in PostgreSQL 12 het ook meer doeltreffend geword. Met COPY was alles reeds vinnig, maar in PostgreSQL 12 vlieg dit absoluut.
Danksy hierdie voordele laat PostgreSQL jou toe om selfs groter datastelle te stoor en dit makliker te maak om te herwin. En geen moeite van jou kant af nie. As die toepassing baie partisies het, soos om tydreeksdata op te neem, sal 'n eenvoudige opgradering sy werkverrigting aansienlik verbeter.
Alhoewel dit nie juis 'n "opgradering en geniet" verbetering is nie, laat PostgreSQL 12 jou toe om vreemde sleutels te skep wat verwys na gepartisioneerde tabelle, wat partisionering 'n plesier maak om mee te werk.
MET navrae het net baie beter geword
Wanneer (ook bekend as CTE, aka MET navrae), kon ek nie wag om 'n artikel oor te skryf nie . Dit is een van daardie kenmerke wat die toepassing sal bespoedig. Tensy jy natuurlik CTE gebruik.
Ek vind dikwels dat nuwelinge in SQL daarvan hou om CTE's te gebruik; as jy dit op 'n sekere manier skryf, voel dit regtig asof jy 'n noodsaaklike program skryf. Persoonlik het ek daarvan gehou om hierdie navrae te herskryf om rond te kom sonder CTE en verhoog produktiwiteit. Nou is alles anders.
PostgreSQL 12 laat jou toe om 'n spesifieke tipe CTE sonder newe-effekte (SELECT), wat net een keer naby die einde van die versoek gebruik word. As ek tred gehou het met die CTE-navrae wat ek herskryf het, sou die meeste van hulle in hierdie kategorie val. Dit help ontwikkelaars om duidelike kode te skryf wat nou ook vinnig loop.
Boonop optimaliseer PostgreSQL 12 SQL-uitvoering self, sonder dat u iets hoef te doen. En alhoewel ek waarskynlik nie nou sulke navrae hoef te optimaliseer nie, is dit wonderlik dat PostgreSQL aanhou werk aan navraagoptimalisering.
Just-in-Time (JIT) - nou verstek
Op PostgreSQL 12-stelsels met ondersteuning JIT-samestelling is by verstek geaktiveer. Eerstens kry jy ondersteuning vir sommige interne bewerkings, en tweedens, navrae met uitdrukkings (die eenvoudigste voorbeeld is x + y) in kieslyste (wat jy na SELECT het), aggregate, uitdrukkings met WHERE-klousules en ander kan JIT gebruik om werkverrigting te verbeter.
Aangesien JIT by verstek in PostgreSQL 12 geaktiveer is, sal werkverrigting op sy eie verbeter, maar ek beveel aan om die toepassing in PostgreSQL 11, wat JIT bekendgestel het, te toets om navraagprestasie te meet en te kyk of jy iets moet instel.
Wat van die res van die nuwe funksies in PostgreSQL 12?
PostgreSQL 12 het 'n klomp oulike nuwe kenmerke, van die vermoë om JSON-data te ondersoek met behulp van standaard SQL/JSON-roete-uitdrukkings tot multi-faktor-verifikasie met 'n parameter clientcert=verify-full, geskep kolomme en nog baie meer. Genoeg vir 'n aparte pos.
Soos PostgreSQL 10, sal PostgreSQL 12 algehele werkverrigting onmiddellik na die opgradering verbeter. U kan natuurlik u eie pad hê - toets die toepassing onder soortgelyke toestande op die produksiestelsel voordat u verbeterings moontlik maak, soos ek met PostgreSQL 10 gedoen het. Selfs al is PostgreSQL 12 reeds meer stabiel as wat ek verwag het, moenie lui wees om te toets nie toedienings deeglik, voordat dit in produksie vrygestel word.
Bron: will.com