Asynchronen sekundären Index erstellen

Sie können kontinuierliche materialisierte Ansichten als asynchrone sekundäre Indexe für Tabellen verwenden.

Bevor Sie diese Seite lesen, sollten Sie sich mit kontinuierlichen materialisierten Ansichtenvertraut machen.

Daten in einer Bigtable-Tabelle werden in der Regel nach Zeilenschlüsseln indexiert. Sie können jedoch eine kontinuierliche materialisierte Ansicht aus einer Quelltabelle erstellen und sie als asynchronen sekundären Index verwenden. So können Sie dieselben Daten mit verschiedenen Abfragemustern abrufen, indem Sie die materialisierte Ansicht abfragen.

Ein asynchroner sekundärer Index ist eine kontinuierliche materialisierte Ansicht, die eine Teilmenge der Spalten aus einer Quelltabelle sowie einen Zeilenschlüssel enthält, der sich vom Zeilenschlüssel in der Quelltabelle unterscheidet. Diese Zeilenschlüssel können auf den folgenden Transformationen basieren, mit denen Ihre Anwendung dieselben Daten anhand verschiedener Abfragemuster abrufen kann:

Attribute in der Quelltabelle, z. B. Spaltenqualifizierer, Spaltenwerte oder Teile des Quellzeilenschlüssels.
Eine Neuformatierung des Zeilenschlüssels.
Eine Transformation, die den Zeilenschlüssel mit einem Attribut kombiniert.

Bigtable synchronisiert asynchrone sekundäre Indexe automatisch mit der Quell tabelle, wobei die Eventual Consistency gilt.

Wann sollte ein asynchroner sekundärer Index verwendet werden?

Anwendungen müssen oft dieselben Daten mit verschiedenen Suchmustern oder Attributen abfragen. Nehmen wir beispielsweise eine Anwendung, die Nutzerinformationen entweder über die E-Mail-Adresse oder eine Telefonnummer abruft. Sie möchten möglicherweise für beide Abfragemuster die gleiche Leistung. Wenn Sie die E-Mail-Adresse als Bigtable-Zeilenschlüssel verwenden und Telefonnummern in einer Spalte speichern, ist die Leistung der Telefonnummernsuche langsamer, da ein vollständiger Tabellenscan erforderlich ist.

Um die Abfrageleistung bei der Suche nach einer Telefonnummer zu verbessern, können Sie mit einer SQL-Anweisung eine kontinuierliche materialisierte Ansicht erstellen. Die SQL-Anweisung weist Bigtable an, wie Ihre Daten mit einem anderen Zeilenschlüssel umstrukturiert werden sollen. Eine kontinuierliche materialisierte Ansicht verhält sich wie eine Tabelle, die Sie abfragen können. Anschließend verwenden Sie die Ansicht als asynchronen sekundären Index. So erhält Ihre Anwendung einen weiteren Zugriffspfad zu denselben Daten. Jeder Pfad verwendet einen anderen Zeilenschlüssel, sodass Sie für jede Abfrage einen alternativen Pfad auswählen können. Um den besten Pfad für Ihre Abfrage auszuwählen, müssen Sie die Struktur des Zeilenschlüssels für jede Tabelle und die in den einzelnen Tabellen gespeicherten Daten kennen.

Die Verwendung einer kontinuierlichen materialisierten Ansicht als asynchroner sekundärer Index kann die Abfrageleistung in den folgenden Anwendungsfällen verbessern:

Daten neu verschlüsseln: Wenn Sie Ihre Daten mit einem anderen Schlüssel als den Zeilenschlüsseln der Quelltabelle abfragen müssen, können Sie eine kontinuierliche materialisierte Ansicht mit dem alternativen Schlüssel erstellen und diese Ansicht abfragen.
Daten filtern: Wenn Sie die Quelltabelle filtern und nur bestimmte Datenzeilen in den asynchronen sekundären Index einfügen möchten, geben Sie in der SQL-Abfrage, die die Ansicht definiert, eine WHERE Klausel an.
Attributschlüssel: Wenn Sie Ihre Daten anhand eines Nicht-Schlüssel attributs abfragen müssen, z. B. eines Spaltenqualifizierers oder -werts, können Sie es in Ihre ORDER BY Klausel aufnehmen.

Asynchrone sekundäre Indexe

Wenn Sie eine kontinuierliche materialisierte Ansicht in Bigtable als asynchronen sekundären Index verwenden möchten, müssen die folgenden Anforderungen erfüllt sein:

Der Zeilenschlüssel für einen neuen asynchronen sekundären Index muss den Zeilenschlüssel der Quelltabelle enthalten, um eine 1:1-Zuordnung zwischen den Zeilen in der Quelltabelle und den Zeilen im asynchronen sekundären Index der kontinuierlichen materialisierten Ansicht zu gewährleisten.
Der asynchrone sekundäre Index muss nicht dasselbe Schema oder dieselben Attribute wie die Quelltabelle haben. Im SELECT-Teil der SQL-Abfrage müssen Sie angeben, welche Spalten aus der Tabelle erforderlich sind, und alle SQL-Transformationen der Daten, die Sie anwenden möchten.
Für den asynchronen sekundären Index müssen nur Daten kopiert werden, die für das Abfragemuster erforderlich sind. Es ist nicht erforderlich, alle Quelldaten in der Quelltabelle anzugeben.
In Bigtable gibt der von Ihnen ausgewählte Zeilenschlüssel die Standardsortierreihenfolge an.

