Entfernen von Daten aus einer Shardable-Datenbank

Ein Artikel zur Lösung des Problems der Optimierung des Löschvorgangs von Dateien aus einem Sharded-System. Es geht um ein Projekt zum Teilen und Arbeiten mit Dateien. Das System war vor ungefähr 8 Jahren ein Startup, dann wurde es erfolgreich gedreht und mehrmals verkauft. Das Projekt hat 4 Entwickler, die von Anfang an mit dem Projekt beschäftigt sind, was sehr wertvoll ist. Die Dokumentation hatte traditionell entweder keine Zeit zum Schreiben oder ist nicht sehr relevant.

Warum würdest du das lesen und warum habe ich das alles geschrieben? Ich möchte über einen Rechen sprechen, der sorgfältig im System liegt und so schlägt, dass die Sterne aus den Augen austreten.

Ich möchte Hanna_Hlushakova ein großes Dankeschön für die Zusammenarbeit sagen, das Projekt zum Ende bringen und bei der Vorbereitung des Artikels helfen. Grundsätzlich finden Sie Beschreibungen des Problems und des von uns verwendeten Algorithmus zur Lösung. Es gibt keine Beispiele für Code, Datenstrukturen oder andere notwendige Dinge. Ich weiß nicht, ob meine Erfahrung Ihnen hilft, einen Rechen zu Hause zu vermeiden, aber ich hoffe, Sie bekommen etwas Nützliches. Vielleicht ist dieser Artikel ein absolut unwiderruflicher Verlust an wertvoller Zeit.

Über das Projekt

Das Projekt ist eines der führenden Unternehmen auf dem Gartner-Platz, hat Kundenunternehmen mit mehr als 300.000 Mitarbeitern in den USA und in Europa und mehrere Milliarden Dateien für die Wartung.

Die folgenden Technologien werden im Projekt verwendet: Microsoft, C # .net-Server, MS SQL-Datenbank, 14 aktive Server + 14 im Datenspiegelungsmodus.

Das Datenvolumen beträgt bis zu 4 TB, die konstante Auslastung in Geschäftszeiten beträgt ca. 400.000 Anfragen pro Minute.

Die Datenbank enthält viele Geschäftslogiken:
450 Tische
1000 gespeicherte Prozeduren
80.000 Zeilen SQL-Code
Traditionell hatten sie entweder keine Zeit, die Dokumentation zu schreiben, oder sie ist nicht relevant.

Über die Aufgabe

Die Aufgabe besteht darin, das Löschen von Dateien aus dem Speicher zu wiederholen, die bereits von Clients gelöscht wurden, und die Speicherdauer gelöschter Dateien ist abgelaufen, falls sie wiederhergestellt werden sollen. In der aktuellen Version wurden nach den Berechnungen des Unternehmens selbst die vor einem Jahr gelöschten Dateien auf den Servern gespeichert, obwohl sie laut Geschäftsbedingungen nur einen Monat hätten gespeichert werden müssen. Da einige der Dateien in S3 gespeichert sind, hat das Unternehmen für die zusätzlichen Daten bezahlt, und Kunden, die den On-Premises-Speicher verwendet haben, haben sich gefragt, warum die Dateien mehr Speicherplatz beanspruchen als sie sollten.

Datenbanken Shardovany für den Firmenkunden.

Wie hat das Entfernen früher funktioniert?

Auf einem globalen Server mit Informationen zu allen Dateien im System wurden Bereiche von 15.000 Dateikennungen gebildet.

Anschließend wurde gemäß dem Zeitplan eine Serverumfrage für eine Reihe von Dateikennungen gestartet.
Die Grenzen des Bereichs wurden auf jeden Splitter übertragen.

Shard hat als Antwort gefundene Dateien aus dem Bereich gesendet.

