Postgres: bloat, pg_repack agus cuingeadan air an cur dheth

Tha fios farsaing air a’ bhuaidh a th’ aig bloat air bùird agus clàran-amais agus tha e an làthair chan ann a-mhàin ann am Postgres. Tha dòighean ann dèiligeadh ris a-mach às a’ bhogsa, leithid VACUUM FULL no CLUSTER, ach bidh iad a’ glasadh chlàran fhad ‘s a tha iad ag obair agus mar sin chan urrainnear an cleachdadh an-còmhnaidh.

Bidh beagan teòiridh anns an artaigil mu mar a tha bloat a ’tachairt, mar as urrainn dhut a shabaid, mu chuingealachaidhean dàil agus na duilgheadasan a bheir iad gu cleachdadh an leudachadh pg_repack.

Tha an artaigil seo stèidhichte air mo chainnt aig PgConf.Russia 2020.

Carson a tha bloat a 'tachairt?

Tha Postgres stèidhichte air modal ioma-dreach (MVCC). Is e an t-adhbhar a th 'ann gum faod grunn dhreachan a bhith aig gach sreath sa chlàr, fhad' s nach eil gnothaichean a 'faicinn barrachd air aon de na dreachan sin, ach chan e gu feum an aon fhear. Leigidh seo le grunn ghnothaichean obrachadh aig an aon àm agus cha mhòr nach eil buaidh sam bith aca air a chèile.

Gu follaiseach, feumar na dreachan sin uile a stòradh. Bidh Postgres ag obair le cuimhne duilleag air duilleag agus is e duilleag an ìre as lugha de dhàta a ghabhas leughadh bho dhiosg no sgrìobhte. Bheir sinn sùil air eisimpleir bheag gus tuigsinn mar a thachras seo.

Canaidh sinn gu bheil clàr againn ris an do chuir sinn grunn chlàran ris. Tha dàta ùr air nochdadh air a’ chiad duilleag den fhaidhle far a bheil an clàr air a stòradh. Is iad sin dreachan beò de shreathan a tha rim faighinn do ghnothaichean eile às deidh gealltanas (airson sìmplidh, gabhaidh sinn ris gu bheil an ìre aonaranachd Leugh Dealaichte).

An uairsin dh’ ùraich sinn aon de na h-inntrigidhean, agus mar sin a’ comharrachadh an t-seann dreach mar nach eil iomchaidh tuilleadh.

Ceum air cheum, ag ùrachadh agus a’ cuir às do dhreachan sreath, chrìochnaich sinn le duilleag anns a bheil timcheall air leth den dàta mar “sgudal”. Chan eil an dàta seo ri fhaicinn do ghnothach sam bith.

Tha uidheamachd aig Postgres VACUUM, a bhios a’ glanadh tionndaidhean nach eil air an cleachdadh agus a’ dèanamh rùm airson dàta ùr. Ach mura h-eil e air a rèiteachadh gu làidir gu leòr no ma tha e trang ag obair ann an clàran eile, tha “dàta sgudail” fhathast ann, agus feumaidh sinn duilleagan a bharrachd a chleachdadh airson dàta ùr.

Mar sin nar n-eisimpleir, aig àm air choreigin bidh ceithir duilleagan anns a’ chlàr, ach cha bhi dàta beò ann ach leth dheth. Mar thoradh air an sin, nuair a gheibh sinn cothrom air a’ chlàr, leughaidh sinn tòrr a bharrachd dàta na tha riatanach.

Fiù ma tha VACUUM a-nis a’ cuir às do gach dreach sreath neo-iomchaidh, cha tig adhartas mòr air an t-suidheachadh. Bidh àite an-asgaidh againn ann an duilleagan no eadhon duilleagan slàn airson sreathan ùra, ach bidh sinn fhathast a’ leughadh barrachd dàta na tha riatanach.
Air an t-slighe, nam biodh duilleag gu tur falamh (an dàrna fear san eisimpleir againn) aig deireadh an fhaidhle, bhiodh e comasach dha VACUUM a ghearradh. Ach a-nis tha i sa mheadhan, agus mar sin chan urrainnear dad a dhèanamh leatha.

Nuair a dh'fhàsas an àireamh de dhuilleagan falamh no gu math tearc, ris an canar bloat, bidh e a 'tòiseachadh a' toirt buaidh air coileanadh.

