Abfrageübersicht

Auf dieser Seite wird die Funktion SEARCH und ihre verschiedenen erweiterten Funktionen beschrieben, die zum Ausführen von Volltextsuchanfragen in Spanner-Tabellen verwendet werden.

Suchindex abfragen

Spanner bietet die SEARCH Funktion für Suchindex abfragen. Ein Beispiel für einen Anwendungsfall wäre eine Anwendung, in der Nutzer Text in ein Suchfeld eingeben und die Anwendung die Nutzereingabe direkt an die Funktion SEARCH sendet. Die Funktion SEARCH würde dann einen Suchindex verwenden, um diesen Text zu finden.

Die Funktion SEARCH erfordert zwei Argumente:

  • Einen Namen für den Suchindex
  • Eine Suchanfrage

Die Funktion SEARCH funktioniert nur, wenn ein Suchindex definiert ist. Die Funktion SEARCH kann mit beliebigen SQL-Konstrukten wie Filtern, Aggregationen oder Joins kombiniert werden.

Die Funktion SEARCH kann nicht mit Transaktionsabfragen verwendet werden.

Die folgende Abfrage verwendet die Funktion SEARCH, um alle Alben zurückzugeben, die entweder friday oder monday im Titel haben:

GoogleSQL 

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'friday OR monday')

PostgreSQL

In diesem Beispiel wird spanner.search verwendet.

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'friday OR monday')

Suchanfrage

Für Suchanfragen wird standardmäßig die Rohsuch anfragen Syntax verwendet. Alternative Syntaxen können mit dem SEARCH dialect Argument angegeben werden.

Dialekt „rquery“

Der Standarddialekt ist die Rohsuchanfrage. Spanner verwendet eine domänenspezifische Sprache (Domain-Specific Language, DSL) namens rquery.

Die rquery-Sprache folgt denselben Regeln wie der Plain-Text-Tokenizer , wenn die Eingabe-Suchanfrage in einzelne Begriffe aufgeteilt wird. Dazu gehört auch die Segmentierung asiatischer Sprachen.

Informationen zur Verwendung von rquery finden Sie unter rquery-Syntax.

Dialekt „words“

Der Dialekt „words“ ist wie rquery, aber einfacher. Er verwendet keine speziellen Operatoren. Beispielsweise wird OR als Suchbegriff und nicht als Disjunktionsoperator behandelt. Die doppelten Anführungszeichen werden als Satzzeichen und nicht als Suchbegriff für eine Wortgruppe behandelt und ignoriert.

Beim Dialekt „words“ wird AND implizit auf alle Begriffe angewendet und ist für die Übereinstimmung erforderlich. Er folgt denselben Regeln wie der Plain-Text-Tokenizer, wenn die Eingabe-Suchanfrage in Begriffe aufgeteilt wird.

Informationen zur Verwendung des Dialekts „words“ finden Sie unter Syntax für „words“ .

Dialekt „words_phrase“

Der Dialekt „words_phrase“ verwendet keine speziellen Operatoren und alle Begriffe werden als Wortgruppe behandelt. Das bedeutet, dass die Begriffe nebeneinander und in der angegebenen Reihenfolge stehen müssen.

Wie bei rquery folgt der Dialekt „words_phrase“ denselben Regeln wie der Plain-Text-Tokenizer, wenn die Eingabe-Suchanfrage in Begriffe aufgeteilt wird.

Informationen zur Verwendung des Dialekts „words_phrase“ finden Sie unter Syntax für „words_phrase“.

Suchanfragen erweitern, um mehr relevante Ergebnisse zu erhalten

Mit den erweiterten Funktionen von Spanner können Sie die Wahrscheinlichkeit erhöhen, relevante Ergebnisse zu finden, indem Sie Suchanfragen mit verwandten Begriffen, Synonymen und Rechtschreibkorrekturen erweitern. Zu diesen Funktionen gehören:

Weitere Informationen finden Sie unter Suche mit Abfrageerweiterung.

Anforderungen an SQL-Abfrage

