Uwchraddio ar gyfer y diog: sut mae PostgreSQL 12 yn gwella perfformiad

Uwchraddio ar gyfer y diog: sut mae PostgreSQL 12 yn gwella perfformiad

PostgreSQL 12, mae'r fersiwn ddiweddaraf o “gronfa ddata berthynol ffynhonnell agored orau'r byd,” yn dod allan mewn ychydig wythnosau (os aiff popeth yn unol â'r cynllun). Mae hyn yn dilyn yr amserlen arferol o ryddhau fersiwn newydd gyda thunnell o nodweddion newydd unwaith y flwyddyn, ac a dweud y gwir, mae hynny'n drawiadol. Dyna pam y deuthum yn aelod gweithgar o gymuned PostgreSQL.

Yn fy marn i, yn wahanol i ddatganiadau blaenorol, nid yw PostgreSQL 12 yn cynnwys un neu ddau o nodweddion chwyldroadol (fel rhaniad neu gyfochredd ymholiad). Fe wnes i cellwair unwaith mai prif nodwedd PostgreSQL 12 yw mwy o sefydlogrwydd. Onid dyna sydd ei angen arnoch pan fyddwch yn rheoli data hanfodol eich busnes?

Ond nid yw PostgreSQL 12 yn stopio yno: gyda nodweddion a gwelliannau newydd, bydd cymwysiadau'n perfformio'n well, a'r cyfan sydd angen i chi ei wneud yw uwchraddio!

(Wel, efallai ailadeiladu'r mynegeion, ond yn y datganiad hwn nid yw mor frawychus ag yr ydym wedi arfer ag ef.)

Bydd yn wych uwchraddio PostgreSQL a mwynhau gwelliannau sylweddol ar unwaith heb ffwdan diangen. Ychydig flynyddoedd yn ôl, adolygais uwchraddiad o PostgreSQL 9.4 i PostgreSQL 10 a gwelais sut y cyflymodd y cais diolch i'r cyfochredd ymholiad gwell yn PostgreSQL 10. Ac, yn bwysicaf oll, nid oedd angen bron dim oddi wrthyf (dim ond gosod paramedr cyfluniad max_parallel_workers).

Cytuno, mae'n gyfleus pan fydd cymwysiadau'n gweithio'n well yn syth ar ôl uwchraddio. Ac rydyn ni'n ymdrechu'n galed iawn i blesio defnyddwyr, oherwydd mae gan PostgreSQL fwy a mwy ohonyn nhw.

Felly sut y gall uwchraddiad syml i PostgreSQL 12 eich gwneud chi'n hapus? Fe ddywedaf wrthych yn awr.

Gwelliannau mynegeio mawr

Heb fynegeio, ni fydd cronfa ddata yn mynd yn bell. Sut arall allwch chi ddod o hyd i wybodaeth yn gyflym? Gelwir system mynegeio sylfaenol PostgreSQL B-coed. Mae'r math hwn o fynegai wedi'i optimeiddio ar gyfer systemau storio.

Yn syml, rydym yn defnyddio'r gweithredwr CREATE INDEX ON some_table (some_column), ac mae PostgreSQL yn gwneud llawer o waith i gadw'r mynegai yn gyfredol tra byddwn yn mewnosod, diweddaru a dileu gwerthoedd yn gyson. Mae popeth yn gweithio ar ei ben ei hun, fel pe bai trwy hud.

Ond mae gan fynegeion PostgreSQL un broblem - nhw yn cael eu chwyddo a chymryd mwy o le ar y ddisg a lleihau perfformiad adfer a diweddaru data. Wrth "bloat" rwy'n golygu cynnal y strwythur mynegai yn aneffeithiol. Gall hyn - neu beidio - fod yn gysylltiedig â'r tuples sothach y mae'n eu tynnu VACUUM (diolch i Peter Gaghan am y wybodaeth)Peter Geoghegan)). Mae bloat mynegai yn arbennig o amlwg mewn llwythi gwaith lle mae'r mynegai yn newid yn weithredol.

Mae PostgreSQL 12 yn gwella perfformiad mynegeion coed B yn fawr, ac mae arbrofion gyda meincnodau fel TPC-C wedi dangos bod 40% yn llai o le yn cael ei ddefnyddio bellach ar gyfartaledd. Nawr rydym yn treulio llai o amser nid yn unig ar gynnal mynegeion coed B (hynny yw, ar weithrediadau ysgrifennu), ond hefyd ar adfer data, oherwydd bod y mynegeion yn llawer llai.

Cymwysiadau sy'n diweddaru eu tablau yn weithredol - yn nodweddiadol cymwysiadau OLTP (prosesu trafodion amser real) - yn defnyddio disgiau ac yn prosesu ceisiadau yn llawer mwy effeithlon. Po fwyaf o le ar ddisg, y mwyaf o le sydd gan y gronfa ddata i dyfu heb uwchraddio'r seilwaith.

Mae rhai strategaethau uwchraddio yn gofyn am ailadeiladu mynegeion coed B i fanteisio ar y buddion hyn (e.e. pg_uwchraddio ni fydd yn ailadeiladu mynegeion yn awtomatig). Mewn fersiynau blaenorol o PostgreSQL, arweiniodd ailadeiladu mynegeion mawr ar dablau at amser segur sylweddol oherwydd na ellid gwneud newidiadau yn y cyfamser. Ond mae gan PostgreSQL 12 nodwedd oer arall: nawr gallwch chi ailadeiladu mynegeion ochr yn ochr â'r gorchymyn REINDEX YN GYDOLi osgoi amser segur yn llwyr.

Mae gwelliannau eraill i'r seilwaith mynegeio yn PostgreSQL 12. Peth arall lle roedd rhywfaint o hud - log ysgrifennu ymlaen llaw, aka WAL (lòg ysgrifennu ymlaen llaw). Mae log ysgrifennu ymlaen llaw yn cofnodi pob trafodiad yn PostgreSQL rhag ofn y bydd methiant ac atgynhyrchu. Mae cymwysiadau yn ei ddefnyddio ar gyfer archifo a adferiad pwynt-mewn-amser. Wrth gwrs, mae'r log ysgrifennu ymlaen llaw yn cael ei ysgrifennu i ddisg, a all effeithio ar berfformiad.

Mae PostgreSQL 12 wedi lleihau gorbenion cofnodion CIY sy'n cael eu creu gan fynegeion GiST, GIN, a SP-GiST yn ystod adeiladu'r mynegai. Mae hyn yn darparu nifer o fanteision diriaethol: mae cofnodion WAL yn cymryd llai o le ar ddisg, ac mae data'n cael ei ailchwarae'n gyflymach, megis yn ystod adferiad ar ôl trychineb neu adferiad pwynt-mewn-amser. Os ydych chi'n defnyddio mynegeion o'r fath yn eich cymwysiadau (er enghraifft, mae cymwysiadau geo-ofodol sy'n seiliedig ar PostGIS yn defnyddio'r mynegai GiST yn aml), mae hon yn nodwedd arall a fydd yn gwella'r profiad yn sylweddol heb unrhyw ymdrech ar eich rhan chi.

Rhaniadu - mwy, gwell, cyflymach

Cyflwynwyd PostgreSQL 10 rhaniad datganiadol. Yn PostgreSQL 11 mae wedi dod yn llawer haws i'w ddefnyddio. Yn PostgreSQL 12 gallwch newid graddfa'r adrannau.

Yn PostgreSQL 12, mae perfformiad y system rhaniad wedi gwella'n sylweddol, yn enwedig os oes miloedd o raniadau yn y tabl. Er enghraifft, os yw ymholiad yn effeithio ar ychydig o raniad yn unig mewn tabl gyda miloedd ohonynt, bydd yn gweithredu'n llawer cyflymach. Nid dim ond ar gyfer y mathau hyn o ymholiadau y mae perfformiad wedi gwella. Byddwch hefyd yn sylwi pa mor gyflym y mae gweithrediadau INSERT ar fyrddau gyda pharwydydd lluosog.

Cofnodi data gan ddefnyddio COPI - gyda llaw, mae hon yn ffordd wych lawrlwytho data swmp a dyma enghraifft yn derbyn JSON — mae tablau rhanedig yn PostgreSQL 12 hefyd wedi dod yn fwy effeithlon. Gyda COPY roedd popeth eisoes yn gyflym, ond yn PostgreSQL 12 mae'n hedfan yn llwyr.

Diolch i'r manteision hyn, mae PostgreSQL yn caniatáu ichi storio setiau data hyd yn oed yn fwy a'u gwneud yn haws i'w hadalw. A dim ymdrech ar eich rhan. Os oes gan y cais lawer o raniad, megis cofnodi data cyfres amser, bydd uwchraddiad syml yn gwella ei berfformiad yn sylweddol.

Er nad yw hwn yn welliant "uwchraddio a mwynhau" yn union, mae PostgreSQL 12 yn caniatáu ichi greu allweddi tramor sy'n cyfeirio at dablau rhanedig, gan wneud rhaniad yn bleser gweithio gydag ef.

Gydag ymholiadau newydd wella o lawer

Pan fydd cymhwyswyd clwt ar gyfer mynegiadau tabl cyffredin adeiledig (aka CTE, aka WITH ymholiadau), allwn i ddim aros i ysgrifennu erthygl am pa mor hapus oedd datblygwyr cymwysiadau gyda PostgreSQL. Dyma un o'r nodweddion hynny a fydd yn cyflymu'r cais. Oni bai, wrth gwrs, eich bod yn defnyddio CTE.

Rwy'n aml yn gweld bod newbies i SQL wrth eu bodd yn defnyddio CTEs; os ydych chi'n eu hysgrifennu mewn ffordd benodol, mae'n wir yn teimlo eich bod chi'n ysgrifennu rhaglen hanfodol. Yn bersonol, roeddwn i'n hoffi ailysgrifennu'r ymholiadau hyn i fynd o gwmpas без CTE a chynyddu cynhyrchiant. Nawr mae popeth yn wahanol.

Mae PostgreSQL 12 yn caniatáu ichi fewnlinio math penodol o CTE heb sgîl-effeithiau (SELECT), a ddefnyddir unwaith yn unig yn agos at ddiwedd y cais. Pe bawn i'n cadw golwg ar yr ymholiadau CTE a ailysgrifennais, byddai'r rhan fwyaf ohonynt yn perthyn i'r categori hwn. Mae hyn yn helpu datblygwyr i ysgrifennu cod clir sydd bellach yn rhedeg yn gyflym hefyd.

Ar ben hynny, mae PostgreSQL 12 yn gwneud y gorau o gyflawni SQL ei hun, heb i chi orfod gwneud unrhyw beth. Ac er ei bod yn debyg na fydd angen i mi wneud y gorau o ymholiadau o'r fath nawr, mae'n wych bod PostgreSQL yn parhau i weithio ar optimeiddio ymholiadau.

Mewn union bryd (JIT) - rhagosodedig nawr

Ar systemau PostgreSQL 12 gyda chefnogaeth LLVM Mae llunio JIT wedi'i alluogi yn ddiofyn. Yn gyntaf oll, rydych chi'n cael cefnogaeth JIT ar gyfer rhai gweithrediadau mewnol, ac yn ail, ymholiadau gydag ymadroddion (yr enghraifft symlaf yw x + y) mewn rhestrau dethol (sydd gennych ar ôl SELECT), agregau, mynegiadau gyda chymalau LLE ac eraill yn gallu defnyddio JIT i wella perfformiad.

Gan fod JIT wedi'i alluogi yn ddiofyn yn PostgreSQL 12, bydd perfformiad yn gwella ar ei ben ei hun, ond rwy'n argymell profi'r cais yn PostgreSQL 11, a gyflwynodd JIT, i fesur perfformiad ymholiad a gweld a oes angen i chi diwnio unrhyw beth.

Beth am weddill y nodweddion newydd yn PostgreSQL 12?

Mae gan PostgreSQL 12 dunnell o nodweddion newydd cŵl, o'r gallu i archwilio data JSON gan ddefnyddio mynegiadau llwybr safonol SQL/JSON i ddilysu aml-ffactor gyda pharamedr clientcert=verify-full, creu colofnau a llawer mwy. Digon ar gyfer post ar wahân.

Fel PostgreSQL 10, bydd PostgreSQL 12 yn gwella perfformiad cyffredinol yn syth ar ôl yr uwchraddio. Gallwch chi, wrth gwrs, gael eich llwybr eich hun - profwch y cais o dan amodau tebyg ar y system gynhyrchu cyn galluogi gwelliannau, fel y gwnes i gyda PostgreSQL 10. Hyd yn oed os yw PostgreSQL 12 eisoes yn fwy sefydlog nag yr oeddwn yn ei ddisgwyl, peidiwch â bod yn ddiog wrth brofi ceisiadau yn drylwyr, cyn eu rhyddhau i gynhyrchu.

Ffynhonnell: hab.com

Ychwanegu sylw