Is e a h-uile dad a tha air a mhìneachadh gu h-àrd meacanaig tachartas bloat ann an clàran. Ann an clàran-amais tha seo a’ tachairt gu ìre mhòr san aon dòigh.

A bheil bloat agam?

Tha grunn dhòighean ann gus faighinn a-mach a bheil bloat agad. Is e am beachd a’ chiad fhear staitistig Postgres a-staigh a chleachdadh, anns a bheil fiosrachadh tuairmseach mun àireamh de shreathan ann an clàran, an àireamh de shreathan “beò”, msaa. Ghabh sinn mar bhunait sgriobt bho PostgreSQL Experts, as urrainn bùird bloat a mheasadh còmhla ri clàran-amais toast agus bloat btree. Anns an eòlas againn, tha a mhearachd 10-20%.

Is e dòigh eile an leudachadh a chleachdadh pg reachd, a leigeas leat coimhead taobh a-staigh nan duilleagan agus faigh an dà chuid tuairmse agus luach bloat ceart. Ach anns an dàrna cùis, feumaidh tu an clàr gu lèir a sganadh.

Tha sinn den bheachd gu bheil luach bloat beag, suas ri 20%, iomchaidh. Faodar a mheas mar analogue de fillfactor airson bùird и clàran-amais. Aig 50% agus nas àirde, faodaidh duilgheadasan coileanaidh tòiseachadh.

Dòighean gus sabaid an aghaidh bloat

Tha grunn dhòighean aig Postgres dèiligeadh ri bloat a-mach às a 'bhogsa, ach chan eil iad an-còmhnaidh freagarrach airson a h-uile duine.

Dèan rèiteachadh air AUTOVACUUM gus nach tachair bloat. No nas mionaidiche, airson a chumail aig ìre iomchaidh dhut. Tha e coltach gur e comhairle “caiptean” a tha seo, ach ann an da-rìribh chan eil seo an-còmhnaidh furasta a choileanadh. Mar eisimpleir, tha leasachadh gnìomhach agad le atharrachaidhean cunbhalach air an sgeama dàta, no tha seòrsa de dh'imrich dàta a 'tachairt. Mar thoradh air an sin, faodaidh do phròifil luchd atharrachadh gu tric agus mar as trice bidh e ag atharrachadh bho bhòrd gu clàr. Tha seo a’ ciallachadh gum feum thu a bhith ag obair beagan air adhart gu cunbhalach agus AUTOVACUUM atharrachadh gu ìomhaigh caochlaideach gach clàr. Ach gu follaiseach chan eil seo furasta a dhèanamh.

Is e adhbhar cumanta eile nach urrainn AUTOVACUUM cumail suas ri clàran leis gu bheil gnothaichean fad-ùine ann a chuireas casg air bho bhith a’ glanadh an dàta a tha ri fhaighinn leis na gnothaichean sin. Tha am moladh an seo cuideachd follaiseach - cuir às do ghnothaichean “cronnach” agus lughdaich ùine nan gnothaichean gnìomhach. Ach ma tha an luchd air an tagradh agad na mheasgachadh de OLAP agus OLTP, faodaidh tu aig an aon àm mòran ùrachaidhean tric agus ceistean goirid a bhith agad, a bharrachd air gnìomhachd fad-ùine - mar eisimpleir, togail aithisg. Ann an suidheachadh mar sin, is fhiach smaoineachadh mu bhith a 'sgaoileadh an luchd thairis air diofar bhunaitean, a leigeas le gach fear dhiubh a bhith nas mionaidiche.

Eisimpleir eile - eadhon ged a tha am pròifil aon-ghnèitheach, ach gu bheil an stòr-dàta fo luchd gu math àrd, is dòcha nach bi eadhon an AUTOVACUUM as ionnsaigheach a ’dèiligeadh, agus thig bloat. Is e sgèileadh (dìreach no còmhnard) an aon fhuasgladh.

Dè a nì thu ann an suidheachadh far a bheil thu air AUTOVACUUM a stèidheachadh, ach tha am bloat a 'sìor fhàs.

