Einhvern tíma í fjarlægri framtíð mun sjálfvirk fjarlæging óþarfa gagna vera eitt af mikilvægum verkefnum DBMS [1]. Í millitíðinni þurfum við sjálf að sjá um að eyða eða flytja óþarfa gögn í ódýrari geymslukerfi. Segjum að þú ákveður að eyða nokkrum milljónum línum. Nokkuð einfalt verkefni, sérstaklega ef ástandið er þekkt og það er viðeigandi vísitala. "DELETE FROM table1 WHERE col1 = :value" - hvað gæti verið einfaldara, ekki satt?
Video:
-
Ég hef setið í Highload dagskrárnefnd frá fyrsta ári, þ.e.a.s. síðan 2007.
-
Og ég hef verið hjá Postgres síðan 2005. Notaði það í mörgum verkefnum.
-
Hópur einnig með RuPostges síðan 2007.
-
Við erum orðin 2100+ þátttakendur á Meetup. Það er í öðru sæti í heiminum á eftir New York, sem San Francisco tók fram úr í langan tíma.
-
Ég hef búið í Kaliforníu í nokkur ár. Ég á meira við bandarísk fyrirtæki, þar á meðal stór. Þeir eru virkir notendur Postgres. Og það er alls konar áhugavert.
er fyrirtækið mitt. Við erum í bransanum að gera sjálfvirk verkefni sem koma í veg fyrir hægagang í þróun.
Ef þú ert að gera eitthvað, þá eru stundum einhvers konar innstungur í kringum Postgres. Segjum að þú þurfir að bíða eftir að stjórnandinn setji upp prufustand fyrir þig, eða þú þarft að bíða eftir að DBA svari þér. Og við finnum slíka flöskuhálsa í þróunar-, prófunar- og stjórnunarferlinu og reynum að útrýma þeim með hjálp sjálfvirkni og nýrra aðferða.
Ég var nýlega á VLDB í Los Angeles. Þetta er stærsta ráðstefnan um gagnagrunna. Og það var skýrsla um að í framtíðinni muni DBMS ekki aðeins geyma, heldur einnig sjálfkrafa eyða gögnum. Þetta er nýtt umræðuefni.
Það eru fleiri og fleiri gögn í heimi zettabæta - það eru 1 petabæt. Og nú er þegar áætlað að við höfum meira en 000 zettabæta af gögnum geymd í heiminum. Og þeir eru fleiri og fleiri.
Og hvað á að gera við það? Það þarf greinilega að fjarlægja það. Hér er hlekkur á þessa áhugaverðu skýrslu. En hingað til hefur þetta ekki verið innleitt í DBMS.
Þeir sem geta talið peninga vilja tvennt. Þeir vilja að við eyðum, svo tæknilega séð ættum við að geta gert það.
Það sem ég mun segja næst er einhver óhlutbundin staða sem inniheldur fullt af raunverulegum aðstæðum, þ.e.a.s. eins konar samantekt á því sem raunverulega gerðist fyrir mig og gagnagrunna í kring oft, mörg ár. Hrífur eru alls staðar og allir stíga á þær allan tímann.
Segjum að við höfum grunn eða nokkrar bækistöðvar sem eru að stækka. Og sumar plötur eru augljóslega rusl. Til dæmis byrjaði notandinn að gera eitthvað þar en kláraði það ekki. Og eftir nokkurn tíma vitum við að þetta ókláraða er ekki lengur hægt að geyma. Það er að segja, við viljum gjarnan þrífa suma ruslahluti til að spara pláss, bæta afköst o.s.frv.
Almennt séð er verkefnið að gera sjálfvirkan fjarlægingu á tilteknum hlutum, ákveðnum línum í einhverri töflu.
Og við höfum slíka beiðni, sem við munum tala um í dag, það er að fjarlægja sorp.
Við báðum reyndan þróunaraðila að gera það. Hann tók þessari beiðni, athugaði hana sjálfur - allt virkar. Prófað á sviðsetningu - allt er í lagi. Rúllað út - allt virkar. Einu sinni á dag keyrum við það - allt er í lagi.
Gagnagrunnurinn stækkar og stækkar. Daily DELETE byrjar að virka aðeins hægar.
Þá skiljum við að nú erum við með markaðsfyrirtæki og umferðin verður margfalt meiri, svo við ákveðum að gera tímabundið hlé á óþarfa hlutum. Og gleymdu að snúa aftur.
Nokkrum mánuðum síðar minntust þeir. Og þessi verktaki hætti eða er upptekinn við eitthvað annað, sagði öðrum að skila því.
Hann athugaði á dev, á sviðsetningu - allt er í lagi. Auðvitað þarf samt að hreinsa upp það sem safnast hefur upp. Hann athugaði að allt virki.
Hvað gerist næst? Þá er allt í molum hjá okkur. Það lækkar þannig að á einhverjum tímapunkti dettur allt niður. Allir eru í sjokki, enginn skilur hvað er að gerast. Og svo kemur í ljós að málið var í þessu DELETE.
Eitthvað fór úrskeiðis? Hér er listi yfir það sem gæti hafa farið úrskeiðis. Hvert af þessu er mikilvægast?
-
Til dæmis var engin endurskoðun, þ.e.a.s. DBA sérfræðingur skoðaði hana ekki. Hann myndi strax finna vandamálið með reyndu auga, og þar að auki hefur hann aðgang að prod, þar sem nokkrar milljónir lína hafa safnast fyrir.
-
Kannski hafa þeir athugað eitthvað rangt.
-
Kannski er vélbúnaðurinn gamaldags og þú þarft að uppfæra þennan grunn.
-
Eða eitthvað er athugavert við gagnagrunninn sjálfan og við þurfum að fara frá Postgres yfir í MySQL.
-
Eða kannski er eitthvað að aðgerðinni.
-
Kannski eru einhver mistök í skipulagi vinnu og þarf að reka einhvern og ráða besta fólkið?
Það var engin DBA athugun. Ef það væri DBA myndi hann sjá þessar nokkrar milljónir línur og jafnvel án nokkurra tilrauna myndi hann segja: "Þeir gera það ekki." Segjum sem svo að ef þessi kóði væri í GitLab, GitHub og það væri kóðaendurskoðunarferli og það væri ekkert slíkt að án samþykkis DBA myndi þessi aðgerð eiga sér stað á pród, þá myndi DBA augljóslega segja: „Þetta er ekki hægt að gera .”
Og hann myndi segja að þú munt eiga í vandræðum með disk IO og allir ferlar verða brjálaðir, það gætu verið læsingar og þú lokar líka fyrir sjálfvirkt tómarúm í nokkrar mínútur, svo þetta er ekki gott.
Önnur mistök - þeir tékkuðu á röngum stað. Við sáum í kjölfarið að mikið af ruslgögnum safnaðist á prod, en verktaki var ekki með uppsafnað gögn í þessum gagnagrunni og enginn bjó til þetta rusl við sviðsetningu. Samkvæmt því voru 1 línur sem gengu fljótt upp.
Við skiljum að prófin okkar eru veik, þ.e.a.s. ferlið sem er byggt tekur ekki vandamál. Fullnægjandi DB tilraun var ekki gerð.
Tilvalin tilraun er helst gerð á sama búnaði. Það er ekki alltaf hægt að gera þetta á sama búnaðinum en það er mjög mikilvægt að þetta sé afrit af gagnagrunninum í fullri stærð. Þetta er það sem ég hef verið að boða í nokkur ár núna. Og fyrir ári síðan talaði ég um þetta, þú getur horft á þetta allt á YouTube.
Kannski er búnaður okkar slæmur? Ef þú horfir, þá hoppaði leynd. Við höfum séð að nýtingin er 100%. Auðvitað, ef þetta væru nútíma NVMe drif, þá væri það líklega miklu auðveldara fyrir okkur. Og kannski myndum við ekki leggjast frá því.
Ef þú ert með ský, þá er uppfærslan auðveldlega gerð þar. Búið að hækka nýjar eftirmyndir á nýja vélbúnaðinum. skipti. Og allt er gott. Frekar auðvelt.
Er hægt að snerta minni diskana einhvern veginn? Og hér, bara með hjálp DBA, kafum við inn í ákveðið efni sem kallast eftirlitsstillingar. Það kemur í ljós að við vorum ekki með eftirlitsstillingar.
Hvað er eftirlitsstöð? Það er í hvaða DBMS sem er. Þegar þú ert með gögn í minni sem breytast eru þau ekki skrifuð strax á diskinn. Upplýsingarnar um að gögnin hafi breyst eru fyrst skrifaðar í framfærsluskrána. Og á einhverjum tímapunkti ákveður DBMS að það sé kominn tími til að dumpa raunverulegum síðum á diskinn, þannig að ef við verðum bilun getum við gert minna REDO. Það er eins og leikfang. Ef við erum drepnir byrjum við leikinn frá síðasta eftirlitsstöðinni. Og allir DBMS útfæra það.
Stillingarnar í Postgres eru eftirbátar. Þau eru hönnuð fyrir 10-15 ára gagnamagn og viðskipti. Og eftirlitsstöð er engin undantekning.
Hér eru upplýsingarnar úr Postgres skoðunarskýrslu okkar, þ.e. sjálfvirka heilsufarsskoðun. Og hér er einhver gagnagrunnur með nokkrum terabætum. Og það sést vel að þvingaðar eftirlitsstöðvar í tæplega 90% tilvika.
Hvað þýðir það? Það eru tvær stillingar þarna. Eftirlitsstöð getur komið með tímamörkum, til dæmis á 10 mínútum. Eða það getur komið þegar töluvert mikið af gögnum hefur verið fyllt út.
Og sjálfgefið er max_wal_saze stillt á 1 gígabæt. Reyndar gerist þetta í Postgres eftir 300-400 megabæti. Þú hefur breytt svo miklum gögnum og eftirlitsstöðin þín gerist.
Og ef enginn stillti það, og þjónustan stækkaði, og fyrirtækið græðir mikið, það hefur mikið af viðskiptum, þá kemur eftirlitsstöðin einu sinni á mínútu, stundum á 30 sekúndna fresti, og stundum skarast það. Þetta er frekar slæmt.
Og við þurfum að tryggja að það komi sjaldnar. Það er, við getum hækkað max_wal_size. Og það mun koma sjaldnar.
En við höfum þróað heila aðferðafræði um hvernig á að gera það réttara, það er hvernig á að taka ákvörðun um val á stillingum, skýrt byggða á tilteknum gögnum.
Í samræmi við það erum við að gera tvær tilraunir á gagnagrunnum.
Fyrsta röð - við breytum max_wal_size. Og við erum að gera stórfellda aðgerð. Í fyrsta lagi gerum við það á sjálfgefna stillingunni 1 gígabæta. Og við gerum stórfellda DELETE af mörgum milljónum lína.
Þú sérð hversu erfitt það er fyrir okkur. Við sjáum að diskur IO er mjög slæmur. Við skoðum hversu mörg WAL við höfum búið til, því þetta er mjög mikilvægt. Við skulum sjá hversu oft eftirlitsstöðin gerðist. Og við sjáum að það er ekki gott.
Næst aukum við max_wal_size. Við endurtökum. Við aukum, við endurtökum. Og svo oft. Í grundvallaratriðum eru 10 stig gott, þar sem 1, 2, 4, 8 gígabæt. Og við skoðum hegðun tiltekins kerfis. Það er ljóst að hér á búnaðurinn að vera eins og á pród. Þú verður að hafa sömu diska, sama magn af minni og sömu Postgres stillingar.
Og á þennan hátt munum við skiptast á kerfinu okkar, og við vitum hvernig DBMS mun haga sér ef slæmt massa DELETE, hvernig það mun eftirlitsstöð.
Checkpoint á rússnesku eru checkpoints.
Dæmi: EYÐU nokkrum milljónum lína eftir vísitölu, línur eru "dreifðar" um síður.
Hér er dæmi. Þetta er einhver grunnur. Og með sjálfgefna stillingu 1 gígabæta fyrir max_wal_size er mjög ljóst að diskarnir okkar fara í hilluna til upptöku. Þessi mynd er dæmigert einkenni mjög veikans sjúklings, það er að segja honum leið virkilega illa. Og það var ein aðgerð, það var bara DELETE af nokkrum milljónum línum.
Ef svona aðgerð er leyfð í prúð þá leggjumst við bara, því það er ljóst að einn DELETE drepur okkur í hillunni.
Ennfremur, þar sem 16 gígabæt, er ljóst að tennurnar hafa þegar farið. Tennur eru nú þegar betri, það er, við erum að banka í loftið, en ekki svo slæmt. Þar var nokkurt frelsi. Hægra megin er skráin. Og fjöldi aðgerða - annað línuritið. Og það er ljóst að við erum nú þegar að anda aðeins léttar þegar 16 gígabæt.
Og þar sem 64 gígabæt má sjá að það er orðið algjörlega betra. Nú þegar eru tennurnar áberandi, það eru fleiri tækifæri til að lifa af aðrar aðgerðir og gera eitthvað við diskinn.
Hvers vegna er það svo?
Ég mun kafa aðeins ofan í smáatriðin, en þetta efni, hvernig á að haga stillingu eftirlitsstaða, getur leitt til heilrar skýrslu, svo ég mun ekki hlaða miklu, en ég mun útlista örlítið hvaða erfiðleikar eru.
Ef eftirlitspunkturinn gerist of oft, og við uppfærum línurnar okkar ekki í röð, heldur finnum eftir vísitölu, sem er gott, vegna þess að við eyðum ekki allri töflunni, þá getur það gerst að við snertum fyrst fyrstu síðuna, síðan þá þúsundustu, og sneri svo aftur til hinnar fyrstu. Og ef á milli þessara heimsókna á fyrstu síðu hefur checkpoint þegar vistað það á disk, þá mun það vista það aftur, vegna þess að við urðum óhrein í annað sinn.
Og við munum þvinga eftirlitsstöð til að vista það mörgum sinnum. Hvernig væri óþarfi aðgerðir fyrir hann.
En það er ekki allt. Síður eru 8 kílóbæti í Postgres og 4 kílóbæti í Linux. Og það er full_page_writes stilling. Það er sjálfgefið virkt. Og þetta er rétt, því ef við slökkva á því, þá er hætta á að aðeins helmingur síðunnar verði vistaður ef hún hrynur.
Hegðunin við að skrifa á WAL framvirka logsins er þannig að þegar við erum með eftirlitsstöð og við skiptum um síðu í fyrsta skipti, þá kemst öll síðan, þ.e.a.s. öll 8 kílóbæti, inn í framvirkan log, þó við breyttum aðeins lína, sem vegur 100 bæti. Og við verðum að skrifa niður alla síðuna.
Í síðari breytingum verður aðeins ákveðinn tuple, en í fyrsta skipti skrifum við allt niður.
Og í samræmi við það, ef eftirlitsstöðin gerðist aftur, þá verðum við að byrja allt frá grunni aftur og ýta á alla síðuna. Með tíðum eftirlitsstöðvum, þegar við förum í gegnum sömu síður, verður full_page_writes = on meira en það gæti verið, þ.e.a.s. við myndum meira WAL. Meira er sent á eftirmyndir, í skjalasafnið, á diskinn.
Og í samræmi við það höfum við tvær uppsagnir.
Ef við aukum max_wal_size kemur í ljós að við gerum það auðveldara fyrir bæði checkpoint og wal writer. Og það er frábært.
Við skulum setja terabæt og lifa með því. Hvað er slæmt við það? Þetta er slæmt, vegna þess að ef bilun verður, munum við klifra tímunum saman, vegna þess að eftirlitsstöðin var fyrir löngu síðan og margt hefur þegar breyst. Og við þurfum að gera allt þetta REDO. Og svo gerum við aðra röð tilrauna.
Við gerum aðgerð og sjáum hvenær eftirlitsstöðin er við það að klárast, við drepum -9 Postgres viljandi.
Og eftir það byrjum við það aftur, og sjáum hversu lengi það mun hækka á þessum búnaði, þ.e.a.s. hversu mikið það endurgerir í þessari slæmu stöðu.
Tvisvar mun ég taka það fram að ástandið er slæmt. Fyrst hrundum við rétt áður en eftirlitsstöðin var búin, þannig að við höfum miklu að tapa. Og í öðru lagi fórum við í stórfellda aðgerð. Og ef eftirlitsstöðvar væru á tímamörkum, þá myndi líklega minna WAL myndast frá síðasta eftirlitsstöð. Það er, það er tvöfaldur tapari.
Við mælum slíkar aðstæður fyrir mismunandi max_wal_size stærðir og skiljum að ef max_wal_size er 64 gígabæt, þá munum við klifra 10 mínútur í tvöfalt versta tilfelli. Og við hugsum hvort það hentar okkur eða ekki. Þetta er viðskiptaspurning. Þessa mynd þurfum við að sýna þeim sem bera ábyrgð á viðskiptaákvörðunum og spyrja: „Hversu lengi getum við legið í hámarki ef vandamál koma upp? Getum við lagst í verstu aðstæður í 3-5 mínútur? Og þú tekur ákvörðun.
Og hér er áhugaverður punktur. Við höfum nokkrar skýrslur um Patroni á ráðstefnunni. Og kannski ertu að nota það. Þetta er sjálfvirk bilun fyrir Postgres. GitLab og Data Egret töluðu um þetta.
Og ef þú ert með sjálfvirka bilun sem kemur eftir 30 sekúndur, þá getum við kannski legið í 10 mínútur? Vegna þess að við munum skipta yfir í eftirmyndina á þessum tímapunkti og allt verður í lagi. Þetta er álitamál. Ég veit ekki skýrt svar. Mér finnst bara að þetta umræðuefni snúist ekki aðeins um bata á hrun.
Ef við náum langan bata eftir bilun, þá verðum við óþægileg í mörgum öðrum aðstæðum. Til dæmis, í sömu tilraunum, þegar við gerum eitthvað og þurfum stundum að bíða í 10 mínútur.
Ég myndi samt ekki ganga of langt, jafnvel þótt við séum með sjálfvirka bilun. Að jafnaði eru gildi eins og 64, 100 gígabæt góð gildi. Stundum er jafnvel þess virði að velja minna. Almennt séð eru þetta lúmsk vísindi.
Til að gera endurtekningar, til dæmis, max_wal_size =1, 8, þarftu að endurtaka fjöldaaðgerðina mörgum sinnum. Þér tókst það. Og á sama grunni viltu gera það aftur, en þú hefur þegar eytt öllu. Hvað skal gera?
Ég mun síðar tala um lausn okkar, hvað við gerum til að endurtaka í slíkum aðstæðum. Og þetta er réttasta aðferðin.
En í þessu tilfelli vorum við heppnir. Ef, eins og það segir hér "BYRJA, EYÐA, ROLLBACK", þá getum við endurtekið DELETE. Það er að segja ef við hættum því sjálf, þá getum við endurtekið það. Og líkamlega á þér munu gögnin liggja á sama stað. Þú færð ekki einu sinni uppþembu. Þú getur endurtekið yfir slíkar DELETEs.
Þessi DELETE með ROLLBACK er tilvalin til að stilla eftirlitsstað, jafnvel þó að þú sért ekki með rétt uppsett gagnagrunnsrannsóknarstofu.
Við gerðum disk með einni dálki "i". Postgres hefur gagnsúlur. Þau eru ósýnileg nema sérstaklega sé beðið um. Þetta eru: ctid, xmid, xmax.
Ctid er líkamlegt heimilisfang. Núll síða, fyrsti túllinn á síðunni.
Það sést að eftir ROOLBACK stóð túpillinn á sama stað. Það er, við getum reynt aftur, það mun haga sér á sama hátt. Þetta er aðalatriðið.
Xmax er dauðatími tupelsins. Það var stimplað, en Postgres veit að færslan var færð til baka, þannig að það skiptir ekki máli hvort það er 0 eða það er rúllað til baka. Þetta bendir til þess að það sé hægt að endurtaka yfir DELETE og athuga magnaðgerðir kerfishegðunarinnar. Þú getur búið til gagnagrunnsrannsóknir fyrir fátæka.
Þetta snýst um forritara. Um DBA líka, þeir skamma forritara alltaf fyrir þetta: "Af hverju ertu að gera svona langar og erfiðar aðgerðir?". Þetta er allt annað hornrétt efni. Áður var stjórnsýsla og nú verður þróun.
Vitanlega höfum við ekki brotnað í sundur. Það er skýrt. Það er ómögulegt annað en að skipta svona DELETE fyrir hrúga af milljónum línur í hluta. Það verður gert í 20 mínútur, og allt mun leggjast niður. En því miður gera jafnvel reyndir verktaki mistök, jafnvel í mjög stórum fyrirtækjum.
Hvers vegna er mikilvægt að brjóta?
-
Ef við sjáum að diskurinn er harður, þá skulum við hægja á honum. Og ef við erum brotin, þá getum við bætt við hléum, við getum hægt á inngjöfinni.
-
Og við munum ekki loka á aðra í langan tíma. Í sumum tilfellum skiptir það ekki máli, ef þú ert að eyða raunverulegu sorpi sem enginn er að vinna í, þá er líklegast að þú lokar ekki á neinn nema sjálfvirka tómarúmsvinnuna, því það mun bíða eftir að viðskiptin ljúki. En ef þú fjarlægir eitthvað sem einhver annar getur beðið um, þá verður þeim lokað, það verður einhvers konar keðjuverkun. Forðast ætti löng viðskipti á vefsíðum og farsímaforritum.
Þetta er áhugavert. Ég sé oft að forritarar spyrja: "Hvaða pakkningastærð ætti ég að velja?".
Það er ljóst að því stærri sem búnturinn er, því minni er kostnaður við viðskipti, þ.e. viðbótarkostnaður af viðskiptum. En á sama tíma eykst tíminn fyrir þessi viðskipti.
Ég hef mjög einfalda reglu: Taktu eins mikið og þú getur, en ekki fara yfir executables á sekúndu.
Af hverju sekúndu? Skýringin er mjög einföld og öllum skiljanleg, jafnvel ekki tæknifólk. Við sjáum viðbrögð. Við skulum taka 50 millisekúndur. Ef eitthvað hefur breyst mun auga okkar bregðast við. Ef minna, þá erfiðara. Ef eitthvað svarar eftir 100 millisekúndur, til dæmis, þú smelltir á músina, og hún svaraði þér eftir 100 millisekúndur, finnurðu nú þegar fyrir þessari smá seinkun. Annað er þegar litið á sem bremsur.
Í samræmi við það, ef við skiptum fjöldaaðgerðum okkar í 10 sekúndna sprengingar, þá eigum við á hættu að við lokum á einhvern. Og það mun virka í nokkrar sekúndur og fólk mun þegar taka eftir því. Þess vegna vil ég helst ekki gera meira en eina sekúndu. En á sama tíma skaltu ekki brjóta það upp mjög fínt, því viðskiptakostnaðurinn verður áberandi. Grunnurinn verður erfiðari og önnur mismunandi vandamál geta komið upp.
Við veljum stærð pakkans. Í hverju tilviki getum við gert það öðruvísi. Hægt að gera sjálfvirkan. Og við erum sannfærð um skilvirkni vinnslu á einum pakka. Það er, við EYÐUM einum pakka eða UPPFÆRÐUM.
Við the vegur, allt sem ég er að tala um snýst ekki bara um DELETE. Eins og þú giskaðir á eru þetta allar magnaðgerðir á gögnum.
Og við sjáum að áætlunin er frábær. Þú getur séð vísitöluskönnunina, aðeins vísitöluskönnun er enn betri. Og við höfum lítið magn af gögnum sem taka þátt. Og innan við sekúnda uppfyllir. Frábær.
Og við þurfum enn að ganga úr skugga um að það sé engin niðurbrot. Það kemur fyrir að fyrstu pakkarnir lagast fljótt og svo versnar það, verra og verra. Ferlið er þannig að þú þarft að prófa mikið. Þetta er nákvæmlega það sem gagnagrunnsrannsóknir eru fyrir.
Og við verðum enn að undirbúa eitthvað svo það geri okkur kleift að fylgja þessu rétt eftir í framleiðslu. Til dæmis getum við skrifað tímann í logann, við getum skrifað hvar við erum núna og hverjum við höfum nú eytt. Og þetta mun leyfa okkur að skilja hvað er að gerast síðar. Og ef eitthvað fer úrskeiðis, finndu vandamálið fljótt.
Ef við þurfum að athuga skilvirkni beiðna og við þurfum að endurtaka það oft, þá er til eitthvað sem heitir náungi láni. Hann er þegar tilbúinn. Það er notað af tugum forritara daglega. Og hann veit hvernig á að gefa risastóran terabæta gagnagrunn á beiðni á 30 sekúndum, þitt eigið eintak. Og þú getur eytt einhverju þar og sagt RESET, og eytt því aftur. Þú getur gert tilraunir með það á þennan hátt. Ég sé framtíð fyrir þessu. Og við erum nú þegar að gera það.
Hvað eru skiptingaraðferðir? Ég sé 3 mismunandi skiptingaraðferðir sem forritararnir á pakkanum nota.
Sú fyrri er mjög einföld. Við erum með tölulegt auðkenni. Og við skulum skipta því niður í mismunandi millibili og vinna með það. Gallinn er augljós. Í fyrsta hlutanum gætum við verið með 100 línur af raunverulegu sorpi, í þeim seinni 5 línur eða alls ekki, eða allar 1 línurnar munu reynast vera sorp. Mjög ójöfn vinna, en það er auðvelt að brjóta það. Þeir tóku hámarksskilríki og mölvuðu það. Þetta er barnaleg nálgun.
Önnur stefnan er yfirveguð nálgun. Það er notað í Gitlab. Þeir tóku og skönnuðu borðið. Við fundum mörk auðkennispökkanna þannig að hver pakki hafði nákvæmlega 10 færslur. Og setja þá í biðröð. Og svo vinnum við. Þú getur gert þetta í mörgum þráðum.
Í fyrstu stefnu líka, við the vegur, þú getur gert þetta í nokkrum þræði. Það er ekki erfitt.
En það er svalari og betri nálgun. Þetta er þriðja stefnan. Og þegar mögulegt er, er betra að velja það. Þetta gerum við á grundvelli sérstakrar vísitölu. Í þessu tilviki mun það líklegast vera vísitala í samræmi við sorpástand okkar og auðkenni. Við munum láta auðkennið fylgja með þannig að það sé aðeins vísitöluskönnun svo að við förum ekki í hauginn.
Almennt er aðeins vísitöluskönnun hraðari en vísitöluskönnun.
Og við finnum fljótt auðkenni okkar sem við viljum eyða. BATCH_SIZE við veljum fyrirfram. Og við fáum þá ekki bara, við fáum þá á sérstakan hátt og hakkum þá strax. En við erum að læsa þannig að ef þeir eru þegar læstir þá læsum við þeim ekki heldur höldum áfram og tökum næstu. Þetta er til að sleppa uppfærslu læst. Þessi frábær eiginleiki Postgres gerir okkur kleift að vinna í nokkrum þráðum ef við viljum. Það er hægt í einum straumi. Og hér er CTE - þetta er ein beiðni. Og við erum með alvöru eyðingu í gangi á annarri hæð þessa CTE - returning *. Þú getur skilað auðkenni, en það er betra *ef þú hefur ekki mikið af gögnum á hverri línu.
Af hverju þurfum við það? Þetta er það sem við þurfum að tilkynna til baka. Við höfum nú eytt svo mörgum línum í raun. Og við höfum landamæri eftir auðkenni eða eftir create_at eins og þetta. Þú getur gert mín., max. Það er hægt að gera eitthvað annað. Hér er hægt að troða miklu. Og það er mjög þægilegt fyrir eftirlit.
Það er enn ein athugasemdin um vísitöluna. Ef við ákveðum að við þurfum sérstaka vísitölu fyrir þetta verkefni, þá þurfum við að ganga úr skugga um að það spilli ekki hrúga aðeins uppfærslum á túllum. Það er að segja, Postgres er með slíka tölfræði. Þetta má sjá í pg_stat_user_tables fyrir töfluna þína. Þú getur séð hvort heitar uppfærslur eru notaðar eða ekki.
Það eru aðstæður þar sem nýja vísitalan þín getur einfaldlega skorið þær af. Og þú hefur allar aðrar uppfærslur sem eru þegar að virka, hægðu á þér. Ekki bara vegna þess að vísitalan birtist (hver vísitala hægir aðeins á uppfærslum, heldur aðeins), en hér eyðileggur hún hana samt. Og það er ómögulegt að gera sérstaka hagræðingu fyrir þetta borð. Þetta gerist stundum. Þetta er svo fíngerð að fáir muna. Og það er auðvelt að stíga þessa hrífu. Stundum gerist það að þú þarft að finna nálgun frá hinni hliðinni og samt vera án þessarar nýju vísitölu, eða gera aðra vísitölu, eða á einhvern annan hátt, til dæmis, þú getur notað seinni aðferðina.
En þetta er besta aðferðin, hvernig á að skipta í lotur og skjóta á lotur með einni beiðni, eyða smá o.s.frv.
Löng viðskipti
Lokað sjálfvirkt tómarúm -
lokavandamál -
Mistök #5 eru mikil. Nikolai frá Okmeter talaði um Postgres eftirlit. Tilvalið Postgres eftirlit er því miður ekki til. Sumt er nær, annað lengra. Okmeter er nógu nálægt því að vera fullkomið, en margt vantar og þarf að bæta við. Þú þarft að vera tilbúinn í þetta.
Til dæmis er best að fylgjast með dauðum túpum. Ef þú ert með marga dauða hluti á borðinu, þá er eitthvað að. Það er betra að bregðast við núna, annars getur verið niðurbrot og við getum legið. Það gerist.
Ef það er stór IO, þá er ljóst að þetta er ekki gott.
Löng viðskipti líka. Langar viðskipti ættu ekki að vera leyfðar á OLTP. Og hér er hlekkur á bút sem gerir þér kleift að taka þennan bút og gera nú þegar einhverja mælingu á löngum viðskiptum.
Af hverju eru löng viðskipti slæm? Vegna þess að allir læsingar losna aðeins í lokin. Og við klúðrum öllum. Auk þess lokum við sjálfvirkt tómarúm fyrir öll borð. Það er alls ekki gott. Jafnvel þó að þú hafir virkjað heitt biðstöðu á eftirmyndinni, þá er það samt slæmt. Almennt séð er hvergi betra að forðast löng viðskipti.
Ef við erum með mörg borð sem eru ekki ryksuguð, þá þurfum við að hafa viðvörun. Hér er slíkt ástand mögulegt. Við getum óbeint haft áhrif á virkni sjálfvirkrar tómarúms. Þetta er brot úr Avito, sem ég bætti aðeins. Og það reyndist vera áhugavert tæki til að sjá hvað við höfum með sjálfvirkt tómarúm. Til dæmis bíða nokkur borð þar og munu ekki bíða eftir að röðin komi að þeim. Þú þarft líka að setja það í eftirlit og hafa viðvörun.
Og gefur út blokkir. Skógur af blokkatrjám. Mér finnst gaman að taka eitthvað frá einhverjum og bæta það. Hér tók ég flotta endurkvæma CTE frá Data Egret sem sýnir skóg af lástrjám. Þetta er gott greiningartæki. Og á grundvelli þess geturðu líka byggt upp eftirlit. En þetta verður að fara varlega. Þú þarft að gera smá statement_timeout fyrir sjálfan þig. Og lock_timeout er æskilegt.
Stundum eiga sér stað allar þessar villur samanlagt.
Aðalmistökin hér eru að mínu mati skipulagsmál. Það er skipulagt, vegna þess að tæknin togar ekki. Þetta er númer 2 - þeir tékkuðu á röngum stað.
Við tékkuðum á röngum stað, því við vorum ekki með framleiðsluklón, sem auðvelt er að athuga. Framkvæmdaraðili gæti alls ekki haft aðgang að framleiðslu.
Og við athuguðum ekki þar. Ef við hefðum athugað þarna hefðum við séð það sjálf. Framkvæmdaraðilinn sá allt þetta jafnvel án DBA ef hann athugaði það í góðu umhverfi, þar sem er sama magn af gögnum og eins staðsetning. Hann hefði séð alla þessa niðurlægingu og hann myndi skammast sín.
Meira um autovacuum. Eftir að við höfum gert gríðarlega sópa upp á nokkrar milljónir lína, þurfum við enn að gera REPACK. Þetta er sérstaklega mikilvægt fyrir vísitölur. Þeim mun líða illa eftir að við höfum hreinsað allt þar.
Og ef þú vilt endurheimta daglega hreinsunarvinnu, þá myndi ég mæla með því að gera það oftar, en minna. Það getur verið einu sinni á mínútu eða jafnvel oftar svolítið. Og þú þarft að fylgjast með tvennu: að þessi hlutur hafi engar villur og að hann standi ekki eftir. Bragðið sem ég sýndi mun bara leysa þetta.
Það sem við gerum er opinn uppspretta. Það er birt á GitLab. Og við gerum það þannig að fólk getur athugað jafnvel án DBA. Við erum að gera gagnagrunnsrannsóknarstofu, það er að segja við köllum grunnþáttinn sem Joe er að vinna á. Og þú getur náð í eintak af framleiðslunni. Nú er komin útfærsla á Joe fyrir slack, þú getur sagt þar: "útskýrðu svona og svo beiðni" og fáðu strax niðurstöðuna fyrir afritið þitt af gagnagrunninum. Þú getur jafnvel DELETE þar og enginn mun taka eftir því.
Segjum að þú sért með 10 terabæt, við gerum gagnagrunnsrannsóknarstofu líka 10 terabæt. Og með 10 terabæta gagnagrunnum samtímis geta 10 verktaki unnið samtímis. Allir geta gert það sem þeir vilja. Getur eytt, sleppt o.s.frv. Það er svo mikil fantasía. Við ræðum þetta á morgun.
Þetta er kallað þunn úthlutun. Þetta er lúmsk úthlutun. Þetta er einhvers konar fantasía sem fjarlægir mjög tafir á þróun, í prófunum og gerir heiminn að betri stað í þessum efnum. Það er, það gerir þér bara kleift að forðast vandamál með magnaðgerðir.
Dæmi: 5 terabæta gagnagrunnur, fá afrit á innan við 30 sekúndum. Og það fer ekki einu sinni eftir stærðinni, það er, það skiptir ekki máli hversu mörg terabæti.
Í dag er hægt að fara í og grafa í verkfærum okkar. Þú getur skráð þig til að sjá hvað er þar. Þú getur sett upp þennan bot. Það er ókeypis. Skrifaðu.
spurningar
Mjög oft við raunverulegar aðstæður kemur í ljós að gögnin sem ættu að vera eftir í töflunni eru miklu minni en það sem þarf að eyða. Það er, í slíkum aðstæðum er oft auðveldara að innleiða slíka nálgun, þegar það er auðveldara að búa til nýjan hlut, afrita aðeins nauðsynleg gögn þangað og trunkað gömlu töfluna. Það er ljóst að þörf er á forritunaraðferð fyrir þetta augnablik, á meðan þú munt skipta. Hvernig er þessi nálgun?
Þetta er mjög góð nálgun og mjög gott verkefni. Það er mjög svipað því sem pg_repack gerir, það er mjög svipað því sem þú þarft að gera þegar þú gerir auðkenni 4 bæti. Margir rammar gerðu þetta fyrir nokkrum árum og bara plöturnar hafa stækkað og þarf að breyta þeim í 8 bæti.
Þetta verkefni er frekar erfitt. Okkur tókst það. Og þú verður að vera mjög varkár. Það eru læsingar o.s.frv. En það er verið að gera það. Það er, staðlað nálgun er að fara með pg_repack. Þú lýsir yfir slíku merki. Og áður en þú byrjar að hlaða inn skyndimyndagögnum inn í það, lýsir þú líka yfir einni plötu sem fylgist með öllum breytingum. Það er bragð að þú gætir ekki einu sinni fylgst með einhverjum breytingum. Það eru fíngerðir. Og svo skiptir þú með því að rúlla breytingum. Það verður stutt pása þegar við leggjum alla niður en almennt er verið að gera þetta.
Ef þú horfir á pg_repack á GitHub, þá þar, þegar það var verkefni að breyta auðkenni úr int 4 í int 8, þá var hugmynd að nota pg_repack sjálft. Þetta er líka mögulegt, en það er smá hakk, en það mun virka fyrir þetta líka. Þú getur gripið inn í triggerinn sem pg_repack notar og sagt þar: "Við þurfum ekki þessi gögn", þ.e.a.s. við flytjum bara það sem við þurfum. Og svo skiptir hann bara og þá er komið að því.
Með þessari nálgun fáum við samt annað eintak af töflunni, þar sem gögnin eru þegar skráð og staflað mjög jafnt með fallegum vísitölum.
Uppblásinn er ekki til staðar, það er góð nálgun. En ég veit að það er reynt að þróa sjálfvirkni fyrir þetta, þ.e.a.s. að gera allsherjarlausn. Ég get komið þér í samband við þessa sjálfvirkni. Það er skrifað í Python, sem er gott.
Ég er bara svolítið frá MySQL heimi, svo ég kom til að hlusta. Og við notum þessa aðferð.
En það er bara ef við höfum 90%. Ef við erum með 5%, þá er ekki mjög gott að nota það.
Takk fyrir skýrsluna! Ef það eru engin úrræði til að gera fullkomið afrit af framleiðslu, er þá einhver reiknirit eða formúla til að reikna út álag eða stærð?
Góð spurning. Hingað til höfum við fundið margra terabæta gagnagrunna. Jafnvel þótt vélbúnaðurinn þar sé ekki sá sami, til dæmis, minna minni, minni örgjörvi og diskar eru ekki alveg eins, en samt gerum við það. Ef það er nákvæmlega hvergi, þá þarftu að hugsa. Leyfðu mér að hugsa þangað til á morgun, þú komst, við tölum saman, þetta er góð spurning.
Takk fyrir skýrsluna! Þú byrjaðir fyrst á því að það er til flott Postgres, sem hefur svona og svo takmarkanir, en hann er að þróast. Og þetta er allt saman hækja í stórum dráttum. Er þetta ekki allt í andstöðu við þróun Postgres sjálfs, þar sem einhver DELETE deferent mun birtast eða eitthvað annað sem ætti að halda á lágu stigi það sem við erum að reyna að smyrja með einhverjum af okkar undarlegu aðferðum hér?
Ef við sögðum í SQL að eyða eða uppfæra margar færslur í einni færslu, hvernig getur Postgres þá dreift því þangað? Við erum líkamlega takmörkuð í rekstri. Við munum samt gera það í langan tíma. Og við munum læsa á þessum tíma o.s.frv.
Búin með vísitölur.
Ég get gert ráð fyrir að sömu eftirlitsstillingar gætu verið sjálfvirkar. Einhvern tímann gæti það verið. En svo skil ég ekki spurninguna.
Spurningin er, er slíkur þróunarvísir sem fer hingað og þangað, og hér fer þinn samhliða? Þeir. Hafa þeir ekki hugsað út í það ennþá?
Ég talaði um meginreglurnar sem hægt er að nota núna. Það er annar botni , með þessu geturðu gert sjálfvirka eftirlitsstillingu. Verður það einhvern tíma í Postgres? Ég veit það ekki, það hefur ekki einu sinni verið rætt ennþá. Við erum enn langt frá því. En það eru til vísindamenn sem búa til ný kerfi. Og þeir troða okkur inn í sjálfvirkar vísitölur. Það eru þróun. Til dæmis er hægt að skoða sjálfvirka stillingu. Það velur færibreytur sjálfkrafa. En hann mun ekki gera eftirlitsstillingar fyrir þig ennþá. Það er, það mun taka upp fyrir frammistöðu, skeljabuff osfrv.
Og til að stilla eftirlitspunkta geturðu gert þetta: ef þú ert með þúsund klasa og mismunandi vélbúnað, mismunandi sýndarvélar í skýinu, geturðu notað botninn okkar gera sjálfvirkni. Og max_wal_size verður sjálfkrafa valið í samræmi við markmiðsstillingar þínar. En enn sem komið er er þetta ekki einu sinni nálægt í kjarnanum, því miður.
Góðan daginn Þú talaðir um hættuna af löngum viðskiptum. Þú sagðir að sjálfvirkt tómarúm sé læst ef eytt er. Hvernig skaðar það okkur annars? Þar sem við erum meira að tala um að losa um pláss og geta notað það. Hvað vantar okkur annars?
Autovacuum er kannski ekki stærsta vandamálið hér. Og sú staðreynd að löng viðskipti geta læst öðrum viðskiptum, þessi möguleiki er hættulegri. Hún gæti hitt eða ekki. Ef hún hitti, þá getur það verið mjög slæmt. Og með autovacuum - þetta er líka vandamál. Það eru tvö vandamál með löng viðskipti í OLTP: læsingar og sjálfvirkt tómarúm. Og ef þú ert með heita biðstöðu virkt á eftirmyndinni, þá færðu samt sjálfvirkt tómarúmslás á skipstjóranum, hann kemur frá eftirmyndinni. En það verða allavega engir læsingar. Og það verða loks. Við erum að tala um gagnabreytingar, svo læsingar eru mikilvægur punktur hér. Og ef þetta er allt í langan, langan tíma, þá eru fleiri og fleiri viðskipti læst. Þeir geta stolið öðrum. Og lok tré birtast. Ég setti inn tengil á brotið. Og þetta vandamál verður meira áberandi hraðar en vandamálið með autovacuum, sem getur aðeins safnast upp.
Takk fyrir skýrsluna! Þú byrjaðir skýrsluna þína á því að segja að þú hafir prófað rangt. Við héldum áfram þeirri hugmynd okkar að við þyrftum að taka sama búnaðinn, með grunninn á sama hátt. Segjum að við gáfum framkvæmdaraðilanum grunn. Og hann varð við beiðninni. Og hann virðist hafa það gott. En hann athugar ekki fyrir lifandi, heldur fyrir lifandi, til dæmis erum við með 60-70% álag. Og jafnvel þótt við notum þessa stillingu, þá virkar hún ekki mjög vel.
Það er mikilvægt að hafa sérfræðing í liðinu og nota DBA sérfræðinga sem geta spáð fyrir um hvað gerist með raunverulegu bakgrunnsálagi. Þegar við keyrðum bara hreinu breytingarnar okkar sjáum við myndina. En fullkomnari nálgun, þegar við gerðum það sama aftur, en með álagi sem hermt er eftir framleiðslu. Það er frekar flott. Þangað til verður þú að þroskast. Þetta er eins og fullorðinn maður. Við skoðuðum bara það sem við höfum og skoðuðum líka hvort við höfum nægt fjármagn. Það er góð spurning.
Þegar við erum nú þegar að gera sorpval og við höfum til dæmis eytt fána
Þetta er það sem autovacuum gerir sjálfkrafa í Postgres.
Ó, gerir hann það?
Autovacuum er sorphirðarinn.
Þakka þér!
Takk fyrir skýrsluna! Er möguleiki á að hanna strax gagnagrunn með skiptingu þannig að allt sorp óhreinkast af aðalborðinu einhvers staðar til hliðar?
Hef auðvitað.
Er þá hægt að verja okkur ef við höfum læst borði sem ætti ekki að nota?
Hef auðvitað. En þetta er eins og hænu og egg spurning. Ef við vitum öll hvað mun gerast í framtíðinni, þá gerum við auðvitað allt flott. En reksturinn er að breytast, það eru nýir dálkar, nýjar beiðnir. Og svo - úps, við viljum fjarlægja það. En þetta hugsjón ástand, í lífinu það á sér stað, en ekki alltaf. En á heildina litið er það góð hugmynd. Bara stytta og það er allt.
Heimild: www.habr.com