, versioni mĂ« e fundit e "bazĂ«s sĂ« tĂ« dhĂ«nave relacionale mĂ« tĂ« mirĂ« nĂ« botĂ« me burim tĂ« hapur" pritet tĂ« dalĂ« brenda disa javĂ«sh (nĂ«se gjithçka shkon sipas planit). Kjo Ă«shtĂ« nĂ« pĂ«rputhje me grafikun e zakonshĂ«m â njĂ« version i ri me shumĂ« mundĂ«si tĂ« reja del çdo vit, dhe, pĂ«r t'u thĂ«nĂ« tĂ« drejtĂ«n, kjo Ă«shtĂ« mbresĂ«lĂ«nĂ«se. Prandaj, unĂ« u bĂ«ra anĂ«tar aktiv i komunitetit PostgreSQL.
Sipas mendimit tim, ndryshe nga versionet e kaluara, PostgreSQL 12 nuk ka një ose dy funksione revolucionare (siç ishin ndarjet ose paralelizmi i kërkesave). Kam bërë një shaka se veçoria kryesore e PostgreSQL 12 është stabiliteti i përmirësuar. A nuk është kjo ajo që na nevojitet kur menaxhojmë të dhëna kritikë për biznesin tuaj?
Por PostgreSQL 12 nuk ndalet këtu: me mundësi dhe përmirësime të reja, aplikacionet do të funksionojnë më mirë, dhe ju nevojitet vetëm një përmirësim!
(Epo, ndoshta edhe ndonjë indeks të ri, por në këtë version kjo nuk është aq e frikshme siç jemi mësuar.)
Do të jetë fantastike të përmirësojmë PostgreSQL dhe menjëherë të shijojmë përmirësime të mëdha pa shumë shqetësime. Disa vjet më parë analizova përditësimin nga PostgreSQL 9.4 në PostgreSQL 10 dhe pashë se si aplikacioni u përshpejtua për shkak të përmirësimit të paralelizmit të kërkesave në PostgreSQL 10. Dhe, më e rëndësishmja, nga unë kërkohej pothuajse asgjë (vetëm të vendosja parametrin e konfigurimit max_parallel_workers).
Pranoni se është e rehatshme kur menjëherë pas përmirësimit aplikacionet funksionojnë më mirë. Ne punojmë shumë për të kënaqur përdoruesit, pasi PostgreSQL ka gjithnjë e më shumë të tillë.
Dhe si papërmirësimi i thjeshtë në PostgreSQL 12 do t'ju bëjë të lumtur? Tani do ta shpjegoj.
Përmirësime të rëndësishme në indeksim
Pa indeksim, një bazë të dhënash nuk do të arrijë shumë larg. Si mund të gjejmë informacionin shpejt? Sistemi themelor i indeksimit në PostgreSQL quhet . Ky lloj indeksi është optimizuar për sistemet e ruajtjes.
Thjesht përdorim operatorin CREATE INDEX ON some_table (some_column), dhe PostgreSQL bën shumë punë për të mbajtur indeksin të azhurnuar gjatë gjithë kohës që ne vazhdimisht futim, azhurnojmë dhe fshijmë vlera. Të gjitha funksionon vetë, si me magji.
Por indekset e PostgreSQL kanĂ« njĂ« problem â ato dhe zĂ«nĂ« hapĂ«sirĂ« tĂ« tepĂ«rt nĂ« disk, çka ul performancĂ«n e nxjerrjes dhe pĂ«rditĂ«simit tĂ« tĂ« dhĂ«nave. NĂ«n "fryrje" kuptoj njĂ« mbajtje tĂ« paefektshme tĂ« strukturĂ«s sĂ« indeksit. Kjo mund tĂ« lidhet me tuprat e mbeturina, qĂ« fshihen nga (faleminderit pĂ«r informacionin Peter Geoghegan ()). Fryrja e indeksit Ă«shtĂ« veçanĂ«risht e dukshme nĂ« ngarkesat e punĂ«s ku indeksi ndryshohet aktivisht.
PostgreSQL 12 përmirëson ndjeshëm performancën e indekseve B-tree, dhe eksperimentet me testet si TPC-C kanë treguar se tani përdoret, mesatarisht, 40% më pak hapësirë. Tani ne shpenzojmë më pak kohë jo vetëm në mirëmbajtjen e indekseve B-tree (d.m.th., operacionet e shkruar), por edhe në nxjerrjen e të dhënave, pasi indekset janë bërë shumë më të vogla.
Aplikacionet qĂ« pĂ«rditĂ«sojnĂ« aktivisht tabelat e tyre â zakonisht kĂ«to janĂ« aplikacione OLTP () â do tĂ« pĂ«rdorin disku mĂ« efektivisht dhe do tĂ« pĂ«rpunojnĂ« kĂ«rkesat. Sa mĂ« shumĂ« hapĂ«sirĂ« qĂ« tĂ« ketĂ« nĂ« disk, aq mĂ« shumĂ« hapĂ«sirĂ« ka baza e tĂ« dhĂ«nave pĂ«r rritje pa pĂ«rmirĂ«simin e infrastrukturĂ«s.
Disa strategji përmirësimi kërkojnë të rindërtojmë indet B-tree për të shfrytëzuar këto përfitime (p.sh., nuk do t'i rindërtojë indet automatikisht). Në versionet e kaluara të PostgreSQL, rindërtimi i indekseve të mëdha në tabela shkaktonte një ndalim të madh, pasi në këtë kohë nuk mund të bënim ndryshime. Por në PostgreSQL 12 ka një veçori tjetër të shkëlqyer: tani mund të rindërtojmë indet paralelisht me komandën , për të shmangur ndalesat krejtësisht.
Në PostgreSQL 12 ka gjithashtu përmirësime të tjera në infrastrukturën e indeksimit. Një tjetër element ku nuk kishte mungesë të magjisë është , i njohur si WAL (write-ahead log). Jurnali i regjistrimit të parakohshëm regjistron çdo transaksion në PostgreSQL në rast dështimi dhe replikimi. Aplikacionet e përdorin atë për arkivimin dhe . Sigurisht, jurnali i regjistrimit të parakohshëm shkruhet në disk, dhe kjo mund të ketë një ndikim në performancën.
Në PostgreSQL 12, kostot e regjistrimeve WAL, të cilat krijohen nga indekset GiST, GIN dhe SP-GiST gjatë ndërtimit të indeksit, janë reduktuar. Kjo ofron disa përfitime të dukshme: regjistrimet WAL zënë më pak hapësirë në disk, dhe të dhënat riprodhohen më shpejt, për shembull, gjatë rikuperimit pas një dështimi ose rikuperimit në një moment të caktuar. Nëse përdorni këto indekse në aplikacionet tuaja (p.sh., aplikacionet gjeoprostranore që bazohen në PostGIS përdorin shumë indeksin GiST), kjo është një tjetër veçori që do të përmirësojë dukshëm performancën pa ndonjë përpjekje nga ana juaj.
Segmentimi â mĂ« shumĂ«, mĂ« mirĂ«, mĂ« shpejt
Në PostgreSQL 10 u prezantua . Në PostgreSQL 11, përdorimi i tij u bë shumë më i lehtë. Në PostgreSQL 12 mund të ndryshoni shkallën e segmenteve.
Në PostgreSQL 12, performanca e sistemit të segmentimit është përmirësuar ndjeshëm, veçanërisht kur tabela ka mijëra segmente. Për shembull, nëse një kërkesë përfshin vetëm disa segmente në një tabelë që ka mijëra, ajo do të ekzekutohet shumë më shpejt. Performanca është përmirësuar jo vetëm për këtë lloj kërkese. Ju gjithashtu do të vëreni se operacionet INSERT në tabelat me shumë segmente janë përshpejtuar.
Shkarkimi i tĂ« dhĂ«nave me â pĂ«r ta thĂ«nĂ«, Ă«shtĂ« njĂ« mĂ«nyrĂ« e shkĂ«lqyer dhe ja njĂ« shembull â nĂ« tabelat e segmentuara nĂ« PostgreSQL 12 gjithashtu Ă«shtĂ« bĂ«rĂ« mĂ« efektive. Me COPY gjithçka ishte e shpejtĂ«, dhe nĂ« PostgreSQL 12 po fluturon.
Falë këtyre avantazheve, në PostgreSQL mund të ruani grupe të dhënash edhe më të mëdha, dhe ka bërë që nxjerrja e tyre të jetë më e lehtë. Dhe pa ndonjë përpjekje nga ana juaj. Nëse aplikacioni ka shumë segmente, për shembull, nëse regjistron të dhëna të serive kohore, një përmirësim i thjeshtë do të rrisë ndjeshëm performancën e tij.
Edhe pse ky përmirësim nuk është krejtësisht në kategorinë "e përmirësuam dhe gëzohemi", në PostgreSQL 12 mund të krijoni çelësa të jashtëm që referohen në tabela të segmentuara, duke e bërë punën me segmentimin një kënaqësi.
Kërkesat WITH janë bërë shumë më të mira
Kur (ato që njihen si CTE, ato që njihen si kërkesat WITH), nuk mund të prisja të shkruaja një artikull për atë . Kjo është një nga ato veçori që do të përshpejtojë aplikacionin. Nëse, sigurisht, përdorni CTE.
Shumë shpesh vë re se fillestarët në SQL pëlqejnë të përdorin CTE: nëse i shkruani ata një mënyrë të caktuar, ndiheni sikur po shkruani një program imperativ. Personalisht, më pëlqente të riprogramoja këto kërkesa për t'i kaluar pa CTE dhe për të rritur performancën. Tani gjithçka është ndryshe.
PostgreSQL 12 lejon të inkorporoni një tip të caktuar CTE pa efekte anësore (SELECT), e cila përdoret vetëm një herë afër fundit të kërkesës. Nëse do të mbaja statistika të kërkesave me CTE, shumica e tyre do të ishin në këtë kategori. Kjo ndihmon zhvilluesit të shkruajnë kod të kuptueshëm, i cili tani gjithashtu funksionon shpejt.
Për më tepër, PostgreSQL 12 optimizon ekzekutimin e SQL vetë, ju nuk do të duhet të bëni asgjë. Dhe ndonëse tani, ndoshta, nuk do të kem nevojë të optimizoj këto kërkesa, është e shkëlqyer që PostgreSQL vazhdon të punojë në optimizimin e kërkesave.
Just-in-Time (JIT) â tani si parazgjedhje
NĂ« sistemet PostgreSQL 12 me mbĂ«shtetje pĂ«r JIT-kompilimin Ă«shtĂ« aktivizuar si parazgjedhje. SĂ« pari, merrni mbĂ«shtetje pĂ«r pĂ«r disa operacione tĂ« brendshme, dhe sĂ« dyti, kĂ«rkesat me shprehjet (shembulli mĂ« i thjeshtĂ« â x + y) nĂ« listat e zgjedhjes (tĂ« cilat keni pasur pas SELECT), agregat, shprehje me propozitat WHERE dhe tĂ« tjera mund tĂ« pĂ«rdorin JIT pĂ«r tĂ« rritur performancĂ«n.
Duke pasur parasysh se JIT është aktivizuar në PostgreSQL 12 si parazgjedhje, performanca do të përmirësohet vetvetiu, por ju rekomandoj të testoni aplikacionin në PostgreSQL 11, ku JIT sapo ishte introduktuar, për të matur performancën e kërkesave dhe për të parë nëse duhet të bëni ndonjë konfigurim.
Por çfarë ndodh me veçoritë e tjera të reja të PostgreSQL 12?
NĂ« PostgreSQL 12 ka njĂ« mori veçorish tĂ« reja tĂ« shkĂ«lqyera â nga mundĂ«sia pĂ«r tĂ« kĂ«rkuar tĂ« dhĂ«nat JSON duke pĂ«rdorur shprehjet standarde tĂ« rrugĂ«s SQL/JSON deri te autentifikimi shumĂ«-faktorĂ«sh me parametrin clientcert=verify-full, kolona tĂ« krijuara dhe shumĂ« tĂ« tjera. Mjafton pĂ«r njĂ« post tĂ« veçantĂ«.
Ashtu si PostgreSQL 10, PostgreSQL 12 do tĂ« rrisĂ« performancĂ«n e pĂ«rgjithshme menjĂ«herĂ« pas pĂ«rmirĂ«simit. Sigurisht, mund tĂ« keni rrugĂ«n tuaj â testoni aplikacionin nĂ«n kushte tĂ« ngjashme nĂ« sistemin e punĂ«s, para se tĂ« aktivizoni pĂ«rmirĂ«simet, siç kam bĂ«rĂ« unĂ« me PostgreSQL 10. Edhe nĂ«se PostgreSQL 12 tashmĂ« Ă«shtĂ« mĂ« i qĂ«ndrueshĂ«m se sa kisha parashikuar, mos u leni pas tĂ« testoni aplikacionet pĂ«rpara se t'i lĂ«shoni nĂ« prodhim.
Burimi: habr.com