Es gibt mehrere Bedingungen, die eine SQL-Abfrage erfüllen muss, um einen Suchindex zu verwenden. Wenn diese Bedingungen nicht erfüllt sind, verwendet die Abfrage entweder einen alternativen Abfrageplan oder schlägt fehl, wenn kein alternativer Plan vorhanden ist.

Abfragen müssen die folgenden Bedingungen erfüllen:

  • Für die Funktionen SEARCH und SEARCH_SUBSTRING ist ein Suchindex erforderlich. Spanner unterstützt diese Funktionen nicht in Abfragen für die Basistabelle oder sekundäre Indexe.

  • Partitionierte Indexe müssen alle Partitionierungsspalten durch eine Gleichheitsbedingung in der WHERE Klausel der Abfrage gebunden sein.

    Wenn ein Suchindex beispielsweise als PARTITION BY x, y definiert ist, muss die Abfrage eine Konjunktion in der WHERE Klausel von x = <parameter or constant> AND y = <parameter or constant> haben. Dieser Suchindex wird vom Abfrageoptimierungstool nicht berücksichtigt, wenn eine solche Bedingung fehlt.

  • Alle TOKENLIST-Spalten, auf die von den Operatoren SEARCH und SEARCH_SUBSTRING verwiesen wird, müssen im selben Suchindex indexiert sein.

    Betrachten Sie beispielsweise die folgende Tabelle und Indexdefinition:

    GoogleSQL 

    CREATE TABLE Albums (
    AlbumId STRING(MAX) NOT NULL,
    AlbumTitle STRING(MAX),
    AlbumStudio STRING(MAX),
    AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
    AlbumStudio_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumStudio)) HIDDEN
) PRIMARY KEY(AlbumId);

CREATE SEARCH INDEX AlbumsTitleIndex ON Albums(AlbumTitle_Tokens);
CREATE SEARCH INDEX AlbumsStudioIndex ON Albums(AlbumStudio_Tokens);

    PostgreSQL 

    CREATE TABLE albums (
    albumid character varying NOT NULL,
    albumtitle character varying,
    albumstudio character varying,
    albumtitle_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN,
    albumstudio_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumstudio)) VIRTUAL HIDDEN,
PRIMARY KEY(albumid));

CREATE SEARCH INDEX albumstitleindex ON albums(albumtitle_tokens);
CREATE SEARCH INDEX albumsstudioindex ON albums(albumstudio_tokens);

    Die folgende Abfrage schlägt fehl, da es keinen einzelnen Suchindex gibt, der sowohl AlbumTitle_Tokens als auch AlbumStudio_Tokens indexiert:

    GoogleSQL 

    SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, @p1)
    AND SEARCH(AlbumStudio_Tokens, @p2)

    PostgreSQL

    In diesem Beispiel werden die Abfrageparameter $1 und $2 verwendet, die an „fast car“ bzw. „blue note“ gebunden sind.

    SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, $1)
    AND spanner.search(albumstudio_tokens, $2)

  • Wenn die Spalte für die Sortierreihenfolge NULL-Werte zulässt, müssen sowohl das Schema als auch die Abfrage Zeilen ausschließen, in denen die Spalte für die Sortierreihenfolge NULL ist. Weitere Informationen finden Sie unter Sortierreihenfolge für Suchindexe.

  • Wenn der Suchindex NULL-gefiltert ist, muss die Abfrage denselben NULL-Filterausdruck enthalten, der in einem Index verwendet wird. Weitere Informationen finden Sie unter NULL-gefilterte Such indexe.

  • Suchindexe und Suchfunktionen werden in DML-, partitionierten DML- oder partitionierten Abfragen nicht unterstützt.

  • Suchindexe und Suchfunktionen werden in der Regel in schreibgeschützten Transaktionen verwendet. Wenn die Anwendungsanforderungen veraltete Ergebnisse zulassen, können Sie die Latenz möglicherweise verbessern, indem Sie Suchanfragen mit einer Veraltungsdauer von mindestens 10 Sekunden ausführen. Weitere Informationen finden Sie unter Veraltete Daten lesen. Dies ist besonders nützlich für Suchanfragen, die auf viele Indexaufteilungen verteilt werden.

