Rhywbryd yn y dyfodol pell, bydd tynnu data diangen yn awtomatig yn un o dasgau pwysig y DBMS [1]. Yn y cyfamser, mae angen i ni ein hunain ofalu am ddileu neu symud data diangen i systemau storio llai costus. Gadewch i ni ddweud eich bod yn penderfynu dileu ychydig filiwn o resi. Tasg eithaf syml, yn enwedig os yw'r cyflwr yn hysbys a bod mynegai addas. "DILEU O'R tabl 1 BLE col1 = :gwerth" - beth allai fod yn symlach, iawn?
Fideo:
-
Rwyf wedi bod ar bwyllgor rhaglen Highload ers y flwyddyn gyntaf, h.y. ers 2007.
-
Ac rydw i wedi bod gyda Postgres ers 2005. Wedi'i ddefnyddio mewn llawer o brosiectau.
-
Grŵp gyda RuPostges hefyd ers 2007.
-
Rydym wedi cynyddu i 2100+ o gyfranogwyr yn Meetup. Mae'n ail yn y byd ar ôl Efrog Newydd, wedi'i oddiweddyd gan San Francisco ers amser maith.
-
Rwyf wedi byw yng Nghaliffornia ers sawl blwyddyn. Rwy'n delio mwy â chwmnïau Americanaidd, gan gynnwys rhai mawr. Maent yn ddefnyddwyr gweithredol o Postgres. Ac mae yna bob math o bethau diddorol.
yw fy nghwmni. Rydym yn y busnes o awtomeiddio tasgau sy'n dileu arafu datblygiad.
Os ydych chi'n gwneud rhywbeth, yna weithiau mae yna ryw fath o blygiau o gwmpas Postgres. Gadewch i ni ddweud bod angen i chi aros i'r gweinyddwr sefydlu stondin prawf i chi, neu mae angen i chi aros i'r DBA ymateb i chi. Ac rydym yn dod o hyd i dagfeydd o'r fath yn y broses ddatblygu, profi a gweinyddu ac yn ceisio eu dileu gyda chymorth awtomeiddio a dulliau newydd.
Roeddwn yn ddiweddar yn VLDB yn Los Angeles. Dyma'r gynhadledd fwyaf ar gronfeydd data. Ac roedd adroddiad y bydd DBMS yn y dyfodol nid yn unig yn storio, ond hefyd yn dileu data yn awtomatig. Mae hwn yn bwnc newydd.
Mae mwy a mwy o ddata ym myd zettabytes - dyna 1 petabytes. Ac yn awr amcangyfrifir eisoes bod gennym fwy na 000 zettabytes o ddata wedi'u storio yn y byd. Ac mae mwy a mwy ohonyn nhw.
A beth i'w wneud ag ef? Yn amlwg mae angen ei ddileu. Dyma ddolen i'r adroddiad diddorol hwn. Ond hyd yma nid yw hyn wedi'i weithredu yn y DBMS.
Mae'r rhai sy'n gallu cyfri arian eisiau dau beth. Maen nhw eisiau i ni ddileu, felly yn dechnegol dylem allu ei wneud.
Yr hyn y byddaf yn ei ddweud nesaf yw rhyw sefyllfa haniaethol sy'n cynnwys criw o sefyllfaoedd go iawn, h.y. math o gasgliad o'r hyn a ddigwyddodd i mi a'r cronfeydd data cyfagos lawer gwaith, sawl blwyddyn. Mae cribiniau ym mhobman ac mae pawb yn camu arnyn nhw drwy'r amser.
Gadewch i ni ddweud bod gennym ni sylfaen neu sawl sylfaen sy'n tyfu. Ac mae rhai cofnodion yn amlwg yn sbwriel. Er enghraifft, dechreuodd y defnyddiwr wneud rhywbeth yno, ond ni wnaeth ei orffen. Ac ar ôl peth amser rydym yn gwybod na ellir storio'r anorffenedig hwn mwyach. Hynny yw, hoffem lanhau rhai pethau sothach er mwyn arbed lle, gwella perfformiad, ac ati.
Yn gyffredinol, y dasg yw awtomeiddio dileu pethau penodol, llinellau penodol mewn rhai tabl.
Ac mae gennym gais o'r fath, y byddwn yn siarad amdano heddiw, hynny yw, am gael gwared ar sbwriel.
Gofynnom i ddatblygwr profiadol wneud hynny. Cymerodd y cais hwn, ei wirio drosto'i hun - mae popeth yn gweithio. Wedi'i brofi ar lwyfannu - mae popeth yn iawn. Wedi'i gyflwyno - mae popeth yn gweithio. Unwaith y dydd rydyn ni'n ei redeg - mae popeth yn iawn.
Mae'r gronfa ddata yn tyfu ac yn tyfu. Mae Daily DELETE yn dechrau gweithio ychydig yn arafach.
Yna rydyn ni'n deall bod gennym ni bellach gwmni marchnata a bydd y traffig sawl gwaith yn fwy, felly rydyn ni'n penderfynu rhoi'r gorau i bethau diangen dros dro. Ac anghofio dychwelyd.
Ychydig fisoedd wedyn roedden nhw'n cofio. Ac mae'r datblygwr hwnnw wedi rhoi'r gorau iddi neu'n brysur gyda rhywbeth arall, wedi cyfarwyddo un arall i'w ddychwelyd.
Gwiriodd ar dev, ar lwyfannu - mae popeth yn iawn. Yn naturiol, mae dal angen i chi lanhau'r hyn sydd wedi cronni. Gwiriodd fod popeth yn gweithio.
Beth sy'n digwydd nesaf? Yna mae popeth yn disgyn ar wahân i ni. Mae'n gostwng fel bod popeth yn disgyn i lawr ar ryw adeg. Mae pawb mewn sioc, does neb yn deall beth sy'n digwydd. Ac yna mae'n troi allan bod y mater yn y DELETE.
Aeth rhywbeth o'i le? Dyma restr o'r hyn a allai fod wedi mynd o'i le. Pa un o'r rhain yw'r pwysicaf?
-
Er enghraifft, nid oedd adolygiad, h.y. ni edrychodd yr arbenigwr DBA arno. Byddai'n dod o hyd i'r broblem ar unwaith gyda llygad profiadol, ac ar wahân, mae ganddo fynediad at brod, lle mae sawl miliwn o linellau wedi cronni.
-
Efallai eu bod wedi gwirio rhywbeth o'i le.
-
Efallai bod y caledwedd wedi dyddio a bod angen i chi uwchraddio'r sylfaen hon.
-
Neu mae rhywbeth o'i le ar y gronfa ddata ei hun, ac mae angen i ni symud o Postgres i MySQL.
-
Neu efallai bod rhywbeth o'i le ar y llawdriniaeth.
-
Efallai bod rhai camgymeriadau wrth drefnu gwaith a bod angen i chi danio rhywun a llogi'r bobl orau?
Nid oedd gwiriad DBA. Pe bai DBA, byddai'n gweld y sawl miliwn o linellau hyn a hyd yn oed heb unrhyw arbrofion byddai'n dweud: "Dydyn nhw ddim yn gwneud hynny." Tybiwch pe bai'r cod hwn yn GitLab, GitHub ac y byddai proses adolygu cod ac nad oedd y fath beth, heb gymeradwyaeth y DBA, y byddai'r llawdriniaeth hon yn digwydd ar prod, yna yn amlwg byddai'r DBA yn dweud: “Ni ellir gwneud hyn .”
A byddai'n dweud y byddwch chi'n cael problemau gyda disg IO a bydd yr holl brosesau'n mynd yn wallgof, efallai y bydd cloeon, a hefyd byddwch chi'n blocio autovacuum am griw o funudau, felly nid yw hyn yn dda.
Yr ail gamgymeriad - maent yn gwirio yn y lle anghywir. Gwelsom ar ôl y ffaith bod llawer o ddata sothach wedi'i gronni ar y cynnyrch, ond nid oedd y datblygwr wedi cronni data yn y gronfa ddata hon, ac ni greodd unrhyw un y sothach hwn yn ystod y llwyfannu. Yn unol â hynny, roedd 1 o linellau a weithiodd allan yn gyflym.
Rydym yn deall bod ein profion yn wan, hynny yw, nid yw'r broses sy'n cael ei hadeiladu yn dal problemau. Ni chynhaliwyd arbrawf DB digonol.
Yn ddelfrydol, cynhelir arbrawf delfrydol ar yr un offer. Nid yw bob amser yn bosibl gwneud hyn ar yr un offer, ond mae'n bwysig iawn ei fod yn gopi maint llawn o'r gronfa ddata. Dyma beth rydw i wedi bod yn ei bregethu ers sawl blwyddyn bellach. A blwyddyn yn ôl fe wnes i siarad am hyn, gallwch chi wylio'r cyfan ar YouTube.
Efallai bod ein hoffer yn ddrwg? Os edrychwch chi, yna neidiodd y latency. Rydym wedi gweld bod y defnydd yn 100%. Wrth gwrs, pe bai'r rhain yn yriannau NVMe modern, yna mae'n debyg y byddai'n llawer haws i ni. Ac efallai na fyddem yn gorwedd i lawr ohono.
Os oes gennych gymylau, yna mae'n hawdd gwneud yr uwchraddio yno. Wedi codi copïau newydd ar y caledwedd newydd. newid i ddigidol. Ac mae popeth yn iawn. Eithaf hawdd.
A yw'n bosibl cyffwrdd â'r disgiau llai rywsut? Ac yma, dim ond gyda chymorth DBA, rydyn ni'n plymio i bwnc penodol o'r enw tiwnio pwynt gwirio. Mae'n ymddangos nad oedd gennym diwnio pwynt gwirio.
Beth yw pwynt gwirio? Mae mewn unrhyw DBMS. Pan fydd gennych ddata yn y cof sy'n newid, nid yw'n cael ei ysgrifennu ar unwaith i ddisg. Mae'r wybodaeth bod y data wedi newid yn cael ei ysgrifennu'n gyntaf i'r log ysgrifennu ymlaen llaw. Ac ar ryw adeg, mae'r DBMS yn penderfynu ei bod hi'n bryd dympio tudalennau go iawn i ddisg, fel y gallwn ni wneud llai o REDO os bydd gennym fethiant. Mae fel tegan. Os cawn ein lladd, byddwn yn cychwyn y gêm o'r pwynt gwirio olaf. Ac mae pob DBMS yn ei weithredu.
Mae'r gosodiadau yn Postgres ar ei hôl hi. Maent wedi'u cynllunio ar gyfer meintiau data a thrafodion 10-15 oed. Ac nid yw pwynt gwirio yn eithriad.
Dyma’r wybodaeth o’n hadroddiad archwiliad Postgres, h.y. gwiriad iechyd awtomatig. A dyma gronfa ddata o sawl terabytes. A gellir gweld yn dda bod pwyntiau gwirio wedi'u gorfodi mewn bron i 90% o achosion.
Beth mae'n ei olygu? Mae dau leoliad yno. Gall checkpoint ddod erbyn terfyn amser, er enghraifft, mewn 10 munud. Neu efallai y daw pan fydd cryn dipyn o ddata wedi'i lenwi.
Ac yn ddiofyn, mae max_wal_saze wedi'i osod i 1 gigabyte. Mewn gwirionedd, mae hyn yn wir yn digwydd yn Postgres ar ôl 300-400 megabeit. Rydych chi wedi newid cymaint o ddata ac mae eich pwynt gwirio yn digwydd.
Ac os nad oedd neb yn ei diwnio, a thyfodd y gwasanaeth, a bod y cwmni'n ennill llawer o arian, mae ganddo lawer o drafodion, yna daw'r pwynt gwirio unwaith y funud, weithiau bob 30 eiliad, ac weithiau hyd yn oed yn gorgyffwrdd. Mae hyn yn eithaf gwael.
Ac mae angen i ni wneud yn siŵr ei fod yn dod yn llai aml. Hynny yw, gallwn godi max_wal_size. A bydd yn dod yn llai aml.
Ond rydym wedi datblygu methodoleg gyfan ar gyfer sut i'w wneud yn fwy cywir, hynny yw, sut i wneud penderfyniad am ddewis lleoliadau, yn amlwg yn seiliedig ar ddata penodol.
Yn unol â hynny, rydym yn cynnal dwy gyfres o arbrofion ar gronfeydd data.
Y gyfres gyntaf - rydym yn newid max_wal_size. Ac rydym yn gwneud llawdriniaeth enfawr. Yn gyntaf, rydym yn ei wneud ar y gosodiad diofyn o 1 gigabyte. Ac rydym yn gwneud DILEU enfawr o filiynau lawer o linellau.
Gallwch weld pa mor anodd yw hi i ni. Rydym yn gweld bod disg IO yn ddrwg iawn. Edrychwn ar faint o CIY yr ydym wedi’u cynhyrchu, oherwydd mae hyn yn bwysig iawn. Gawn ni weld sawl gwaith y digwyddodd y pwynt gwirio. A gwelwn nad yw'n dda.
Nesaf rydym yn cynyddu max_wal_size. Rydyn ni'n ailadrodd. Rydym yn cynyddu, rydym yn ailadrodd. A chymaint o weithiau. Mewn egwyddor, mae 10 pwynt yn dda, lle mae 1, 2, 4, 8 gigabeit. Ac rydym yn edrych ar ymddygiad system benodol. Mae'n amlwg y dylai'r offer fod yn debyg yma ar gynnyrch. Rhaid bod gennych yr un disgiau, yr un faint o gof, a'r un gosodiadau Postgres.
Ac yn y modd hwn byddwn yn cyfnewid ein system, ac rydym yn gwybod sut y bydd y DBMS yn ymddwyn rhag ofn y bydd màs drwg DELETE, sut y bydd yn checkpoint.
Checkpoint yn Rwsieg yn checkpoints.
Enghraifft: DILEU sawl miliwn o resi yn ôl mynegai, mae rhesi'n cael eu "gwasgaru" ar draws tudalennau.
Dyma enghraifft. Dyma rywfaint o sylfaen. A chyda'r gosodiad diofyn o 1 gigabyte ar gyfer max_wal_size, mae'n amlwg iawn bod ein disgiau'n mynd i'r silff i'w recordio. Mae'r llun hwn yn symptom nodweddiadol o glaf sâl iawn, hynny yw, roedd yn teimlo'n ddrwg iawn. Ac roedd un llawdriniaeth sengl, dim ond DILEU o sawl miliwn o linellau oedd.
Os caniateir gweithrediad o'r fath yn prod, yna byddwn yn gorwedd i lawr, oherwydd mae'n amlwg bod un DELETE yn ein lladd yn y silff.
Bellach, lle 16 gigabeit, mae'n amlwg bod y dannedd eisoes wedi mynd. Mae dannedd eisoes yn well, hynny yw, rydym yn curo ar y nenfwd, ond nid mor ddrwg. Roedd rhywfaint o ryddid yno. Ar y dde mae'r cofnod. A nifer y gweithrediadau - yr ail graff. Ac mae'n amlwg ein bod eisoes yn anadlu ychydig yn haws pan fydd 16 gigabeit.
A lle gellir gweld 64 gigabeit ei fod wedi dod yn hollol well. Eisoes mae'r dannedd yn amlwg, mae mwy o gyfleoedd i oroesi gweithrediadau eraill a gwneud rhywbeth gyda'r ddisg.
Pam felly
Byddaf yn blymio i'r manylion ychydig, ond gall y pwnc hwn, sut i gynnal tiwnio pwynt gwirio, arwain at adroddiad cyfan, felly ni fyddaf yn llwytho llawer, ond amlinellaf ychydig o'r anawsterau sydd yna.
Os bydd y pwynt gwirio yn digwydd yn rhy aml, ac rydym yn diweddaru ein llinellau nid yn ddilyniannol, ond yn dod o hyd yn ôl mynegai, sy'n dda, oherwydd nid ydym yn dileu'r tabl cyfan, yna efallai y bydd yn digwydd ein bod wedi cyffwrdd â'r dudalen gyntaf ar y dechrau, yna'r milfed, ac yna dychwelodd at y cyntaf. Ac os rhwng yr ymweliadau hyn â'r dudalen gyntaf, mae'r pwynt gwirio eisoes wedi'i gadw ar ddisg, yna bydd yn ei arbed eto, oherwydd fe'i cawsom yn fudr yr eildro.
A byddwn yn gorfodi pwynt gwirio i'w achub lawer gwaith. Sut y byddai llawdriniaethau diangen iddo.
Ond nid dyna'r cyfan. Y tudalennau yw 8 kilobeit yn Postgres a 4 kilobytes yn Linux. Ac mae gosodiad full_page_writes. Mae'n cael ei alluogi yn ddiofyn. Ac mae hyn yn gywir, oherwydd os byddwn yn ei droi i ffwrdd, yna mae perygl mai dim ond hanner y dudalen fydd yn cael ei arbed os bydd yn chwalu.
Mae ymddygiad ysgrifennu i WAL y blaengofnod yn golygu pan fydd gennym bwynt gwirio ac rydym yn newid y dudalen am y tro cyntaf, mae'r dudalen gyfan, h.y., pob un o'r 8 cilobeit, yn mynd i mewn i'r log ymlaen, er mai dim ond y dudalen ymlaen y gwnaethom ei newid llinell, sy'n pwyso 100 beit. Ac mae'n rhaid i ni ysgrifennu'r dudalen gyfan.
Mewn newidiadau dilynol dim ond tuple penodol fydd, ond am y tro cyntaf rydym yn ysgrifennu popeth.
Ac, yn unol â hynny, os digwyddodd y pwynt gwirio eto, yna mae'n rhaid i ni ddechrau popeth o'r dechrau eto a gwthio'r dudalen gyfan. Gyda phwyntiau gwirio aml, pan fyddwn yn cerdded trwy'r un tudalennau, bydd full_page_writes = ymlaen yn fwy nag y gallai fod, h.y. rydym yn cynhyrchu mwy o CIY. Anfonir mwy i gopïau, i'r archif, i ddisg.
Ac, yn unol â hynny, mae gennym ddau ddiswyddiad.
Os byddwn yn cynyddu max_wal_size, mae'n ymddangos ein bod yn ei gwneud hi'n haws i ysgrifenwyr pwynt gwirio a wal. Ac mae hynny'n wych.
Gadewch i ni roi terabyte mewn a byw ag ef. Beth sy'n ddrwg amdano? Mae hyn yn ddrwg, oherwydd rhag ofn y bydd methiant, byddwn yn dringo am oriau, oherwydd roedd y pwynt gwirio amser maith yn ôl ac mae llawer eisoes wedi newid. Ac mae angen i ni wneud hyn i gyd REDO. Ac felly rydyn ni'n gwneud yr ail gyfres o arbrofion.
Rydyn ni'n gwneud llawdriniaeth ac yn gweld pan fydd y pwynt gwirio ar fin cael ei gwblhau, rydyn ni'n lladd -9 Postgres yn bwrpasol.
Ac ar ôl hynny rydyn ni'n ei gychwyn eto, ac yn gweld pa mor hir y bydd yn codi ar yr offer hwn, h.y. faint y bydd yn AIL-wneud yn y sefyllfa ddrwg hon.
Ddwywaith sylwaf fod y sefyllfa’n ddrwg. Yn gyntaf, fe wnaethon ni ddamwain reit cyn i'r pwynt gwirio ddod i ben, felly mae gennym ni lawer i'w golli. Ac yn ail, cawsom lawdriniaeth enfawr. A phe bai pwyntiau gwirio ar derfyn amser, yna, yn fwyaf tebygol, byddai llai o CIY yn cael ei gynhyrchu ers y pwynt gwirio diwethaf. Hynny yw, mae'n golled ddwbl.
Rydym yn mesur sefyllfa o'r fath ar gyfer gwahanol feintiau max_wal_size ac yn deall, os yw max_wal_size yn 64 gigabeit, yna mewn achos gwaethaf dwbl byddwn yn dringo am 10 munud. Ac rydyn ni'n meddwl a yw'n addas i ni ai peidio. Cwestiwn busnes yw hwn. Mae angen i ni ddangos y darlun hwn i'r rhai sy'n gyfrifol am benderfyniadau busnes a gofyn, “Am ba hyd y gallwn orwedd ar y mwyaf rhag ofn y bydd problem? A allwn ni orwedd yn y sefyllfa waethaf am 3-5 munud? Ac rydych chi'n gwneud penderfyniad.
A dyma bwynt diddorol. Mae gennym ni gwpl o adroddiadau am Patroni yn y gynhadledd. Ac efallai eich bod chi'n ei ddefnyddio. Mae hwn yn fethiant awtomatig ar gyfer Postgres. Siaradodd GitLab a Data Egret am hyn.
Ac os oes gennych fethiant awtomatig sy'n dod mewn 30 eiliad, yna efallai y gallwn ni orwedd am 10 munud? Oherwydd byddwn yn newid i'r replica erbyn y pwynt hwn, a bydd popeth yn iawn. Mae hwn yn bwynt dadleuol. Nid wyf yn gwybod ateb clir. Rwy'n teimlo nad yw'r pwnc hwn yn ymwneud ag adferiad mewn damwain yn unig.
Os cawn adferiad hir ar ôl methiant, yna byddwn yn anghyfforddus mewn llawer o sefyllfaoedd eraill. Er enghraifft, yn yr un arbrofion, pan fyddwn yn gwneud rhywbeth ac weithiau yn gorfod aros am 10 munud.
Ni fyddwn yn mynd yn rhy bell o hyd, hyd yn oed os oes gennym fethiant awtomatig. Fel rheol, mae gwerthoedd fel 64, 100 gigabeit yn werthoedd da. Weithiau mae hyd yn oed yn werth dewis llai. Yn gyffredinol, mae hon yn wyddoniaeth gynnil.
I wneud iteriadau, er enghraifft, max_wal_size = 1, 8, mae angen i chi ailadrodd y llawdriniaeth màs sawl gwaith. Fe wnaethoch chi. Ac ar yr un sylfaen rydych chi am ei wneud eto, ond rydych chi eisoes wedi dileu popeth. Beth i'w wneud?
Byddaf yn siarad yn ddiweddarach am ein datrysiad, yr hyn a wnawn er mwyn ailadrodd mewn sefyllfaoedd o'r fath. A dyma'r dull mwyaf cywir.
Ond yn yr achos hwn, roeddem yn ffodus. Os, fel y mae'n ei ddweud yma "DECHREU, DILEU, ROLL YN ÔL", yna gallwn ailadrodd DILEU. Hynny yw, os ydym yn ei ganslo ein hunain, yna gallwn ei ailadrodd. Ac yn gorfforol arnoch chi bydd y data yn gorwedd yn yr un lle. Nid ydych hyd yn oed yn cael unrhyw bloat. Gallwch ailadrodd dros DELETEs o'r fath.
Mae'r DILEU hwn gyda ROLLback yn ddelfrydol ar gyfer tiwnio pwynt gwirio, hyd yn oed os nad oes gennych chi labordai cronfa ddata sydd wedi'u defnyddio'n gywir.
Fe wnaethon ni blât gydag un golofn "i". Mae gan Postgres golofnau cyfleustodau. Maent yn anweledig oni bai y gofynnir yn benodol amdanynt. Sef: ctid, xmid, xmax.
Cyfeiriad corfforol yw Ctid. Tudalen sero, y tuple cyntaf yn y dudalen.
Gellir gweld bod y tuple wedi aros yn yr un lle ar ôl ROOLBACK. Hynny yw, gallwn geisio eto, bydd yn ymddwyn yr un ffordd. Dyma'r prif beth.
Xmax yw amser marwolaeth y tuple. Cafodd ei stampio, ond mae Postgres yn gwybod bod y trafodiad wedi'i rolio'n ôl, felly nid oes ots a yw'n 0 neu'n drafodiad wedi'i rolio'n ôl. Mae hyn yn awgrymu ei bod yn bosibl ailadrodd dros DELETE a gwirio gweithrediadau swmp ymddygiad y system. Gallwch chi wneud labordai cronfa ddata ar gyfer y tlawd.
Mae hyn yn ymwneud â rhaglenwyr. Ynglŷn â DBA, hefyd, maen nhw bob amser yn twyllo rhaglenwyr am hyn: “Pam ydych chi'n gwneud gweithrediadau mor hir ac anodd?”. Mae hwn yn bwnc perpendicwlar hollol wahanol. Roedd gweinyddiaeth yn arfer bod, a nawr bydd datblygiad.
Yn amlwg, nid ydym wedi torri’n ddarnau. Mae'n amlwg. Mae'n amhosibl peidio â thorri'r fath DELETE am bentwr o filiynau o linellau yn rhannau. Bydd yn cael ei wneud am 20 munud, a bydd popeth yn gorwedd. Ond, yn anffodus, mae hyd yn oed datblygwyr profiadol yn gwneud camgymeriadau, hyd yn oed mewn cwmnïau mawr iawn.
Pam mae'n bwysig torri?
-
Os gwelwn fod y ddisg yn galed, yna gadewch i ni ei arafu. Ac os ydym wedi torri, yna gallwn ychwanegu seibiau, gallwn arafu throtling.
-
Ac ni fyddwn yn rhwystro eraill am amser hir. Mewn rhai achosion, nid oes ots, os ydych chi'n dileu sbwriel go iawn nad oes neb yn gweithio arno, yna mae'n fwyaf tebygol na fyddwch chi'n rhwystro unrhyw un ac eithrio'r gwaith autovacuum, oherwydd bydd yn aros i'r trafodiad gael ei gwblhau. Ond os byddwch yn tynnu rhywbeth y gall rhywun arall ofyn amdano, yna byddant yn cael eu rhwystro, bydd rhyw fath o adwaith cadwynol. Dylid osgoi trafodion hir ar wefannau a chymwysiadau symudol.
Mae hyn yn ddiddorol. Rwy'n aml yn gweld bod datblygwyr yn gofyn: "Pa faint pecyn ddylwn i ei ddewis?".
Mae'n amlwg po fwyaf yw maint y bwndel, y lleiaf yw'r gorbenion trafodiad, h.y., y gorbenion ychwanegol o drafodion. Ond ar yr un pryd, mae'r amser yn cynyddu ar gyfer y trafodiad hwn.
Mae gennyf reol syml iawn: cymerwch gymaint ag y gallwch, ond peidiwch â mynd dros weithrediadau yr eiliad.
Pam eiliad? Mae'r esboniad yn syml iawn ac yn ddealladwy i bawb, hyd yn oed pobl nad ydynt yn dechnegol. Rydym yn gweld adwaith. Gadewch i ni gymryd 50 milieiliad. Os bydd rhywbeth wedi newid, yna bydd ein llygad yn ymateb. Os yn llai, yna yn fwy anodd. Os bydd rhywbeth yn ymateb ar ôl 100 milieiliad, er enghraifft, fe wnaethoch chi glicio'r llygoden, a'i fod yn eich ateb ar ôl 100 milieiliad, rydych chi eisoes yn teimlo'r oedi bach hwn. Mae eiliad eisoes yn cael ei weld fel breciau.
Yn unol â hynny, os byddwn yn torri ein gweithrediadau torfol yn hyrddiau 10 eiliad, yna mae gennym risg y byddwn yn rhwystro rhywun. A bydd yn gweithio am ychydig eiliadau, a bydd pobl eisoes yn sylwi arno. Felly, mae’n well gennyf beidio â gwneud mwy nag eiliad. Ond ar yr un pryd, peidiwch â'i dorri'n fân iawn, oherwydd bydd gorbenion y trafodiad yn amlwg. Bydd y sylfaen yn galetach, a gall problemau gwahanol eraill godi.
Rydym yn dewis maint y pecyn. Ym mhob achos, gallwn ei wneud yn wahanol. Gellir ei awtomeiddio. Ac rydym yn argyhoeddedig o effeithlonrwydd prosesu un pecyn. Hynny yw, rydyn ni'n DILEU un pecyn neu DDIWEDDARIAD.
Gyda llaw, nid yw popeth rwy'n siarad amdano yn ymwneud â DELETE yn unig. Fel y gwnaethoch ddyfalu, mae'r rhain yn unrhyw weithrediadau swmp ar ddata.
A gwelwn fod y cynllun yn rhagorol. Gallwch weld y sgan mynegai, sgan mynegai yn unig yn well fyth. Ac mae gennym ychydig bach o ddata dan sylw. Ac mae llai nag eiliad yn cyflawni. Super.
Ac mae angen inni wneud yn siŵr o hyd nad oes unrhyw ddiraddio. Mae'n digwydd bod y pecynnau cyntaf yn gweithio allan yn gyflym, ac yna mae'n gwaethygu, yn waeth ac yn waeth. Mae'r broses yn golygu bod angen i chi brofi llawer. Dyma'n union beth yw pwrpas labordai cronfa ddata.
Ac mae'n rhaid i ni baratoi rhywbeth o hyd fel y bydd yn caniatáu inni ddilyn hyn yn gywir wrth gynhyrchu. Er enghraifft, gallwn ysgrifennu'r amser yn y log, gallwn ysgrifennu lle'r ydym nawr a phwy yr ydym bellach wedi'u dileu. A bydd hyn yn ein galluogi i ddeall beth sy'n digwydd yn nes ymlaen. A rhag ofn i rywbeth fynd o'i le, dewch o hyd i'r broblem yn gyflym.
Os oes angen i ni wirio effeithlonrwydd ceisiadau a bod angen i ni ailadrodd sawl gwaith, yna mae yna'r fath beth â chyd-bot. Mae e'n barod yn barod. Fe'i defnyddir gan ddwsinau o ddatblygwyr bob dydd. Ac mae'n gwybod sut i roi cronfa ddata terabyte enfawr ar gais mewn 30 eiliad, eich copi eich hun. A gallwch ddileu rhywbeth yno a dweud AILOSOD, a'i ddileu eto. Gallwch chi arbrofi ag ef fel hyn. Rwy'n gweld dyfodol i'r peth hwn. Ac rydym eisoes yn ei wneud.
Beth yw strategaethau rhannu? Rwy'n gweld 3 strategaeth rannu gwahanol y mae'r datblygwyr ar y pecyn yn eu defnyddio.
Mae'r un cyntaf yn syml iawn. Mae gennym ID rhifol. A gadewch i ni ei dorri i lawr i gyfnodau gwahanol a gweithio gyda hynny. Mae'r anfantais yn glir. Yn y segment cyntaf, efallai y bydd gennym 100 llinell o garbage go iawn, yn yr ail 5 llinell neu ddim o gwbl, neu bydd pob un o'r 1 o linellau yn troi allan i fod yn sothach. Gwaith anwastad iawn, ond mae'n hawdd ei dorri. Fe wnaethon nhw gymryd yr ID mwyaf a'i dorri. Mae hwn yn ddull naïf.
Mae'r ail strategaeth yn ddull cytbwys. Fe'i defnyddir yn Gitlab. Cymerasant y bwrdd a'i sganio. Daethom o hyd i ffiniau'r pecynnau adnabod fel bod gan bob pecyn union 10 o gofnodion. A rhowch nhw mewn ciw. Ac yna rydym yn prosesu. Gallwch chi wneud hyn mewn sawl trywydd.
Yn y strategaeth gyntaf, hefyd, gyda llaw, gallwch chi wneud hyn mewn sawl llinyn. Nid yw'n anodd.
Ond mae yna ddull oerach a gwell. Dyma'r drydedd strategaeth. A phan fo'n bosibl, mae'n well ei ddewis. Gwnawn hyn ar sail mynegai arbennig. Yn yr achos hwn, mae'n debygol y bydd yn fynegai yn ôl ein cyflwr sothach a'n ID. Byddwn yn cynnwys yr ID fel ei fod yn sgan mynegai yn unig fel nad ydym yn mynd i'r domen.
Yn gyffredinol, mae sgan mynegai yn unig yn gyflymach na sgan mynegai.
Ac rydym yn dod o hyd yn gyflym i'n IDs yr ydym am eu dileu. BATCH_SIZE rydym yn dewis ymlaen llaw. Ac rydym nid yn unig yn eu cael, rydym yn eu cael mewn ffordd arbennig ac yn eu hacio ar unwaith. Ond rydyn ni'n cloi felly os ydyn nhw eisoes wedi'u cloi, nid ydym yn eu cloi, ond yn symud ymlaen ac yn cymryd y rhai nesaf. Mae hwn ar gyfer sgip diweddaru wedi'i gloi. Mae'r nodwedd wych hon o Postgres yn caniatáu inni weithio mewn sawl trywydd os ydym eisiau. Mae'n bosibl mewn un ffrwd. A dyma CTE - dyma un cais. Ac mae gennym ni ddileu go iawn yn digwydd yn ail lawr y CTE hwn - returning *. Gallwch ddychwelyd id, ond mae'n well *os nad oes gennych lawer o ddata ar bob llinell.
Pam mae ei angen arnom? Dyma beth sydd angen inni adrodd yn ôl arno. Rydym bellach wedi dileu cymaint o linellau mewn gwirionedd. Ac mae gennym ffiniau gan ID neu gan created_at fel hyn. Gallwch chi wneud min, max. Gellir gwneud rhywbeth arall. Gallwch chi stwffio llawer yma. Ac mae'n gyfleus iawn ar gyfer monitro.
Mae un nodyn arall am y mynegai. Os byddwn yn penderfynu bod angen mynegai arbennig ar gyfer y dasg hon, yna mae angen i ni sicrhau nad yw'n difetha diweddariadau tuples yn unig. Hynny yw, mae gan Postgres ystadegau o'r fath. Mae hyn i'w weld yn pg_stat_user_tables ar gyfer eich bwrdd. Gallwch weld a yw diweddariadau poeth yn cael eu defnyddio ai peidio.
Mae sefyllfaoedd pan fydd eich mynegai newydd yn gallu eu torri i ffwrdd. Ac mae gennych yr holl ddiweddariadau eraill sydd eisoes yn gweithio, arafwch. Nid yn unig oherwydd bod y mynegai yn ymddangos (mae pob mynegai yn arafu diweddariadau ychydig, ond ychydig), ond yma mae'n dal i'w ddifetha. Ac mae'n amhosibl gwneud optimeiddio arbennig ar gyfer y tabl hwn. Mae hyn yn digwydd weithiau. Mae hwn yn gymaint o gynildeb nad oes llawer o bobl yn ei gofio. Ac mae'r rhaca hwn yn hawdd i gamu ymlaen. Weithiau mae'n digwydd bod angen i chi ddod o hyd i ddull o'r ochr arall a dal i wneud heb y mynegai newydd hwn, neu wneud mynegai arall, neu mewn rhyw ffordd arall, er enghraifft, gallwch ddefnyddio'r ail ddull.
Ond dyma'r strategaeth fwyaf optimaidd, sut i rannu'n sypiau a saethu mewn sypiau gydag un cais, dileu ychydig, ac ati.
Trafodion hir
Autovacuum wedi'i rwystro -
mater blocio -
Mae camgymeriad #5 yn un mawr. Soniodd Nikolai o Okmeter am fonitro Postgres. Yn anffodus, nid yw monitro delfrydol Postgres yn bodoli. Mae rhai yn agosach, mae rhai ymhellach. Mae Okmeter yn ddigon agos at fod yn berffaith, ond mae llawer ar goll ac mae angen ei ychwanegu. Mae angen i chi fod yn barod ar gyfer hyn.
Er enghraifft, mae'n well monitro tuples marw. Os oes gennych chi lawer o bethau marw yn y tabl, yna mae rhywbeth o'i le. Mae'n well ymateb yn awr, neu efallai y bydd diraddio, a gallwn orwedd. Mae'n digwydd.
Os oes IO mawr, yna mae'n amlwg nad yw hyn yn dda.
Trafodion hir hefyd. Ni ddylid caniatáu trafodion hir ar OLTP. A dyma ddolen i snippet sy'n eich galluogi i gymryd y pyt hwn a gwneud rhywfaint o olrhain trafodion hir eisoes.
Pam mae trafodion hir yn ddrwg? Oherwydd dim ond ar y diwedd y bydd yr holl gloeon yn cael eu rhyddhau. Ac rydym yn sgriwio pawb. Hefyd, rydym yn blocio gwactod ar gyfer pob bwrdd. Nid yw'n dda o gwbl. Hyd yn oed os oes gennych chi wrth gefn poeth wedi'i alluogi ar y replica, mae'n dal yn ddrwg. Yn gyffredinol, nid yw'n well osgoi trafodion hir yn unman.
Os oes gennym lawer o fyrddau nad ydynt wedi'u hwfro, yna mae angen inni gael rhybudd. Yma mae sefyllfa o'r fath yn bosibl. Gallwn effeithio'n anuniongyrchol ar weithrediad autovacuum. Mae hwn yn pyt gan Avito, yr wyf yn gwella ychydig. Ac roedd yn arf diddorol i weld beth sydd gennym gyda autovacuum. Er enghraifft, mae rhai byrddau yn aros yno ac ni fyddant yn aros am eu tro. Mae angen i chi hefyd ei roi mewn monitro a chael rhybudd.
A blociau materion. Coedwig o goed bloc. Rwy'n hoffi cymryd rhywbeth gan rywun a'i wella. Yma cymerais CTE recursive oer gan Data Egret sy'n dangos coedwig o goed clo. Mae hwn yn offeryn diagnostig da. Ac ar ei sail, gallwch hefyd adeiladu monitro. Ond rhaid gwneud hyn yn ofalus. Mae angen i chi wneud datganiad_amser terfyn bach i chi'ch hun. Ac mae lock_timeout yn ddymunol.
Weithiau mae'r holl wallau hyn yn digwydd mewn swm.
Yn fy marn i, y prif gamgymeriad yma yw sefydliadol. Mae'n sefydliadol, oherwydd nid yw'r dechneg yn tynnu. Dyma rif 2 - fe wnaethon nhw wirio yn y lle anghywir.
Fe wnaethom wirio yn y lle anghywir, oherwydd nid oedd gennym glôn cynhyrchu, sy'n hawdd ei wirio. Efallai na fydd gan ddatblygwr fynediad at gynhyrchu o gwbl.
Ac nid ydym yn gwirio yno. Pe baem wedi gwirio yno, byddem wedi ei weld ein hunain. Gwelodd y datblygwr y cyfan hyd yn oed heb DBA pe bai'n ei wirio mewn amgylchedd da, lle mae'r un faint o ddata a lleoliad union yr un fath. Byddai wedi gweld yr holl ddiraddiad hwn a byddai ganddo gywilydd.
Mwy am wactod awtomatig. Ar ôl i ni wneud ehangder enfawr o sawl miliwn o linellau, mae angen i ni wneud AILWEDDU o hyd. Mae hyn yn arbennig o bwysig ar gyfer mynegeion. Byddan nhw'n teimlo'n ddrwg ar ôl i ni lanhau popeth yno.
Ac os ydych chi am ddod â'r gwaith glanhau dyddiol yn ôl, yna byddwn yn awgrymu ei wneud yn amlach, ond yn llai. Gall fod unwaith y funud neu hyd yn oed yn amlach ychydig. Ac mae angen i chi fonitro dau beth: nad oes gan y peth hwn unrhyw wallau ac nad yw ar ei hôl hi. Bydd y tric a ddangosais yn datrys hyn yn unig.
Yr hyn a wnawn yw ffynhonnell agored. Mae wedi'i bostio ar GitLab. Ac rydym yn ei wneud fel y gall pobl wirio hyd yn oed heb DBA. Rydym yn gwneud labordy cronfa ddata, hynny yw, rydym yn galw'r gydran sylfaen y mae Joe yn gweithio arni ar hyn o bryd. A gallwch chi fachu copi o'r cynhyrchiad. Nawr mae Joe ar gyfer slac ar waith, gallwch ddweud yno: “eglurwch gais o'r fath” a chael canlyniad eich copi o'r gronfa ddata ar unwaith. Gallwch chi hyd yn oed DILEU yno, ac ni fydd neb yn sylwi arno.
Gadewch i ni ddweud bod gennych chi 10 terabytes, rydyn ni'n gwneud labordy cronfa ddata hefyd yn 10 terabytes. A chyda chronfeydd data 10 terabyte ar yr un pryd, gall 10 datblygwr weithio ar yr un pryd. Gall pawb wneud yr hyn a fynnant. Yn gallu dileu, gollwng, ac ati Dyna ffantasi o'r fath. Byddwn yn siarad am hyn yfory.
Gelwir hyn yn ddarpariaeth denau. Darpariaeth gynnil yw hon. Mae hwn yn rhyw fath o ffantasi sy'n cael gwared yn fawr ar oedi mewn datblygiad, wrth brofi ac yn gwneud y byd yn lle gwell yn hyn o beth. Hynny yw, mae'n caniatáu ichi osgoi problemau gyda gweithrediadau swmp.
Enghraifft: Cronfa ddata 5 terabyte, cael copi mewn llai na 30 eiliad. Ac nid yw hyd yn oed yn dibynnu ar y maint, hynny yw, nid oes ots faint o terabytes.
Heddiw gallwch chi fynd i a chloddio i'n hoffer. Gallwch gofrestru i weld beth sydd yno. Gallwch chi osod y bot hwn. Mae'n rhad ac am ddim. Ysgrifennu.
cwestiynau
Yn aml iawn mewn sefyllfaoedd go iawn mae'n troi allan bod y data a ddylai aros yn y tabl yn llawer llai na'r hyn sydd angen ei ddileu. Hynny yw, mewn sefyllfa o'r fath, mae'n aml yn haws gweithredu dull o'r fath, pan fydd yn haws creu gwrthrych newydd, copïwch y data angenrheidiol yn unig yno, a chefnwch yr hen dabl. Mae’n amlwg bod angen dull rhaglennol ar gyfer y foment hon, tra byddwch yn newid. Sut mae'r dull hwn?
Mae hon yn ddull da iawn ac yn dasg dda iawn. Mae'n debyg iawn i'r hyn y mae pg_repack yn ei wneud, mae'n debyg iawn i'r hyn y mae'n rhaid i chi ei wneud pan fyddwch chi'n gwneud IDs 4 bytes. Gwnaeth llawer o fframweithiau hyn ychydig flynyddoedd yn ôl, a dim ond y platiau sydd wedi tyfu i fyny, ac mae angen eu trosi i 8 bytes.
Mae'r dasg hon yn eithaf anodd. Fe wnaethom ni. Ac mae'n rhaid i chi fod yn ofalus iawn. Mae cloeon, ac ati Ond mae'n cael ei wneud. Hynny yw, y dull safonol yw mynd gyda pg_repack. Rydych chi'n datgan label o'r fath. A chyn i chi ddechrau uwchlwytho data ciplun i mewn iddo, rydych hefyd yn datgan un plât sy'n olrhain pob newid. Mae tric efallai na fyddwch hyd yn oed yn olrhain rhai newidiadau. Mae yna gynildeb. Ac yna rydych chi'n newid trwy newidiadau treigl. Bydd saib byr pan fyddwn yn cau pawb i lawr, ond yn gyffredinol mae hyn yn cael ei wneud.
Os edrychwch ar pg_repack ar GitHub, yna, pan oedd tasg i drosi ID o int 4 i int 8, yna roedd syniad i ddefnyddio pg_repack ei hun. Mae hyn hefyd yn bosibl, ond mae'n dipyn o hac, ond bydd yn gweithio i hyn hefyd. Gallwch ymyrryd yn y sbardun y mae pg_repack yn ei ddefnyddio a dweud yno: "Nid oes angen y data hwn arnom", h.y. dim ond yr hyn sydd ei angen arnom y byddwn yn ei drosglwyddo. Ac yna mae'n switsio a dyna ni.
Gyda'r dull hwn, rydym yn dal i gael ail gopi o'r tabl, lle mae'r data eisoes wedi'i fynegeio a'i bentyrru'n gyfartal iawn gyda mynegeion hardd.
Nid yw Bloat yn bresennol, mae'n ddull da. Ond gwn fod ymdrechion i ddatblygu awtomeiddio ar gyfer hyn, h.y. i wneud ateb cyffredinol. Gallaf eich rhoi mewn cysylltiad â'r awtomeiddio hwn. Mae wedi'i ysgrifennu yn Python, sy'n beth da.
Dim ond ychydig bach ydw i o fyd MySQL, felly des i i wrando. Ac rydym yn defnyddio'r dull hwn.
Ond dim ond os oes gennym ni 90%. Os oes gennym 5%, yna nid yw'n dda iawn ei ddefnyddio.
Diolch am yr adroddiad! Os nad oes adnoddau i wneud copi cyflawn o'r prod, a oes unrhyw algorithm neu fformiwla i gyfrifo'r llwyth neu'r maint?
Cwestiwn da. Hyd yn hyn, rydym yn gallu dod o hyd i gronfeydd data aml-terabyte. Hyd yn oed os nad yw'r caledwedd yno yr un peth, er enghraifft, nid yw llai o gof, llai o brosesydd a disgiau yn union yr un peth, ond rydym yn dal i wneud hynny. Os nad oes unrhyw le o gwbl, yna mae angen ichi feddwl. Gadewch imi feddwl tan yfory, daethoch, byddwn yn siarad, mae hwn yn gwestiwn da.
Diolch am yr adroddiad! Fe wnaethoch chi ddechrau am y ffaith bod Postgres cŵl, sydd â chyfyngiadau o'r fath, ond mae'n datblygu. Ac mae hyn i gyd yn fagwrfa ar y cyfan. Onid yw hyn i gyd yn gwrthdaro â datblygiad Postgres ei hun, lle bydd rhai gohirwyr DELETE yn ymddangos neu rywbeth arall a ddylai gadw ar lefel isel yr hyn yr ydym yn ceisio ei daenu gyda rhai o'n dulliau rhyfedd yma?
Os dywedasom yn SQL am ddileu neu ddiweddaru llawer o gofnodion mewn un trafodiad, yna sut y gall Postgres ei ddosbarthu yno? Rydym yn gyfyngedig yn gorfforol o ran gweithrediadau. Byddwn yn dal i wneud hynny am amser hir. A byddwn yn cloi ar hyn o bryd, ac ati.
Wedi'i wneud gyda mynegeion.
Gallaf dybio y gallai'r un tiwnio pwynt gwirio fod yn awtomataidd. Rhyw ddydd efallai y bydd. Ond wedyn dwi ddim yn deall y cwestiwn mewn gwirionedd.
Y cwestiwn yw, a oes yna fector datblygiad o'r fath sy'n mynd yma ac acw, a dyma'ch un chi yn mynd yn gyfochrog? Y rhai. Onid ydyn nhw wedi meddwl amdano eto?
Siaradais am yr egwyddorion y gellir eu defnyddio yn awr. Mae bot arall , gyda hyn gallwch chi wneud tiwnio pwynt gwirio awtomataidd. A fydd hi ryw ddydd yn Postgres? Dydw i ddim yn gwybod, nid yw hyd yn oed wedi cael ei drafod eto. Rydym yn dal i fod ymhell o hynny. Ond mae yna wyddonwyr sy'n gwneud systemau newydd. Ac maent yn ein gwthio i mewn i fynegeion awtomatig. Mae yna ddatblygiadau. Er enghraifft, gallwch edrych ar diwnio ceir. Mae'n dewis paramedrau yn awtomatig. Ond ni fydd yn tiwnio pwynt gwirio i chi eto. Hynny yw, bydd yn codi ar gyfer perfformiad, byffer cragen, ac ati.
Ac ar gyfer tiwnio pwynt gwirio, gallwch chi wneud hyn: os oes gennych chi fil o glystyrau a chaledwedd gwahanol, gwahanol beiriannau rhithwir yn y cwmwl, gallwch chi ddefnyddio ein bot gwneud awtomeiddio. A bydd max_wal_size yn cael ei ddewis yn ôl eich gosodiadau targed yn awtomatig. Ond hyd yn hyn nid yw hyn hyd yn oed yn agos yn y craidd, yn anffodus.
Prynhawn Da Soniasoch am beryglon trafodion hir. Dywedasoch fod autovacuum yn cael ei rwystro rhag ofn y caiff ei ddileu. Sut arall mae'n niweidio ni? Oherwydd rydym yn sôn mwy am ryddhau lle a gallu ei ddefnyddio. Beth arall ydyn ni ar goll?
Efallai nad Autovacuum yw'r broblem fwyaf yma. Ac mae'r ffaith y gall trafodiad hir gloi trafodion eraill, mae'r posibilrwydd hwn yn fwy peryglus. Gall hi gyfarfod neu beidio. Os cyfarfu hi, yna gall fod yn ddrwg iawn. A chyda autovacuum - mae hyn hefyd yn broblem. Mae dwy broblem gyda thrafodion hir yn OLTP: cloeon a autovacuum. Ac os oes gennych adborth wrth gefn poeth wedi'i alluogi ar y replica, yna byddwch yn dal i dderbyn clo autovacuum ar y meistr, bydd yn cyrraedd o'r replica. Ond o leiaf ni fydd cloeon. A bydd loks. Rydym yn sôn am newidiadau data, felly mae cloeon yn bwynt pwysig yma. Ac os yw hyn i gyd am amser hir, hir, yna mae mwy a mwy o drafodion wedi'u cloi. Gallant ddwyn eraill. Ac wele goed yn ymddangos. Darparais ddolen i'r pyt. Ac mae'r broblem hon yn dod yn fwy amlwg yn gyflymach na'r broblem gyda autovacuum, a all gronni yn unig.
Diolch am yr adroddiad! Dechreuasoch eich adroddiad trwy ddweud eich bod wedi profi'n anghywir. Fe wnaethom barhau â'n syniad bod angen i ni gymryd yr un offer, gyda'r sylfaen yn yr un modd. Gadewch i ni ddweud inni roi sylfaen i'r datblygwr. A chydymffurfiai a'r cais. Ac mae'n ymddangos ei fod yn iawn. Ond nid yw'n gwirio am fyw, ond ar gyfer byw, er enghraifft, mae gennym lwyth o 60-70%. A hyd yn oed os ydym yn defnyddio'r tiwnio hwn, nid yw'n gweithio'n dda iawn.
Mae cael arbenigwr ar y tîm a defnyddio arbenigwyr DBA a all ragweld beth fydd yn digwydd gyda llwyth cefndir go iawn yn bwysig. Pan rydyn ni newydd yrru ein newidiadau glân, rydyn ni'n gweld y llun. Ond dull mwy datblygedig, pan wnaethom yr un peth eto, ond gyda llwyth wedi'i efelychu â chynhyrchu. Mae'n eithaf cŵl. Tan hynny, mae'n rhaid i chi dyfu i fyny. Mae fel oedolyn. Fe wnaethon ni edrych ar yr hyn sydd gennym ni a hefyd edrych i weld a oes gennym ni ddigon o adnoddau. Dyna gwestiwn da.
Pan fyddwn eisoes yn gwneud dewis sbwriel ac mae gennym, er enghraifft, faner wedi'i dileu
Dyma beth mae autovacuum yn ei wneud yn awtomatig yn Postgres.
O, a yw'n ei wneud?
Autovacuum yw'r casglwr sbwriel.
Diolch yn fawr!
Diolch am yr adroddiad! A oes opsiwn i ddylunio cronfa ddata ar unwaith gyda rhaniad yn y fath fodd fel bod yr holl sbwriel yn mynd yn fudr o'r prif fwrdd rhywle i'r ochr?
Wrth gwrs wedi.
A yw'n bosibl felly amddiffyn ein hunain os ydym wedi cloi bwrdd na ddylid ei ddefnyddio?
Wrth gwrs wedi. Ond mae fel cwestiwn cyw iâr ac wy. Os ydym i gyd yn gwybod beth fydd yn digwydd yn y dyfodol, yna, wrth gwrs, byddwn yn gwneud popeth yn oer. Ond mae'r busnes yn newid, mae yna golofnau newydd, ceisiadau newydd. Ac yna - wps, rydyn ni am ei ddileu. Ond mae hyn yn sefyllfa ddelfrydol, mewn bywyd mae'n digwydd, ond nid bob amser. Ond ar y cyfan mae'n syniad da. Dim ond blaendorri a dyna ni.
Ffynhonnell: hab.com