Informationen zur Leistung in Cloud Bigtable

Auf dieser Seite finden Sie Informationen zur ungefähren Leistung, die Cloud Bigtable unter optimalen Bedingungen bereitstellen kann, zu Faktoren, die sich auf die Leistung auswirken können, und Tipps zum Testen und Beheben von Leistungsproblemen in Cloud Bigtable.

Leistung bei typischer Arbeitslast

Cloud Bigtable bietet eine äußerst vorhersehbare Leistung, die linear skalierbar ist. Wenn Sie die nachfolgend beschriebenen Ursachen einer niedrigeren Leistung vermeiden, kann jeder Cloud Bigtable-Knoten den folgenden ungefähren Durchsatz bereitstellen, je nachdem, welchen Speichertyp der Cluster verwendet:

Speichertyp Lesevorgänge   Schreibvorgänge   Scans
SSD bis zu 10.000 Zeilen pro Sekunde oder bis zu 10.000 Zeilen pro Sekunde oder bis zu 220 MB/s
HDD bis zu 500 Zeilen pro Sekunde oder bis zu 10.000 Zeilen pro Sekunde oder bis zu 180 MB/s

Bei diesen Schätzwerten wird davon ausgegangen, dass jede Zeile 1 KB Daten enthält.

Grundsätzlich erhöht sich die Leistung eines Clusters linear mit der Anzahl der Knoten im Cluster. Wenn Sie beispielsweise einen SSD-Cluster mit 10 Knoten erstellen, kann der Cluster bei einer typischen Arbeitslast mit ausschließlich Lese- oder Schreibvorgängen bis zu 100.000 Zeilen pro Sekunde unterstützen.

Cloud Bigtable-Kapazität planen

Kompromiss zwischen hohem Durchsatz und niedriger Latenz

Bei der Planung Ihrer Cloud Bigtable-Cluster ist es wichtig, den Kompromiss zwischen Durchsatz und Latenz zu berücksichtigen. Cloud Bigtable wird in einem breiten Spektrum von Anwendungen verwendet und unterschiedliche Anwendungsfälle können unterschiedliche Optimierungsziele haben. Bei einem Batch-Datenverarbeitungsjob könnten Sie beispielsweise den Durchsatz mehr, aber die Latenz weniger beachten. Andererseits kann ein Onlinedienst, der Nutzeranfragen verarbeitet, eine niedrigere Latenz gegenüber dem Durchsatz haben. Daher ist es wichtig, die Kapazität entsprechend zu planen.

Die Zahlen im Bereich Leistung bei typischen Arbeitslasten werden erreicht, wenn Sie den Durchsatz priorisieren, aber die Extremwertlatenz für Cloud Bigtable unter einer solchen Last ist möglicherweise zu hoch für latenzempfindliche Anwendungen. Im Allgemeinen bietet Cloud Bigtable optimale Latenz, wenn die CPU-Auslastung für einen Cluster unter 70 % liegt. Bei latenzempfindlichen Anwendungen empfehlen wir jedoch eine mindestens zweimal so hohe Kapazität für die maximalen Abfragen pro Sekunde Ihrer Anwendung in Cloud Table. Diese Kapazität gewährleistet, dass der Cloud Bigtable-Cluster auf weniger als 50 % CPU-Last ausgeführt wird, sodass er Front-End-Diensten eine niedrige Latenz ermöglicht. Diese Kapazität stellt auch einen Zwischenspeicher für Trafficspitzen oder Schlüsselzugriff-Hotspots bereit, was zu einem ungleichmäßigen Traffic zwischen Knoten im Cluster führen kann.

Typische Arbeitslasten in Cloud Bigtable ausführen

Führen Sie für die Kapazitätsplanung immer Ihre eigenen typischen Arbeitslasten für einen Cloud Bigtable-Cluster aus, damit Sie die beste Ressourcenzuweisung für Ihre Anwendungen ermitteln können.

PerfKit Benchmarker von Google nutzt YCSB, um Cloud-Dienste zu vergleichen. Folgen Sie der PerfKitBenchmarker-Anleitung für Cloud Bigtable, um Tests für Ihre eigenen Arbeitslasten zu erstellen. Dabei sollten Sie die Parameter in den yaml-Benchmarking-Konfigurationsdateien anpassen, damit die generierte Benchmark die folgenden Eigenschaften in Ihrer Produktion widerspiegelt:

Weitere Best Practices finden Sie unter Leistungstest mit Cloud Bigtable.

Ursachen einer niedrigeren Leistung

