Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Schema und Datenmodell

Zusammenfassung Datenmodelle

Eine Cloud Spanner-Datenbank kann eine oder mehrere Tabellen enthalten. Tabellen sehen wie relationale Datenbanktabellen aus, da sie aus Zeilen, Spalten und Werten aufgebaut sind und Primärschlüssel enthalten. Daten in Cloud Spanner sind stark typisiert: Jede Datenbank benötigt ein Schema, das die Datentypen jeder Spalte von jeder Tabelle bestimmen muss. Zu den zulässigen Datentypen gehören skalare Typen und Array-Typen. Sie werden auf der Seite Datentypen genauer erläutert. Für eine Tabelle können Sie auch einen oder mehrere sekundäre Indexe definieren.

Hierarchische Tabellenbeziehungen

Es gibt zwei Möglichkeiten, hierarchische Beziehungen in Cloud Spanner zu definieren: Tabellenverschränkung und Fremdschlüssel.

Die Tabellenverschränkung von Cloud Spanner ist eine gute Wahl für viele über-/untergeordnete Beziehungen, bei denen der Primärschlüssel der untergeordneten Tabelle die Primärschlüsselspalten der übergeordneten Tabelle enthält. Die gemeinsame Anordnung untergeordneter Zeilen mit den übergeordneten Zeilen kann die Leistung erheblich verbessern. Wenn Sie beispielsweise eine Tabelle Customers und eine Tabelle Invoices haben und Ihre Anwendung ruft häufig alle Rechnungen für einen bestimmten Kunden ab, können Sie Invoices als untergeordnete Tabelle von Customers definieren. Dazu deklarieren Sie eine Datenlokalitätsbeziehung zwischen zwei logisch unabhängigen Tabellen: Sie weisen Cloud Spanner an, physisch eine oder mehrere Zeilen von Invoices mit einer Customers-Zeile zu speichern.

Eine ausführliche Erläuterung zur Verschränkung von Tabellen finden Sie weiter unten unter Verschränkte Tabellen erstellen.

Fremdschlüssel sind eine allgemeinere über-/untergeordnete Lösung, die zusätzliche Anwendungsfälle behandelt. Sie sind nicht auf Primärschlüsselspalten beschränkt und Tabellen können mehrere Fremdschlüsselbeziehungen haben, die in einigen Beziehungen als übergeordnete und in anderen als untergeordnete Beziehungen gelten. Eine Fremdschlüsselbeziehung impliziert jedoch nicht, dass sich die Tabellen auf der Speicherebene befinden.

Weitere Informationen zu Fremdschlüsseln und ihrem Vergleich mit verschränkten Tabellen finden Sie in der Übersicht über Fremdschlüssel.

Primärschlüssel

Wie legen Sie für Cloud Spanner fest, welche Invoices-Zeilen mit welchen Customers-Zeilen gespeichert werden sollen? Dazu verwenden Sie den Primärschlüssel dieser Tabellen. Jede Tabelle muss einen Primärschlüssel besitzen und dieser Primärschlüssel kann aus null oder mehr Spalten dieser Tabelle bestehen. Wenn Sie eine Tabelle als einer anderen Tabelle untergeordnet deklarieren, müssen eine oder mehrere Primärschlüsselspalten der übergeordneten Tabelle das Präfix des Primärschlüssels der untergeordneten Tabelle sein. Das bedeutet, wenn der Primärschlüssel einer übergeordneten Tabelle aus n Spalten besteht, muss der Primärschlüssel von jeder ihr untergeordneten Tabelle ebenfalls aus den gleichen n Spalten bestehen, in der gleichen Reihenfolge und beginnend mit der gleichen Spalte.

