, versioni më i fundit i "bazës së të dhënave më të mira relacionale me burim të hapur në botë", do të dalë pas disa javësh (nëse gjithçka shkon sipas planit). Kjo ndjek orarin e zakonshëm të lëshimit të një versioni të ri me një sërë veçorish të reja një herë në vit, dhe sinqerisht, kjo është mbresëlënëse. Kjo është arsyeja pse u bëra një anëtar aktiv i komunitetit PostgreSQL.
Sipas mendimit tim, ndryshe nga publikimet e mëparshme, PostgreSQL 12 nuk përmban një ose dy veçori revolucionare (si ndarjen ose paralelizmin e pyetjeve). Dikur bëra shaka se tipari kryesor i PostgreSQL 12 është stabiliteti më i madh. A nuk është kjo ajo që ju nevojitet kur menaxhoni të dhënat kritike të biznesit tuaj?
Por PostgreSQL 12 nuk ndalet këtu: me veçori dhe përmirësime të reja, aplikacionet do të performojnë më mirë, dhe gjithçka që duhet të bëni është të përmirësoni!
(Epo, ndoshta rindërtoni indekset, por në këtë version nuk është aq e frikshme sa jemi mësuar.)
Do të jetë mirë të përmirësoni PostgreSQL dhe të shijoni menjëherë përmirësime të rëndësishme pa bujë të panevojshme. Disa vite më parë, rishikova një përmirësim nga PostgreSQL 9.4 në PostgreSQL 10 dhe pashë se si u shpejtua aplikacioni falë paralelizmit të përmirësuar të pyetjeve në PostgreSQL 10. Dhe, më e rëndësishmja, pothuajse asgjë nuk kërkohej nga unë (vetëm vendosni një parametër konfigurimi max_parallel_workers).
Dakord, është i përshtatshëm kur aplikacionet funksionojnë më mirë menjëherë pas një përmirësimi. Dhe ne përpiqemi shumë për të kënaqur përdoruesit, sepse PostgreSQL ka gjithnjë e më shumë prej tyre.
Pra, si mund t'ju bëjë të lumtur një përmirësim i thjeshtë në PostgreSQL 12? Unë do t'ju them tani.
Përmirësime të mëdha të indeksimit
Pa indeksimin, një bazë të dhënash nuk do të shkojë larg. Si tjetër mund të gjeni shpejt informacion? Sistemi themelor i indeksimit të PostgreSQL quhet . Ky lloj indeksi është i optimizuar për sistemet e ruajtjes.
Ne thjesht përdorim operatorin CREATE INDEX ON some_table (some_column), dhe PostgreSQL bën shumë punë për ta mbajtur indeksin të përditësuar ndërkohë që ne vendosim, përditësojmë dhe fshijmë vazhdimisht vlerat. Gjithçka funksionon më vete, si me magji.
Por indekset PostgreSQL kanë një problem - ata dhe zënë hapësirë shtesë në disk dhe zvogëlojnë performancën e rikthimit dhe përditësimit të të dhënave. Me "fryrje" nënkuptoj ruajtjen joefektive të strukturës së indeksit. Kjo mund - ose jo - të jetë e lidhur me tuplet e mbeturinave që ai heq (faleminderit Peter Gaghan për informacionin))). Fryrja e indeksit është veçanërisht e dukshme në ngarkesat e punës ku indeksi po ndryshon në mënyrë aktive.
PostgreSQL 12 përmirëson shumë performancën e indekseve të pemës B dhe eksperimentet me standarde si TPC-C kanë treguar se mesatarisht tani përdoret 40% më pak hapësirë. Tani ne shpenzojmë më pak kohë jo vetëm për ruajtjen e indekseve të pemës B (d.m.th., për operacionet e shkrimit), por edhe për marrjen e të dhënave, sepse indekset janë shumë më të vogla.
Aplikacione që përditësojnë në mënyrë aktive tabelat e tyre - zakonisht aplikacionet OLTP () - do të përdorë diskun dhe do të përpunojë kërkesat në mënyrë shumë më efikase. Sa më shumë hapësirë në disk, aq më shumë hapësirë duhet të rritet baza e të dhënave pa përmirësuar infrastrukturën.
Disa strategji përmirësimi kërkojnë rindërtimin e indekseve të pemës B për të përfituar nga këto përfitime (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 rezultoi në ndërprerje të konsiderueshme, sepse ndryshimet nuk mund të bëheshin ndërkohë. Por PostgreSQL 12 ka një veçori tjetër interesante: tani mund të rindërtoni indekset paralelisht me komandën për të shmangur plotësisht kohën e ndërprerjes.
Ka përmirësime të tjera në infrastrukturën e indeksimit në PostgreSQL 12. Një gjë tjetër ku kishte ndonjë magji - , i njohur ndryshe si WAL (regjistri i shkrimit përpara). Një regjistër i parashkrimit regjistron çdo transaksion në PostgreSQL në rast dështimi dhe përsëritjeje. Aplikacionet e përdorin atë për arkivim dhe . Sigurisht, regjistri i shkrimit përpara është shkruar në disk, gjë që mund të ndikojë në performancën.
PostgreSQL 12 ka reduktuar shpenzimet e përgjithshme të regjistrimeve WAL që krijohen nga indekset GiST, GIN dhe SP-GiST gjatë ndërtimit të indeksit. Kjo siguron disa përfitime të prekshme: regjistrimet WAL zënë më pak hapësirë në disk dhe të dhënat riluhen më shpejt, si për shembull gjatë rikuperimit nga katastrofa ose rikuperimi në kohë. Nëse përdorni indekse të tilla në aplikacionet tuaja (për shembull, aplikacionet gjeohapësinore të bazuara në PostGIS përdorin shumë indeksin GiST), kjo është një veçori tjetër që do të përmirësojë ndjeshëm përvojën pa asnjë përpjekje nga ana juaj.
Ndarja - më e madhe, më e mirë, më e shpejtë
Prezantohet PostgreSQL 10 . Në PostgreSQL 11 është bërë shumë më e lehtë për t'u përdorur. Në PostgreSQL 12 mund të ndryshoni shkallën e seksioneve.
Në PostgreSQL 12, performanca e sistemit të ndarjes është bërë dukshëm më e mirë, veçanërisht nëse ka mijëra ndarje në tabelë. Për shembull, nëse një pyetje prek vetëm disa ndarje në një tabelë me mijëra prej tyre, ai do të ekzekutohet shumë më shpejt. Performanca nuk është përmirësuar vetëm për këto lloj pyetjesh. Do të vini re gjithashtu se sa më të shpejtë janë operacionet INSERT në tabela me ndarje të shumta.
Regjistrimi i të dhënave duke përdorur - meqë ra fjala, kjo është një mënyrë e shkëlqyer dhe këtu është një shembull — Tabelat e ndara në PostgreSQL 12 janë bërë gjithashtu më efikase. Me COPY gjithçka ishte tashmë e shpejtë, por në PostgreSQL 12 ajo absolutisht fluturon.
Falë këtyre avantazheve, PostgreSQL ju lejon të ruani grupe të dhënash edhe më të mëdha dhe t'i bëni ato më të lehta për t'u marrë. Dhe asnjë përpjekje nga ana juaj. Nëse aplikacioni ka shumë ndarje, të tilla si regjistrimi i të dhënave të serive kohore, një përmirësim i thjeshtë do të përmirësojë ndjeshëm performancën e tij.
Ndërsa ky nuk është saktësisht një përmirësim "përmirëso dhe shijo", PostgreSQL 12 ju lejon të krijoni çelësa të huaj që referojnë tabelat e ndara, duke e bërë ndarjen një kënaqësi për të punuar me të.
ME pyetjet sapo u bë shumë më mirë
Kur (aka CTE, aka WITH queries), mezi prisja të shkruaj një artikull rreth . Kjo është një nga ato veçori që do të shpejtojë aplikimin. Përveç nëse, sigurisht, përdorni CTE.
Shpesh zbuloj se fillestarët në SQL duan të përdorin CTE; nëse i shkruani ato në një mënyrë të caktuar, me të vërtetë ndjehet sikur po shkruani një program imperativ. Personalisht, më pëlqeu t'i rishkruaj këto pyetje për t'u kthyer pa CTE dhe rrisin produktivitetin. Tani gjithçka është ndryshe.
PostgreSQL 12 ju lejon të futni një lloj specifik të CTE pa efekte anësore (SELECT), i cili përdoret vetëm një herë afër fundit të kërkesës. Nëse do të mbaja gjurmët e pyetjeve të CTE që rishkrova, shumica e tyre do të binin në këtë kategori. Kjo i ndihmon zhvilluesit të shkruajnë një kod të qartë që tani funksionon gjithashtu shpejt.
Për më tepër, PostgreSQL 12 optimizon vetë ekzekutimin e SQL, pa pasur nevojë të bëni asgjë. Dhe megjithëse ndoshta nuk do të më duhet të optimizoj pyetje të tilla tani, është mirë që PostgreSQL vazhdon të punojë në optimizimin e pyetjeve.
Just-in-Time (JIT) - tani e paracaktuar
Në sistemet PostgreSQL 12 me mbështetje Kompilimi JIT është aktivizuar si parazgjedhje. Para së gjithash, ju merrni mbështetje për disa operacione të brendshme, dhe së dyti, pyetjet me shprehje (shembulli më i thjeshtë është x + y) në listat e përzgjedhura (të cilat i keni pas SELECT), agregatët, shprehjet me klauzola WHERE dhe të tjera mund të përdorin JIT për të përmirësuar performancën.
Meqenëse JIT është aktivizuar si parazgjedhje në PostgreSQL 12, performanca do të përmirësohet vetë, por unë rekomandoj të testoni aplikacionin në PostgreSQL 11, i cili prezantoi JIT, për të matur performancën e pyetjeve dhe për të parë nëse keni nevojë të sintonizoni ndonjë gjë.
Po në lidhje me pjesën tjetër të veçorive të reja në PostgreSQL 12?
PostgreSQL 12 ka një ton karakteristikash të reja interesante, nga aftësia për të ekzaminuar të dhënat JSON duke përdorur shprehjet standarde të rrugës SQL/JSON deri te vërtetimi me shumë faktorë me një parametër clientcert=verify-full, kolona të krijuara dhe shumë më tepër. Mjaft për një postim të veçantë.
Ashtu si PostgreSQL 10, PostgreSQL 12 do të përmirësojë performancën e përgjithshme menjëherë pas azhurnimit. Ju, sigurisht, mund të keni rrugën tuaj - testoni aplikacionin në kushte të ngjashme në sistemin e prodhimit përpara se të aktivizoni përmirësime, siç bëra me PostgreSQL 10. Edhe nëse PostgreSQL 12 është tashmë më i qëndrueshëm nga sa prisja, mos u bëni dembel në testim aplikimet tërësisht, përpara se t'i lëshojnë në prodhim.
Burimi: www.habr.com