Niekedy v ďalekej budúcnosti bude automatické odstraňovanie nepotrebných dát jednou z dôležitých úloh DBMS [1]. Medzitým sa my sami musíme postarať o vymazanie alebo presun nepotrebných dát do menej nákladných úložných systémov. Povedzme, že sa rozhodnete odstrániť niekoľko miliónov riadkov. Pomerne jednoduchá úloha, najmä ak je známy stav a existuje vhodný index. "DELETE FROM table1 WHERE col1 = :value" - čo môže byť jednoduchšie, však?
Video:
-
V programovom výbore Highload som od prvého ročníka, teda od roku 2007.
-
A v Postgres som od roku 2005. Použil sa v mnohých projektoch.
-
Skupina s RuPostges tiež od roku 2007.
-
Na Meetupe sme sa rozrástli na 2100+ účastníkov. Po New Yorku je druhý na svete, dlhodobo ho predbieha San Francisco.
-
Už niekoľko rokov žijem v Kalifornii. Viac sa venujem americkým firmám, vrátane veľkých. Sú aktívnymi používateľmi Postgresu. A sú tam všelijaké zaujímavosti.
je moja spoločnosť. Zaoberáme sa automatizáciou úloh, ktoré eliminujú spomalenie vývoja.
Ak niečo robíte, potom sa niekedy okolo Postgresu nájdu nejaké zátky. Povedzme, že musíte počkať, kým vám admin nastaví testovaciu stanicu, alebo musíte počkať, kým vám DBA odpovie. A práve takéto úzke miesta nachádzame v procese vývoja, testovania a administrácie a snažíme sa ich eliminovať pomocou automatizácie a nových prístupov.
Nedávno som bol vo VLDB v Los Angeles. Ide o najväčšiu konferenciu o databázach. A objavila sa správa, že v budúcnosti bude DBMS nielen ukladať, ale aj automaticky mazať údaje. Toto je nová téma.
Vo svete zettabajtov je stále viac dát – to je 1 000 000 petabajtov. A už teraz sa odhaduje, že na svete máme uložených viac ako 100 zettabajtov dát. A je ich stále viac.
A čo s tým robiť? Je zrejmé, že ho treba odstrániť. Tu je odkaz na túto zaujímavú správu. Ale zatiaľ to nebolo implementované v DBMS.
Tí, ktorí vedia počítať peniaze, chcú dve veci. Chcú, aby sme ich vymazali, takže technicky by sme to mali zvládnuť.
Čo poviem nabudúce, je nejaká abstraktná situácia, ktorá zahŕňa kopu reálnych situácií, teda akýsi kompilát toho, čo sa mne a okolitým databázam vlastne stalo veľakrát, veľa rokov. Hrable sú všade a každý na ne neustále šľape.
Povedzme, že máme základňu alebo niekoľko základov, ktoré rastú. A niektoré záznamy sú zjavne svinstvo. Používateľ tam napríklad začal niečo robiť, no nedokončil to. A po nejakom čase vieme, že tento nedokončený už nie je možné skladovať. To znamená, že by sme chceli vyčistiť nejaké odpadky, aby sme ušetrili miesto, zlepšili výkon atď.
Vo všeobecnosti je úlohou automatizovať mazanie konkrétnych vecí, konkrétnych riadkov v nejakej tabuľke.
A máme takú požiadavku, o ktorej si dnes povieme, teda o odvoze smetí.
Požiadali sme o to skúseného vývojára. Vzal túto požiadavku, skontroloval ju pre seba - všetko funguje. Testované na stagingu - všetko v poriadku. Rozvinuté - všetko funguje. Raz za deň to spustíme - všetko je v poriadku.
Databáza rastie a rastie. Denné DELETE začne fungovať o niečo pomalšie.
Potom pochopíme, že teraz máme marketingovú firmu a návštevnosť bude niekoľkonásobne väčšia, tak sa rozhodneme nepotrebné veci dočasne pozastaviť. A zabudni sa vrátiť.
O pár mesiacov sa spamätali. A ten vývojár skončil alebo je zaneprázdnený niečím iným, dal inému pokyn, aby to vrátil.
Skontroloval na vývoji, na stagingu - všetko je v poriadku. Prirodzene, stále musíte vyčistiť to, čo sa nahromadilo. Skontroloval, či všetko funguje.
Čo bude ďalej? Potom sa nám všetko rozpadá. Klesá tak, že v určitom bode všetko spadne. Všetci sú v šoku, nikto nechápe, čo sa deje. A potom sa ukáže, že vec bola v tomto DELETE.
Niečo sa pokazilo? Tu je zoznam toho, čo sa mohlo pokaziť. Ktorý z nich je najdôležitejší?
-
Napríklad neexistovala žiadna recenzia, t. j. expert DBA sa na to nepozrel. Skúseným okom by problém okamžite našiel a okrem toho má prístup k produ, kde sa nahromadilo niekoľko miliónov riadkov.
-
Možno niečo zle skontrolovali.
-
Možno je hardvér zastaraný a musíte túto základňu upgradovať.
-
Alebo niečo nie je v poriadku so samotnou databázou a musíme prejsť z Postgresu na MySQL.
-
Alebo možno nie je niečo v poriadku s operáciou.
-
Možno sú nejaké chyby v organizácii práce a potrebujete niekoho prepustiť a zamestnať najlepších ľudí?
Neexistovala žiadna kontrola DBA. Ak by existoval DBA, videl by týchto niekoľko miliónov riadkov a aj bez akýchkoľvek experimentov by povedal: "To nerobia." Predpokladajme, že ak by tento kód bol v GitLab, GitHub a bol by tam proces kontroly kódu a nebol by taký, že bez schválenia DBA by sa táto operácia uskutočnila na prod, potom by DBA samozrejme povedal: „Toto sa nedá urobiť. “
A povedal by, že budete mať problémy s IO disku a všetky procesy sa zbláznia, môžu tam byť zámky a tiež budete blokovať autovakuum na veľa minút, takže to nie je dobré.
Druhá chyba - kontrolovali na nesprávnom mieste. Potom sme videli, že na produkte sa nahromadilo veľa nevyžiadaných údajov, ale vývojár nemal nahromadené údaje v tejto databáze a nikto tieto nevyžiadané údaje nevytvoril počas stagingu. V súlade s tým tam bolo 1 000 riadkov, ktoré rýchlo fungovali.
Chápeme, že naše testy sú slabé, t. j. vytvorený proces nezachytáva problémy. Nebol vykonaný adekvátny DB experiment.
Ideálny experiment sa prednostne vykonáva na rovnakom zariadení. Nie je to vždy možné urobiť na rovnakom zariadení, ale je veľmi dôležité, aby to bola kópia databázy v plnej veľkosti. Toto kážem už niekoľko rokov. A pred rokom som o tom hovoril, všetko si môžete pozrieť na YouTube.
Možno je naše vybavenie zlé? Ak sa pozriete, latencia vyskočila. Videli sme, že využitie je 100%. Samozrejme, ak by to boli moderné NVMe disky, potom by to bolo pre nás zrejme oveľa jednoduchšie. A možno by sme z toho neľahli.
Ak máte mraky, potom sa upgrade jednoducho vykoná tam. Vybudované nové repliky na novom hardvéri. prepnúť. A všetko je v poriadku. Celkom ľahko.
Dá sa nejako dotknúť menších diskov? A tu sa len s pomocou DBA ponoríme do určitej témy zvanej ladenie kontrolných bodov. Ukázalo sa, že sme nemali ladenie kontrolných bodov.
Čo je kontrolný bod? Je v každom DBMS. Keď máte v pamäti dáta, ktoré sa menia, nie sú okamžite zapísané na disk. Informácia, že údaje sa zmenili, sa najskôr zapíše do denníka zápisu dopredu. A v určitom bode sa DBMS rozhodne, že je čas uložiť skutočné stránky na disk, aby sme v prípade zlyhania mohli robiť menej REDO. Je to ako hračka. Ak nás zabijú, začneme hru od posledného kontrolného bodu. A všetky DBMS to implementujú.
Nastavenia v Postgrese zaostávajú. Sú určené pre 10-15 rokov staré objemy dát a transakcií. A checkpoint nie je výnimkou.
Tu sú informácie z našej kontrolnej správy Postgres, t. j. automatickej kontroly zdravotného stavu. A tu je nejaká databáza niekoľkých terabajtov. A dobre vidno, že vynútené kontroly v takmer 90% prípadov.
Čo to znamená? Sú tam dve nastavenia. Kontrolný bod môže prísť časovým limitom, napríklad za 10 minút. Alebo to môže prísť, keď sa vyplní pomerne veľa údajov.
A predvolene je max_wal_saze nastavený na 1 gigabajt. V skutočnosti sa to naozaj deje v Postgrese po 300-400 megabajtoch. Zmenili ste toľko údajov a váš kontrolný bod sa stane.
A ak to nikto nenaladil a služba rástla a spoločnosť zarába veľa peňazí, má veľa transakcií, tak kontrolný bod prichádza raz za minútu, niekedy každých 30 sekúnd a niekedy sa dokonca prekrýva. To je dosť zlé.
A musíme zabezpečiť, aby to prichádzalo menej často. To znamená, že môžeme zvýšiť max_wal_size. A príde menej často.
Vyvinuli sme ale celú metodiku, ako to urobiť správnejšie, teda ako sa rozhodnúť o výbere nastavení, jasne na základe konkrétnych údajov.
V súlade s tým robíme dve série experimentov s databázami.
Prvá séria - zmeníme max_wal_size. A robíme rozsiahlu operáciu. Najprv to urobíme pri predvolenom nastavení 1 gigabajt. A robíme masívne VYMAZANIE mnohých miliónov riadkov.
Vidíte, aké je to pre nás ťažké. Vidíme, že IO disku je veľmi zlé. Pozeráme sa na to, koľko WAL sme vygenerovali, pretože je to veľmi dôležité. Pozrime sa, koľkokrát sa kontrolný bod stal. A vidíme, že to nie je dobré.
Ďalej zväčšíme max_wal_size. Opakujeme. Zvyšujeme, opakujeme. A toľkokrát. V zásade je dobrých 10 bodov, kde 1, 2, 4, 8 gigabajtov. A pozrieme sa na správanie konkrétneho systému. Je jasné, že tu by mala byť výbava ako na prod. Musíte mať rovnaké disky, rovnaké množstvo pamäte a rovnaké nastavenia Postgres.
A takto si vymeníme náš systém a vieme, ako sa bude správať DBMS v prípade zlého hromadného DELETE, ako bude checkpoint.
Kontrolný bod v ruštine sú kontrolné stanovištia.
Príklad: DELETE niekoľko miliónov riadkov podľa indexu, riadky sú „rozhádzané“ po stránkach.
Tu je príklad. Toto je nejaký základ. A s predvoleným nastavením 1 gigabajt pre max_wal_size je úplne jasné, že naše disky idú do police na nahrávanie. Tento obrázok je typickým príznakom veľmi chorého pacienta, to znamená, že sa naozaj cítil zle. A bola tam jedna jediná operácia, bolo tam len VYMAZANIE niekoľkých miliónov riadkov.
Ak je takáto operácia povolená v prod, tak budeme len ležať, lebo je jasné, že jedno DELETE nás v pluku zabije.
Ďalej, kde je 16 gigabajtov, je jasné, že zuby už odišli. Zuby sú už lepšie, teda klopeme na strop, ale nie až tak zle. Bola tam určitá sloboda. Na pravej strane je záznam. A počet operácií - druhý graf. A je jasné, že pri 16 gigabajtoch sa nám už dýcha o niečo ľahšie.
A kde je 64 gigabajtov vidieť, že sa to úplne zlepšilo. Už sú zuby výrazné, je viac možností prežiť ďalšie operácie a urobiť niečo s diskom.
Prečo je to?
Trochu sa ponorím do detailov, ale z tejto témy, ako vykonať ladenie kontrolných bodov, môže vzniknúť celá správa, takže nebudem veľa načítavať, ale trochu načrtnem, aké sú tam ťažkosti.
Ak sa kontrolný bod vyskytuje príliš často a neaktualizujeme naše riadky postupne, ale vyhľadávame podľa indexu, čo je dobré, pretože nevymažeme celú tabuľku, potom sa môže stať, že sme sa najskôr dotkli prvej stránky, potom tisíciny, a potom sa vrátil k prvému . A ak medzi týmito návštevami prvej stránky už ju checkpoint uložil na disk, tak ju uloží znova, lebo sme ju zašpinili druhýkrát.
A prinútime kontrolný bod, aby to mnohokrát uložil. Ako by pre neho boli nadbytočné operácie.
To však nie je všetko. Stránky majú 8 kilobajtov v Postgrese a 4 kilobajty v Linuxe. A je tu nastavenie full_page_writes. V predvolenom nastavení je povolená. A to je správne, pretože ak ho vypneme, tak hrozí, že pri páde sa zachráni len polovica stránky.
Správanie sa pri zápise do WAL dopredného protokolu je také, že keď máme kontrolný bod a prvýkrát zmeníme stránku, celá stránka, teda všetkých 8 kilobajtov, sa dostane do dopredného protokolu, hoci sme zmenili iba riadok, ktorý váži 100 bajtov. A musíme si zapísať celú stranu.
V následných zmenách bude len konkrétna n-tica, ale prvýkrát zapisujeme všetko.
A teda, ak by sa kontrolný bod opakoval, musíme začať všetko od začiatku a stlačiť celú stránku. Pri častých kontrolných bodoch, keď prechádzame rovnakými stránkami, full_page_writes = on bude viac, ako by mohlo byť, t. j. vygenerujeme viac WAL. Viac sa posiela do replík, do archívu, na disk.
A preto máme dvoch prepustených pracovníkov.
Ak zväčšíme max_wal_size, ukáže sa, že to uľahčíme pre checkpoint aj wal Writer. A to je skvelé.
Vložme terabajt a žime s ním. čo je na tom zlé? To je zlé, lebo v prípade neúspechu budeme liezť hodiny, pretože kontrola bola dávno a už sa veľa zmenilo. A toto všetko musíme urobiť REDO. A tak robíme druhú sériu experimentov.
Urobíme operáciu a uvidíme, keď sa kontrolný bod dokončí, úmyselne zabijeme -9 Postgres.
A potom to znova spustíme a uvidíme, ako dlho to bude na tomto zariadení stúpať, t. j. ako veľmi sa to v tejto zlej situácii REDO.
Dvakrát podotknem, že situácia je zlá. Najprv sme havarovali tesne pred koncom kontroly, takže máme čo stratiť. A po druhé, mali sme masívnu operáciu. A ak by kontrolné body boli v časovom limite, potom by sa s najväčšou pravdepodobnosťou od posledného kontrolného bodu vygenerovalo menej WAL. To znamená, že ide o dvojitý prepadák.
Takúto situáciu meriame pre rôzne veľkosti max_wal_size a chápeme, že ak je max_wal_size 64 gigabajtov, tak v dvojnásobnom najhoršom prípade budeme stúpať 10 minút. A rozmýšľame, či nám to vyhovuje alebo nie. Toto je obchodná otázka. Tento obrázok musíme ukázať tým, ktorí sú zodpovední za obchodné rozhodnutia, a opýtať sa: „Ako dlho môžeme maximálne ležať v prípade problému? Môžeme si v najhoršej situácii ľahnúť na 3-5 minút? A ty sa rozhodneš.
A tu je zaujímavý bod. Na konferencii máme pár správ o Patroni. A možno to aj využívate. Toto je autofailover pre Postgres. GitLab a Data Egret o tom hovorili.
A ak máte autofailover, ktorý príde za 30 sekúnd, potom si možno môžeme ľahnúť na 10 minút? Pretože v tomto bode prejdeme na repliku a všetko bude v poriadku. Toto je sporný bod. Jednoznačnú odpoveď nepoznám. Len mám pocit, že táto téma sa netýka len obnovy po havárii.
Ak nás po neúspechu čaká dlhé zotavovanie, potom budeme nepríjemní v mnohých iných situáciách. Napríklad pri rovnakých pokusoch, keď niečo robíme a niekedy musíme čakať aj 10 minút.
Stále by som nezachádzal príliš ďaleko, aj keď máme autofailover. Hodnoty ako 64, 100 gigabajtov sú spravidla dobré hodnoty. Niekedy sa dokonca oplatí vyberať menej. Vo všeobecnosti je to jemná veda.
Ak chcete vykonať iterácie, napríklad max_wal_size =1, 8, musíte hromadnú operáciu mnohokrát zopakovať. Podarilo sa ti to. A na tej istej báze to chcete urobiť znova, ale už ste všetko vymazali. Čo robiť?
Neskôr poviem o našom riešení, čo robíme, aby sme v takýchto situáciách opakovali. A toto je ten najsprávnejší prístup.
V tomto prípade sme však mali šťastie. Ak, ako sa tu hovorí „ZAČAŤ, VYMAZAŤ, ROLLBACK“, môžeme zopakovať DELETE. Teda ak sme si to sami zrušili, tak to môžeme zopakovať. A fyzicky na vás budú dáta ležať na rovnakom mieste. Ani sa ti nenafúkne. Takéto DELETE môžete opakovať.
Toto DELETE s ROLLBACK je ideálne na ladenie kontrolných bodov, aj keď nemáte správne nasadené databázové laboratóriá.
Vyrobili sme dosku s jedným stĺpikom „i“. Postgres má stĺpce utility. Sú neviditeľné, pokiaľ nie sú špeciálne požiadané. Sú to: ctid, xmid, xmax.
Ctid je fyzická adresa. Nultá stránka, prvá n-tica na stránke.
Je vidieť, že po ROOLBACK ostala tuple na rovnakom mieste. To znamená, že to môžeme skúsiť znova, bude sa to správať rovnako. Toto je hlavná vec.
Xmax je čas smrti n-tice. Bola opečiatkovaná, ale Postgres vie, že transakcia bola vrátená späť, takže nezáleží na tom, či je 0 alebo ide o vrátenú transakciu. To naznačuje, že je možné iterovať cez DELETE a kontrolovať hromadné operácie správania systému. Môžete urobiť databázové laboratóriá pre chudobných.
Toto je o programátoroch. Aj o DBA za to programátorom vždy nadávajú: „Prečo robíte také dlhé a náročné operácie?“. Toto je úplne iná kolmá téma. Kedysi bola administratíva a teraz bude vývoj.
Je zrejmé, že sme sa nerozbili na kúsky. To je jasné. Nie je možné nerozbiť takéto DELETE pre hromadu miliónov riadkov na časti. Bude sa to robiť 20 minút a všetko bude ležať. Ale, bohužiaľ, aj skúsení vývojári robia chyby, dokonca aj vo veľmi veľkých spoločnostiach.
Prečo je dôležité lámať sa?
-
Ak vidíme, že je disk tvrdý, tak ho spomaľme. A ak sme rozbití, potom môžeme pridať pauzy, môžeme spomaliť škrtenie.
-
A ostatných nebudeme dlho blokovať. V niektorých prípadoch to nevadí, ak odstraňujete skutočný odpad, na ktorom nikto nepracuje, s najväčšou pravdepodobnosťou nezablokujete nikoho okrem práce s automatickým vysávaním, pretože bude čakať na dokončenie transakcie. Ale ak odstránite niečo, čo môže niekto iný požiadať, potom budú zablokované, dôjde k nejakej reťazovej reakcii. Na webových stránkach a mobilných aplikáciách by ste sa mali vyhnúť dlhým transakciám.
Toto je zaujímavé. Často vidím, že sa vývojári pýtajú: „Akú veľkosť balenia si mám vybrať?“.
Je zrejmé, že čím väčšia je veľkosť balíka, tým menšia je réžia transakcie, t. j. dodatočná réžia z transakcií. Zároveň sa však predlžuje čas tejto transakcie.
Mám veľmi jednoduché pravidlo: vezmite si toľko, koľko môžete, ale neprekračujte spustiteľné súbory za sekundu.
Prečo sekundu? Vysvetlenie je veľmi jednoduché a zrozumiteľné pre každého, aj pre netechnických ľudí. Vidíme reakciu. Vezmime si 50 milisekúnd. Ak sa niečo zmenilo, naše oko zareaguje. Ak menej, tak ťažšie. Ak niečo zareaguje po 100 milisekúndách, napríklad ste klikli myšou, a ono vám odpovedalo po 100 milisekúndách, toto mierne oneskorenie už cítite. Sekundu už vnímame ako brzdy.
Ak teda rozdelíme naše hromadné operácie na 10-sekundové dávky, potom máme riziko, že niekoho zablokujeme. A bude to fungovať niekoľko sekúnd a ľudia si to už všimnú. Preto radšej nerobím viac ako sekundu. Zároveň to však nerozdeľujte veľmi jemne, pretože réžia transakcie bude viditeľná. Podklad bude tvrdší a môžu nastať ďalšie rôzne problémy.
Vyberáme veľkosť balenia. V každom prípade to môžeme urobiť inak. Dá sa zautomatizovať. A sme presvedčení o efektívnosti spracovania jedného balenia. To znamená, že urobíme DELETE jedného balíka alebo UPDATE.
Mimochodom, všetko, o čom hovorím, nie je len o DELETE. Ako ste uhádli, ide o akékoľvek hromadné operácie s údajmi.
A vidíme, že plán je výborný. Môžete vidieť indexové skenovanie, indexové skenovanie je ešte lepšie. A máme k dispozícii malé množstvo údajov. A splní menej ako sekunda. Super.
A stále sa musíme uistiť, že nedochádza k degradácii. Stáva sa, že prvé balenia rýchlo vyjdú a potom je to horšie, horšie a horšie. Proces je taký, že musíte veľa testovať. Presne na to slúžia databázové laboratóriá.
A ešte musíme niečo pripraviť, aby nám to umožnilo to pri výrobe správne dodržiavať. Môžeme si napríklad zapísať čas do logu, môžeme napísať, kde sa práve nachádzame a koho sme teraz vymazali. A to nám umožní pochopiť, čo sa deje neskôr. A ak sa niečo pokazí, rýchlo nájdite problém.
Ak potrebujeme skontrolovať efektivitu požiadaviek a musíme ich mnohokrát opakovať, potom existuje niečo ako kolega bot. Už je pripravený. Denne ho využívajú desiatky vývojárov. A vie, ako poskytnúť obrovskú terabajtovú databázu na požiadanie za 30 sekúnd, vašu vlastnú kópiu. A môžete tam niečo vymazať a povedať RESET a znova to vymazať. Môžete s ním takto experimentovať. V tejto veci vidím budúcnosť. A už to robíme.
Čo sú to stratégie rozdelenia? Vidím 3 rôzne stratégie rozdelenia, ktoré používajú vývojári v balíku.
Prvý z nich je veľmi jednoduchý. Máme číselné ID. A rozložme si to na rôzne intervaly a pracujme s tým. Nevýhoda je jasná. V prvom segmente môžeme mať 100 riadkov skutočného odpadu, v druhom 5 riadkov alebo vôbec, alebo sa všetkých 1 000 riadkov ukáže ako odpad. Veľmi nerovnomerná práca, ale ľahko sa zlomí. Zobrali maximálny preukaz a rozbili ho. Toto je naivný prístup.
Druhou stratégiou je vyvážený prístup. Používa sa v Gitlabe. Vzali a prehľadali stôl. Našli sme hranice balíkov ID tak, aby každý balík mal presne 10 000 záznamov. A postavte ich do radu. A potom spracujeme. Môžete to urobiť vo viacerých vláknach.
Mimochodom, aj v prvej stratégii to môžete urobiť v niekoľkých vláknach. Nie je to ťažké.
Existuje však chladnejší a lepší prístup. Toto je tretia stratégia. A keď je to možné, je lepšie si ho vybrať. Robíme to na základe špeciálneho indexu. V tomto prípade to bude s najväčšou pravdepodobnosťou index podľa nášho stavu odpadu a ID. Zahrnieme ID tak, aby to bol iba indexový sken, aby sme nešli do haldy.
Vo všeobecnosti je iba indexové skenovanie rýchlejšie ako indexové skenovanie.
A rýchlo nájdeme svoje ID, ktoré chceme vymazať. BATCH_SIZE vyberieme vopred. A my ich nielen získame, ale aj špeciálnym spôsobom získame a hneď aj hackneme. My ale zamykáme tak, že ak sú už zamknuté, tak ich nezamykáme, ale ideme ďalej a berieme ďalšie. Toto je pre zamknutie preskočenia aktualizácie. Táto super funkcia Postgres nám umožňuje pracovať vo viacerých vláknach, ak chceme. Je to možné v jednom prúde. A tu je CTE - to je jedna požiadavka. A v druhom poschodí tohto CTE prebieha skutočné vymazanie - returning *. Môžete vrátiť ID, ale je to lepšie *ak nemáte veľa údajov na každom riadku.
Prečo to potrebujeme? To je to, čo musíme nahlásiť. Teraz sme v skutočnosti vymazali toľko riadkov. A máme hranice podľa ID alebo podľa created_at takto. Môžete urobiť min, max. Dá sa urobiť niečo iné. Môžete tu napchať veľa. A to je veľmi výhodné na monitorovanie.
K indexu je ešte jedna poznámka. Ak sa rozhodneme, že na túto úlohu potrebujeme špeciálny index, potom sa musíme uistiť, že nekazí aktualizácie haldy iba ničiek. To znamená, že Postgres má takéto štatistiky. Môžete to vidieť v pg_stat_user_tables pre vašu tabuľku. Môžete vidieť, či sa používajú horúce aktualizácie alebo nie.
Sú situácie, keď ich váš nový index môže jednoducho odrezať. A máte všetky ostatné aktualizácie, ktoré už fungujú, spomaľte. Nielen preto, že sa objavil index (každý index trochu, ale trochu spomaľuje aktualizácie), ale tu to stále ničí. A pre túto tabuľku nie je možné vykonať špeciálnu optimalizáciu. To sa občas stáva. Toto je taká jemnosť, ktorú si málokto pamätá. A na tieto hrable sa ľahko šliape. Niekedy sa stane, že potrebujete nájsť prístup z druhej strany a napriek tomu sa zaobísť bez tohto nového indexu, alebo vytvoriť iný index, alebo iným spôsobom, napríklad, môžete použiť druhú metódu.
Ale toto je najoptimálnejšia stratégia, ako sa rozdeliť na dávky a strieľať na dávky s jednou požiadavkou, trochu vymazať atď.
Dlhé transakcie
Zablokované automatické vákuum -
problém s blokovaním -
Chyba #5 je veľká. Nikolai z Okmeter hovoril o monitorovaní Postgres. Ideálne monitorovanie Postgres, žiaľ, neexistuje. Niektorí sú bližšie, niektorí sú ďalej. Okmeter je dostatočne blízko k dokonalosti, ale veľa chýba a je potrebné pridať. Na to musíte byť pripravení.
Napríklad mŕtve n-tice sa najlepšie monitorujú. Ak máte v tabuľke veľa mŕtvych vecí, niečo nie je v poriadku. Je lepšie reagovať hneď, inak môže dôjsť k degradácii a môžeme si ľahnúť. To sa stáva.
Ak je tam veľké IO, tak je jasné, že to nie je dobré.
Dlhé transakcie tiež. Dlhé transakcie by na OLTP nemali byť povolené. A tu je odkaz na úryvok, ktorý vám umožňuje vziať tento úryvok a už sledovať dlhé transakcie.
Prečo sú dlhé transakcie zlé? Pretože všetky zámky sa uvoľnia až na konci. A všetkých poserieme. Navyše blokujeme automatické vákuum pre všetky stoly. Vôbec to nie je dobré. Aj keď máte na replike povolený pohotovostný režim, stále je to zlé. Všeobecne platí, že nikde nie je lepšie vyhnúť sa dlhým transakciám.
Ak máme veľa stolov, ktoré nie sú povysávané, potom musíme mať upozornenie. Tu je takáto situácia možná. Činnosť autovákua môžeme nepriamo ovplyvniť. Toto je úryvok z Avita, ktorý som mierne vylepšil. A ukázalo sa, že je to zaujímavý nástroj, ako zistiť, čo máme s autovakuom. Napríklad niektoré stoly tam čakajú a nebudú čakať, kým na ne príde rad. Tiež to musíte dať do monitorovania a mať upozornenie.
A vydáva bloky. Les blokových stromov. Rád si od niekoho niečo vezmem a vylepším. Tu som vzal skvelý rekurzívny CTE z Data Egret, ktorý ukazuje les zámkových stromov. Je to dobrý diagnostický nástroj. A na jeho základe sa dá postaviť aj monitoring. Ale to sa musí robiť opatrne. Musíte urobiť malý statement_timeout pre seba. A lock_timeout je žiaduci.
Niekedy sa všetky tieto chyby vyskytujú v súčte.
Tu je podľa mňa hlavná chyba organizačná. Je to organizačné, pretože technika neťahá. Toto je číslo 2 - skontrolovali na nesprávnom mieste.
Kontrolovali sme na nesprávnom mieste, pretože sme nemali produkčný klon, ktorý sa dá ľahko skontrolovať. Vývojár nemusí mať vôbec prístup k produkcii.
A skontrolovali sme tam nie. Keby sme to tam skontrolovali, sami by sme to videli. Vývojár to všetko videl aj bez DBA, ak to skontroloval v dobrom prostredí, kde je rovnaký objem dát a identická lokalita. Videl by celú túto degradáciu a hanbil by sa.
Viac o autovákue. Potom, čo sme urobili masívne zametanie niekoľkých miliónov riadkov, musíme ešte urobiť PREBALENIE. Toto je obzvlášť dôležité pre indexy. Keď tam všetko vyčistíme, budú sa cítiť zle.
A ak chcete vrátiť každodenné upratovacie práce, potom by som navrhoval robiť to častejšie, ale menšie. Môže to byť raz za minútu alebo trochu častejšie. A treba sledovať dve veci: či táto vec nemá chyby a nezaostáva. Trik, ktorý som ukázal, to vyrieši.
To, čo robíme, je open source. Je zverejnený na GitLab. A robíme to tak, aby ľudia mohli kontrolovať aj bez DBA. Robíme databázové laboratórium, to znamená, že voláme základný komponent, na ktorom Joe práve pracuje. A môžete si vziať kópiu výroby. Teraz existuje implementácia Joe for Slack, môžete tam povedať: „vysvetlite taký a taký dotaz“ a okamžite získate výsledok pre svoju kópiu databázy. Môžete tam dokonca VYMAZAŤ a nikto si to nevšimne.
Povedzme, že máte 10 terabajtov, robíme databázové laboratórium tiež 10 terabajtov. A so simultánnymi 10 terabajtovými databázami môže súčasne pracovať 10 vývojárov. Každý si môže robiť čo chce. Môže vymazať, zahodiť atď. To je taká fantázia. O tom sa porozprávame zajtra.
Toto sa nazýva tenké poskytovanie. Toto je jemné poskytovanie. Toto je nejaký druh fantázie, ktorý výrazne odstraňuje oneskorenia vo vývoji, v testovaní a robí svet v tomto smere lepším miestom. To znamená, že vám umožňuje vyhnúť sa problémom s hromadnými operáciami.
Príklad: 5 terabajtová databáza, získanie kópie za menej ako 30 sekúnd. A nezáleží ani na veľkosti, teda nezáleží na tom, koľko terabajtov.
Dnes môžete ísť do a kopať do našich nástrojov. Môžete sa zaregistrovať, aby ste videli, čo tam je. Môžete nainštalovať tohto robota. Je to zadarmo. Napíšte.
otázky
Veľmi často sa v reálnych situáciách ukazuje, že údajov, ktoré by mali zostať v tabuľke, je oveľa menej, ako je potrebné vymazať. To znamená, že v takejto situácii je často jednoduchšie implementovať takýto prístup, keď je jednoduchšie vytvoriť nový objekt, skopírovať tam iba potrebné údaje a uložiť starú tabuľku. Je jasné, že v tejto chvíli je potrebný programový prístup, zatiaľ čo budete prepínať. Aký je tento prístup?
Je to veľmi dobrý prístup a veľmi dobrá úloha. Je to veľmi podobné tomu, čo robí pg_repack, je to veľmi podobné tomu, čo musíte urobiť, keď vytvoríte ID 4 bajty. Mnoho rámcov to urobilo pred niekoľkými rokmi a práve platne vyrástli a je potrebné ich previesť na 8 bajtov.
Táto úloha je dosť náročná. Zvládli sme to. A musíte byť veľmi opatrní. Sú tam zámky atď. Ale robí sa to. To znamená, že štandardný prístup je použiť pg_repack. Deklarujete takéto označenie. A predtým, ako doň začnete nahrávať údaje o snímkach, deklarujete aj jeden štítok, ktorý sleduje všetky zmeny. Existuje trik, že niektoré zmeny možno ani nebudete sledovať. Existujú jemnosti. A potom prepínate postupnými zmenami. Nastane krátka prestávka, keď všetkých vypneme, ale vo všeobecnosti sa to robí.
Ak sa pozriete na pg_repack na GitHub, potom tam bola úloha previesť ID z int 4 na int 8, potom tu bol nápad použiť samotný pg_repack. To je tiež možné, ale je to trochu hack, ale bude to fungovať aj na toto. Môžete zasiahnuť do spúšťača, ktorý používa pg_repack, a povedať tam: "Tieto dáta nepotrebujeme", t.j. prenášame len to, čo potrebujeme. A potom už len prepne a je to.
S týmto prístupom stále získavame druhú kópiu tabuľky, v ktorej sú údaje už indexované a naskladané veľmi rovnomerne s krásnymi indexmi.
Nafukovanie nie je prítomné, je to dobrý prístup. Ale viem, že existujú pokusy vyvinúť na to automatizáciu, t.j. vytvoriť univerzálne riešenie. Môžem vám dať kontakt na túto automatizáciu. Je napísaný v Pythone, čo je dobrá vec.
Som len trochu zo sveta MySQL, tak som si to prišiel vypočuť. A my používame tento prístup.
Ale je to len vtedy, ak máme 90%. Ak máme 5%, tak to nie je veľmi dobré použiť.
Ďakujeme za správu! Ak neexistujú žiadne zdroje na vytvorenie úplnej kópie produktu, existuje nejaký algoritmus alebo vzorec na výpočet zaťaženia alebo veľkosti?
Dobrá otázka. Zatiaľ sme schopní nájsť viacterabajtové databázy. Aj keď hardvér tam nie je rovnaký, napríklad menej pamäte, menej procesora a disky nie sú úplne rovnaké, ale stále to robíme. Ak nie je absolútne nikde, musíte premýšľať. Nechajte ma premýšľať do zajtra, prišli ste, porozprávame sa, to je dobrá otázka.
Ďakujeme za správu! Najprv ste začali o tom, že existuje cool Postgres, ktorý má také a také obmedzenia, ale vyvíja sa. A to všetko je vo všeobecnosti barlička. Nie je to všetko v rozpore s vývojom samotného Postgresu, v ktorom sa objaví nejaký deferent DELETE alebo niečo iné, čo by malo držať na nízkej úrovni to, čo sa tu snažíme nejakými našimi podivnými prostriedkami pomaznať?
Ak sme v SQL povedali odstrániť alebo aktualizovať veľa záznamov v jednej transakcii, ako to tam môže Postgres distribuovať? V prevádzke sme fyzicky obmedzení. Ešte dlho to budeme robiť. A v tomto čase zamkneme atď.
Hotovo s indexmi.
Môžem predpokladať, že rovnaké ladenie kontrolných bodov by sa dalo zautomatizovať. Raz to môže byť. Ale potom naozaj nerozumiem otázke.
Otázkou je, či existuje taký vektor vývoja, ktorý ide sem a tam, a tu váš ide paralelne? Tie. Ešte nad tým nerozmýšľali?
Hovoril som o princípoch, ktoré sa dajú použiť teraz. Existuje ďalší robot , s týmto môžete vykonávať automatické ladenie kontrolných bodov. Bude to niekedy v Postgrese? Neviem, ešte sa o tom ani nehovorilo. Od toho máme ešte ďaleko. Ale sú vedci, ktorí vyrábajú nové systémy. A strčia nás do automatických indexov. Existuje vývoj. Môžete sa napríklad pozrieť na automatické ladenie. Parametre vyberá automaticky. Ten vám ale zatiaľ ladenie kontrolných bodov neurobí. To znamená, že bude zvyšovať výkon, vyrovnávaciu pamäť prostredia atď.
A na ladenie kontrolných bodov môžete urobiť toto: ak máte tisíc klastrov a rôzny hardvér, rôzne virtuálne stroje v cloude, môžete použiť nášho bota robiť automatizáciu. A max_wal_size sa vyberie podľa vašich cieľových nastavení automaticky. Ale zatiaľ to nie je ani zďaleka v jadre, bohužiaľ.
Dobrý deň Hovorili ste o nebezpečenstvách dlhých transakcií. Povedali ste, že autovakuum je zablokované v prípade vymazania. Ako nám ešte škodí? Pretože hovoríme skôr o uvoľnení priestoru a možnosti ho využiť. Čo nám ešte chýba?
Autovákuum tu možno nie je najväčší problém. A skutočnosť, že dlhá transakcia môže uzamknúť iné transakcie, je táto možnosť nebezpečnejšia. Môže a nemusí sa stretnúť. Ak sa stretla, tak to môže byť veľmi zlé. A s autovakuom - to je tiež problém. Pri dlhých transakciách v OLTP existujú dva problémy: zámky a automatické vákuovanie. A ak máte na replike zapnutú spätnú väzbu v pohotovostnom režime, tak na master dorazí aj autovakuový zámok, príde z repliky. Ale aspoň nebudú žiadne zámky. A budú lokše. Hovoríme o zmenách údajov, takže zámky sú tu dôležitým bodom. A ak je to všetko na dlhý, dlhý čas, potom je uzamknutých stále viac transakcií. Môžu kradnúť iných. A objavujú sa lok stromy. Poskytol som odkaz na úryvok. A tento problém sa stáva výraznejším rýchlejšie ako problém s autovakuom, ktoré sa môže len hromadiť.
Ďakujeme za správu! Svoju správu ste začali tým, že ste testovali nesprávne. Pokračovali sme v našej myšlienke, že musíme vziať rovnaké vybavenie, so základňou rovnakým spôsobom. Povedzme, že sme dali vývojárovi základ. A žiadosti vyhovel. A zdá sa, že je v poriadku. Ale on nekontroluje na živo, ale na živo máme napríklad záťaž 60-70%. A ak aj použijeme toto ladenie, tak to veľmi nefunguje.
Je dôležité mať v tíme odborníka a využívať expertov na DBA, ktorí dokážu predpovedať, čo sa stane so skutočným zaťažením pozadia. Keď sme práve previedli naše čisté zmeny, vidíme obrázok. Ale pokročilejší prístup, keď sme znova urobili to isté, ale so záťažou simulovanou výrobou. Je to celkom v pohode. Dovtedy musíš dospieť. Je to ako s dospelým. Pozreli sme sa len na to, čo máme a aj na to, či máme dostatok zdrojov. To je dobrá otázka.
Keď už robíme garbage select a máme napríklad vymazaný príznak
Toto robí automatické vákuum v Postgrese.
Oh, robí to?
Autovákuum je zberač odpadu.
Ďakujeme!
Ďakujeme za správu! Existuje možnosť okamžite navrhnúť databázu s rozdelením na oddiely tak, aby sa všetok odpad zašpinil z hlavnej tabuľky niekde nabok?
Samozrejme, že mám.
Je možné sa potom chrániť, ak sme zamkli stôl, ktorý by sa nemal používať?
Samozrejme, že mám. Ale je to ako otázka sliepky a vajíčka. Ak všetci vieme, čo sa stane v budúcnosti, potom, samozrejme, urobíme všetko v pohode. Ale biznis sa mení, sú tu nové kolónky, nové požiadavky. A potom – ups, chceme to odstrániť. Ale táto ideálna situácia sa v živote vyskytuje, ale nie vždy. Ale celkovo je to dobrý nápad. Stačí skrátiť a je to.
Zdroj: hab.com