Cloud Spanner speichert Zeilen in einer Reihenfolge nach Primärschlüsselwerten, wobei untergeordnete Zeilen zwischen übergeordneten Zeilen eingefügt werden, die dasselbe Primärschlüsselpräfix verwenden. Diese Einfügung von untergeordneten Zeilen zwischen übergeordneten Zeilen entlang der Primärschlüsseldimension wird Verschränkung genannt, wobei untergeordnete Tabellen auch als verschränkte Tabellen bezeichnet werden. Eine Abbildung verschränkter Zeilen finden Sie im Abschnitt Verschränkte Tabellen erstellen weiter unten.

Zusammenfassung: Mit Cloud Spanner können Sie Zeilen relationaler Tabellen physisch gemeinsam speichern. Die nachstehenden Schemabeispiele zeigen, wie dieses physische Layout aussieht.

Primärschlüssel auswählen

Mit dem Primärschlüssel wird jede Zeile in einer Tabelle eindeutig identifiziert. Wenn Sie vorhandene Zeilen in einer Tabelle aktualisieren oder löschen möchten, muss die Tabelle über einen Primärschlüssel verfügen, der aus einer oder mehreren Spalten besteht. (Eine Tabelle ohne Primärschlüsselspalten kann nur eine Zeile enthalten.) Oft hat Ihre Anwendung bereits ein Feld, das als Primärschlüssel verwendet werden kann. Im Beispiel der Tabelle Customers oben kann beispielsweise eine von einer Anwendung bereitgestellte CustomerId vorhanden sein, die als Primärschlüssel dient. In anderen Fällen müssen Sie eventuell beim Einfügen einer Zeile einen Primärschlüssel generieren, z. B. einen von Ihnen generierten eindeutigen Wert des Typs INT64.

In allen Fällen sollten Sie darauf achten, keine Hotspots mit der Wahl Ihres Primärschlüssels zu erstellen. Wenn Sie beispielsweise Datensätze mit einer monoton ansteigenden Ganzzahl als Schlüssel einfügen, fügen Sie sie immer am Ende des Schlüsselbereichs ein. Dies ist nicht wünschenswert, da Cloud Spanner die Daten zwischen den Servern nach Schlüsselbereichen aufteilt. Dies bedeutet, dass Ihre Einfügungen auf einen einzelnen Server gerichtet werden und einen Hotspot bilden. Mit diesen Verfahren können Sie die Last auf mehrere Server verteilen und Hotspots vermeiden:

Datenbankaufteilungen

Sie können Hierarchien von Beziehungen zwischen übergeordneten und untergeordneten Elementen zwischen Tabellen mit bis zu sieben Ebenen definieren, was bedeutet, dass Sie Zeilen mit sieben logisch unabhängigen Tabellen zusammen unterbringen können. Wenn die Größe der Daten in Ihren Tabellen gering ist, kann Ihre Datenbank wahrscheinlich von einem einzigen Cloud Spanner-Server verarbeitet werden. Aber was passiert, wenn Ihre relationalen Tabellen wachsen und die Ressourcengrenzen eines einzelnen Servers erreichen? Cloud Spanner ist eine verteilte Datenbank. Dies bedeutet, dass Cloud Spanner Ihre Daten mit wachsender Datenbankgröße in Portionen aufteilt, die als "Splits" bezeichnet werden. Dabei können einzelne Splits voneinander unabhängig verschoben und verschiedenen Servern zugewiesen werden, die sich an verschiedenen physischen Standorten befinden können. Ein Split enthält einen Bereich zusammenhängender Zeilen. Die Start- und Endschlüssel dieses Bereichs werden als "Split-Grenzen" bezeichnet. Cloud Spanner fügt abhängig von der Größe und/oder Last automatisch Split-Grenzen hinzu und entfernt sie. Dadurch ändert sich die Anzahl der Splits in der Datenbank.

Lastbasierte Aufteilung