sgioba VACUUM LÀN ag ath-thogail susbaint chlàran is chlàran-amais agus a’ fàgail dìreach dàta buntainneach annta. Gus cuir às do bloat, bidh e ag obair gu foirfe, ach nuair a thèid a chuir gu bàs tha glas sònraichte air a ’bhòrd air a ghlacadh (AccessExclusiveLock), nach leig le ceistean a chuir an gnìomh air a’ chlàr seo, eadhon tagh. Mas urrainn dhut stad a chuir air do sheirbheis no pàirt dheth airson ùine (bho dheich mionaidean gu grunn uairean a thìde a rèir meud an stòr-dàta agus am bathar-cruaidh agad), is e an roghainn seo as fheàrr. Gu mì-fhortanach, chan eil ùine againn VACUUM FULL a ruith rè an cumail suas clàraichte, agus mar sin chan eil an dòigh seo freagarrach dhuinn.

sgioba CLAR Ag ath-thogail susbaint chlàran san aon dòigh ri VACUUM FULL, ach a ’leigeil leat clàr-amais a shònrachadh a rèir an tèid an dàta òrdachadh gu corporra air diosc (ach san àm ri teachd chan eil an òrdugh cinnteach airson sreathan ùra). Ann an suidheachaidhean sònraichte, tha seo na dheagh optimization airson grunn cheistean - le bhith a 'leughadh ioma-chlàran le clàr-amais. Tha ana-cothrom na h-àithne an aon rud ri VACUUM FULL - bidh e a’ glasadh a’ bhùird rè obrachadh.

sgioba REINDEX coltach ris an dà roimhe, ach ag ath-thogail clàr-amais sònraichte no a h-uile clàr-amais den chlàr. Tha glasan beagan nas laige: ShareLock air a’ bhòrd (a’ cur casg air atharrachaidhean, ach a’ ceadachadh taghadh) agus AccessExclusiveLock air a’ chlàr-amais ga ath-thogail (bacadh cheistean a’ cleachdadh a’ chlàr-amais seo). Ach, anns an 12mh dreach de Postgres nochd paramadair A CHRUTHACHADH, a leigeas leat an clàr-amais ath-thogail gun a bhith a’ cur bacadh air cur-ris, atharrachadh no cuir às do chlàran aig an aon àm.

Ann an dreachan nas tràithe de Postgres, faodaidh tu toradh coltach ri REINDEX CONCURRENTLY a ’cleachdadh CRUTHACHADH CLÀR-INNSIDH AIRSON. Leigidh e leat clàr-amais a chruthachadh gun ghlasadh teann (ShareUpdateExclusiveLock, nach cuir bacadh air ceistean co-shìnte), an uairsin cuir fear ùr an àite an t-seann chlàr-amais agus cuir às don t-seann chlàr-amais. Leigidh seo leat cuir às do bloat clàr-amais gun a bhith a’ cur bacadh air an tagradh agad. Tha e cudromach beachdachadh nuair a bhios tu ag ath-thogail clàran-amais gum bi eallach a bharrachd air an fho-shiostam diosc.

Mar sin, ma tha dòighean ann airson clàran-amais cuir às do bloat “air an iteig,” chan eil gin ann airson bùird. Seo far a bheil diofar leudachaidhean taobh a-muigh a’ tighinn a-steach: pg_repack (pg_reorg roimhe), pgcompact, pgcompacttable agus feadhainn eile. San artaigil seo, cha dèan mi coimeas eadar iad agus cha bhith mi a ’bruidhinn ach mu dheidhinn pg_repack, a bhios, às deidh beagan atharrachaidh, a’ cleachdadh sinn fhìn.

Mar a tha pg_repack ag obair

Canaidh sinn gu bheil clàr gu tur àbhaisteach againn - le clàran-amais, cuingealachaidhean agus, gu mì-fhortanach, le bloat. Is e a’ chiad cheum de pg_repack clàr log a chruthachadh gus dàta a stòradh mu gach atharrachadh fhad ‘s a tha e a’ ruith. Bidh an inneal-brosnachaidh ag ath-aithris na h-atharrachaidhean sin airson gach cuir a-steach, ùrachadh agus cuir às. An uairsin thèid clàr a chruthachadh, coltach ris an fhear thùsail ann an structar, ach às aonais clàran-amais agus cuingeachaidhean, gus nach cuir iad dàil air a ’phròiseas cuir a-steach dàta.

