Überlegungen zum Importieren von Daten für MariaDB

Der folgende Inhalt enthält technische Informationen zum Laden von Daten in MariaDB. Dieser Inhalt richtet sich an Benutzer, die mit der MariaDB-Serverarchitektur vertraut sind.

Binäre Protokollierung

Die Aktivierung der binären Protokollierung reduziert die Leistung beim Laden von Daten und erfordert bis zu viermal mehr Festplattenspeicher als bei deaktivierter Protokollierung. Die Transaktionsgröße, die zum Laden der Daten verwendet wird, wirkt sich direkt auf die Systemleistung und den Speicherplatzbedarf aus. Größere Transaktionen erfordern mehr Ressourcen.

Transaktionsgröße

Die Transaktionsgröße beeinflusst die folgenden Aspekte des Ladens von MariaDB-Daten:

• Ressourcenverbrauch

• Nutzung des Festplattenspeichers

• Vorgang fortsetzen

• Zeit, sich zu erholen

• Eingabeformat (Flatfiles oder SQL)

In diesem Abschnitt wird beschrieben, wie sich die Transaktionsgröße auf die binäre Protokollierung auswirkt, und verdeutlicht, welche Vorteile das Deaktivieren der binären Protokollierung bei umfangreichen Datenladevorgängen mit sich bringen kann. Sie können die binäre Protokollierung aktivieren und deaktivieren, indem Sie den Aufbewahrungszeitraum für automatische Amazon RDS-Backups festlegen. Nicht-Null-Werte aktivieren die binäre Protokollierung und Null deaktiviert diese. Weitere Informationen finden Sie unter Aufbewahrungszeitraum für Backups.

In diesem Abschnitt werden auch die Auswirkungen großer Transaktionen auf InnoDB beschrieben und warum es wichtig ist, die Transaktionsgrößen klein zu halten.

Kleine Transaktionen

Bei kleinen Transaktionen sorgt die binäre Protokollierung für eine Verdopplung der Schreibvorgänge auf der Festplatte, die für das Laden der Daten erforderlich sind. Dieser Effekt kann die Leistung für andere Datenbanksitzungen signifikant herabsetzen und die zum Laden der Daten erforderliche Zeit erhöhen. Die eingetretene Verschlechterung hängt teilweise von den folgenden Faktoren ab:

• Upload-Rate

• Andere Datenbankaktivitäten, die während des Ladevorgangs stattfinden

• Kapazität Ihrer Amazon RDS-DB-Instance

Die Binärprotokolle verbrauchen außerdem Festplattenspeicher, der in etwa der Menge der geladenen Daten entspricht, bis die Protokolle gesichert und entfernt werden. Amazon RDS minimiert dies, indem binäre Protokolle häufig gesichert und entfernt werden.

Große Transaktionen

Bei großen Transaktionen verdreifacht die binäre Protokollierung die IOPS und die Festplattennutzung aus den folgenden Gründen:

• Der Binärprotokollcache speichert Transaktionsdaten vorübergehend auf der Festplatte.

• Dieser Cache wächst mit der Transaktionsgröße, wodurch Speicherplatz beansprucht wird.

• Wenn die Transaktion (Commit oder Rollback) abgeschlossen ist, kopiert das System den Cache in das Binärprotokoll.

Bei diesem Vorgang werden drei Kopien der Daten erstellt:

• Die Originaldaten

• Der Cache auf der Festplatte

• Der letzte binäre Protokolleintrag

Jeder Schreibvorgang verursacht zusätzliche I/O, was sich weiter auf die Leistung auswirkt.

Aus diesem Grund benötigt die binäre Protokollierung dreimal so viel Festplattenspeicher wie die deaktivierte Protokollierung. Wenn Sie beispielsweise 10 GiB an Daten als eine einzelne Transaktion laden, werden drei Kopien erstellt:

• 10 GiB für die Tabellendaten

