Statistiken zu Splits

In diesem Dokument wird beschrieben, wie Sie Hotspots in Ihrer Datenbank erkennen und Fehler beheben. Sie können sowohl mit GoogleSQL als auch mit PostgreSQL auf Statistiken zu Hotspots in Segmenten zugreifen.

Spanner speichert Ihre Daten als zusammenhängenden Schlüsselbereich, der nach den Primärschlüsseln Ihrer Tabellen und Indexe sortiert ist. 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. Der Split umfasst den Split-Start, aber nicht das Split-Limit.

In Spanner sind Hotspots Situationen, in denen zu viele Anfragen an denselben Server gesendet werden, wodurch die Ressourcen des Servers überlastet werden und möglicherweise hohe Latenzen auftreten. Die von Hotspots betroffenen Splits werden als heiße oder warme Splits bezeichnet.

Die Hotspot-Statistik eines Splits (im System als CPU_USAGE_SCORE identifiziert) ist ein Maß für die Last auf einem Split, die durch die auf dem Server verfügbaren Ressourcen eingeschränkt ist. Dieser Wert wird als Prozentsatz angegeben. Wenn mehr als 50% der Last auf einem Split durch die verfügbaren Ressourcen eingeschränkt werden, gilt der Split als „warm“. Wenn 100% der Last auf einem Split eingeschränkt sind, gilt der Split als „hot“. Solche Hot Splits können sich auch auf die Latenz der Anfragen auswirken, die von ihnen verarbeitet werden.

Die CPU_USAGE_SCORE eines Splits kann konstant bleiben oder sich im Laufe der Zeit ändern, je nachdem, auf welche Arbeitslasten der Split zugreift und wie sich die Splitgrenzen ändern.

Basierend auf den Ressourcenbeschränkungen für warme und heiße Splits verwendet Spanner möglicherweise lastbasierte Aufteilung, um die Last gleichmäßig auf den Schlüsselbereich zu verteilen. Die warmen und heißen Splits können zur Lastverteilung auf die Server der Instanz verschoben werden. Spanner führt die lastbasierte Aufteilung im Hintergrund durch, um die Auswirkungen auf die Latenz zu minimieren. Aufgrund von Anti-Patterns in der Anwendung kann Spanner die Last jedoch möglicherweise auch nach mehreren Versuchen nicht ausgleichen. In der Spalte UNSPLITTABLE_REASONS in den Statistikansichten finden Sie die genauen Gründe, warum ein Hot- oder Warm-Split nicht weiter unterteilt werden konnte. Daher müssen dauerhafte warme oder heiße Splits, die mindestens 10 Minuten dauern, möglicherweise weiter untersucht und die Anwendung geändert werden, insbesondere wenn UNSPLITTABLE_REASONS vorhanden sind.

Mit den Statistiken zum Heißlaufen von Spanner-Splits können Sie die Splits ermitteln, in denen Hotspots auftreten, und nachvollziehen, warum sie möglicherweise bestehen bleiben. Anhand dieser Statistiken und UNSPLITTABLE_REASONS-Codes können Sie ermitteln, welche Maßnahmen Sie ergreifen müssen, um Hotspots zu beheben. Sie können dann bei Bedarf Änderungen an Ihrer Anwendung oder Ihrem Schema vornehmen.

Auf Statistiken zu Hot Splits zugreifen

Cloud Spanner stellt die Statistiken für Hot Splits im Schema SPANNER_SYS bereit. SPANNER_SYS-Daten sind ü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
Die Methode executeSql oder executeStreamingSql.

Die folgenden von Spanner bereitgestellten Methoden für einzelne Leseaufrufe unterstützen SPANNER_SYS nicht:

Starken Lesevorgang aus einer einzelnen Zeile oder mehreren Zeilen in einer Tabelle durchführen
Veralteten Lesevorgang aus einer einzelnen Zeile oder mehreren Zeilen in einer Tabelle durchführen
Aus einer einzelnen Zeile oder mehreren Zeilen in einem sekundären Index lesen

Statistiken zu am stärksten genutzten Splits

Mit den folgenden Ansichten können Sie Hot Splits im Blick behalten:

SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Hier werden Splits angezeigt, die in 1-Minuten-Intervallen beliebt sind.
SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: Hier werden Splits angezeigt, die während eines beliebigen Teils eines 10-Minuten-Intervalls beliebt sind.
SPANNER_SYS.SPLIT_STATS_TOP_HOUR: Hier werden Splits angezeigt, die während eines beliebigen Teils eines 1-Stunden-Intervalls beliebt sind.