An uairsin, bidh pg_repack a ’gluasad an dàta bhon t-seann chlàr chun chlàr ùr, a’ sìoladh a-mach gu fèin-ghluasadach a h-uile sreath neo-iomchaidh, agus an uairsin a ’cruthachadh clàran-amais airson a’ bhùird ùr. Nuair a bhios na h-obraichean sin uile air an coileanadh, bidh atharrachaidhean a’ cruinneachadh anns a’ chlàr log.

Is e an ath cheum na h-atharrachaidhean a ghluasad chun chlàr ùr. Bidh an imrich air a dhèanamh thairis air grunn thursan, agus nuair a tha nas lugha na 20 inntrig air fhàgail anns a’ chlàr log, bidh pg_repack a’ faighinn glas làidir, ag imrich an dàta as ùire, agus a’ dol an àite an t-seann chlàr leis an fhear ùr ann an clàran siostam Postgres. Is e seo an aon ùine agus glè ghoirid nuair nach bi e comasach dhut obrachadh leis a’ bhòrd. Às deidh seo, thèid an seann bhòrd agus am bòrd le logaichean a dhubhadh às agus thèid àite a shaoradh san t-siostam faidhle. Tha am pròiseas deiseil.

Tha a h-uile dad a 'coimhead math ann an teòiridh, ach dè a thachras ann an cleachdadh? Rinn sinn deuchainn air pg_repack gun luchd agus fo luchd, agus rinn sinn sgrùdadh air an obair aige gun fhios nach biodh e ro-luath (ann am faclan eile, a’ cleachdadh Ctrl + C). Bha na deuchainnean uile deimhinneach.

Chaidh sinn dhan stòr bìdh - agus an uairsin cha deach a h-uile càil mar a bha dùil againn.

A 'chiad pancake air a reic

Air a’ chiad bhuidheann fhuair sinn mearachd mu bhith a’ briseadh cuingealachadh sònraichte:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

Bha clàr-amais ainm fèin-ghinte aig a’ chuingealachadh seo_16508 - chaidh a chruthachadh le pg_repack. Stèidhichte air na buadhan a tha air an toirt a-steach don sgrìobhadh aige, cho-dhùin sinn an cuingeachadh “ar” a tha a rèir sin. B’ e an duilgheadas a bh’ ann nach e cuingealachadh gu tur àbhaisteach a tha seo, ach cuingealachadh air a chuir dheth (cuingealachadh air a chuir dheth), i.e. thèid an dearbhadh aige a dhèanamh nas fhaide na an àithne sql, a tha a’ leantainn gu builean ris nach robh dùil.

Cuingeachaidhean dàil: carson a tha feum orra agus mar a tha iad ag obair

Beagan teòiridh mu chuingealachaidhean dàil.
Beachdaichidh sinn air eisimpleir shìmplidh: tha leabhar-stiùiridh againn de chàraichean le dà fheart - ainm agus òrdugh a 'chàir anns an eòlaire.

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

Canaidh sinn gum feumadh sinn a’ chiad agus an dàrna càr atharrachadh. Is e am fuasgladh sìmplidh a’ chiad luach ùrachadh chun dàrna fear, agus an dàrna fear chun chiad:

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

Ach nuair a bhios sinn a’ ruith a’ chòd seo, tha sinn an dùil ri briseadh bacaidh leis gu bheil òrdugh nan luachan sa chlàr gun samhail:

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

Ciamar as urrainn dhomh a dhèanamh ann an dòigh eadar-dhealaichte? Roghainn a h-aon: cuir luach a bharrachd an àite òrdugh a tha cinnteach nach bi e sa chlàr, mar eisimpleir “-1”. Ann am prògramadh, canar “ag iomlaid luachan dà chaochladair tro thrian.” Is e an aon eas-bhuannachd den dòigh seo an ùrachadh a bharrachd.

Roghainn a dhà: Ath-dhealbhaich am bòrd gus seòrsa dàta puing-fleòdraidh a chleachdadh airson luach an òrduigh an àite nan àireamhan iomlan. An uairsin, nuair a bhios tu ag ùrachadh an luach bho 1, mar eisimpleir, gu 2.5, bidh a ’chiad inntrigeadh gu fèin-ghluasadach“ a ’seasamh” eadar an dàrna agus an treas fear. Tha am fuasgladh seo ag obair, ach tha dà chuingealachadh ann. An toiseach, chan obraich e dhut ma thèid an luach a chleachdadh an àiteigin san eadar-aghaidh. San dàrna h-àite, a rèir dè cho mionaideach ‘s a tha an seòrsa dàta, bidh àireamh chuingealaichte de chuir a-steach a dh’ fhaodadh a bhith agad mus dèan thu ath-àireamhachadh air luachan a h-uile clàr.

