Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Shed-Last

Die Verbesserung der Reaktionszeiten und die Erhöhung der verfügbaren Ressourcen für kritische Workflows erfordern möglicherweise die Beseitigung überflüssiger Lasten. Bei vielen der in diesem Abschnitt behandelten Lösungen handelt es sich um Kompromissentscheidungen. Sie haben Konsequenzen für die Anwendung und müssen sorgfältig abgewogen werden. Sie können auch in den folgenden Situationen in Betracht ziehen, diese Lösungen in den folgenden Situationen zu verwenden:

Zu unmittelbaren Änderungen gehören die folgenden:

Bevor Sie diese Maßnahmen ergreifen, sollten Sie sie im Kontext der langfristigen Geschäftsziele und Risiken bewerten.

Separieren von Lese- und Schreibdatenströmen

Eine gängige Technik beim Ausführen von Anwendungen, die auf MySQL basieren, besteht darin, Lesevorgänge von der (primären) Writer-Datenbank-Instance auf eine oder mehrere schreibgeschützte Datenbankreplikate auszulagern. Durch das Auslagern von Lesevorgängen können Sie die Gesamtlast auf der primären Datenbank-Instance reduzieren und Platz für Schreibvorgänge schaffen. Achten Sie darauf, nur Lesevorgänge anzuvisieren, die nicht von der unmittelbaren Konsistenz der Replikate read-after-writeabhängig sind. Ein effizienterer Ansatz besteht darin, den gesamten Lesetraffic auf das Replikat zu verlagern und für den Fall einer Verzögerung der read-after-write Replikation einen erneuten Versuch einzuplanen. Es gibt unabhängige Lese-Workloads, die ausgelagert werden können, z. B. Reporting Services. Andere Lesevorgänge erfordern Änderungen auf Anwendungsebene, wobei der Kontext, aus dem der Lesevorgang ausgeführt wurde, allgemein bekannt ist.

Ein alternativer Ansatz besteht darin, eine Datenbank-Proxylösung als Vermittler zwischen der Anwendung und der Datenbank zu implementieren, die die Funktion der Aufteilung von Lese- und Schreibvorgängen und das Routing von Abfragen ohne Kenntnis der Anwendung bereitstellen kann. ProxySQL, MariaDB MaxScale, ScaleArc und Heimdall Data sind einige der verfügbaren MySQL-kompatiblen Proxy-Lösungen. Diese Produkte bieten mehrere zusätzliche Features, wie z. B. Caching oder Verbindungsmultiplexing. Wenn Sie einen plötzlichen Anstieg des Datenverkehrs feststellen und eine neue Technologie in Ihrem Anwendungsstapel implementieren, empfehlen wir, mit den grundlegenden Funktionen zum Aufteilen von read/write Abfragen zu beginnen und das Verhalten und die Leistung zu testen, bevor Sie zusätzliche Funktionen verwenden, die unbeabsichtigte Nebenwirkungen haben könnten.

Archivieren oder löschen von älteren Daten

Eine weitere Methode zur Verbesserung der Datenbankleistung besteht darin, historische Daten in eine andere Tabelle, Datenbank oder Amazon Simple Storage Service (Amazon S3) auszulagern. In vielen Datenbanken werden alle Daten für den gesamten Verlauf der Anwendung inline gespeichert. Unter normalen Umständen bietet dies in einer typischen benutzerorientierten Anwendung den Benutzern die Möglichkeit, alle ihre historischen Bestellungen einzusehen. Wenn die Nachfrage plötzlich ansteigt, sind viele Benutzer, die die Anwendung aktiv nutzen, wahrscheinlich neu oder konzentrieren sich darauf, eine neue Bestellung aufzugeben. Wenn sich die historischen Daten online befinden, in einer einzigen Tabelle mit Milliarden von Zeilen, summiert sich das. Die Tabelle hat wahrscheinlich auch große Indizes. Sowohl Tabellendaten als auch Indizes werden in einer Baumstruktur gespeichert. Für mehr Einträge in einer Tabelle sind mehr Ebenen im Baum erforderlich, was wiederum mehr I/O Operationen für den Zugriff auf die Zeilen erfordert. Dies erhöht die Zugriffszeit, um einzelne Datensätze zu finden. Noch wichtiger ist, dass dadurch große, nicht benötigte Teile des Index im Datenbankseiten-Cache (InnoDB-Pufferpool) gespeichert werden.

