, "munduko kode irekiko datu-base erlazional onena"ren azken bertsioa aste pare batean aterako da (dena aurreikusitakoaren arabera badoa). Honek ohiko ordutegiari jarraitzen dio: funtzio berri asko dituen bertsio berri bat ateratzen da urtean behin, eta, egia esan, ikusgarria da. Horregatik, PostgreSQL komunitateko kide aktibo bihurtu nintzen.
Nire ustez, iraganeko bertsioek ez bezala, PostgreSQL 12-k ez ditu ezaugarri iraultzaile bat edo bi (adibidez, partizioa edo kontsultaren paralelismoa). Behin txantxetan esan nuen PostgreSQL 12-ren ezaugarri nagusia egonkortasun handiagoa dela. Ez al da hori behar duzuna zure negozioaren datu kritikoak kudeatzen dituzunean?
Baina PostgreSQL 12 ez da horretara mugatzen: funtzio eta hobekuntza berriekin, aplikazioek hobeto funtzionatuko dute, Egin behar duzun guztia berritzea da!
(Beno, agian indizeak berreraiki ere bai, baina bertsio honetan ez da ohituta gauden bezain beldurgarria.)
Oso ona litzateke PostgreSQL berritzea eta berehala hobekuntza esanguratsuak gozatzea alferrikako keinurik gabe. Duela urte batzuk, PostgreSQL 9.4-tik PostgreSQL 10-rako bertsio-berritzea aztertu nuen eta aplikazioa zenbat bizkorragoa zen PostgreSQL 10-n kontsulta paralelo hobetu zela eta. Eta, batez ere, ia ezer ez zitzaidan eskatzen (konfigurazio-parametroa ezarri besterik ez dago max_parallel_workers).
Ados, komenigarria da aplikazioak eguneratu ondoren berehala hobeto funtzionatzen dutenean. Eta oso gogor saiatzen gara erabiltzaileei atsegin ematen, PostgreSQL-k gero eta gehiago dituelako.
Eta nola egiten zaitu zoriontsu PostgreSQL 12 eguneratze sinple batek? Orain esango dizut.
Indexatzeko hobekuntza handiak
Indexatu gabe, datu-basea ez da urrutira joango. Bestela nola aurki dezakezu informazioa azkar? Oinarrizko PostgreSQL indexatzeko sistema deitzen zaio . Indize mota hau biltegiratze sistemetarako optimizatuta dago.
Operatzailea besterik ez dugu erabiltzen CREATE INDEX ON some_table (some_column), eta PostgreSQL-k lan bikaina egiten du indizea eguneratuta mantentzen, balioak etengabe txertatzen, eguneratzen eta ezabatzen ari garen bitartean. Dena berez funtzionatzen du, magia bezala.
Baina PostgreSQL indizeek arazo bat dute - haiek eta diskoko espazio gehigarria hartzen du, eta datuak ateratzeko eta eguneratzeko errendimendua murrizten da. "Puztu" esan nahi dut indize-egituraren mantentze ez eraginkorra. Hau zabor tupleekin erlazionatuta egon daiteke edo ez (eskerrik asko Peter Gagani informazioagatik))). Indizearen puzkera nabarmena da indizea aktiboki aldatzen ari den lan-kargan.
PostgreSQL 12-k B-zuhaitz indizeen errendimendua asko hobetzen du, eta TPC-C bezalako probekin egindako esperimentuek erakutsi dute orain espazioa erabiltzen dela, batez beste, %40 gutxiago. Orain denbora gutxiago ematen dugu B-zuhaitz indizeak mantentzen ez ezik (hau da, eragiketak idazten), baita datuak berreskuratzen ere, indizeak askoz txikiagoak direlako.
Taulak aktiboki eguneratzen dituzten aplikazioak OLTP aplikazioak izan ohi dira () askoz eraginkorragoa izango da diskoaren erabilerari eta kontsulten prozesamenduari dagokionez. Zenbat eta espazio gehiago diskoan, datu-baseak hazteko leku gehiago izango du azpiegitura berritu gabe.
Bertsio-estrategia batzuek B-zuhaitz indizeak berreraiki behar dituzu abantaila horietaz baliatzeko (adibidez, ez ditu indizeak automatikoki berreraikiko). PostgreSQL-ren aurreko bertsioetan, tauletan indize handiak berreraikitzeak geldialdi handiak eragin zituen denbora horretan aldaketarik ezin zelako egin. Baina PostgreSQL 12-k beste ezaugarri polit bat du: orain indizeak berreraiki ditzakezu komandoarekin paraleloan geldialdia guztiz saihesteko.
PostgreSQL 12-k beste hobekuntza batzuk ditu indexatzeko azpiegituran. Magia pixka bat zegoen beste gauza bat - , aka WAL (idatzi aurretiko erregistroa). Aurrez idatzitako erregistroak transakzio guztiak idazten ditu PostgreSQL-n, hutsegite eta errepikapen kasuan. Aplikazioek artxibatzeko erabiltzen dute eta . Jakina, idazteko aurrerapenaren erregistroa diskoan idazten da, eta horrek errendimenduan eragina izan dezake.
PostgreSQL 12-k GiST, GIN eta SP-GiST indizeek sortzen dituzten WAL erregistroen gainkostua murriztu du indize bat eraikitzen denean. Honek hainbat onura ukigarri ditu: WAL erregistroek diskoko leku gutxiago hartzen dute eta datuak azkarrago errepikatzen dira, esate baterako, hutsegite garaian edo momentuko berreskurapenean. Zure aplikazioetan horrelako indizeak erabiltzen badituzu (adibidez, PostGIS-en oinarritutako aplikazio geoespazialek GiST indizea asko erabiltzen dute), hau da errendimendua asko hobetuko duen beste ezaugarri bat, zure aldetik inolako ahaleginik egin gabe.
Banaketa - Handiagoa, Hobeto, Azkarrago
PostgreSQL 10 aurkeztu da . PostgreSQL 11-n, askoz errazagoa bihurtu da erabiltzeko. PostgreSQL 12-n, partizioak eskalatu ditzakezu.
PostgreSQL 12-n, partizio-sistemaren errendimendua nabarmen hobetu da, batez ere taula batean milaka partizio badaude. Esaterako, kontsulta batek mila partizio gutxi batzuei bakarrik eragiten badie taula batean, askoz azkarrago exekutatuko da. Errendimenduaren hobekuntzak ez dira kontsulta mota hauetara mugatzen. Gainera, INSERT eragiketak zenbateko azkarragoak diren partizio asko dituzten tauletan ere nabarituko duzu.
Datuak erabiliz idaztea - Bide batez, hau modu bikaina da eta hona hemen adibide bat - PostgreSQL 12-n zatitutako tauletara ere eraginkorragoa bihurtu da. Dena azkarra zen COPY-rekin, baina PostgreSQL 12-n guztiz hegan egiten du.
Abantaila hauei esker, PostgreSQL-k datu-multzo are handiagoak gordetzea eta errazago berreskuratzea ahalbidetzen du. Eta zure aldetik ahaleginik ez. Aplikazioak atal asko baditu, adibidez, denbora serieko datuak idazten baditu, berritze sinple batek bere errendimendua nabarmen hobetuko du.
Eta hau ez den zehatz-mehatz eguneratzeko eta pozteko hobekuntza bat den arren, PostgreSQL 12-n partikatutako taulak aipatzen dituzten atzerriko gakoak sor ditzakezu, partizioarekin lan egitea plazer bat izan dadin.
Kontsultekin asko hobetu da
Noiz (aka CTE, aka Kontsultekin), nola idazteko azkura nengoen . Hau da aplikazioa bizkortuko duen ezaugarri horietako bat. CTE erabiltzen ari ez bazara, noski.
Askotan nabaritzen dut SQL hasiberriek CTEak erabiltzea maite dutela: modu jakin batean idazten badituzu, programa ezinbesteko bat idazten ari zarela sentitzen duzu. Pertsonalki, kontsulta hauek berridaztea gustatu zitzaidan ibiltzeko gabe CTE eta produktibitatea handitzea. Orain dena ezberdina da.
PostgreSQL 12-k CTE mota zehatz bat sartzea ahalbidetzen du bigarren mailako efekturik gabe (SELECT), eskaeraren amaieran behin bakarrik erabiltzen dena. Berridatzi ditudan CTE kontsulten jarraipena egingo banu, gehienak kategoria honetan sartuko lirateke. Horrek garatzaileei orain azkarra den kode argia idazten laguntzen die.
Gainera, PostgreSQL 12-k SQL exekuzioa bera optimizatzen du, ez duzu ezer egin beharrik. Orain ziurrenik horrelako kontsultak optimizatu beharko ez ditudan arren, bikaina da PostgreSQL-k kontsultaren optimizazioan lanean jarraitzea.
Just-in-Time (JIT) - orain lehenetsia
PostgreSQL 12 sistemetan laguntzarekin JIT konpilazioa lehenespenez gaituta dago. Lehenik eta behin, laguntza jasotzen duzu barne-eragiketa batzuetarako, eta, bigarrenik, esamoldeekin (adibiderik errazena x + y da) hautapen-zerrendetan (HAUSTEN ondoren dituzu), agregatuak, WHERE klausulak dituzten esamoldeak eta beste batzuek JIT erabil dezakete errendimendua hobetzeko.
PostgreSQL 12-n JIT lehenespenez gaituta dagoenez, errendimendua hobetuko da bere kabuz, baina PostgreSQL 11-n aplikazioa probatzea proposatzen dut, non JIT sartu zen lehen aldiz, kontsulta-errendimendua neurtzeko eta zerbait moldatu behar den ikusteko.
Baina zer gertatzen da PostgreSQL 12-ren gainerako ezaugarri berriekin?
PostgreSQL 12-k funtzio berri ugari ditu, JSON datuak SQL/JSON ibilbide-adierazpen estandarrak erabiliz ikuskatzeko gaitasunetik, faktore anitzeko autentifikaziora arte. clientcert=verify-full, sortutako zutabeak eta abar. Aparteko mezu baterako nahikoa.
PostgreSQL 10 bezala, PostgreSQL 12-k errendimendu orokorra hobetuko du eguneratu eta berehala. Noski, zure modua izan dezakezu: probatu aplikazioa antzeko baldintzetan ekoizpen-sistema batean hobekuntzak gaitu aurretik, PostgreSQL 10-rekin egin nuen bezala. Nahiz eta PostgreSQL 12 dagoeneko espero nuena baino egonkorragoa izan, ez izan alferra aplikazioak probatzeko. beno, produkziora atera aurretik.
Iturria: www.habr.com