, versioni mĂ« i fundit "i bazĂ«s sĂ« tĂ« dhĂ«nave relacionale mĂ« tĂ« mirĂ« nĂ« botĂ« me burim tĂ« hapur", do tĂ« dalĂ« brenda disa javĂ«sh (nĂ«se gjithçka shkon sipas planit). Kjo i pĂ«rkon orarit tĂ« zakonshĂ«m â njĂ« version i ri me shumĂ« mundĂ«si tĂ« reja del çdo vit dhe, sinqerisht, kjo Ă«shtĂ« e impresionueshme. Prandaj kam bĂ«rĂ« anĂ«tar tĂ« aktiv tĂ« komunitetit PostgreSQL.
Mendoj se, ndryshe nga botimet e kaluara, PostgreSQL 12 nuk ka një ose dy funksione revolucionare (siç janë, për shembull, ndarjet ose paralelizmi i kërkesave). Kam bërë një shaka se karakteristika kryesore e PostgreSQL 12 është stabiliteti më i madh. A nuk është kjo ajo që na nevojitet kur menaxhojmë të dhëna të rëndësishme për biznesin tuaj?
Por PostgreSQL 12 nuk përfundon këtu: me mundësitë dhe përmirësimet e reja, aplikacionet do të funksionojnë më mirë, dhe nga ju kërkohet vetëm të bëni ngritjen!
(Epo, ndoshta duhet të rindërtoni indekset, por në këtë version nuk është aq e frikshme sa jemi mësuar.)
Do tĂ« ishte bukur â tĂ« ngrini PostgreSQL dhe menjĂ«herĂ« tĂ« shijoni pĂ«rmirĂ«sime tĂ« konsiderueshme pa lĂ«vizje tĂ« tepĂ«rta. Disa vjet mĂ« parĂ« kam analizuar pĂ«rditĂ«simin nga PostgreSQL 9.4 nĂ« PostgreSQL 10 dhe kam parĂ« si u pĂ«rshpejtua aplikacioni falĂ« pĂ«rmirĂ«simit tĂ« paralelizmit tĂ« kĂ«rkesave nĂ« PostgreSQL 10. Dhe, mĂ« kryesorja, nuk mĂ« nevojitej pothuajse asgjĂ« (vetĂ«m tĂ« vendosja njĂ« parametĂ«r konfigurimi max_parallel_workers).
Bashkohuni me mua, është e përshtatshme kur menjëherë pas ngritjes aplikacionet funksionojnë më mirë. Ne punojmë shumë për të bërë përdoruesit të lumtur, pasi numri i përdoruesve të PostgreSQL po rritet.
Dhe si do t'ju bëjë më të lumtur një ngritje e thjeshtë në PostgreSQL 12? Tani do t'ju tregoj.
Përmirësime serioze në indeksim
Pa indeksimin, baza e të dhënave nuk do të arrijë shumë. Si mund të gjeni informacione shpejt? Sistemi themelor i indeksimit të PostgreSQL quhet . Ky tip indeksi është optimizuar për sistemet e ruajtjes.
Ne thjesht përdorim operatorin CREATE INDEX ON some_table (some_column), ndërsa PostgreSQL bën punën e madhe për të mbajtur indekset e azhurnuara ndërsa ne vazhdimisht shtojmë, përditësojmë dhe fshijmë vlera. Të gjitha funksionon vetvetiu, si me magji.
Por indekset e PostgreSQL kanĂ« njĂ« problem â ato dhe zĂ«nĂ« hapĂ«sirĂ« tĂ« panevojshme nĂ« disk, ndĂ«rsa performanca e nxjerrjes dhe pĂ«rditĂ«simit tĂ« tĂ« dhĂ«nave zvogĂ«lohet. Me "pĂ«rgjakje" nĂ«nkuptoj mbajtjen joefikase tĂ« strukturĂ«s sĂ« indeksit. Kjo mund tĂ« jetĂ« - ose nuk mund tĂ« jetĂ« - e lidhur me tupat e plehrave qĂ« fshin (faleminderit pĂ«r informacionin Peter Geogheganit ()). PĂ«rshtatja e indeksit Ă«shtĂ« veçanĂ«risht e dukshme nĂ« ngarkesat e punĂ«s ku indekset modifikohen aktivisht.
PostgreSQL 12 përmirëson ndjeshëm funksionimin e indekseve B-tree, dhe eksperimentet me testet e tipit TPC-C treguan se tani përdoret, mesatarisht, 40% më pak hapësirë. Tani harxhojmë më pak kohë jo vetëm për mirëmbajtjen e indekseve B-tree (dmth në operacionet e shkrimit), por gjithashtu në nxjerrjen e të dhënave, pasi indekset janë bërë shumë më të vogla.
Aplikacionet që azhurnojnë aktivisht tabelat e tyre - zakonisht këto janë aplikacione OLTP () - do të përdorin diskun shumë më efikas dhe do të përpunojnë kërkesat. Sa më shumë hapësirë në disk, aq më shumë hapësirë ka databaza për rritje pa përmirësimin e infrastrukturës.
Disa strategji përmirësimi kërkojnë që të rindërtohen indekset B-tree për të shfrytëzuar këto përparësi (p.sh., nuk do të rindërtojë indekset automatikisht). Në versionet e mëparshme të PostgreSQL, rindërtimi i indekseve të mëdha në tabela rezultonte në një ndalim të dukshëm, pasi gjatë kësaj kohe nuk mund të bëheshin ndryshime. Por në PostgreSQL 12 ka edhe një veçori të shkëlqyer: tani mund të rindërtohen indekset paralelisht me komandën , për të shmangur tërësisht ndalimin.
Në PostgreSQL 12 ka përmirësime të tjera në infrastrukturën e indeksohës. Një tjetër gjë ku nuk kishte mungesë të magjisë është , gjithashtu e njohur si WAL (logu i shkrimit të parakohshëm). Logu i shkrimit të parakohshëm regjistron çdo transaksion në PostgreSQL për rastet e dështimit dhe replikimit. Aplikacionet e përdorin atë për arkivimin dhe . Sigurisht, logu i shkrimit të parakohshëm shkruhet në disk, dhe kjo mund të ndikojë në performancën.
Në PostgreSQL 12, kostot për regjistrimet WAL, të cilat krijohen nga indekset GiST, GIN dhe SP-GiST gjatë krijimit të indeksit janë reduktuar. Kjo ofron disa avantazhe 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., aplikacione gjeo-hapsinore që përdorin shumë indeksin GiST), kjo është një tjetër veçori që do të përmirësojë ndjeshëm performancën e saj pa asnjë përpjekje nga ana juaj.
ShkĂ«putja â mĂ« shumĂ«, mĂ« mirĂ«, mĂ« shpejt
Në PostgreSQL 10 u prezantua . Në PostgreSQL 11 e përdorimi i saj u bë shumë më i thjeshtë. Në PostgreSQL 12 mund të ndryshoni masën e seksioneve.
Në PostgreSQL 12, performanca e sistemit të shkëputjes u përmirësua ndjeshëm, veçanërisht nëse tabela ka mijëra seksione. Për shembull, nëse një kërkesë përfshin vetëm disa seksione në një tabelë ku 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. Gjithashtu, do të vini re se operacionet INSERT në tabela me shumë seksione janë përshpejtuar.
Regjistrimi i tĂ« dhĂ«nave me â pĂ«r mĂ« tepĂ«r, kjo Ă«shtĂ« njĂ« mĂ«nyrĂ« e shkĂ«lqyer dhe ja njĂ« shembull â nĂ« tabelat e ndara nĂ« PostgreSQL 12 gjithashtu u bĂ« mĂ« efikase. Me COPY ishte gjithmonĂ« e shpejtĂ«, por tani nĂ« PostgreSQL 12 fluturon.
Falë këtyre avantazheve, në PostgreSQL mund të ruani grupe të dhënash me një madhësi edhe më të madhe dhe është bërë më e lehtë t'i nxirrni ato. Dhe nuk kërkon përpjekje nga ana juaj. Nëse aplikacioni ka shumë seksione, për shembull, nëse shkruan të dhëna serike, një përmirësim i thjeshtë do të përmirësojë ndjeshëm performancën e tij.
Dhe edhe pse ky përmirësim nuk është pikërisht nga kategoria "përmirësuam dhe jemi të lumtur", në PostgreSQL 12 mund të krijoni çelësa të jashtëm që i referohen tabelave të ndara, për të bërë që puna me shkëputjen të jetë një kënaqësi.
Kërkesat WITH janë bërë shumë më të mira
Kur (të njohura gjithashtu si CTE, ata gjithashtu kërkesat WITH), isha në pritje për të shkruar një artikull mbi Kjo është një nga ato veçori që do e shpejtojnë aplikacionin. Nëse, sigurisht, përdorni CTE.
Unë shpesh vë re se fillestarët në SQL pëlqejnë të përdorin CTE: nëse i shkruani ata në një mënyrë të caktuar, e ndjeni që po shkruani një program imperativ. Personalish, më pëlqente të riformuloja këto pyetje për t'u ankuar pa CTE dhe për të përmirësuar performancën. Tani gjërat janë ndryshe.
PostgreSQL 12 lejon integrimin e një lloji të caktuar të CTE pa efekte anësore (SELECT), i cili përdoret vetëm një herë më afër fundit të pyetjes. Nëse do të mbaja statistika të pyetjeve me CTE që kam riformuluar, shumica e tyre do të binin në këtë kategori. Kjo ndihmon zhvilluesit të shkruajnë kod të kuptueshëm, i cili tani funksionon shpejt gjithashtu.
Për më tepër, PostgreSQL 12 optimizon vetë ekzekutimin e SQL, nuk do t'ju 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 pyetjeve.
Just-in-Time (JIT) â tani Ă«shtĂ« default
NĂ« sistemet PostgreSQL 12 me mbĂ«shtetje Kompilimi JIT Ă«shtĂ« aktivizuar si standard. SĂ« pari, ju merrni mbĂ«shtetje pĂ«r disa operacione tĂ« brendshme, dhe sĂ« dyti, pyetjet me shprehje (shembulli mĂ« i thjeshtĂ« â x + y) nĂ« listat e zgjedhjes (tĂ« cilat keni pasur pas SELECT), agregate, shprehje me kushtet WHERE dhe tĂ« tjera mund tĂ« pĂ«rdorin JIT pĂ«r tĂ« rritur performancĂ«n.
Duke qenë se JIT është aktivizuar në PostgreSQL 12 si standard, performanca do të përmirësohet vetë, por unë rekomandoj të testoni aplikacionin në PostgreSQL 11, ku sapo kishte dalë JIT, për të matur performancën e pyetjeve dhe për të parë nëse duhet të bëni ndonjë konfigurim.
E çfarë do të ndodhë me karakteristikat e tjera të reja të PostgreSQL 12?
NĂ« PostgreSQL 12 ka shumĂ« karakteristika tĂ« reja interesante â nga mundĂ«sia pĂ«r tĂ« eksploruar tĂ« dhĂ«nat JSON duke pĂ«rdorur shprehjet standarde tĂ« rrugĂ«s SQL/JSON deri te autentifikimi me shumĂ« faktor me parametrin clientcert=verify-full, kolona tĂ« krijuara dhe shumĂ« tĂ« tjera. Mjafton pĂ«r njĂ« postim 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Ă« kushte tĂ« ngjashme nĂ« sistemin nĂ« punĂ« pĂ«rpara se tĂ« aktivizoni pĂ«rmirĂ«simet, siç kam bĂ«rĂ« unĂ« me PostgreSQL 10. Edhe nĂ«se PostgreSQL 12 tani Ă«shtĂ« mĂ« stabil sesa e kisha pritur, mos u dorĂ«zoni pĂ«r tĂ« testuar me kujdes aplikacionet para se t'i publikoni nĂ« prodhim.
Burimi: habr.com