Als Beispiel dafür, wie Cloud Spanner die lastbasierte Aufteilung zur Vermeidung von Hotspots vornimmt, gehen Sie erst einmal davon aus, dass Ihre Datenbank eine Tabelle mit 10 Zeilen enthält, die öfter gelesen werden als alle anderen Zeilen in der Tabelle. Cloud Spanner kann Split-Grenzen zwischen jeder dieser 10 Zeilen hinzufügen, sodass sie von einem anderen Server verarbeitet werden, sodass nicht alle Lesevorgänge dieser Zeilen die Ressourcen eines einzelnen Servers nutzen können auf.

Als allgemeine Regel gilt: Wenn Sie die Best Practices für das Schemadesign befolgen, kann Cloud Spanner Hotspots so verringern, dass der Lesedurchsatz alle paar Minuten verbessert werden muss, bis Sie die Ressourcen in der Instanz beanspruchen. Sie können auch keine neuen Split-Grenzen hinzufügen, da Sie eine Aufteilung haben, die nur eine einzelne Zeile ohne verschränkte untergeordnete Elemente abdeckt.

Schemabeispiele

Die nachstehenden Schemabeispiele zeigen, wie Sie Cloud Spanner-Tabellen mit und ohne hierarchische Beziehungen erstellen, und veranschaulichen die entsprechenden physischen Layouts der Daten.

Tabelle erstellen

Angenommen, Sie erstellen eine Musikanwendung und Sie benötigen eine einfache Tabelle, in der Zeilen von Sängerdaten gespeichert werden:

Tabelle "Singers" mit 5 Zeilen und 4 Spalten

Logische Ansicht der Zeilen in einer einfachen Tabelle "Singers". Die Primärschlüsselspalte erscheint links neben der fett hervorgehobenen Linie.

Beachten Sie, dass die Tabelle eine Primärschlüsselspalte SingerId enthält, die links von der fett gedruckten Linie angezeigt wird, und dass die Tabellen nach Zeilen, Spalten und Werten geordnet sind.

Sie können die Tabelle mit einem Cloud Spanner-Schema so definieren:

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

Beachten Sie Folgendes zum Beispielschema:

  • Singers ist eine Tabelle im Stammverzeichnis der Datenbankhierarchie, da sie nicht als untergeordnetes Element einer anderen Tabelle definiert ist.
  • Primärschlüsselspalten sind in der Regel mit NOT NULL annotiert. Sie können diese Annotation aber weglassen, wenn NULL-Werte in Schlüsselspalten zulässig sein sollen. Weitere Informationen dazu finden Sie unter Schlüsselspalten.
  • Nicht im Primärschlüssel enthaltene Spalten werden als Nicht-Schlüsselspalten bezeichnet und können die optionale Annotation NOT NULL enthalten.
  • Es ist erforderlich, dass Spalten, die den Typ STRING oder BYTES verwenden, mit einer Länge definiert werden, die die maximale Anzahl von im Feld gespeicherte Unicode-Zeichen angibt. Ausführliche Informationen dazu finden Sie unter Skalare Datentypen.

Wie sieht das physische Layout der Zeilen in der Tabelle Singers aus? Das folgende Diagramm stellt die Zeilen der Tabelle Singers dar, die durch den zusammenhängenden sortierten Primärschlüssel gespeichert wurden, also "Singers(1)", dann "Singers(2)" usw., wobei "Singers(1)" für die Zeile in der Singers-Tabelle, die mit 1 codiert ist, steht.

Beispielzeilen einer Tabelle in zusammenhängender Schlüsselreihenfolge

Physisches Layout der Zeilen in der Tabelle mit einer Beispiel-Split-Grenze, die dazu führt, dass Splits von verschiedenen Servern verarbeitet werden.

Das obige Diagramm zeigt ein Beispiel für eine Split-Grenze zwischen den Zeilen mit den Schlüsseln Singers(3) und Singers(4), wobei die Daten aus den dadurch entstandenen Splits verschiedenen Servern zugewiesen werden. Das bedeutet, dass mit dieser Tabelle Zeilen von Singers-Daten an verschiedenen Standorten gespeichert werden können.

Mehrere Tabellen erstellen