Der Hauptserver fügte die fehlenden Dateien der Warteschlangentabelle zum Löschen in seiner Datenbank hinzu.
Anschließend erhielt der Dienst zum Löschen physischer Dateien aus der Warteschlangentabelle eine Reihe von Kennungen zum Löschen. Anschließend wurde eine Bestätigung gesendet, dass die Dateien gelöscht werden sollen, und für alle Shards wurde geprüft, ob diese Dateien dort verwendet wurden.
Mit zunehmender Anzahl von Dateien begann dieser Ansatz sehr langsam zu funktionieren, da es mehrere Milliarden Dateien gab und die Anzahl der Bereiche signifikant zunahm. Gelöschte Dateien blieben immer noch weniger als 5% im Vergleich zur Gesamtzahl. Es ist sehr ineffizient, Milliarden von Dateien zu sortieren, um mehrere Millionen gelöschter Dateien zu finden.

Wenn ein Benutzer eine Datei löscht, sollte sie beispielsweise 1 Monat lang gespeichert werden, falls sie wiederhergestellt werden muss. Nach diesem Zeitraum sollte die Datei vom Programm aus dem Repository gelöscht werden. Bei der aktuellen Anzahl von Dateien, der Anzahl von Bereichen und der Geschwindigkeit der Bereichsumgehung würde es 1 Jahr dauern, bis der Server alle Bereiche vollständig umgeht.
Es ist klar, dass der Ort nicht freigegeben wurde, und dies führte zu Unzufriedenheit der Benutzer, da ihre Server viel mehr Dateien gespeichert haben, als gemeldet werden sollten. Das Dienstleistungsunternehmen selbst bezahlte einen zusätzlichen Platz auf S3, was für ihn ein direkter Verlust war.

Nur auf S3 wurden zu Beginn der Arbeit 2 Petabyte gelöschter Dateien gespeichert, und dies ist nur in der Cloud. Darüber hinaus gab es Clients, deren Dateien auf ihren dedizierten Servern gespeichert waren, die das gleiche Problem hatten: Der Speicherplatz des Servers wurde von Dateien belegt, die von Benutzern gelöscht, aber nicht vom Server gelöscht wurden.

Was hast du beschlossen zu tun?

Wir haben uns entschlossen, die Entfernungsereignisse zu verfolgen:

• Der Client hat die Datei gelöscht und ist dann abgelaufen.
• Der Benutzer hat die Datei sofort ohne die Möglichkeit einer Wiederherstellung gelöscht.

Beim Löschen einer Datei aus einer Sharded-Datenbank haben wir uns für einen optimistischen Ansatz entschieden und eine der Überprüfungen zur Verwendung entfernt. Wir wussten, dass 99% der Dateien nur innerhalb eines Shards verwendet werden. Wir haben uns entschlossen, die Datei sofort zur Löschwarteschlange hinzuzufügen und den Rest der Shards nicht auf die Verwendung dieser Datei zu überprüfen, da die Überprüfung erneut durchgeführt wird, wenn das Löschen aus dem Speicher den Dienst bestätigt.

Außerdem haben sie den aktuellen Job verlassen, der gelöschte Dateien nach Bereichen überprüft hat, um Dateien hinzuzufügen, die vor der Veröffentlichung der neuen Version gelöscht wurden.

Alles, was auf dem Shard gelöscht wurde, wird in einer Tabelle gesammelt und dann mit Informationen zu allen Dateien auf einen einzelnen Server übertragen.

Auf diesem Server wird es an die Löschwarteschlangentabelle gesendet.

In der Tabelle zum Löschen vor dem Löschen wird überprüft, ob die Datei nicht für alle Shards verwendet wird. Dieser Teil der Überprüfung war vor der Codeänderung hier und sie beschlossen, ihn nicht zu berühren.

Was mussten Sie im Code ändern?

Auf jedem der Shards wurde eine Tabelle hinzugefügt, in die die Kennung der gelöschten Datei geschrieben werden soll.

Wir haben alle Verfahren zum Löschen von Dateien aus der Datenbank gefunden, es gab nur 2. Nachdem der Benutzer die Datei gelöscht hat, liegt die Datei noch einige Zeit in der Datenbank.

Beim Löschen einer Datei aus der Datenbank haben wir dieser lokalen Tabelle einen Eintrag mit gelöschten Dateien hinzugefügt.

