Best Practices für Massenladen

Diese Seite enthält Richtlinien für das effiziente Laden großer Datenmengen im Bulk in Spanner.

Sie haben mehrere Möglichkeiten, Daten im Bulk in Spanner zu laden:

Sie können zwar auch Zeilen mit der Google Cloud CLI einfügen, die Verwendung der gcloud CLI für Bulk-Ladevorgänge wird jedoch nicht empfohlen.

Leistungsrichtlinien für das Laden im Bulk

Maximieren Sie die Partitionierung, um das Schreiben der Daten auf Worker-Aufgaben zu verteilen, um eine optimale Leistung beim Laden im Bulk zu erreichen.

Spanner verwendet eine lastbasierte Aufteilung, um die Datenlast gleichmäßig auf die Rechenressourcen der Instanz zu verteilen. Nach einigen Minuten hoher Last führt Spanner Split-Grenzen zwischen Zeilen ein. Der Durchsatz sollte sich für Schreibvorgänge alle paar Minuten verdoppeln, wenn die Datenlast gut verteilt ist und Sie die Best Practices für das Schemadesign und das Laden im Bulk befolgen, bis die verfügbaren CPU-Ressourcen in Ihrer Instanz belegt sind.

Daten nach Primärschlüssel partitionieren

Spanner partitioniert Tabellen dynamisch in kleinere Bereiche. Der Primärschlüssel einer Zeile bestimmt, wo sie partitioniert wird.

Partitionieren Sie die Daten mit dem folgenden Muster nach dem Primärschlüssel, um einen optimalen Schreibdurchsatz für das Laden im Bulk zu erhalten:

  • Jede Partition enthält abhängig von den Schlüsselspalten einen Bereich von aufeinanderfolgenden Zeilen.
  • Jeder Commit enthält nur Daten für eine einzige Partition.

Es wird empfohlen, dass die Anzahl der Partitionen zehnmal der Anzahl der Knoten in Ihrer Spanner-Instanz entspricht. So weisen Sie Partitionen Zeilen zu:

  • Filtern Sie die Daten nach Primärschlüssel.
  • Teilen Sie die Daten in 10 * (Anzahl Knoten) getrennte Partitionen gleicher Größe auf.
  • Erstellen Sie für jede Partition eine eigene Worker-Aufgabe und weisen Sie diese zu. Die Worker-Aufgaben werden in Ihrer Anwendung erstellt. Dies ist keine Spanner-Funktion.

Nach diesem Muster ergibt sich normalerweise ein Gesamtdurchsatz von 10–20 MB pro Sekunde und Knoten für den Bulk-Schreibvorgang.

Beim Laden von Daten erstellt und aktualisiert Spanner Splits, um die Last auf die Knoten in Ihrer Instanz zu verteilen. Bei diesem Vorgang kann es zu einem vorübergehenden Rückgang des Durchsatzes kommen.

Beispiel

Eine regionale Konfiguration hat 3 Knoten. Es sind 90.000 Zeilen in einer nicht verschränkten Tabelle enthalten. Die Primärschlüssel in der Tabelle reichen von 1 bis 90.000.

  • Zeilen: 90.000 Zeilen
  • Knoten: 3
  • Partitionen: 10 * 3 = 30
  • Zeilen pro Partition: 90.000 / 30 = 3.000

Die erste Partition umfasst den Schlüsselbereich 1 bis 3.000. Die zweite Partition umfasst den Schlüsselbereich 3.001 bis 6.000. Die 30. Partition umfasst den Schlüsselbereich 87.001 bis 90.000. (Sie sollten in einer großen Tabelle keine sequentiellen Schlüssel verwenden. Dieses Beispiel dient nur zur Veranschaulichung.)

Jede Worker-Aufgabe sendet die Schreibvorgänge für eine einzelne Partition. Innerhalb jeder Partition sollten Sie die Zeilen nach Primärschlüssel schreiben. Auch bei zufälligen Schreibvorgängen in Bezug auf den Primärschlüssel ergibt sich so ein angemessen hoher Durchsatz. Über Testläufe erfahren Sie, welcher Ansatz die beste Leistung für Ihr Dataset bietet.

Wenn Sie keine Partitionen verwenden wollen

Das Schreiben zufälliger Zeilen innerhalb eines Commits kann länger dauern als das Schreiben eines zusammenhängenden Satzes von Zeilen in einem Commit und wahrscheinlich Daten in verschiedenen Partitionen. Die Commit-Latenz und der Overhead sind aufgrund der besseren Koordination zwischen den Servern höher, wenn mehr Splits in einen Commit geschrieben werden. Es sind wahrscheinlich mehrere Splits beteiligt, da jede zufällig ausgewählte Zeile zu einem anderen Split gehören kann. Im ungünstigsten Fall umfasst jeder Schreibvorgang jeden Split in der Spanner-Instanz. Wie bereits erwähnt, verringert sich der Schreibdurchsatz, wenn mehr Splits beteiligt sind.

Bulk-Ladevorgang ohne Partitionierung

Das Schreiben eines zusammenhängenden Satzes von Zeilen in einen Commit kann schneller sein als das Schreiben zufälliger Zeilen. Zufällige Zeilen enthalten wahrscheinlich auch Daten aus verschiedenen Partitionen.

Wenn mehr Partitionen in einen Commit geschrieben werden, ist mehr Koordination zwischen den Servern erforderlich, was die Commit-Latenz und den Commit-Aufwand erhöht.