Angenommen, Sie möchten jetzt in der Musikanwendung einige grundlegende Daten zum Album jedes Sängers hinzufügen.

Tabelle "Albums" mit 5 Zeilen und 3 Spalten

Logische Ansicht der Zeilen in einer Tabelle "Albums". Primärschlüsselspalten werden links neben der fett gedruckten Linie dargestellt.

Beachten Sie, dass der Primärschlüssel von Albums aus zwei Spalten besteht: SingerId und AlbumId, um jedes Album mit seinem Sänger zu verknüpfen. Das im Folgenden aufgeführte Beispielschema definiert sowohl die Albums- als auch die Singers-Tabelle im Stamm der Datenbankhierarchie. Damit sind diese Tabellen hierarchisch gleichgeordnet.

-- Schema hierarchy:
-- + Singers (sibling table of Albums)
-- + Albums (sibling table of Singers)
CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

Das physische Layout der Zeilen von Singersund Albums gleicht dem des Diagramms. Die Zeilen der Tabelle Albums sind nach zusammenhängenden Primärschlüsseln gespeichert. Danach sind die Zeilen der Tabelle Singers nach zusammenhängenden Primärschlüsseln gespeichert:

Physisches Layout von Zeilen: Die Zeilen "Albums" und "Singers" sind jeweils nach Schlüsselwert gespeichert

Physisches Layout der Zeilen der Tabellen "Singers" und "Albums", beide am Stamm der Datenbankhierarchie.

Wichtiger Hinweis zum obigen Schema: Cloud Spanner geht von keiner Datenlokalitätsbeziehung zwischen den Tabellen Singers und Albums aus, da es sich um übergeordnete Tabellen handelt. Wenn die Datenbank wächst, kann Cloud Spanner Split-Grenzen zwischen allen oben dargestellten Zeilen einfügen. Dies bedeutet, dass sich die Zeilen der Tabelle Albums am Ende in einem anderen Split als die Zeilen der Tabelle Singers befinden können und die beiden Splits sich unabhängig voneinander verschieben können.

Je nach den Anforderungen Ihrer Anwendung kann es sinnvoll sein, dass Albums-Daten auf verschiedenen Splits von Singers-Daten gespeichert werden. Wenn Ihre Anwendung jedoch häufig Informationen zu allen Alben eines bestimmten Sängers abrufen muss, sollten Sie Albums als untergeordnete Tabelle von Singers erstellen, damit Zeilen aus beiden Tabellen unter der Primärschlüsseldimension gemeinsam gespeichert sind. Im nächsten Beispiel wird dies genauer erläutert.

Verschränkte Tabellen erstellen

Nehmen wir für die Aufgabe, Ihre Musikanwendung zu entwerfen, außerdem an, dass die Anwendung häufig auf Zeilen von sowohl Tabelle Singers als auch Tabelle Albums für einen bestimmten Primärschlüssel zugreifen muss. Beispielsweise muss bei jedem Zugriff auf die Zeile Singers(1) auch auf die Zeilen Albums(1, 1) und Albums(1, 2) zugegriffen werden. Das heißt, Singers und Albums müssen eine starke Datenlokalitätsbeziehung haben.

Sie können diese Datenlokalitätsbeziehung durch Erstellen der Tabelle Albumsals untergeordnete oder verschränkte Tabelle von Singers angeben. Wie im Abschnitt Primärschlüssel erläutert, handelt es sich bei einer verschränkten Tabelle um eine Tabelle, die Sie als einer anderen Tabelle untergeordnet deklariert haben, da die Zeilen der untergeordneten Tabelle zusammen mit der zugehörigen übergeordneten Zeile gespeichert werden sollen. Wie bereits erwähnt, muss das Präfix des Primärschlüssels einer untergeordneten Tabelle dem Primärschlüssel der übergeordneten Tabelle entsprechen.

Die fett dargestellte Zeile im Schema unten zeigt, wie Albums als verschränkte Tabelle von Singers erstellt wird.