Diese Ansichten haben folgende Eigenschaften:

Jede Ansicht enthält Daten für nicht überlappende Zeitintervalle in der Länge, die der Ansichtsname festlegt.
Die Intervalle basieren auf der Uhrzeit:
- 1-Minuten-Intervalle enden nach einer vollen Minute.
- 10-Minuten-Intervalle enden in der 10. Minute der Stunde, z. B. 11:10:00, 11:20:00.
- 1-Stunden-Intervalle enden zu jeder vollen Stunde.
Nach jedem Intervall erfasst Cloud Spanner Daten von allen Servern und stellt die Daten danach in den SPANNER_SYS-Ansichten bereit. Beispielsweise sind die neuesten, für SQL-Abfragen verfügbaren Intervalle um 11:59:30 Uhr:
- 1 Minute: 11:58:00–11:58:59 Uhr
- 10 Minuten: 11:40:00–11:49:59 Uhr
- 1 Stunde: 10:00:00–10:59:59 Uhr
Spanner gruppiert die Statistiken nach Splits.
Jede Zeile enthält Statistiken, einschließlich des CPU_USAGE_SCORE-Prozentsatzes, der angibt, wie heiß oder warm ein Split ist, für jeden Split, für den Spanner während des angegebenen Intervalls Statistiken erfasst.
Die Ansicht SPANNER_SYS.SPLIT_STATS_TOP_MINUTE enthält detaillierte Statistiken für jede Minute. In dieser Ansicht können Sie die letzten Ereignisse detailliert debuggen.
In den Ansichten SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE und SPANNER_SYS.SPLIT_STATS_TOP_HOUR werden aggregierte Daten in 10‑Minuten- bzw. Stundenintervallen dargestellt. Verwenden Sie diese Ansichten für die Trendanalyse oder um Probleme der letzten Tage oder Wochen zu untersuchen. Weitere Informationen zur Aggregation finden Sie unter Ereignisaggregation ansehen.
Wenn Spanner nicht alle Hot Splits während des Intervalls speichern kann, priorisiert das System die Splits mit dem höchsten CPU_USAGE_SCORE-Prozentsatz im angegebenen Intervall. Wenn keine Splits zurückgegeben werden, gibt es keine Hot Splits.

Datenaufbewahrung

Die maximale Datenmenge, die Spanner für jede Ansicht zu einem beliebigen Zeitpunkt beibehält, ist wie folgt:

SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Intervalle der letzten 24 Stunden.
SPANNER_SYS.SPLIT_STATS_TOP_10MINUTE: Intervalle der letzten 4 Tage.
SPANNER_SYS.SPLIT_STATS_TOP_HOUR: Intervalle der letzten 30 Tage.

Diese Aufbewahrungszeiträume können nicht verlängert oder verkürzt werden und Sie können nicht verhindern, dass Spanner Statistiken zu Hot Splits erfasst.

Wenn Sie Statistikdaten löschen möchten, müssen Sie entweder die verfolgte Datenbank löschen oder warten, bis die Statistikdaten aus der Aufbewahrung entfernt werden.
Wenn Sie Statistikdaten länger aufbewahren möchten, kopieren Sie die Daten regelmäßig aus den Statistikansichten für den Hot-Split.

Schema ansehen

Die folgende Tabelle zeigt das Schema für Statistiken zu Hot Splits:

Spaltenname	Typ	Beschreibung
`INTERVAL_END`	`TIMESTAMP`	Ende des Zeitintervalls, in dem der Split stark oder sehr 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 Limitschlüssel kann auch <end> sein, was das Ende des Schlüsselbereichs angibt.
`CPU_USAGE_SCORE`	`INT64`	Der `CPU_USAGE_SCORE`-Prozentsatz der Splits. Ein `CPU_USAGE_SCORE`-Prozentsatz von 50% weist auf das Vorhandensein von warmen oder heißen Splits hin.
`AFFECTED_TABLES`	`STRING ARRAY`	Die Tabellen, deren Zeilen möglicherweise im Split enthalten sind.
`UNSPLITTABLE_REASONS`	`STRING ARRAY`	Gibt den Typ der Hotspots an, die durch die lastbasierte Aufteilung nicht behoben werden können, häufig aufgrund von Anti-Patterns. Wenn ein Grund angegeben ist, ist wahrscheinlich eine Nutzeraktion erforderlich, z. B. Anpassungen des Schemas oder der Arbeitslast. Ein leeres Array bedeutet, dass entweder während dieses Intervalls keine nicht aufteilbaren Bedingungen erkannt wurden oder die hohe Last zu kurzlebig war, als dass Spanner hätte feststellen können, ob sie nicht aufteilbar war. Weitere Informationen finden Sie unter `UNSPLITTABLE_REASONS`-Typen.

