Diku në një të ardhme të largët, heqja automatike e të dhënave të panevojshme do të jetë një nga detyrat e rëndësishme të DBMS [1]. Ndërkohë, ne vetë duhet të kujdesemi për fshirjen ose zhvendosjen e të dhënave të panevojshme në sisteme ruajtjeje më pak të kushtueshme. Le të themi se keni vendosur të fshini disa milionë rreshta. Një detyrë mjaft e thjeshtë, veçanërisht nëse dihet gjendja dhe ekziston një indeks i përshtatshëm. "FSHI NGA tabela1 WHERE col1 = :value" - çfarë mund të jetë më e thjeshtë, apo jo?
Video:
-
Unë jam në komitetin e programit Highload që nga viti i parë, pra që nga viti 2007.
-
Dhe unë kam qenë me Postgres që nga viti 2005. E ka përdorur në shumë projekte.
-
Grupi me RuPostges gjithashtu që nga viti 2007.
-
Ne jemi rritur në 2100+ pjesëmarrës në Meetup. Ai është i dyti në botë pas Nju Jorkut, i kaluar nga San Francisko për një kohë të gjatë.
-
Unë kam jetuar në Kaliforni për disa vjet. Unë merrem më shumë me kompani amerikane, duke përfshirë edhe ato të mëdha. Ata janë përdorues aktivë të Postgres. Dhe ka të gjitha llojet e gjërave interesante.
eshte kompania ime. Ne jemi në biznesin e automatizimit të detyrave që eliminojnë ngadalësimet e zhvillimit.
Nëse jeni duke bërë diçka, atëherë ndonjëherë ka disa lloj prizash rreth Postgres. Le të themi se duhet të prisni që administratori të krijojë një stend testimi për ju, ose duhet të prisni që DBA t'ju përgjigjet. Dhe ne gjejmë pengesa të tilla në procesin e zhvillimit, testimit dhe administrimit dhe përpiqemi t'i eliminojmë ato me ndihmën e automatizimit dhe qasjeve të reja.
Kohët e fundit kam qenë në VLDB në Los Angeles. Kjo është konferenca më e madhe për bazat e të dhënave. Dhe kishte një raport që në të ardhmen DBMS jo vetëm që do të ruajë, por edhe do të fshijë automatikisht të dhënat. Kjo është një temë e re.
Ka gjithnjë e më shumë të dhëna në botën e zetabytes - janë 1 petabajt. Dhe tani tashmë vlerësohet se kemi më shumë se 000 zetabajt të dhëna të ruajtura në botë. Dhe ka gjithnjë e më shumë prej tyre.
Dhe çfarë të bëni me të? Është e qartë se ajo duhet të hiqet. Këtu është një lidhje me këtë raport interesant. Por deri më tani kjo nuk është zbatuar në DBMS.
Ata që dinë të numërojnë para duan dy gjëra. Ata duan që ne të fshijmë, kështu që teknikisht ne duhet të jemi në gjendje ta bëjmë atë.
Ajo që do të tregoj më pas është një situatë abstrakte që përfshin një sërë situatash reale, d.m.th një lloj përmbledhjeje të asaj që në të vërtetë më ndodhi me mua dhe bazat e të dhënave përreth shumë herë, shumë vite. Raket janë kudo dhe të gjithë i shkelin gjatë gjithë kohës.
Le të themi se kemi një bazë ose disa baza që janë në rritje. Dhe disa regjistrime janë padyshim mbeturina. Për shembull, përdoruesi filloi të bënte diçka atje, por nuk e mbaroi atë. Dhe pas ca kohësh ne e dimë se kjo e papërfunduar nuk mund të ruhet më. Kjo do të thotë, ne do të dëshironim të pastronim disa gjëra të mbeturinave për të kursyer hapësirë, për të përmirësuar performancën, etj.
Në përgjithësi, detyra është të automatizoni heqjen e gjërave specifike, linjave specifike në një tabelë.
Dhe ne kemi një kërkesë të tillë, për të cilën do të flasim sot, pra për heqjen e plehrave.
Ne i kërkuam një zhvilluesi me përvojë ta bënte atë. Ai e mori këtë kërkesë, e kontrolloi vetë - gjithçka funksionon. Testuar në skenë - gjithçka është në rregull. U hap - gjithçka funksionon. Një herë në ditë e drejtojmë - gjithçka është në rregull.
Baza e të dhënave rritet dhe rritet. DELETE ditore fillon të funksionojë pak më ngadalë.
Atëherë kuptojmë që tani kemi një kompani marketingu dhe trafiku do të jetë disa herë më i madh, ndaj vendosim të ndalojmë përkohësisht gjërat e panevojshme. Dhe harro të kthehesh.
Disa muaj më vonë u kujtuan. Dhe ai zhvillues u largua ose është i zënë me diçka tjetër, e udhëzoi një tjetër ta kthente atë.
Ai kontrolloi në dev, në skenë - gjithçka është në rregull. Natyrisht, ju ende duhet të pastroni atë që është grumbulluar. Ai kontrolloi se gjithçka funksiononte.
Çfarë ndodh më pas? Atëherë gjithçka na prishet. Bie në mënyrë që në një moment gjithçka të bjerë poshtë. Të gjithë janë në shok, askush nuk e kupton se çfarë po ndodh. Dhe pastaj rezulton se çështja ishte në këtë FSHIJE.
Dicka shkoi keq? Këtu është një listë e asaj që mund të ketë shkuar keq. Cila nga këto është më e rëndësishmja?
-
Për shembull, nuk ka pasur shqyrtim, dmth eksperti i DBA nuk e ka parë atë. Problemin do ta gjente menjëherë me një sy me eksperiencë dhe veç kësaj, ka akses në prod, ku janë grumbulluar disa milionë rreshta.
-
Ndoshta ata kontrolluan diçka të gabuar.
-
Ndoshta hardueri është i vjetëruar dhe ju duhet të përmirësoni këtë bazë.
-
Ose diçka nuk shkon me vetë bazën e të dhënave, dhe ne duhet të kalojmë nga Postgres në MySQL.
-
Ose ndoshta ka diçka që nuk shkon me operacionin.
-
Ndoshta ka disa gabime në organizimin e punës dhe ju duhet të pushoni dikë dhe të punësoni njerëzit më të mirë?
Nuk kishte kontroll DBA. Nëse do të kishte një DBA, ai do t'i shihte këto disa milionë rreshta dhe madje pa asnjë eksperiment do të thoshte: "Ata nuk e bëjnë këtë." Supozoni nëse ky kod do të ishte në GitLab, GitHub dhe do të kishte një proces rishikimi të kodit dhe nuk do të kishte një gjë të tillë që pa miratimin e DBA ky operacion do të bëhej në prod, atëherë padyshim DBA do të thoshte: "Kjo nuk mund të bëhet .
Dhe ai do të thoshte se do të keni probleme me IO të diskut dhe të gjitha proceset do të çmenden, mund të ketë bllokime, dhe gjithashtu do të bllokoni autovakumin për disa minuta, kështu që kjo nuk është mirë.
Gabimi i dytë - ata kontrolluan në vendin e gabuar. Ne pamë pas faktit që shumë të dhëna të padëshiruara u grumbulluan në prod, por zhvilluesi nuk kishte të dhëna të grumbulluara në këtë bazë të dhënash dhe askush nuk e krijoi këtë junk gjatë vendosjes. Prandaj, kishte 1 linja që funksionuan shpejt.
Ne e kuptojmë që testet tona janë të dobëta, domethënë procesi që ndërtohet nuk kap probleme. Një eksperiment adekuat DB nuk u krye.
Një eksperiment ideal preferohet të kryhet në të njëjtën pajisje. Nuk është gjithmonë e mundur ta bëni këtë në të njëjtën pajisje, por është shumë e rëndësishme që ajo të jetë një kopje e plotë e bazës së të dhënave. Kjo është ajo që unë kam predikuar prej disa vitesh. Dhe një vit më parë fola për këtë, mund t'i shikoni të gjitha në YouTube.
Ndoshta pajisjet tona janë të këqija? Nëse shikoni, atëherë vonesa u hodh. Kemi parë që shfrytëzimi është 100%. Sigurisht, nëse këto do të ishin disqe moderne NVMe, atëherë ndoshta do të ishte shumë më e lehtë për ne. Dhe mbase nuk do të hiqnim dorë prej saj.
Nëse keni re, atëherë përmirësimi bëhet lehtësisht atje. Ngriti kopje të reja në pajisjen e re. kaloni mbi. Dhe gjithçka është mirë. Mjaft e lehtë.
A është e mundur të prekësh disi disqet më të vegjël? Dhe këtu, vetëm me ndihmën e DBA, ne zhytemi në një temë të caktuar të quajtur akordim i pikës së kontrollit. Rezulton se nuk kemi pasur akordim të pikës së kontrollit.
Çfarë është pika e kontrollit? Është në çdo DBMS. Kur keni të dhëna në memorie që ndryshojnë, ato nuk shkruhen menjëherë në disk. Informacioni që të dhënat kanë ndryshuar shkruhet fillimisht në regjistrin e parashkrimit. Dhe në një moment, DBMS vendos që është koha për të hedhur faqet reale në disk, në mënyrë që nëse kemi një dështim, të mund të bëjmë më pak REDO. Është si një lodër. Nëse vritemi, do ta fillojmë lojën nga pika e fundit e kontrollit. Dhe të gjitha DBMS e zbatojnë atë.
Cilësimet në Postgres kanë mbetur prapa. Ato janë të dizajnuara për vëllime të dhënash dhe transaksionesh të moshës 10-15 vjeç. Dhe pika e kontrollit nuk është përjashtim.
Këtu janë informacionet nga raporti ynë i kontrollit të Postgres, d.m.th kontrolli automatik i shëndetit. Dhe këtu është një bazë të dhënash prej disa terabajtësh. Dhe mund të shihet mirë se pikat e kontrollit të detyruara në pothuajse 90% të rasteve.
Çfarë do të thotë? Ka dy cilësime atje. Pika e kontrollit mund të vijë me afat, për shembull, në 10 minuta. Ose mund të vijë kur janë plotësuar mjaft të dhëna.
Dhe si parazgjedhje max_wal_saze është vendosur në 1 gigabajt. Në fakt, kjo ndodh vërtet në Postgres pas 300-400 megabajt. Ju keni ndryshuar kaq shumë të dhëna dhe pika juaj e kontrollit ndodh.
Dhe nëse askush nuk e akordoi, dhe shërbimi u rrit, dhe kompania fiton shumë para, ka shumë transaksione, atëherë pika e kontrollit vjen një herë në minutë, ndonjëherë çdo 30 sekonda, dhe ndonjëherë edhe mbivendoset. Kjo është mjaft e keqe.
Dhe ne duhet të sigurohemi që të vijë më rrallë. Kjo do të thotë, ne mund të rrisim max_wal_size. Dhe do të vijë më rrallë.
Por ne kemi zhvilluar një metodologji të tërë se si ta bëjmë atë më saktë, domethënë si të marrim një vendim për zgjedhjen e cilësimeve, bazuar qartë në të dhëna specifike.
Prandaj, ne po bëjmë dy seri eksperimentesh në bazat e të dhënave.
Seria e parë - ne ndryshojmë max_wal_size. Dhe ne po bëjmë një operacion masiv. Së pari, ne e bëjmë atë në cilësimin e paracaktuar prej 1 gigabajt. Dhe ne bëjmë një fshirje masive të shumë miliona rreshtave.
Ju mund të shihni se sa e vështirë është për ne. Ne shohim që IO e diskut është shumë e keqe. Ne shikojmë sa WAL kemi gjeneruar, sepse kjo është shumë e rëndësishme. Le të shohim sa herë ka ndodhur postblloku. Dhe ne shohim që nuk është mirë.
Më pas ne rrisim max_wal_size. Ne e përsërisim. Rritemi, e përsërisim. Dhe kaq shumë herë. Në parim, 10 pikë janë të mira, ku 1, 2, 4, 8 gigabajt. Dhe ne shikojmë sjelljen e një sistemi të veçantë. Është e qartë se këtu pajisjet duhet të jenë si në prod. Duhet të keni të njëjtat disqe, të njëjtën sasi memorie dhe të njëjtat cilësime Postgres.
Dhe në këtë mënyrë ne do të shkëmbejmë sistemin tonë dhe e dimë se si do të sillet DBMS në rast të një DELETE të keq masiv, si do të jetë pika kontrolli.
Pikat e kontrollit në rusisht janë pika kontrolli.
Shembull: FSHI disa milionë rreshta sipas indeksit, rreshtat janë "të shpërndara" nëpër faqe.
Këtu është një shembull. Kjo është një bazë. Dhe me vendosjen e paracaktuar prej 1 gigabajt për max_wal_size, është shumë e qartë që disqet tona shkojnë në raft për regjistrim. Kjo foto është një simptomë tipike e një pacienti shumë të sëmurë, domethënë ai është ndjerë vërtet keq. Dhe kishte një operacion të vetëm, kishte vetëm një FSHIJE prej disa milionë linjash.
Nëse një operacion i tillë lejohet në prod, atëherë ne thjesht do të shtrihemi, sepse është e qartë se një FSHIJE na vret në raft.
Më tej, ku 16 gigabajt, është e qartë se dhëmbët tashmë kanë shkuar. Dhëmbët tashmë janë më të mirë, domethënë po trokasim në tavan, por jo aq keq. Aty kishte pak liri. Në të djathtë është rekordi. Dhe numri i operacioneve - grafiku i dytë. Dhe është e qartë se tashmë po marrim frymë pak më lehtë kur 16 gigabajt.
Dhe ku mund të shihet 64 gigabajt se është bërë krejtësisht më mirë. Tashmë dhëmbët janë të theksuar, ka më shumë mundësi për t'i mbijetuar operacioneve të tjera dhe për të bërë diçka me diskun.
Pse kaq?
Do të zhytem pak në detaje, por kjo temë, si të kryhet akordimi i pikës së kontrollit, mund të rezultojë në një raport të tërë, kështu që nuk do të ngarkoj shumë, por do të përshkruaj pak se çfarë vështirësish ka.
Nëse pika e kontrollit ndodh shumë shpesh, dhe ne përditësojmë linjat tona jo në mënyrë sekuenciale, por gjejmë sipas indeksit, gjë që është mirë, sepse nuk e fshijmë të gjithë tabelën, atëherë mund të ndodhë që në fillim të prekim faqen e parë, pastaj të mijtën, dhe pastaj u kthye në të parën . Dhe nëse midis këtyre vizitave në faqen e parë, pika e kontrollit e ka ruajtur tashmë në disk, atëherë do ta ruajë përsëri, sepse e kemi bërë pis për herë të dytë.
Dhe ne do të detyrojmë postbllokun ta ruajë atë shumë herë. Si do të kishte operacione të tepërta për të.
Por kjo nuk është e gjitha. Faqet janë 8 kilobajt në Postgres dhe 4 kilobajt në Linux. Dhe ka një cilësim full_page_writes. Është aktivizuar si parazgjedhje. Dhe kjo është e saktë, sepse nëse e fikim, atëherë ekziston rreziku që vetëm gjysma e faqes të ruhet nëse prishet.
Sjellja e shkrimit në WAL të regjistrit përpara është e tillë që kur kemi një pikë kontrolli dhe ndryshojmë faqen për herë të parë, e gjithë faqja, d.m.th., të gjitha 8 kilobajt, futet në regjistrin përpara, megjithëse ne ndryshuam vetëm linjë, e cila peshon 100 bajt. Dhe ne duhet të shkruajmë të gjithë faqen.
Në ndryshimet e mëvonshme do të ketë vetëm një tufë specifike, por për herë të parë ne shkruajmë gjithçka.
Dhe, në përputhje me rrethanat, nëse pika e kontrollit ndodhi përsëri, atëherë duhet të fillojmë përsëri gjithçka nga e para dhe të shtyjmë të gjithë faqen. Me pika kontrolli të shpeshta, kur kalojmë nëpër të njëjtat faqe, full_page_writes = on do të jetë më shumë se sa mund të jetë, d.m.th. ne gjenerojmë më shumë WAL. Më shumë dërgohet në kopje, në arkiv, në disk.
Dhe, në përputhje me rrethanat, ne kemi dy teprica.
Nëse rrisim max_wal_size, rezulton se e bëjmë më të lehtë si për pikën e kontrollit ashtu edhe për wal shkrimtarin. Dhe kjo është e mrekullueshme.
Le të vendosim një terabajt dhe të jetojmë me të. Çfarë të keqe ka? Kjo është e keqe, sepse në rast dështimi do të ngjitemi për orë të tëra, sepse postblloku ishte shumë kohë më parë dhe shumëçka tashmë ka ndryshuar. Dhe ne duhet ta bëjmë të gjithë këtë RIDO. Dhe kështu ne bëjmë serinë e dytë të eksperimenteve.
Ne bëjmë një operacion dhe shohim kur postblloku është gati të përfundojë, ne vrasim -9 Postgres me qëllim.
Dhe pas kësaj e fillojmë përsëri, dhe shohim se sa do të rritet në këtë pajisje, d.m.th. sa do të RIDO në këtë situatë të keqe.
Dy herë do të vërej se situata është e keqe. Së pari, ne u rrëzuam pak para se të mbaronte postblloku, kështu që kemi shumë për të humbur. Dhe së dyti, ne patëm një operacion masiv. Dhe nëse pikat e kontrollit ishin në afat, atëherë, ka shumë të ngjarë, më pak WAL do të gjenerohej që nga pika e fundit e kontrollit. Kjo do të thotë, është një humbës i dyfishtë.
Ne matim një situatë të tillë për madhësi të ndryshme max_wal_size dhe kuptojmë se nëse max_wal_size është 64 gigabajt, atëherë në rastin më të keq të dyfishtë do të ngjitemi për 10 minuta. Dhe ne mendojmë nëse na përshtatet apo jo. Kjo është një pyetje biznesi. Ne duhet t'ua tregojmë këtë fotografi atyre që janë përgjegjës për vendimet e biznesit dhe të pyesim: “Sa kohë mund të shtrihemi më së shumti në rast problemi? A mund të shtrihemi në situatën më të keqe për 3-5 minuta? Dhe ju merrni një vendim.
Dhe këtu është një pikë interesante. Për Patronin kemi nja dy raporte në konferencë. Dhe ndoshta ju jeni duke e përdorur atë. Ky është një autofailover për Postgres. GitLab dhe Data Egret folën për këtë.
Dhe nëse keni një dështim automatik që vjen në 30 sekonda, atëherë ndoshta mund të shtrihemi për 10 minuta? Sepse ne do të kalojmë në kopje deri në këtë pikë, dhe gjithçka do të jetë mirë. Kjo është një pikë e diskutueshme. Nuk di një përgjigje të qartë. Thjesht mendoj se kjo temë nuk është vetëm rreth rikuperimit të aksidentit.
Nëse kemi një rikuperim të gjatë pas një dështimi, atëherë do të jemi të parehatshëm në shumë situata të tjera. Për shembull, në të njëjtat eksperimente, kur bëjmë diçka dhe ndonjëherë duhet të presim për 10 minuta.
Unë ende nuk do të shkoja shumë larg, edhe nëse kemi një autofailover. Si rregull, vlera të tilla si 64, 100 gigabajt janë vlera të mira. Ndonjëherë ia vlen të zgjidhni më pak. Në përgjithësi, kjo është një shkencë delikate.
Për të bërë përsëritje, për shembull, max_wal_size =1, 8, duhet të përsërisni operacionin masiv shumë herë. Ti e bëre atë. Dhe në të njëjtën bazë dëshironi ta bëni përsëri, por tashmë keni fshirë gjithçka. Çfarë duhet bërë?
Do të flas më vonë për zgjidhjen tonë, çfarë bëjmë për të përsëritur në situata të tilla. Dhe kjo është qasja më e saktë.
Por në këtë rast, ne ishim me fat. Nëse, siç thotë këtu "FILLO, FSHI, RIKOSHT", atëherë mund të përsërisim FSHIJ. Kjo do të thotë, nëse e anulojmë vetë, atëherë mund ta përsërisim. Dhe fizikisht tek ju të dhënat do të qëndrojnë në të njëjtin vend. Ju as nuk merrni ndonjë fryrje. Ju mund të përsërisni mbi këto DELETE.
Ky FSHJE me ROLLBACK është ideal për akordimin e pikës së kontrollit, edhe nëse nuk keni një laborator të vendosur siç duhet bazën e të dhënave.
Bëmë një pjatë me një kolonë "i". Postgres ka kolona të shërbimeve. Ato janë të padukshme nëse nuk kërkohet në mënyrë specifike. Këto janë: ctid, xmid, xmax.
Ctid është një adresë fizike. Faqja zero, tufa e parë në faqe.
Mund të shihet se pas ROOLBACK tupleja mbeti në të njëjtin vend. Kjo do të thotë, ne mund të provojmë përsëri, do të sillet në të njëjtën mënyrë. Kjo është gjëja kryesore.
Xmax është koha e vdekjes së tuples. Ishte e stampuar, por Postgres e di që transaksioni është rikthyer, kështu që nuk ka rëndësi nëse është 0 apo është një transaksion i rikthyer. Kjo sugjeron që është e mundur të përsëriteni mbi DELETE dhe të kontrolloni operacionet në masë të sjelljes së sistemit. Ju mund të bëni laboratorë të të dhënave për të varfërit.
Bëhet fjalë për programuesit. Në lidhje me DBA-në, gjithashtu, ata gjithmonë qortojnë programuesit për këtë: "Pse po bëni operacione kaq të gjata dhe të vështira?". Kjo është një temë krejtësisht e ndryshme pingule. Dikur ka pasur administrim, tani do të ketë zhvillim.
Natyrisht, ne nuk jemi ndarë në copa. Është e qartë. Është e pamundur të mos ndash një FSHJE të tillë për një grumbull miliona rreshtash në pjesë. Do të bëhet për 20 minuta, dhe gjithçka do të shtrihet. Por, për fat të keq, edhe zhvilluesit me përvojë bëjnë gabime, madje edhe në kompani shumë të mëdha.
Pse është e rëndësishme të thyesh?
-
Nëse shohim që disku është i fortë, atëherë le ta ngadalësojmë atë. Dhe nëse jemi të thyer, atëherë mund të shtojmë pauza, mund të ngadalësojmë mbytjen.
-
Dhe ne nuk do të bllokojmë të tjerët për një kohë të gjatë. Në disa raste nuk ka rëndësi, nëse jeni duke fshirë mbeturina të vërteta që askush nuk po punon, atëherë me shumë mundësi nuk do të bllokoni askënd përveç punës së autovakumit, sepse do të presë që transaksioni të përfundojë. Por nëse hiqni diçka që dikush tjetër mund të kërkojë, atëherë ata do të bllokohen, do të ketë një lloj reagimi zinxhir. Transaksionet e gjata duhet të shmangen në faqet e internetit dhe aplikacionet celulare.
Kjo eshte interesante. Shpesh shoh që zhvilluesit pyesin: "Çfarë madhësie paketimi duhet të zgjedh?".
Është e qartë se sa më e madhe të jetë madhësia e paketës, aq më i vogël është shpenzimi i përgjithshëm i transaksionit, d.m.th., shpenzimet e përgjithshme shtesë nga transaksionet. Por në të njëjtën kohë, koha për këtë transaksion rritet.
Unë kam një rregull shumë të thjeshtë: merrni sa më shumë që mundeni, por mos kaloni mbi ekzekutuesit për sekondë.
Pse një sekondë? Shpjegimi është shumë i thjeshtë dhe i kuptueshëm për të gjithë, edhe për njerëzit jo teknikë. Ne shohim një reagim. Le të marrim 50 milisekonda. Nëse diçka ka ndryshuar, atëherë syri ynë do të reagojë. Nëse më pak, atëherë më e vështirë. Nëse diçka përgjigjet pas 100 milisekondash, për shembull, ju keni klikuar miun dhe ai ju përgjigjet pas 100 milisekondash, ju tashmë e ndjeni këtë vonesë të vogël. Një sekondë tashmë perceptohet si frena.
Prandaj, nëse i thyejmë operacionet tona masive në breshëri 10 sekondash, atëherë kemi rrezik që të bllokojmë dikë. Dhe do të funksionojë për disa sekonda, dhe njerëzit tashmë do ta vënë re atë. Prandaj, preferoj të mos bëj më shumë se një sekondë. Por në të njëjtën kohë, mos e prishni atë shumë mirë, sepse shpenzimet e sipërme të transaksionit do të jenë të dukshme. Baza do të jetë më e vështirë dhe mund të shfaqen probleme të tjera të ndryshme.
Ne zgjedhim madhësinë e paketës. Në secilin rast, ne mund ta bëjmë atë ndryshe. Mund të automatizohet. Dhe ne jemi të bindur për efikasitetin e përpunimit të një pakete. Kjo do të thotë, ne bëjmë DELETE të një pakete ose UPDATE.
Meqë ra fjala, gjithçka për të cilën po flas nuk ka të bëjë vetëm me fshirjen. Siç e menduat, këto janë çdo operacion me shumicë në të dhëna.
Dhe ne shohim që plani është i shkëlqyer. Ju mund të shihni skanimin e indeksit, skanimi vetëm me indeks është edhe më i mirë. Dhe ne kemi një sasi të vogël të të dhënave të përfshira. Dhe më pak se një sekondë përmbush. Super.
Dhe ne ende duhet të sigurohemi që të mos ketë degradim. Ndodh që paketat e para të funksionojnë shpejt, dhe më pas bëhet më keq, më keq dhe më keq. Procesi është i tillë që ju duhet të provoni shumë. Kjo është pikërisht ajo për të cilën janë laboratorët e bazës së të dhënave.
Dhe ne ende duhet të përgatisim diçka në mënyrë që të na lejojë ta ndjekim këtë saktë në prodhim. Për shembull, ne mund të shkruajmë kohën në regjistër, mund të shkruajmë se ku jemi tani dhe kë kemi fshirë tani. Dhe kjo do të na lejojë të kuptojmë se çfarë po ndodh më vonë. Dhe në rast se diçka shkon keq, gjeni shpejt problemin.
Nëse duhet të kontrollojmë efikasitetin e kërkesave dhe duhet të përsërisim shumë herë, atëherë ekziston një gjë e tillë si një bot tjetër. Ai tashmë është gati. Përdoret nga dhjetëra zhvillues çdo ditë. Dhe ai e di se si të japë një bazë të dhënash të madhe terabyte sipas kërkesës në 30 sekonda, kopjen tuaj. Dhe mund të fshini diçka atje dhe të thoni RESET, dhe ta fshini përsëri. Ju mund të eksperimentoni me të në këtë mënyrë. Unë shoh një të ardhme për këtë gjë. Dhe ne tashmë po e bëjmë atë.
Cilat janë strategjitë e ndarjes? Unë shoh 3 strategji të ndryshme ndarjeje që zhvilluesit në paketë po përdorin.
E para është shumë e thjeshtë. Ne kemi një ID numerike. Dhe le ta ndajmë atë në intervale të ndryshme dhe të punojmë me këtë. Ana negative është e qartë. Në segmentin e parë mund të kemi 100 rreshta mbeturina të vërteta, në të dytin 5 rreshta ose aspak, ose të 1 rreshtat do të rezultojnë të jenë mbeturina. Puna shumë e pabarabartë, por është e lehtë për t'u thyer. Morën letërnjoftimin maksimal dhe e thyen. Kjo është një qasje naive.
Strategjia e dytë është një qasje e balancuar. Përdoret në Gitlab. Ata morën dhe skanuan tryezën. Ne gjetëm kufijtë e paketave të identitetit në mënyrë që çdo paketë të kishte saktësisht 10 regjistrime. Dhe vendosini në një radhë. Dhe pastaj ne përpunojmë. Ju mund ta bëni këtë në fije të shumta.
Në strategjinë e parë, gjithashtu, meqë ra fjala, ju mund ta bëni këtë në disa fije. Nuk është e vështirë.
Por ka një qasje më të ftohtë dhe më të mirë. Kjo është strategjia e tretë. Dhe kur është e mundur, është më mirë ta zgjidhni atë. Ne e bëjmë këtë në bazë të një indeksi të veçantë. Në këtë rast, ka shumë të ngjarë të jetë një indeks sipas gjendjes sonë të plehrave dhe ID-së. Ne do të përfshijmë ID-në në mënyrë që të jetë një skanim vetëm me indeks, në mënyrë që të mos shkojmë në grumbull.
Në përgjithësi, skanimi vetëm me indeks është më i shpejtë se skanimi i indeksit.
Dhe ne gjejmë shpejt ID-të tona që duam t'i heqim. BATCH_SIZE ne zgjedhim paraprakisht. Dhe ne jo vetëm që i marrim, por i marrim në një mënyrë të veçantë dhe i hakojmë menjëherë. Por ne po mbyllim që nëse janë tashmë të kyçur, të mos i mbyllim, por të vazhdojmë dhe të marrim të tjerat. Kjo është për përditësimin, kapërcimi është i kyçur. Kjo super veçori e Postgres na lejon të punojmë në disa thread nëse duam. Është e mundur në një rrjedhë. Dhe këtu ka një CTE - kjo është një kërkesë. Dhe ne kemi një fshirje të vërtetë që po ndodh në katin e dytë të kësaj CTE - returning *. Mund ta kthesh ID-në, por është më mirë *nëse nuk keni shumë të dhëna për secilën rresht.
Pse na duhet? Kjo është ajo që ne duhet të raportojmë përsëri. Tani kemi fshirë kaq shumë rreshta në fakt. Dhe ne kemi kufij me ID ose nga krijuar_at si kjo. Ju mund të bëni min, maksimum. Diçka tjetër mund të bëhet. Këtu mund të bëni shumë gjëra. Dhe është shumë i përshtatshëm për monitorim.
Ka edhe një shënim tjetër për indeksin. Nëse vendosim se kemi nevojë për një indeks të veçantë për këtë detyrë, atëherë duhet të sigurohemi që ai të mos prishë përditësimet e grumbullimit të vetëm tuples. Dmth Postgres ka statistika të tilla. Kjo mund të shihet në pg_stat_user_tables për tabelën tuaj. Mund të shihni nëse përditësimet e nxehta po përdoren apo jo.
Ka situata kur indeksi juaj i ri thjesht mund t'i ndërpresë ato. Dhe ju keni të gjitha përditësimet e tjera që tashmë po funksionojnë, ngadalësoni. Jo vetëm sepse u shfaq indeksi (çdo indeks ngadalëson përditësimet pak, por pak), por këtu ai ende e prish atë. Dhe është e pamundur të bëhet një optimizim i veçantë për këtë tabelë. Kjo ndodh ndonjëherë. Kjo është një hollësi e tillë që pak njerëz e mbajnë mend. Dhe kjo grabujë është e lehtë për tu shkelur. Ndonjëherë ndodh që ju duhet të gjeni një qasje nga ana tjetër dhe të bëni akoma pa këtë indeks të ri, ose të bëni një indeks tjetër, ose në ndonjë mënyrë tjetër, për shembull, mund të përdorni metodën e dytë.
Por kjo është strategjia më optimale, si të ndaheni në tufa dhe të qëlloni në tufa me një kërkesë, të fshini pak, etj.
Transaksionet e gjata
Autovakum i bllokuar -
problem bllokimi -
Gabimi numër 5 është i madh. Nikolai nga Okmeter foli për monitorimin e Postgres. Monitorimi Ideal Postgres, për fat të keq, nuk ekziston. Disa janë më afër, disa janë më larg. Okmeter është mjaft afër për të qenë perfekt, por shumë mungojnë dhe duhet shtuar. Ju duhet të jeni gati për këtë.
Për shembull, tuplet e vdekur monitorohen më së miri. Nëse keni shumë gjëra të vdekura në tabelë, atëherë diçka nuk është në rregull. Është më mirë të reagojmë tani, përndryshe mund të ketë degradim dhe mund të shtrihemi. Ndodh.
Nëse ka një IO të madhe, atëherë është e qartë se kjo nuk është e mirë.
Transaksione të gjata gjithashtu. Transaksionet e gjata nuk duhet të lejohen në OLTP. Dhe këtu është një lidhje me një fragment që ju lejon të merrni këtë fragment dhe të bëni tashmë disa gjurmime të transaksioneve të gjata.
Pse transaksionet e gjata janë të këqija? Sepse të gjitha bravat do të lirohen vetëm në fund. Dhe ne i vidhosim të gjithë. Plus, ne bllokojmë autovakumin për të gjitha tavolinat. Nuk është aspak mirë. Edhe nëse e keni të aktivizuar gatishmërinë e nxehtë në kopje, është ende keq. Në përgjithësi, askund nuk është më mirë të shmangni transaksionet e gjata.
Nëse kemi shumë tabela që nuk janë të pastruara me korrent, atëherë duhet të kemi një alarm. Këtu një situatë e tillë është e mundur. Mund të ndikojmë indirekt në funksionimin e autovakumit. Ky është një fragment nga Avito, të cilin e përmirësova pak. Dhe doli të ishte një mjet interesant për të parë se çfarë kemi me autovakum. Për shembull, disa tavolina janë duke pritur atje dhe nuk do të presin radhën e tyre. Ju gjithashtu duhet ta vendosni atë në monitorim dhe të keni një alarm.
Dhe lëshon blloqe. Pyll me pemë blloku. Më pëlqen të marr diçka nga dikush dhe ta përmirësoj atë. Këtu, Data Egret mori një CTE rekursive të lezetshme që tregon një pyll me pemë të mbyllura. Ky është një mjet i mirë diagnostikues. Dhe mbi bazën e tij, ju gjithashtu mund të ndërtoni monitorim. Por kjo duhet bërë me kujdes. Ju duhet të bëni një deklaratë të vogël timeout për veten tuaj. Dhe lock_timeout është e dëshirueshme.
Ndonjëherë të gjitha këto gabime ndodhin në përmbledhje.
Për mendimin tim, gabimi kryesor këtu është organizativ. Është organizative, sepse teknika nuk tërheq. Ky është numri 2 - ata kontrolluan në vendin e gabuar.
Ne kontrolluam në vendin e gabuar, sepse nuk kishim një klon prodhimi, i cili kontrollohet lehtë. Një zhvillues mund të mos ketë fare akses në prodhim.
Dhe ne nuk kontrolluam atje. Nëse do të kishim kontrolluar atje, do ta kishim parë vetë. Zhvilluesi i pa të gjitha edhe pa një DBA nëse e kontrollonte në një mjedis të mirë, ku ka të njëjtën sasi të dhënash dhe një vendndodhje identike. Do ta kishte parë gjithë këtë degradim dhe do t'i vinte turp.
Më shumë rreth autovakumit. Pasi të kemi bërë një spastrim masiv prej disa milion linjash, duhet të bëjmë RIPACK. Kjo është veçanërisht e rëndësishme për indekset. Ata do të ndihen keq pasi të kemi pastruar gjithçka atje.
Dhe nëse doni të riktheni punën e përditshme të pastrimit, atëherë do të sugjeroja ta bëni atë më shpesh, por më të vogël. Mund të jetë një herë në minutë ose edhe më shpesh pak. Dhe ju duhet të monitoroni dy gjëra: që kjo gjë të mos ketë gabime dhe që të mos mbetet pas. Truku që tregova thjesht do ta zgjidhë këtë.
Ajo që ne bëjmë është me kod të hapur. Është postuar në GitLab. Dhe ne e bëjmë atë në mënyrë që njerëzit të mund të kontrollojnë edhe pa një DBA. Ne po bëjmë një laborator të bazës së të dhënave, domethënë, ne e quajmë komponentin bazë në të cilin Joe po punon aktualisht. Dhe ju mund të kapni një kopje të prodhimit. Tani ekziston një zbatim i Joe-së për zbehje, mund të thoni atje: "shpjegoni këtë dhe atë kërkesë" dhe merrni menjëherë rezultatin për kopjen tuaj të bazës së të dhënave. Mund edhe të fshini atje, dhe askush nuk do ta vërejë atë.
Le të themi se keni 10 terabajt, ne e bëjmë laboratorin e bazës së të dhënave gjithashtu 10 terabajt. Dhe me bazat e të dhënave të njëkohshme 10 terabyte, 10 zhvillues mund të punojnë njëkohësisht. Të gjithë mund të bëjnë çfarë të duan. Mund të fshijë, lëshojë, etj. Kjo është një fantazi e tillë. Nesër do të flasim për këtë.
Kjo quhet furnizim i hollë. Ky është sigurim delikate. Kjo është një lloj fantazie që largon shumë vonesat në zhvillim, në testim dhe e bën botën një vend më të mirë në këtë drejtim. Kjo do të thotë, thjesht ju lejon të shmangni problemet me operacionet me shumicë.
Shembull: baza e të dhënave 5 terabyte, duke marrë një kopje në më pak se 30 sekonda. Dhe nuk varet as nga madhësia, domethënë nuk ka rëndësi sa terabajt.
Sot mund të shkoni në dhe gërmoni në veglat tona. Mund të regjistroheni për të parë se çfarë ka. Mund ta instaloni këtë bot. Është falas. Shkruaj.
Pyetjet tuaja
Shumë shpesh në situata reale rezulton se të dhënat që duhet të mbeten në tabelë janë shumë më pak se ato që duhen fshirë. Kjo do të thotë, në një situatë të tillë, shpesh është më e lehtë të zbatohet një qasje e tillë, kur është më e lehtë të krijosh një objekt të ri, të kopjosh vetëm të dhënat e nevojshme atje dhe të trungosh tabelën e vjetër. Është e qartë se për këtë moment nevojitet një qasje programore, ndërkohë që ju do të kaloni. Si është kjo qasje?
Kjo është një qasje shumë e mirë dhe një detyrë shumë e mirë. Është shumë e ngjashme me atë që bën pg_repack, është shumë e ngjashme me atë që duhet të bëni kur i bëni ID-të 4 bajt. Shumë korniza e bënë këtë disa vite më parë, dhe vetëm pllakat janë rritur dhe ato duhet të konvertohen në 8 bajt.
Kjo detyrë është mjaft e vështirë. Ne e beme ate. Dhe duhet të jeni shumë të kujdesshëm. Ka brava etj. Por po bëhet. Kjo do të thotë, qasja standarde është të shkosh me pg_repack. Ju deklaroni një etiketë të tillë. Dhe përpara se të filloni të ngarkoni të dhënat e fotografive në të, ju gjithashtu deklaroni një pllakë që gjurmon të gjitha ndryshimet. Ekziston një truk që mund të mos gjurmoni as disa ndryshime. Ka hollësi. Dhe pastaj kaloni duke rrotulluar ndryshimet. Do të ketë një pauzë të shkurtër kur t'i mbyllim të gjithë, por në përgjithësi kjo po bëhet.
Nëse shikoni pg_repack në GitHub, atëherë atje, kur kishte një detyrë për të kthyer një ID nga int 4 në int 8, atëherë kishte një ide për të përdorur vetë pg_repack. Kjo është gjithashtu e mundur, por është pak hak, por do të funksionojë edhe për këtë. Ju mund të ndërhyni në këmbëzën që përdor pg_repack dhe të thoni atje: "Nuk na duhen këto të dhëna", d.m.th. ne transferojmë vetëm atë që na nevojitet. Dhe pastaj ai thjesht ndërron dhe kaq.
Me këtë qasje, ne ende marrim një kopje të dytë të tabelës, në të cilën të dhënat tashmë janë të indeksuara dhe të grumbulluara në mënyrë shumë të barabartë me indekse të bukura.
Fryrja nuk është e pranishme, është një qasje e mirë. Por e di që ka përpjekje për të zhvilluar një automatizim për këtë, pra për të bërë një zgjidhje universale. Unë mund t'ju vë në kontakt me këtë automatizim. Është shkruar në Python, gjë që është një gjë e mirë.
Unë jam vetëm pak nga bota e MySQL, kështu që erdha të dëgjoj. Dhe ne përdorim këtë qasje.
Por kjo është vetëm nëse kemi 90%. Nëse kemi 5%, atëherë nuk është shumë mirë ta përdorim.
Faleminderit për raportin! Nëse nuk ka burime për të bërë një kopje të plotë të prod-it, a ka ndonjë algoritëm ose formulë për të llogaritur ngarkesën ose madhësinë?
Pyetje e mirë. Deri më tani, ne jemi në gjendje të gjejmë baza të dhënash me shumë terabajt. Edhe nëse hardueri atje nuk është i njëjtë, për shembull, më pak memorie, më pak procesor dhe disqe nuk janë saktësisht të njëjta, por gjithsesi ne e bëjmë atë. Nëse nuk ka absolutisht askund, atëherë duhet të mendoni. Më lejoni të mendoj deri nesër, ju keni ardhur, ne do të flasim, kjo është një pyetje e mirë.
Faleminderit për raportin! Ju fillimisht filluat për faktin se ekziston një Postgres i lezetshëm, i cili ka kufizime të tilla e kaq, por po zhvillohet. Dhe kjo është e gjitha një patericë në përgjithësi. A nuk është e gjithë kjo në kundërshtim me zhvillimin e vetë Postgres, në të cilin do të shfaqet ndonjë DELETE deferent apo diçka tjetër që duhet të mbajë në një nivel të ulët atë që ne po përpiqemi të njollosim me disa nga mjetet tona të çuditshme këtu?
Nëse kemi thënë në SQL të fshijmë ose përditësojmë shumë regjistrime në një transaksion, atëherë si mund ta shpërndajë Postgres atje? Jemi të kufizuar fizikisht në operacione. Ne do ta bëjmë akoma për një kohë të gjatë. Dhe ne do të kyçemi në këtë kohë, etj.
Bërë me indekse.
Mund të supozoj se i njëjti akordim i pikës së kontrollit mund të jetë i automatizuar. Një ditë mund të jetë. Por atëherë nuk e kuptoj vërtet pyetjen.
Pyetja është, a ka një vektor të tillë zhvillimi që shkon aty-këtu, dhe këtu i juaji shkon paralel? ato. Nuk e kanë menduar akoma?
Unë fola për parimet që mund të përdoren tani. Ka një bot tjetër , me këtë ju mund të bëni akordim automatik të pikës së kontrollit. A do të jetë një ditë në Postgres? Nuk e di, as që është diskutuar ende. Jemi ende larg kësaj. Por ka shkencëtarë që bëjnë sisteme të reja. Dhe ata na shtyjnë në indekse automatike. Ka zhvillime. Për shembull, mund të shikoni akordimin automatik. Ai zgjedh parametrat automatikisht. Por ai nuk do të bëjë ende akordim të pikës së kontrollit për ju. Kjo do të thotë, do të marrë përsipër performancën, buferin e guaskës, etj.
Dhe për akordimin e pikës së kontrollit, mund ta bëni këtë: nëse keni një mijë grupime dhe pajisje të ndryshme, makina të ndryshme virtuale në cloud, mund të përdorni botin tonë bëni automatizim. Dhe max_wal_size do të zgjidhet automatikisht sipas cilësimeve tuaja të synuara. Por deri tani kjo nuk është as afër në thelb, për fat të keq.
Mirembrema Ju folët për rreziqet e transaksioneve të gjata. Ju thatë që autovakuumi bllokohet në rast fshirjesh. Si ndryshe na dëmton? Sepse ne po flasim më shumë për lirimin e hapësirës dhe mundësinë për ta përdorur atë. Çfarë na mungon tjetër?
Autovakum nuk është ndoshta problemi më i madh këtu. Dhe fakti që një transaksion i gjatë mund të bllokojë transaksione të tjera, kjo mundësi është më e rrezikshme. Ajo mund të takohet ose jo. Nëse ajo u takua, atëherë mund të jetë shumë keq. Dhe me autovakum - ky është gjithashtu një problem. Ekzistojnë dy probleme me transaksionet e gjata në OLTP: bravat dhe autovakum. Dhe nëse keni të aktivizuar reagimet e gatishmërisë së nxehtë në kopje, atëherë do të merrni përsëri një bllokim autovakum në master, ai do të vijë nga kopja. Por të paktën nuk do të ketë bravë. Dhe do të ketë lopë. Ne po flasim për ndryshime të të dhënave, kështu që kyçjet janë një pikë e rëndësishme këtu. Dhe nëse kjo është e gjitha për një kohë të gjatë, të gjatë, atëherë gjithnjë e më shumë transaksione bllokohen. Ata mund të vjedhin të tjerët. Dhe shfaqen pemë lok. Kam dhënë një lidhje për fragmentin. Dhe ky problem bëhet më i dukshëm më shpejt se problemi me autovakum, i cili vetëm mund të grumbullohet.
Faleminderit për raportin! Ju e nisët raportin tuaj duke thënë se keni testuar gabim. Vazhduam idenë tonë se duhet të marrim të njëjtat pajisje, me bazën në të njëjtën mënyrë. Le të themi se i kemi dhënë zhvilluesit një bazë. Dhe ai e plotësoi kërkesën. Dhe duket se është mirë. Por ai nuk kontrollon për live, por për live, për shembull, ne kemi një ngarkesë prej 60-70%. Dhe edhe nëse e përdorim këtë akordim, nuk funksionon shumë mirë.
Të kesh një ekspert në ekip dhe të përdorësh ekspertë të DBA që mund të parashikojnë se çfarë do të ndodhë me një ngarkesë reale të sfondit është e rëndësishme. Kur sapo bëmë ndryshimet tona të pastra, shohim foton. Por një qasje më e avancuar, kur bëmë përsëri të njëjtën gjë, por me një ngarkesë të simuluar me prodhimin. Është mjaft e lezetshme. Deri atëherë, ju duhet të rriteni. Është si një i rritur. Ne thjesht shikuam atë që kemi dhe gjithashtu shikuam nëse kemi burime të mjaftueshme. Kjo është një pyetje e mirë.
Kur tashmë jemi duke bërë një përzgjedhje të mbeturinave dhe kemi, për shembull, një flamur të fshirë
Kjo është ajo që autovakuumi bën automatikisht në Postgres.
Oh, a e bën ai?
Autovakuumi është mbledhësi i plehrave.
Ju faleminderit!
Faleminderit për raportin! A ka një mundësi për të hartuar menjëherë një bazë të dhënash me ndarje në mënyrë të tillë që të gjitha mbeturinat të ndoten nga tavolina kryesore diku anash?
Sigurisht që kanë.
A është e mundur atëherë të mbrohemi nëse kemi mbyllur një tavolinë që nuk duhet të përdoret?
Sigurisht që kanë. Por është si një pyetje pule dhe vezë. Nëse të gjithë e dimë se çfarë do të ndodhë në të ardhmen, atëherë, sigurisht, do të bëjmë gjithçka të mirë. Por biznesi po ndryshon, ka rubrika të reja, kërkesa të reja. Dhe pastaj - oops, ne duam ta heqim atë. Por kjo situatë ideale, në jetë ndodh, por jo gjithmonë. Por në përgjithësi është një ide e mirë. Thjesht shkurtoje dhe kaq.
Burimi: www.habr.com