Auf dem globalen Server mit Dateien haben sie einen Job erstellt, der eine Liste von Dateien aus Shard-Datenbanken herunterlädt. Wenn Sie nur eine Prozedur aus einer Shardable-Datenbank aufrufen, wird eine DELETE-Datei erstellt und eine Liste der Dateien in OUTPUT angezeigt. In MS SQL Server ist das Ziehen von einem Remoteserver viel schneller als das Einfügen in einen Remoteserver. All dies geschieht in Blöcken.
Diese Dateien werden dann zur Löschwarteschlangentabelle auf dem globalen Server hinzugefügt.
Der Warteschlangentabelle wurde eine Tabelle mit einer Shard-ID hinzugefügt, um festzustellen, woher das Löschereignis stammt.

Wie hat es jeder getestet?

Es gibt 3 Umgebungen:

Dev ist eine Entwicklungsumgebung. Der Code stammt aus dem Entwicklungszweig des Gith. Es ist möglich, eine andere Version des Codes auf IIS bereitzustellen und mehrere Orchestrierungsversionen zu erstellen. Es wird vom Client in VPN eine Verbindung zur Entwicklungsumgebung hergestellt. Bis vor kurzem bestand die Unannehmlichkeit nur bei Datenbanken, da alle Änderungen an der Datenbank die Arbeit anderer Teile des Systems beeinträchtigen können. Dann wurden die Basen lokal gemacht. Bereits laufender Code kann auf Entwickler-Server mit Datenbanken übertragen werden, um nicht die Arbeit aller zu ruinieren. In einer Entwicklungsumgebung befinden sich 3 statt 12 Shards auf dem Produkt. Dies reicht jedoch normalerweise aus, um die Interaktion zu testen.

Staging - Die Umgebung ist mit dem Produkt entsprechend der Version des Codes identisch (fast das gleiche, wie es selten vorkommt, aber die Administratoren ändern das Produkt direkt auf dem Produkt). Eine Kopie des Codes aus dem Hauptzweig. Manchmal wurden einige Unterschiede zum Code auf dem Produkt in der Datenbank festgestellt, aber im Allgemeinen sind sie identisch. Es gibt auch 3 Scherben auf der Inszenierung sowie auf der Jungfrau. Sowohl die Inszenierung als auch die Entwicklung sind nicht belastet. Hier können Sie Integrationstests bereits vollständig ausführen, da der Code mit dem Produkt übereinstimmt. Alle Tests müssen bestanden sein. Dies ist eine Voraussetzung, bevor Sie zur Bereitstellung gehen.

Perf Lab, wo Tests unter Last durchgeführt werden. Die Last wird mit einem Jmeter erzeugt, zehnmal weniger als auf dem Produkt, und es gibt nur einen Splitter, was manchmal zu Unannehmlichkeiten führt. Verkaufsdaten werden erfasst, anonymisiert und im Perf Lab verwendet. Alle Server haben die gleiche Konfiguration wie auf prod.

Die Last ist 10-mal geringer, da angenommen wird, dass dies eine ungefähre Last ist, die für 1 Scherbe zum Stoß kommt. Der Nachteil ist, dass die globale Basis im Gegensatz zum Verkauf sehr wenig ausgelastet ist. Und wenn die Änderungen hauptsächlich die globale Datenbank mit Dateien betreffen, können Sie sich nur annähernd auf die Testergebnisse verlassen - auf dem Produkt funktioniert dies möglicherweise nicht so. Obwohl perf lab die Last nicht ideal auf das Produkt abstimmt, hilft die Möglichkeit, unter der Last zu testen, bereits dabei, viele Fehler zu erkennen, bevor sie auf dem Produkt bereitgestellt werden.

Es gibt auch einen Sicherungsserver, auf dem Sie die Daten aus dem Verkauf anzeigen können, um einige Fälle abzufangen. Im Allgemeinen arbeitet das Unternehmen unter einer Lizenz, die Entwicklern den Zugriff auf Verkaufsdaten und dem Zugriff des Verwaltungs- und Supportteams (Operations) auf die Entwicklung untersagt. Sie müssen daher die Datenbankadministratoren um Hilfe bitten. Verkaufsdaten machen das Testen sehr einfach, da einige Fälle nur bei Produktdaten auftreten und es sehr nützlich ist, die Daten in einem realen System zu untersuchen, um zu verstehen, wie das System für den Benutzer funktioniert.