Wenn Cloud Bigtable eine geringere Leistung erzielt, als in den obigen Schätzwerten angegeben, kann dies mehrere Gründe haben.

  • Das Schema der Tabelle ist nicht korrekt entworfen. Für eine gute Schreibleistung von Cloud Bigtable ist es entscheidend, ein Schema zu entwerfen, mit dem Lese- und Schreibvorgänge gleichmäßig auf alle Tabellen verteilt werden können. Weitere Informationen finden Sie unter Schema entwerfen.
  • Die Zeilen der Cloud Bigtable-Tabelle enthalten große Datenmengen. Bei den oben genannten Leistungsschätzwerten wird davon ausgegangen, dass jede Zeile 1 KB Daten enthält. Sie können größere Datenmengen pro Zeile lesen und schreiben, eine höhere Datenmenge pro Zeile reduziert jedoch die Anzahl an Zeilen pro Sekunde.
  • Die Zeilen der Cloud Bigtable-Tabelle enthalten sehr viele Zellen. Cloud Bigtable benötigt Zeit für die Verarbeitung der einzelnen Zellen in einer Zeile. Außerdem bedeutet jede Zelle eine zusätzliche Datenmenge, die in der Tabelle gespeichert und über das Netzwerk gesendet wird. Wenn Sie beispielsweise 1 KB (1.024 Byte) Daten speichern, ist es sehr viel platzsparender, diese Daten in einer einzelnen Zelle zu speichern als in 1.024 Zellen mit jeweils 1 Byte. Wenn Sie die Daten auf mehr Zellen als nötig aufteilen, erhalten Sie ggf. nicht die bestmögliche Leistung. Wenn Zeilen eine große Anzahl Zellen enthalten, da Spalten mehrere Zeitstempelversionen beinhalten, sollten Sie nur den aktuellsten Wert beibehalten. Eine weitere Option für bereits vorhandene Tabellen wäre es, bei jedem Umschreiben alle vorherigen Versionen zu löschen.
  • Der Cloud Bigtable-Cluster hat nicht ausreichend Knoten. Sollte Ihr Cloud Bigtable Cluster überlastet sein, kann es helfen, mehr Knoten hinzuzufügen. Mit Monitoringtools sehen Sie, ob Ihr Cluster überlastet ist.
  • Der Cloud Bigtable-Cluster wurde vor kurzer Zeit vergrößert oder verkleinert. Nachdem Sie die Anzahl der Knoten in einem Cluster hochskaliert haben, kann es unter Last bis zu 20 Minuten dauern, bis Sie eine signifikante Verbesserung der Clusterleistung feststellen. Wenn Sie die Anzahl der Knoten in einem Cluster herunterskalieren, sollten Sie die Clustergröße nicht um mehr als 10 % in einem zehnminütigen Zeitraum reduzieren, um Latenzspitzen zu minimieren.
  • Der Cloud Bigtable-Cluster nutzt HDD-Festplatten. In den meisten Fällen sollte Ihr Cluster SSD-Festplatten verwenden, die eine deutlich bessere Leistung als HDD-Festplatten liefern. Genaueres erfahren Sie unter Zwischen SSD- und HDD-Speicher wählen.
  • Es liegen Probleme mit der Netzwerkverbindung vor. Netzwerkprobleme können den Durchsatz reduzieren und dazu führen, dass Lesen und Schreiben länger als gewöhnlich dauert. Probleme treten insbesondere dann auf, wenn die Clients nicht in derselben Zone wie der Cloud Bigtable-Cluster oder außerhalb von Google Cloud ausgeführt werden.

Da verschiedene Arbeitslasten Leistungsschwankungen verursachen können, sollten Sie Tests mit Ihren eigenen Arbeitslasten ausführen, um die genauesten Vergleichswerte zu erhalten.

Replikation und Leistung

Das Aktivieren der Replikation wirkt sich auf die Leistung einer Cloud Bigtable-Instanz aus. Die Auswirkungen sind für einige Messwerte positiv und für andere negativ. Machen Sie sich mit den möglichen Auswirkungen auf die Leistung vertraut, bevor Sie die Replikation aktivieren.

Durchsatz für Lesevorgänge

Durch die Replikation kann der Durchsatz von Lesevorgängen verbessert werden, insbesondere wenn Sie Routing mit mehreren Clustern verwenden. Darüber hinaus kann die Replikation die Leselatenz reduzieren, indem Ihre Cloud Bigtable-Daten geografisch näher an den Nutzern Ihrer Anwendung platziert werden.

