Auf dieser Seite wird beschrieben, wie Sie Hotspots in Ihrer Datenbank erkennen und beheben. Sie können sowohl mit GoogleSQL als auch mit PostgreSQL auf Statistiken zu Hotspots in Aufteilungen zugreifen.
Spanner speichert Ihre Daten als zusammenhängenden Schlüsselbereich, sortiert nach den Primärschlüsseln Ihrer Tabellen und Indexe. Ein Split ist ein Bereich von Zeilen aus einer Gruppe von Tabellen oder einem Index. Der Anfang des Splits wird als Split-Start bezeichnet. Mit dem Split-Limit wird das Ende des Splits festgelegt. Die Aufteilung umfasst den Beginn der Aufteilung, aber nicht das Limit.
In Spanner sind Hotspots Situationen, in denen zu viele Anfragen an denselben Server gesendet werden, wodurch die Ressourcen des Servers ausgelastet werden und es möglicherweise zu hohen Latenzen kommt. Die von Hotspots betroffenen Splits werden als Hotspots oder Warmspots bezeichnet.
Die Hotspot-Statistik eines Splits (im System als CPU_USAGE_SCORE gekennzeichnet) ist ein Maß für die Last auf einem Split, die durch die auf dem Server verfügbaren Ressourcen eingeschränkt ist. Dieser Messwert wird als Prozentsatz angegeben. Wenn mehr als 50% der Last auf einem Split durch die verfügbaren Ressourcen eingeschränkt ist, gilt der Split als warm. Wenn 100% der Auslastung einer Teilung eingeschränkt sind, gilt sie als heiß.
Spanner verwendet eine lastbasierte Aufteilung, um die Datenlast gleichmäßig auf die Server der Instanz zu verteilen. Die Warm- und Hot-Splits können zum Load Balancing auf verschiedene Server verschoben oder in kleinere Splits aufgeteilt werden. Möglicherweise kann Spanner die Last jedoch auch nach mehreren Aufteilungsversuchen aufgrund von Anti-Mustern in der Anwendung nicht ausgleichen. Daher sind bei anhaltenden Hotspots, die mindestens 10 Minuten andauern, weitere Schritte zur Fehlerbehebung und mögliche Anwendungsänderungen erforderlich.
Anhand der Statistiken zu heißen Spaltenaufteilungen in Spanner können Sie die Aufteilungen ermitteln, an denen Hotspots auftreten. Sie können dann bei Bedarf Änderungen an Ihrer Anwendung oder Ihrem Schema vornehmen. Sie können diese Statistiken mithilfe von SQL-Anweisungen aus den SPANNER_SYS.SPLIT_STATS_TOP_MINUTE-Systemtabellen abrufen.
Verfügbarkeit von Statistiken für Hot Splits
Spanner stellt die Statistiken für Hot Splits im Schema SPANNER_SYS bereit. SPANNER_SYS-Daten sind nur über GoogleSQL- und PostgreSQL-Schnittstellen verfügbar. Sie haben folgende Möglichkeiten, auf diese Daten zuzugreifen:
- Die Spanner Studio-Seite einer Datenbank in der Google Cloud -Console
- Befehl
gcloud spanner databases execute-sql executeQueryAPI
Spanner-APIs für Einzellesevorgänge unterstützen SPANNER_SYS nicht.
Statistiken zu erfolgreichen Splits
In der folgenden Tabelle können Sie Hot Splits nachverfolgen:
SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Hier sehen Sie Aufteilungen, die in 1-Minuten-Intervallen aktuell sind.
Diese Tabellen haben folgende Attribute:
- Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle in der Dauer, die der Tabellenname festlegt.
Die Intervalle beziehen sich auf die Uhrzeit:
- 1-Minuten-Intervalle enden nach einer Minute.
Nach jedem Intervall erfasst Spanner Daten von allen Servern und stellt die Daten danach in den
SPANNER_SYS-Tabellen bereit.Beispielsweise sind die neuesten, für SQL-Abfragen verfügbaren Intervalle um 11:59:30 Uhr:
- 1 Minute: 00:58:00–00:58:59 Uhr
Spanner gruppiert die Statistiken nach Teilern.
Jede Zeile enthält einen Prozentsatz, der angibt, wie stark ein Split genutzt wird. Dieser Prozentsatz bezieht sich auf jeden Split, für den Spanner während des angegebenen Intervalls Statistiken erfasst.
Wenn weniger als 50% der Last auf einem Split durch die verfügbaren Ressourcen eingeschränkt sind, erfasst Spanner die Statistik nicht. Wenn Spanner nicht alle heißen Splits im angegebenen Intervall speichern kann, priorisiert das System die Splits mit dem höchsten
CPU_USAGE_SCORE-Prozentsatz im angegebenen Intervall. Wenn keine Aufteilungen zurückgegeben werden, gibt es keine Hotspots.
Tabellenschema
Die folgende Tabelle zeigt das Tabellenschema für die folgenden Statistiken:
SPANNER_SYS.SPLIT_STATS_TOP_MINUTE
| Spaltenname | Typ | Beschreibung |
|---|---|---|
INTERVAL_END |
TIMESTAMP |
Ende des Zeitintervalls, in dem der Split stark genutzt wurde |
SPLIT_START |
STRING |
Der Startschlüssel des Zeilenbereichs im Split. Der Split-Start kann auch <begin> sein, was den Beginn des Schlüsselbereichs angibt. |
SPLIT_LIMIT
|
STRING
|
Der Limitschlüssel für den Zeilenbereich im Split. Der Limit-Schlüssel kann auch <end> sein, was das Ende des Schlüsselbereichs angibt.| |
CPU_USAGE_SCORE
|
INT64
|
Der CPU_USAGE_SCORE-Prozentsatz der Aufteilungen. Ein CPU_USAGE_SCORE-Prozentsatz von 50% gibt an, dass es „warme“ oder „heiße“ Splits gibt. |
AFFECTED_TABLES |
STRING ARRAY |
Die Tabellen, deren Zeilen möglicherweise im Split enthalten sind |
Start- und Limitschlüssel für Split
Ein Split ist ein zusammenhängender Zeilenbereich einer Datenbank und wird durch die Schlüssel start und limit definiert. Eine Teilung kann eine einzelne Zeile, ein schmaler oder ein breiter Zeilenbereich sein und mehrere Tabellen oder Indexe umfassen.
In den Spalten SPLIT_START und SPLIT_LIMIT werden die Primärschlüssel einer Warm- oder Hot-Split-Datenquelle angegeben.
Beispielschema
Das folgende Schema ist eine Beispieltabelle für die Themen auf dieser Seite.
GoogleSQL
CREATE TABLE Users (
UserId INT64 NOT NULL,
FirstName STRING(MAX),
LastName STRING(MAX),
) PRIMARY KEY(UserId);
CREATE INDEX UsersByFirstName ON Users(FirstName DESC);
CREATE TABLE Threads (
UserId INT64 NOT NULL,
ThreadId INT64 NOT NULL,
Starred BOOL,
) PRIMARY KEY(UserId, ThreadId),
INTERLEAVE IN PARENT Users ON DELETE CASCADE;
CREATE TABLE Messages (
UserId INT64 NOT NULL,
ThreadId INT64 NOT NULL,
MessageId INT64 NOT NULL,
Subject STRING(MAX),
Body STRING(MAX),
) PRIMARY KEY(UserId, ThreadId, MessageId),
INTERLEAVE IN PARENT Threads ON DELETE CASCADE;
CREATE INDEX MessagesIdx ON Messages(UserId, ThreadId, Subject),
INTERLEAVE IN Threads;
PostgreSQL
CREATE TABLE users
(
userid BIGINT NOT NULL PRIMARY KEY,-- INT64 to BIGINT
firstname VARCHAR(max),-- STRING(MAX) to VARCHAR(MAX)
lastname VARCHAR(max)
);
CREATE INDEX usersbyfirstname
ON users(firstname DESC);
CREATE TABLE threads
(
userid BIGINT NOT NULL,
threadid BIGINT NOT NULL,
starred BOOLEAN, -- BOOL to BOOLEAN
PRIMARY KEY (userid, threadid),
CONSTRAINT fk_threads_user FOREIGN KEY (userid) REFERENCES users(userid) ON
DELETE CASCADE -- Interleave to Foreign Key constraint
);
CREATE TABLE messages
(
userid BIGINT NOT NULL,
threadid BIGINT NOT NULL,
messageid BIGINT NOT NULL PRIMARY KEY,
subject VARCHAR(max),
body VARCHAR(max),
CONSTRAINT fk_messages_thread FOREIGN KEY (userid, threadid) REFERENCES
threads(userid, threadid) ON DELETE CASCADE
-- Interleave to Foreign Key constraint
);
CREATE INDEX messagesidx ON messages(userid, threadid, subject), REFERENCES
threads(userid, threadid);
Angenommen, Ihr Schlüsselbereich sieht so aus:
| PRIMÄRSCHÜSSEL |
|---|
<begin> |
Users() |
Threads() |
Users(2) |
Users(3) |
Threads(3) |
Threads(3,"a") |
Messages(3,"a",1) |
Messages(3,"a",2) |
Threads(3, "aa") |
Users(9) |
Users(10) |
Threads(10) |
UsersByFirstName("abc") |
UsersByFirstName("abcd") |
<end> |
Beispiel für eine Aufteilung
Im Folgenden finden Sie einige Beispielaufteilungen, die veranschaulichen, wie diese aussehen.
SPLIT_START und SPLIT_LIMIT können die Zeile einer Tabelle oder eines Index angeben. Es kann sich aber auch um <begin> und <end> handeln, die die Grenzen des Schlüsselbereichs der Datenbank darstellen. SPLIT_START und SPLIT_LIMIT können auch gekürzte Schlüssel enthalten, d. h. Schlüssel, die vor einem vollständigen Schlüssel in der Tabelle stehen. Beispiel: Threads(10) ist ein Präfix für jede Threads-Zeile, die in Users(10) verschachtelt ist.
| SPLIT_START | SPLIT_LIMIT | AFFECTED_TABLES | ERKLÄRUNG |
|---|---|---|---|
Users(3) |
Users(10) |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Die Aufteilung beginnt bei Zeile UserId=3 und endet bei der Zeile vor Zeile UserId = 10. Die Aufteilung enthält die Tabellenzeilen von Users und alle Zeilen der überlappenden Tabellen für UserId=3 bis 10. |
Messages(3,"a",1) |
Threads(3,"aa") |
Threads, Messages, MessagesIdx |
Die Aufteilung beginnt bei der Zeile mit UserId=3, ThreadId="a" und MessageId=1 und endet bei der Zeile vor der Zeile mit dem Schlüssel UserId=3 und ThreadsId = "aa". Die Aufteilung enthält alle Tabellen zwischen Messages(3,"a",1) und Threads(3,"aa"). Da split_start und split_limit in derselben übergeordneten Tabellenzeile verschachtelt sind, enthält der Split die verschachtelten Tabellenzeilen zwischen Start und Limit. Unter Übersicht über Schemas erfahren Sie, wie überlappende Tabellen zusammenhängen. |
Messages(3,"a",1) |
<end> |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Die Aufteilung beginnt in der Tabelle „Nachrichten“ bei der Zeile mit dem Schlüssel UserId=3, ThreadId="a" und MessageId=1. Der Split enthält alle Zeilen von split_start bis <end>, dem Ende des Schlüsselbereichs der Datenbank. Alle Zeilen der Tabellen nach split_start, z. B. Users(4), sind in der Aufteilung enthalten. |
<begin> |
Users(9) |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Die Aufteilung beginnt bei <begin>, dem Beginn des Schlüsselbereichs der Datenbank, und endet mit der Zeile vor der Zeile Users mit UserId=9. Der Split enthält also alle Tabellenzeilen vor Users, alle Zeilen der Tabelle Users vor UserId=9 und die Zeilen der verschachtelten Tabellen. |
Messages(3,"a",1) |
Threads(10) |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Der Split beginnt bei Messages(3,"a", 1), ist in Users(3) verschachtelt und endet in der Zeile vor Threads(10). Threads(10) ist ein gekürzter Split-Schlüssel, der ein Präfix eines beliebigen Schlüssels der Threads-Tabelle ist, die in Users(10) verschachtelt ist. |
Users() |
<end> |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Der Split beginnt am abgeschnittenen Split-Schlüssel von Users(), der vor jedem vollständigen Schlüssel der Tabelle Users steht. Die Aufteilung erstreckt sich bis zum Ende des möglichen Schlüsselbereichs in der Datenbank. „affected_tables“ umfasst daher die Tabelle Users, ihre verschachtelten Tabellen und Indexe sowie alle Tabellen, die nach den Nutzern angezeigt werden können. |
Threads(10) |
UsersByFirstName("abc") |
UsersByFirstName: Users, Threads, Messages, MessagesIdx |
Die Aufteilung beginnt in Zeile Threads mit UserId = 10 und endet beim Index UsersByFirstName im Schlüssel vor "abc". |
Beispielabfragen zum Finden von erfolgreichen Splits
Das folgende Beispiel zeigt eine SQL-Anweisung, mit der Sie die Statistiken für Hot Splits abrufen können. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, gcloud oder der Google Cloud -Konsole ausführen.
GoogleSQL
SELECT t.split_start,
t.split_limit,
t.cpu_usage_score,
t.affected_tables,
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end =
(SELECT MAX(interval_end)
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE)
ORDER BY t.cpu_usage_score DESC;
PostgreSQL
SELECT t.split_start,
t.split_limit,
t.cpu_usage_score,
t.affected_tables
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end = (
SELECT MAX(interval_end)
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE
)
ORDER BY t.cpu_usage_score DESC;
Die Abfrageausgabe sieht so aus:
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
AFFECTED_TABLES |
|---|---|---|---|
Users(13) |
Users(76) |
82 |
Messages,Users,Threads |
Users(101) |
Users(102) |
90 |
Messages,Users,Threads |
Threads(10, "a") |
Threads(10, "aa") |
100 |
Messages,Threads |
Messages(631, "abc", 1) |
Messages(631, "abc", 3) |
100 |
Messages |
Threads(12, "zebra") |
Users(14) |
76 |
Messages,Users,Threads |
Users(620) |
<end> |
100 |
Messages,Users,Threads |
Datenaufbewahrung für Statistiken zur Hot Split-Testvariante
Spanner speichert die Daten für jede Tabelle mindestens für den folgenden Zeitraum:
SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Intervalle der letzten 6 Stunden.
Fehlerbehebung bei Hotspots mithilfe von Statistiken zu Hot Splits
In diesem Abschnitt wird beschrieben, wie Sie Hotspots erkennen und beheben.
Zeitraum auswählen, der untersucht werden soll
Prüfen Sie die Latenzmesswerte für Ihre Spanner-Datenbank, um den Zeitraum zu ermitteln, in dem Ihre Anwendung eine hohe Latenz und hohe CPU-Auslastung aufweist. Beispiel: Es wird angezeigt, dass ein Problem am 18. Mai 2024 um 22:50 Uhr aufgetreten ist.
Dauerhaften Hotspot finden
Da Spanner die Last mithilfe der lastbasierten Aufteilung ausgleicht, sollten Sie prüfen, ob das Hotspotting länger als 10 Minuten andauert. Dazu können Sie die Tabelle SPANNER_SYS.SPLIT_STATS_TOP_MINUTE abfragen, wie im folgenden Beispiel gezeigt:
GoogleSQL
SELECT Count(DISTINCT t.interval_end)
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.utilization >= 50
AND t.interval_end >= "interval_end_date_time"
AND t.interval_end <= "interval_end_date_time";
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
PostgreSQL
SELECT COUNT(DISTINCT t.interval_end)
FROM SPLIT_STATS_TOP_MINUTE t
WHERE t.utilization >= 50
AND t.interval_end >= 'interval_end_date_time'::timestamptz
AND t.interval_end <= 'interval_end_date_time'::timestamptz;
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
Wenn das vorherige Abfrageergebnis 10 entspricht, kommt es in Ihrer Datenbank zu Hotspots, die möglicherweise weiter behoben werden müssen.
Aufteilungen mit dem höchsten CPU_USAGE_SCORE-Wert ermitteln
In diesem Beispiel führen wir die folgende SQL-Abfrage aus, um die Zeilenbereiche mit der höchsten CPU_USAGE_SCORE-Ebene zu ermitteln:
GoogleSQL
SELECT t.split_start,
t.split_limit,
t.affected_tables,
t.cpu_usage_score
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.cpu_usage_score >= 50
AND t.interval_end = "interval_end_date_time";
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
PostgreSQL
SELECT t.split_start,
t.split_limit,
t.affected_tables,
t.cpu_usage_score
FROM SPLIT_STATS_TOP_MINUTE t
WHERE t.cpu_usage_score = 100
AND t.interval_end = 'interval_end_date_time'::timestamptz;
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
Die vorherige SQL-Anweisung gibt Folgendes aus:
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
AFFECTED_TABLES |
|---|---|---|---|
Users(180) |
<end> |
85 |
Messages,Users,Threads |
Users(24) |
Users(76) |
76 |
Messages,Users,Threads |
In dieser Ergebnistabelle sehen Sie, dass Hotspots bei zwei Aufteilungen aufgetreten sind. Die lastbasierte Aufteilung von Spanner kann versuchen, Hotspots in diesen Aufteilungen zu beheben. Dies ist jedoch möglicherweise nicht möglich, wenn es im Schema oder in der Arbeitslast problematische Muster gibt. Um festzustellen, ob es Aufspaltungen gibt, die Ihre Aufmerksamkeit erfordern, empfehlen wir, die Aufspaltungen mindestens 10 Minuten lang zu verfolgen. Mit der folgenden SQL-Abfrage wird beispielsweise die erste Aufteilung in den letzten zehn Minuten erfasst.
GoogleSQL
SELECT t.interval_end,
t.split_start,
t.split_limit,
t.cpu_usage_score
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.split_start = "users(180)"
AND t.split_limit = "<end>"
AND t.interval_end >= "interval_end_date_time"
AND t.interval_end <= "interval_end_date_time";
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
PostgreSQL
SELECT t.interval_end,
t.split_start,
t.split_limit,
t.cpu_usage_score
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.split_start = 'users(180)'
AND t.split_limit = ''
AND t.interval_end >= 'interval_end_date_time'::timestamptz
AND t.interval_end <= 'interval_end_date_time'::timestamptz;
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
Die vorherige SQL-Anweisung gibt Folgendes aus:
INTERVAL_END |
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
|---|---|---|---|
2024-05-18T17:46:00Z |
Users(180) |
<end> |
85 |
2024-05-18T17:47:00Z |
Users(180) |
<end> |
85 |
2024-05-18T17:48:00Z |
Users(180) |
<end> |
85 |
2024-05-18T17:49:00Z |
Users(180) |
<end> |
85 |
2024-05-18T17:50:00Z |
Users(180) |
<end> |
85 |
Die Aufteilung war in den letzten Minuten sehr gefragt. Sie können die Aufteilung länger beobachten, um festzustellen, ob der Hotspot durch die lastbasierte Aufteilung von Spanner gemildert wird. Es kann vorkommen, dass Spanner den Load Balancing-Vorgang nicht weiter ausführen kann.
Fragen Sie beispielsweise die Tabelle SPANNER_SYS.SPLIT_STATS_TOP_MINUTE ab. Sehen Sie sich die folgenden Beispielszenarien an.
GoogleSQL
SELECT t.interval_end,
t.split_start,
t.split_limit,
t.cpu_usage_score
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end >= "interval_end_date_time"
AND t.interval_end <= "interval_end_date_time";
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
PostgreSQL
SELECT t.interval_end,
t.split_start,
t.split_limit,
t._cpu_usage
FROM SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end >= 'interval_end_date_time'::timestamptz
AND t.interval_end <= 'interval_end_date_time'::timestamptz;
Ersetzen Sie interval_end_date_time durch das Datum und die Uhrzeit für das Intervall im Format 2024-05-18T17:40:00Z.
Einzelne „heiße“ Zeile
Im folgenden Beispiel sieht es so aus, als ob Threads(10,"spanner") in einer einzelnen Zeilenaufteilung enthalten ist, die über 10 Minuten lang aktiv war. Das kann passieren, wenn eine beliebte Zeile ständig geladen wird.
INTERVAL_END |
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
|---|---|---|---|
2024-05-16T20:40:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:41:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:42:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:43:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:44:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:45:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
62 |
2024-05-16T20:46:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
80 |
2024-05-16T20:47:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
80 |
2024-05-16T20:48:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
80 |
2024-05-16T20:49:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
100 |
2024-05-16T20:50:00Z |
Threads(10,"spanner") |
Threads(10,"spanner1") |
100 |
Spanner kann die Last für diesen einzelnen Schlüssel nicht ausgleichen, da er nicht weiter aufgeteilt werden kann.
Beweglicher Hotspot
Im folgenden Beispiel wird die Last im Laufe der Zeit durch zusammenhängende Aufteilungen verschoben und über Zeitintervalle hinweg zu einer neuen Aufteilung weitergeleitet.
INTERVAL_END |
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
|---|---|---|---|
2024-05-16T20:40:00Z |
Threads(1,"a") |
Threads(1,"aa") |
100 |
2024-05-16T20:41:00Z |
Threads(1,"aa") |
Threads(1,"ab") |
100 |
2024-05-16T20:42:00Z |
Threads(1,"ab") |
Threads(1,"c") |
100 |
2024-05-16T20:43:00Z |
Threads(1,"c") |
Threads(1,"ca") |
100 |
Dies kann beispielsweise bei einer Arbeitslast auftreten, bei der Schlüssel in monoton steigender Reihenfolge gelesen oder geschrieben werden. Spanner kann die Last nicht ausgleichen, um die Auswirkungen dieses Anwendungsverhaltens zu mindern.
Normales Load Balancing
Spanner versucht, die Last auszugleichen, indem weitere Teilmengen hinzugefügt oder verschoben werden. Das folgende Beispiel zeigt, wie das aussehen könnte.
INTERVAL_END |
SPLIT_START |
SPLIT_LIMIT |
CPU_USAGE_SCORE |
|---|---|---|---|
2024-05-16T20:40:00Z |
Threads(1000,"zebra") |
<end> |
82 |
2024-05-16T20:41:00Z |
Threads(1000,"zebra") |
<end> |
90 |
2024-05-16T20:42:00Z |
Threads(1000,"zebra") |
<end> |
100 |
2024-05-16T20:43:00Z |
Threads(1000,"zebra") |
Threads(2000,"spanner") |
100 |
2024-05-16T20:44:00Z |
Threads(1200,"c") |
Threads(2000) |
92 |
2024-05-16T20:45:00Z |
Threads(1500,"c") |
Threads(1700,"zach") |
76 |
2024-05-16T20:46:00Z |
Threads(1700) |
Threads(1700,"c") |
76 |
2024-05-16T20:47:00Z |
Threads(1700) |
Threads(1700,"c") |
50 |
2024-05-16T20:48:00Z |
Threads(1700) |
Threads(1700,"c") |
39 |
Hier wurde der größere Split am 16.05.2024 um 17:40:00 Uhr (UTC) in einen kleineren Split aufgeteilt. Dadurch ist die Statistik CPU_USAGE_SCORE gesunken.
Spanner erstellt möglicherweise keine Splits in einzelne Zeilen. Die Aufteilungen spiegeln die Arbeitslast wider, die zu der hohen CPU_USAGE_SCORE-Statistik führt.
Wenn Sie über einen Zeitraum von mehr als 10 Minuten eine anhaltende Hot Split-Situation beobachten, lesen Sie den Hilfeartikel Best Practices zur Minimierung von Hotspots.
Best Practices zur Minimierung von Hotspots
Wenn das Load Balancing die Latenz nicht verringert, müssen Sie als Nächstes die Ursache für die Hotspots ermitteln. Danach haben Sie die Möglichkeit, entweder die Arbeitslast für Hotspots zu reduzieren oder das Anwendungsschema und die Logik zu optimieren, um Hotspots zu vermeiden.
Ursache ermitteln
Verwenden Sie die Statistiken zu Sperren und Transaktionen, um nach Transaktionen mit einer langen Wartezeit bei der Sperrung zu suchen, bei denen sich der Startschlüssel des Zeilenbereichs in der Hot Split befindet.
Verwenden Sie die Abfragestatistiken, um nach Abfragen zu suchen, die aus der Tabelle mit dem heißen Split gelesen werden und bei denen sich die Latenz in letzter Zeit erhöht hat oder das Verhältnis von Latenz zu CPU höher ist.
Verwenden Sie Älteste aktive Abfragen, um nach Abfragen zu suchen, die Daten aus der Tabelle mit der Hot Split-Partition lesen und eine höhere als die erwartete Latenz haben.
Achten Sie auf folgende Sonderfälle:
- Prüfen Sie, ob die Gültigkeitsdauer (TTL) vor Kurzem aktiviert wurde. Wenn es viele Aufteilungen aus alten Daten gibt, kann TTL beim Löschen großer Datenmengen die
CPU_USAGE_SCORE-Ebenen erhöhen. In diesem Fall sollte sich das Problem von selbst beheben, sobald die anfänglichen Löschvorgänge abgeschlossen sind.
Arbeitslast optimieren
- Beachten Sie die Best Practices für SQL. Prüfen Sie, ob veraltete Lesevorgänge, Schreibvorgänge ohne vorherige Lesevorgänge oder Indexe die Ursache sind.
- Orientieren Sie sich an den Best Practices für Schemas. Achten Sie darauf, dass Ihr Schema für das Load Balancing ausgelegt ist und Hotspots vermieden werden.
Nächste Schritte
- Best Practices für das Schemadesign
- Weitere Informationen zu Key Visualizer
- Beispiele für Schemadesigns ansehen
- Informationen zum Ermitteln von Hotspots mit dem Dashboard für Split-Statistiken14