Roghainn a trì: cuir a’ bhacadh dheth dheth gus nach tèid a sgrùdadh ach aig àm a’ gheallaidh:

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

Leis gu bheil loidsig ar ciad iarrtas a’ dèanamh cinnteach gu bheil na luachan uile gun samhail aig àm a’ gheallaidh, soirbhichidh e.

Tha an eisimpleir a chaidh a dheasbad gu h-àrd, gu dearbh, gu math synthetigeach, ach tha e a’ nochdadh a ’bheachd. Anns an tagradh againn, bidh sinn a ’cleachdadh cuingeadan dàil gus loidsig a chuir an gnìomh a tha an urra ri còmhstrithean fhuasgladh nuair a bhios luchd-cleachdaidh ag obair aig an aon àm le nithean widget co-roinnte air a’ bhòrd. Le bhith a’ cleachdadh a leithid de chuingealachaidhean leigidh sin leinn an còd tagraidh a dhèanamh beagan nas sìmplidhe.

San fharsaingeachd, a rèir an seòrsa cuingealachadh, tha trì ìrean granularity aig Postgres airson an sgrùdadh: ìrean sreath, malairt, agus faireachdainn.

Source: begriffs

Bithear an-còmhnaidh a’ sgrùdadh CHECK and NOT NULL aig ìre na loidhne; airson cuingeachaidhean eile, mar a chithear bhon chlàr, tha diofar roghainnean ann. Faodaidh tu barrachd a leughadh an seo.

Gus geàrr-chunntas goirid a dhèanamh, tha cuingealachaidhean dàil ann an grunn shuidheachaidhean a 'toirt seachad còd nas leughaidh agus nas lugha de dh' òrdughan. Ach, feumaidh tu pàigheadh ​​​​airson seo le bhith a 'dèanamh iom-fhillte air a' phròiseas dì-bhugachaidh, leis gu bheil a 'mhionaid a' tachairt agus a 'mhionaid a gheibh thu a-mach mu dheidhinn air an sgaradh ann an ùine. Is e duilgheadas eile a dh’ fhaodadh a bhith ann gur dòcha nach bi an neach-clàraidh an-còmhnaidh comasach air plana as fheàrr a thogail ma tha an t-iarrtas a’ toirt a-steach cuingealachadh dàil.

Leasachadh air pg_repack

Tha sinn air dèiligeadh ri dè na cuingeadan a chaidh a chuir dheth, ach ciamar a tha iad co-cheangailte ris an duilgheadas againn? Cuimhnichidh sinn a’ mhearachd a fhuair sinn na bu thràithe:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

Bidh e a’ tachairt nuair a thèid dàta a chopaigeadh bho chlàr log gu clàr ùr. Tha seo a' coimhead neònach oir... tha an dàta sa chlàr log air a ghealltainn còmhla ris an dàta sa chlàr stòr. Ma choinnicheas iad ri cuingealachaidhean a’ chiad chlàr, ciamar as urrainn dhaibh na h-aon chuingealachaidhean a bhriseadh anns an fhear ùr?

Mar a thionndaidh e, tha freumh na trioblaid na laighe anns a 'cheum roimhe de pg_repack, a tha a' cruthachadh clàran-amais a-mhàin, ach chan e cuingealachaidhean: bha cuingealachadh sònraichte aig an t-seann chlàr, agus chruthaich am fear ùr clàr-amais sònraichte na àite.

Tha e cudromach toirt fa-near an seo ma tha an cuingealachadh àbhaisteach agus gun a bhith air a chuir dheth, gu bheil an clàr-amais sònraichte a chaidh a chruthachadh na àite co-ionann ris a’ bhacadh seo, oir Tha cuingealachaidhean sònraichte ann am Postgres air an cur an gnìomh le bhith a’ cruthachadh clàr-amais gun samhail. Ach ann an cùis cuingealachadh dàil, chan eil an giùlan mar an ceudna, oir chan urrainnear an clàr-amais a chuir dheth agus tha e an-còmhnaidh air a sgrùdadh aig an àm a thèid an òrdugh sql a chuir gu bàs.