Durchsatz für Schreibvorgänge

Die Replikation kann zwar die Leseleistung verbessern, den Durchsatz für Schreibvorgänge kann sie jedoch nicht erhöhen. Ein Schreibzugriff auf einen Cluster muss auf alle anderen Cluster in der Instanz repliziert werden. Daher verbraucht jeder Cluster CPU-Ressourcen, um Änderungen aus den anderen Clustern abzurufen. Der Durchsatz für Schreibvorgänge kann ggf. sinken, da die Replikation für jeden Cluster zusätzliche Arbeit erfordert.

Beispiel: Sie haben eine Instanz mit einem einzelnen Cluster, der drei Knoten hat.

Einzel-Cluster-Instanz mit drei Knoten

Wenn Sie dem Cluster weitere Knoten hinzufügen, sind die Auswirkungen auf den Durchsatz der Lesevorgänge anders, als wenn Sie die Replikation durch Hinzufügen eines zweiten Clusters mit drei Knoten aktivieren:

Hinzufügen von Knoten zum ursprünglichen Cluster: Sie können dem Cluster drei Knoten hinzufügen (insgesamt sechs Knoten). Der Durchsatz der Schreibvorgänge für die Instanz verdoppelt sich, die Daten der Instanz sind jedoch nur in einer Zone verfügbar.

Einzel-Cluster-Instanz mit sechs Knoten

Mit Replikation: Alternativ können Sie einen zweiten Cluster mit drei Knoten hinzufügen (insgesamt sechs Knoten). Die Instanz schreibt jetzt jedes Datenelement zweimal: Wenn der Schreibvorgang zum ersten Mal empfangen wird und noch einmal, wenn er auf dem anderen Cluster repliziert wird. Der Durchsatz für Schreibvorgänge nimmt nicht zu und kann ggf. abnehmen. Sie profitieren jedoch davon, dass Ihre Daten in zwei verschiedenen Zonen verfügbar sind.

Zwei-Cluster-Instanz mit sechs Knoten

In diesen Beispielen kann die Instanz mit einem einzelnen Cluster im Vergleich zur replizierten Instanz den doppelten Durchsatz für Schreibvorgänge verarbeiten, auch wenn die Cluster einer jeden Instanz insgesamt sechs Knoten haben.

Replikationslatenz

Wenn Sie Multi-Cluster-Routing verwenden, unterliegt die Replikation für Cloud Bigtable der Eventual Consistency. In der Regel dauert es länger, Daten über eine größere Entfernung hinweg zu replizieren. Replizierte Cluster in verschiedenen Regionen haben normalerweise eine höhere Replikationslatenz als replizierte Cluster in derselben Region.

Anwendungsprofile und Traffic-Routing

Je nach Anwendungsfall verwenden Sie ein oder mehrere Anwendungsprofile für das Routing von Cloud Bigtable-Traffic. Jedes Anwendungsprofil verwendet entweder Multi-Cluster- oder Single-Cluster-Routing. Die Wahl des Routings kann sich auf die Leistung auswirken.

Multi-Cluster-Routing kann die Latenz minimieren. Ein Anwendungsprofil mit Multi-Cluster-Routing leitet Anfragen aus Sicht der Anwendung automatisch an den nächstgelegenen Cluster in einer Instanz weiter. Die Schreibvorgänge werden dann auf die anderen Cluster in der Instanz repliziert. Diese automatische Wahl der kürzesten Entfernung führt zur geringsten Latenz.

Ein Anwendungsprofil, das Single-Cluster-Routing verwendet, kann für bestimmte Anwendungsfälle optimal sein, z. B. für das Trennen von Arbeitslasten oder für die "Lesen nach Schreiben"-Semantik in einem einzelnen Cluster. Die Latenz wird jedoch nicht so verringert wie bei Multi-Cluster-Routing.

Informationen zum Konfigurieren Ihrer Anwendungsprofile für diese und andere Anwendungsfälle finden Sie unter Beispiele für Replikationseinstellungen.

Wie Cloud Bigtable meine Daten mit der Zeit optimiert

Zum Speichern der zugrunde liegenden Daten für jede Ihrer Tabellen teilt Cloud Bigtable die Daten in mehrere Tabellenreihen, die zwischen Knoten in Ihrem Cloud Bigtable-Cluster verschoben werden können. Durch diese Speichermethode kann Cloud Bigtable zwei verschiedene Strategien zur Optimierung Ihrer Daten im Zeitverlauf verwenden:

  1. Cloud Bigtable versucht, ungefähr die gleiche Menge Daten auf jedem Knoten zu speichern.
  2. Cloud Bigtable versucht, die Lese- und Schreibvorgänge gleichmäßig auf alle Cloud Bigtable-Knoten zu verteilen.

