Irgendwann in ferner Zukunft wird die automatische Entfernung unnötiger Daten eine der wichtigen Aufgaben des DBMS sein [1]. In der Zwischenzeit müssen wir uns selbst darum kümmern, unnötige Daten zu löschen oder auf kostengünstigere Speichersysteme zu verschieben. Nehmen wir an, Sie möchten einige Millionen Zeilen löschen. Eine recht einfache Aufgabe, insbesondere wenn die Erkrankung bekannt ist und ein geeigneter Index vorhanden ist. „DELETE FROM table1 WHERE col1 = :value“ – was könnte einfacher sein, oder?
Video:
-
Ich bin seit dem ersten Jahr, also seit 2007, im Highload-Programmkomitee.
-
Und ich bin seit 2005 bei Postgres. Habe es in vielen Projekten verwendet.
-
Gruppe mit RuPostges auch seit 2007.
-
Wir sind bei Meetup auf über 2100 Teilnehmer angewachsen. Nach New York liegt es weltweit an zweiter Stelle und wurde lange Zeit von San Francisco überholt.
-
Ich lebe seit mehreren Jahren in Kalifornien. Ich habe mehr mit amerikanischen Unternehmen zu tun, auch mit großen. Sie sind aktive Benutzer von Postgres. Und es gibt allerhand interessante Dinge.
ist mein Unternehmen. Unser Geschäft ist die Automatisierung von Aufgaben, die Entwicklungsverzögerungen verhindern.
Wenn Sie etwas tun, gibt es manchmal Probleme mit Postgres. Nehmen wir an, Sie müssen warten, bis der Administrator einen Teststand für Sie eingerichtet hat, oder Sie müssen darauf warten, dass der DBA Ihnen antwortet. Und wir finden solche Engpässe im Entwicklungs-, Test- und Administrationsprozess und versuchen, sie mithilfe von Automatisierung und neuen Ansätzen zu beseitigen.
Ich war kürzlich bei VLDB in Los Angeles. Dies ist die größte Konferenz zum Thema Datenbanken. Und es gab einen Bericht, dass DBMS in Zukunft Daten nicht nur speichern, sondern auch automatisch löschen wird. Das ist ein neues Thema.
In der Zettabyte-Welt gibt es immer mehr Daten – das sind 1 Petabyte. Und jetzt wird bereits geschätzt, dass auf der Welt mehr als 000 Zettabytes an Daten gespeichert sind. Und davon gibt es immer mehr.
Und was tun damit? Offensichtlich muss es entfernt werden. Hier ist ein Link zu diesem interessanten Bericht. Bisher wurde dies jedoch nicht im DBMS implementiert.
Wer Geld zählen kann, will zwei Dinge. Sie wollen, dass wir löschen, also sollten wir technisch dazu in der Lage sein.
Was ich als nächstes erzählen werde, ist eine abstrakte Situation, die eine Reihe realer Situationen umfasst, d. h. eine Art Zusammenstellung dessen, was mir und den umliegenden Datenbanken viele Male, viele Jahre lang tatsächlich passiert ist. Rechen sind überall und jeder tritt ständig darauf.
Nehmen wir an, wir haben eine oder mehrere Basen, die wachsen. Und einige Aufzeichnungen sind offensichtlich Müll. Beispielsweise hat der Benutzer dort etwas begonnen, es aber nicht beendet. Und nach einiger Zeit wissen wir, dass dieses Unvollendete nicht mehr gelagert werden kann. Das heißt, wir möchten einige Müllteile bereinigen, um Platz zu sparen, die Leistung zu verbessern usw.
Im Allgemeinen besteht die Aufgabe darin, das Entfernen bestimmter Dinge, bestimmter Zeilen in einer Tabelle zu automatisieren.
Und wir haben eine solche Bitte, über die wir heute sprechen werden, nämlich über die Müllentsorgung.
Wir haben einen erfahrenen Entwickler damit beauftragt. Er hat diese Anfrage angenommen, selbst überprüft – alles funktioniert. Getestet auf der Bühne - alles in Ordnung. Ausgerollt - alles funktioniert. Einmal am Tag lassen wir es laufen – alles ist in Ordnung.
Die Datenbank wächst und wächst. Daily DELETE beginnt etwas langsamer zu arbeiten.
Dann verstehen wir, dass wir jetzt eine Marketingfirma haben und der Verkehr um ein Vielfaches größer sein wird, also beschließen wir, unnötige Dinge vorübergehend anzuhalten. Und vergiss zurückzukommen.
Ein paar Monate später erinnerten sie sich. Und wenn der Entwickler gekündigt hat oder mit etwas anderem beschäftigt ist, hat er einen anderen angewiesen, es zurückzugeben.
Er überprüfte die Entwicklung und das Staging – alles ist in Ordnung. Natürlich müssen Sie noch die Ansammlungen beseitigen. Er hat überprüft, ob alles funktioniert.
Was passiert als nächstes? Dann bricht für uns alles zusammen. Es sinkt, sodass irgendwann alles herunterfällt. Alle sind geschockt, niemand versteht, was passiert. Und dann stellt sich heraus, dass die Sache in diesem LÖSCHEN lag.
Etwas ist schief gelaufen? Hier ist eine Liste dessen, was schief gelaufen sein könnte. Welches davon ist das Wichtigste?
-
Beispielsweise gab es kein Review, d. h. der DBA-Experte hat sich nicht damit befasst. Mit einem erfahrenen Auge würde er das Problem sofort finden und außerdem hat er Zugriff auf Prod, wo sich mehrere Millionen Zeilen angesammelt haben.
-
Vielleicht haben sie etwas falsch überprüft.
-
Möglicherweise ist die Hardware veraltet und Sie müssen diese Basis aktualisieren.
-
Oder mit der Datenbank selbst stimmt etwas nicht und wir müssen von Postgres auf MySQL umsteigen.
-
Oder vielleicht stimmt etwas mit der Operation nicht.
-
Vielleicht gibt es Fehler in der Arbeitsorganisation und Sie müssen jemanden entlassen und die besten Leute einstellen?
Es gab keine DBA-Prüfung. Wenn es einen DBA gäbe, würde er diese mehreren Millionen Zeilen sehen und auch ohne Experimente sagen: „Das machen sie nicht.“ Angenommen, wenn dieser Code in GitLab, GitHub wäre und es einen Codeüberprüfungsprozess gäbe und es nicht gäbe, dass dieser Vorgang ohne die Genehmigung des DBA auf prod stattfinden würde, dann würde der DBA offensichtlich sagen: „Das ist nicht möglich.“ .“
Und er würde sagen, dass Sie Probleme mit der Festplatten-E/A haben und alle Prozesse verrückt werden, es möglicherweise Sperren gibt und Sie außerdem die automatische Vakuumierung für einige Minuten blockieren werden, also ist das nicht gut.
Der zweite Fehler: Sie haben an der falschen Stelle eingecheckt. Wir haben im Nachhinein festgestellt, dass sich auf dem Produkt viele Junk-Daten angesammelt haben, aber der Entwickler hatte keine Daten in dieser Datenbank angesammelt, und niemand hat diesen Junk während der Bereitstellung erstellt. Demnach waren es 1 Zeilen, die schnell geklappt haben.
Wir verstehen, dass unsere Tests schwach sind, das heißt, der aufgebaute Prozess erkennt keine Probleme. Ein adäquates DB-Experiment wurde nicht durchgeführt.
Ein ideales Experiment wird vorzugsweise mit derselben Ausrüstung durchgeführt. Dies ist nicht immer auf demselben Gerät möglich, es ist jedoch sehr wichtig, dass es sich um eine Kopie der Datenbank in voller Größe handelt. Das ist es, was ich schon seit mehreren Jahren predige. Und vor einem Jahr habe ich darüber gesprochen, Sie können alles auf YouTube ansehen.
Vielleicht ist unsere Ausrüstung schlecht? Wenn Sie hinschauen, dann ist die Latenz sprunghaft angestiegen. Wir haben gesehen, dass die Auslastung bei 100 % liegt. Wenn es sich natürlich um moderne NVMe-Laufwerke handeln würde, wäre es für uns wahrscheinlich viel einfacher. Und vielleicht würden wir nicht aufgeben.
Wenn Sie über Clouds verfügen, kann das Upgrade dort problemlos durchgeführt werden. Neue Replikate auf der neuen Hardware erstellt. Umschalten. Und alles ist gut. Ziemlich einfach.
Ist es möglich, die kleineren Festplatten irgendwie zu berühren? Und hier tauchen wir, allein mit Hilfe von DBA, in ein bestimmtes Thema namens Checkpoint-Tuning ein. Es stellte sich heraus, dass wir kein Checkpoint-Tuning hatten.
Was ist ein Checkpoint? Es ist in jedem DBMS vorhanden. Wenn sich Daten im Speicher ändern, werden diese nicht sofort auf die Festplatte geschrieben. Die Information, dass sich die Daten geändert haben, wird zunächst in das Write-Ahead-Protokoll geschrieben. Und irgendwann entscheidet das DBMS, dass es an der Zeit ist, echte Seiten auf die Festplatte zu sichern, damit wir bei einem Fehler weniger REDO durchführen können. Es ist wie ein Spielzeug. Wenn wir getötet werden, beginnen wir das Spiel am letzten Kontrollpunkt. Und alle DBMS implementieren es.
Die Einstellungen in Postgres hinken hinterher. Sie sind für 10–15 Jahre alte Daten- und Transaktionsvolumina ausgelegt. Und Checkpoint ist keine Ausnahme.
Hier sind die Informationen aus unserem Postgres-Check-up-Bericht, also dem automatischen Gesundheitscheck. Und hier ist eine Datenbank mit mehreren Terabyte. Und es ist gut zu erkennen, dass es in fast 90 % der Fälle zu Zwangskontrollen kommt.
Was bedeutet das? Da gibt es zwei Einstellungen. Der Checkpoint kann durch Timeout beispielsweise in 10 Minuten erreicht werden. Oder es kann passieren, wenn ziemlich viele Daten ausgefüllt wurden.
Und standardmäßig ist max_wal_saze auf 1 Gigabyte eingestellt. Tatsächlich passiert dies in Postgres tatsächlich nach 300-400 Megabyte. Sie haben so viele Daten geändert und Ihr Checkpoint passiert.
Und wenn niemand es optimiert hat und der Service gewachsen ist und das Unternehmen viel Geld verdient und viele Transaktionen hat, dann kommt der Checkpoint einmal pro Minute, manchmal alle 30 Sekunden und manchmal sogar überlappend. Das ist ziemlich schlimm.
Und wir müssen dafür sorgen, dass es seltener vorkommt. Das heißt, wir können max_wal_size erhöhen. Und es wird seltener kommen.
Aber wir haben eine ganze Methodik entwickelt, wie man es richtiger macht, das heißt, wie man eine Entscheidung über die Wahl der Einstellungen trifft, eindeutig auf der Grundlage spezifischer Daten.
Dementsprechend führen wir zwei Versuchsreihen zu Datenbanken durch.
Die erste Serie – wir ändern max_wal_size. Und wir führen eine riesige Operation durch. Zuerst machen wir es mit der Standardeinstellung von 1 Gigabyte. Und wir führen einen massiven DELETE-Vorgang für viele Millionen Zeilen durch.
Sie sehen, wie schwer es für uns ist. Wir sehen, dass die Festplatten-IO sehr schlecht ist. Wir schauen uns an, wie viele WALs wir generiert haben, denn das ist sehr wichtig. Mal sehen, wie oft der Checkpoint passiert ist. Und wir sehen, dass es nicht gut ist.
Als nächstes erhöhen wir max_wal_size. Wir wiederholen. Wir erhöhen, wir wiederholen. Und so oft. Im Prinzip sind 10 Punkte gut, wobei 1, 2, 4, 8 Gigabyte. Und wir betrachten das Verhalten eines bestimmten Systems. Es ist klar, dass hier die Ausrüstung wie bei Produkt sein sollte. Sie müssen über dieselben Festplatten, dieselbe Speichermenge und dieselben Postgres-Einstellungen verfügen.
Und auf diese Weise tauschen wir unser System aus und wissen, wie sich das DBMS im Falle eines fehlerhaften Massen-DELETE verhält und wie es einen Checkpoint durchführt.
Checkpoint auf Russisch sind Checkpoints.
Beispiel: Mehrere Millionen Zeilen nach Index löschen, die Zeilen sind über die Seiten „verstreut“.
Hier ist ein Beispiel. Das ist eine Basis. Und mit der Standardeinstellung von 1 Gigabyte für max_wal_size ist es ganz klar, dass unsere Festplatten zur Aufnahme ins Regal kommen. Dieses Bild ist ein typisches Symptom eines sehr kranken Patienten, das heißt, ihm ging es wirklich schlecht. Und es gab eine einzige Operation, es gab nur ein DELETE von mehreren Millionen Zeilen.
Wenn eine solche Operation in Prod erlaubt ist, werden wir uns einfach hinlegen, denn es ist klar, dass ein DELETE uns im Regal tötet.
Außerdem ist bei 16 Gigabyte klar, dass die Zähne bereits verschwunden sind. Die Zähne sind schon besser, das heißt, wir klopfen an die Decke, aber nicht so schlimm. Da gab es eine gewisse Freiheit. Rechts ist die Aufzeichnung. Und die Anzahl der Operationen - das zweite Diagramm. Und es ist klar, dass wir bei 16 Gigabyte schon etwas leichter atmen.
Und bei 64 Gigabyte sieht man, dass es komplett besser geworden ist. Sobald die Zähne ausgeprägt sind, bestehen mehr Möglichkeiten, andere Operationen zu überstehen und etwas mit der Bandscheibe zu tun.
Warum ist das so?
Ich werde ein wenig auf die Details eingehen, aber dieses Thema, wie man Checkpoint-Tuning durchführt, kann zu einem ganzen Bericht führen, daher werde ich nicht viel laden, aber ich werde ein wenig skizzieren, welche Schwierigkeiten es gibt.
Wenn der Prüfpunkt zu oft auftritt und wir unsere Zeilen nicht nacheinander aktualisieren, sondern nach dem Index suchen, was gut ist, da wir nicht die gesamte Tabelle löschen, kann es vorkommen, dass wir zuerst die erste Seite berührt haben, dann die tausendste. und kehrte dann zum ersten zurück. Und wenn Checkpoint zwischen diesen Besuchen der ersten Seite diese bereits auf der Festplatte gespeichert hat, wird sie erneut gespeichert, da wir sie ein zweites Mal verschmutzt haben.
Und wir werden Checkpoint dazu zwingen, es viele Male zu speichern. Wie würde es für ihn zu überflüssigen Operationen kommen?
Aber das ist noch nicht alles. Seiten sind in Postgres 8 Kilobyte und in Linux 4 Kilobyte groß. Und es gibt eine full_page_writes-Einstellung. Es ist standardmäßig aktiviert. Und das ist richtig, denn wenn wir es ausschalten, besteht die Gefahr, dass bei einem Absturz nur die Hälfte der Seite gespeichert wird.
Das Verhalten beim Schreiben in die WAL des Forward-Logs ist so, dass, wenn wir einen Prüfpunkt haben und die Seite zum ersten Mal ändern, die gesamte Seite, d. h. alle 8 Kilobyte, in das Forward-Log gelangt, obwohl wir nur die Seite geändert haben Zeile, die 100 Bytes wiegt. Und wir müssen die gesamte Seite aufschreiben.
Bei späteren Änderungen wird es nur ein bestimmtes Tupel geben, aber zum ersten Mal schreiben wir alles auf.
Und dementsprechend müssen wir, wenn der Checkpoint erneut auftritt, alles noch einmal von vorne beginnen und die gesamte Seite pushen. Bei häufigen Prüfpunkten, wenn wir durch dieselben Seiten gehen, wird full_page_writes = on mehr sein, als es sein könnte, d. h. wir generieren mehr WAL. Mehr wird an Replikate, an das Archiv, an die Festplatte gesendet.
Und dementsprechend haben wir zwei Entlassungen.
Wenn wir max_wal_size erhöhen, stellt sich heraus, dass wir es sowohl für den Checkpoint als auch für den Wal-Writer einfacher machen. Und das ist großartig.
Geben wir ein Terabyte rein und leben damit. Was ist daran schlecht? Das ist schlecht, denn im Falle eines Ausfalls werden wir stundenlang klettern, da der Kontrollpunkt schon lange her ist und sich bereits viel geändert hat. Und wir müssen das alles REDO machen. Und so machen wir die zweite Versuchsreihe.
Wir führen eine Operation durch und sehen, wann der Checkpoint bald abgeschlossen ist. Wir töten -9 Postgres absichtlich.
Und danach starten wir es erneut und sehen, wie lange es auf diesem Gerät ansteigt, d. h. um wie viel es in dieser schlechten Situation REDO wird.
Zweimal werde ich feststellen, dass die Situation schlecht ist. Erstens sind wir kurz vor Ende des Kontrollpunkts abgestürzt, also haben wir viel zu verlieren. Und zweitens hatten wir eine riesige Operation. Und wenn die Prüfpunkte eine Zeitüberschreitung hätten, würde höchstwahrscheinlich seit dem letzten Prüfpunkt weniger WAL generiert werden. Das heißt, es ist ein doppelter Verlierer.
Wir messen eine solche Situation für verschiedene max_wal_size-Größen und gehen davon aus, dass, wenn max_wal_size 64 Gigabyte beträgt, wir im schlimmsten Fall im doppelten Fall 10 Minuten lang klettern werden. Und wir überlegen, ob es uns passt oder nicht. Dies ist eine geschäftliche Frage. Dieses Bild müssen wir den unternehmerischen Entscheidungsträgern vor Augen führen und fragen: „Wie lange können wir im Falle eines Problems höchstens liegen bleiben?“ Können wir uns in der schlimmsten Situation 3-5 Minuten lang hinlegen? Und Sie treffen eine Entscheidung.
Und hier ist ein interessanter Punkt. Wir haben ein paar Berichte über Patroni auf der Konferenz. Und vielleicht nutzen Sie es. Dies ist ein Autofailover für Postgres. GitLab und Data Egret haben darüber gesprochen.
Und wenn Sie einen automatischen Failover haben, der in 30 Sekunden erfolgt, können wir uns dann vielleicht 10 Minuten hinlegen? Denn zu diesem Zeitpunkt werden wir auf die Replik umsteigen und alles wird gut. Das ist ein strittiger Punkt. Ich weiß keine klare Antwort. Ich habe einfach das Gefühl, dass es bei diesem Thema nicht nur um die Wiederherstellung nach einem Absturz geht.
Wenn wir uns nach einem Misserfolg lange erholen, werden wir uns in vielen anderen Situationen unwohl fühlen. Zum Beispiel in denselben Experimenten, wenn wir etwas tun und manchmal 10 Minuten warten müssen.
Ich würde trotzdem nicht zu weit gehen, selbst wenn wir ein automatisches Failover hätten. In der Regel sind Werte wie 64, 100 Gigabyte gute Werte. Manchmal lohnt es sich sogar, weniger zu wählen. Im Allgemeinen ist dies eine subtile Wissenschaft.
Um Iterationen durchzuführen, zum Beispiel max_wal_size =1, 8, müssen Sie die Massenoperation viele Male wiederholen. Du hast es geschafft. Und auf der gleichen Basis möchten Sie es noch einmal machen, haben aber bereits alles gelöscht. Was zu tun ist?
Ich werde später über unsere Lösung sprechen und darüber, was wir tun, um in solchen Situationen zu iterieren. Und das ist der richtigste Ansatz.
Aber in diesem Fall hatten wir Glück. Wenn, wie es hier heißt, „BEGIN, DELETE, ROLLBACK“, dann können wir DELETE wiederholen. Das heißt, wenn wir es selbst abgesagt haben, können wir es wiederholen. Und physisch liegen die Daten bei Ihnen am selben Ort. Es kommt nicht einmal zu Blähungen. Sie können über solche DELETEs iterieren.
Dieses DELETE mit ROLLBACK ist ideal für die Checkpoint-Optimierung, selbst wenn Sie nicht über ordnungsgemäß bereitgestellte Datenbanklabore verfügen.
Wir haben eine Platte mit einer Spalte „i“ gemacht. Postgres verfügt über Utility-Spalten. Sie sind unsichtbar, sofern nicht ausdrücklich darum gebeten wird. Dies sind: ctid, xmid, xmax.
Ctid ist eine physische Adresse. Nullseite, das erste Tupel auf der Seite.
Es ist ersichtlich, dass das Tupel nach ROOLBACK an der gleichen Stelle blieb. Das heißt, wir können es noch einmal versuchen, es wird sich genauso verhalten. Das ist wichtig.
Xmax ist der Zeitpunkt des Todes des Tupels. Es wurde gestempelt, aber Postgres weiß, dass die Transaktion zurückgesetzt wurde, daher spielt es keine Rolle, ob sie 0 ist oder es sich um eine zurückgesetzte Transaktion handelt. Dies legt nahe, dass es möglich ist, über DELETE zu iterieren und die Massenvorgänge des Systemverhaltens zu überprüfen. Sie können Datenbanklabore für die Armen einrichten.
Hier geht es um Programmierer. Auch in Bezug auf DBA schimpfen sie Programmierer immer: „Warum führen Sie so lange und schwierige Operationen durch?“. Das ist ein ganz anderes senkrechtes Thema. Früher gab es Verwaltung, jetzt wird es Entwicklung geben.
Offensichtlich sind wir nicht in Stücke zerbrochen. Das ist klar. Es ist unmöglich, ein solches DELETE für einen Haufen von Millionen Zeilen nicht in Teile aufzubrechen. Es wird 20 Minuten lang gemacht und alles wird liegen. Aber leider machen auch erfahrene Entwickler Fehler, selbst in sehr großen Unternehmen.
Warum ist es wichtig zu brechen?
-
Wenn wir feststellen, dass die Festplatte hart ist, verlangsamen wir sie. Und wenn wir mal kaputt sind, dann können wir Pausen einbauen, wir können die Drosselung verlangsamen.
-
Und wir werden andere noch lange nicht blockieren. In einigen Fällen spielt es keine Rolle, wenn Sie echten Müll löschen, an dem niemand arbeitet, dann werden Sie höchstwahrscheinlich niemanden außer der Autovacuum-Arbeit blockieren, da diese auf den Abschluss der Transaktion wartet. Wenn Sie jedoch etwas entfernen, das jemand anderes anfordern kann, wird dieser blockiert und es kommt zu einer Art Kettenreaktion. Lange Transaktionen sollten auf Websites und mobilen Anwendungen vermieden werden.
Das ist interessant. Ich sehe oft, dass Entwickler fragen: „Welche Packungsgröße soll ich wählen?“.
Es ist klar, dass der Transaktions-Overhead, d. h. der zusätzliche Overhead durch Transaktionen, umso geringer ist, je größer die Bündelgröße ist. Gleichzeitig erhöht sich aber auch die Zeit für diese Transaktion.
Ich habe eine ganz einfache Regel: Nehmen Sie so viel wie möglich, aber überschreiten Sie nicht die Anzahl der ausführbaren Dateien pro Sekunde.
Warum eine Sekunde? Die Erklärung ist sehr einfach und für jeden verständlich, auch für Nicht-Techniker. Wir sehen eine Reaktion. Nehmen wir 50 Millisekunden. Wenn sich etwas verändert hat, reagiert unser Auge. Wenn weniger, dann schwieriger. Wenn etwas nach 100 Millisekunden antwortet, Sie zum Beispiel mit der Maus geklickt haben und diese Ihnen nach 100 Millisekunden geantwortet hat, spüren Sie bereits diese leichte Verzögerung. Eine Sekunde wird bereits als Bremse wahrgenommen.
Wenn wir also unsere Massenoperationen in 10-Sekunden-Schübe aufteilen, besteht die Gefahr, dass wir jemanden blockieren. Und es wird für ein paar Sekunden funktionieren, und die Leute werden es bereits bemerken. Deshalb mache ich es lieber nicht länger als eine Sekunde. Aber teilen Sie es gleichzeitig nicht sehr fein auf, da der Transaktionsaufwand spürbar sein wird. Die Basis wird härter und es können andere Probleme auftreten.
Wir wählen die Größe der Packung. In jedem Fall können wir es anders machen. Kann automatisiert werden. Und wir sind von der Effizienz der Verarbeitung einer Packung überzeugt. Das heißt, wir löschen ein Paket oder aktualisieren es.
Übrigens geht es bei allem, worüber ich spreche, nicht nur um DELETE. Wie Sie vermutet haben, handelt es sich dabei um Massenoperationen an Daten.
Und wir sehen, dass der Plan ausgezeichnet ist. Sie können den Index-Scan sehen, der Index-Only-Scan ist sogar noch besser. Und es handelt sich um eine kleine Datenmenge. Und weniger als eine Sekunde erfüllt. Super.
Und wir müssen weiterhin sicherstellen, dass es zu keiner Verschlechterung kommt. Es kommt vor, dass die ersten Packungen schnell klappen und es dann immer schlimmer wird. Der Prozess ist so, dass Sie viel testen müssen. Genau dafür sind Datenbanklabore da.
Und wir müssen noch etwas vorbereiten, damit wir das in der Produktion richtig umsetzen können. Wir können zum Beispiel die Zeit in das Protokoll schreiben, wir können schreiben, wo wir jetzt sind und wen wir jetzt gelöscht haben. Und so können wir später verstehen, was passiert. Und falls etwas schief geht, finden Sie schnell das Problem.
Wenn wir die Effizienz von Anfragen überprüfen und viele Male iterieren müssen, dann gibt es so etwas wie einen Mit-Bot. Er ist schon bereit. Es wird täglich von Dutzenden Entwicklern verwendet. Und er versteht es, einer riesigen Terabyte-Datenbank auf Wunsch in 30 Sekunden eine eigene Kopie zu geben. Und Sie können dort etwas löschen und RESET sagen und es erneut löschen. Auf diese Weise können Sie damit experimentieren. Ich sehe eine Zukunft für dieses Ding. Und wir tun es bereits.
Was sind Partitionierungsstrategien? Ich sehe drei verschiedene Partitionierungsstrategien, die die Entwickler des Pakets verwenden.
Der erste ist sehr einfach. Wir haben eine numerische ID. Und lasst es uns in verschiedene Intervalle aufteilen und damit arbeiten. Der Nachteil ist klar. Im ersten Abschnitt haben wir möglicherweise 100 Zeilen echten Mülls, im zweiten 5 Zeilen oder gar keinen, oder alle 1 Zeilen erweisen sich als Müll. Die Arbeit ist sehr ungleichmäßig, kann aber leicht brechen. Sie nahmen den Höchstausweis und zerschmetterten ihn. Das ist ein naiver Ansatz.
Die zweite Strategie ist ein ausgewogener Ansatz. Es wird in Gitlab verwendet. Sie nahmen den Tisch und scannten ihn. Wir haben die Grenzen der ID-Pakete so festgelegt, dass jedes Paket genau 10 Datensätze enthielt. Und stellen Sie sie in eine Warteschlange. Und dann verarbeiten wir. Sie können dies in mehreren Threads tun.
Auch bei der ersten Strategie können Sie dies übrigens in mehreren Threads tun. Es ist nicht schwer.
Aber es gibt einen cooleren und besseren Ansatz. Dies ist die dritte Strategie. Und wenn möglich, ist es besser, es zu wählen. Wir tun dies auf Basis eines speziellen Indexes. In diesem Fall handelt es sich höchstwahrscheinlich um einen Index entsprechend unserem Müllzustand und unserer ID. Wir werden die ID einbeziehen, damit es sich nur um einen Index-Scan handelt, sodass wir nicht zum Heap gehen.
Im Allgemeinen ist der Nur-Index-Scan schneller als der Index-Scan.
Und wir finden schnell unsere IDs, die wir löschen möchten. BATCH_SIZE wählen wir im Voraus aus. Und wir bekommen sie nicht nur, wir bekommen sie auf eine besondere Art und Weise und hacken sie sofort. Aber wir sperren, sodass wir, wenn sie bereits gesperrt sind, sie nicht sperren, sondern weitermachen und die nächsten nehmen. Dies ist für das Überspringen von Updates gesperrt. Diese tolle Funktion von Postgres ermöglicht es uns, bei Bedarf in mehreren Threads zu arbeiten. Es ist in einem Stream möglich. Und hier gibt es einen CTE – das ist eine Anfrage. Und im zweiten Stock dieses CTE ist eine echte Streichung im Gange – returning *. Sie können die ID zurückgeben, aber es ist besser *wenn Sie nicht viele Daten in jeder Zeile haben.
Warum brauchen wir es? Das ist es, was wir zurückmelden müssen. Wir haben jetzt tatsächlich so viele Zeilen gelöscht. Und wir haben Grenzen nach ID oder nach erstelltem_at wie folgt. Sie können min, max tun. Es kann noch etwas anderes getan werden. Hier kann man viel stopfen. Und es ist sehr praktisch für die Überwachung.
Es gibt noch eine Anmerkung zum Index. Wenn wir beschließen, dass wir für diese Aufgabe einen speziellen Index benötigen, müssen wir sicherstellen, dass dadurch die Aktualisierungen nur der Heap-Tupel nicht beeinträchtigt werden. Das heißt, Postgres verfügt über solche Statistiken. Dies ist in pg_stat_user_tables für Ihre Tabelle ersichtlich. Sie können sehen, ob Hot-Updates verwendet werden oder nicht.
Es gibt Situationen, in denen Ihr neuer Index sie einfach abschneiden kann. Und wenn Sie alle anderen Updates haben, die bereits funktionieren, machen Sie es langsamer. Nicht nur, weil der Index aufgetaucht ist (jeder Index verlangsamt Aktualisierungen ein wenig, aber ein wenig), sondern hier ruiniert er ihn immer noch. Und es ist unmöglich, für diese Tabelle eine spezielle Optimierung vorzunehmen. Das kommt manchmal vor. Das ist eine Subtilität, an die sich nur wenige Menschen erinnern. Und dieser Rechen ist leicht zu betreten. Manchmal kommt es vor, dass Sie einen Ansatz von der anderen Seite finden und trotzdem auf diesen neuen Index verzichten müssen, einen anderen Index erstellen oder auf andere Weise beispielsweise die zweite Methode verwenden müssen.
Dies ist jedoch die optimalste Strategie, wie man in Chargen aufteilt und mit einer einzigen Anfrage auf Chargen schießt, ein wenig löscht usw.
Lange Transaktionen
Blockiertes Autovakuum -
Blockierungsproblem -
Fehler Nr. 5 ist ein großer. Nikolai von Okmeter sprach über die Postgres-Überwachung. Eine ideale Postgres-Überwachung gibt es leider nicht. Manche sind näher, manche weiter. Okmeter ist nah genug an der Perfektion, aber es fehlt viel und muss hinzugefügt werden. Darauf müssen Sie vorbereitet sein.
Beispielsweise werden tote Tupel am besten überwacht. Wenn Sie viele tote Dinge in der Tabelle haben, stimmt etwas nicht. Es ist besser, jetzt zu reagieren, sonst kann es zu einer Verschlechterung kommen und wir können uns hinlegen. So etwas passiert.
Wenn es eine große E/A gibt, ist klar, dass dies nicht gut ist.
Auch lange Transaktionen. Lange Transaktionen sollten auf OLTP nicht erlaubt sein. Und hier ist ein Link zu einem Snippet, mit dem Sie dieses Snippet verwenden und bereits lange Transaktionen verfolgen können.
Warum sind lange Transaktionen schlecht? Denn alle Sperren werden erst am Ende freigegeben. Und wir verarschen alle. Außerdem blockieren wir das automatische Vakuumieren für alle Tische. Es ist überhaupt nicht gut. Selbst wenn Sie Hot Standby auf dem Replikat aktiviert haben, ist es immer noch schlecht. Im Allgemeinen ist es nirgendwo besser, lange Transaktionen zu vermeiden.
Wenn wir viele Tische haben, die nicht gesaugt werden, dann brauchen wir eine Warnung. Hier ist eine solche Situation möglich. Wir können den Betrieb des Autovakuums indirekt beeinflussen. Dies ist ein Ausschnitt aus Avito, den ich leicht verbessert habe. Und es erwies sich als interessantes Werkzeug, um zu sehen, was wir mit dem Autovakuum haben. Einige Tische warten beispielsweise dort und warten nicht, bis sie an der Reihe sind. Sie müssen es auch in die Überwachung versetzen und eine Warnung haben.
Und gibt Blöcke aus. Wald aus Blockbäumen. Ich mag es, etwas von jemandem zu nehmen und es zu verbessern. Hier habe ich einen coolen rekursiven CTE von Data Egret genommen, der einen Wald aus Lockbäumen zeigt. Dies ist ein gutes Diagnosetool. Und auf dieser Basis können Sie auch ein Monitoring aufbauen. Dies muss jedoch sorgfältig erfolgen. Sie müssen ein kleines Statement_timeout für sich selbst erstellen. Und lock_timeout ist wünschenswert.
Manchmal treten alle diese Fehler in der Summe auf.
Meiner Meinung nach ist der Hauptfehler hier organisatorischer Natur. Es ist organisatorisch, weil die Technik nicht zieht. Das ist Nummer 2 – sie haben an der falschen Stelle eingecheckt.
Wir haben an der falschen Stelle nachgeschaut, weil wir keinen Produktionsklon hatten, der leicht zu überprüfen ist. Ein Entwickler hat möglicherweise überhaupt keinen Zugriff auf die Produktion.
Und wir haben dort nicht nachgesehen. Wenn wir dort nachgesehen hätten, hätten wir es selbst gesehen. Der Entwickler hat alles auch ohne DBA gesehen, wenn er es in einer guten Umgebung überprüft hat, in der die gleiche Datenmenge und der identische Speicherort vorhanden sind. Er hätte all diese Erniedrigung gesehen und würde sich schämen.
Mehr über Autovakuum. Nachdem wir mehrere Millionen Zeilen massiv durchsucht haben, müssen wir noch REPACK durchführen. Dies ist besonders wichtig für Indizes. Sie werden sich schlecht fühlen, nachdem wir dort alles gereinigt haben.
Und wenn Sie die tägliche Reinigungsarbeit zurückholen möchten, dann würde ich vorschlagen, sie häufiger, aber kleiner, durchzuführen. Es kann einmal pro Minute oder auch etwas öfter sein. Und Sie müssen zwei Dinge überwachen: dass dieses Ding keine Fehler hat und dass es nicht hinterherhinkt. Der Trick, den ich gezeigt habe, wird dieses Problem einfach lösen.
Was wir tun, ist Open Source. Es ist auf GitLab veröffentlicht. Und wir sorgen dafür, dass Menschen auch ohne DBA prüfen können. Wir führen ein Datenbanklabor durch, das heißt, wir rufen die Basiskomponente auf, an der Joe gerade arbeitet. Und Sie können sich eine Kopie der Produktion sichern. Jetzt gibt es eine Implementierung von Joe für Slack, Sie können dort sagen: „Erklären Sie diese und jene Anfrage“ und erhalten Sie sofort das Ergebnis für Ihre Kopie der Datenbank. Dort kann man sogar LÖSCHEN, ohne dass es jemandem auffällt.
Nehmen wir an, Sie haben 10 Terabyte, wir machen das Datenbanklabor ebenfalls auf 10 Terabyte. Und mit gleichzeitigen 10-Terabyte-Datenbanken können 10 Entwickler gleichzeitig arbeiten. Jeder kann machen, was er will. Kann löschen, löschen usw. Das ist so eine Fantasie. Wir werden morgen darüber sprechen.
Dies wird als Thin Provisioning bezeichnet. Dies ist eine subtile Bereitstellung. Dies ist eine Art Fantasie, die Verzögerungen bei der Entwicklung und beim Testen erheblich beseitigt und die Welt in dieser Hinsicht zu einem besseren Ort macht. Das heißt, Sie können damit lediglich Probleme bei Massenvorgängen vermeiden.
Beispiel: 5-Terabyte-Datenbank, eine Kopie wird in weniger als 30 Sekunden erstellt. Dabei kommt es nicht einmal auf die Größe an, das heißt, es spielt keine Rolle, wie viele Terabyte es sind.
Heute können Sie gehen und stöbern Sie in unseren Werkzeugen. Sie können sich registrieren, um zu sehen, was es gibt. Sie können diesen Bot installieren. Es ist kostenlos. Schreiben.
Fragen
In realen Situationen stellt sich sehr oft heraus, dass viel weniger Daten in der Tabelle verbleiben sollten, als gelöscht werden müssen. Das heißt, in einer solchen Situation ist es oft einfacher, einen solchen Ansatz zu implementieren, wenn es einfacher ist, ein neues Objekt zu erstellen, nur die erforderlichen Daten dorthin zu kopieren und die alte Tabelle zu bündeln. Es ist klar, dass für diesen Moment, während Sie wechseln werden, ein programmatischer Ansatz erforderlich ist. Wie ist dieser Ansatz?
Das ist ein sehr guter Ansatz und eine sehr gute Aufgabe. Es ist sehr ähnlich zu dem, was pg_repack macht, es ist sehr ähnlich zu dem, was Sie tun müssen, wenn Sie IDs auf 4 Bytes festlegen. Viele Frameworks haben dies vor einigen Jahren getan, und nur die Platten sind erwachsen geworden und müssen auf 8 Byte konvertiert werden.
Diese Aufgabe ist ziemlich schwierig. Wir haben es geschafft. Und man muss sehr vorsichtig sein. Es gibt Schlösser usw. Aber es wird gemacht. Das heißt, der Standardansatz besteht darin, pg_repack zu verwenden. Sie deklarieren ein solches Etikett. Und bevor Sie mit dem Hochladen von Snapshot-Daten beginnen, deklarieren Sie auch eine Platte, die alle Änderungen verfolgt. Es gibt einen Trick, der dazu führt, dass Sie einige Änderungen möglicherweise nicht einmal verfolgen. Es gibt Feinheiten. Und dann wechseln Sie durch rollierende Änderungen. Es wird eine kurze Pause geben, in der wir alle schließen, aber im Allgemeinen wird dies getan.
Wenn Sie sich pg_repack auf GitHub ansehen, dann gab es dort, als es eine Aufgabe gab, eine ID von int 4 in int 8 zu konvertieren, die Idee, pg_repack selbst zu verwenden. Das ist auch möglich, aber es ist ein bisschen kompliziert, aber es wird auch hier funktionieren. Sie können in den Trigger eingreifen, den pg_repack verwendet, und dort sagen: „Wir brauchen diese Daten nicht“, d. h. wir übertragen nur das, was wir brauchen. Und dann wechselt er einfach und das wars.
Mit diesem Ansatz erhalten wir immer noch eine zweite Kopie der Tabelle, in der die Daten bereits indiziert und mit schönen Indizes sehr gleichmäßig gestapelt sind.
Blähungen gibt es nicht, es ist ein guter Ansatz. Ich weiß aber, dass es Versuche gibt, hierfür eine Automatisierung zu entwickeln, also eine universelle Lösung zu schaffen. Ich kann Sie mit dieser Automatisierung in Kontakt bringen. Es ist in Python geschrieben, was eine gute Sache ist.
Ich komme nur ein wenig aus der Welt von MySQL, also bin ich gekommen, um zuzuhören. Und diesen Ansatz nutzen wir.
Aber nur, wenn wir 90 % haben. Wenn wir 5 % haben, ist es nicht sehr gut, sie zu nutzen.
Danke für den Bericht! Gibt es einen Algorithmus oder eine Formel zur Berechnung der Last oder Größe, wenn keine Ressourcen zum Erstellen einer vollständigen Kopie des Produkts vorhanden sind?
Gute Frage. Bisher sind wir in der Lage, Multi-Terabyte-Datenbanken zu finden. Auch wenn die Hardware dort nicht die gleiche ist, zum Beispiel weniger Speicher, weniger Prozessor und Festplatten, sind sie nicht genau gleich, aber wir machen es trotzdem. Wenn es absolut nirgendwo ist, müssen Sie nachdenken. Lass mich bis morgen nachdenken, du bist gekommen, wir werden reden, das ist eine gute Frage.
Danke für den Bericht! Sie haben zunächst davon gesprochen, dass es ein cooles Postgres gibt, das gewisse Einschränkungen aufweist, sich aber weiterentwickelt. Und das ist alles im Großen und Ganzen eine Krücke. Steht das nicht alles im Widerspruch zur Entwicklung von Postgres selbst, in dem ein DELETE-Deferent auftauchen wird oder etwas anderes, das das, was wir hier mit einigen unserer seltsamen Mittel zu verschmieren versuchen, auf einem niedrigen Niveau halten sollte?
Wenn wir in SQL gesagt haben, dass in einer Transaktion viele Datensätze gelöscht oder aktualisiert werden sollen, wie kann Postgres sie dann dort verteilen? Wir sind im Betrieb körperlich eingeschränkt. Wir werden es noch lange tun. Und wir werden zu diesem Zeitpunkt sperren usw.
Fertig mit Indizes.
Ich kann davon ausgehen, dass die gleiche Checkpoint-Abstimmung automatisiert werden könnte. Eines Tages könnte es soweit sein. Aber dann verstehe ich die Frage nicht wirklich.
Die Frage ist: Gibt es einen solchen Entwicklungsvektor, der hin und her geht und der Ihre parallel verläuft? Diese. Haben sie noch nicht darüber nachgedacht?
Ich habe über die Prinzipien gesprochen, die jetzt angewendet werden können. Es gibt einen anderen Bot , damit können Sie ein automatisiertes Checkpoint-Tuning durchführen. Wird es eines Tages in Postgres sein? Ich weiß es nicht, es wurde noch nicht einmal besprochen. Davon sind wir noch weit entfernt. Aber es gibt Wissenschaftler, die neue Systeme entwickeln. Und sie drängen uns in automatische Indizes. Es gibt Entwicklungen. Schauen Sie sich zum Beispiel Autotuning an. Die Parameter werden automatisch ausgewählt. Aber er wird noch kein Checkpoint-Tuning für Sie durchführen. Das heißt, es nimmt Leistung, Shell-Puffer usw. zu.
Und für die Checkpoint-Optimierung können Sie Folgendes tun: Wenn Sie tausend Cluster und unterschiedliche Hardware sowie unterschiedliche virtuelle Maschinen in der Cloud haben, können Sie unseren Bot verwenden Automatisierung durchführen. Und max_wal_size wird automatisch entsprechend Ihren Zieleinstellungen ausgewählt. Aber bisher ist das im Kern leider noch nicht einmal annähernd der Fall.
Guten Tag! Sie haben über die Gefahren langer Transaktionen gesprochen. Sie sagten, dass das Autovakuum bei Löschungen blockiert wird. Wie schadet es uns sonst noch? Weil es mehr darum geht, Speicherplatz freizugeben und ihn nutzen zu können. Was fehlt uns sonst noch?
Autovakuum ist hier vielleicht nicht das größte Problem. Und die Tatsache, dass eine lange Transaktion andere Transaktionen sperren kann, macht diese Möglichkeit noch gefährlicher. Sie kann sich treffen oder auch nicht. Wenn sie sich trifft, kann es sehr schlimm sein. Und beim Autovakuum ist das auch ein Problem. Bei langen Transaktionen in OLTP gibt es zwei Probleme: Sperren und Autovacuum. Und wenn Sie Hot-Standby-Feedback auf dem Replikat aktiviert haben, erhalten Sie trotzdem eine Autovacuum-Sperre auf dem Master, diese kommt vom Replikat. Aber zumindest wird es keine Sperren geben. Und es wird Loks geben. Da es sich um Datenänderungen handelt, sind Sperren hier ein wichtiger Punkt. Und wenn das alles noch sehr lange so ist, dann werden immer mehr Transaktionen gesperrt. Sie können andere stehlen. Und Lok-Bäume erscheinen. Ich habe einen Link zum Snippet bereitgestellt. Und dieses Problem macht sich schneller bemerkbar als das Problem mit dem Autovakuum, das sich nur anhäufen kann.
Danke für den Bericht! Sie haben Ihren Bericht damit begonnen, dass Sie gesagt haben, dass Sie falsch getestet haben. Wir setzten unsere Idee fort, dass wir die gleiche Ausrüstung mit der gleichen Basis mitnehmen müssen. Nehmen wir an, wir haben dem Entwickler eine Basis gegeben. Und er kam der Bitte nach. Und es scheint ihm gut zu gehen. Er prüft aber nicht auf Live, aber bei Live haben wir zum Beispiel eine Auslastung von 60-70 %. Und selbst wenn wir diese Abstimmung verwenden, funktioniert es nicht sehr gut.
Es ist wichtig, einen Experten im Team zu haben und DBA-Experten einzusetzen, die vorhersagen können, was bei einer echten Hintergrundlast passieren wird. Als wir gerade unsere sauberen Änderungen vorgenommen haben, sehen wir das Bild. Aber ein fortgeschrittenerer Ansatz, bei dem wir das Gleiche noch einmal gemacht haben, aber mit einer mit der Produktion simulierten Belastung. Es ist ziemlich cool. Bis dahin muss man erwachsen werden. Es ist wie ein Erwachsener. Wir haben einfach geschaut, was wir haben und auch geschaut, ob wir genug Ressourcen haben. Das ist eine gute Frage.
Wenn wir bereits eine Müllauswahl durchführen und beispielsweise eine gelöschte Flagge haben
Dies ist, was Autovacuum in Postgres automatisch tut.
Oh, macht er das?
Autovacuum ist der Müllsammler.
Vielen Dank!
Danke für den Bericht! Gibt es eine Möglichkeit, eine Datenbank mit Partitionierung sofort so zu entwerfen, dass der gesamte Müll irgendwo an der Seite von der Haupttabelle verschmutzt wird?
Natürlich gibt es.
Ist es dann möglich, uns zu schützen, wenn wir einen Tisch verschlossen haben, der nicht benutzt werden sollte?
Natürlich gibt es. Aber es ist wie eine Henne-Ei-Frage. Wenn wir alle wissen, was in Zukunft passieren wird, dann werden wir natürlich alles cool machen. Aber das Geschäft verändert sich, es gibt neue Rubriken, neue Anfragen. Und dann – ups, wir wollen es entfernen. Aber diese ideale Situation kommt im Leben vor, aber nicht immer. Aber insgesamt ist es eine gute Idee. Einfach abschneiden und fertig.
Source: habr.com