• 10 GiB für den binären Log-Cache

• 10 GiB für die binäre Logdatei

Der gesamte benötigte temporäre Festplattenspeicher beträgt 30 GiB.

Wichtige Überlegungen zum Festplattenspeicher:

• Die Cache-Datei bleibt bestehen, bis entweder die Sitzung endet oder eine neue Transaktion einen weiteren Cache erstellt.

• Das Binärprotokoll bleibt so lange bestehen, bis es gesichert wird, und kann möglicherweise 20 GiB (Cache und Protokoll) für einen längeren Zeitraum enthalten.

Wenn Sie die Daten LOAD DATA LOCAL INFILE zum Laden verwenden, erstellt Data Recovery eine vierte Kopie für den Fall, dass die Datenbank aus einer vor dem Ladevorgang erstellten Sicherung wiederhergestellt werden muss. Während der Wiederherstellung extrahiert MariaDB die Daten aus dem Binärprotokoll in eine Flat-Datei. MariaDB läuft dann. LOAD DATA LOCAL INFILE Aufbauend auf dem vorherigen Beispiel erfordert diese Wiederherstellung insgesamt einen temporären Festplattenspeicher von 40 GiB oder jeweils 10 GiB für Tabelle, Cache, Protokoll und lokale Datei. Ohne mindestens 40 GiB freien Festplattenspeicher schlägt die Wiederherstellung fehl.

Optimierung großer Datenlasten

Deaktivieren Sie bei großen Datenlasten die binäre Protokollierung, um den Overhead und den Speicherplatzbedarf zu reduzieren. Sie können die binäre Protokollierung deaktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf 0 setzen. Stellen Sie nach Abschluss des Ladevorgangs die Aufbewahrungsdauer für Backups auf den entsprechenden Wert ungleich Null zurück. Weitere Informationen finden Sie unter Ändern einer Amazon RDS DB-Instance und Aufbewahrungszeitraum für Backup in der Einstellungstabelle.

Anmerkung

Wenn es sich bei der DB-Instance um eine Quell-DB-Instance für Read Replicas handelt, können Sie den Aufbewahrungszeitraum für Backups nicht auf 0 setzen.

Wir empfehlen Ihnen, vor dem Laden der Daten einen DB-Snapshot zu erstellen. Weitere Informationen finden Sie unter Verwaltung manueller Backups.

InnoDB

Die folgenden Informationen zu Undo-Logging- und Wiederherstellungsoptionen unterstützen dabei, InnoDB-Transaktionen klein zu halten, um die Datenbankleistung zu optimieren.

Grundlegendes zur InnoDB-Undo-Protokollierung

Undo ist ein Protokollierungsmechanismus, der das Rollback von Transaktionen ermöglicht und Multi-Version Concurrency Control (MVCC) unterstützt.

Für MariaDB 10.11 und niedrigere Versionen werden Undo-Logs im InnoDB-System-Tablespace (normalerweise ibdata1) gespeichert und aufbewahrt, bis der Purge-Thread sie entfernt. Infolgedessen können umfangreiche Datenladetransaktionen dazu führen, dass der System-Tablespace ziemlich groß wird und Speicherplatz beansprucht, den Sie nicht zurückgewinnen können, es sei denn, Sie erstellen die Datenbank neu.

Für alle MariaDB-Versionen muss der Purge-Thread warten, um alle Undo-Logs zu entfernen, bis die älteste aktive Transaktion entweder festgeschrieben oder zurückgesetzt wird. Wenn die Datenbank während des Ladevorgangs andere Transaktionen verarbeitet, sammeln sich auch deren Undo-Logs an und können nicht entfernt werden, selbst wenn die Transaktionen festgeschrieben werden und keine andere Transaktion die Undo-Logs für MVCC benötigt. In dieser Situation werden alle Transaktionen — einschließlich schreibgeschützter Transaktionen — langsamer. Diese Verlangsamung ist darauf zurückzuführen, dass alle Transaktionen auf alle Zeilen zugreifen, die von jeder Transaktion — nicht nur der Ladetransaktion — geändert werden. Tatsächlich müssen Transaktionen Undo-Logs durchsuchen, deren Löschung durch lang andauernde Ladetransaktionen während einer Undo-Log-Bereinigung verhindert wurde. Dies beeinträchtigt die Leistung aller Operationen, die auf geänderte Zeilen zugreifen.

