, ang pinakabag-o nga pagpagawas sa "labing maayo nga open source relational database sa kalibutan", mogawas sa pipila ka mga semana (kung ang tanan moadto sumala sa plano). Nagsunod kini sa naandan nga eskedyul - usa ka bag-ong bersyon nga adunay daghang mga bag-ong bahin mogawas kausa sa usa ka tuig, ug, prangka, kini impresibo. Mao nga nahimo kong aktibong miyembro sa komunidad sa PostgreSQL.
Sa akong opinyon, dili sama sa nangaging mga pagpagawas, ang PostgreSQL 12 walay usa o duha ka rebolusyonaryong bahin (sama sa partitioning o query parallelism). Gibiaybiay nako kaniadto nga ang panguna nga bahin sa PostgreSQL 12 mao ang labi ka kalig-on. Dili ba kana ang imong kinahanglan kung imong gidumala ang kritikal nga datos sa imong negosyo?
Apan ang PostgreSQL 12 dili limitado niini: nga adunay bag-ong mga bahin ug mga pag-uswag, ang mga aplikasyon mahimong mas maayo, Ang kinahanglan nimong buhaton mao ang pag-upgrade!
(Aw, tingali bisan sa pagtukod pag-usab sa mga indeks, apan sa kini nga pagpagawas dili kini ingon ka makahadlok sama sa atong naandan.)
Nindot kaayo nga i-upgrade ang PostgreSQL ug matagamtam dayon ang hinungdanon nga mga pag-uswag nga walaβy kinahanglan nga mga lihok. Pipila ka tuig ang milabay, akong gisusi ang pag-upgrade gikan sa PostgreSQL 9.4 ngadto sa PostgreSQL 10 ug nakita kung unsa ka paspas ang aplikasyon tungod sa gipaayo nga paralelismo sa pangutana sa PostgreSQL 10. Ug, labaw sa tanan, halos walay gikinahanglan kanako (ibutang lang ang configuration parameter max_parallel_workers).
Uyon, kini kombenyente kung ang mga aplikasyon molihok dayon pagkahuman sa pag-upgrade. Ug naningkamot kami pag-ayo aron mapahimut-an ang mga tiggamit, tungod kay ang PostgreSQL adunay daghan ug daghan kanila.
Ug sa unsang paagi ang usa ka yano nga pag-upgrade sa PostgreSQL 12 makapalipay kanimo? Karon sultihan ko ikaw.
Panguna nga pag-uswag sa pag-indeks
Kung walay pag-indeks, ang database dili moadto sa layo. Unsaon pa nimo pagpangita dayon og impormasyon? Ang sukaranan nga PostgreSQL indexing system gitawag . Kini nga matang sa indeks gi-optimize alang sa mga sistema sa pagtipig.
Gigamit ra namo ang operator CREATE INDEX ON some_table (some_column), ug ang PostgreSQL usa ka maayo nga trabaho sa pagpadayon sa indeks nga hangtod karon samtang kami kanunay nga nagsal-ot, nag-update, ug nagtangtang sa mga kantidad. Ang tanan molihok sa iyang kaugalingon, sama sa salamangka.
Apan ang mga index sa PostgreSQL adunay usa ka problema - sila ug mokuha ug dugang nga wanang sa disk, ug ang pasundayag sa pagkuha ug pag-update sa datos mikunhod. Pinaagi sa "bloat" gipasabut nako ang dili maayo nga pagpadayon sa istruktura sa indeks. Mahimo kini o walaβy kalabotan sa mga tuple sa basura nga (salamat kay Peter Gagan sa impormasyon))). Ang index bloat labi nga mamatikdan sa mga workloads diin ang indeks aktibo nga nagbag-o.
Ang PostgreSQL 12 labi nga nagpauswag sa paghimo sa mga indeks sa B-tree, ug ang mga eksperimento nga adunay mga pagsulay sama sa TPC-C nagpakita nga ang wanang gigamit karon, sa aberids, 40% nga gamay. Karon kami mogugol og gamay nga panahon dili lamang sa pagmintinar sa B-tree index (nga mao, pagsulat sa mga operasyon), apan usab sa pagkuha sa data, tungod kay ang mga indeks nahimong mas gamay.
Ang mga aplikasyon nga aktibong nag-update sa ilang mga lamesa kasagarang mga aplikasyon sa OLTP () mahimong mas episyente sa termino sa paggamit sa disk ug pagproseso sa pangutana. Ang mas daghang disk space, mas daghang lawak ang database kinahanglan nga motubo nga walay pag-upgrade sa imprastraktura.
Ang ubang mga estratehiya sa pag-upgrade nagkinahanglan kanimo sa pagtukod pag-usab sa mga indeks sa B-tree aron mapahimuslan kini nga mga benepisyo (pananglitan, dili awtomatik nga magtukod pag-usab sa mga indeks). Sa nangaging mga bersyon sa PostgreSQL, ang pagtukod pag-usab sa dagkong mga indeks sa mga lamesa miresulta sa mahinungdanong downtime tungod kay walay mga kausaban nga mahimo nianang panahona. Apan ang PostgreSQL 12 adunay lain nga cool nga bahin: karon mahimo nimong tukuron pag-usab ang mga indeks nga managsama sa mando aron hingpit nga malikayan ang downtime.
Ang PostgreSQL 12 adunay uban pang mga pagpaayo sa imprastraktura sa pag-indeks. Laing butang diin adunay pipila ka salamangka - , aka WAL (write-ahead log). Ang write-ahead log nagsulat sa matag transaksyon sa PostgreSQL kung adunay kapakyasan ug replikasyon. Gigamit kini sa mga aplikasyon alang sa pag-archive ug . Siyempre, ang write-ahead log gisulat sa disk, ug kini makaapekto sa performance.
Ang PostgreSQL 12 nagpamenos sa overhead sa mga rekord sa WAL nga gimugna sa GiST, GIN, ug SP-GIST nga mga index kung ang usa ka indeks gihimo. Kini adunay ubay-ubay nga mahikap nga mga benepisyo: Ang mga rekord sa WAL mokuha ug gamay nga espasyo sa disk, ug ang data mas paspas nga gibalikbalik, sama sa panahon sa failover o point-in-time nga pagbawi. Kung mogamit ka sa ingon nga mga indeks sa imong mga aplikasyon (pananglitan, ang mga aplikasyon sa geospatial nga nakabase sa PostGIS naggamit sa indeks sa GiST), kini usa pa nga bahin nga labi nga makapauswag sa pasundayag nga walaβy bisan unsang paningkamot sa imong bahin.
Pagbahin - Mas Dako, Mas Maayo, Mas paspas
Gipaila ang PostgreSQL 10 . Sa PostgreSQL 11, kini nahimong mas sayon ββββgamiton. Sa PostgreSQL 12, mahimo nimong sukdon ang mga partisyon.
Sa PostgreSQL 12, ang performance sa partitioning system miuswag pag-ayo, ilabina kung adunay liboan ka partition sa usa ka lamesa. Pananglitan, kung ang usa ka pangutana makaapekto lamang sa pipila ka mga partisyon sa usa ka lamesa nga adunay liboan niini, kini modagan nga mas paspas. Ang pagpaayo sa performance dili limitado sa kini nga mga matang sa mga pangutana. Mamatikdan usab nimo kung unsa ka paspas ang mga operasyon sa INSERT sa mga lamesa nga adunay daghang mga partisyon.
Pagsulat sa datos gamit ang - sa paagi, kini usa ka maayo nga paagi ug ania ang usa ka pananglitan - sa mga partitioned table sa PostgreSQL 12 nahimo usab nga mas episyente. Ang tanan paspas sa COPY, apan sa PostgreSQL 12 kini molupad sa hingpit.
Kini nga mga benepisyo nagpaposible alang sa PostgreSQL nga magtipig bisan labi ka daghang mga datos ug himuon kini nga dali nga makuha. Ug walay effort sa imong part. Kung ang aplikasyon adunay daghang mga seksyon, pananglitan, nagsulat kini nga datos sa serye sa oras, ang usa ka yano nga pag-upgrade makapauswag sa pasundayag niini.
Ug samtang dili kini eksakto nga pag-uswag-ug-pagmaya nga pag-uswag, sa PostgreSQL 12 makahimo ka og mga langyaw nga yawe nga nagtumong sa mga partitioned nga mga lamesa aron ang pagtrabaho uban ang partitioning usa ka kalipay.
UBAN sa mga pangutana mas maayo pa
Kanus-a (aka CTE, aka WITH pangutana), nangalisang ko sa pagsulat og artikulo kon unsaon . Kini usa sa mga bahin nga makapadali sa aplikasyon. Gawas kung, siyempre, naggamit ka CTE.
Kanunay nakong namatikdan nga ang mga nagsugod sa SQL ganahan nga mogamit sa mga CTE: kung isulat nimo kini sa usa ka piho nga paagi, gibati nimo nga nagsulat ka usa ka kinahanglanon nga programa. Sa personal, ganahan kong isulat pag-usab kini nga mga pangutana aron makalibot nga walay CTE ug pagdugang sa pagka-produktibo. Karon lahi na ang tanan.
Gitugotan ka sa PostgreSQL 12 nga mag-inline sa usa ka piho nga tipo sa CTE nga walaβy mga epekto (SELECT), nga gigamit lang kausa duol sa katapusan sa hangyo. Kung gibantayan nako ang mga pangutana sa CTE nga akong gisulat pag-usab, kadaghanan kanila mahulog sa kini nga kategorya. Nakatabang kini sa mga developers sa pagsulat sa tin-aw nga code nga karon paspas usab.
Dugang pa, ang PostgreSQL 12 nag-optimize sa SQL execution mismo, wala ka'y ββkinahanglan buhaton. Samtang dili nako kinahanglan nga i-optimize ang ingon nga mga pangutana karon, maayo nga ang PostgreSQL nagpadayon sa pagtrabaho sa pag-optimize sa pangutana.
Just-in-Time (JIT) - karon ang default
Sa PostgreSQL 12 nga mga sistema nga adunay suporta Ang JIT compilation gipalihok pinaagi sa default. Una, makakuha ka og suporta alang sa pipila ka mga internal nga operasyon, ug ikaduha, ang mga pangutana nga adunay mga ekspresyon (ang pinakasimple nga pananglitan mao ang x + y) sa mga pinili nga lista (nga naa nimo pagkahuman sa SELECT), mga aggregate, mga ekspresyon nga adunay mga clause sa WHERE, ug uban pa nga magamit ang JIT aron mapauswag ang pasundayag.
Tungod kay ang JIT gipalihok pinaagi sa default sa PostgreSQL 12, ang pasundayag mouswag sa iyang kaugalingon, apan akong gisugyot nga sulayan ang aplikasyon sa PostgreSQL 11, diin ang JIT unang gipaila, aron masukod ang pasundayag sa pangutana ug tan-awon kung adunay kinahanglan nga pag-tweak.
Apan komosta ang nahabilin sa mga bag-ong bahin sa PostgreSQL 12?
Ang PostgreSQL 12 adunay usa ka tonelada nga cool nga bag-ong mga bahin, gikan sa abilidad sa pag-inspeksyon sa datos sa JSON gamit ang standard nga mga ekspresyon sa ruta sa SQL / JSON hangtod sa multi-factor authentication nga adunay usa ka clientcert=verify-full, namugna nga mga kolum, ug uban pa. Igo na para sa bulag nga post.
Sama sa PostgreSQL 10, ang PostgreSQL 12 mopauswag sa kinatibuk-ang pasundayag dayon pagkahuman sa pag-upgrade. Siyempre, mahimo nimo ang imong kaugalingon nga paagi - sulayi ang aplikasyon sa ilawom sa parehas nga mga kondisyon sa usa ka sistema sa produksiyon sa wala pa ma-enable ang mga pag-uswag, sama sa akong gibuhat sa PostgreSQL 10. Bisan kung ang PostgreSQL 12 mas lig-on kaysa sa akong gilauman, ayaw tapolan sa pagsulay sa mga aplikasyon maayo, sa wala pa ipagawas kini sa produksiyon.
Source: www.habr.com