Někdy ve vzdálené budoucnosti bude automatické odstraňování nepotřebných dat jedním z důležitých úkolů SŘB [1]. Mezitím se my sami musíme postarat o mazání nebo přesun nepotřebných dat do levnějších úložných systémů. Řekněme, že se rozhodnete smazat několik milionů řádků. Docela jednoduchý úkol, zvláště pokud je známa podmínka a existuje vhodný index. "DELETE FROM table1 WHERE col1 = :value" - co by mohlo být jednodušší, že?
Video:
-
V programovém výboru Highload jsem od prvního roku, tedy od roku 2007.
-
A v Postgresu jsem od roku 2005. Použito v mnoha projektech.
-
Skupina s RuPostges také od roku 2007.
-
Na Meetupu jsme se rozrostli na 2100+ účastníků. Je druhý na světě po New Yorku, dlouho ho předběhlo San Francisco.
-
Několik let žiji v Kalifornii. Jednám spíše s americkými firmami, včetně velkých. Jsou aktivními uživateli Postgresu. A jsou tam nejrůznější zajímavosti.
je moje společnost. Zabýváme se automatizací úloh, které eliminují zpomalení vývoje.
Pokud něco děláte, pak se někdy kolem Postgresu objeví nějaké zátky. Řekněme, že musíte počkat, až vám admin nastaví testovací stanoviště, nebo musíte počkat, až vám odpoví DBA. A taková úzká místa v procesu vývoje, testování a administrace nacházíme a snažíme se je odstranit pomocí automatizace a nových přístupů.
Nedávno jsem byl na VLDB v Los Angeles. Jedná se o největší konferenci o databázích. A objevila se zpráva, že v budoucnu bude DBMS nejen ukládat, ale také automaticky mazat data. Toto je nové téma.
Ve světě zettabajtů je stále více dat – to je 1 000 000 petabajtů. A nyní se již odhaduje, že máme na světě uloženo více než 100 zettabajtů dat. A je jich čím dál tím víc.
A co s tím dělat? Je zřejmé, že je třeba ji odstranit. Zde je odkaz na tuto zajímavou zprávu. Ale zatím to nebylo implementováno v DBMS.
Kdo umí počítat peníze, chce dvě věci. Chtějí, abychom smazali, takže technicky bychom to měli být schopni udělat.
Co povím příště, je nějaká abstraktní situace, která zahrnuje hromadu reálných situací, tedy jakýsi sestřih toho, co se mi a okolním databázím vlastně stalo mnohokrát, mnoho let. Hrábě jsou všude a všichni na ně neustále šlapou.
Řekněme, že máme základnu nebo několik základen, které rostou. A některé záznamy jsou evidentně svinstvo. Uživatel tam například začal něco dělat, ale nedokončil to. A po nějaké době víme, že tento nedodělek již nelze uložit. To znamená, že bychom chtěli vyčistit nějaké odpadky, abychom ušetřili místo, zlepšili výkon atd.
Obecně je úkolem automatizovat mazání konkrétních věcí, konkrétních řádků v nějaké tabulce.
A máme takový požadavek, o kterém si dnes povíme, tedy o odvozu odpadků.
Požádali jsme o to zkušeného vývojáře. Vzal tuto žádost, zkontroloval ji pro sebe - vše funguje. Vyzkoušeno na staging - vše v pořádku. Rozbaleno - vše funguje. Jednou denně to spustíme - vše je v pořádku.
Databáze roste a roste. Denní DELETE začne fungovat trochu pomaleji.
Pak jsme pochopili, že teď máme marketingovou společnost a návštěvnost bude několikanásobně větší, takže se rozhodneme dočasně pozastavit nepotřebné věci. A zapomeňte se vrátit.
O několik měsíců později si vzpomněli. A ten vývojář skončil nebo je zaneprázdněn něčím jiným a dal pokyn jinému, aby to vrátil.
Zkontroloval na vývoji, na stagingu - vše je v pořádku. Přirozeně musíte stále uklidit, co se nahromadilo. Zkontroloval, že vše funguje.
Co se stane dál? Pak se nám všechno rozpadne. Klesá tak, že v určitém okamžiku všechno spadne. Všichni jsou v šoku, nikdo nechápe, co se děje. A pak se ukáže, že věc byla v tomto DELETE.
Něco se pokazilo? Zde je seznam toho, co se mohlo pokazit. Která z nich je nejdůležitější?
-
Například neexistovala žádná recenze, tj. expert DBA se na to nepodíval. Zkušeným okem by problém okamžitě našel a kromě toho má přístup k produ, kde se nahromadilo několik milionů řádků.
-
Možná něco špatně zkontrolovali.
-
Možná je hardware zastaralý a budete muset tuto základnu upgradovat.
-
Nebo je něco špatně se samotnou databází a musíme přejít z Postgresu na MySQL.
-
Nebo je možná s operací něco špatně.
-
Možná jsou nějaké chyby v organizaci práce a potřebujete někoho vyhodit a najmout ty nejlepší lidi?
Neproběhla žádná kontrola DBA. Kdyby existoval DBA, viděl by těchto několik milionů řádků a i bez jakýchkoli experimentů by řekl: "To nedělají." Předpokládejme, že kdyby tento kód byl v GitLabu, GitHubu a existoval by proces kontroly kódu a neexistovala by žádná taková věc, že by bez schválení DBA tato operace probíhala na prod, pak by DBA samozřejmě řekl: „To nelze udělat .“
A řekl by, že budeš mít problémy s IO disku a všechny procesy se zblázní, můžou tam být zámky a taky si zablokuješ autovakuum na hromadu minut, takže to není dobré.
Druhá chyba - kontrolovali na špatném místě. Poté jsme viděli, že se na produktu nahromadilo mnoho nevyžádaných dat, ale vývojář v této databázi nashromážděná data neměl a nikdo tento nevyžádaný obsah během stagingu nevytvořil. V souladu s tím bylo 1 000 řádků, které rychle fungovaly.
Chápeme, že naše testy jsou slabé, to znamená, že vytvořený proces nezachycuje problémy. Nebyl proveden adekvátní DB experiment.
Ideální experiment se přednostně provádí na stejném zařízení. Není to vždy možné provést na stejném zařízení, ale je velmi důležité, aby to byla kopie databáze v plné velikosti. To je to, co kážu již několik let. A před rokem jsem o tom mluvil, můžete to všechno sledovat na YouTube.
Možná je naše vybavení špatné? Když se podíváte, tak latence vyskočila. Viděli jsme, že využití je 100 %. Samozřejmě, pokud by se jednalo o moderní NVMe disky, pak by to pro nás bylo pravděpodobně mnohem jednodušší. A možná bychom z toho neulehli.
Pokud máte mraky, pak se upgrade snadno provede tam. Vyrostl nové repliky na novém hardwaru. přepnout. A vše je v pořádku. Velice jednoduché.
Dá se nějak dotknout menších disků? A zde se právě s pomocí DBA ponoříme do určitého tématu zvaného ladění kontrolních bodů. Ukázalo se, že jsme neměli ladění kontrolních bodů.
Co je kontrolní bod? Je v každém DBMS. Když máte v paměti data, která se mění, nejsou okamžitě zapsána na disk. Informace o změně dat se nejprve zapíše do protokolu pro předběžný zápis. A v určitém okamžiku se DBMS rozhodne, že je čas uložit skutečné stránky na disk, takže pokud dojde k selhání, můžeme dělat méně REDO. Je to jako hračka. Pokud jsme zabiti, začneme hru od posledního kontrolního bodu. A všechny DBMS to implementují.
Nastavení v Postgresu pokulhávají. Jsou určeny pro 10-15 let staré objemy dat a transakcí. A checkpoint není výjimkou.
Zde jsou informace z naší kontrolní zprávy Postgres, tedy automatické kontroly stavu. A tady je nějaká databáze o několika terabajtech. A je dobře vidět, že v téměř 90% případů vynucené checkpointy.
Co to znamená? Jsou tam dvě nastavení. Kontrolní bod může přijít časovým limitem, například za 10 minut. Nebo to může přijít, když je vyplněno poměrně hodně dat.
A ve výchozím nastavení je max_wal_saze nastaveno na 1 gigabajt. Ve skutečnosti se to opravdu děje v Postgresu po 300-400 megabajtech. Změnili jste tolik dat a dojde k vašemu kontrolnímu bodu.
A pokud to nikdo nevyladil a služba rostla a firma vydělává hodně peněz, má hodně transakcí, tak kontrolní bod přichází jednou za minutu, někdy za 30 sekund a někdy se i překrývají. To je dost špatné.
A musíme zajistit, aby to přicházelo méně často. To znamená, že můžeme zvýšit max_wal_size. A bude to přicházet méně často.
Vyvinuli jsme ale celou metodiku, jak to udělat správněji, tedy jak se rozhodnout o výběru nastavení, jasně na základě konkrétních dat.
V souladu s tím provádíme dvě série experimentů s databázemi.
První série - změníme max_wal_size. A děláme masivní operaci. Nejprve to uděláme s výchozím nastavením 1 gigabajt. A děláme masivní DELETE mnoha milionů řádků.
Vidíte, jak je to pro nás těžké. Vidíme, že IO disku je velmi špatné. Podíváme se na to, kolik WAL jsme vygenerovali, protože to je velmi důležité. Podívejme se, kolikrát se kontrolní bod stal. A vidíme, že to není dobré.
Dále zvýšíme max_wal_size. opakujeme. Zvyšujeme, opakujeme. A tolikrát. V zásadě je dobrých 10 bodů, kde 1, 2, 4, 8 gigabajtů. A podíváme se na chování konkrétního systému. Je jasné, že zde by vybavení mělo být jako na prod. Musíte mít stejné disky, stejné množství paměti a stejné nastavení Postgres.
A tímto způsobem vyměníme náš systém a víme, jak se bude DBMS chovat v případě špatného hromadného DELETE, jak bude kontrolní bod.
Checkpoint v ruštině jsou kontrolní body.
Příklad: DELETE několik milionů řádků podle indexu, řádky jsou „rozházené“ po stránkách.
Zde je příklad. Tohle je nějaká základna. A s výchozím nastavením 1 gigabajt pro max_wal_size je zcela jasné, že naše disky jdou do police pro nahrávání. Tento obrázek je typickým příznakem velmi nemocného pacienta, to znamená, že se opravdu cítil špatně. A byla tam jedna jediná operace, bylo tam jen DELETE několika milionů řádků.
Pokud je taková operace povolena v prod, tak budeme jen ležet, protože je jasné, že jedno DELETE nás zabije v poličce.
Dále, kde je 16 gigabajtů, je jasné, že zuby již odešly. Zuby už jsou lepší, to znamená, že se klepeme o strop, ale ne tak špatně. Byla tam určitá svoboda. Vpravo je záznam. A počet operací - druhý graf. A je jasné, že už se nám při 16 gigabajtech dýchá o něco snáz.
A kde je vidět 64 gigabajtů, že se to úplně zlepšilo. Už jsou zuby výrazné, je více příležitostí přežít další operace a něco s diskem udělat.
Proč tomu tak je?
Trochu se ponořím do detailů, ale z tohoto tématu, jak provádět ladění kontrolních bodů, může vzniknout celá zpráva, takže nebudu moc načítat, ale trochu nastíním, jaké jsou tam potíže.
Pokud se kontrolní bod vyskytuje příliš často a my aktualizujeme naše řádky ne sekvenčně, ale najdeme podle indexu, což je dobré, protože nesmažeme celou tabulku, pak se může stát, že jsme se nejprve dotkli první stránky, poté tisíciny, a pak se vrátil k prvnímu. A pokud mezi těmito návštěvami první stránky už to checkpoint uložil na disk, tak to uloží znovu, protože jsme to zašpinili podruhé.
A donutíme kontrolní bod, aby to mnohokrát uložil. Jak by pro něj byly nadbytečné operace.
Ale to není vše. Stránky mají 8 kilobajtů v Postgresu a 4 kilobajty v Linuxu. A je zde nastavení full_page_writes. Ve výchozím nastavení je povoleno. A to je správně, protože když to vypneme, tak hrozí, že se při pádu uloží jen půlka stránky.
Chování zápisu do WAL dopředného protokolu je takové, že když máme kontrolní bod a poprvé změníme stránku, dostane se do dopředného protokolu celá stránka, tedy všech 8 kilobajtů, ačkoliv jsme změnili pouze řádek, který váží 100 bajtů. A musíme si zapsat celou stránku.
V následných změnách bude pouze konkrétní n-tice, ale poprvé zapisujeme vše.
A pokud by se tedy kontrolní bod opakoval, musíme vše začít znovu od začátku a tlačit celou stránku. Při častých kontrolních bodech, když procházíme stejnými stránkami, bude full_page_writes = on více, než by mohlo být, tj. generujeme více WAL. Více se posílá do replik, do archivu, na disk.
A v důsledku toho máme dvě propouštění.
Pokud zvýšíme max_wal_size, ukáže se, že to usnadníme jak checkpointu, tak wal Writeru. A to je skvělé.
Vložme terabajt a žijme s ním. co je na tom špatného? To je špatné, protože v případě neúspěchu budeme lézt hodiny, protože kontrola byla dávno a už se hodně změnilo. A to všechno musíme udělat REDO. A tak děláme druhou sérii experimentů.
Provedeme operaci a uvidíme, až bude kontrolní bod dokončen, záměrně zabijeme -9 Postgres.
A potom to znovu spustíme a uvidíme, jak dlouho to bude na tomto zařízení stoupat, tedy jak moc se to v této špatné situaci REDO.
Dvakrát podotýkám, že situace je špatná. Nejprve jsme havarovali těsně před koncem kontroly, takže máme hodně co ztratit. A za druhé jsme měli masivní operaci. A pokud by kontrolní body měly časový limit, pak by se s největší pravděpodobností od posledního kontrolního bodu vygenerovalo méně WAL. To znamená, že je to dvojitý propadák.
Takovou situaci měříme pro různé velikosti max_wal_size a chápeme, že pokud je max_wal_size 64 gigabajtů, pak ve dvojnásobném nejhorším případě budeme stoupat 10 minut. A přemýšlíme, jestli nám to vyhovuje nebo ne. Toto je obchodní otázka. Musíme tento obrázek ukázat těm, kteří jsou zodpovědní za obchodní rozhodnutí, a zeptat se: „Jak dlouho můžeme maximálně ležet v případě problému? Můžeme si v nejhorší situaci 3-5 minut lehnout? A vy se rozhodnete.
A tady je zajímavý bod. Na konferenci máme několik zpráv o Patroni. A možná to používáte. Toto je autofailover pro Postgres. GitLab a Data Egret o tom hovořili.
A pokud máte autofailover, který přijde za 30 sekund, pak si možná můžeme lehnout na 10 minut? Protože v tuto chvíli přejdeme na repliku a vše bude v pořádku. To je sporný bod. Neznám jasnou odpověď. Jen mám pocit, že toto téma se netýká pouze obnovy po haváriích.
Pokud nás po neúspěchu čeká dlouhé zotavování, pak se budeme cítit nepříjemně v mnoha jiných situacích. Například ve stejných experimentech, kdy něco děláme a někdy musíme čekat 10 minut.
Stále bych nešel příliš daleko, i když máme autofailover. Hodnoty jako 64, 100 gigabajtů jsou zpravidla dobré hodnoty. Někdy se dokonce vyplatí vybírat méně. Obecně se jedná o jemnou vědu.
Chcete-li provést iterace, například max_wal_size =1, 8, musíte hromadnou operaci mnohokrát opakovat. Dokázal jsi to. A na stejném základě to chcete udělat znovu, ale už jste vše smazali. Co dělat?
Později budu mluvit o našem řešení, co děláme, abychom v takových situacích opakovali. A to je ten nejsprávnější přístup.
Ale v tomto případě jsme měli štěstí. Pokud, jak je zde napsáno „BEGIN, DELETE, ROLLBACK“, můžeme DELETE opakovat. To znamená, že pokud jsme to sami zrušili, tak to můžeme zopakovat. A fyzicky u vás budou data ležet na stejném místě. Nemáš ani nadýmání. Přes taková DELETE můžete iterovat.
Toto DELETE with ROLLBACK je ideální pro ladění kontrolních bodů, i když nemáte správně nasazené databázové laboratoře.
Vyrobili jsme desku s jedním sloupkem "i". Postgres má sloupce utility. Jsou neviditelní, pokud o ně není výslovně požádáno. Jsou to: ctid, xmid, xmax.
Ctid je fyzická adresa. Nulová stránka, první n-tice na stránce.
Je vidět, že po ROOLBACK zůstala n-tice na stejném místě. To znamená, že to můžeme zkusit znovu, bude se to chovat stejně. To je hlavní.
Xmax je čas smrti n-tice. Bylo to orazítkováno, ale Postgres ví, že transakce byla vrácena zpět, takže nezáleží na tom, zda je 0 nebo je to vrácená transakce. To naznačuje, že je možné iterovat přes DELETE a zkontrolovat hromadné operace chování systému. Můžete udělat databázové laboratoře pro chudé.
Tohle je o programátorech. Také o DBA za to programátory vždy nadávají: „Proč děláte tak dlouhé a obtížné operace?“. To je úplně jiné kolmé téma. Dříve byla administrativa a nyní bude vývoj.
Je zřejmé, že jsme se nerozbili na kusy. To je jasné. Takové DELETE pro hromadu milionů řádků nelze nerozbít na části. Bude se to dělat 20 minut a všechno si lehne. Ale bohužel i zkušení vývojáři dělají chyby, a to i ve velmi velkých společnostech.
Proč je důležité se zlomit?
-
Pokud vidíme, že je disk tvrdý, tak ho zpomalme. A pokud jsme rozbití, pak můžeme přidat pauzy, můžeme zpomalit škrcení.
-
A ostatní ještě dlouho blokovat nebudeme. V některých případech to nevadí, pokud mažete skutečný odpad, na kterém nikdo nepracuje, pak s největší pravděpodobností nezablokujete nikoho kromě práce s autovakuem, protože bude čekat na dokončení transakce. Ale pokud odstraníte něco, co může někdo jiný požadovat, pak bude zablokován, dojde k nějaké řetězové reakci. Na webových stránkách a mobilních aplikacích je třeba se vyhnout dlouhým transakcím.
To je zajímavé. Často vidím, že se vývojáři ptají: „Jakou velikost balení si mám vybrat?“.
Je jasné, že čím větší je velikost balíčku, tím menší je transakční režie, tedy dodatečná režie z transakcí. Zároveň se ale prodlužuje čas této transakce.
Mám velmi jednoduché pravidlo: vezměte si tolik, kolik můžete, ale nepřekračujte počet spustitelných souborů za sekundu.
Proč vteřinu? Vysvětlení je velmi jednoduché a srozumitelné všem, i netechnickým lidem. Vidíme reakci. Vezměme si 50 milisekund. Pokud se něco změní, naše oko zareaguje. Když méně, tak obtížněji. Pokud něco odpoví po 100 milisekundách, například jste klikli myší, a ono vám odpovědělo po 100 milisekundách, toto malé zpoždění již cítíte. Vteřina je již vnímána jako brzda.
Pokud tedy naše hromadné operace rozložíme na 10sekundové dávky, pak máme riziko, že někoho zablokujeme. A bude to pár sekund fungovat a lidé si toho už všimnou. Proto raději nedělám víc než vteřinu. Zároveň to však nerozbíjejte velmi jemně, protože režie transakce bude patrná. Základna bude tvrdší a mohou nastat další různé problémy.
Vybíráme velikost balení. V každém případě to můžeme udělat jinak. Lze automatizovat. A jsme přesvědčeni o efektivitě zpracování jednoho balení. To znamená, že provedeme DELETE jednoho balíčku nebo UPDATE.
Mimochodem, vše, o čem mluvím, není jen o DELETE. Jak jste uhodli, jedná se o jakékoli hromadné operace s daty.
A vidíme, že plán je skvělý. Můžete vidět index scan, index only scan je ještě lepší. A máme k dispozici malé množství dat. A méně než sekunda se splní. Super.
A stále se musíme ujistit, že nedochází k degradaci. Stává se, že první balení rychle vyjdou a pak je to horší, horší a horší. Proces je takový, že musíte hodně testovat. Přesně k tomu slouží databázové laboratoře.
A ještě musíme něco připravit, aby nám to umožnilo to ve výrobě správně dodržet. Do logu můžeme zapsat například čas, můžeme napsat, kde se právě nacházíme a koho jsme nyní smazali. A to nám umožní pochopit, co se děje později. A pokud se něco pokazí, rychle najděte problém.
Pokud potřebujeme zkontrolovat efektivitu požadavků a potřebujeme je mnohokrát opakovat, pak existuje něco jako kolega bot. Už je připravený. Denně jej využívají desítky vývojářů. A ví, jak poskytnout obrovskou terabajtovou databázi na vyžádání za 30 sekund, vaši vlastní kopii. A můžete tam něco smazat a říct RESET a zase to smazat. Můžete s tím takto experimentovat. V tomhle vidím budoucnost. A už to děláme.
Co jsou to rozdělovací strategie? Vidím 3 různé strategie rozdělení, které používají vývojáři v balíčku.
První z nich je velmi jednoduchý. Máme číselné ID. A pojďme si to rozdělit na různé intervaly a pracovat s tím. Nevýhoda je jasná. V prvním segmentu můžeme mít 100 řádků skutečného odpadu, ve druhém 5 řádků nebo vůbec, nebo se všech 1 000 řádků ukáže jako smetí. Velmi nerovnoměrná práce, ale snadno se zlomí. Vzali maximální ID a rozbili ho. To je naivní přístup.
Druhou strategií je vyvážený přístup. Používá se v Gitlabu. Vzali a prohlédli stůl. Našli jsme hranice ID balíčků tak, že každý balíček měl přesně 10 000 záznamů. A postavit je do fronty. A pak zpracováváme. Můžete to udělat ve více vláknech.
Mimochodem, v první strategii to můžete udělat také v několika vláknech. Není to složité.
Ale existuje chladnější a lepší přístup. Toto je třetí strategie. A když je to možné, je lepší si to vybrat. Děláme to na základě speciálního indexu. V tomto případě to bude s největší pravděpodobností index podle našeho stavu odpadu a ID. Zahrneme ID tak, aby se jednalo pouze o skenování indexu, abychom nešli na hromadu.
Obecně je pouze indexové skenování rychlejší než indexové skenování.
A rychle najdeme svá ID, která chceme odstranit. BATCH_SIZE vybíráme předem. A nejenže je získáváme, získáváme je speciálním způsobem a hned je hackneme. My ale zamykáme tak, že když už jsou zamčené, tak je nezamykáme, ale jdeme dál a bereme další. Toto je pro aktualizaci přeskočení uzamčeno. Tato super funkce Postgresu nám umožňuje pracovat v několika vláknech, pokud chceme. Je to možné v jednom proudu. A tady je CTE - to je jeden požadavek. A ve druhém patře tohoto CTE probíhá skutečné mazání - returning *. Můžete vrátit ID, ale je to lepší *pokud nemáte na každém řádku mnoho dat.
Proč to potřebujeme? To je to, co musíme hlásit. Nyní jsme ve skutečnosti smazali tolik řádků. A máme hranice podle ID nebo podle created_at takhle. Můžete udělat min, max. Dá se udělat něco jiného. Dá se tu nacpat hodně. A to je velmi výhodné pro sledování.
K indexu je ještě jedna poznámka. Pokud se rozhodneme, že pro tento úkol potřebujeme speciální index, pak se musíme ujistit, že nekazí aktualizace haldy pouze n-tic. To znamená, že Postgres má takové statistiky. To lze vidět v pg_stat_user_tables pro vaši tabulku. Můžete vidět, zda se používají horké aktualizace nebo ne.
Jsou situace, kdy je váš nový index může jednoduše odříznout. A máte všechny ostatní aktualizace, které již fungují, zpomalte. Nejen proto, že se objevil index (každý index trochu, ale trochu zpomaluje aktualizace), ale tady to stále kazí. A pro tuto tabulku není možné provést speciální optimalizaci. To se občas stává. To je taková jemnost, kterou si málokdo pamatuje. A na toto hrábě se snadno šlape. Někdy se stane, že potřebujete najít přístup z druhé strany a přesto se obejít bez tohoto nového indexu, nebo vytvořit jiný index, nebo jiným způsobem, například můžete použít druhou metodu.
Ale to je nejoptimálnější strategie, jak se rozdělit na dávky a střílet po dávkách s jedním požadavkem, trochu mazat atd.
Dlouhé transakce
Zablokované autovakuum -
problém s blokováním -
Chyba #5 je velká. Nikolai z Okmeter hovořil o monitorování Postgres. Ideální monitoring Postgres bohužel neexistuje. Někdo je blíž, někdo dál. Okmeter je dost blízko k dokonalosti, ale hodně toho chybí a je třeba to přidat. Na to musíte být připraveni.
Například mrtvé n-tice se nejlépe sledují. Pokud máte v tabulce hodně mrtvých věcí, pak je něco špatně. Je lepší reagovat hned, jinak může dojít k degradaci a můžeme si lehnout. Stalo se to.
Pokud je tam velké IO, tak je jasné, že to není dobré.
Také dlouhé transakce. Dlouhé transakce by na OLTP neměly být povoleny. A zde je odkaz na úryvek, který vám umožní vzít tento úryvek a již provádět nějaké sledování dlouhých transakcí.
Proč jsou dlouhé transakce špatné? Protože všechny zámky se uvolní až na konci. A nasereme všechny. Navíc blokujeme automatické vakuování pro všechny stoly. Není to vůbec dobré. I když máte na replice povolený pohotovostní režim, je to stále špatné. Obecně platí, že nikde není lepší vyhnout se dlouhým transakcím.
Pokud máme mnoho stolů, které nejsou vysáté, musíme mít upozornění. Zde je taková situace možná. Činnost autovakua můžeme nepřímo ovlivnit. Toto je úryvek z Avita, který jsem mírně vylepšil. A ukázalo se, že je to zajímavý nástroj, jak zjistit, co máme s autovakuem. Některé stoly tam například čekají a nebudou čekat, až na ně přijde řada. Také to musíte dát do monitorování a mít upozornění.
A vydává bloky. Les blokových stromů. Rád si od někoho něco vezmu a vylepším. Zde jsem vzal skvělý rekurzivní CTE z Data Egret, který ukazuje les zámkových stromů. Je to dobrý diagnostický nástroj. A na jeho základě lze postavit i monitoring. Ale to musí být provedeno opatrně. Musíte si udělat malý statement_timeout pro sebe. A lock_timeout je žádoucí.
Někdy se všechny tyto chyby vyskytují v součtu.
Zde je podle mě hlavní chyba organizační. Je to organizační, protože technika netáhne. Toto je číslo 2 - zkontrolovali na špatném místě.
Kontrolovali jsme na špatném místě, protože jsme neměli produkční klon, který lze snadno zkontrolovat. Vývojář nemusí mít vůbec přístup k produkci.
A tam jsme nekontrolovali. Kdybychom to tam zkontrolovali, sami bychom to viděli. Vývojář to všechno viděl i bez DBA, pokud to zkontroloval v dobrém prostředí, kde je stejné množství dat a identické umístění. Viděl by celou tu degradaci a styděl by se.
Více o autovakuu. Poté, co jsme provedli masivní zametání několika milionů řádků, stále musíme provést PŘEBALENÍ. To je důležité zejména pro indexy. Budou se cítit špatně, až tam všechno uklidíme.
A pokud chcete vrátit každodenní úklidové práce, pak bych navrhoval dělat to častěji, ale menší. Může to být jednou za minutu nebo i trochu častěji. A je potřeba hlídat dvě věci: aby tato věc neměla chyby a nezaostávala. Trik, který jsem ukázal, to vyřeší.
To, co děláme, je open source. Je to zveřejněno na GitLabu. A děláme to tak, aby lidé mohli kontrolovat i bez DBA. Děláme databázové laboratoře, to znamená, že voláme základní komponentu, na které Joe právě pracuje. A můžete si vzít kopii výroby. Nyní existuje implementace Joe for slack, můžete tam říci: „vysvětlete ten a ten požadavek“ a okamžitě získáte výsledek pro vaši kopii databáze. Můžete tam dokonce VYMAZAT a nikdo si toho nevšimne.
Řekněme, že máte 10 terabajtů, uděláme databázovou laboratoř také 10 terabajtů. A se současnými 10 terabajtovými databázemi může 10 vývojářů pracovat současně. Každý si může dělat, co chce. Může mazat, dropovat atd. To je taková fantazie. Budeme o tom mluvit zítra.
Tomu se říká tenké zajišťování. Toto je jemné poskytování. Jedná se o jakýsi druh fantazie, který výrazně odstraňuje zpoždění ve vývoji, v testování a dělá svět v tomto ohledu lepším místem. To znamená, že vám to jen umožňuje vyhnout se problémům s hromadnými operacemi.
Příklad: 5 terabajtová databáze, získání kopie za méně než 30 sekund. A nezáleží ani na velikosti, tedy na počtu terabajtů.
Dnes můžete jít do a kopat do našich nástrojů. Můžete se zaregistrovat, abyste viděli, co tam je. Můžete nainstalovat tohoto robota. Je to zdarma. Napsat.
otázky
Velmi často se v reálných situacích ukazuje, že dat, která by měla v tabulce zůstat, je mnohem méně, než je potřeba smazat. To znamená, že v takové situaci je často jednodušší implementovat takový přístup, kdy je snazší vytvořit nový objekt, zkopírovat tam pouze potřebná data a zabalit starou tabulku. Je jasné, že pro tuto chvíli je potřeba programový přístup, zatímco budete přepínat. Jaký je tento přístup?
To je velmi dobrý přístup a velmi dobrý úkol. Je to velmi podobné tomu, co dělá pg_repack, je to velmi podobné tomu, co musíte udělat, když uděláte ID 4 bajty. Mnoho frameworků to udělalo před několika lety a právě desky vyrostly a je třeba je převést na 8 bajtů.
Tento úkol je poměrně obtížný. Dokázali jsme to. A musíte být velmi opatrní. Jsou tam zámky atd. Ale dělá se to. To znamená, že standardní přístup je použít pg_repack. Deklarujete takové označení. A než do něj začnete nahrávat data snímků, deklarujete také jeden štítek, který sleduje všechny změny. Existuje trik, že některé změny možná ani nebudete sledovat. Existují jemnosti. A pak přepnete postupnými změnami. Nastane krátká pauza, kdy všechny zavřeme, ale obecně se to dělá.
Když se podíváte na pg_repack na GitHubu, tak tam, když byl úkol převést ID z int 4 na int 8, pak přišel nápad použít samotný pg_repack. I to je možné, ale je to trochu hack, ale i na tohle to půjde. Můžete zasáhnout do spouštěče, který pg_repack používá, a říct tam: „Tato data nepotřebujeme“, tj. přenášíme jen to, co potřebujeme. A pak se prostě přepne a je to.
S tímto přístupem stále získáváme druhou kopii tabulky, ve které jsou data již indexována a naskládána velmi rovnoměrně s krásnými indexy.
Nafouknutí není přítomno, je to dobrý přístup. Ale vím, že existují pokusy vyvinout pro to automatizaci, tedy vytvořit univerzální řešení. Mohu vám dát kontakt na tuto automatizaci. Je to napsané v Pythonu, což je dobrá věc.
Jsem jen trochu ze světa MySQL, tak jsem si přišel poslechnout. A my používáme tento přístup.
Ale je to jen v případě, že máme 90 %. Pokud máme 5 %, tak to není moc dobré používat.
Díky za zprávu! Pokud neexistují žádné zdroje pro vytvoření úplné kopie produktu, existuje nějaký algoritmus nebo vzorec pro výpočet zatížení nebo velikosti?
Dobrá otázka. Zatím jsme schopni najít víceterabajtové databáze. I když hardware tam není stejný, například méně paměti, méně procesoru a disky nejsou úplně stejné, ale přesto to děláme. Pokud není absolutně nikde, musíte přemýšlet. Nech mě přemýšlet do zítřka, přišel jsi, promluvíme si, to je dobrá otázka.
Díky za zprávu! Nejprve jste začali o tom, že existuje skvělý Postgres, který má taková a taková omezení, ale vyvíjí se. A to všechno je vesměs berlička. Není to vše v rozporu s vývojem samotného Postgresu, ve kterém se objeví nějaký deferent DELETE nebo něco jiného, co by mělo držet na nízké úrovni to, co se tady snažíme nějakými našimi podivnými prostředky namazat?
Pokud jsme v SQL řekli odstranit nebo aktualizovat mnoho záznamů v jedné transakci, jak to tam může Postgres distribuovat? V provozu jsme fyzicky omezeni. Ještě dlouho to budeme dělat. A v tuto dobu zamykáme atd.
Hotovo s indexy.
Mohu předpokládat, že stejné ladění kontrolních bodů by mohlo být automatizováno. Jednou to může být. Pak ale moc nerozumím otázce.
Otázkou je, jestli existuje takový vektor vývoje, který jde sem a tam, a tady ten váš jde paralelně? Tito. Ještě o tom nepřemýšleli?
Mluvil jsem o principech, které lze nyní použít. Existuje další bot , s tímto můžete provádět automatické ladění kontrolních bodů. Bude to někdy v Postgresu? Nevím, ještě se o tom ani nemluvilo. K tomu jsme ještě daleko. Ale jsou vědci, kteří vytvářejí nové systémy. A strkají nás do automatických indexů. Existuje vývoj. Můžete se například podívat na automatické ladění. Parametry vybírá automaticky. Doladění kontrolních bodů vám ale zatím dělat nebude. To znamená, že bude zvyšovat výkon, vyrovnávací paměť prostředí atd.
A pro ladění kontrolních bodů můžete udělat toto: pokud máte tisíc clusterů a jiný hardware, různé virtuální stroje v cloudu, můžete použít našeho bota dělat automatizaci. A max_wal_size bude vybrána podle vašeho cílového nastavení automaticky. Ale zatím to není ani zdaleka v jádru, bohužel.
Dobré odpoledne Mluvil jste o nebezpečí dlouhých transakcí. Řekl jste, že autovakuum je blokováno v případě mazání. Jak nám ještě škodí? Protože nám jde spíše o to, abychom uvolnili prostor a mohli jej využívat. Co nám ještě chybí?
Autovakuum zde možná není největší problém. A skutečnost, že dlouhá transakce může uzamknout další transakce, je tato možnost nebezpečnější. Může a nemusí se potkat. Pokud se setkala, pak to může být velmi špatné. A s autovakuem - to je také problém. S dlouhými transakcemi v OLTP jsou dva problémy: zámky a autovakuum. A pokud máš na replice povolenou zpětnou vazbu v pohotovostním režimu, tak na masteru stejně dostaneš autovakuový zámek, ten dorazí z repliky. Ale aspoň nebudou žádné zámky. A budou lokše. Mluvíme o změnách dat, takže zámky jsou zde důležitým bodem. A pokud je to vše na dlouhou, dlouhou dobu, pak je zablokováno více a více transakcí. Mohou krást ostatní. A objevují se lok stromy. Dal jsem odkaz na úryvek. A tento problém se stává znatelnějším rychleji než problém s autovakuem, který se může pouze hromadit.
Díky za zprávu! Svou zprávu jste zahájili tím, že jste testovali nesprávně. Pokračovali jsme v naší myšlence, že musíme vzít stejné vybavení, se základnou stejným způsobem. Řekněme, že jsme dali vývojáři základ. A žádosti vyhověl. A zdá se, že je v pořádku. Ten ale nekontroluje na živo, ale na živě máme např. zátěž 60-70%. A i když toto ladění použijeme, moc to nefunguje.
Je důležité mít v týmu odborníka a využívat odborníky na DBA, kteří dokážou předpovědět, co se stane se skutečným zatížením na pozadí. Když jsme právě provedli naše čisté změny, vidíme obrázek. Ale pokročilejší přístup, kdy jsme udělali to samé znovu, ale se zátěží simulovanou s výrobou. Je to docela v pohodě. Do té doby musíš dospět. Je to jako dospělý. Jen jsme se podívali na to, co máme a také na to, zda máme dostatek zdrojů. To je dobrá otázka.
Když už děláme garbage select a máme např. smazaný příznak
To je to, co autovakuum dělá automaticky v Postgresu.
Oh, dělá to?
Autovakuum je sběrač odpadků.
Děkujeme!
Díky za zprávu! Existuje možnost okamžitě navrhnout databázi s rozdělením tak, aby se veškerý odpad zašpinil z hlavní tabulky někam na stranu?
Samozřejmě existuje.
Je možné se potom chránit, když jsme zamkli stůl, který by se neměl používat?
Samozřejmě že ano. Ale je to jako otázka slepice a vejce. Pokud všichni víme, co se bude dít v budoucnu, tak samozřejmě vše uděláme v pohodě. Obchod se ale mění, jsou nové kolonky, nové požadavky. A pak – jejda, chceme to odstranit. Ale tato ideální situace v životě nastává, ale ne vždy. Ale celkově je to dobrý nápad. Stačí zkrátit a je to.
Zdroj: www.habr.com