PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11

Have a great Friday everyone! Kaunti at kaunting oras ang natitira bago ang paglulunsad ng kurso "Relational DBMS", kaya ngayon ibinabahagi namin ang pagsasalin ng isa pang kapaki-pakinabang na materyal sa paksa.

Sa yugto ng pag-unlad PostgreSQL 11 Nagkaroon ng ilang kahanga-hangang gawaing ginawa upang mapabuti ang paghahati ng talahanayan. Paghahati ng mga talahanayan - ito ay isang function na umiral sa PostgreSQL sa loob ng mahabang panahon, ngunit ito, kung sabihin, mahalagang hindi umiiral hanggang sa bersyon 10, kung saan ito ay naging isang napaka-kapaki-pakinabang na function. Nauna naming sinabi na ang table inheritance ay ang aming pagpapatupad ng partitioning, at ito ay totoo. Tanging ang pamamaraang ito ang nagpilit sa iyo na gawin ang karamihan sa gawain nang manu-mano. Halimbawa, kung gusto mong maipasok ang mga tuple sa mga seksyon sa panahon ng mga INSERT, kailangan mong i-configure ang mga trigger upang gawin ito para sa iyo. Ang paghahati sa pamamagitan ng mana ay napakabagal at mahirap na bumuo ng karagdagang pag-andar sa itaas.

Sa PostgreSQL 10, nakita namin ang pagsilang ng "declarative partitioning," isang tampok na idinisenyo upang malutas ang maraming problema na hindi malulutas gamit ang lumang paraan ng pamana. Ito ay humantong sa isang mas malakas na tool na nagpapahintulot sa amin na hatiin ang data nang pahalang!

Paghahambing ng tampok

Ipinakilala ng PostgreSQL 11 ang isang kahanga-hangang hanay ng mga bagong feature na tumutulong sa pagpapahusay ng performance at gawing mas transparent ang mga naka-partition na talahanayan sa mga application.

PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11
PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11
PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11
1. Paggamit ng Limiting Exceptions
2. Nagdaragdag lamang ng mga node
3. Para lamang sa isang partitioned table na tumutukoy sa isang non-partitioned
4. Dapat maglaman ang mga index ng lahat ng mga pangunahing column ng partition
5. Dapat magkatugma ang mga paghihigpit sa seksyon sa magkabilang panig

Pagiging Produktibo

May good news din tayo dito! Idinagdag ang bagong paraan pagtanggal ng mga seksyon. Maaaring matukoy ng bagong algorithm na ito ang mga angkop na seksyon sa pamamagitan ng pagtingin sa kondisyon ng query WHERE. Ang nakaraang algorithm, sa turn, ay nagsuri sa bawat seksyon upang matukoy kung matutugunan nito ang kundisyon WHERE. Nagresulta ito sa karagdagang pagtaas sa oras ng pagpaplano habang dumami ang bilang ng mga seksyon.

Sa 9.6, na may partitioning sa pamamagitan ng inheritance, ang pagruruta ng mga tuple sa mga partition ay karaniwang ginagawa sa pamamagitan ng pagsusulat ng trigger function na naglalaman ng isang serye ng mga IF statement para ipasok ang tuple sa tamang partition. Ang mga pag-andar na ito ay maaaring napakabagal sa pagpapatupad. Sa deklaratibong partitioning idinagdag sa bersyon 10, ito ay gumagana nang mas mabilis.

Gamit ang isang partitioned table na may 100 partition, masusuri natin ang performance ng paglo-load ng 10 milyong row sa isang table na may 1 BIGINT column at 5 INT column.

PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11

Pagganap ng pag-query sa talahanayang ito upang makahanap ng isang naka-index na tala at magsagawa ng DML upang manipulahin ang isang tala (gamit lamang ang 1 processor):

PostgreSQL 11: Ebolusyon ng pagkahati mula sa Postgres 9.6 hanggang Postgres 11

Dito makikita natin na ang pagganap ng bawat operasyon ay tumaas nang malaki mula noong PG 9.6. Mga kahilingan SELECT mas maganda ang hitsura, lalo na ang mga may kakayahang magbukod ng maraming partisyon sa panahon ng pagpaplano ng query. Nangangahulugan ito na maaaring laktawan ng scheduler ang maraming gawain na dapat ay nagawa na nito noon pa. Halimbawa, ang mga landas ay hindi na binuo para sa mga hindi kinakailangang seksyon.

Konklusyon

Nagsisimula nang maging napakalakas na feature sa PostgreSQL ang paghahati ng talahanayan. Binibigyang-daan ka nitong mabilis na magpakita ng data online at dalhin ito offline nang hindi naghihintay na makumpleto ang mabagal, napakalaking pagpapatakbo ng DML.. Nangangahulugan din ito na ang kaugnay na data ay maaaring maimbak nang magkasama, ibig sabihin, ang data na kailangan mo ay maaaring ma-access nang mas mahusay. Ang mga pagpapahusay na ginawa sa bersyong ito ay hindi magiging posible kung wala ang mga developer, reviewer at committer na walang pagod na nagtrabaho sa lahat ng mga feature na ito.
Salamat sa kanilang lahat! Ang PostgreSQL 11 ay mukhang hindi kapani-paniwala!

Narito ang isang maikli ngunit medyo kawili-wiling artikulo. Ibahagi ang iyong mga komento at huwag kalimutang mag-sign up para sa Bukas na Araw, kung saan ang programa ng kurso ay ilalarawan nang detalyado.

Pinagmulan: www.habr.com

Magdagdag ng komento