Wahrscheinlich sind mehrere Partitionen beteiligt, da jede zufällig ausgewählte Zeile zu einer anderen Partition gehören kann. Im schlimmsten Fall umfasst jeder Schreibvorgang jede Partition in der Spanner-Instanz. Wie bereits erwähnt, verringert sich der Durchsatz für Schreibvorgänge, wenn mehr Partitionen beteiligt sind.

Überlastung vermeiden

Es ist möglich, mehr Schreibanfragen zu senden, als Spanner verarbeiten kann. Spanner verarbeitet die Überlast, indem Transaktionen abgebrochen werden. Dies wird als Pushback bezeichnet. Bei schreibgeschützten Transaktionen wiederholt Spanner die Transaktion automatisch. In diesen Fällen hat der Pushback eine hohe Latenz. Bei hohen Lasten kann der Pushback bis zu einer Minute dauern. Bei sehr großer Last kann der Pushback mehrere Minuten dauern. Sie können einen Pushback vermeiden, indem Sie die Schreibanfragen drosseln, um die CPU-Auslastung in einem angemessenen Grenzwert zu halten. Alternativ können Nutzer die Anzahl der Knoten erhöhen, damit die CPU-Auslastung innerhalb der Limits bleibt.

Commit von Mutationen mit 1 MB bis 5 MB gleichzeitig

Jeder Schreibvorgang in Spanner ist mit einem gewissen Aufwand verbunden, unabhängig davon, ob der Schreibvorgang groß oder klein ist. Maximieren Sie die Datenmenge, die pro Schreibvorgang gespeichert wird, um den Durchsatz zu maximieren. Größere Schreibvorgänge senken den Aufwand pro Schreibvorgang. Es empfiehlt sich, für jeden Commit eine Mutation für Hunderte von Zeilen auszuführen. Wenn relativ große Zeilen geschrieben werden, bietet eine Commit-Größe von 1 MB bis 5 MB normalerweise die beste Leistung. Wenn Sie kleine oder indexierte Werte schreiben, sollten Sie in der Regel höchstens einige hundert Zeilen in einem einzigen Commit schreiben. Unabhängig von der Commit-Größe und der Anzahl der Zeilen ist die Anzahl der Mutationen pro Commit auf 80.000 begrenzt. Sie sollten den Durchsatz testen und messen, um die optimale Leistung zu ermitteln.

Commits, die größer als 5 MB oder mehr als ein paar hundert Zeilen sind, bieten keinen zusätzlichen Vorteil. Außerdem besteht die Gefahr, dass die Spanner-Limits für Commit-Größe und Mutationen pro Commit überschritten werden.

Richtlinien für sekundäre Indexe

Wenn Ihre Datenbank über sekundäre Indexe verfügt, müssen Sie wählen, ob Sie die Indexe vor oder nach dem Laden der Tabellendaten dem Datenbankschema hinzufügen.

  • Wenn Sie den Index vor dem Laden der Daten hinzufügen, kann die Schemaänderung sofort abgeschlossen werden. Allerdings dauert jeder Schreibvorgang, der sich auf den Index auswirkt, länger, da auch der Index aktualisiert werden muss. Wenn der Datenladevorgang abgeschlossen ist, kann die Datenbank sofort mit allen vorhandenen Indexen verwendet werden. Wenn Sie eine Tabelle und ihre Indexe gleichzeitig erstellen möchten, senden Sie die DDL-Anweisungen für die neue Tabelle und die neuen Indexe in einer einzigen Anfrage an Spanner.

  • Wenn Sie den Index nach dem Laden der Daten hinzufügen, ist jeder Schreibvorgang effizient. Die Schemaänderung für jeden Index-Backfill kann jedoch lange dauern. Die Datenbank ist nicht vollständig nutzbar und Abfragen können die Indexe erst verwenden, wenn alle Schemaänderungen abgeschlossen sind. Die Datenbank kann weiterhin Schreib- und Abfragen ausführen, allerdings mit einer geringeren Geschwindigkeit.

Wir empfehlen, für Ihre Geschäftsanwendung wichtige Indexe hinzuzufügen, bevor Sie die Daten laden. Fügen Sie alle nicht kritischen Indexe nach der Migration der Daten hinzu.

Durchsatz testen und messen

Es kann schwierig sein, den Durchsatz vorherzusagen. Sie sollten Ihre Strategie testen, Daten im Bulk zu laden, bevor Sie dies tatsächlich ausführen. Ein ausführliches Beispiel für die Partitionierung und Überwachung von Leistung finden Sie unter Durchsatz für die Datenlast maximieren.

Best Practices für das periodische Laden im Bulk in eine vorhandene Datenbank

Wenn Sie eine vorhandene Datenbank aktualisieren, die Daten enthält, jedoch keine sekundären Indexe hat, gelten weiterhin die Empfehlungen in diesem Thema.

Bei sekundären Indexen hilft Ihnen diese Anleitung wahrscheinlich gut weiter. Die Leistung hängt davon ab, wie viele Splits im Durchschnitt an Ihren Transaktionen beteiligt sind. Wenn der Durchsatz zu niedrig ausfällt, können Sie Folgendes versuchen:

  • Fügen Sie eine geringere Anzahl von Mutationen in jeden Commit ein. Das kann den Durchsatz erhöhen.
  • Wenn Ihr Upload die aktuelle Gesamtgröße der zu aktualisierenden Tabelle überschreitet, löschen Sie die sekundären Indexe und fügen Sie sie nach dem Hochladen der Daten neu hinzu. Dieser Schritt ist normalerweise nicht erforderlich, kann jedoch den Durchsatz verbessern.