Optionen zur Wiederherstellung von InnoDB-Transaktionen

Obwohl InnoDB Commit-Operationen optimiert, sind große Transaktions-Rollbacks langsam. Führen Sie für eine schnellere Wiederherstellung eine Wiederherstellung durch oder stellen Sie einen point-in-time DB-Snapshot wieder her. Weitere Informationen erhalten Sie unter Point-in-time Wiederherstellung und Wiederherstellung auf einer DB-Instance.

Formate für den Datenimport

MariaDB unterstützt zwei Datenimportformate: Flatfiles und SQL. Lesen Sie die Informationen zu den einzelnen Formaten, um die beste Option für Ihre Bedürfnisse zu ermitteln.

Flache Dateien

Laden Sie für kleine Transaktionen Flatfiles mitLOAD DATA LOCAL INFILE. Dieses Datenimportformat bietet gegenüber der Verwendung von SQL die folgenden Vorteile:

• Weniger Netzwerkverkehr

• Niedrigere Datenübertragungskosten

• Geringerer Aufwand für die Datenbankverarbeitung

• Schnellere Verarbeitung

LOAD DATA LOCAL INFILElädt die gesamte Flat-Datei als eine Transaktion. Halten Sie die Größe der einzelnen Dateien klein, um die folgenden Vorteile zu erzielen:

• Wiederaufnahmefunktion — Sie können verfolgen, welche Dateien geladen wurden. Wenn beim Laden ein Problem auftritt, können Sie dort weitermachen, wo Sie aufgehört haben. Möglicherweise müssen Sie einige Daten erneut an Amazon RDS übertragen, aber bei kleinen Dateien ist die Menge der erneuten Übertragung minimal.

• Paralleles Laden von Daten — Wenn Sie über ausreichend IOPS und Netzwerkbandbreite für das Laden einer einzelnen Datei verfügen, kann das parallele Laden Zeit sparen.

• Steuerung der Laderate — Wenn sich Ihre Datenlast negativ auf andere Prozesse auswirkt, können Sie die Laderate steuern, indem Sie das Intervall zwischen den Dateien verlängern.

Große Transaktionen verringern die Vorteile, die sich aus LOAD DATA LOCAL INFILE dem Import von Daten ergeben. Wenn Sie eine große Datenmenge nicht in kleinere Dateien aufteilen können, sollten Sie SQL verwenden.

SQL

SQL hat einen Hauptvorteil gegenüber flachen Dateien: Sie können die Transaktionsgröße leicht klein halten. Das Laden von SQL kann jedoch erheblich länger dauern als das Laden von Flatfiles. Außerdem kann es nach einem Fehler schwierig sein, zu bestimmen, wo weitergemacht werden soll — Sie können Mariadb-Dump-Dateien nicht neu starten. Wenn beim Laden der Mariadb-Dump-Datei ein Fehler auftritt, müssen Sie die Datei ändern oder ersetzen, bevor der Ladevorgang fortgesetzt werden kann. Alternativ können Sie, nachdem Sie die Ursache des Fehlers behoben haben, den Zeitpunkt vor dem Laden wiederherstellen und die Datei erneut senden. Weitere Informationen finden Sie unter Point-in-time Wiederherstellung.

Verwenden von Amazon RDS-DB-Snapshots für Datenbank-Checkpoints