-- Schema hierarchy:
-- + Singers
--   + Albums (interleaved table, child table of Singers)
CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Hinweise zu diesem Schema:

  • SingerId, das Präfix des Primärschlüssels der untergeordneten Tabelle Albums, ist auch der Primärschlüssel der übergeordneten Tabelle Singers. Dies ist nicht erforderlich, wenn Singers und Albums sich auf derselben Ebene der Hierarchie befinden. In diesem Schema ist es allerdings erforderlich, weil Albums als untergeordnete Tabelle von Singers deklariert ist.
  • Die Annotation ON DELETE CASCADE bedeutet, dass beim Löschen einer Zeile der übergeordneten Tabelle die Zeile der entsprechenden untergeordneten Tabelle automatisch ebenfalls gelöscht wird, also alle Zeilen, die mit dem gleichen Primärschlüssel beginnen. Wenn eine untergeordnete Tabelle diese Annotation nicht enthält oder die Annotation ON DELETE NO ACTION lautet, müssen Sie die untergeordneten Zeilen löschen, bevor Sie die übergeordnete Zeile löschen können.
  • Verschränkte Zeilen werden zuerst nach Zeilen der übergeordneten Tabelle, dann nach zusammenhängenden Zeilen der untergeordneten Tabelle mit dem Primärschlüssel des übergeordneten Elements sortiert, in diesem Fall also "Singers(1)", dann "Albums(1, 1)", dann "Albums(1, 2)" und so weiter.
  • Die Datenlokalitätsbeziehung zwischen jedem Sänger und dessen Albumdaten würde beibehalten, wenn diese Datenbank aufgeteilt wird, solange die Größe einer Sängerzeile und alle Albums-Zeilen unter 8 GB bleiben und es gibt keinen Hotspot in einer dieser Albums-Zeilen.
  • Nur wenn eine übergeordnete Zeile existiert, können Sie untergeordnete Zeilen einfügen. Die übergeordnete Zeile kann entweder bereits in der Datenbank vorhanden sein oder vor der Einfügen der untergeordneten Zeilen in derselben Transaktion eingefügt werden.

Physisches Layout von Zeilen: "Albums"-Zeilen sind zwischen "Singers"-Zeilen verschränkt

Physisches Layout der Zeilen von "Singers" und ihrer untergeordneten Tabelle "Albums".

Eine Hierarchie von verschränkten Tabellen erstellen

Die hierarchische Beziehung zwischen Singers und Albums kann auf weitere nachfolgende Tabellen erweitert werden. Beispielsweise können Sie eine verschränkte Tabelle namens Songs als untergeordnetes Element von Albums erstellen, um die Trackliste jedes Albums zu speichern:

Tabelle "Songs" mit 6 Zeilen und 4 Spalten

Logische Ansicht von Zeilen in einer Tabelle "Songs". Primärschlüsselspalten werden links neben der fett gedruckten Linie dargestellt.

Songs muss einen Primärschlüssel haben, der aus allen Primärschlüsseln der in der Hierarchie ihr übergeordneten Tabellen besteht, also SingerId und AlbumId.

-- Schema hierarchy:
-- + Singers
--   + Albums (interleaved table, child table of Singers)
--     + Songs (interleaved table, child table of Albums)
CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

CREATE TABLE Songs (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  TrackId      INT64 NOT NULL,
  SongName     STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId, TrackId),
  INTERLEAVE IN PARENT Albums ON DELETE CASCADE;

Das folgende Diagramm stellt eine physische Ansicht verschränkter Zeilen dar. In diesem Beispiel erhöht Cloud Spanner mit einer wachsenden Zahl von Sängern Split-Grenzen zwischen Sängern, um den Lokalität zwischen einem Sänger und den zugehörigen Album- und Songdaten zu erhalten. Wenn die Größe einer Sängerzeile und ihrer untergeordneten Zeilen jedoch das Limit von 8 GB überschreitet oder in den untergeordneten Zeilen ein Hotspot erkannt wird, versucht Cloud Spanner, _verschränkte Grenzwerte für _ verschränkt hinzuzufügentabellen , um diese Hotspot-Zeile mit allen untergeordneten Zeilen darunter zu isolieren.

