Valamikor a távoli jövőben a szükségtelen adatok automatikus eltávolítása a DBMS egyik fontos feladata lesz [1]. Addig is nekünk magunknak kell gondoskodnunk a felesleges adatok törléséről vagy olcsóbb tárolórendszerekbe való áthelyezéséről. Tegyük fel, hogy több millió sor törlése mellett dönt. Meglehetősen egyszerű feladat, főleg ha ismert a feltétel és van megfelelő index. "DELETE FROM table1 WHERE col1 = :value" - mi lehetne egyszerűbb, igaz?
videók:
-
Az első évtől, azaz 2007-től vagyok a Highload programbizottság tagja.
-
És 2005 óta vagyok a Postgresnél. Sok projektben használták.
-
A csoport 2007 óta a RuPostgesnél is dolgozik.
-
2100+ résztvevőre nőttünk a Meetupon. Ez a második hely a világon New York után, már régen megelőzte San Franciscót.
-
Több éve élek Kaliforniában. Főleg amerikai cégekkel dolgozom, köztük nagyokkal is. Ők aktív Postgres felhasználók. És ott mindenféle érdekesség felmerül.
– ez az én cégem. A fejlesztési lassulásokat kiküszöbölő feladatok automatizálásával foglalkozunk.
Ha csinálsz valamit, néha vannak hibák a Postgres körül. Tegyük fel, hogy meg kell várnia, amíg az adminisztrátor megkapja a tesztpadot, vagy meg kell várnia, amíg a DBA válaszol Önnek. Ilyen szűk keresztmetszeteket pedig a fejlesztési, tesztelési és adminisztrációs folyamatban találunk, és automatizálással és új megközelítésekkel próbáljuk kiküszöbölni.
Nemrég a VLDB-n voltam Los Angelesben. Ez a legnagyobb adatbázis-konferencia. És volt egy jelentés, hogy a jövőben a DBMS-ek nem csak tárolják, hanem automatikusan törlik is az adatokat. Ez egy új téma.
Egyre több adat van a világon.A zetabájt 1 000 000 petabájt. És most már a becslések szerint több mint 100 zettabájtnyi adatot tárolunk a világon. És egyre többen vannak.
És mit kell vele csinálni? Egyértelmű, hogy törölni kell. Itt található egy link ehhez az érdekes jelentéshez. Ezt azonban ez idáig nem implementálták a DBMS-ben.
Azok, akik tudják, hogyan kell pénzt számolni, két dolgot akarnak. Azt akarják, hogy töröljük, ezért technikailag meg kell tudnunk tenni.
Amit ezután elmondok, az egy absztrakt szituáció, amely egy csomó valós helyzetet tartalmaz, vagyis egy bizonyos összeállítás arról, hogy mi is történt valójában velem és a környező adatbázisokkal sokszor, sok éven át. Gereblyék mindenhol vannak, és mindenki mindig rájuk lép.
Tegyük fel, hogy van egy vagy több bázisunk, amelyek növekszik. És néhány rekord nyilvánvaló szemét. Például a felhasználó elkezdett valamit ott csinálni, de nem fejezte be. És egy idő után tudjuk, hogy ezt a befejezetlen munkát már nem lehet tárolni. Vagyis szeretnénk néhány ócska dolgot kitakarítani, hogy helyet takarítsunk meg, javítsuk a teljesítményt stb.
Általánosságban elmondható, hogy a feladat bizonyos dolgok, konkrét sorok törlésének automatizálása egy táblázatban.
És van egy kérésünk, amiről ma beszélünk, vagyis a szemétszállításról.
Egy tapasztalt fejlesztőt kértünk meg erre. Elfogadta ezt a kérést, maga ellenőrizte – minden működik. Kipróbáltam a színpadon - minden rendben van. Kigurult - minden működik. Naponta egyszer lefutjuk ezt – minden rendben van.
Az adatbázis folyamatosan bővül és bővül. A napi DELETE valamivel lassabban kezd működni.
Aztán rájövünk, hogy most marketingcég vagyunk, és a forgalom többszöröse lesz, ezért úgy döntünk, hogy átmenetileg szüneteltetjük a felesleges dolgokat. És elfelejtjük visszaadni.
Néhány hónappal később emlékeztek. És az a fejlesztő kilépett, vagy valami mással volt elfoglalva, kijelöltek egy másikat, hogy küldje vissza.
Ellenőrizte a fejlesztőt, a bemutatót – minden rendben van. Természetesen még mindig meg kell takarítania, ami felhalmozódott. Megvizsgálta, minden működik.
Mi történik ezután? Aztán nekünk minden szétesik. Annyira leesik, hogy egy ponton minden leesik. Mindenki sokkos állapotban van, senki sem érti, mi történik. Aztán kiderül, hogy ez a TÖRLÉS volt a gond.
Valami elromlott? Itt van egy lista azokról a dolgokról, amelyek elromolhatnak. Ezek közül melyik a legfontosabb?
-
Például nem volt felülvizsgálat, vagyis a DBA szakértő nem nézett. Tapasztalt szemmel azonnal megtalálná a problémát, ráadásul hozzáfér a prod-hoz, ahol több millió sor halmozódott fel.
-
Lehet, hogy valamit rosszul ellenőriztek.
-
Lehet, hogy a hardver elavult, és frissítenie kell ezt az adatbázist.
-
Vagy valami nem stimmel magával az adatbázissal, és át kell lépnünk a Postgres-ről a MySQL-re.
-
Vagy lehet, hogy valami baj van a művelettel.
-
Lehet, hogy vannak hibák a munkaszervezésben, és valakit el kell bocsátani, és jobb embereket kell felvenni?
Nem volt DBA ellenőrzés. Ha lenne DBA, látná ezt a több millió sort, és még minden kísérlet nélkül is azt mondaná: „Ezt nem csinálják.” Tegyük fel, ha ez a kód a GitLab-ban, a GitHub-ban lenne, és volt egy kódellenőrzési folyamat, és nem volt olyan, hogy a DBA jóváhagyása nélkül ez a művelet prod-on megy végbe, akkor nyilvánvalóan a DBA azt mondaná: „Ezt nem teheti meg. ”
És azt mondaná, hogy gondok lesznek a lemez IO-val, és minden folyamat megbolondul, lehetnek zárak, és az autovákuumot is blokkolod egy csomó percig, szóval ez nem jó.
A második hiba, hogy rossz helyen ellenőriztek. Utána láttuk, hogy a prod-on sok szemét adat halmozódott fel, de a fejlesztőnek nem volt felhalmozott adata ebben az adatbázisban, és ezt a szemetet nem igazán hozta létre senki a színpadon. Ennek megfelelően 1 sor volt, amelyek gyorsan elkészültek.
Tisztában vagyunk vele, hogy tesztjeink gyengék, vagyis a felépített folyamat nem észleli a problémákat. Nem végeztek megfelelő DB-kísérletet.
Az ideális kísérletet lehetőleg ugyanazon a berendezésen kell elvégezni. Ez nem mindig lehetséges ugyanazon a hardveren, de nagyon fontos, hogy az adatbázis teljes méretű másolata legyen. Ezt prédikálom már több éve. És egy éve beszéltem erről, a YouTube-on meg lehet nézni az egészet.
Lehet, hogy rossz a felszerelésünk? Ha megnézed, a látencia megugrott. Láttuk, hogy az újrahasznosítás 100%-os. Persze ha ezek modern NVMe meghajtók lennének, akkor valószínűleg sokkal könnyebb dolgunk lenne. És talán nem feküdnénk le emiatt.
Ha felhők vannak, akkor a frissítés egyszerű. Új replikákat indítottunk el új hardveren. Átkapcsolás. És minden rendben van. Elég könnyű.
Meg lehet valahogy érinteni a kisebb lemezeket? És itt a DBA segítségével belemerülünk egy bizonyos témába, az úgynevezett checkpoint tuningba. Kiderült, hogy nem végeztünk ellenőrzőpont hangolást.
Mi az az ellenőrző pont? Ez bármely DBMS-ben elérhető. Amikor a memóriában lévő adatok megváltoznak, azok nem kerülnek azonnal lemezre. Az adatok megváltozott információi először a továbbítási naplóba kerülnek az előreírási naplóba. És egy bizonyos ponton a DBMS úgy dönt, hogy ideje a valódi oldalakat lemezre dobni, hogy ha meghibásodást tapasztalunk, kevesebbet tudjunk REDO-zni. Olyan, mint egy játék. Ha megölnek minket, akkor az utolsó ellenőrzőponttól kezdjük a játékot. És minden DBMS megvalósítja ezt.
A Postgres beállításai késnek. 10-15 éves adatmennyiségekhez és műveletekhez tervezték. És az ellenőrző pont sem kivétel.
Ez az információ a Postgres ellenőrzéssel, azaz az automatikus állapotellenőrzéssel végzett jelentésünkből származik. És itt van néhány terabájtnyi adatbázis. És nyilvánvaló, hogy az esetek csaknem 90%-ában kényszerűek az ellenőrzőpontok.
Mit jelent? Két beállítás van ott. Az ellenőrzőpont az időtúllépéskor, például 10 percen belül előfordulhat. Vagy akkor fordulhat elő, amikor elég sok adatot töltöttek ki.
És alapértelmezés szerint a max_wal_saze 1 gigabájtra van állítva. Valójában ez Postgresben 300-400 megabájt után történik meg. Nagyon sok adatot módosítottál, és van egy ellenőrzőpontod.
És ha senki nem tuningolt, de nőtt a szolgáltatás, és sok pénzt keres a cég, sok tranzakciója van, akkor az ellenőrzés percenként egyszer történik, néha 30 másodpercenként egyszer, és néha átfedik egymást . Ez nagyon rossz.
És gondoskodnunk kell arról, hogy ritkábban jöjjön el. Vagyis emelhetjük a max_wal_size-t. És ritkábban fog támadni.
De kidolgoztunk egy egész módszertant arra, hogyan lehet ezt helyesebben megtenni, vagyis hogyan hozzunk döntéseket a beállítások kiválasztásáról, egyértelműen konkrét adatok alapján.
Ennek megfelelően két adatbázis-kísérletsorozatot végzünk.
Első sorozat - megváltoztatjuk a max_wal_size-t. És hatalmas műveletet hajtunk végre. Először az alapértelmezett 1 gigabájt beállítással csináljuk. És egy hatalmas, sok millió sorból álló DELETE-t végzünk.
Láthatod, milyen nehéz ez nekünk. Látjuk, hogy a lemez IO nagyon rossz. Lássuk, mennyi WAL-t termeltünk, mert ez nagyon fontos. Nézzük meg, hányszor történt az ellenőrzőpont. És látjuk, hogy ez nem jó.
Ezután növeljük a max_wal_size-t. Ismételjük. Növelje, ismételje meg. És annyiszor. Elvileg jó a 10 pont, ahol 1, 2, 4, 8 gigabájt. És egy adott rendszer viselkedését nézzük. Nyilvánvaló, hogy a felszerelésnek olyannak kell lennie, mint a prod-on. Ugyanazoknak a lemezeknek, ugyanannyi memóriának és ugyanazoknak a Postgres-beállításoknak kell lenniük.
És így kicseréljük a rendszerünket, és tudjuk, hogy a DBMS hogyan fog viselkedni rossz tömeg esetén DELETE, hogyan ellenőrzi.
A Checkpoint oroszul ellenőrzési pontokat jelent.
Példa: Több millió sor törlése index szerint, a sorok „szétszórtak” az oldalak között.
Íme egy példa. Ez némi alap. A max_wal_size alapértelmezett 1 gigabájt beállításával pedig teljesen egyértelmű, hogy a rögzítéshez szükséges lemezeink a polcra kerülnek. Ez a kép egy nagyon beteg beteg tipikus tünete, vagyis tényleg rosszul érezte magát. És csak egy művelet volt, itt csak a DELETE több millió sorból.
Ha a prod-ban megengedik egy ilyen műveletet, akkor csak lezuhanunk, mert egyértelmű, hogy egy DELETE megöl minket a polcon.
Továbbá, ahol 16 gigabájt van, láthatja, hogy a fogak már elkezdtek megjelenni. A fogak már jobbak, azaz kopogunk a plafonon, de nem olyan rosszul. Megjelent ott egy kis szabadság. A jobb oldalon a felvétel látható. A műveletek száma pedig a második grafikon. És jól látszik, hogy a 16 gigabájttal már kicsit könnyebben lélegzünk.
Ahol pedig 64 gigabájt látszik, ott teljesen jobb lett. Már a fogak is jól láthatóak, több lehetőség van más műtétek túlélésére és a koronggal való tennivalóra.
Miért van ez?
Kicsit belemerülök a részletekbe, de ez a témakör az ellenőrzőpontok hangolásáról egy egész jelentést eredményezhet, így nem részletezem túl, de egy kicsit felvázolom, hogy milyen nehézségek vannak.
Ha túl gyakran fordul elő ellenőrző pont, és nem sorban frissítjük sorainkat, hanem index alapján keressük meg őket, ami jó, mert nem töröljük a teljes táblát, akkor előfordulhat, hogy először az első, majd az ezredik oldalt érintettük meg, majd visszatért az elsőhöz . És ha az első oldal látogatásai között az ellenőrzőpont már elmentette a lemezre, akkor újra el fogja menteni, mert másodszor is beszennyeztük.
És sokszor fogjuk kényszeríteni az ellenőrzőpont mentését. Mintha redundáns műveletek lennének rá.
De ez még nem minden. Postgresben az oldalak súlya 8 kilobájt, Linuxban pedig 4 kilobájt. És van egy full_page_writes beállítás. Alapértelmezés szerint engedélyezve van. És ez így is van így, mert ha kikapcsoljuk, fennáll a veszélye annak, hogy hiba esetén csak az oldal fele kerül mentésre.
A továbbítási napló WAL-jában lévő bejegyzés viselkedése olyan, hogy amikor van egy ellenőrzőpontunk és először változtatunk egy oldalt, akkor az egész oldal, azaz mind a 8 kilobájt a továbbítási naplóba kerül, bár mi csak megváltoztatott egy 100 bájt súlyú sort. És kénytelenek vagyunk az egész oldalt leírni.
A későbbi változtatásoknál csak egy adott sor lesz, de először mindent leírunk.
És ennek megfelelően, ha az ellenőrzőpont ismét megtörténik, akkor mindent elölről kell kezdenünk, és az egész oldalt be kell zsúfolni. Gyakori ellenőrzőpontoknál, amikor ugyanazokat az oldalakat járjuk végig, a full_page_writes = on nagyobb lesz, mint amilyen lehetne, azaz több WAL-t generálunk. Többet küldenek a replikákba, az archívumba, a lemezre.
És ennek megfelelően két elbocsátásunk van.
Ha növeljük a max_wal_size-t, akkor kiderül, hogy mind a checkpoint, mind a wal writer munkáját megkönnyítjük. És ez nagyszerű.
Telepítsünk egy terabájtot és éljünk vele. Mi a rossz benne? Ez rossz, mert meghibásodás esetén órákig felkelünk, mert régen volt az ellenőrző pont és már sok minden változott. És mindezért REDO-t kell tennünk. Ezért egy második kísérletsorozatot végzünk.
Elvégezzük a műveletet, és megnézzük, hogy az ellenőrzőpont közel áll a befejezéshez, szándékosan csinálunk egy -9 Postgres-t.
Utána pedig újraindítjuk, és meglátjuk, mennyi ideig tart ezen a berendezésen felemelkedni, vagyis mennyit tesz a REDO ebben a rossz helyzetben.
Kétszer is megjegyzem, rossz a helyzet. Először is, az ellenőrzőpont vége előtt elestünk, így sok vesztenivalónk van. Másodszor pedig volt egy hatalmas műtétünk. És ha az ellenőrzőpontoknak időkorlátja lett volna, akkor valószínűleg kevesebb WAL keletkezett volna az utolsó ellenőrzőpont óta. Vagyis ez egy kétszeres vesztes.
Ezt a helyzetet különböző max_wal_size-hez mérjük, és megértjük, hogy ha a max_wal_size 64 gigabájt, akkor duplán legrosszabb helyzetben 10 percig emelkedünk. És azt gondoljuk, hogy ez megfelel-e nekünk vagy sem. Ez üzleti kérdés. Meg kell mutatnunk ezt a képet az üzleti döntésekért felelősöknek, és fel kell tennünk a kérdést: „Hány időt várhatunk maximálisan probléma esetén? Lefeküdhetünk rosszabb helyzetben 3-5 percre?” És hozol egy döntést.
És itt van egy érdekes pont. Pár beszámolónk van Patroniról a konferencián. És lehet, hogy használod is. Ez a Postgres automatikus feladatátvétele. A GitLab és a Data Egret beszélt erről.
És ha van egy automatikus feladatátvételed, ami 30 másodpercen belül megtörténik, akkor talán le tudunk feküdni 10 percre? Mert ezen a ponton átváltunk a replikára, és minden rendben lesz. Ez egy vitatott kérdés. Nem tudok egyértelmű választ. Egyszerűen úgy érzem, hogy ez a téma nem csak a katasztrófaelhárításról szól.
Ha sokáig felépülünk egy kudarcból, akkor sok más helyzetben kényelmetlenül érezzük magunkat. Például ugyanazokban a kísérletekben, amikor csinálunk valamit, és néha 10 percet kell várnunk.
Még mindig nem mennék túl messzire, még akkor sem, ha van automatikus feladatátvételünk. Általános szabály, hogy az olyan értékek, mint a 64, 100 gigabájt, jó értékek. Néha még érdemes is kevesebbet választani. Általában véve ez egy finom tudomány.
Például a max_wal_size = 1, 8 ismétléséhez a tömeges műveletet sokszor meg kell ismételni. Megcsináltad. És ugyanazon az alapon szeretné újra megtenni, de már mindent törölt. Mit kell tenni?
Később elmondom a megoldásunkról, és arról, hogy mit teszünk az ilyen helyzetekben való ismétlődés érdekében. És ez a leghelyesebb megközelítés.
De ebben az esetben szerencsénk volt. Ha, ahogy itt van írva: „KEZDÉS, TÖRLÉS, VISSZÉRÍTÉS”, akkor megismételhetjük a TÖRLÉST. Vagyis ha mi magunk töröltük, akkor megismételhetjük. És fizikailag ott lesznek az adatai. Még csak nem is puffadsz. Iterálhat ilyen DELETE-en.
Ez a TÖRLÉS a ROLLBACK funkcióval ideális az ellenőrzőpontok hangolásához, még akkor is, ha nincs megfelelően telepített adatbázis-laboratóriuma.
Egy „i” oszlopos táblát készítettünk. A Postgres szolgáltatási oszlopokkal rendelkezik. Láthatatlanok, hacsak nem kérik külön. Ezek a következők: ctid, xmid, xmax.
A Ctid a fizikai cím. A nulla oldal, az első sor az oldalon.
Látható, hogy a ROOLBACK után a tuple ugyanazon a helyen maradt. Vagyis megpróbálhatjuk újra, ugyanúgy fog viselkedni. Ez a fő dolog.
Xmax a sor halálának ideje. Be van adva, de a Postgres tudja, hogy ezt a tranzakciót visszaállították, így nem számít, hogy 0 vagy visszavont tranzakció. Ez arra utal, hogy a DELETE használható a rendszer viselkedésének hatalmas műveleteinek ismétlésére és tesztelésére. Csinálhatsz adatbázis-laborokat a szegények számára.
Ez a programozókról szól. A DBA-val kapcsolatban is mindig szidják ezért a programozókat: „Miért csinálsz ilyen hosszú és nehéz műveleteket?” Ez egy teljesen más merőleges téma. Korábban adminisztráció volt, de most fejlesztés lesz.
Nyilvánvalóan nem bontottuk részekre. Ez egyértelmű. Lehetetlen egy ilyen DELETE-t több millió sorra részekre bontani. 20 percet vesz igénybe, és minden lefekszik. De sajnos még a tapasztalt fejlesztők is követnek el hibákat, még nagyon nagy cégeknél is.
Miért fontos a törés?
-
Ha azt látjuk, hogy kemény a lemez, akkor lassítsuk le. Ha pedig megtörtünk, akkor szüneteket tehetünk, lassíthatjuk a gázadást.
-
És nem fogunk sokáig blokkolni másokat. Bizonyos esetekben nem számít, ha valódi szemetet távolít el, amelyen senki sem dolgozik, akkor nagy valószínűséggel senkit nem fog blokkolni, kivéve az autovacuum munkáját, mert megvárja a tranzakció befejezését. De ha törölsz valamit, amit esetleg más kér, akkor letiltják, lesz valami láncreakció. Weboldalakon és mobilalkalmazásokon kerülni kell a hosszú tranzakciókat.
Ez érdekes. Gyakran látom, hogy a fejlesztők megkérdezik: „Milyen csomagméretet válasszak?”
Nyilvánvaló, hogy minél nagyobb a kötegméret, annál alacsonyabb a tranzakciós rezsi, azaz a tranzakciós többletköltség. Ugyanakkor ennek a tranzakciónak az ideje növekszik.
Van egy nagyon egyszerű szabályom: vegyél be minél többet, de ne lépd túl a másodpercenkénti végrehajtást.
Miért egy másodperc? A magyarázat nagyon egyszerű és mindenki számára érthető, még a nem technikusok számára is. Látjuk a reakciót. Vegyünk 50 milliszekundumot. Ha valami megváltozott, a szemünk reagálni fog. Ha kevesebb, akkor nehezebb. Ha valami 100 ezredmásodperc után válaszol, például kattintott az egérrel, és 100 ezredmásodperc után válaszolt, akkor már érzi ezt a kis késést. A másodpercet már fékként érzékelik.
Ennek megfelelően, ha tömegműveleteinket 10 másodperces sorozatokra osztjuk, akkor fennáll annak a veszélye, hogy blokkolunk valakit. És néhány másodpercig működni fog, és az emberek már észreveszik. Ezért inkább nem csinálom egy másodpercnél tovább. De ugyanakkor ne bontsa túl kicsire, mert a tranzakciós rezsi észrevehető lesz. Ez nehezebb lesz az alap számára, és számos egyéb probléma merülhet fel.
Kiválasztjuk a csomag méretét. Ezt minden esetben másként tehetjük meg. Automatizálható. És meg vagyunk győződve egy csomag feldolgozásának hatékonyságáról. Ez azt jelenti, hogy egy csomag TÖRLÉSE vagy FRISSÍTÉS.
Egyébként mindent, amit mondok, nem csak a DELETE-ről szól. Ahogy sejtette, ezek az adatok tömeges műveletei.
És látjuk, hogy a terv kiváló. Láthatja az index szkennelést, még jobb, ha csak az indexet. És van egy kis mennyiségű adatunk. És minden kevesebb, mint egy másodperc alatt működik. Szuper.
És még mindig meg kell győződnünk arról, hogy nincs degradáció. Előfordul, hogy az első tételeket gyorsan kidolgozzák, majd minden egyre rosszabb és rosszabb lesz. A folyamat olyan, hogy sokat kell tesztelni. Pontosan erre van szükség az adatbázis-laborokra.
És még mindig elő kell készítenünk valamit, hogy lehetővé tegye ennek helyes nyomon követését a gyártás során. Például beírhatjuk a naplóba az időt, megírhatjuk, hogy most hol tartunk, és kiket töröltünk. És ez lehetővé teszi számunkra, hogy később megértsük, mi történik. És ha valami elromlik, gyorsan keresse meg a problémát.
Ha ellenőriznünk kell a lekérdezések hatékonyságát, és sokszor kell iterálnunk, akkor létezik olyan, hogy egy társbot. Már készen van. Több tucat fejlesztő használja nap mint nap. És kérésre 30 másodperc alatt hatalmas terabájtos adatbázist tud biztosítani, az Ön saját példányát. És ott törölhet valamit, és azt mondja, hogy RESET, és újra törölheti. Így lehet vele kísérletezni. Ebben látom a jövőt. És ezt már tesszük.
Mik a particionálási stratégiák? Három különböző particionálási stratégiát látok, amelyeket a fejlesztők használnak a csomagon.
Az első nagyon egyszerű. Számszerű azonosítóval rendelkezünk. És bontsuk fel különböző intervallumokra, és dolgozzunk vele. A hátránya egyértelmű. Az első szegmensben lehet 100 sor valódi szemét, a másodikban 5 sor vagy egyáltalán nem, különben mind az 1 sor szemétnek bizonyul. Nagyon egyenetlen munka, de könnyen törhető. Elvették a maximális azonosítót és összetörték. Ez egy naiv megközelítés.
A második stratégia a kiegyensúlyozott megközelítés. A Gitlabban használják. Fogtuk és átkutattuk az asztalt. Megtaláltuk az azonosító csomagok határait, így minden csomag pontosan 10 000 rekordot tartalmazott. És beraktak valamiféle sorba. És dolgozunk tovább. Ezt több szálban is megteheti.
Az első stratégiában egyébként ezt több szálon is megteheti. Ez nem nehéz.
De van egy menőbb és optimálisabb megközelítés. Ez a harmadik stratégia. És ha lehetséges, jobb ezt választani. Ezt egy speciális index alapján tesszük. Ebben az esetben nagy valószínűséggel a szemétállapotunkon és az azonosítónkon alapuló index lesz. Az azonosítót beletesszük, hogy csak indexelés legyen, hogy ne menjünk a kupacba.
A csak indexvizsgálat általában gyorsabb, mint az indexvizsgálat.
És gyorsan megtaláljuk a törölni kívánt azonosítóinkat. A BATCH_SIZE elemet előre kiválasztjuk. És nem csak fogadjuk, hanem különleges módon fogadjuk és azonnal kijavítjuk. De úgy zárjuk le őket, hogy ha már zárva vannak, akkor ne zárjuk le, hanem menjünk tovább és vesszük a következőket. Ez a frissítés zárolva van. Ez a Postgres szuper funkció lehetővé teszi, hogy több szálban dolgozzunk, ha akarunk. Esetleg egy szálban. És akkor ott van a CTE - ez egy kérés. És valódi költöztetés történik ennek a CTE-nek a második emeletén - returning *. Visszaadhatja az azonosítót, de jobb *, ha az egyes sorokban kevés adat van.
Miért van erre szükségünk? Erre szükségünk van a jelentéshez. Valójában mostanra annyi sort töröltünk. És a mi határaink az ID vagy a Created_at alapján ilyenek. Megteheti min, max. Valami mást is lehet tenni. Sok mindent be lehet zsúfolni ide. És ez nagyon kényelmes a megfigyeléshez.
Még egy megjegyzés az indexről. Ha úgy döntünk, hogy ehhez a feladathoz speciális indexre van szükségünk, akkor ügyelnünk kell arra, hogy az ne rontsa el a kupac frissítéseket. Vagyis a Postgres rendelkezik ilyen statisztikákkal. Ez látható a tábla pg_stat_user_tables-jában. Megnézheti, hogy az aktuális frissítések használatban vannak-e vagy sem.
Vannak helyzetek, amikor az új index egyszerűen levágja őket. És az összes többi, már futó frissítés lelassul. Nem csak azért, mert megjelent az index (minden index egy kicsit lassítja a frissítéseket, de csak egy kicsit), de itt még mindig elrontja a dolgokat. Ehhez a táblázathoz pedig lehetetlen speciális optimalizálást végezni. Ez néha előfordul. Ez egy olyan finomság, amelyre kevesen emlékeznek. És könnyű rálépni erre a gereblyére. Néha megesik, hogy meg kell találnia a másik oldal megközelítését, és továbbra is nélkülöznie kell ezt az új indexet, vagy készítsen egy másik indexet, vagy tegyen valami mást, például használhatja a második módszert.
De ez a legoptimálisabb stratégia, hogyan lehet kötegekre bontani és egy kéréssel kötegekre lőni, egyszerre keveset törölni stb.
Hosszú tranzakciók -
Blokkolt autovákuum
Blokkolási probléma
Az 5-ös hiba nagy. Az okmeteri Nikolay a Postgres megfigyeléséről beszélt. Sajnos tökéletes Postgres felügyelet nem létezik. Van aki közelebb van, van aki távolabb. Az Okmeter elég közel van ahhoz, hogy tökéletes legyen, de sok hiányzik és hozzá kell tenni. Erre fel kell készülni.
Például jobb megfigyelni a halott sorokat. Ha sok halott cucc van az asztalon, akkor valami nincs rendben. Jobb, ha most reagálunk, különben ott leépülés lehet, és le tudunk feküdni. Megtörténik.
Ha nagy az IO, akkor egyértelmű, hogy ez nem jó.
Hosszú tranzakciók is. A hosszú tranzakciókat nem szabad engedélyezni az OLTP-n. És itt van egy link a kódrészlethez, amely lehetővé teszi, hogy ezt a részletet felhasználva már nyomon követhesse a hosszú tranzakciókat.
Miért rosszak a hosszú tranzakciók? Mert minden zárat csak a végén oldanak fel. És mindenkit bezárunk. Ráadásul minden asztalnál blokkoljuk az autovákuumot. Ez egyáltalán nem jó. Még akkor is rossz, ha a replikán engedélyezve van a forró készenlét. Általában mindenhol jobb elkerülni a hosszú tranzakciókat.
Ha sok asztalunk nincs porszívózva, akkor riasztást kell kapnunk. Itt is előfordulhat ilyen helyzet. Közvetve befolyásolhatjuk az autovákuum működését. Ez egy részlet az Avito-ból, amit kicsit javítottam. És érdekes eszköznek bizonyult, hogy megnézzük, mi van az autovákuummal. Például néhány asztal vár ott, és nem várják ki a sorukat. Azt is figyelni kell, és figyelmeztetni kell.
És blokkokat ad ki. Blokkoló fák erdeje. Szeretek elvenni valamit valakitől és javítani rajta. Itt vettem egy menő rekurzív CTE-t a Data Egret-től, amely egy záródó fák erdőjét mutatja. Ez jó dolog a diagnosztika szempontjából. És ennek alapján monitorozás is építhető. De ezt óvatosan kell megtenni. Egy kis nyilatkozatot_timeout kell készítened magadnak. A lock_timeout pedig kívánatos.
Néha ezek a hibák együtt fordulnak elő.
Véleményem szerint itt a szervezési hiba a legfontosabb. Szervezeti, mert a technológia nem működik. Ez a 2. szám – rossz helyen ellenőrizték.
Rossz helyen ellenőriztük, mert nem volt könnyen ellenőrizhető termelési klónunk. Előfordulhat, hogy a fejlesztő egyáltalán nem fér hozzá a termeléshez.
És rossz helyen ellenőriztük. Ha ott ellenőrizték volna, mi magunk is láttuk volna. Mindezt DBA nélkül is láthatta a fejlesztő, ha jó környezetben ellenőrizte, ahol ugyanannyi adat és azonos elrendezés van. Látta volna ezt a sok leépülést, és szégyellte volna.
Bővebben az autóporszívóról. Miután elvégeztünk egy hatalmas, több millió vonal tisztítását, még mindig el kell végeznünk az ÚJRACSOMAGOLÁST. Ez különösen fontos az indexeknél. Rosszul érzik magukat, miután ott mindent kitakarítottunk.
Ha pedig vissza szeretnéd hozni a lehúzás napi munkáját, akkor azt javaslom gyakrabban, de kisebb mértékben. Ez lehet percenként egyszer, vagy még gyakrabban egy kicsit. És két dolgot kell figyelnünk: hogy ebben a dologban ne legyenek hibák, és hogy ne maradjon le. Az általam bemutatott trükk segítségével megoldhatod ezt.
Amit csinálunk, az nyílt forráskódú. Ez a GitLab-on van közzétéve. És ezt úgy tesszük, hogy az emberek DBA nélkül is ellenőrizhessenek. Csinálunk egy adatbázis-labort, vagyis meghívjuk azt az alapkomponenst, amelyen Joe éppen dolgozik. És megragadhat egy példányt a gyártásról. Most van a Joe for slack implementációja, ott azt mondhatja: „magyarázza meg ezt és ezt a kérést”, és azonnal megkapja az eredményt az adatbázis másolatához. Ott akár a DELETE-t is megteheti, és senki sem veszi észre.
Tegyük fel, hogy 10 terabájtja van, egy adatbázis-labort készítünk, szintén 10 terabájtot. És 10 fejlesztő dolgozhat egyidejűleg egyidejűleg 10 terabájtos adatbázisokkal. Mindenki azt csinál, amit akar. Lehet törölni, eldobni stb. Ez fantasztikus. Erről holnap beszélünk.
Ezt vékony kiépítésnek nevezik. Ez egy finom kiépítés. Ez egyfajta fantázia, amely nagymértékben kiküszöböli a fejlesztési és tesztelési késéseket, és jobb hellyé teszi a világot ebből a szempontból. Vagyis ez csak lehetővé teszi a tömeges műveletekkel kapcsolatos problémák elkerülését.
Példa: 5 terabájtos adatbázis, egy másolat beszerzése kevesebb, mint 30 másodperc alatt. És még csak nem is a mérettől függ, vagyis nem mindegy, hány terabájt.
Ma már mehetsz és beleássunk a szerszámainkba. Regisztrálhat és megnézheti, mi van ott. Ezt a botot telepítheted magadnak. Ez ingyenes. Ír.
kérdések
Valós helyzetekben nagyon gyakran kiderül, hogy a táblázatban maradó adatok sokkal kevesebbek, mint amennyit törölni kell. Vagyis ilyen helyzetben sokszor könnyebb ezt a megközelítést megvalósítani, amikor egyszerűbb új objektumot létrehozni, csak a szükséges adatokat másolni oda és átírni a régi táblát. Nyilvánvaló, hogy ebben a pillanatban szoftveres megközelítésre van szüksége a váltás során. Milyen ez a megközelítés?
Ez egy nagyon jó megközelítés és egy nagyon jó feladat. Nagyon hasonló ahhoz, amit a pg_repack csinál, nagyon hasonló ahhoz, amit akkor kell tenned, amikor az emberek azonosítása 4 bájtosra nőtt. Sok keretrendszer megtette ezt néhány évvel ezelőtt, és a lemezek most nőttek nagyobbra, és 8 bájtosra kell konvertálni őket.
Ez a feladat meglehetősen nehéz. Megcsináltuk. És nagyon óvatosnak kell lennie. Vannak zárak, stb. De kész. Vagyis a standard megközelítés a pg_repack használata. Ön egy ilyen jelet hirdet. És mielőtt elkezdené feltölteni a pillanatképadatokkal, deklaráljon egy táblázatot is, amely nyomon követi az összes változást. Van egy trükk, hogy bizonyos változásokat nem is követhetsz nyomon. Vannak finomságok. Aztán váltasz, és bevezeted a változtatásokat. Rövid szünet következik, amikor mindenkit bezárunk, de összességében ez megtörténik.
Ha megnézed a pg_repack-et a GitHubon, akkor amikor volt egy feladat, hogy az azonosítót int 4-ről int 8-ra konvertáld, akkor volt egy ötlet, hogy magát a pg_repack-et használd. Ez is lehetséges, de ez egy kicsit hacker módszer, de erre is bejön. Beavatkozhat a pg_repack parancsot használó triggerbe, és azt mondhatja: „Nincs szükségünk ezekre az adatokra”, azaz csak azt továbbítjuk, amire szükségünk van. Aztán csak vált, és ennyi.
Ezzel a megközelítéssel megkapjuk a táblázat második példányát is, amelyben az adatok már indexelve vannak, és nagyon simán, gyönyörű indexekkel vannak elhelyezve.
Nem, ez egy jó megközelítés. De azt tudom, hogy erre vannak kísérletek automatizálást, azaz univerzális megoldást készíteni. Bemutathatom ezt az automatizálást. Pythonban van írva, jó dolog.
Csak egy kicsit vagyok a MySQL világából, ezért jöttem, hogy meghallgatjam. És ezt a megközelítést alkalmazzuk.
De ez csak akkor van, ha megvan a 90%. Ha van 5%, akkor nem túl jó használni.
Köszönöm a beszámolót! Ha nincsenek erőforrások a prod teljes másolatának elkészítéséhez, van-e algoritmus vagy képlet a terhelés vagy a méret kiszámítására?
Jó kérdés. Eddig több terabájtos adatbázisokat tudunk találni. Még ha nem is ugyanaz a hardver, pl kevesebb memória, kevesebb processzor és nem is teljesen egyformák a lemezek, akkor is csináljuk. Ha egyáltalán nincs sehol, akkor gondolkodni kell rajta. Hadd gondolkodjak holnapig, eljöttél, megbeszéljük, ez jó kérdés.
Köszönöm a beszámolót! Először arról kezdtél beszélni, hogy van egy menő Postgres, aminek vannak ilyen-olyan korlátai, de fejlődik. És ez az egész nagyjából mankó. Mindez nem mond ellent magának a Postgres fejlődésének, amelyben valamiféle DELETE deferent jelenik meg, vagy valami más, aminek alacsony szinten kellene tartania azt, amit itt a saját furcsa eszközeinkkel próbálunk leplezni?
Ha az SQL-ben azt mondtuk, hogy egy tranzakció során sok rekordot töröljünk vagy frissítsünk, akkor hogyan tudja ezt a Postgres terjeszteni? Fizikailag korlátozottak vagyunk a műveletekben. Még sokáig ezt fogjuk csinálni. És ilyenkor zárni fogunk stb.
Ugyanezt tették az indexekkel is.
Feltételezem, hogy ugyanaz az ellenőrzőpont hangolás automatizálható. Egyszer ez megtörténhet. De akkor nem igazán értem a kérdést.
A kérdés a következő: van-e olyan fejlődési vektor, amely pontosan oda megy, és itt párhuzamosan megy a tiéddel? Azok. Még nem gondolnak rá?
A most használható elvekről beszéltem. Van egy másik bot is , ezzel automatizált ellenőrzőpont hangolást végezhet. Megtörténik ez valaha Postgresben? Nem tudom, erről még nem is beszélnek. Ettől még messze vagyunk. De vannak tudósok, akik új rendszereket készítenek. És betolnak minket az automatikus indexekbe. Vannak fejlemények. Például megnézheti az automatikus hangolást. Automatikusan kiválasztja a paramétereket. De még nem végez ellenőrzőpont hangolást helyetted. Vagyis kiválasztja a teljesítményt, a shell puffert stb.
Az ellenőrzőpontok hangolásához pedig a következőt teheted: ha ezer klasztered és különböző hardvered, különböző virtuális géped van a felhőben, használhatod a robotunkat. automatizálást készíteni. A max_wal_size automatikusan kiválasztásra kerül a célbeállításoknak megfelelően. De ez egyelőre még közel sincs a kernelhez, sajnos.
Jó napot Ön beszélt a hosszú tranzakciók veszélyeiről. Azt mondtad, hogy törlés esetén az autovákuum le van tiltva. Hogyan árt ez még nekünk? Mert inkább a hely felszabadításáról és annak használatáról beszélünk. Mit veszíthetünk még?
Lehet, hogy az autovákuum itt nem a legnagyobb probléma. És az a tény, hogy egy hosszú tranzakció blokkolhat más tranzakciókat, veszélyesebb lehetőség. Lehet, hogy találkozik, vagy nem. Ha találkozik, a dolgok nagyon rosszak lehetnek. És az autovákuumnál ez is probléma. Két probléma van az OLTP hosszú tranzakcióival: zárak és autovákuum. Ha pedig a replikán engedélyezve van a hot standby visszacsatolás, akkor az autovákuumos blokkolás is megérkezik a masterhez, az a replikából érkezik. De ott legalább nem lesznek zárak. És itt lesznek zárak. Adatváltozásokról beszélünk, ezért itt a zárak fontos szempontok. És ha ez így megy sokáig, akkor egyre több tranzakciót blokkolnak. Csapdába csalhatnak másokat. És megjelennek a zárfák. Adtam egy linket a részlethez. És ez a probléma gyorsan észrevehetőbbé válik, mint az autovákuum problémája, amely csak felhalmozódhat.
Köszönöm a beszámolót! A jelentését azzal kezdte, hogy helytelenül tesztelt. Folytattuk az elképzelésünket, hogy ugyanazt a berendezést kell venni, pontosan ugyanazzal az alappal. Tegyük fel, hogy a fejlesztőnek adtunk egy alapot. És eleget is tett a kérésnek. És úgy tűnik, jól van. De nem élőben ellenőrzi, hanem például élőben a terhelésünk 60-70%. És még ha ezt a tuningot használjuk is, nem sikerül túl jól
Fontos, hogy legyen egy szakértő a csapatában, és olyan DBA-szakértőket használjon, akik meg tudják jósolni, mi fog történni valós háttérterhelés mellett. Amikor egyszerűen áthajtottuk a tiszta változásainkat, látjuk a képet. De egy fejlettebb megközelítés az volt, amikor újra megcsináltuk ugyanezt, de szimulált gyártási terhelés mellett. Ez teljesen klassz. Addig még fel kell nőnünk. Érett. Pusztán azt néztük, amink van, és azt is megnéztük, hogy van-e elég forrásunk. Ez egy jó kérdés.
Amikor már szemétválogatást végzünk, és van például egy törölt jelzőnk
Ezt teszi az autovacuum automatikusan a Postgresben.
Ó, ő ezt csinálja?
Az autovákuum a szemétgyűjtő.
Köszönöm!
Köszönöm a beszámolót! Van olyan lehetőség, hogy azonnal megtervezzünk egy adatbázist particionálással úgy, hogy az összes szemetet eltávolítsák a főtábláról valahol oldalra?
Természetesen van.
Meg tudjuk-e védeni magunkat, ha bezártunk egy asztalt, amelyet nem szabad használni?
Természetesen van. De ez tyúk-tojás kérdés. Ha mindannyian tudjuk, mi fog történni a jövőben, akkor természetesen mindent nagyszerűen fogunk csinálni. De az üzlet változik, új oszlopok és új kérések jelennek meg. És akkor - hoppá, törölni akarjuk. De ez egy ideális helyzet, előfordul az életben, de nem mindig. De összességében jó ötlet. Csak csonkold és ennyi.
Forrás: will.com