Bei Tests im Perf Lab stellte sich heraus, dass das Laden von Dateien aus dem Speicher überhaupt nicht durch das Wort realisiert wurde. Bei der Implementierung von Lasttests haben wir häufigere Anforderungen von Client-Software ausgewählt, von denen einige nicht in die Bereinigung des Speichers einbezogen wurden. Da es sich um eine Datenbank handelt, wurde ein vereinfachter Test für alle geänderten Objekte durchgeführt, wobei die geänderten Prozeduren manuell für verschiedene Daten aufgerufen wurden. (über die Optionen, die ich kannte).
Darüber hinaus wurde bei Integrations- und Perfektionstests der Schwerpunkt auf die beliebteste Art der Dateispeicherung gelegt.

Ein zusätzliches Merkmal des Perf-Labors, das nicht sofort herausgefunden wurde, ist die Nichtübereinstimmung der Datenmenge in einigen Tabellen zu Produkt und Perf. In dem Sinne, dass alle Verkaufsjobs an der Perf arbeiten, die Daten generieren, aber es gibt nicht immer etwas, das die in der Tabelle generierten Daten verarbeitet. Und zum Beispiel ist die oben erwähnte Tabellenwarteschlange zum Löschen auf dem Perf viel größer als auf dem Produkt - 20 Millionen Datensätze auf dem Perf und 200.000 Datensätze auf dem Produkt.

Bereitstellungsprozess

Der Bereitstellungsprozess ist ziemlich Standard. Es gab keine Änderungen im Anwendungscode für diese Aufgabe, alle Änderungen sind nur in der Datenbank. Ein DBA wird immer in die Datenbank gerollt, dieser Prozess ist nicht automatisiert. Es werden 2 Versionen von Skripten vorbereitet - zum Anwenden von Änderungen und zum Zurücksetzen von Änderungen, und eine Anweisung für DBA wird geschrieben. Es werden immer 2 Versionen von Skripten erstellt, die notwendigerweise auf Rollback und Rollback von Änderungen getestet werden. Dieselben Skripte werden verwendet, um Änderungen an Staging und Perf Lab vorzunehmen, bevor die Integration und die Lasttests gestartet werden.

Was ist nach dem Einsatz passiert?

In den ersten 5 Stunden nach der Bereitstellung kam es zu 1 Million Ereignissen, bei denen die Client-Software beim Versuch, die Datei herunterzuladen, einen Fehler erhielt. Das Ereignis "Datei beschädigt". Dies bedeutet, dass der Client versucht, die Datei herunterzuladen, die Datei jedoch nicht im Repository gefunden wurde. Normalerweise sind diese Ereignisse entweder gar nicht oder sie werden mit 1 - 2 Tausend pro Tag gemessen.

Ich muss sofort sagen, dass es mindestens 1 Woche gedauert hat, um die Ursache des Fehlers in einem Team von 3 und manchmal 5 Personen (einschließlich mir) zu finden.

Wir haben die gesamte Liste der Dateien gesammelt, für die das Ereignis "Datei beschädigt" aufgetreten ist.

Trotz der Tatsache, dass es mehr als 1 Million Ereignisse gab und alle von verschiedenen Benutzern und Unternehmen stammten, enthielt diese Liste nur 250 eindeutige Dateien.

Der DBA auf dem Sicherungsserver wurde ausgelöst, um Datenbanksicherungen zum Zeitpunkt des Eintreffens der Ereignisse zu untersuchen. In den Projektbasen gibt es einige Tabellen mit allen Arten von Protokollen, die bei der Analyse hilfreich waren. Selbst wenn Informationen aus der Datenbank gelöscht werden, wird ein Protokoll zu dem hinzugefügt, was gelöscht wurde und von welchem ​​Ereignis. Auf dem Produkt werden solche Datensätze 1 Woche lang gespeichert und dann auf dem Archivserver zusammengeführt.

