Suchindexe partitionieren

Spanner unterstützt sowohl nicht partitionierte als auch partitionierte Suchindexe. Auf dieser Seite wird beschrieben, wie Sie einen partitionierten Suchindex in Spanner erstellen.

Übersicht

Ein nicht partitionierter Index wird erstellt, wenn die Klausel PARTITION BY in der Indexdefinition weggelassen wird. In einem nicht partitionierten Index muss eine Abfrage aus für alle Indexaufteilungen. Dadurch wird die potenzielle Skalierbarkeit der Volltextsuche eingeschränkt. Abfragen.

Partitionierte Indexe unterteilen den Index dagegen in kleinere Einheiten, eine für jede eindeutige Partition. Abfragen können jeweils nur in einer einzelnen Partition gesucht werden, die durch eine Gleichheitsbedingung in der WHERE-Klausel angegeben wird. Abfragen auf partitionierte Indexe sind im Allgemeinen effizienter als Abfragen auf nicht partitionierte Indexe, da Spanner nur Daten für eine einzelne Partition lesen muss. Die Partitionierung des Suchindexes entspricht dem Schlüsselpräfix eines sekundären Index.

Angenommen, es gibt 1.000.000 SingerIds in einer Datenbank und die folgenden beiden Indexe:

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  SingerId STRING(MAX) NOT NULL,
  ReleaseTimestamp INT64 NOT NULL,
  AlbumTitle STRING(MAX),
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
  SingerId_Tokens TOKENLIST AS (TOKEN(SingerId)) HIDDEN
) PRIMARY KEY(SingerId, AlbumId);

CREATE SEARCH INDEX AlbumsUnpartitionedIndex
ON Albums(AlbumTitle_Tokens, SingerId_Tokens);

CREATE SEARCH INDEX AlbumsIndexBySingerId
ON Albums(AlbumTitle_Tokens)
PARTITION BY SingerId;

In der folgenden Abfrage wird der Index AlbumsIndexBySingerId ausgewählt, da nur nach Daten für einen einzelnen Sänger gesucht wird. Bei dieser Art von Abfrage werden in der Regel weniger Ressourcen verbraucht.

SELECT AlbumId
FROM Albums
WHERE SingerId = "singer1"
AND SEARCH(AlbumTitle_Tokens, 'happy')

Es ist auch möglich, AlbumsUnpartitionedIndex für eine Abfrage zu erzwingen, um dieselben Ergebnisse zurückzugeben. Sie verbraucht jedoch mehr Ressourcen, da die Abfrage auf den gesamten Index zugreifen muss. teilt und filtert alle Alben für alle Sänger, um das Token "fröhlich" zu finden, und nicht nur die Splits, die dem Sänger singer1 entsprechen.

Manchmal muss die Anwendung jedoch alle als die Alben eines bestimmten Sängers. In diesen Fällen müssen Sie einen nicht partitionierten Index verwenden:

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'piano concerto 1')

Die allgemeine Empfehlung ist, die Partitionierung mit dem höchsten Detaillierungsgrad das für die Abfrage praktikabel ist. Wenn die Anwendung zum Beispiel ein E-Mail-Postfach abfragt, bei dem jede Suchanfrage auf ein bestimmtes Postfach beschränkt ist, Partitionieren Sie den Suchindex nach der Postfach-ID. Wenn die Abfrage jedoch alle Posteingänge durchsuchen muss, ist ein nicht partitionierter Index besser geeignet.

Bestimmte Anwendungen erfordern möglicherweise mehrere Partitionierungsstrategien, Suchanforderungen berücksichtigen. Ein Inventarverwaltungssystem muss beispielsweise Suchanfragen unterstützen, die nach Produkttyp oder Hersteller gefiltert werden. Außerdem benötigen einige Anwendungen möglicherweise mehrere Vorsortierungen, z. B. wie das Sortieren nach Erstellungs- oder Änderungszeit. In diesen Fällen empfehlen wir, mehrere Suchindizes zu erstellen, die jeweils für die entsprechenden Suchanfragen optimiert sind.

Nächste Schritte