Irgendwann an der wäiter Zukunft ass d'automatesch Entfernung vun onnéidege Donnéeën eng vun de wichtegen Aufgabe vum DBMS [1]. An der Tëschenzäit musse mir eis selwer këmmeren fir onnéideg Daten op manner deier Späichersystemer ze läschen oder ze verschécken. Loosst d'soen Dir decidéiert e puer Millioune Zeile ze läschen. Eng zimlech einfach Aufgab, besonnesch wann d'Konditioun bekannt ass an e passenden Index gëtt. "LÄSCHEN VUN Table1 WOU col1 =: Wäert" - wat kéint méi einfach sinn, richteg?
Video:
-
Ech sinn zënter dem éischte Joer am Highload Programmkomitee, also zënter 2007.
-
An ech sinn zënter 2005 bei Postgres. Benotzt et a ville Projeten.
-
Grupp mat RuPostges och zënter 2007.
-
Mir sinn op 2100+ Participanten op Meetup gewuess. Dëst ass déi zweet Plaz op der Welt no New York, déi San Francisco viru laanger Zäit iwwerholl huet.
-
Ech hu fir e puer Joer a Kalifornien gelieft. Ech beschäftegen mech méi mat amerikanesche Firmen, dorënner grouss. Si sinn aktiv Benotzer vu Postgres. An et ginn all Zorte vun interessant Saachen.
- dëst ass meng Firma. Mir sinn am Geschäft fir Aufgaben ze automatiséieren déi Entwécklungsbremsen eliminéieren.
Wann Dir eppes maacht, da ginn et heiansdo eng Aart vu Stecker ronderëm Postgres. Loosst eis soen datt Dir musst waarden bis den Administrateur en Teststand fir Iech opstellt, oder Dir musst waarden op d'DBA fir Iech ze reagéieren. A mir fannen esou Flaschenhalsen am Entwécklungs-, Test- an Administratiounsprozess a probéieren se mat der Hëllef vun der Automatisatioun an neien Approchen ze eliminéieren.
Ech war viru kuerzem um VLDB zu Los Angeles. Dëst ass déi gréisste Datebankkonferenz. An et gouf e Bericht, datt an Zukunft DBMSs net nëmmen Daten späicheren, awer och automatesch läschen. Dëst ass en neit Thema.
Et gëtt ëmmer méi Daten an der Welt vun Zettabytes - dat sinn 1 Petabytes. An elo gëtt scho geschat datt mir méi wéi 000 Zettabytes vun Daten op der Welt gespäichert hunn. An et ginn ëmmer méi vun hinnen.
A wat maache mat deem? Et ass kloer datt et muss geläscht ginn. Hei ass e Link op dësen interessante Bericht. Awer bis elo ass dëst net am DBMS ëmgesat ginn.
Déi, déi Suen ziele kënnen, wëllen zwou Saachen. Si wëllen datt mir läschen, also technesch solle mir et kënne maachen.
Wat ech nächst wäert erzielen ass eng abstrakt Situatioun déi eng Rëtsch vun realen Situatiounen enthält, dat heescht eng gewëssen Zesummesetzung vun deem wat tatsächlech mat mir an den Ëmgéigend Datenbanken vill Mol, vill Joer geschitt ass. Rakes sinn iwwerall a jidderee trëppelt se déi ganzen Zäit.
Loosst eis soen datt mir eng Basis hunn oder e puer Basen déi wuessen. An e puer records sinn offensichtlech Dreckstipp. Zum Beispill huet de Benotzer ugefaang eppes do ze maachen, awer huet et net fäerdeg gemaach. A no enger Zäit wësse mer datt dëst ongeschloss net méi kann gespäichert ginn. Dat ass, mir wëllen e puer Dreck Saachen botzen fir Plaz ze spueren, Leeschtung ze verbesseren, etc.
Am Allgemengen ass d'Aufgab d'Entfernung vu spezifesche Saachen ze automatiséieren, spezifesch Linnen an enger Tabell.
A mir hunn esou eng Demande, iwwer déi mir haut schwätzen, dat heescht iwwer Müllentfernung.
Mir hunn en erfuerene Entwéckler gefrot dëst ze maachen. Hien huet dës Demande geholl, et selwer iwwerpréift - alles funktionnéiert. Getest op der Inszenéierung - alles ass gutt. Gerullt et - alles funktionnéiert. Eemol am Dag lafe mir et - alles ass gutt.
D'Datebank wiisst a wiisst. Deeglech DELETE fänkt e bësse méi lues ze schaffen.
Da verstinn mir datt mir elo eng Marketingfirma hunn an de Traffic e puer Mol méi grouss ass, sou datt mir décidéieren fir onnéideg Saachen temporär ze pausen. A vergiessen zréck.
E puer Méint méi spéit hu si sech erënnert. An deen Entwéckler huet opginn oder war mat eppes anescht beschäftegt, si hunn en aneren zougewisen fir et zréckzeginn.
Hien huet op Dev gepréift, op der Inszenéierung - alles ass OK. Natierlech musst Dir nach ëmmer botzen wat gesammelt ass. Hien huet gepréift, alles funktionnéiert.
Wat geschitt dann? Da fällt alles fir eis aus. Et fällt sou datt iergendwann alles erof fält. Jiddereen ass am Schock, kee versteet wat geschitt. An da stellt sech eraus datt d'Saach an dësem DELETE war.
Gouf eppes falsch? Hei ass eng Lëscht vu wat kéint falsch goen. Wéi eng vun dësen ass déi wichtegst?
-
Zum Beispill gouf et keng Iwwerpréiwung, also den DBA Expert huet et net gekuckt. Hie géif de Problem direkt mat engem erfuerene Auge fannen, an ausserdeem huet hien Zougang zu Prod, wou sech e puer Millioune Linnen accumuléiert hunn.
-
Vläicht hu se eppes falsch gepréift.
-
Vläicht ass d'Hardware aktuell an Dir musst dës Basis upgraden.
-
Oder eppes ass falsch mat der Datebank selwer, a mir musse vu Postgres op MySQL réckelen.
-
Oder vläicht ass et eppes falsch mat der Operatioun.
-
Vläicht ginn et e puer Feeler an der Organisatioun vun der Aarbecht an Dir musst een entloossen a besser Leit astellen?
Et gouf keng DBA Scheck. Wann et eng DBA wier, géif hien dës e puer Millioune Linnen gesinn an och ouni Experimenter soen: "Si maachen dat net." Ugeholl, wann dëse Code am GitLab, GitHub wier an et géif e Code Iwwerpréiwungsprozess ginn an et wier näischt sou datt ouni d'Zustimmung vun der DBA dës Operatioun op Prod stattfënnt, da géif selbstverständlech d'DBA soen: "Dëst kann net gemaach ginn. ".
An hie géif soen datt Dir Probleemer mat Disk IO wäert hunn an all Prozesser wäerte verréckt ginn, et kann Spären sinn, an Dir wäert och Autovakuum fir e puer Minutten blockéieren, also ass dëst net gutt.
Den zweete Feeler - si hunn op der falscher Plaz gepréift. Mir hunn no der Tatsaach gesinn datt vill Junkdaten op Prod gesammelt hunn, awer den Entwéckler huet keng Daten an dëser Datebank gesammelt, a keen huet dëse Junk wärend der Staging erstallt. Deementspriechend goufen et 1 Linnen, déi séier geklappt hunn.
Mir verstinn datt eis Tester schwaach sinn, dat heescht, de Prozess deen gebaut gëtt, fënnt keng Probleemer. Eng adäquat DB Experiment war net gesuergt.
En idealen Experiment soll am léifsten op der selwechter Ausrüstung duerchgefouert ginn. Et ass net ëmmer méiglech dëst op der selwechter Hardware ze maachen, awer et ass ganz wichteg datt et eng vollgréisst Kopie vun der Datebank ass. Dëst ass wat ech säit e puer Joer gepriedegt hunn. An virun engem Joer hunn ech doriwwer geschwat, Dir kënnt alles op YouTube kucken.
Vläicht ass eis Ausrüstung schlecht? Wann Dir kuckt, da sprang d'Latenz. Mir hunn gesinn datt de Recycling 100% war. Natierlech, wann dës modern NVMe Drive waren, da wier et wahrscheinlech vill méi einfach fir eis. A vläicht géife mir net dowéinst leien.
Wann Dir Wolleken hutt, da gëtt den Upgrade einfach do gemaach. Opgehuewe nei replicas op der neier Hardware. ëmsetzen. An alles ass gutt. Zimlech einfach.
Ass et méiglech iergendwéi déi méi kleng Disken ze beréieren? An hei, just mat der Hëllef vun DBA, dauche mir an e bestëmmt Thema genannt Checkpoint Tuning. Et stellt sech eraus datt mir keng Checkpoint Tuning haten.
Wat ass e Kontrollpunkt? Dëst ass verfügbar an all DBMS. Wann Dir Daten an der Erënnerung hutt déi ännert, ginn se net direkt op Disk geschriwwe. Informatioun datt d'Donnéeën geännert hunn ass fir d'éischt an de Forward Log geschriwwe ginn, am Write-ahead Log. An iergendwann entscheet d'DBMS datt et Zäit ass déi richteg Säiten op Disk ze werfen, sou datt wa mir e Feeler hunn, kënne mir manner REDO maachen. Et ass wéi e Spillsaach. Wa mir ëmbruecht ginn, fänken mir d'Spill vum leschte Kontrollpunkt un. An all DBMS implementéieren dëst.
Astellungen an Postgres sinn lagging. Si si fir 10-15 Joer al Volumen vun Daten an Operatiounen entworf. A Checkpoint ass keng Ausnahm.
Hei ass d'Informatioun vun eisem Postgres Check-up Bericht, dh automatesch Gesondheetscheck. An hei ass eng Datebank vu verschiddenen Terabytes. An et ass gutt ze gesinn, datt a bal 90% vun de Fäll gezwongen Kontrollen.
Wat heescht dat? Et ginn zwou Astellungen do. Checkpoint kann duerch Timeout kommen, zum Beispill, um 10 Minutten. Oder et ka kommen wann zimlech vill Daten ausgefëllt sinn.
An par défaut ass max_wal_saze op 1 gigabyte gesat. Tatsächlech geschitt dat wierklech am Postgres no 300-400 Megabytes. Dir hutt sou vill Daten geännert an Äre Kontrollpunkt geschitt.
A wann keen et ofgestëmmt huet, awer de Service ass gewuess, an d'Firma verdéngt vill Suen, et huet vill Transaktiounen, da geschitt de Checkpoint eemol d'Minutt, heiansdo eemol all 30 Sekonnen, an heiansdo iwwerlappt se sech souguer géigesäiteg . Dëst ass wierklech schlecht.
A mir mussen dofir suergen, datt et manner dacks kënnt. Dat ass, mir kënnen max_wal_size erhéijen. An et wäert manner dacks kommen.
Awer mir hunn eng ganz Methodik entwéckelt fir et méi korrekt ze maachen, dat ass, wéi Dir eng Entscheedung iwwer d'Auswiel vun Astellunge maache kënnt, kloer op spezifesch Donnéeën baséiert.
Deementspriechend maache mir zwou Serien Experimenter op Datenbanken.
Éischt Serie - mir änneren max_wal_size. A mir maachen eng massiv Operatioun. Als éischt maache mir et am Standardastellung vun 1 Gigabyte. A mir maachen e massive DELETE vu ville Millioune Linnen.
Dir kënnt gesinn wéi schwéier et fir eis ass. Mir gesinn datt Disk IO ganz schlecht ass. Loosst eis kucken wéi vill WAL mir generéiert hunn, well dëst ass ganz wichteg. Loosst eis kucken wéi oft de Checkpoint geschitt ass. A mir gesinn datt et net gutt ass.
Als nächst erhéijen mir max_wal_size. Mir widderhuelen. Erhéijung, widderhuelen. An esou vill Mol. Am Prinzip ass 10 Punkten gutt, wou 1, 2, 4, 8 Gigabyte. A mir kucken op d'Behuele vun engem bestëmmte System. Et ass kloer datt hei d'Ausrüstung soll sinn wéi op Prod. Dir musst déiselwecht Disken hunn, déiselwecht Quantitéit un Erënnerung, an déiselwecht Postgres Astellungen.
An op dës Manéier wäerte mir eise System austauschen, a mir wësse wéi d'DBMS sech am Fall vun enger schlechter Mass DELETE behält, wéi et Checkpoint wäert.
Checkpoint op russesch heescht Kontroll Punkten.
Beispill: E puer Millioune Reihen no Index LËSCHT, Zeile sinn "verstreet" iwwer Säiten.
Hei ass e Beispill. Dëst ass eng Basis. A mat der Default-Astellung vun 1 Gigabyte fir max_wal_size, ass et ganz kloer datt eis Disken op d'Regal goen fir opzehuelen. Dëst Bild ass en typescht Symptom vun engem ganz kranke Patient, dat heescht, hien huet sech wierklech schlecht gefillt. An et war eng eenzeg Operatioun, et war just e DELETE vun e puer Millioune Linnen.
Wann esou eng Operatioun am Prod erlaabt ass, da wäerte mir eis einfach leeën, well et ass kloer datt een DELETE eis am Regal ëmbréngt.
Weider, wou 16 gigabytes, et ass kloer, datt d'Zänn schonn fort sinn. Zänn si scho besser, dat heescht, mir klappen op d'Plafong, awer net sou schlecht. Do war e bësse Fräiheet. Riets ass de Rekord. An d'Zuel vun Operatiounen - déi zweet Grafik. An et ass kloer, datt mir schonn e bësse méi einfach otmen wann 16 gigabytes.
A wou 64 Gigabyte gesäit een, datt et komplett besser ginn ass. Schonn sinn d'Zänn ausgeschwat, et gi méi Méiglechkeeten fir aner Operatiounen ze iwwerliewen an eppes mat der Scheif ze maachen.
Firwat ass et esou?
Ech wäert e bëssen an d'Detailer tauchen, awer dëst Thema, wéi Dir d'Kontrollpunkttuning ausféiert, kann zu engem ganze Bericht resultéieren, also wäert ech net vill lueden, awer ech wäert e bësse skizzéieren wat Schwieregkeeten et sinn.
Wann de Checkpoint ze dacks geschitt, a mir aktualiséieren eis Zeilen net sequenziell, awer fannen duerch Index, wat gutt ass, well mir de ganzen Dësch net läschen, da kann et geschéien datt mir am Ufank déi éischt Säit beréiert hunn, dann den Dausendsten, an dann zréck op déi éischt. A wann tëscht dëse Visiten op déi éischt Säit, Checkpoint huet et schonn op Disk gespäichert, da späichert et et erëm, well mir et eng zweete Kéier dreckeg hunn.
A mir wäerte Checkpoint forcéieren et vill Mol ze retten. Wéi géif et iwwerflësseg Operatioune fir hien ginn.
Mä dat ass net alles. Säiten sinn 8 kilobytes am Postgres a 4 kilobytes am Linux. An et gëtt eng full_page_writes Astellung. Et ass par défaut aktivéiert. An dat ass richteg, well wa mir et ausschalten, da besteet d'Gefor datt nëmmen d'Halschent vun der Säit gespäichert gëtt, wann se ofbriechen.
D'Behuele fir op d'WAL vum Forward Log ze schreiwen ass sou datt wa mir e Kontrollpunkt hunn a mir d'Säit fir d'éischte Kéier änneren, déi ganz Säit, dh all 8 Kilobytes, an de Forward Log erakënnt, obwuel mir nëmmen de Forward geännert hunn. Linn, déi 100 Bytes weit. A mir mussen déi ganz Säit opschreiwen.
A spéider Ännerungen gëtt et nëmmen e spezifesche Tupel, awer fir d'éischte Kéier schreiwen mir alles op.
An deementspriechend, wann de Kontrollpunkt erëm geschitt ass, da musse mer alles vun Null unzefänken an déi ganz Säit drécken. Mat reegelméissege Kontrollpunkten, wa mir duerch déiselwecht Säite goen, wäert full_page_writes = on méi sinn wéi et kéint sinn, dh mir generéiere méi WAL. Méi gëtt op Repliken, an d'Archiv, op Disk geschéckt.
An deementspriechend hu mir zwou Entloossungen.
Wa mir max_wal_size Erhéijung, et stellt sech eraus, datt mir maachen et méi einfach fir souwuel Checkpoint an Wal Schrëftsteller. An dat ass super.
Loosst eis en Terabyte installéieren a liewen domat. Wat ass schlecht doriwwer? Dat ass schlecht, well am Fall vun Echec wäerte mir stonnelaang opstoen, well de Kontrollpunkt war viru laanger Zäit a scho vill geännert. A mir mussen REDO fir all dëst maachen. An dofir maache mir eng zweet Serie vun Experimenter.
Mir maachen eng Operatioun a gesinn wéini de Checkpoint fäerdeg ass, mir killen -9 Postgres op Zweck.
An duerno fänken mer et erëm un, a kucken wéi laang et op dëser Ausrüstung eropgeet, also wéi vill et an dëser schlechter Situatioun REDO wäert.
Zweemol wäert ech feststellen datt d'Situatioun schlecht ass. Fir d'éischt si mer gefall, ier de Kontrollpunkt eriwwer war, also hu mir vill ze verléieren. An zweetens hu mir eng massiv Operatioun. A wann d'Checkpoints op Timeout wieren, da wier héchstwahrscheinlech manner WAL zënter dem leschte Checkpoint generéiert. Dat ass, et ass eng duebel Verléierer.
Mir moossen esou eng Situatioun fir verschidde max_wal_size Gréissten a verstinn datt wann max_wal_size 64 gigabytes ass, da wäerte mir an engem duebele schlëmmste Fall fir 10 Minutten klammen. A mir denken ob et eis passt oder net. Dëst ass eng Affär Fro. Mir mussen deene Verantwortlech fir Geschäftsentscheedungen dëst Bild weisen a froen: "Wéi laang kënne mir am meeschten am Fall vun engem Problem leien? Kënne mir eis an der schlëmmster Situatioun fir 3-5 Minutten leien? An Dir maacht eng Entscheedung.
An hei ass en interessante Punkt. Mir hunn e puer Berichter iwwer Patroni op der Konferenz. A vläicht benotzt Dir et. Dëst ass en Autofailover fir Postgres. GitLab an Data Egret hunn iwwer dëst geschwat.
A wann Dir en Autofailover hutt deen an 30 Sekonnen kënnt, da kënne mir vläicht 10 Minuten leeën? Well mir wiesselen op d'Replique vun dësem Punkt, an alles wäert gutt sinn. Dëst ass e moot Punkt. Ech weess keng kloer Äntwert. Ech fille just datt dëst Thema net nëmmen ëm Crash Erhuelung ass.
Wa mir eng laang Erhuelung no engem Echec hunn, da wäerte mir a villen anere Situatiounen onwuel sinn. Zum Beispill, an der selwechter Experimenter, wa mir eppes maachen an heiansdo mussen 10 Minutten wait.
Ech géif nach ëmmer net ze wäit goen, och wa mir Autofailover hunn. Als Regel, Wäerter wéi 64, 100 Gigabytes si gutt Wäerter. Heiansdo lount et sech souguer manner ze wielen. Am Allgemengen ass dëst eng subtile Wëssenschaft.
Fir ze iteréieren, zum Beispill, max_wal_size = 1, 8, musst Dir d'Massoperatioun vill Mol widderhuelen. Dir hutt et gemaach. An op der selwechter Basis wëllt Dir et nach eng Kéier maachen, awer Dir hutt alles scho geläscht. Wat kann een maachen?
Ech wäert spéider iwwer eis Léisung schwätzen, wat mir maache fir an esou Situatiounen ze iteréieren. An dëst ass déi richteg Approche.
Mä an dësem Fall, mir waren Gléck. Wann, wéi et hei seet "BEGIN, DELETE, ROLLBACK", da kënne mir LËSCHEN widderhuelen. Dat heescht, wa mir et selwer annuléieren, da kënne mir et widderhuelen. A kierperlech bei Iech wäerten d'Donnéeën op der selwechter Plaz leien. Dir kritt emol kee Bloat. Dir kënnt iwwer sou DELETEs iteréieren.
Dëst DELETE mat ROLLBACK ass ideal fir Checkpoint Tuning, och wann Dir keng richteg agesat Datebank Laboe hutt.
Mir hunn eng Plack mat enger Kolonn "i" gemaach. Postgres huet Utility Sailen. Si sinn onsichtbar ausser speziell gefrot. Dëst sinn: ctid, xmid, xmax.
Ctid ass eng kierperlech Adress. Null Säit, déi éischt Tuple op der Säit.
Et kann gesi ginn datt nom ROOLBACK den Tupel op der selwechter Plaz bliwwen ass. Dat ass, mir kënnen nach eng Kéier probéieren, et wäert déi selwecht Manéier behuelen. Dëst ass den Haapt Saach.
Xmax ass d'Zäit vum Doud vum Tupel. Et gouf gestempelt, awer Postgres weess datt d'Transaktioun zréckgerullt gouf, also ass et egal ob et 0 ass oder et ass eng zréckgerullte Transaktioun. Dëst hindeit datt et méiglech ass iwwer DELETE ze iteréieren an d'Mass Operatioune vum Systemverhalen ze kontrolléieren. Dir kënnt Datebank Laboe fir déi Aarm maachen.
Dëst ass iwwer Programméierer. Och iwwer DBA schëlle si Programméierer ëmmer dofir: "Firwat maacht Dir esou laang a schwéier Operatiounen?". Dëst ass e komplett aner senkrecht Thema. Et war fréier Administratioun, an elo gëtt et Entwécklung.
Natierlech hu mir net a Stécker gebrach. Et ass kloer. Et ass onméiglech net esou DELETE fir e Koup vu Millioune Linnen an Deeler ze briechen. Et gëtt fir 20 Minutten gemaach, an alles wäert leien. Mee, leider, souguer erfuerene Entwéckler maachen Feeler, och a ganz grousse Firmen.
Firwat ass Break wichteg?
-
Wa mir gesinn datt d'Disk schwéier ass, da loosst eis et lues maachen. A wa mir gebrach sinn, da kënne mir Pausen addéieren, mir kënnen d'Drossel verlangsamen.
-
A mir wäerten anerer net fir eng laang Zäit blockéieren. An e puer Fäll ass et egal, wann Dir e richtegt Dreck läscht, op deem kee schafft, da wäert Dir wahrscheinlech kee blockéieren ausser d'Autovakuumaarbecht, well et waart bis d'Transaktioun fäerdeg ass. Awer wann Dir eppes läscht, wat een aneren kann ufroen, da gi se blockéiert, et gëtt eng Aart vu Kettenreaktioun. Laang Transaktioune sollten op Websäiten a mobilen Uwendungen vermeit ginn.
Dëst ass interessant. Ech gesinn dacks datt d'Entwéckler froen: "Wat Packgréisst soll ech wielen?".
Et ass kloer datt wat méi grouss d'Bündelgréisst ass, dest méi kleng ass d'Transaktiounsoverhead, dh déi zousätzlech Overhead vun Transaktiounen. Awer gläichzäiteg erhéicht d'Zäit fir dës Transaktioun.
Ech hunn eng ganz einfach Regel: huelt sou vill wéi Dir kënnt, awer gitt net iwwer Exekutables pro Sekonn.
Firwat eng zweet? D'Erklärung ass ganz einfach a verständlech fir jiddereen, och net-technesch Leit. Mir gesinn eng Reaktioun. Loosst eis 50 Millisekonnen huelen. Wann eppes geännert huet, da reagéiert eis Aen. Wann manner, dann méi schwéier. Wann eppes no 100 Millisekonnen reagéiert, zum Beispill, hutt Dir op d'Maus geklickt, an et huet Iech no 100 Millisekonnen geäntwert, fillt Dir schonn dës liicht Verspéidung. Eng zweet gëtt schonn als Bremsen ugesinn.
Deementspriechend, wa mir eis Mass Operatiounen an 10 Sekonnen Bursts opbriechen, da riskéiere mir datt mir een blockéieren. An et wäert e puer Sekonnen funktionnéieren, an d'Leit wäerten et scho bemierken. Dofir maachen ech léiwer net méi wéi eng Sekonn. Awer gläichzäiteg briechen et net ganz fein op, well d'Transaktiounsoverhead bemierkbar ass. D'Basis wäert méi haart sinn, an aner verschidde Probleemer kënnen entstoen.
Mir wielen d'Packgréisst. An all Fall kënne mir dat anescht maachen. Kann automatiséiert ginn. A mir sinn iwwerzeegt vun der Effizienz vun der Veraarbechtung vun engem Pak. Dat ass, mir maachen LËSCHTEN vun engem Pak oder UPDATE.
Iwwregens, alles wat ech schwätzen ass net nëmmen ëm DELETE. Wéi Dir et scho geduecht hutt, sinn dëst all bulk Operatiounen op Daten.
A mir gesinn datt de Plang exzellent ass. Dir kënnt den Index Scan gesinn, nëmmen Index Scan ass nach besser. A mir hunn eng kleng Quantitéit un Daten involvéiert. A manner wéi eng Sekonn erfëllt. Super.
A mir mussen nach suergen, datt et keng Degradatioun gëtt. Et geschitt datt déi éischt Chargen séier ausgeschafft ginn, an da gëtt alles ëmmer méi schlëmm a méi schlëmm. De Prozess ass sou datt Dir vill muss testen. Dat ass genee fir wat Datebank Laboe gebraucht ginn.
A mir mussen nach eppes virbereeden fir datt et eis erlaabt dat richteg an der Produktioun ze verfollegen. Zum Beispill kënne mir d'Zäit am Logbuch schreiwen, mir kënne schreiwen wou mir elo sinn a wien mir elo geläscht hunn. An dëst erlaabt eis ze verstoen wat spéider geschitt. A wann eppes falsch leeft, fanne séier de Problem.
Wa mir d'Effizienz vun Ufroe musse kontrolléieren a mir musse vill Mol iteréieren, da gëtt et sou eppes wéi e Matbierger Bot. Hien ass scho prett. Et gëtt all Dag vun Dosende vun Entwéckler benotzt. An hie weess wéi eng riseg Terabyte-Datebank op Ufro an 30 Sekonnen ze ginn, Är eege Kopie. An Dir kënnt eppes do läschen a soen RESET, an läschen et erëm. Dir kënnt op dës Manéier experimentéieren. Ech gesinn eng Zukunft fir dës Saach. A mir maachen et schonn.
Wat sinn Partitionsstrategien? Ech gesinn 3 verschidde Partitionsstrategien déi d'Entwéckler um Pak benotzen.
Déi éischt ass ganz einfach. Mir hunn eng numeresch ID. A loosse mer et an verschidden Intervalle opbriechen a mat deem schaffen. Den Nodeel ass kloer. Am éischte Segment hu mir vläicht 100 Linnen vun echtem Dreck, an der zweeter 5 Linnen oder guer net, oder all 1 Linnen wäerten Dreck sinn. Ganz ongläich Aarbecht, awer et ass einfach ze briechen. Si hunn déi maximal ID geholl an se zerstéiert. Dëst ass eng naiv Approche.
Déi zweet Strategie ass eng equilibréiert Approche. Et gëtt am Gitlab benotzt. Si hunn den Dësch geholl an gescannt. Mir hunn d'Grenze vun den ID-Päck fonnt, sou datt all Pak genee 10 records hat. A setzen se an eng Schlaang. An dann veraarbecht mir. Dir kënnt dat a ville Threads maachen.
An der éischter Strategie, iwwregens, kënnt Dir dëst och a verschiddene Threads maachen. Et ass net schwéier.
Awer et gëtt eng méi cool a besser Approche. Dëst ass déi drëtt Strategie. A wann et méiglech ass, ass et besser et ze wielen. Mir maachen dat op Basis vun engem speziellen Index. An dësem Fall wäert et héchstwahrscheinlech en Index sinn no eisem Müllzoustand an ID. Mir wäerten d'ID enthalen sou datt et nëmmen en Index Scan ass fir datt mir net op de Koup goen.
Typesch ass den Index Scann méi séier wéi den Index Scan.
A mir fanne séier eis IDen déi mir wëllen läschen. Mir wielen BATCH_SIZE am Viraus. A mir kréien se net nëmmen, mir empfänken se op eng speziell Manéier a fixéieren se direkt. Mee mir spären se sou datt wa se scho gespaart sinn, mir spären se net, awer fuere weider an huelen déi nächst. Dëst ass fir d'Aktualiséierung gespaart. Dës Postgres Super Feature erlaabt eis a verschidde Threads ze schaffen wa mir wëllen. Eventuell an engem Fuedem. An dann ass et CTE - dëst ass eng Ufro. A mir hunn eng richteg Läschung um zweete Stack vun dësem CTE - returning *. Dir kënnt ID zréckginn, awer et ass besser *wann Dir hutt net vill Donnéeën op all Linn.
Firwat brauche mir dat? Mir brauchen dat fir ze mellen. Mir hunn elo esou vill Zeile geläscht tatsächlech. An eis Grenze vun ID oder create_at sinn esou. Dir kënnt min, max. Soss ka gemaach ginn. Et gëtt vill, wat Dir hei kache kënnt. An dëst ass ganz bequem fir d'Iwwerwaachung.
Et gëtt nach eng Notiz iwwer den Index. Wa mir décidéieren, datt mir e speziellen Index fir dës Aufgab brauchen, da musse mir sécherstellen, datt et net Koup nëmmen tuples Aktualiséierungen verduerwen. Dat ass, Postgres huet esou Statistiken. Dëst kann an pg_stat_user_tables fir Ären Dësch gesi ginn. Dir kënnt kucken ob waarm Updates benotzt ginn oder net.
Et gi Situatiounen wou Ären neien Index se einfach ofschneiden kann. An all aner Aktualiséierungen, déi scho lafen, wäerte méi lues sinn. Net nëmme well den Index erschéngt (all Index verlangsamt d'Aktualiséierungen e bëssen, awer nëmmen e bëssen), mee hei wäert et nach ëmmer d'Saachen duercherneen bréngen. An et ass onméiglech eng speziell Optimisatioun fir dësen Dësch ze maachen. Dëst geschitt heiansdo. Dëst ass eng Subtilitéit déi wéineg Leit erënneren. An et ass einfach op dëser Rake ze trëppelen. Heiansdo geschitt et datt Dir eng Approche vun der anerer Säit muss fannen an ëmmer nach ouni dësen neien Index maachen, oder en aneren Index maachen, oder soss eppes maachen, zum Beispill, Dir kënnt déi zweet Method benotzen.
Awer dëst ass déi optimal Strategie, wéi een a Chargen opgedeelt gëtt a Batches mat enger Ufro schéisst, e bëssen läschen, asw.
Laang Transaktiounen -
Blockéiert Autovakuum -
Blockéierungsprobleem -
Feeler #5 ass e groussen. Nikolai vun Okmeter geschwat iwwer Postgres Iwwerwachung. Ideal Postgres Iwwerwachung, leider, existéiert net. E puer si méi no, anerer si méi wäit. Okmeter ass no genuch fir perfekt ze sinn, awer vill fehlt a muss derbäigesat ginn. Dir musst prett sinn fir dëst.
Zum Beispill, doudege Tupelen sinn am beschten iwwerwaacht. Wann Dir vill doudege Saachen am Dësch hutt, dann ass eppes falsch. Et ass besser elo ze reagéieren, soss kann et zu Degradatioun kommen, a mir kënne leien. Et geschitt.
Wann et eng grouss IO ass, ass et kloer datt dëst net gutt ass.
Laang Transaktiounen och. Laang Transaktioune sollen net op OLTP erlaabt sinn. An hei ass e Link op e Snippet deen Iech erlaabt dësen Snippet ze huelen a schonn e puer Tracking vu laange Transaktiounen ze maachen.
Firwat sinn laang Transaktiounen schlecht? Well all d'Schlässer ginn eréischt um Enn fräigelooss. A mir spären jiddereen op. Plus blockéiere mir Autovakuum fir all Dëscher. Dëst ass guer net gutt. Och wann Dir waarm Standby op der Replica aktivéiert hutt, ass et nach ëmmer schlecht. Am Allgemengen, néierens ass et besser laang Transaktiounen ze vermeiden.
Wa mir vill Dëscher hunn déi net vacuuméiert sinn, da musse mir eng Alarm hunn. Hei ass esou eng Situatioun méiglech. Mir kënnen indirekt d'Operatioun vum Autovakuum beaflossen. Dëst ass en Ausschnëtt vum Avito, deen ech liicht verbessert hunn. An et huet sech als interessant Tool erausgestallt fir ze kucken wat mir mam Autovakuum hunn. Zum Beispill, e puer Dëscher waarden do a wäert net fir hiren Tour waarden. Dir musst et och an d'Iwwerwaachung setzen an eng Alarm hunn.
An erausginn Blocken. Bësch vu Blockbeem. Ech hu gär eppes vun engem ze huelen an et ze verbesseren. Hei hunn ech e cool rekursive CTE vun Data Egret geholl, deen e Bësch vu Spärbeem weist. Dëst ass e gutt diagnostescht Instrument. An op senger Basis kënnt Dir och Iwwerwaachung bauen. Mä dëst muss virsiichteg gemaach ginn. Dir musst eng kleng Statement_Timeout fir Iech selwer maachen. A lock_timeout ass wënschenswäert.
Heiansdo geschéien all dës Feeler zesummen.
Menger Meenung no ass dee wichtegste Feeler hei organisatoresch. Et ass organisatoresch, well d'Technologie net funktionnéiert. Dëst ass Nummer 2 - si hunn op der falscher Plaz gepréift.
Mir hunn do net gepréift well mir keng Produktiounsklon haten déi einfach ze kontrolléieren war. En Entwéckler kann guer net Zougang zu Produktioun hunn.
A mir hunn do net gepréift. Wa mer do gepréift hätten, hätte mer et selwer gesinn. Den Entwéckler huet alles gesinn och ouni DBA wann hien et an engem gudden Ëmfeld gepréift huet, wou et déiselwecht Quantitéit un Daten an eng identesch Plaz ass. Hien hätt all dës Degradatioun gesinn an hie géif sech schummen.
Méi iwwer Autovakuum. Nodeems mir e massive Sweep vun e puer Millioune Linnen gemaach hunn, musse mir nach ëmmer REPACK maachen. Dëst ass besonnesch wichteg fir Indexen. Si fille sech schlecht nodeems mer do alles gebotzt hunn.
A wann Dir wëllt déi deeglech Botzaarbecht zréckbréngen, da géif ech proposéieren et méi dacks ze maachen, awer méi kleng. Et kann eemol pro Minutt sinn oder souguer méi dacks e bëssen. An Dir musst zwou Saachen iwwerwaachen: datt dës Saach keng Feeler huet an datt et net hannendrun ass. Den Trick deen ech gewisen hunn wäert dëst just léisen.
Wat mir maachen ass Open Source. Et ass op GitLab gepost. A mir maachen et sou datt d'Leit och ouni DBA kënne kontrolléieren. Mir maachen en Datebanklabo, dat heescht, mir nennen de Basiskomponent un deem de Joe de Moment schafft. An Dir kënnt eng Kopie vun der Produktioun gräifen. Elo gëtt et eng Implementatioun vum Joe fir Slack, Dir kënnt do soen: "erkläert esou an esou eng Ufro" an direkt d'Resultat fir Är Kopie vun der Datebank kréien. Dir kënnt do souguer LËSCHEN, a keen wäert et mierken.
Loosst d'soen Dir hutt 10 Terabyte, mir maachen Datebank Labo och 10 Terabyte. A mat gläichzäiteg 10 Terabyte Datenbanken kënnen 10 Entwéckler gläichzäiteg schaffen. Jidderee kann maachen wat e wëllt. Kann läschen, drop, etc. Dat ass sou eng Fantasie. Mir schwätzen iwwer dëst muer.
Dëst nennt een dënn Versuergung. Dëst ass subtile Bestëmmung. Dëst ass eng Zort Fantasie déi Verspéidungen an der Entwécklung an Tester staark eliminéiert an d'Welt an dëser Hisiicht eng besser Plaz mécht. Dat ass, et erlaabt Iech just Problemer mat bulk Operatiounen ze vermeiden.
Beispill: 5 Terabyte Datebank, kritt eng Kopie a manner wéi 30 Sekonnen. An et hänkt och net vun der Gréisst of, dat heescht, et ass egal wéivill Terabytes.
Haut kënnt Dir op a gräift an eis Tools. Dir kënnt Iech aschreiwen fir ze kucken wat do ass. Dir kënnt dëse Bot installéieren. Et ass gratis. Schreiwen.
Är Froen
Ganz dacks an realen Situatiounen stellt sech eraus datt d'Donnéeën déi an der Tabell bleiwen solle vill manner sinn wéi dat wat geläscht muss ginn. Dat ass, an esou enger Situatioun ass et dacks méi einfach esou eng Approche ëmzesetzen, wann et méi einfach ass en neien Objet ze kreéieren, nëmmen déi néideg Donnéeën do ze kopéieren an den alen Dësch ze trunkéieren. Et ass kloer datt eng programmatesch Approche fir dëse Moment gebraucht gëtt, während Dir wiesselt. Wéi ass dës Approche?
Dëst ass eng ganz gutt Approche an eng ganz gutt Aufgab. Et ass ganz ähnlech wéi pg_repack mécht, et ass ganz ähnlech wéi wat Dir maache musst wann Dir d'Leit ID 4 Bytes gemaach hutt. Vill Kaderen hunn dëst virun e puer Joer gemaach, an d'Placke si just méi grouss ginn, a si mussen op 8 Bytes ëmgewandelt ginn.
Dës Aufgab ass relativ schwéier. Mir hunn et gemaach. An Dir musst ganz virsiichteg sinn. Et gi Spären, etc.. Mee et gëtt gemaach. Dat ass, d'Standard Approche ass mat pg_repack ze goen. Dir deklaréiert esou e Label. A ier Dir ufänkt Snapshotdaten dran eropzelueden, deklaréiert Dir och eng Plack déi all Ännerungen verfollegt. Et gëtt en Trick datt Dir e puer Ännerungen net emol verfollegt. Et gi Subtletien. An dann wiesselt Dir duerch Rolling Ännerungen. Et gëtt eng kuerz Paus wann mir jiddereen zoumaachen, awer allgemeng gëtt dat gemaach.
Wann Dir pg_repack op GitHub kuckt, dann do, wann et eng Aufgab war fir eng ID vun int 4 op int 8 ze konvertéieren, da war et eng Iddi fir pg_repack selwer ze benotzen. Dëst ass och méiglech, awer et ass e bësse vun engem Hack, awer et funktionnéiert och fir dëst. Dir kënnt am Ausléiser intervenéieren deen pg_repack benotzt an do soen: "Mir brauchen dës Donnéeën net", dat heescht mir transferéieren nëmmen dat wat mir brauchen. An dann wiesselt hien just an dat ass et.
Mat dëser Approche kréie mir nach ëmmer eng zweet Kopie vun der Tabell, an där d'Donnéeën scho indexéiert sinn a ganz gläichméisseg mat schéine Indexen gestapelt sinn.
Bloat ass net präsent, et ass eng gutt Approche. Mee ech weess, datt et Versich gëtt eng Automatisatioun dofir z'entwéckelen, also eng universell Léisung ze maachen. Ech kann Iech mat dëser Automatisatioun a Kontakt setzen. Et ass am Python geschriwwen, wat eng gutt Saach ass.
Ech sinn just e bëssen aus der Welt vu MySQL, also sinn ech komm fir ze lauschteren. A mir benotzen dës Approche.
Mä et ass nëmme wa mir 90% hunn. Wa mir 5% hunn, dann ass et net ganz gutt et ze benotzen.
Merci fir de Bericht! Wann et keng Ressourcen sinn fir eng voll Kopie vu Prod ze maachen, gëtt et en Algorithmus oder Formel fir d'Laascht oder d'Gréisst ze berechnen?
Gutt Fro. Bis elo kënne mir Multi-Terabyte Datenbanken fannen. Och wann d'Hardware do net déi selwecht ass, Zum Beispill, manner Erënnerung, manner Prozessor an Disken sinn net genee déi selwecht, mä mir maachen et nach. Wann et absolut néierens ass, da musst Dir denken. Loosst mech bis muer denken, Dir sidd komm, mir schwätzen, dat ass eng gutt Fro.
Merci fir de Bericht! Dir hutt fir d'éischt ugefaang iwwer d'Tatsaach datt et e coole Postgres gëtt, deen esou an esou Aschränkungen huet, awer et entwéckelt sech. An dëst ass am grousse Ganzen eng Krut. Ass dat net alles am Konflikt mat der Entwécklung vu Postgres selwer, an där e puer DELETE-Deferenten optrieden oder soss eppes wat op engem nidderegen Niveau soll halen, wat mir probéieren mat e puer vun eise komeschen Mëttelen hei ze verschmieren?
Wa mir an SQL gesot hunn, vill Rekorder an enger Transaktioun ze läschen oder ze aktualiséieren, wéi kann Postgres et do verdeelen? Mir si kierperlech limitéiert an Operatiounen. Mir wäerten et nach laang maachen. A mir wäerten zu dëser Zäit Spär, etc.
Si hunn datselwecht gemaach mat Indexen.
Ech kann dovun ausgoen, datt déi selwecht Checkpoint tuning automatiséiert ginn. Irgendwann kann et sinn. Awer dann verstinn ech d'Fro net wierklech.
D'Fro ass: Gëtt et en Entwécklungsvektor dee richteg dohinner geet a parallel zu Ärem hei geet? Déi. Hunn se nach net driwwer geduecht?
Ech hunn iwwer d'Prinzipien geschwat, déi elo kënne benotzt ginn. Et gëtt en anere Bot , mat dësem kënnt Dir automatiséiert Checkpoint Tuning maachen. Wäert et iergendwann zu Postgres sinn? Ech weess et net, et ass nach net emol diskutéiert ginn. Mir sinn nach wäit dovunner. Awer et gi Wëssenschaftler déi nei Systemer maachen. A si drécken eis an automatesch Indizes. Et ginn Entwécklungen. Zum Beispill kënnt Dir op Auto Tuning kucken. Et wielt Parameteren automatesch. Awer hien wäert nach keng Checkpoint Tuning fir Iech maachen. Dat ass, et wäert ophuelen fir Leeschtung, Shell-Puffer, etc.
A fir Checkpoint Tuning kënnt Dir dëst maachen: wann Dir dausend Stärekéip a verschidde Hardware hutt, verschidde virtuell Maschinnen an der Wollek, kënnt Dir eise Bot benotzen Automatisatioun maachen. A max_wal_size gëtt automatesch no Ären Zilastellungen ausgewielt. Mee bis elo ass dat leider net emol no am Kär.
Gudde Mëtteg Dir hutt iwwer d'Gefore vu laanger Transaktioune geschwat. Dir sot datt den Autovakuum am Fall vu Läschen blockéiert ass. Wéi soss schued et eis? Well mir schwätze méi iwwer d'Plaz befreien an et ze benotzen. Wat vermësse mir nach?
Autovacuum ass vläicht net de gréisste Problem hei. An de Fait, datt eng laang Transaktioun aner Transaktiounen Spär kann, ass dës Méiglechkeet méi geféierlech. Si kann oder vläicht net treffen. Wann hatt begéint, da kann et ganz schlecht ginn. A mam Autovakuum - dat ass och e Problem. Et ginn zwee Probleemer mat laangen Transaktiounen am OLTP: Spären an Autovakuum. A wann Dir waarm Standby-Feedback op der Replica aktivéiert hutt, da kënnt den Autovakuumschloss och op de Master, et kënnt aus der Replika. Mee op d'mannst gëtt et keng Spären. An et wäert Loks ginn. Mir schwätzen iwwer Dateännerungen, sou datt Spären e wichtege Punkt hei sinn. A wann dat alles fir eng laang, laang Zäit ass, da sinn ëmmer méi Transaktioune gespaart. Si kënnen anerer klauen. A lok Beem schéngen. Ech hunn e Link op den Ausschnëtt geliwwert. An dëse Problem gëtt méi séier bemierkenswäert wéi de Problem mam Autovakuum, deen nëmmen accumuléiert ka ginn.
Merci fir de Bericht! Dir hutt Äre Bericht ugefaang andeems Dir gesot hutt datt Dir falsch getest hutt. Mir hunn eis Iddi weidergefouert datt mir déiselwecht Ausrüstung mussen huelen, mat der Basis op déiselwecht Manéier. Loosst eis soen, mir hunn dem Entwéckler eng Basis ginn. An hien huet der Demande nokomm. An hien schéngt gutt ze sinn. Mä hien kontrolléiert net fir Live, mee fir Live, zum Beispill, hu mir eng Laascht vu 60-70%. An och wa mir dës Tuning benotzen, funktionnéiert et net ganz gutt.
En Expert op Ärem Team ze hunn an DBA Experten ze benotzen déi viraussoe kënnen wat ënner realen Hannergrondlaascht geschitt ass wichteg. Wa mir einfach duerch eis reng Ännerungen gefuer sinn, gesi mir d'Bild. Awer eng méi fortgeschratt Approche war wann mir déi selwecht Saach erëm gemaach hunn, awer mat enger simuléierter Produktiounslaascht. Dëst ass ganz cool. Mir mussen nach bis zu dësem Punkt wuessen. Et ass reift. Mir hunn reng gekuckt wat mir hunn an och gekuckt ob mir genuch Ressourcen hunn. Dat ass eng gutt Fro.
Wa mir schonn eng Müllauswiel maachen a mir hunn zum Beispill e geläschte Fändel
Dëst ass wat Autovakuum automatesch am Postgres mécht.
Oh, mécht hien et?
Autovacuum ass de Müllsammler.
Merci!
Merci fir de Bericht! Gëtt et eng Optioun fir direkt eng Datebank mat Partitionéierung esou ze designen datt all Gerempels vun der Haaptdësch iergendwou op d'Säit dreckeg gëtt?
Natierlech hunn.
Ass et dann méiglech, eis ze schützen, wa mir en Dësch gespaart hunn, deen net sollt benotzt ginn?
Natierlech hunn. Awer et ass wéi eng Poulet an Ee Fro. Wa mir all wëssen wat an Zukunft wäert geschéien, da maache mir natierlech alles cool. Awer d'Geschäft ännert sech, et ginn nei Sailen, nei Ufroen. An dann - Oops, mir wëllen et ewechhuelen. Awer dës ideal Situatioun, am Liewen geschitt et, awer net ëmmer. Mee insgesamt ass et eng gutt Iddi. Just ofschneiden an dat ass et.
Source: will.com