Und ebenso die Tabellen mit Protokollen, die bei der Analyse der Ereignisse sehr hilfreich waren:
Auf jedem Shard wird ein vollständiges Protokoll mit Clientereignissen geführt

Auf dem globalen Server:

• Protokoll der Anforderungen zum Herunterladen aller Dateien durch Benutzer
• Protokollieren Sie das Hochladen von Dateien von Benutzern auf das System
• FileCorrupt-Ereignisprotokoll
• Protokolldatei, um das Löschen aus dem Speicher abzubrechen
• Protokoll der gelöschten Dateien aus der Datenbank

Zusätzlich war ein ELK mit Anwendungsprotokollen verfügbar.

Wir haben es geschafft, den Fehler in der Entwicklungsumgebung zu wiederholen, was die Richtigkeit der Annahme bestätigte. Anfangs nahm niemand diese Hypothese ernst, da es sehr schwer zu glauben war, dass so viele Faktoren gleichzeitig zusammenfielen und so viele Benutzer zu dieser bestimmten Zeit kamen.

Was ist schief gelaufen?

Es stellte sich heraus, dass das System ungefähr 250 (zum Vergleich Milliarden von Dateien im System) Super-Duper-Mega-Dateien hatte. 250 ja!

Diese Dateien waren noch sehr alt. Zum Zeitpunkt des Hochladens dieser Dateien auf das System wurde ein anderes System zum Generieren des Dateischlüssels für den Speicher verwendet.

Es stellte sich heraus, dass sich die Methode zum physischen Entfernen aus dem physischen Speicher für diesen Schlüsseltyp anders verhält als für andere Dateien.

In der Klasse mit Löschung gibt es einen Codeblock mit einer Bedingung speziell für Dateien mit dem alten Schlüssel. Das System verschiebt diese alte Datei zum Zeitpunkt des Löschens an einen anderen Speicherort, bevor überprüft wird, ob sich die Datei nicht auf Shards befindet. Nun, das hat nicht geklappt.

Und es stellte sich heraus, dass in dem Moment, in dem die Datei verschoben wurde (und ich werde daran erinnern, dass sie sehr beliebt ist), wenn einer der Benutzer versucht, ihm neue Benutzerrechte zu erteilen, die Client-Software in den Speicher für diese Datei wechselt, die Datei jedoch nicht am richtigen Ort ist. Da es verschoben wird, klappt das also nicht. Und die Client-Software sendet eine Nachricht, dass die Datei beschädigt ist. In der Datenbank wird es als defekt markiert. Und alle Informationen werden aus der Datenbank gelöscht (fast alle).

In der Zwischenzeit stellt unsere Shard-Check-Routine fest, dass die Datei verwendet wird. Und sendet eine Antwort, die Sie zurückgeben müssen. Alle Informationen wurden jedoch bereits aus der Datenbank gelöscht, und es ist unmöglich, sie zurückzugeben.

Lustig, oder?

Das heißt, als die Datei gelöscht wurde, befand sich der Benutzer in dem Zeitraum, in dem die Datei verschoben, die Shards überprüft wurden, und zu diesem Zeitpunkt schickte der Benutzer eine Anforderung zum Herunterladen.

Hier ist es - Highload in Aktion, wenn die unglaublichsten Spiele, die Sie treffen.



Nachdem wir uns von der Überraschung erholt und alles zurückgesetzt hatten, stellten wir sicher, dass die Dateien der Benutzer lebendig sind, da sie von den Festplatten anderer Clients wiederhergestellt wurden.

Bei den Tests war natürlich alles in Ordnung, da während des Tests neuere Dateien mit einem neuen Schlüsseltyp gelöscht wurden, der in den letzten 5 Jahren verwendet wurde. Solche Dateien werden zum Zeitpunkt des Löschens nicht an einen anderen Speicherort übertragen.

Unser Optimismus ließ nach und wir beschlossen, nicht den optimistischsten Weg zu gehen.

Rückblick