Im Folgenden sehen Sie eine physische Ansicht verschränkter Zeilen. Sofern nicht die Größe einer einzelnen Sängerzeile und alle ihre untergeordneten Zeilen über die Obergrenze von 8 GB fällt oder in den untergeordneten Zeilen ein Hotspot erkannt wird, bevorzugt Cloud Spanner Split-Grenzen zwischen Sängern, um Daten zu erhalten. Lokalität zwischen einem Sänger und dessen Alben- und Songdaten.

Physische Ansicht der Zeilen: "Songs" sind in "Albums" verschränkt und "Albums" sind zwischen "Singers" verschränkt

Physisches Layout von Zeilen der Tabellen "Singers", "Albums" und "Songs", die eine Hierarchie verschränkter Tabellen bilden.

Zusammenfassung: Eine übergeordnete Tabelle bildet zusammen mit allen untergeordneten und nachfolgenden Tabellen im Schema eine Tabellenhierarchie. Obwohl jede Tabelle in der Hierarchie logisch unabhängig ist, können Sie durch diese physische Verschränkung die Leistung verbessern, da die Tabellen schon vorab verknüpft werden. Dadurch können Sie auf die Zeilen der relationalen Tabellen zusammen zugreifen und gleichzeitig die Zugriffe auf Festplatten minimieren.

Verbinden Sie nach Möglichkeit Daten in verschränkten Tabellen mit dem Primärschlüssel. Da verschränkte Zeilen in der Regel physisch im selben Split wie die übergeordnete Zeile gespeichert werden, kann Cloud Spanner Joins nach Primärschlüssel lokal ausführen, um den Zugriff auf das Laufwerk und den Netzwerkverkehr zu minimieren. Im folgenden Beispiel werden Singers und Albums zum Primärschlüssel SingerId zusammengeführt:

SELECT s.FirstName, a.AlbumTitle
FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;

Das Verschränken von Tabellen in Cloud Spanner wird für 1:n-bezogene Daten empfohlen, auf die häufig zugegriffen wird.

Schlüsselspalten

An den Schlüsseln einer Tabelle sind keine Änderungen möglich: Sie können weder eine Schlüsselspalte zu einer vorhandenen Tabelle hinzufügen noch eine Schlüsselspalte aus einer vorhandenen Tabelle entfernen.

NULLs speichern

Primärschlüsselspalten können zum Speichern von NULLs bestimmt werden. Wenn Sie NULL-Werte in einer Primärschlüsselspalte speichern möchten, lassen Sie die NOT NULL-Klausel für diese Spalte im Schema weg.

Das folgende Beispiel zeigt das Weglassen der NOT NULL-Klausel in der Primärschlüsselspalte SingerId. Da SingerId der Primärschlüssel ist, kann maximal eine Zeile in der Tabelle Singers vorhanden sein, der in der entsprechenden Spalte NULL gespeichert ist.

CREATE TABLE Singers (
  SingerId   INT64,
  FirstName  STRING(1024),
  LastName   STRING(1024),
) PRIMARY KEY (SingerId);

Die Eigenschaft der Primärschlüsselspalte, für die Nullwerte zulässig sind, muss zwischen der übergeordneten und der untergeordneten Tabellendeklaration übereinstimmen. In diesem Beispiel ist Albums.SingerId INT64 NOT NULL nicht zulässig. In der Deklaration des Schlüssels muss die Klausel NOT NULL weggelassen werden, da sie von Singers.SingerId weggelassen wird.