Mar sin, tha brìgh na trioblaid na laighe ann an "dàil" an t-seic: anns a 'chlàr tùsail tha e a' tachairt aig àm a 'gheallaidh, agus anns a' chlàr ùr aig an àm a thèid an òrdugh sql a chur gu bàs. Tha seo a’ ciallachadh gum feum sinn dèanamh cinnteach gun tèid na sgrùdaidhean a dhèanamh mar an ceudna anns gach cùis: an-còmhnaidh dàil no an-còmhnaidh sa bhad.

Mar sin dè na beachdan a bh’ againn?

Cruthaich clàr-amais coltach ri dàil

Is e a’ chiad bheachd an dà sgrùdadh a dhèanamh sa mhodh sa bhad. Dh’ fhaodadh seo grunn chuingealachaidhean meallta a ghineadh, ach ma tha glè bheag dhiubh ann, cha bu chòir seo buaidh a thoirt air obair luchd-cleachdaidh, leis gu bheil còmhstri mar sin nan suidheachadh àbhaisteach dhaibh. Bidh iad a ’tachairt, mar eisimpleir, nuair a thòisicheas dà neach-cleachdaidh a’ deasachadh an aon widget aig an aon àm, agus nach eil ùine aig teachdaiche an dàrna neach-cleachdaidh fiosrachadh fhaighinn gu bheil am widget mu thràth air a bhacadh airson deasachadh leis a ’chiad neach-cleachdaidh. Ann an suidheachadh mar sin, bidh am frithealaiche a’ diùltadh an dàrna neach-cleachdaidh, agus bidh an neach-dèiligidh aige a’ toirt air ais na h-atharrachaidhean agus a’ bacadh a’ widget. Beagan nas fhaide air adhart, nuair a chuireas a’ chiad neach-cleachdaidh crìoch air deasachadh, gheibh an dàrna fear fiosrachadh nach eil am widget air a bhacadh tuilleadh agus bidh e comasach dhaibh an gnìomh aca ath-aithris.

Gus dèanamh cinnteach gu bheil sgrùdaidhean an-còmhnaidh ann am modh nach deach a chuir dheth, chruthaich sinn clàr-amais ùr coltach ris a’ bhacadh tùsail a chaidh a chuir dheth:

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

Anns an àrainneachd deuchainn, cha d’ fhuair sinn ach beagan mhearachdan ris an robh dùil. Soirbheachas! Ruith sinn pg_repack a-rithist air cinneasachadh agus fhuair sinn 5 mearachdan air a’ chiad bhuidheann ann an uair a thìde de dh’ obair. Is e toradh iomchaidh a tha seo. Ach, mu thràth air an dàrna buidheann chaidh an àireamh de mhearachdan suas gu mòr agus bha againn ri stad a chuir air pg_repack.

Carson a thachair e? Tha an coltas gun tachair mearachd an urra ri cia mheud neach-cleachdaidh a tha ag obair leis na h-aon widgets aig an aon àm. A rèir choltais, aig an àm sin bha mòran nas lugha de dh’ atharrachaidhean farpaiseach ann leis an dàta air a stòradh air a’ chiad bhuidheann na bha air an fheadhainn eile, i.e. bha sinn dìreach “fortanach”.

Cha do dh’obraich am beachd. Aig an ìre sin, chunnaic sinn dà fhuasgladh eile: ath-sgrìobh an còd tagraidh againn gus cuir às do chuingealachaidhean dàil, no “teach” pg_repack gus obrachadh leotha. Thagh sinn an dàrna fear.

Cuir cuingeadan dàil bhon chlàr thùsail an àite clàran-amais sa chlàr ùr

Bha adhbhar an ath-sgrùdaidh follaiseach - ma tha cuingealachadh dàil air a 'chlàr tùsail, an uairsin airson an tè ùr feumaidh tu a leithid de chuingealachadh a chruthachadh, agus chan e clàr-amais.

Gus na h-atharrachaidhean againn a dhearbhadh, sgrìobh sinn deuchainn shìmplidh:

• clàr le cuingealachadh dàil agus aon chlàr;
• cuir a-steach dàta ann an lùb a tha an aghaidh clàr a tha ann mar-thà;
• dèan ùrachadh - chan eil an dàta a’ strì tuilleadh;
• na h-atharrachaidhean a dhèanamh.

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