Die Archivierung älterer Daten in einer separaten Tabelle, einer separaten Datenbank oder Amazon S3 kann die Zugriffszeiten für Endbenutzer reduzieren, wertvollen Cache freigeben und die allgemeine Anwendungsleistung verbessern. Durch die Archivierung älterer Daten vor dem Ereignis (z. B. durch Aufbewahrung von nur 30 oder 90 Tagen) wird die Größe der Tabellen und Indizes für kritische Tabellen begrenzt. Diese Änderung erfordert, dass die Anwendung so geändert wird, dass die älteren Daten nur für die kleine Gruppe von Benutzern, die ausdrücklich nach historischen Daten fragen, von einem sekundären Speicherort aus abgerufen werden.

Verschieben Sie unkritische ETL-Prozesse

Extraktionen aus dem Hauptdatenbanksystem für ETL-Prozesse können ein Stabilitätsrisiko für stark transaktionale und gleichzeitige Workloads unter Hyperscale-Bedingungen darstellen. ETL-Verfahren sind für die folgenden Eigenschaften bekannt:

ETL-Prozesse, die variabel oder unvorhersehbar sind (z. B. erhöhen Abfragen wie INSERT INTO ... SELECT FROM ...;) die allgemeine Variabilität in Bezug auf Last und Konflikte und erhöhen so das Stabilitätsrisiko).

Wenn möglich, sollten Sie die Häufigkeit, mit der ETL-Prozesse ausgeführt werden, verschieben oder reduzieren, insbesondere wenn sie keine kritischen Funktionen bereitstellen. Ändern Sie kritische ETL-Prozesse so, dass sie in begrenzten Arbeitseinheiten ablaufen, z. B. bei der Verarbeitung von Batches mit einer festen Anzahl von Zeilen (z. B. mit LIMIT-Klauseln), separate Transaktionen verwenden oder kleinere Datenmengen über einen längeren Zeitraum abrufen, um den Spitzenressourcenbedarf der DB-Instance zu reduzieren.

Ausschalten weniger wichtiger Anwendungs-Feature

Wenn bei der Bearbeitung einer Flut von Anfragen die Benutzererfahrung erheblich beeinträchtigt oder Features entfernt werden, die nicht zum Kerngeschäft gehören, werden Datenbankressourcen für wichtige Funktionen geschont. Dies kann eine geringfügige Änderung des Kundenerlebnisses erfordern, aber ein anderer Ablauf ist besser als ein Ausfall der Website. Vielleicht kann die Personalisierung auf der Titelseite der Website, die immer einen Datenbankaufruf durchführt, vorübergehend deaktiviert werden. Oder Sie können aufhören, wiederkehrenden Kunden maßgeschneiderte Angebote zu präsentieren, während Sie Produkte auswählen. Durch das vorübergehende Deaktivieren von Features kann die Seite zwischengespeichert oder bereitgestellt werden, ohne dass Datenbankzugriff erforderlich ist.

Andere Beispiele sind ein Frontend mit einem Abfragemechanismus, der nach Datenänderungen sucht, für die ein Datenbankaufruf erforderlich ist. Eine Reduzierung der Abfragehäufigkeit führt sofort zu weniger Datenbankaufrufen. Benutzeroberflächen, die Seitennummerierung erfordern oder Benutzern die Möglichkeit bieten, sortierte Ergebnismengen abzurufen, die weiter vom obersten Ergebnis entfernt sind, erfordern zunehmend teurere Datenbankaufrufe. Beschränken Sie die Anzahl der Seiten in einer Ergebnismenge, um die Datenbank vor den teuersten Datenbankaufrufen zu schützen. Verwenden Sie Feature-Flags in der Anwendungsebene, damit das Betriebsteam Feature ausschalten oder herabsetzen kann, wenn die Anwendungs- oder Datenbanklast zunimmt.