CREATE TABLE Singers (
  SingerId   INT64,
  FirstName  STRING(1024),
  LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,  -- NOT ALLOWED!
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Unzulässige Typen

Folgendes kann nicht vom Typ ARRAY sein:

  • Die Schlüsselspalten einer Tabelle
  • Die Schlüsselspalten eines Index

Mehrinstanzenfähigkeit entwerfen

Falls Sie Daten speichern, die verschiedenen Kunden gehören, möchten Sie eventuell Mehrinstanzenfähigkeit bereitstellen. Zum Beispiel kann es für einen Musikdienst von Interesse sein, die Daten jedes einzelnen Plattenlabels separat zu speichern.

Klassische Mehrinstanzenfähigkeit

Der gängige Ansatz, für Mehrinstanzenfähigkeit zu sorgen, besteht darin, für jeden Kunden eine eigene Datenbank zu erstellen. In diesem Beispiel hat jede Datenbank ihre eigene Tabelle Singers:

Datenbank 1: Ackworth Records
SingerId FirstName LastName
1MarcRichards
2CatalinaSmith
Datenbank 2: Cama Records
SingerId FirstName LastName
3MarcRichards
4GabrielWright
Datenbank 3: Eagan Records
SingerId FirstName LastName
1BenjaminMartinez
2HannaHarris

Schema für das Datenverwaltungsschema für Cloud Spanner-Mehrinstanzenfähigkeit verwenden

Eine weitere Möglichkeit zur Erstellung von Mehrmandantenfähigkeit in Cloud Spanner besteht darin, für jeden Kunden einen anderen Primärschlüsselwert zu verwenden. Sie fügen in Ihre Tabellen eine Spalte mit dem Schlüssel CustomerId oder mit einem ähnlichen Schlüssel ein. Wenn Sie CustomerId zur ersten Schlüsselspalte erklären, ist die Lokalität der Daten für jeden Kunden passend. Cloud Spanner teilt die Daten anhand von Größen- und Lademustern automatisch auf Ihre Knoten auf. In diesem Beispiel gibt es eine einzige Singers-Tabelle für alle Kunden:

Cloud Spanner-Datenbank mit Mehrinstanzenfähigkeit
CustomerId SingerId FirstName LastName
11MarcRichards
12CatalinaSmith
23MarcRichards
24GabrielWright
31BenjaminMartinez
32HannaHarris

Wenn für jeden Kunden eine separate Datenbank erforderlich ist, sind diese Einschränkungen zu beachten:

  • Es gelten Beschränkungen für die Anzahl der Datenbanken pro Instanz und für die Anzahl der Tabellen pro Datenbank. Je nach Kundenanzahl ist es gegebenenfalls nicht möglich, separate Datenbanken oder Tabellen zu verwenden.
  • Das Hinzufügen neuer Tabellen und nicht verschränkter Indexe kann sehr lange dauern. Wenn Ihre Schemas so gestaltet sind, dass das Hinzufügen neuer Tabellen und Indexe erforderlich ist, können Sie möglicherweise nicht die gewünschte Leistung erzielen.

Das Erstellen separater Datenbanken funktioniert eventuell besser, wenn Sie Ihre Tabellen so auf die Datenbanken verteilen, dass jede Datenbank eine geringe Anzahl von Schemaänderungen pro Woche aufweist.

Wenn Sie bei Ihrer Anwendung für jeden Kunden separate Tabellen und Indexe erstellen, sollten Sie nicht alle Tabellen und Indexe in derselben Datenbank ablegen. Teilen Sie sie stattdessen auf viele Datenbanken auf, um Leistungsprobleme beim Erstellen einer großen Anzahl von Indexen zu minimieren. Für die Anzahl der Tabellen und Indexe pro Datenbank gibt es ebenfalls Limits.

Weitere Informationen zu anderen Datenverwaltungsmustern und dem Anwendungsdesign für Mehrinstanzenfähigkeit finden Sie unter Mehrinstanzenfähigkeit in Cloud Spanner implementieren.