Iam en la malproksima estonteco, la aŭtomata forigo de nenecesaj datumoj estos unu el la gravaj taskoj de la DBMS [1]. Intertempe, ni mem devas prizorgi forigi aŭ movi nenecesajn datumojn al malpli multekostaj stokadsistemoj. Ni diru, ke vi decidas forigi kelkajn milionojn da vicoj. Sufiĉe simpla tasko, precipe se la kondiĉo estas konata kaj ekzistas taŭga indekso. "DELETE FROM table1 WHERE col1 = :valoro" - kio povus esti pli simpla, ĉu ne?
Video:
-
Mi estas en la komitato de la programo Highload ekde la unua jaro, t.e. ekde 2007.
-
Kaj mi estas kun Postgres ekde 2005. Uzis ĝin en multaj projektoj.
-
Grupo kun RuPostges ankaŭ ekde 2007.
-
Ni kreskis al 2100+ partoprenantoj ĉe Meetup. Ĝi estas la dua en la mondo post Novjorko, antaŭita de San Francisco dum longa tempo.
-
Mi loĝas en Kalifornio dum pluraj jaroj. Mi traktas pli kun usonaj kompanioj, inkluzive de grandaj. Ili estas aktivaj uzantoj de Postgres. Kaj estas ĉiaj interesaj aferoj.
estas mia kompanio. Ni estas en la komerco de aŭtomatigi taskojn, kiuj forigas evoluajn malrapidojn.
Se vi faras ion, tiam foje ekzistas iaj ŝtopiloj ĉirkaŭ Postgres. Ni diru, ke vi devas atendi ke la administranto starigu teststandon por vi, aŭ vi devas atendi ke la DBA respondas al vi. Kaj ni trovas tiajn botelojn en la procezo de disvolviĝo, testado kaj administrado kaj provas forigi ilin helpe de aŭtomatigo kaj novaj aliroj.
Mi estis lastatempe ĉe VLDB en Los-Anĝeleso. Ĉi tiu estas la plej granda konferenco pri datumbazoj. Kaj estis raporto, ke estonte DBMS ne nur stokos, sed ankaŭ aŭtomate forigos datumojn. Ĉi tio estas nova temo.
Estas pli kaj pli da datumoj en la mondo de zettabajtoj - tio estas 1 petabajtoj. Kaj nun oni jam taksas, ke ni havas pli ol 000 zettabajtojn da datumoj stokitaj en la mondo. Kaj estas pli kaj pli da ili.
Kaj kion fari kun ĝi? Evidente ĝi devas esti forigita. Jen ligo al ĉi tiu interesa raporto. Sed ĝis nun ĉi tio ne estis efektivigita en la DBMS.
Tiuj, kiuj povas kalkuli monon, volas du aferojn. Ili volas, ke ni forigu, do teknike ni devus povi fari ĝin.
Kion mi rakontos poste estas ia abstrakta situacio, kiu inkluzivas amason da realaj situacioj, t.e. ian kompilon de tio, kio efektive okazis al mi kaj la ĉirkaŭaj datumbazoj multfoje, multajn jarojn. Rastiloj estas ĉie kaj ĉiuj paŝas sur ilin la tutan tempon.
Ni diru, ke ni havas bazon aŭ plurajn bazojn kiuj kreskas. Kaj iuj diskoj estas evidente rubo. Ekzemple, la uzanto komencis fari ion tie, sed ne finis ĝin. Kaj post iom da tempo ni scias, ke ĉi tiu nefinita ne plu povas esti konservita. Tio estas, ni ŝatus purigi kelkajn rubaĵojn por ŝpari spacon, plibonigi rendimenton ktp.
Ĝenerale, la tasko estas aŭtomatigi la forigon de specifaj aferoj, specifaj linioj en iu tabelo.
Kaj ni havas tian peton, pri kiu ni parolos hodiaŭ, tio estas pri forigo de rubo.
Ni petis spertan programiston fari ĝin. Li akceptis ĉi tiun peton, kontrolis ĝin mem - ĉio funkcias. Provita sur surscenigo - ĉio estas en ordo. Disvolvita - ĉio funkcias. Unufoje tage ni kuras ĝin - ĉio estas en ordo.
La datumbazo kreskas kaj kreskas. Ĉiutage DELETE komencas funkcii iom pli malrapide.
Tiam ni komprenas, ke ni nun havas merkatan kompanion kaj la trafiko estos plurfoje pli granda, do ni decidas provizore paŭzi nenecesajn aferojn. Kaj forgesu reveni.
Kelkajn monatojn poste ili rememoris. Kaj tiu programisto forlasas aŭ estas okupata de io alia, instrukciis alian redoni ĝin.
Li kontrolis pri dev, pri surscenigo - ĉio estas en ordo. Kompreneble, vi ankoraŭ bezonas purigi tion, kio akumuliĝis. Li kontrolis, ke ĉio funkcias.
Kio okazas poste? Tiam ĉio disfalas por ni. Ĝi falas tiel, ke iam ĉio falas. Ĉiuj estas en ŝoko, neniu komprenas kio okazas. Kaj tiam rezultas, ke la afero estis en ĉi tiu DELETE.
Io misfunkciis? Jen listo de kio povus esti misfunkciinta. Kiu el ĉi tiuj estas la plej grava?
-
Ekzemple, ne estis revizio, t.e. la DBA-eksperto ne rigardis ĝin. Li tuj trovus la problemon per sperta okulo, kaj krome li havas aliron al prod, kie amasiĝis pluraj milionoj da linioj.
-
Eble ili kontrolis ion malĝustan.
-
Eble la aparataro estas malmoderna kaj vi devas ĝisdatigi ĉi tiun bazon.
-
Aŭ io misas kun la datumbazo mem, kaj ni devas moviĝi de Postgres al MySQL.
-
Aŭ eble estas io malĝusta kun la operacio.
-
Eble estas iuj eraroj en la organizo de laboro kaj vi bezonas maldungi iun kaj dungi la plej bonajn homojn?
Ne estis DBA-kontrolo. Se ekzistus DBA, li vidus ĉi tiujn plurajn milionojn da linioj kaj eĉ sen iuj eksperimentoj dirus: "Ili ne faras tion." Supozu, se ĉi tiu kodo estus en GitLab, GitHub kaj ekzistus koda revizia procezo kaj ne ekzistus tia afero, ke sen la aprobo de la DBA ĉi tiu operacio okazus sur prod, tiam evidente la DBA dirus: "Ĉi tio ne povas esti farita. .”
Kaj li dirus, ke vi havos problemojn kun disko IO kaj ĉiuj procezoj freneziĝos, eble estos seruroj, kaj ankaŭ vi blokos aŭtomatan vakuon dum kelkaj minutoj, do ĉi tio ne estas bona.
La dua eraro - ili kontrolis en malĝusta loko. Ni vidis post tio, ke multaj rubaĵoj amasiĝis sur prod, sed la programisto ne amasigis datumojn en ĉi tiu datumbazo, kaj neniu kreis ĉi tiun rubaĵon dum surscenigo. Sekve, estis 1 linioj kiuj rapide funkciis.
Ni komprenas, ke niaj testoj estas malfortaj, t.e. la procezo kiu estas konstruita ne kaptas problemojn. Adekvata DB-eksperimento ne estis farita.
Ideala eksperimento estas prefere farita sur la sama ekipaĵo. Ne ĉiam eblas fari tion sur la sama ekipaĵo, sed estas tre grave ke ĝi estu plengranda kopio de la datumbazo. Jen kion mi predikas jam de kelkaj jaroj. Kaj antaŭ unu jaro mi parolis pri tio, vi povas spekti ĉion ĉe Jutubo.
Eble nia ekipaĵo estas malbona? Se vi rigardas, tiam la latenteco saltis. Ni vidis, ke utiligo estas 100%. Kompreneble, se ĉi tiuj estus modernaj NVMe-diskoj, tiam verŝajne estus multe pli facile por ni. Kaj eble ni ne kuŝus de ĝi.
Se vi havas nubojn, tiam la ĝisdatigo estas facile farita tie. Kreskigis novajn kopiojn sur la nova aparataro. ŝaltilo. Kaj ĉio estas bona. Sufiĉe facila.
Ĉu eblas iel tuŝi la pli malgrandajn diskojn? Kaj ĉi tie, nur kun la helpo de DBA, ni plonĝas en certan temon nomitan kontrolpunkto-agordado. Montriĝas, ke ni ne havis kontrolpunkto-agordon.
Kio estas kontrolpunkto? Ĝi estas en iu ajn DBMS. Kiam vi havas datumojn en memoro, kiuj ŝanĝiĝas, ĝi ne estas tuj skribita al disko. La informoj, ke la datenoj ŝanĝiĝis, unue estas skribitaj al la antaŭskriba protokolo. Kaj iam, la DBMS decidas, ke estas tempo forĵeti realajn paĝojn al disko, por ke se ni havas malsukceson, ni povas fari malpli REDO. Ĝi estas kiel ludilo. Se ni estas mortigitaj, ni komencos la ludon de la lasta transirejo. Kaj ĉiuj DBMS efektivigas ĝin.
La agordoj en Postgres postrestas. Ili estas desegnitaj por 10-15-jaraj volumoj de datumoj kaj transakcioj. Kaj transirejo ne estas escepto.
Jen la informoj de nia raporto pri kontrolo de Postgres, t.e. aŭtomata sankontrolo. Kaj jen iu datumbazo de pluraj terabajtoj. Kaj oni povas bone vidi, ke devigis kontrolpunktojn en preskaŭ 90% de kazoj.
Kion ĝi signifas? Estas du agordoj tie. Kontrolpunkto povas veni per tempoforigo, ekzemple, en 10 minutoj. Aŭ ĝi povas veni kiam sufiĉe multe da datumoj estas plenigitaj.
Kaj defaŭlte max_wal_saze estas agordita al 1 gigabajto. Fakte, ĉi tio vere okazas en Postgres post 300-400 megabajtoj. Vi ŝanĝis tiom da datumoj kaj via kontrolpunkto okazas.
Kaj se neniu agordis ĝin, kaj la servo kreskis, kaj la kompanio gajnas multe da mono, ĝi havas multajn transakciojn, tiam la kontrolpunkto venas unufoje ĉiuminute, foje ĉiujn 30 sekundojn, kaj foje eĉ interkovras. Ĉi tio estas sufiĉe malbona.
Kaj ni devas certigi, ke ĝi venas malpli ofte. Tio estas, ni povas altigi max_wal_size. Kaj ĝi venos malpli ofte.
Sed ni evoluigis tutan metodaron por kiel fari ĝin pli ĝuste, tio estas, kiel fari decidon pri elekto de agordoj, klare bazita sur specifaj datumoj.
Sekve, ni faras du seriojn da eksperimentoj pri datumbazoj.
La unua serio - ni ŝanĝas max_wal_size. Kaj ni faras amasan operacion. Unue, ni faras ĝin laŭ la defaŭlta agordo de 1 gigabajto. Kaj ni faras amasan FORIĜI de multaj milionoj da linioj.
Vi povas vidi kiel malfacile estas por ni. Ni vidas, ke disko IO estas tre malbona. Ni rigardas kiom da WAL-oj ni generis, ĉar tio estas tre grava. Ni vidu kiom da fojoj la transirejo okazis. Kaj ni vidas, ke ĝi ne estas bona.
Poste ni pliigas max_wal_size. Ni ripetas. Ni pliigas, ni ripetas. Kaj tiom da fojoj. Principe, 10 poentoj estas bona, kie 1, 2, 4, 8 gigabajtoj. Kaj ni rigardas la konduton de aparta sistemo. Estas klare, ke ĉi tie la ekipaĵo devus esti kiel sur prod. Vi devas havi la samajn diskojn, la saman kvanton da memoro kaj la samajn agordojn de Postgres.
Kaj tiamaniere ni interŝanĝos nian sistemon, kaj ni scias kiel la DBMS kondutos en kazo de malbona maso DELETE, kiel ĝi estos kontrolpunkto.
Transirejo en la rusa estas transirejoj.
Ekzemplo: FORIGI plurajn milionojn da vicoj laŭ indekso, vicoj estas "disigitaj" tra paĝoj.
Jen ekzemplo. Ĉi tio estas iu bazo. Kaj kun la defaŭlta agordo de 1 gigabajto por max_wal_size, estas tre klare, ke niaj diskoj iras al la breto por registri. Ĉi tiu bildo estas tipa simptomo de tre malsana paciento, tio estas, li vere sentis malbone. Kaj estis unu sola operacio, estis nur DELETE de pluraj milionoj da linioj.
Se tia operacio estas permesita en prod, tiam ni nur kuŝiĝos, ĉar estas klare, ke unu DELETE mortigas nin en la regimento.
Plue, kie 16 gigabajtoj, estas klare, ke la dentoj jam iris. Dentoj jam estas pli bonaj, tio estas, ni frapas la plafonon, sed ne tiel malbone. Estis iom da libereco tie. Dekstre estas la rekordo. Kaj la nombro da operacioj - la dua grafeo. Kaj estas certe ke ni jam spiras iom pli facile kiam 16 gigabajtoj.
Kaj kie 64 gigabajtoj videblas, ke ĝi fariĝis tute pli bona. Jam la dentoj estas prononcitaj, estas pli da ŝancoj por postvivi aliajn operaciojn kaj fari ion per la disko.
Kial?
Mi iomete plonĝos en la detalojn, sed ĉi tiu temo, kiel fari kontrolpunkto-agordon, povas rezultigi tutan raporton, do mi ne multe ŝarĝos, sed mi iomete skizos, kiaj malfacilaĵoj estas.
Se la kontrolpunkto okazas tro ofte, kaj ni ĝisdatigas niajn liniojn ne sinsekve, sed trovas per indekso, kio estas bona, ĉar ni ne forigas la tutan tabelon, tiam povas okazi, ke komence ni tuŝis la unuan paĝon, poste la milan, kaj poste revenis al la unua. Kaj se inter ĉi tiuj vizitoj al la unua paĝo, kontrolpunkto jam konservis ĝin al disko, tiam ĝi konservos ĝin denove, ĉar ni malpurigis ĝin duan fojon.
Kaj ni devigos kontrolpunkton konservi ĝin multfoje. Kiel estus superfluaj operacioj por li.
Sed tio ne estas ĉio. Paĝoj estas 8 kilobajtoj en Postgres kaj 4 kilobajtoj en Linukso. Kaj ekzistas full_page_writes agordo. Ĝi estas ebligita defaŭlte. Kaj ĉi tio estas ĝusta, ĉar se ni malŝaltas ĝin, tiam estas danĝero, ke nur duono de la paĝo estos konservita se ĝi kraŝos.
La konduto de skribi al la WAL de la antaŭa protokolo estas tia, ke kiam ni havas kontrolpunkton kaj ni ŝanĝas la paĝon unuafoje, la tuta paĝo, t.e., ĉiuj 8 kilobajtoj, eniras en la antaŭan protokolon, kvankam ni nur ŝanĝis la paĝon. linio, kiu pezas 100 bajtojn. Kaj ni devas noti la tutan paĝon.
En postaj ŝanĝoj estos nur specifa opo, sed unuafoje ni skribas ĉion.
Kaj, sekve, se la kontrolpunkto denove okazis, tiam ni devas komenci ĉion de nulo denove kaj puŝi la tutan paĝon. Kun oftaj kontrolpunktoj, kiam ni trairas la samajn paĝojn, full_page_writes = on estos pli ol ĝi povus esti, t.e. ni generas pli da WAL. Pli estas senditaj al kopioj, al la arkivo, al disko.
Kaj, sekve, ni havas du redundojn.
Se ni pliigas max_wal_size, rezultas, ke ni faciligas kaj por kontrolpunkto kaj wal writer. Kaj tio estas bonega.
Ni enmetu terabajton kaj vivu kun ĝi. Kio estas malbona pri ĝi? Ĉi tio estas malbona, ĉar okaze de malsukceso, ni grimpos dum horoj, ĉar la kontrolejo estis antaŭ longe kaj multo jam ŝanĝiĝis. Kaj ni devas fari ĉion ĉi REDO. Kaj tiel ni faras la duan serion de eksperimentoj.
Ni faras operacion kaj vidas kiam la kontrolpunkto estas kompletigota, ni mortigas -9 Postgres intence.
Kaj post tio ni rekomencos ĝin, kaj vidu kiom longe ĝi leviĝos sur ĉi tiu ekipaĵo, t.e. kiom ĝi REDOS en ĉi tiu malbona situacio.
Dufoje mi rimarkos, ke la situacio estas malbona. Unue, ni kraŝis ĝuste antaŭ ol la transirejo finiĝis, do ni havas multon por perdi. Kaj due, ni havis amasan operacion. Kaj se transirejoj estus je tempodaŭro, tiam, plej verŝajne, malpli WAL estus generita ekde la lasta transirejo. Tio estas, ĝi estas duobla malgajninto.
Ni mezuras tian situacion por malsamaj grandecoj de max_wal_size kaj komprenas, ke se max_wal_size estas 64 gigabajtoj, tiam en duobla plej malbona kazo ni grimpos dum 10 minutoj. Kaj ni pensas ĉu ĝi konvenas al ni aŭ ne. Ĉi tio estas komerca demando. Ni devas montri ĉi tiun bildon al la respondecaj pri komercaj decidoj kaj demandi: "Kiom longe ni povas kuŝi maksimume en kazo de problemo? Ĉu ni povas kuŝi en la plej malbona situacio dum 3-5 minutoj? Kaj vi prenas decidon.
Kaj jen interesa punkto. Ni havas kelkajn raportojn pri Patroni ĉe la konferenco. Kaj eble vi uzas ĝin. Ĉi tio estas aŭtomata malfunkciigo por Postgres. GitLab kaj Data Egret parolis pri tio.
Kaj se vi havas aŭtomatan malsukceson, kiu venas en 30 sekundoj, tiam eble ni povas kuŝi dum 10 minutoj? Ĉar ni ŝanĝos al la kopio ĝis ĉi tiu punkto, kaj ĉio estos en ordo. Ĉi tio estas dubinda punkto. Mi ne konas klaran respondon. Mi nur sentas, ke ĉi tiu temo ne temas nur pri kraŝa reakiro.
Se ni havas longan resaniĝon post fiasko, tiam ni estos malkomfortaj en multaj aliaj situacioj. Ekzemple, en la samaj eksperimentoj, kiam ni faras ion kaj foje devas atendi 10 minutojn.
Mi ankoraŭ ne irus tro malproksimen, eĉ se ni havus aŭtomatan malfunkciigon. Kiel regulo, valoroj kiel 64, 100 gigabajtoj estas bonaj valoroj. Kelkfoje eĉ indas elekti malpli. Ĝenerale, ĉi tio estas subtila scienco.
Por fari ripetojn, ekzemple, max_wal_size =1, 8, vi devas ripeti la amasoperacion multajn fojojn. Vi faris ĝin. Kaj sur la sama bazo vi volas fari ĝin denove, sed vi jam forigis ĉion. Kion fari?
Mi parolos poste pri nia solvo, kion ni faras por ripeti en tiaj situacioj. Kaj ĉi tiu estas la plej ĝusta aliro.
Sed en ĉi tiu kazo, ni estis bonŝancaj. Se, kiel ĝi diras ĉi tie "KOMENCU, FORIGI, ROLLBACK", tiam ni povas ripeti DELETE. Tio estas, se ni mem nuligis ĝin, tiam ni povas ripeti ĝin. Kaj fizike ĉe vi la datumoj kuŝos en la sama loko. Vi eĉ ne ŝveliĝas. Vi povas ripeti tiajn FORIŜojn.
Ĉi tiu DELETE kun ROLLBACK estas ideala por kontrolpunkto-agordado, eĉ se vi ne havas konvene deplojitajn datumbazajn laboratoriojn.
Ni faris teleron kun unu kolumno "i". Postgres havas utilajn kolumnojn. Ili estas nevideblaj krom se specife petas. Ĉi tiuj estas: ctid, xmid, xmax.
Ctid estas fizika adreso. Nula paĝo, la unua opo en la paĝo.
Videblas, ke post ROOLBACK la opo restis en la sama loko. Tio estas, ni povas provi denove, ĝi kondutos same. Ĉi tio estas la ĉefa afero.
Xmax estas la tempo de morto de la opo. Ĝi estis stampita, sed Postgres scias, ke la transakcio estis nuligita, do ne gravas ĉu ĝi estas 0 aŭ ĝi estas retrovita transakcio. Ĉi tio sugestas, ke eblas ripeti super DELETE kaj kontroli la amasajn operaciojn de la sistema konduto. Vi povas fari datumbazajn laboratoriojn por malriĉuloj.
Ĉi tio temas pri programistoj. Ankaŭ pri DBA oni ĉiam riproĉas programistojn pro tio: "Kial vi faras tiel longajn kaj malfacilajn operaciojn?". Ĉi tio estas tute malsama perpendikulara temo. Antaŭe estis administrado, kaj nun estos evoluo.
Evidente, ni ne rompiĝis en pecojn. Estas klare. Estas neeble ne rompi tian DELETE por amaso da milionoj da linioj en partojn. Ĝi estos farita dum 20 minutoj, kaj ĉio kuŝos. Sed, bedaŭrinde, eĉ spertaj programistoj faras erarojn, eĉ en tre grandaj kompanioj.
Kial gravas rompi?
-
Se ni vidas, ke la disko estas malmola, tiam ni malrapidigu ĝin. Kaj se ni estas rompitaj, tiam ni povas aldoni paŭzojn, ni povas malrapidigi la strekadon.
-
Kaj ni ne blokos aliajn dum longa tempo. En iuj kazoj ne gravas, se vi forigas veran rubon, pri kiu neniu laboras, tiam plej verŝajne vi ne blokos iun ajn krom la aŭtomalplena laboro, ĉar ĝi atendos la finiĝon de la transakcio. Sed se vi forigas ion, kion iu alia povas peti, tiam ili estos blokitaj, estos ia ĉena reago. Longaj transakcioj devus esti evititaj en retejoj kaj moveblaj aplikoj.
Ĉi tio estas interesa. Mi ofte vidas, ke programistoj demandas: "Kian pakgrandecon mi elektu?".
Estas klare, ke ju pli granda estas la pakaĵo, des pli malgranda estas la transakcio superkosto, t.e., la plia superkosto de transakcioj. Sed samtempe, la tempo pliiĝas por ĉi tiu transakcio.
Mi havas tre simplan regulon: prenu kiom vi povas, sed ne trapasu ruleblajn sekundojn.
Kial sekundo? La klarigo estas tre simpla kaj komprenebla por ĉiuj, eĉ neteknikuloj. Ni vidas reagon. Ni prenu 50 milisekundojn. Se io ŝanĝiĝis, tiam nia okulo reagos. Se malpli, tiam pli malfacila. Se io respondas post 100 milisekundoj, ekzemple, vi klakis la muson, kaj ĝi respondis al vi post 100 milisekundoj, vi jam sentas ĉi tiun eta malfruon. Sekundo jam estas perceptata kiel bremsoj.
Sekve, se ni rompas niajn amasajn operaciojn en 10-sekundajn eksplodojn, tiam ni havas riskon, ke ni blokos iun. Kaj ĝi funkcios dum kelkaj sekundoj, kaj homoj jam rimarkos ĝin. Tial mi preferas ne fari pli ol sekundon. Sed samtempe, ne disigu ĝin tre fajne, ĉar la transakcio supre estos videbla. La bazo estos pli malfacila, kaj aliaj malsamaj problemoj povas ekesti.
Ni elektas la grandecon de la pako. En ĉiu kazo, ni povas fari ĝin malsame. Povas esti aŭtomatigita. Kaj ni estas konvinkitaj pri la efikeco de la prilaborado de unu pako. Tio estas, ni faras FORIGI de unu pako aŭ ĜISDATIGI.
Cetere, ĉio, pri kio mi parolas, temas ne nur pri FORIGI. Kiel vi divenis, ĉi tiuj estas iuj amasaj operacioj pri datumoj.
Kaj ni vidas, ke la plano estas bonega. Vi povas vidi la indeksan skanadon, nur indeksa skanado estas eĉ pli bona. Kaj ni havas malgrandan kvanton da datumoj implikitaj. Kaj malpli ol sekundo plenumas. Super.
Kaj ni ankoraŭ devas certigi, ke ne estas degradado. Okazas, ke la unuaj pakoj rapide funkcias, kaj tiam ĝi fariĝas pli kaj pli malbona. La procezo estas tia, ke vi devas multe provi. Ĝuste por tio estas datumbazaj laboratorioj.
Kaj ni ankoraŭ devas prepari ion por ke ĝi permesu al ni sekvi tion ĝuste en produktado. Ekzemple, ni povas skribi la tempon en la protokolo, ni povas skribi kie ni nun estas kaj kiun ni nun forigis. Kaj ĉi tio permesos al ni kompreni kio okazas poste. Kaj se io misfunkcias, rapide trovu la problemon.
Se ni bezonas kontroli la efikecon de petoj kaj ni devas ripeti multajn fojojn, tiam ekzistas tia afero kiel samranga bot. Li jam estas preta. Ĝi estas uzata de dekoj da programistoj ĉiutage. Kaj li scias kiel doni grandegan terabajtan datumbazon laŭpeto en 30 sekundoj, vian propran kopion. Kaj vi povas forigi ion tie kaj diri RESET, kaj forigi ĝin denove. Vi povas eksperimenti kun ĝi tiel. Mi vidas estontecon por ĉi tiu afero. Kaj ni jam faras ĝin.
Kio estas dispartigaj strategioj? Mi vidas 3 malsamajn dispartigajn strategiojn, kiujn la programistoj sur la pako uzas.
La unua estas tre simpla. Ni havas nombran ID. Kaj ni dividu ĝin en malsamajn intervalojn kaj laboru kun tio. La malavantaĝo estas klara. En la unua segmento, ni povas havi 100 liniojn de reala rubo, en la dua 5 linioj aŭ tute ne, aŭ ĉiuj 1 linioj montriĝos esti rubo. Tre malebena laboro, sed ĝi estas facile rompiĝi. Ili prenis la maksimuman identigilon kaj frakasis ĝin. Ĉi tio estas naiva aliro.
La dua strategio estas ekvilibra aliro. Ĝi estas uzata en Gitlab. Ili prenis kaj skanis la tablon. Ni trovis la limojn de la ID-pakoj tiel ke ĉiu pako havis ekzakte 10 rekordojn. Kaj metu ilin en vicon. Kaj tiam ni procesas. Vi povas fari tion en pluraj fadenoj.
Ankaŭ en la unua strategio, cetere, vi povas fari tion en pluraj fadenoj. Ĝi ne estas malfacila.
Sed ekzistas pli malvarmeta kaj pli bona aliro. Ĉi tiu estas la tria strategio. Kaj kiam eblas, estas pli bone elekti ĝin. Ni faras tion surbaze de speciala indekso. En ĉi tiu kazo, ĝi plej verŝajne estos indekso laŭ nia rubokondiĉo kaj identigilo. Ni inkludos la ID por ke ĝi estu nur indekso skanado por ke ni ne iru al la amaso.
Ĝenerale, nur indeksa skanado estas pli rapida ol indeksa skanado.
Kaj ni rapide trovas niajn identigilojn, kiujn ni volas forigi. BATCH_SIZE ni elektas anticipe. Kaj ni ne nur ricevas ilin, ni ricevas ilin en speciala maniero kaj tuj hakas ilin. Sed ni ŝlosas tiel, ke se ili jam estas ŝlositaj, ni ne ŝlosas ilin, sed antaŭeniras kaj prenu la sekvajn. Ĉi tio estas por ĝisdatigo skip ŝlosita. Ĉi tiu bonega funkcio de Postgres permesas al ni labori en pluraj fadenoj, se ni volas. Ĝi eblas en unu rivereto. Kaj ĉi tie estas CTE - ĉi tiu estas unu peto. Kaj ni havas realan forigon en la dua etaĝo de ĉi tiu CTE - returning *. Vi povas redoni identigilon, sed estas pli bone *se vi ne havas multe da datumoj sur ĉiu linio.
Kial ni bezonas ĝin? Jen kion ni devas raporti. Ni nun forigis tiom da linioj fakte. Kaj ni havas landlimojn per ID aŭ per create_at tiel. Vi povas fari min, max. Io alia povas esti farita. Vi povas plenigi multe ĉi tie. Kaj ĝi estas tre oportuna por monitorado.
Estas unu plia noto pri la indekso. Se ni decidas, ke ni bezonas specialan indekson por ĉi tiu tasko, tiam ni devas certigi, ke ĝi ne difektu amason de nur opoj-ĝisdatigoj. Tio estas, Postgres havas tiajn statistikojn. Ĉi tio videblas en pg_stat_user_tables por via tabelo. Vi povas vidi ĉu varmaj ĝisdatigoj estas uzataj aŭ ne.
Estas situacioj, kiam via nova indekso povas simple fortranĉi ilin. Kaj vi havas ĉiujn aliajn ĝisdatigojn, kiuj jam funkcias, malrapidu. Ne nur ĉar la indekso aperis (ĉiu indekso iom malrapidigas ĝisdatigojn, sed iom), sed ĉi tie ĝi ankoraŭ ruinigas ĝin. Kaj estas neeble fari specialan optimumigon por ĉi tiu tablo. Ĉi tio okazas foje. Ĉi tio estas tia subtileco, kiun malmultaj homoj memoras. Kaj ĉi tiu rastilo estas facile treti sur. Kelkfoje okazas, ke vi devas trovi aliron de la alia flanko kaj ankoraŭ malhavi ĉi tiun novan indekson, aŭ fari alian indekson, aŭ alimaniere, ekzemple, vi povas uzi la duan metodon.
Sed ĉi tio estas la plej optimuma strategio, kiel dividi en arojn kaj pafi ĉe aroj per unu peto, forigi iomete, ktp.
Longaj transakcioj
Blokita aŭtomata vakuo -
problemo pri blokado -
Eraro #5 estas granda. Nikolai el Okmeter parolis pri monitorado de Postgres. Ideala Postgres-monitorado bedaŭrinde ne ekzistas. Iuj estas pli proksimaj, iuj pli for. Okmeter estas sufiĉe proksima al esti perfekta, sed multe mankas kaj devas esti aldonita. Vi devas esti preta por ĉi tio.
Ekzemple, mortintaj opoj estas plej bone monitoritaj. Se vi havas multajn mortintojn en la tabelo, tiam io estas malĝusta. Estas pli bone reagi nun, alie povas esti degradado, kaj ni povas kuŝi. Ĝi okazas.
Se estas granda IO, tiam estas klare, ke ĉi tio ne estas bona.
Longaj transakcioj ankaŭ. Longaj transakcioj ne devus esti permesitaj sur OLTP. Kaj jen ligo al fragmento, kiu permesas vin preni ĉi tiun fragmenton kaj jam fari iom da spurado de longaj transakcioj.
Kial longaj transakcioj estas malbonaj? Ĉar ĉiuj seruroj estos liberigitaj nur ĉe la fino. Kaj ni ŝraŭbas ĉiujn. Krome, ni blokas aŭtomatan vakuon por ĉiuj tabloj. Ĝi tute ne estas bona. Eĉ se vi havas varman standby ebligita sur la kopio, ĝi ankoraŭ estas malbona. Ĝenerale, nenie estas pli bone eviti longajn transakciojn.
Se ni havas multajn tablojn, kiuj ne estas vakuitaj, tiam ni devas havi alarmon. Ĉi tie tia situacio eblas. Ni povas nerekte influi la funkciadon de aŭtomata vakuo. Ĉi tio estas fragmento de Avito, kiun mi iomete plibonigis. Kaj ĝi rezultis esti interesa ilo por vidi kion ni havas kun aŭtomata vakuo. Ekzemple, iuj tabloj atendas tie kaj ne atendos sian vicon. Vi ankaŭ devas meti ĝin en monitoradon kaj havi alarmon.
Kaj eldonas blokojn. Arbaro de blokarboj. Mi ŝatas preni ion de iu kaj plibonigi ĝin. Ĉi tie mi prenis bonegan rekursivan CTE de Data Egret, kiu montras arbaron de serurbaj arboj. Ĉi tio estas bona diagnoza ilo. Kaj sur ĝia bazo, vi ankaŭ povas konstrui monitoradon. Sed ĉi tio devas esti farita zorge. Vi devas fari malgrandan statement_timeout por vi mem. Kaj lock_timeout estas dezirinda.
Kelkfoje ĉiuj ĉi tiuj eraroj okazas en sumo.
Laŭ mi, la ĉefa eraro ĉi tie estas organiza. Ĝi estas organiza, ĉar la tekniko ne tiras. Ĉi tio estas la numero 2 - ili kontrolis en malĝusta loko.
Ni kontrolis en malĝusta loko, ĉar ni ne havis produktan klonon, kiu estas facile kontroli. Programisto eble tute ne havas aliron al produktado.
Kaj ni kontrolis ne tie. Se ni estus kontrolintaj tie, ni mem vidus ĝin. La programisto vidis ĉion eĉ sen DBA se li kontrolis ĝin en bona medio, kie estas la sama kvanto da datumoj kaj identa loko. Li estus vidinta ĉi tiun tutan degradadon kaj li hontus.
Pli pri aŭtomata vakuo. Post kiam ni faris amasan balaadon de pluraj milionoj da linioj, ni ankoraŭ devas fari REPACK. Ĉi tio estas precipe grava por indeksoj. Ili sentos malbonon post kiam ni purigis ĉion tie.
Kaj se vi volas revenigi la ĉiutagan purigadon, tiam mi sugestus fari ĝin pli ofte, sed pli malgranda. Ĝi povas esti unufoje en minuto aŭ eĉ pli ofte iomete. Kaj vi devas kontroli du aferojn: ke ĉi tiu afero ne havas erarojn kaj ke ĝi ne postrestas. La lertaĵo, kiun mi montris, nur solvos ĉi tion.
Kion ni faras estas malferma fonto. Ĝi estas afiŝita sur GitLab. Kaj ni faras ĝin tiel ke homoj povas kontroli eĉ sen DBA. Ni faras datumbazan laboratorion, tio estas, ni nomas la bazan komponanton pri kiu Joe nuntempe laboras. Kaj vi povas preni kopion de produktado. Nun ekzistas efektivigo de Joe por malstreĉo, vi povas diri tie: "klarigu tian kaj tian peton" kaj tuj ricevu la rezulton por via kopio de la datumbazo. Vi povas eĉ FORVIĜI tie, kaj neniu rimarkos ĝin.
Ni diru, ke vi havas 10 terabajtojn, ni faras datumbazan laboratorion ankaŭ 10 terabajtojn. Kaj kun samtempaj 10 terabajtaj datumbazoj, 10 programistoj povas labori samtempe. Ĉiu povas fari kion ili volas. Povas forigi, faligi, ktp. Tio estas tia fantazio. Pri tio ni parolos morgaŭ.
Ĉi tio nomiĝas maldika provizo. Ĉi tio estas subtila provizado. Ĉi tio estas ia fantazio, kiu multe forigas prokrastojn en evoluo, en testado kaj faras la mondon pli bona loko ĉi-rilate. Tio estas, ĝi nur permesas vin eviti problemojn kun pograndaj operacioj.
Ekzemplo: datumbazo de 5 terabajtoj, ricevante kopion en malpli ol 30 sekundoj. Kaj ĝi eĉ ne dependas de la grandeco, tio estas, ne gravas kiom da terabajtoj.
Hodiaŭ vi povas iri al kaj fosu en niajn ilojn. Vi povas registriĝi por vidi kio estas tie. Vi povas instali ĉi tiun roboton. Ĝi estas senpaga. Skribu.
Viaj demandoj
Tre ofte en realaj situacioj rezultas, ke la datumoj, kiuj devus resti en la tabelo, estas multe malpli ol tio, kio devas esti forigita. Tio estas, en tia situacio, estas ofte pli facile efektivigi tian aliron, kiam estas pli facile krei novan objekton, kopii nur la necesajn datumojn tie, kaj trunki la malnovan tabelon. Estas klare, ke programa aliro estas necesa por ĉi tiu momento, dum vi ŝanĝos. Kiel estas ĉi tiu aliro?
Ĉi tio estas tre bona aliro kaj tre bona tasko. Ĝi estas tre simila al tio, kion faras pg_repack, ĝi estas tre simila al tio, kion vi devas fari kiam vi faras identigilojn 4 bajtojn. Multaj kadroj faris tion antaŭ kelkaj jaroj, kaj nur la platoj kreskis, kaj ili devas esti konvertitaj al 8 bajtoj.
Ĉi tiu tasko estas sufiĉe malfacila. Ni faris ĝin. Kaj vi devas esti tre singarda. Estas seruroj ktp. Sed ĝi estas farita. Tio estas, la norma aliro estas iri kun pg_repack. Vi deklaras tian etikedon. Kaj antaŭ ol vi komencas alŝuti momentajn datumojn en ĝin, vi ankaŭ deklaras unu platon, kiu spuras ĉiujn ŝanĝojn. Estas lertaĵo, ke vi eble eĉ ne spuras iujn ŝanĝojn. Estas subtilecoj. Kaj tiam vi ŝanĝas per ruliĝantaj ŝanĝoj. Estos mallonga paŭzo kiam ni fermos ĉiujn, sed ĝenerale tio estas farita.
Se vi rigardas pg_repack sur GitHub, tiam tie, kiam estis tasko konverti ID de int 4 al int 8, tiam estis ideo uzi pg_repack mem. Ĉi tio ankaŭ eblas, sed ĝi estas iom da hako, sed ĝi funkcios ankaŭ por ĉi tio. Vi povas interveni en la ellasilon, kiun pg_repack uzas kaj diri tie: "Ni ne bezonas ĉi tiujn datumojn", t.e. ni transdonas nur tion, kion ni bezonas. Kaj tiam li nur ŝaltas kaj jen ĝi.
Kun ĉi tiu aliro, ni ankoraŭ ricevas duan kopion de la tabelo, en kiu la datumoj jam estas indeksitaj kaj stakitaj tre egale kun belaj indeksoj.
Bloat ne ĉeestas, ĝi estas bona aliro. Sed mi scias, ke estas provoj evoluigi aŭtomatigon por ĉi tio, t.e. fari universalan solvon. Mi povas kontakti vin kun ĉi tiu aŭtomatigo. Ĝi estas skribita en Python, kio estas bona afero.
Mi estas nur iomete el la mondo de MySQL, do mi venis por aŭskulti. Kaj ni uzas ĉi tiun aliron.
Sed estas nur se ni havas 90%. Se ni havas 5%, tiam ne estas tre bone uzi ĝin.
Dankon pro la raporto! Se ne ekzistas rimedoj por fari kompletan kopion de prod, ĉu ekzistas ia algoritmo aŭ formulo por kalkuli la ŝarĝon aŭ grandecon?
Bona demando. Ĝis nun, ni kapablas trovi mult-terabajtajn datumbazojn. Eĉ se la aparataro ne estas la sama, ekzemple, malpli da memoro, malpli da procesoro kaj diskoj ne estas ĝuste la samaj, sed tamen ni faras ĝin. Se estas absolute nenie, tiam vi devas pensi. Lasu min pensi ĝis morgaŭ, vi venis, ni parolos, ĉi tio estas bona demando.
Dankon pro la raporto! Vi unue komencis pri tio, ke ekzistas bonega Postgres, kiu havas tiajn kaj tiajn limigojn, sed ĝi disvolviĝas. Kaj ĉi tio ĉio estas lambastono ĝenerale. Ĉu ĉio ĉi ne konfliktas kun la evoluo de Postgres mem, en kiu aperos iu DELETE-deferento aŭ io alia, kiu devus teni je malalta nivelo, kion ni provas ŝmiri per iuj niaj strangaj rimedoj ĉi tie?
Se ni diris en SQL forigi aŭ ĝisdatigi multajn rekordojn en unu transakcio, tiam kiel Postgres povas distribui ĝin tie? Ni estas fizike limigitaj en operacioj. Ni ankoraŭ faros ĝin dum longa tempo. Kaj ni ŝlosos ĉi-momente, ktp.
Farite kun indeksoj.
Mi povas supozi, ke la sama kontrolpunkto-agordado povus esti aŭtomatigita. Iam eble estos. Sed tiam mi ne vere komprenas la demandon.
La demando estas, ĉu ekzistas tia vektoro de evoluo, kiu iras ĉi tie kaj tie, kaj ĉi tie la via iras paralela? Tiuj. Ĉu ili ankoraŭ ne pensis pri tio?
Mi parolis pri la principoj uzeblaj nun. Estas alia bot , per tio vi povas fari aŭtomatan agordon de kontrolpunkto. Ĉu ĝi estos iam en Postgres? Mi ne scias, ĝi eĉ ne estas diskutita ankoraŭ. Ni ankoraŭ estas malproksime de tio. Sed estas sciencistoj, kiuj faras novajn sistemojn. Kaj ili ŝovas nin en aŭtomatajn indeksojn. Estas evoluoj. Ekzemple, vi povas rigardi aŭtomatan agordon. Ĝi elektas parametrojn aŭtomate. Sed li ankoraŭ ne faros kontrolpunkton por vi. Tio estas, ĝi prenos por rendimento, ŝelbufro, ktp.
Kaj por agordado de kontrolpunkto, vi povas fari ĉi tion: se vi havas mil aretojn kaj malsaman aparataron, malsamajn virtualajn maŝinojn en la nubo, vi povas uzi nian roboton. fari aŭtomatigon. Kaj max_wal_size aŭtomate estos elektita laŭ viaj celaj agordoj. Sed ĝis nun ĉi tio eĉ ne estas proksima en la kerno, bedaŭrinde.
Bonan posttagmezon Vi parolis pri la danĝeroj de longaj transakcioj. Vi diris, ke aŭtomata vakuo estas blokita okaze de forigoj. Kiel alie ĝi damaĝas nin? Ĉar ni parolas pli pri liberigi spacon kaj povi uzi ĝin. Kion alian ni mankas?
Aŭtomata vakuo eble ne estas la plej granda problemo ĉi tie. Kaj la fakto, ke longa transakcio povas ŝlosi aliajn transakciojn, ĉi tiu ebleco estas pli danĝera. Ŝi povas aŭ eble ne renkontas. Se ŝi renkontis, tiam ĝi povas esti tre malbona. Kaj kun aŭtomata vakuo - ĉi tio ankaŭ estas problemo. Estas du problemoj kun longaj transakcioj en OLTP: seruroj kaj aŭtomata vakuo. Kaj se vi havas varman atendan retrosciigon ebligita sur la kopio, tiam vi ankoraŭ ricevos aŭtomatan vakuan seruron sur la majstro, ĝi alvenos de la kopio. Sed almenaŭ ne estos seruroj. Kaj estos loks. Ni parolas pri datumŝanĝoj, do seruroj estas grava punkto ĉi tie. Kaj se ĉi tio estas ĉio por longa, longa tempo, tiam pli kaj pli da transakcioj estas ŝlositaj. Ili povas ŝteli aliajn. Kaj aperas lok-arboj. Mi disponigis ligilon al la fragmento. Kaj ĉi tiu problemo fariĝas pli rimarkebla pli rapide ol la problemo kun aŭtomata vakuo, kiu povas nur akumuliĝi.
Dankon pro la raporto! Vi komencis vian raporton dirante, ke vi testis malĝuste. Ni daŭrigis nian ideon, ke ni devas preni la saman ekipaĵon, kun la bazo en la sama maniero. Ni diru, ke ni donis al la programisto bazon. Kaj li plenumis la peton. Kaj li ŝajnas esti bona. Sed li ne kontrolas por vivas, sed por vivas, ekzemple, ni havas ŝarĝon de 60-70%. Kaj eĉ se ni uzas ĉi tiun agordon, ĝi ne funkcias tre bone.
Gravas havi spertulon pri la teamo kaj uzi DBA-fakulojn, kiuj povas antaŭdiri, kio okazos kun reala fona ŝarĝo. Kiam ni ĵus veturis niajn purajn ŝanĝojn, ni vidas la bildon. Sed pli progresinta alproksimiĝo, kiam ni faris la samon denove, sed kun ŝarĝo simulita kun produktado. Ĝi estas sufiĉe mojosa. Ĝis tiam, vi devas kreski. Estas kiel plenkreskulo. Ni nur rigardis kion ni havas kaj ankaŭ rigardis ĉu ni havas sufiĉe da rimedoj. Tio estas bona demando.
Kiam ni jam faras ruban elekton kaj ni havas, ekzemple, forigitan flagon
Jen kion aŭtomate faras aŭtomalvakuo en Postgres.
Ho, ĉu li faras ĝin?
Aŭtovakuo estas la rubkolektanto.
Dankon!
Dankon pro la raporto! Ĉu estas eblo tuj desegni datumbazon kun dispartigo tiel, ke ĉiuj rubaĵoj malpuriĝu de la ĉefa tablo ie flanken?
Kompreneble havas.
Ĉu eblas do protekti nin, se ni ŝlosis tablon, kiun oni ne uzu?
Kompreneble havas. Sed ĝi estas kvazaŭ demando pri kokido kaj ovo. Se ni ĉiuj scias, kio okazos en la estonteco, tiam, kompreneble, ni faros ĉion malvarmeta. Sed la komerco ŝanĝiĝas, estas novaj kolumnoj, novaj petoj. Kaj tiam - ho, ni volas forigi ĝin. Sed ĉi tiu ideala situacio, en la vivo ĝi okazas, sed ne ĉiam. Sed ĝenerale ĝi estas bona ideo. Nur detranĉu kaj jen ĝi.
fonto: www.habr.com