Manchmal stehen diese Strategien im Widerspruch zueinander. Wenn beispielsweise die Zeilen einer Tabellenreihe sehr häufig gelesen werden, könnte Cloud Bigtable diese Tabellenreihe auf einem eigenen Knoten speichern, auch wenn das dazu führt, dass auf einigen Knoten mehr Daten als auf anderen gespeichert werden.

Als Teil dieses Vorgangs könnte Cloud Bigtable auch eine Tabellenreihe in zwei oder mehr kleinere Tabellenreihen aufspalten, entweder um die Größe zu reduzieren oder um häufig genutzte Zeilen innerhalb einer Tabellenreihe zu isolieren.

Im folgenden Teil werden diese Strategien detaillierter erläutert.

Datenmenge auf Knoten verteilen

Wenn Sie Daten in eine Cloud Bigtable-Tabelle schreiben, teilt Cloud Bigtable die Daten in Tabellenreihen. Jede Tabellenreihe enthält einen fortlaufenden Bereich an Zeilen innerhalb der Tabelle.

Sollten Sie nur eine kleine Datenmenge in die Tabelle geschrieben haben, wird Cloud Bigtable alle Tabellenreihen auf einem einzigen Knoten in Ihrem Cluster speichern:

Ein Cluster mit vier Tabellenreihen auf einem einzelnen Knoten.

Nachdem sich mehr Tabellenreihen angesammelt haben, wird Cloud Bigtable einige von ihnen zu anderen Knoten verschieben, sodass die Datenmenge gleichmäßiger über den Cluster verteilt ist:

Weitere Tabellenreihen sind auf mehrere Knoten verteilt.

Lese- und Schreibvorgänge gleichmäßig auf Knoten verteilen

Wenn Sie Ihr Schema korrekt entworfen haben, sollten Lese- und Schreibvorgänge gleichmäßig auf die gesamte Tabelle verteilt sein. Es gibt aber Fälle, in denen Sie es nicht verhindern können, dass auf manche Zeilen öfter zugegriffen wird als auf andere. Cloud Bigtable hilft Ihnen an dieser Stelle, da es Lese- und Schreibvorgänge berücksichtigt, wenn es Tabellenreihen auf Knoten verteilt.

Nehmen wir beispielsweise an, 25 % der Lesevorgänge betreffen eine kleine Zahl der Tabellenreihen in einem Cluster und Lesevorgänge wären in allen anderen Tabellenreihen gleichmäßig verteilt:

Von 48 Tabellenreihen gehen 25 % der Lesevorgänge auf 3 Tabellenreihen.

Cloud Bigtable wird die vorhandenen Tabellenreihen umverteilen, sodass Lesevorgänge so gleichmäßig wie möglich auf den gesamten Cluster verteilt sind:

Die drei meistgenutzten Tabellenreihen werden auf ihrem eigenen Knoten isoliert.

Leistungstest mit Cloud Bigtable

Wenn Sie einen Leistungstest für eine Anwendung ausführen, die von Cloud Bigtable abhängig ist, beachten Sie beim Planen und Ausführen des Tests die folgenden Richtlinien:

  • Testen Sie mit genügend Daten.
    • Wenn die Tabellen in Ihrer Produktionsinstanz insgesamt maximal 100 GB Daten pro Knoten enthalten, testen Sie mit einer Tabelle mit derselben Datenmenge.
    • Wenn die Tabellen mehr als 100 GB Daten pro Knoten enthalten, testen Sie sie mit einer Tabelle, die mindestens 100 GB Daten pro Knoten enthält. Wenn die Produktionsinstanz beispielsweise einen Cluster mit vier Knoten hat und die Tabellen in der Instanz insgesamt 1 TB Daten enthalten, führen Sie den Test mit einer Tabelle von mindestens 400 GB aus.
  • Testen Sie mit einer einzelnen Tabelle.
  • Unter der empfohlenen Speicherauslastung pro Knoten bleiben. Weitere Informationen finden Sie unter Speicherauslastung pro Knoten.
  • Einen intensiven Vortest ausführen. Dieser Schritt gibt Cloud Bigtable die Möglichkeit, Daten basierend auf den Zugriffsmustern, die es beobachtet, auf die Knoten zu verteilen.
  • Den Test mindestens 10 Minuten ausführen. Dieser Schritt ermöglicht die weitere Optimierung Ihrer Daten durch Cloud Bigtable. Außerdem wird dafür gesorgt, dass sowohl Lesevorgänge von der Festplatte als auch im Cache gespeicherte Lesevorgänge aus dem Arbeitsspeicher getestet werden.