Wenn Sie asynchrone sekundäre Indexe abfragen möchten, müssen die folgenden Anforderungen erfüllt sein:

Jede Spalte in der ORDER BY-Klausel muss auch in der SELECT-Klausel enthalten sein.
Nachdem Sie den asynchronen sekundären Index definiert haben, muss Ihre Anwendung zwischen der Abfrage der Quelltabelle und der materialisierten Ansicht, die den asynchronen sekundären Index darstellt, wählen können.
Anwendungen schreiben nicht direkt in den Index, der kontinuierlich mit der Quelltabelle synchronisiert wird. Schreiben Sie immer in die Quelltabelle.
Der asynchrone sekundäre Index unterliegt der Eventual Consistency. Daten werden zuerst in die Quelltabelle geschrieben und dann in das Format des asynchronen sekundären Index transformiert.
Wir empfehlen, einen abdeckenden Index zu erstellen. Weitere Informationen finden Sie im Abschnitt Abdeckende Indexe in diesem Dokument.
Die ORDER BY-Klausel muss den unveränderten Zeilenschlüssel der Quelltabelle enthalten und alle Daten müssen in aufsteigender Reihenfolge sortiert sein. Der Zeilenschlüssel in der Quelltabelle wird immer in die materialisierte Ansicht projiziert, kann aber mit anderen Attributen kombiniert werden.
Die Spalten in der ORDER BY-Klausel werden Teil des strukturierten Zeilenschlüssels des asynchronen sekundären Index. Alle anderen ausgewählten Spalten werden zu Nicht-Schlüsselspaltenwerten im asynchronen sekundären Index. Wenn Sie einen Wert in der ORDER BY Klausel in einen bestimmten GoogleSQL-Datentyp für Bigtable konvertieren, behält er seinen Datentyp im strukturierten Zeilenschlüssel des asynchronen sekundären Index bei.

Abdeckende Indexe

Ein abdeckender Index enthält alle Spalten, die für Ihre Abfragen erforderlich sind. Wenn Sie einen abdeckenden Index abfragen, kann Bigtable alle erforderlichen Daten direkt aus dem Index abrufen, ohne auf die Quelltabelle zugreifen zu müssen. Wir empfehlen diesen Ansatz für eine optimale Leistung, da er die Anzahl der Festplattenlesevorgänge minimiert. Wenn Sie einen abdeckenden Index erstellen möchten, müssen Sie in der SELECT-Anweisung alle Spalten angeben, die Sie in Ihren Abfragen benötigen.

Wenn Sie einen nicht abdeckenden Index erstellen möchten, fragen Sie den Index ab und suchen Sie dann mit den Ergebnissen die zusätzlichen Spalten, die Sie aus der Quelltabelle benötigen.

Asynchronen sekundären Index definieren

Sie erstellen einen asynchronen sekundären Index, indem Sie eine kontinuierliche materialisierte Ansicht mit einer SQL-Abfrage erstellen, die den asynchronen sekundären Index definiert.

Im folgenden Beispiel erstellt die SQL-Abfrage einen asynchronen sekundären Index, mit dem Sie Daten zu Nutzerinteraktionen abfragen können. Die ORDER BY-Klausel definiert den strukturierten Zeilenschlüssel des asynchronen sekundären Index, indem sie eine Kombination aus der Telefonnummer, der Nutzer-ID und der E-Mail-Adresse des Nutzers verwendet. Außerdem wird der Spaltenfamilie activity der Name interactions zugewiesen:

SELECT
  user['phone'] AS phone,
  CAST(user['id'] AS INT64) AS user_id,
  _key AS email,
  activity AS interactions
FROM CLICKS_TABLE
ORDER BY 1, 2, 3;

In der folgenden Tabelle wird erläutert, wie der Index erstellt wird, indem die Ansicht derselben Zeile in der Quelltabelle mit dem entsprechenden asynchronen sekundären Index verglichen wird:

Zeile der Quelltabelle	Zeile des asynchronen sekundären Index
Zeilenschlüssel: `_key`: `user1@example.com` Attribute: `user`: `{id: "123", phone: "555-123-4567"}` `activity`: `{action: "CLICKED_PRODUCT_A"}`	Strukturierter Zeilenschlüssel: `phone`: `555-123-4567` `user_id`: `123` `email`: `user1@example.com` Attribut: `interactions`: `{action: "CLICKED_PRODUCT_A"}`
Zeilenschlüssel: `_key`: `user2@example.com` Attribute: `user`: `{id: "456", phone: "555-987-6543"}` `activity`: `{action: "VIEWED_PRODUCT_B"}`	Strukturierter Zeilenschlüssel: `phone`: `555-987-6543` `user_id`: `456` `email`: `user2@example.com` Attribut: `interactions`: `{action: "VIEWED_PRODUCT_B"}`
Zeilenschlüssel: `_key`: `user3@example.com` Attribute: `user`: `{id: "1000", phone: "555-111-2222"}` `activity`: `{action: "ADDED_TO_CART_PRODUCT_C"}`	Strukturierter Zeilenschlüssel: `phone`: `555-111-2222` `user_id`: `1000` `email`: `user3@example.com` Attribut: `interactions`: `{action: "ADDED_TO_CART_PRODUCT_C"}`

Beschränkungen

Um den Ausgabeschlüssel zu lesen, der der Schlüssel des asynchronen sekundären Index ist, können Sie nur SQL-Abfragen verwenden.