Thuit an dreach tùsail de pg_repack an-còmhnaidh air a’ chiad chuir a-steach, dh’ obraich an dreach atharraichte gun mhearachdan. Sgoinneil.

Bidh sinn a’ dol gu cinneasachadh agus a-rithist a’ faighinn mearachd aig an aon ìre de chopaigeadh dàta bhon chlàr log gu fear ùr:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

Suidheachadh clasaigeach: bidh a h-uile dad ag obair ann an àrainneachdan deuchainn, ach chan ann ann an cinneasachadh?!

APPLY_COUNT agus ceangal dà bhaidse

Thòisich sinn air a’ chòd a mhion-sgrùdadh gu litireil loidhne air loidhne agus lorg sinn puing chudromach: tha dàta air a ghluasad bhon chlàr log gu fear ùr ann an baidsean, chomharraich an seasmhach APPLY_COUNT meud a’ bhaidse:

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

Is e an duilgheadas a th ’ann gum faod an dàta bhon ghnothach tùsail, anns am faodadh grunn obrachaidhean an cuingealachadh a bhriseadh, nuair a thèid a ghluasad, a thighinn gu crìch aig snaim dà bhaidse - thèid leth de na h-òrdughan a ghealltainn anns a’ chiad baidse, agus an leth eile anns an dara. Agus an seo, a rèir do fhortan: mura h-eil na sgiobaidhean a 'briseadh rud sam bith anns a' chiad bhaidse, tha a h-uile dad gu math, ach ma nì iad, bidh mearachd a 'tachairt.

Tha APPLY_COUNT co-ionann ri 1000 clàr, a tha a’ mìneachadh carson a bha na deuchainnean againn soirbheachail - cha do chòmhdaich iad cùis “batch snaim”. Chleachd sinn dà àithne - cuir a-steach agus ùraich, agus mar sin bha dìreach 500 gnìomh de dhà àithne an-còmhnaidh air an cur ann am baidse agus cha robh duilgheadas sam bith againn. Às deidh dhuinn an dàrna ùrachadh a chuir ris, sguir an deasachadh againn ag obair:

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

Mar sin, is e an ath ghnìomh dèanamh cinnteach gu bheil dàta bhon chlàr tùsail, a chaidh atharrachadh ann an aon ghnothach, a’ tighinn gu crìch sa chlàr ùr cuideachd taobh a-staigh aon ghnothach.

A 'diùltadh bho bhith a' sgoltadh

Agus a-rithist bha dà fhuasgladh againn. An toiseach: fàgaidh sinn gu tur sgaradh ann an baidsean agus gluasad dàta ann an aon ghnothach. B’ e buannachd an fhuasglaidh seo cho sìmplidh ‘s a bha e - cha robh na h-atharrachaidhean còd riatanach ach glè bheag (co-dhiù, ann an dreachan nas sine dh’ obraich pg_reorg dìreach mar sin). Ach tha duilgheadas ann - tha sinn a 'cruthachadh malairt fad-ùine, agus tha seo, mar a chaidh a ràdh roimhe, na chunnart do bhith a' nochdadh bloat ùr.

Tha an dàrna fuasgladh nas iom-fhillte, ach is dòcha nas ceart: cruthaich colbh anns a 'chlàr log le aithnichear a' ghnothaich a chuir dàta ris a 'chlàr. An uairsin, nuair a nì sinn leth-bhreac den dàta, is urrainn dhuinn a chuir còmhla leis a’ fheart seo agus dèanamh cinnteach gu bheil atharrachaidhean co-cheangailte air an gluasad còmhla. Thèid am baidse a chruthachadh bho ghrunn ghnothaichean (no aon mhòr) agus bidh a mheud ag atharrachadh a rèir dè an ìre de dhàta a chaidh atharrachadh anns na gnothaichean sin. Tha e cudromach cuimhneachadh, leis gu bheil dàta bho dhiofar ghnothaichean a’ dol a-steach don chlàr log ann an òrdugh air thuaiream, cha bhith e comasach tuilleadh a leughadh ann an òrdugh, mar a bha e roimhe. seqscan airson gach iarrtas le sìoladh le tx_id ro dhaor, tha feum air clàr-amais, ach maillichidh e cuideachd air a’ mhodh mar thoradh air an ùrachadh a bharrachd. San fharsaingeachd, mar as àbhaist, feumaidh tu rudeigin a thoirt seachad.