Split-Start- und Split-Limitschlüssel

Ein Split ist ein zusammenhängender Zeilenbereich einer Datenbank, der durch die Start- und Limit-Schlüssel definiert wird. Eine Aufteilung 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 warmen oder heißen Aufteilung angegeben.

Beispielschema

Das folgende Schema ist eine Beispielstabelle 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);

Stellen Sie sich vor, Ihr Schlüsselbereich sieht so aus:

PRIMÄRSCHLÜ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 Splits

Im Folgenden finden Sie einige Beispiele für Splits, damit Sie sich ein Bild davon machen können.

SPLIT_START und SPLIT_LIMIT können die Zeile einer Tabelle oder eines Index angeben oder <begin> und <end> sein, die die Grenzen des Schlüsselbereichs der Datenbank darstellen. SPLIT_START und SPLIT_LIMIT können auch gekürzte Schlüssel enthalten, die allen vollständigen Schlüsseln in der Tabelle vorangestellt sind. Threads(10) ist beispielsweise 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 in der Zeile mit `UserId=3` und endet in der Zeile vor der Zeile mit `UserId = 10`. Der Split enthält die `Users`-Tabellenzeilen und alle zugehörigen überlappenden Tabellenzeilen für `UserId=3` bis 10.
`Messages(3,"a",1)`	`Threads(3,"aa")`	`Threads`, `Messages`, `MessagesIdx`	Der Split beginnt mit der Zeile mit `UserId=3`, `ThreadId="a"` und `MessageId=1` und endet mit 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 Zeile der übergeordneten Tabelle verschränkt sind, enthält der Split die Zeilen der verschränkten Tabellen zwischen dem Start und dem Grenzwert. Unter schemas-overview erfahren Sie, wie verschachtelte Tabellen zusammen angeordnet werden.
`Messages(3,"a",1)`	`<end>`	`UsersByFirstName`: `Users`, `Threads`, `Messages`, `MessagesIdx`	Die Aufteilung beginnt in der Tabelle „messages“ in 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 dem `split_start`, z. B. `Users(4)`, sind im Split enthalten.
`<begin>`	`Users(9)`	`UsersByFirstName`: `Users`, `Threads`, `Messages`, `MessagesIdx`	Der Split beginnt bei `<begin>`, dem Beginn des Schlüsselbereichs der Datenbank, und endet in der Zeile vor der `Users`-Zeile mit `UserId=9`. Der Split enthält also alle Tabellenzeilen vor `Users`, alle Zeilen der `Users`-Tabelle 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)`, das in `Users(3)` verschachtelt ist, 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 mit dem gekürzten Split-Schlüssel von `Users()`, der jedem vollständigen Schlüssel der Tabelle `Users` vorangestellt ist. Der Split erstreckt sich bis zum Ende des möglichen Schlüsselbereichs in der Datenbank. Die affected_tables umfassen daher die Tabelle `Users`, ihre verschachtelten Tabellen und Indexe sowie alle Tabellen, die nach „users“ angezeigt werden.
`Threads(10)`	`UsersByFirstName("abc")`	`UsersByFirstName`: `Users`, `Threads`, `Messages`, `MessagesIdx`	Der Split beginnt in der `Threads`-Zeile mit `UserId = 10` und endet am Index `UsersByFirstName` mit dem Schlüssel vor `"abc"`.

`UNSPLITTABLE_REASONS`-Typen

Wenn Spanner einen Hotspot nicht durch lastbasiertes Aufteilen beheben kann, werden in der Spalte UNSPLITTABLE_REASONS der Ansichten SPLIT_STATS_TOP_* einer oder mehrere der folgenden Gründe angegeben:

`HOT_ROW`

Beschreibung:Die hohe Last konzentriert sich auf eine einzelne Zeile. In Spanner können keine Aufteilungspunkte innerhalb einer einzelnen Zeile hinzugefügt werden.

Häufige Ursachen:

Häufige Vorgänge mit hohem Volumen (Lesen, Schreiben oder Aktualisieren) für einen einzelnen Schlüssel.
Schemadesigns, die den Zugriff auf eine einzelne Zeile zentralisieren.