, ang pinakabagong bersyon ng "pinakamahusay na open source relational database ng mundo," ay lalabas sa loob ng ilang linggo (kung naaayon ang lahat sa plano). Ito ay sumusunod sa karaniwang iskedyul ng paglalabas ng bagong bersyon na may isang toneladang bagong feature minsan sa isang taon, at sa totoo lang, kahanga-hanga iyon. Kaya naman naging aktibong miyembro ako ng komunidad ng PostgreSQL.
Sa palagay ko, hindi tulad ng mga nakaraang release, ang PostgreSQL 12 ay hindi naglalaman ng isa o dalawang rebolusyonaryong tampok (tulad ng partitioning o query parallelism). Minsan akong nagbiro na ang pangunahing tampok ng PostgreSQL 12 ay higit na katatagan. Hindi ba iyon ang kailangan mo kapag pinamamahalaan mo ang kritikal na data ng iyong negosyo?
Ngunit ang PostgreSQL 12 ay hindi titigil doon: sa mga bagong feature at pagpapahusay, ang mga application ay gaganap nang mas mahusay, at ang kailangan mo lang gawin ay mag-upgrade!
(Buweno, marahil ay muling itayo ang mga index, ngunit sa paglabas na ito ay hindi ito nakakatakot gaya ng nakasanayan natin.)
Magiging mahusay na i-upgrade ang PostgreSQL at agad na tamasahin ang mga makabuluhang pagpapabuti nang walang hindi kinakailangang pagkabahala. Ilang taon na ang nakalilipas, nirepaso ko ang isang pag-upgrade mula sa PostgreSQL 9.4 hanggang PostgreSQL 10 at nakita ko kung paano bumilis ang application salamat sa pinahusay na paralelismo ng query sa PostgreSQL 10. At, higit sa lahat, halos walang kailangan mula sa akin (magtakda lamang ng parameter ng pagsasaayos max_parallel_workers).
Sumang-ayon, ito ay maginhawa kapag ang mga application ay gumana kaagad pagkatapos ng isang pag-upgrade. At kami ay nagsisikap nang husto na pasayahin ang mga user, dahil ang PostgreSQL ay mayroong higit at marami sa kanila.
Kaya paano ka mapasaya ng simpleng pag-upgrade sa PostgreSQL 12? sasabihin ko sayo ngayon.
Mga pangunahing pagpapabuti sa pag-index
Kung walang pag-index, ang isang database ay hindi lalayo. Paano ka pa makakahanap ng impormasyon nang mabilis? Ang pangunahing sistema ng pag-index ng PostgreSQL ay tinatawag . Ang ganitong uri ng index ay na-optimize para sa mga storage system.
Ginagamit lang namin ang operator CREATE INDEX ON some_table (some_column), at ang PostgreSQL ay gumagawa ng maraming trabaho upang panatilihing napapanahon ang index habang patuloy kaming naglalagay, nag-a-update, at nagtatanggal ng mga halaga. Ang lahat ay gumagana sa sarili nitong, na parang sa pamamagitan ng magic.
Ngunit ang mga index ng PostgreSQL ay may isang problema - sila at kumuha ng dagdag na espasyo sa disk at bawasan ang pagganap ng pagkuha at pag-update ng data. Sa pamamagitan ng "bloat" ang ibig kong sabihin ay hindi epektibong pagpapanatili ng istraktura ng index. Ito ay maaaring - o maaaring hindi - nauugnay sa mga tuple ng basura na inaalis nito (salamat kay Peter Gaghan para sa impormasyon))). Ang index bloat ay lalong kapansin-pansin sa mga workload kung saan ang index ay aktibong nagbabago.
Ang PostgreSQL 12 ay lubos na nagpapabuti sa pagganap ng mga B-tree index, at ipinakita ng mga eksperimento na may mga benchmark tulad ng TPC-C na sa average na 40% mas kaunting espasyo ang ginagamit na ngayon. Ngayon ay gumugugol kami ng mas kaunting oras hindi lamang sa pagpapanatili ng mga index ng B-tree (iyon ay, sa mga operasyon ng pagsulat), kundi pati na rin sa pagkuha ng data, dahil ang mga index ay mas maliit.
Mga application na aktibong nag-a-update ng kanilang mga talahanayan - karaniwang mga OLTP application () - gagamit ng disk at magproseso ng mga kahilingan nang mas mahusay. Ang mas maraming espasyo sa disk, mas maraming espasyo ang database ay kailangang lumago nang hindi ina-upgrade ang imprastraktura.
Ang ilang mga diskarte sa pag-upgrade ay nangangailangan ng muling pagbuo ng mga B-tree index upang samantalahin ang mga benepisyong ito (hal. hindi awtomatikong muling bubuo ng mga index). Sa mga nakaraang bersyon ng PostgreSQL, ang muling pagbuo ng malalaking index sa mga talahanayan ay nagresulta sa makabuluhang downtime dahil hindi maaaring gawin ang mga pagbabago sa pansamantala. Ngunit ang PostgreSQL 12 ay may isa pang cool na tampok: ngayon ay maaari mong muling itayo ang mga index na kahanay sa utos upang ganap na maiwasan ang downtime.
Mayroong iba pang mga pagpapabuti sa imprastraktura ng pag-index sa PostgreSQL 12. Isa pang bagay kung saan nagkaroon ng mahika - , aka WAL (write-ahead log). Itinatala ng write-ahead log ang bawat transaksyon sa PostgreSQL kung sakaling mabigo at pagtitiklop. Ginagamit ito ng mga application para sa pag-archive at . Siyempre, ang write-ahead log ay isinulat sa disk, na maaaring makaapekto sa pagganap.
Binawasan ng PostgreSQL 12 ang overhead ng mga tala ng WAL na nilikha ng mga index ng GiST, GIN, at SP-GiST sa panahon ng pagbuo ng index. Nagbibigay ito ng ilang nakikitang benepisyo: Ang mga tala ng WAL ay kumukuha ng mas kaunting espasyo sa disk, at ang data ay nire-replay nang mas mabilis, tulad ng sa panahon ng pagbawi ng kalamidad o pagbawi ng point-in-time. Kung gumagamit ka ng mga naturang index sa iyong mga application (halimbawa, ang mga geospatial na application na nakabatay sa PostGIS ay madalas na gumagamit ng GiST index), ito ay isa pang tampok na makabuluhang magpapahusay sa karanasan nang walang anumang pagsisikap sa iyong bahagi.
Paghati - mas malaki, mas mahusay, mas mabilis
Ipinakilala ang PostgreSQL 10 . Sa PostgreSQL 11 ito ay naging mas madaling gamitin. Sa PostgreSQL 12 maaari mong baguhin ang sukat ng mga seksyon.
Sa PostgreSQL 12, ang pagganap ng partitioning system ay naging mas mahusay, lalo na kung mayroong libu-libong mga partisyon sa talahanayan. Halimbawa, kung ang isang query ay makakaapekto lamang sa ilang mga partisyon sa isang talahanayan na may libu-libo sa kanila, ito ay isasagawa nang mas mabilis. Ang pagganap ay hindi lamang pinabuting para sa mga ganitong uri ng mga query. Mapapansin mo rin kung gaano kabilis ang mga operasyon ng INSERT sa mga talahanayan na may maraming partition.
Pagre-record ng data gamit ang - sa pamamagitan ng paraan, ito ay isang mahusay na paraan at narito ang isang halimbawa β ang mga naka-partition na talahanayan sa PostgreSQL 12 ay naging mas mahusay din. Sa COPY ang lahat ay mabilis na, ngunit sa PostgreSQL 12 ito ay ganap na lumilipad.
Salamat sa mga pakinabang na ito, pinapayagan ka ng PostgreSQL na mag-imbak ng mas malalaking set ng data at gawing mas madaling makuha ang mga ito. At walang effort sa part mo. Kung ang application ay may maraming mga partisyon, tulad ng pagtatala ng data ng serye ng oras, ang isang simpleng pag-upgrade ay makabuluhang mapabuti ang pagganap nito.
Bagama't hindi ito eksaktong pagpapabuti ng "pag-upgrade at pag-enjoy", pinapayagan ka ng PostgreSQL 12 na lumikha ng mga dayuhang key na tumutukoy sa mga naka-partition na talahanayan, na ginagawang kasiyahan ang paghati sa trabaho.
WITH query just got a lot better
Kapag (aka CTE, aka WITH query), hindi ako makapaghintay na magsulat ng isang artikulo tungkol sa . Isa ito sa mga feature na magpapabilis sa application. Maliban kung, siyempre, gumamit ka ng CTE.
Madalas kong makita na ang mga baguhan sa SQL ay gustong gumamit ng mga CTE; kung isusulat mo ang mga ito sa isang tiyak na paraan, talagang parang sumusulat ka ng isang kinakailangang programa. Sa personal, nagustuhan kong muling isulat ang mga query na ito para makalibot wala CTE at pataasin ang produktibidad. Ngayon iba na ang lahat.
Binibigyang-daan ka ng PostgreSQL 12 na mag-inline ng isang partikular na uri ng CTE nang walang mga side effect (SELECT), na isang beses lang ginagamit malapit sa dulo ng kahilingan. Kung sinusubaybayan ko ang mga query sa CTE na muling isinulat ko, karamihan sa mga ito ay mahuhulog sa kategoryang ito. Nakakatulong ito sa mga developer na magsulat ng malinaw na code na ngayon ay mabilis ding tumatakbo.
Bukod dito, ang PostgreSQL 12 ay nag-optimize ng SQL execution mismo, nang hindi mo kailangang gawin. At kahit na malamang na hindi ko na kailangang i-optimize ang mga naturang query ngayon, ito ay mahusay na ang PostgreSQL ay patuloy na gumagana sa query optimization.
Just-in-Time (JIT) - default na ngayon
Sa PostgreSQL 12 system na may suporta Ang JIT compilation ay pinagana bilang default. Una sa lahat, nakakakuha ka ng suporta para sa ilang panloob na operasyon, at pangalawa, ang mga query na may mga expression (ang pinakasimpleng halimbawa ay x + y) sa mga piling listahan (na mayroon ka pagkatapos ng SELECT), mga pinagsama-samang, mga expression na may mga sugnay na WHERE at iba pa ay maaaring gumamit ng JIT upang mapabuti ang pagganap.
Dahil ang JIT ay pinagana bilang default sa PostgreSQL 12, ang pagganap ay magpapabuti sa sarili nitong, ngunit inirerekumenda kong subukan ang application sa PostgreSQL 11, na nagpakilala sa JIT, upang sukatin ang pagganap ng query at makita kung kailangan mong ibagay ang anuman.
Paano ang iba pang mga bagong tampok sa PostgreSQL 12?
Ang PostgreSQL 12 ay may isang tonelada ng mga cool na bagong tampok, mula sa kakayahang galugarin ang data ng JSON gamit ang karaniwang mga expression ng ruta ng SQL/JSON hanggang sa multi-factor na pagpapatunay na may isang parameter clientcert=verify-full, gumawa ng mga column at marami pang iba. Sapat na para sa isang hiwalay na post.
Tulad ng PostgreSQL 10, mapapabuti ng PostgreSQL 12 ang pangkalahatang pagganap kaagad pagkatapos ng pag-upgrade. Siyempre, maaari kang magkaroon ng iyong sariling landas - subukan ang application sa ilalim ng mga katulad na kondisyon sa sistema ng produksyon bago paganahin ang mga pagpapabuti, tulad ng ginawa ko sa PostgreSQL 10. Kahit na ang PostgreSQL 12 ay mas matatag kaysa sa inaasahan ko, huwag maging tamad sa pagsubok mga aplikasyon nang lubusan, bago ilabas ang mga ito sa produksyon.
Pinagmulan: www.habr.com