Mar sin, chuir sinn romhainn tòiseachadh leis a 'chiad roghainn, oir tha e nas sìmplidh. An toiseach, bha e riatanach tuigsinn am biodh gnothach fada na fhìor dhuilgheadas. Leis gu bheil am prìomh ghluasad dàta bhon t-seann chlàr chun chlàr ùr cuideachd a ’tachairt ann an aon ghnothach fada, dh’ atharraich a ’cheist gu“ dè an ìre a mheudaicheas sinn a ’ghnothach seo?” Tha fad a’ chiad ghnothaich an urra gu mòr ri meud a’ chlàir. Tha fad fear ùr an urra ri cia mheud atharrachadh a bhios a’ cruinneachadh sa chlàr aig àm gluasad dàta, i.e. air dian an luchd. Thachair an ruith pg_repack aig àm far nach robh mòran eallach seirbheis ann, agus bha meud nan atharrachaidhean gu math beag an taca ri meud tùsail a’ chlàir. Cho-dhùin sinn gum faodadh sinn dearmad a dhèanamh air àm malairt ùr (airson coimeas, gu cuibheasach tha e 1 uair agus 2-3 mionaidean).

Bha na deuchainnean adhartach. Cuir air bhog air cinneasachadh cuideachd. Airson soilleireachd, seo dealbh le meud aon de na stòran-dàta às deidh dha ruith:

Leis gu robh sinn gu tur riaraichte leis an fhuasgladh seo, cha do dh'fheuch sinn ris an dàrna fear a chuir an gnìomh, ach tha sinn a 'beachdachadh air a' chomas a bhith a 'bruidhinn ris an luchd-leasachaidh leudachaidh. Gu mì-fhortanach, chan eil an ath-sgrùdadh a th’ againn an-dràsta deiseil airson fhoillseachadh, leis nach do dh’ fhuasgail sinn ach an duilgheadas le cuingeachaidhean gun samhail a chaidh a chuir dheth, agus airson bad làn-chuimseach feumar taic a thoirt do sheòrsan eile. Tha sinn an dòchas gun urrainn dhuinn seo a dhèanamh san àm ri teachd.

Is dòcha gu bheil ceist agad, carson a chaidh sinn eadhon an sàs anns an sgeulachd seo le atharrachadh pg_repack, agus nach do chleachd sinn, mar eisimpleir, na analogues aige? Aig àm air choreigin bha sinn cuideachd a 'smaoineachadh mu dheidhinn seo, ach thug an deagh eòlas air a bhith ga chleachdadh na bu tràithe, air bùird gun chuingealachaidhean dàil, sinn a' feuchainn ri brìgh na trioblaid a thuigsinn agus a rèiteachadh. A bharrachd air an sin, tha feum air ùine airson deuchainnean a dhèanamh le bhith a’ cleachdadh fhuasglaidhean eile, agus mar sin cho-dhùin sinn gum feuchadh sinn an-toiseach ris an duilgheadas a cheartachadh ann, agus nan do thuig sinn nach b’ urrainn dhuinn seo a dhèanamh ann an ùine reusanta, thòisicheadh ​​​​sinn a’ coimhead air analogues. .

toraidhean

Dè as urrainn dhuinn a mholadh stèidhichte air ar n-eòlas fhèin:

1. Cum sùil air do bhodhaig. Stèidhichte air dàta sgrùdaidh, tuigidh tu dè cho math ‘s a tha autovacuum air a rèiteachadh.
2. Atharraich AUTOVACUUM gus bloat a chumail aig ìre iomchaidh.
3. Ma tha am bloat fhathast a 'fàs agus nach urrainn dhut faighinn thairis air le bhith a' cleachdadh innealan taobh a-muigh a 'bhogsa, na biodh eagal ort leudachadh a-muigh a chleachdadh. Is e am prìomh rud a h-uile dad a dhearbhadh gu math.
4. Na biodh eagal ort fuasglaidhean bhon taobh a-muigh atharrachadh a rèir do fheumalachdan - uaireannan faodaidh seo a bhith nas èifeachdaiche agus eadhon nas fhasa na bhith ag atharrachadh do chòd fhèin.

Source: www.habr.com