Wenn Sie Daten über lange Zeiträume — wie Stunden oder Tage — ohne binäre Protokollierung laden, verwenden Sie DB-Snapshots, um regelmäßige Checkpoints für die Datensicherheit bereitzustellen. Jeder DB-Snapshot erstellt eine konsistente Kopie Ihrer Datenbank-Instance, die bei Systemausfällen oder Datenbeschädigungen als Wiederherstellungspunkt dient. Da DB-Snapshots schnell sind, hat häufiges Checkpointing nur minimale Auswirkungen auf die Ladeleistung. Sie können frühere DB-Snapshots löschen, ohne die Haltbarkeit der Datenbank oder die Wiederherstellungsmöglichkeiten zu beeinträchtigen. Weitere Hinweise zu DB-Snapshots finden Sie unter. Verwaltung manueller Backups

Verkürzung der Ladezeiten der Datenbank

Die folgenden Punkte sind zusätzliche Tipps zur Verkürzung der Ladezeiten:

• Erstellen Sie alle sekundären Indizes, bevor Sie Daten in MariaDB-Datenbanken laden. Im Gegensatz zu anderen Datenbanksystemen erstellt MariaDB die gesamte Tabelle neu, wenn Sekundärindizes hinzugefügt oder geändert werden. Dieser Prozess erstellt eine neue Tabelle mit Indexänderungen, kopiert alle Daten und löscht die Originaltabelle.

• Lädt Daten in der Reihenfolge der Primärschlüssel. Für InnoDB-Tabellen kann dies die Ladezeiten um 75 bis 80% und die Datendateigröße um 50% reduzieren.

• Deaktivieren Sie Fremdschlüsseleinschränkungen, indem Sie foreign_key_checks auf 0 setzen. Dies ist häufig für Flatfiles erforderlich, die mit geladen werdenLOAD DATA LOCAL INFILE. Bei jedem Ladevorgang beschleunigt die Deaktivierung der Fremdschlüsselprüfungen das Laden der Daten. Aktivieren Sie nach Abschluss des Ladevorgangs die Einschränkungen erneut, indem Sie die Einstellungen foreign_key_checks auf festlegen 1 und die Daten überprüfen.

• Laden Sie Daten parallel, sofern Sie sich nicht einem Ressourcenlimit nähern. Verwenden Sie gegebenenfalls partitionierte Tabellen, um das gleichzeitige Laden über mehrere Tabellensegmente hinweg zu ermöglichen.

• Um den Aufwand bei der SQL-Ausführung zu reduzieren, kombinieren Sie mehrere INSERT Anweisungen zu einzelnen Operationen mit mehreren INSERT Werten. mariadb-dumpimplementiert diese Optimierung automatisch.

• Reduzieren Sie InnoDB-Protokoll-IO-Operationen, indem Sie innodb_flush_log_at_trx_commit auf 0 setzen. Stellen Sie nach Abschluss des Ladevorgangs innodb_flush_log_at_trx_commit auf 1 wieder her.

  Warnung

  Die Einstellung innodb_flush_log_at_trx_commit auf 0 bewirkt, dass InnoDB seine Logs jede Sekunde leert, nicht bei jedem Commit. Diese Einstellung erhöht die Leistung, kann jedoch zu Transaktionsverlusten bei Systemausfällen führen.

• Wenn Sie Daten in eine DB-Instance laden, die keine Read Replicas hat, setzen Sie den Wert sync_binlog auf0. Stellen Sie nach Abschluss des Ladevorgangs sync_binlog parameter auf 1 wieder her.

• Laden Sie Daten in eine Single-AZ-DB-Instance, bevor Sie die DB-Instance in eine Multi-AZ-Bereitstellung konvertieren. Wenn die DB-Instance bereits eine Multi-AZ-Bereitstellung verwendet, empfehlen wir nicht, zum Laden von Daten zu einer Single-AZ-Bereitstellung zu wechseln. Dies führt nur zu geringfügigen Verbesserungen