Suchindexe und Suchfunktionen werden in Lese-/Schreibtransaktionen nicht empfohlen. Während der Ausführung sperren Suchanfragen eine gesamte Indexpartition. Daher kann eine hohe Anzahl von Suchanfragen in Lese-/Schreibtransaktionen zu Sperrkonflikten führen, die Latenzspitzen verursachen. Standardmäßig werden Suchindexe in Lese-/Schreibtransaktionen nicht automatisch ausgewählt. Wenn eine Abfrage gezwungen wird, einen Suchindex in einer Lese-/Schreibtransaktion zu verwenden, schlägt sie standardmäßig fehl. Sie schlägt auch fehl, wenn die Abfrage eine der Suchfunktionen enthält. Dieses Verhalten kann mit dem GoogleSQL-Hinweis auf Anweisungsebene @{ALLOW_SEARCH_INDEXES_IN_TRANSACTION=TRUE} überschrieben werden. Abfragen sind jedoch weiterhin anfällig für Sperrkonflikte.

Sobald die Bedingungen für die Indexberechtigung erfüllt sind, versucht das Abfrageoptimierungstool, Nicht-Text-Abfragebedingungen zu beschleunigen (z. B. Rating > 4). Wenn der Suchindex die entsprechende TOKENLIST-Spalte nicht enthält, wird die Bedingung nicht beschleunigt und bleibt eine Restbedingung.

Suchparameter

Suchanfrageargumente werden entweder als Literal oder als Abfrage parameter angegeben. Wir empfehlen, für die Volltextsuche Suchparameter anstelle von Stringliteralen zu verwenden, wenn Argumente Parameterwerte zulassen.

Indexauswahl

Spanner wählt in der Regel den effizientesten Index für eine Abfrage mithilfe der kostenbasierten Modellierung aus. Der Hinweis FORCE_INDEX weist Spanner jedoch explizit an, einen bestimmten Suchindex zu verwenden. Im folgenden Beispiel wird gezeigt, wie Sie Spanner zwingen, AlbumsIndex zu verwenden:

GoogleSQL 

SELECT AlbumId
FROM Albums @{FORCE_INDEX=AlbumsIndex}
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

PostgreSQL 

SELECT albumid
FROM albums/*@force_index=albumsindex*/
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')

Wenn der angegebene Suchindex nicht geeignet ist, schlägt die Abfrage fehl, auch wenn andere geeignete Suchindexe vorhanden sind.

Snippets in Suchergebnissen

Ein Snippet ist ein Textausschnitt, der aus einem bestimmten String extrahiert wird und Nutzern eine Vorstellung davon vermittelt, was ein Suchergebnis enthält und warum das Ergebnis für ihre Suchanfrage relevant ist.

In Gmail werden beispielsweise Snippets verwendet, um den Teil einer E-Mail anzugeben, der mit der Suchanfrage übereinstimmt:

Liste der Snippets

Es hat mehrere Vorteile, wenn die Datenbank ein Snippet generiert:

  1. Komfort: Sie müssen keine Logik implementieren, um Snippets aus einer Suchanfrage zu generieren.
  2. Effizienz: Snippets reduzieren die Ausgabegröße vom Server.

Die SNIPPET Funktion erstellt das Snippet. Sie gibt den relevanten Teil des ursprünglichen Stringwerts zusammen mit den Positionen der hervorzuhebenden Zeichen zurück. Der Client kann dann auswählen, wie das Snippet dem Endnutzer angezeigt werden soll (z. B. mit hervorgehobenem Text oder Fettdruck).

Im folgenden Beispiel wird SNIPPET verwendet, um Text aus AlbumTitle abzurufen:

GoogleSQL 

SELECT AlbumId, SNIPPET(AlbumTitle, "Fast Car")
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "Fast Car")

PostgreSQL

In diesem Beispiel wird spanner.snippet verwendet.

SELECT albumid, spanner.snippet(albumtitle, 'Fast Car')
FROM albums
WHERE spanner.search(albumtitle_tokens, 'Fast Car')

Nächste Schritte