Fehlerbehebung bei Leistungsproblemen

Wenn Sie der Meinung sind, dass Cloud Bigtable möglicherweise einen Leistungsengpass in Ihrer Anwendung verursacht, prüfen Sie Folgendes:

  • Sehen Sie sich die Key Visualizer-Scans für die Tabelle an. Das Key Visualizer-Tool für Cloud Bigtable erstellt täglich Scans, aus denen die Nutzungsmuster der einzelnen Tabellen in einem Cluster ersichtlich sind. Mit Key Visualizer können Sie prüfen, ob die Nutzungsmuster unerwünschte Ergebnissen bedingen, z. B. Hotspots bei bestimmten Zeilen oder eine übermäßig hohe CPU-Auslastung. Weitere Informationen zum Einstieg in Key Visualizer.
  • Versuchen Sie, den Code, der die Lese- und Schreibvorgänge von Cloud Bigtable durchführt, auszukommentieren. Wenn sich das Leistungsproblem löst, nutzen Sie Cloud Bigtable wahrscheinlich auf eine Art, die in unzulänglicher Leistung resultiert. Wenn das Leistungsproblem weiterhin besteht, liegt das Problem wahrscheinlich nicht an Cloud Bigtable.
  • Achten Sie darauf, möglichst wenig Clients zu erstellen. Das Erstellen eines Clients für Cloud Bigtable ist ein relativ teurer Vorgang. Deshalb sollten Sie so wenig Clients wie möglich erstellen.

    • Wenn Sie die Replikation verwenden oder mithilfe von Anwendungsprofilen unterschiedliche Arten von Traffic für die Instanz ermitteln möchten, erstellen Sie einen Client pro Anwendungsprofil und geben die Clients für die gesamte Anwendung frei.
    • Wenn Sie keine Replikation und keine Anwendungsprofile verwenden, erstellen Sie einen einzigen Client und geben Sie ihn in Ihrer gesamten Anwendung frei.

    Wenn Sie den HBase-Client für Java verwenden, erstellen Sie ein Connection-Objekt anstelle eines Clients, deshalb sollten Sie möglichst wenig Verbindungen erstellen.

  • Schreiben und lesen Sie in möglichst vielen verschiedenen Zeilen Ihrer Tabelle. Cloud Bigtable funktioniert am besten, wenn Lese- und Schreibvorgänge gleichmäßig auf die ganze Tabelle verteilt sind. Dies hilft Cloud Bigtable dabei, die Arbeitslast auf alle Knoten im Cluster zu verteilen. Wenn Lese- und Schreibvorgänge nicht auf alle Knoten in Cloud Bigtable verteilt werden können, beeinträchtigt das die Leistung.

    Wenn Sie feststellen, dass Sie nur eine kleine Anzahl von Zeilen lesen und schreiben, müssen Sie möglicherweise das Schema so neu entwerfen, dass Lese- und Schreibvorgänge gleichmäßiger verteilt sind.

  • Prüfen Sie, ob Sie die gleiche Leistung für Lese- und Schreibvorgänge sehen. Wenn Sie feststellen, dass Lesevorgänge viel schneller als Schreibvorgänge sind, versuchen Sie möglicherweise, Zeilenschlüssel zu lesen, die nicht vorhanden sind, oder einen großen Bereich von Zeilenschlüsseln zu lesen, der nur eine geringe Anzahl von Zeilen enthält.

    Für einen fundierten Vergleich zwischen Lese- und Schreibvorgängen sollten Sie dafür sorgen, dass mindestens 90 % Ihrer Lesevorgänge gültige Ergebnisse zurückgeben. Außerdem sollten Sie beim Lesen einer großen Anzahl an Zeilenschlüsseln die Leistung anhand der tatsächlichen Anzahl an Zeilen in dem Bereich messen und nicht anhand der maximalen Anzahl an Zeilen, die existieren könnten.

  • Verwenden Sie die richtigen Schreibanfragen für Ihre Daten. Durch Auswahl des optimalen Schreibvorgangs Ihrer Daten können Sie eine hohe Leistung erzielen.

Weitere Informationen