, de lêste ferzje fan "de wrâlds bêste iepen boarne relaasje databank," komt út yn in pear wiken (as alles giet neffens plan). Dit folget it gewoane skema fan it frijjaan fan in nije ferzje mei ien kear yn 't jier in ton nije funksjes, en earlik sein, dat is yndrukwekkend. Dêrom bin ik in aktyf lid wurden fan 'e PostgreSQL-mienskip.
Yn myn miening, yn tsjinstelling ta eardere releases, befettet PostgreSQL 12 gjin ien of twa revolúsjonêre funksjes (lykas partitioning of query parallelism). Ik haw ienris grapke dat it haadfunksje fan PostgreSQL 12 gruttere stabiliteit is. Is dat net wat jo nedich binne as jo de krityske gegevens fan jo bedriuw beheare?
Mar PostgreSQL 12 stopt dêr net: mei nije funksjes en ferbetteringen sille applikaasjes better prestearje, en alles wat jo hoege te dwaan is upgrade!
(No, miskien de yndeksen opnij opbouwe, mar yn dizze release is it net sa eng as wy wend binne.)
It sil geweldich wêze om PostgreSQL te upgrade en direkt genietsje fan signifikante ferbetteringen sûnder ûnnedige drokte. In pear jier lyn haw ik in upgrade fan PostgreSQL 9.4 nei PostgreSQL 10 besjoen en seach hoe't de applikaasje fersnelle troch it ferbettere query-parallelisme yn PostgreSQL 10. En, it wichtichste, wie hast neat fan my ferplicht (gewoan in konfiguraasjeparameter ynstelle max_parallel_workers).
Iens, it is handich as applikaasjes direkt nei in upgrade better wurkje. En wy besykje heul hurd om brûkers te behagen, om't PostgreSQL der hieltyd mear fan hat.
Dus hoe kin in ienfâldige upgrade nei PostgreSQL 12 jo bliid meitsje? Ik sil it dy no sizze.
Grutte yndeksearjende ferbetterings
Sûnder yndeksearring sil in databank net fier gean. Hoe kinne jo oars fluch ynformaasje fine? It fûnemintele yndeksearringsysteem fan PostgreSQL wurdt neamd . Dit type yndeks is optimalisearre foar opslachsystemen.
Wy brûke gewoan de operator CREATE INDEX ON some_table (some_column), en PostgreSQL docht in protte wurk om de yndeks by de tiid te hâlden wylst wy konstant wearden ynfoegje, bywurkje en wiskje. Alles wurket op himsels, as by magy.
Mar PostgreSQL-yndeksen hawwe ien probleem - se en nimme up ekstra skiif romte en ferminderje de prestaasjes fan gegevens opheljen en fernijing. Mei "bloat" bedoel ik it net effektyf behâld fan de yndeksstruktuer. Dit kin - of miskien net - relatearre wurde oan de jiskefet dy't it ferwideret (mei tank oan Peter Gaghan foar de ynformaasje))). Yndeksbloat is benammen te merken yn wurkloads wêr't de yndeks aktyf feroaret.
PostgreSQL 12 ferbetteret de prestaasjes fan B-beam-yndeksen sterk, en eksperiminten mei benchmarks lykas TPC-C hawwe sjen litten dat no gemiddeld 40% minder romte brûkt wurdt. No besteegje wy minder tiid net allinnich oan it behâld fan B-beam-yndeksen (dat is oan skriuwoperaasjes), mar ek oan it opheljen fan gegevens, om't de yndeksen folle lytser binne.
Applikaasjes dy't har tabellen aktyf bywurkje - typysk OLTP-applikaasjes () - sil skiif brûke en fersiken folle effisjinter ferwurkje. Hoe mear skiifromte, hoe mear romte de databank moat groeie sûnder de ynfrastruktuer te ferbetterjen.
Guon upgradestrategyen fereaskje it opbouwen fan B-beam-yndeksen om te profitearjen fan dizze foardielen (bgl. sil yndeksen net automatysk opnij opbouwe). Yn eardere ferzjes fan PostgreSQL resultearre it opnij opbouwen fan grutte yndeksen op tabellen yn signifikante downtime, om't feroaringen yn 'e tuskentiid net makke wurde kinne. Mar PostgreSQL 12 hat in oare koele funksje: no kinne jo yndeksen opnij opbouwe parallel mei it kommando om downtime folslein te foarkommen.
D'r binne oare ferbetteringen oan 'e yndeksearjende ynfrastruktuer yn PostgreSQL 12. In oar ding wêr't wat magy wie - , aka WAL (foarôf skriuwe log). In skriuw-foarút-log registrearret elke transaksje yn PostgreSQL yn gefal fan mislearring en replikaasje. Applikaasjes brûke it foar argivearjen en . Fansels wurdt it write-ahead-logboek op skiif skreaun, wat de prestaasjes kin beynfloedzje.
PostgreSQL 12 hat de overhead fan WAL-records fermindere dy't wurde makke troch de GiST-, GIN- en SP-GiST-yndeksen tidens yndekskonstruksje. Dit soarget foar ferskate taastbere foardielen: WAL-records nimme minder skiifromte yn, en gegevens wurde rapper ôfspile, lykas by rampherstel of punt-yn-tiid herstel. As jo soksoarte yndeksen brûke yn jo applikaasjes (bygelyks PostGIS-basearre geospatiale applikaasjes brûke de GiST-yndeks in protte), is dit in oare funksje dy't de ûnderfining signifikant sil ferbetterje sûnder ynspanning fan jo kant.
Partitioning - grutter, better, flugger
PostgreSQL 10 yntrodusearre . Yn PostgreSQL 11 is it folle makliker wurden te brûken. Yn PostgreSQL 12 kinne jo de skaal fan seksjes feroarje.
Yn PostgreSQL 12 is de prestaasjes fan it partitioneringssysteem signifikant better wurden, benammen as d'r tûzenen partysjes yn 'e tabel binne. As in query bygelyks mar in pear partysjes yn in tabel mei tûzenen beynfloedet, sil it folle flugger útfiere. Prestaasjes wurde net allinich ferbettere foar dizze soarten fragen. Jo sille ek merke hoe rapper INSERT-operaasjes binne op tabellen mei meardere partysjes.
Recording gegevens mei help fan - Trouwens, dit is in geweldige manier en hjir is in foarbyld - ferdielde tabellen yn PostgreSQL 12 binne ek effisjinter wurden. Mei COPY wie alles al fluch, mar yn PostgreSQL 12 fljocht it absolút.
Mei tank oan dizze foardielen kinne PostgreSQL jo noch gruttere datasets opslaan en makliker meitsje om se werom te heljen. En gjin ynspanning fan jo kant. As de applikaasje in protte partysjes hat, lykas it opnimmen fan tiidseriegegevens, sil in ienfâldige upgrade har prestaasjes signifikant ferbetterje.
Hoewol dit net krekt in "upgrade en genietsje" ferbettering is, lit PostgreSQL 12 jo bûtenlânske kaaien meitsje dy't ferwize nei partitioneare tabellen, wêrtroch partitionearjen in genot makket om mei te wurkjen.
WITH queries krekt wurden in stik better
Wannear (aka CTE, aka WITH queries), ik koe net wachtsje om in artikel oer te skriuwen . Dit is ien fan dy funksjes dy't de applikaasje sille fersnelle. Utsein as jo fansels CTE brûke.
Ik fyn faak dat newbies foar SQL graach CTE's brûke; as jo se op in bepaalde manier skriuwe, fielt it echt as jo in ymperatyf programma skriuwe. Persoanlik mocht ik dizze fragen oerskriuwe om rûn te kommen sûnder CTE en fergrutsjen produktiviteit. No is alles oars.
PostgreSQL 12 lit jo in spesifyk type CTE ynline sûnder side-effekten (SELECT), dy't mar ien kear brûkt wurdt tichtby it ein fan it fersyk. As ik de CTE-fragen folgje dy't ik opnij skreau, soene de measten yn dizze kategory falle. Dit helpt ûntwikkelders dúdlike koade te skriuwen dy't no ek fluch rint.
Boppedat optimisearret PostgreSQL 12 SQL-útfiering sels, sûnder dat jo wat hoege te dwaan. En hoewol ik wierskynlik no sokke queries net hoege te optimalisearjen, is it geweldich dat PostgreSQL trochgiet te wurkjen oan query-optimalisaasje.
Just-in-Time (JIT) - no standert
Op PostgreSQL 12-systemen mei stipe JIT-kompilaasje is standert ynskeakele. Earst krije jo stipe foar guon ynterne operaasjes, en twad, queries mei útdrukkingen (it ienfâldichste foarbyld is x + y) yn selektearre listen (dy't jo hawwe nei SELECT), aggregates, útdrukkingen mei WHERE clauses en oaren kinne brûke JIT te ferbetterjen prestaasjes.
Sûnt JIT standert ynskeakele is yn PostgreSQL 12, sille prestaasjes op har eigen ferbetterje, mar ik advisearje de applikaasje te testen yn PostgreSQL 11, dy't JIT yntrodusearre, om query-prestaasjes te mjitten en te sjen as jo wat moatte ôfstimme.
Hoe sit it mei de rest fan 'e nije funksjes yn PostgreSQL 12?
PostgreSQL 12 hat in ton koele nije funksjes, fan 'e mooglikheid om JSON-gegevens te ûndersiikjen mei standert SQL / JSON-rûte-útdrukkingen oant multyfaktorautentikaasje mei in parameter clientcert=verify-full, oanmakke kolommen en folle mear. Genôch foar in aparte post.
Lykas PostgreSQL 10, sil PostgreSQL 12 de algemiene prestaasjes ferbetterje direkt nei de upgrade. Jo kinne fansels jo eigen paad hawwe - test de applikaasje ûnder ferlykbere omstannichheden op it produksjesysteem foardat jo ferbetteringen ynskeakelje, lykas ik dien mei PostgreSQL 10. Sels as PostgreSQL 12 al stabiler is as ik ferwachte, wês dan net lui yn testen applikaasjes yngeand, foardat se frijlitte yn produksje.
Boarne: www.habr.com