Wir haben beschlossen, dass wir Tests für verschiedene Arten von Speichern hinzufügen müssen
Fügen Sie perf lab eine Last hinzu, die Anrufe verwendet, wenn sie aus dem Speicher entfernt werden
Schließen Sie berühmte Rennbedingungen
Überwachung hinzufügen (obwohl dies in den Plänen vorgesehen wäre, aber nicht in den ursprünglichen Umfang passt)

Über die Überwachung

Sie beschlossen, sofort zu überwachen, aber dann trat er in den Hintergrund, da eine schnellere Bereitstellung erforderlich war.

Für die Überwachung verwendete das Projekt Zabbix, ELK, Grafana, NewRelic, SQL Sentry und eine Testversion von AppDynamics.

Davon befanden sich auf pef lab NewRelic und SQL Sentry.

Wir haben bereits alle Systemmetriken gemessen und wollten daher Geschäftsmetriken messen. Ich hatte Erfahrung mit der Organisation einer solchen Überwachung durch Zabbix - wir haben uns dazu entschlossen, dasselbe zu tun.

Das Schema ist in der Datenbank sehr einfach, um eine Tabelle zu erstellen, in die die erforderlichen Metriken per Job erfasst werden können, und eine Prozedur, mit der die gesammelten Metriken nach Zabbix hochgeladen werden.

Metriken:

• Die Anzahl der Dateien in der Warteschlange, die global gelöscht werden sollen
• Anzahl der vom Server in die Warteschlange gestellten Dateien
• Die Anzahl der Dateien, die vom Repository an das Deinstallationsprogramm gesendet wurden
• Anzahl der gelöschten Dateien
• Anzahl der FileCorrupt-Ereignisse
• Die Anzahl der Dateien, die auf jedem Shard gelöscht werden sollen

Die Überwachung wurde separat implementiert und auf dem Produkt bereitgestellt, bevor mit der Bereitstellung einer neuen Implementierung des Löschvorgangs begonnen wurde.

Neue Lösung

Im Allgemeinen entschieden wir, dass es besser ist, zu viel zu essen als nicht zu schlafen, und machten einen neuen Plan.

1. Überprüfen Sie auf demselben Shard, dass niemand die Datei mehr sicher verwendet, und übertragen Sie nur nicht verwendete Dateien auf den Server.
2. Sammeln Sie beim Übertragen auf den Server alle Dateien in der Tabelle und stellen Sie sicher, dass die Dateien nicht für Shards verwendet werden, bevor Sie sie in die Warteschlangentabelle der Warteschlange stellen.
3. Wenn Sie eine Datei verwenden und im System danach suchen, markieren Sie die Warteschlange in der Tabelle als eine Datei, die überprüft werden muss.
4. Geben Sie nur Dateien zurück, für die keine Suche durchgeführt wurde.
5. Dateien, die durchsucht wurden, erneut auf Scherben prüfen;
6. Entfernen Sie im Allgemeinen die Prüfung in der Prozedur, mit der die Datei gelöscht wird, da sie schnell funktionieren sollte - und die verwendete Datei sie im Prinzip nicht erreichen sollte.
7. Berücksichtigen Sie bei der Prozedur, dass alles durch die geschlagene Datei gelöscht wird, die gerade gelöscht wird, und löschen Sie keine Informationen darüber.

Punkt 6 während des Einsatzes beinhaltete das Entfernen des Schecks in mehreren Schritten. Zuerst ließen sie den Scheck, dann eine Woche später wurde der Scheck in den Akten der Mitarbeiter des Unternehmens deaktiviert, nach 2 Wochen schalteten sie den Scheck überhaupt aus.

Was mussten Sie im Code ändern?

Auch hier gelten alle Änderungen nur für die Datenbank.

Das Ausmaß der Änderungen war auf dem globalen Server am größten:
Fügen Sie eine Zwischentabelle hinzu, in die alle von Shards heruntergeladenen Dateien eingefügt werden sollen.
Erstellen Sie einen Job, der die Dateien in der Zwischentabelle überprüft, dass sie nicht für Shards verwendet werden.

Fügen Sie in der Warteschlange der gelöschten Dateien ein Feld mit dem Datum hinzu, an dem zuletzt auf die Datei zugegriffen wurde, und fügen Sie einen Index hinzu.

Finden Sie alle Prozeduren mit Zugriff auf die Datei - es stellte sich heraus, 5 Prozeduren. Fügen Sie ihnen einen Block hinzu, der das Datum der letzten Verwendung in der Warteschlangentabelle ändert. Das Datum ändert sich jedes Mal, unabhängig davon, ob es gefüllt wurde oder nicht.

Fügen Sie das Löschprogramm zu den Verfahren zur Ausgabe von Dateien hinzu, sodass nur Dateien mit einem leeren Verwendungsdatum angezeigt werden.

Fügen Sie einen Job hinzu, der alle Dateien mit dem Verwendungsdatum sammelt und prüft (mit einer Verzögerung von 10 Minuten, die erforderlich ist, damit die Client-Software die Datei zum Shard hinzufügen kann, dauert es im Allgemeinen bis zu 2 Minuten, entscheidet sich jedoch, auf Nummer sicher zu gehen). Verwenden Sie die Datei für alle Shards. Nach Abschluss der Prüfung wird das Verwendungsdatum auf Null zurückgesetzt, wenn die Datei nicht gefunden wird. Andernfalls wird die Datei aus der Warteschlange gelöscht. Wenn sich das Verwendungsdatum während des Überprüfungsprozesses geändert hat, ändern sich die Daten nicht, da davon ausgegangen wird, dass die Datei während der Überprüfung auf den Shard hochgeladen werden konnte, auf dem die Überprüfung bereits abgeschlossen war und ein neuer Überprüfungszyklus für die Datei erforderlich war.

Auf Scherben:

Bei der Prozedur, bei der Dateien mit gelöschten Dateien aus der Tabelle gelöscht werden, musste überprüft werden, ob die Datei nicht verwendet wurde. Das Verfahren hat seine Einfachheit und Schönheit nicht sehr verloren - in DELETE mit Ausgabe haben sie einfach NOT EXISTS hinzugefügt.

Wir haben einen JOB hinzugefügt, der im Hintergrund von den auf dem Server verwendeten Tabellendateien abweicht.

Tests

Den Integrationstests wurden Szenarien zur Verwendung aller Speicheroptionen hinzugefügt.
Sie haben auch neue Fälle geschrieben, um neue Funktionen zum Entfernen von Dateien zu testen.

Perf Lab hat dem globalen Server eine zusätzliche Last hinzugefügt. Zusätzlich haben wir eine Last hinzugefügt, die dem Löschen von Dateien aus dem Speicher entspricht.

Bereitstellen

Skripte wurden für die Anwendung und das Rollback von Änderungen für die Datenbank vorbereitet. DBA rollte Skripte und es stellte sich heraus, dass sie beim Auslastungstest die Sperren von Warteschlangentabellen zum Löschen von Dateien nicht beachteten. Infolgedessen haben wir den Index nicht festgelegt, was nicht der optimalste war.

Aus diesem Grund war es erforderlich, die JOB-Prüfungen nach Bereichen zu deaktivieren und Kennungen gelöschter Dateien manuell nach Dateien zu analysieren und hinzuzufügen, die vor der Bereitstellung des neuen Codes im System gelöscht wurden.

Ergebnisse

Infolgedessen werden aufgrund der Bereitstellung neue gelöschte Dateien innerhalb von 24 Stunden aus dem Speicher gelöscht.
Dateien, die vor dem Start des neuen Systems gelöscht wurden, wurden bei der Sicherung erstellt und der Warteschlange für Produkte hinzugefügt.

Infolgedessen wurden überschüssige Daten zu S3 in Höhe von 2 Petabyte gelöscht. Dasselbe geschah mit Dateien auf dedizierten Client-Servern, und jetzt stimmt ihr Platz auf dem Server mit dem Platz überein, der auf ihren Clients angezeigt wird.

Der gekrümmte Index in der Warteschlangentabelle lebt immer noch von prod, der Aufgabe, den Index im Backlog zu ändern, wird jedoch aufgrund von Aufgaben mit höherer Priorität leicht verschoben.