Diese Seite wurde von der Cloud Translation API übersetzt.

Abfrageübersicht

Auf dieser Seite werden die Funktion SEARCH und der erweiterte Abfragemodus beschrieben, mit denen Volltextabfragen in Spanner-Tabellen ausgeführt werden.

Suchindex abfragen

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

Für die Funktion SEARCH sind zwei Argumente erforderlich:

Einen Suchindexnamen
Eine unformatierte Suchanfrage

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

Die Funktion SEARCH kann nicht mit Transaktionsabfragen verwendet werden.

In der folgenden Abfrage wird die Funktion SEARCH verwendet, um alle Alben zurückzugeben, deren Titel entweder friday oder monday enthält:

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

Unbearbeitete Suchanfragen und die Sprache „rquery“

Das zweite Argument der Funktion SEARCH ist eine unbearbeitete Suchanfrage. Spanner verwendet eine domainspezifische Sprache (DSL) namens rquery.

Die RQuery-Sprache folgt denselben Regeln wie der Plain-Text-Tokenisierer, wenn der Eingabestring in einzelne Begriffe unterteilt wird. Dazu gehört auch die Segmentierung asiatischer Sprachen.

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

Erweiterter Abfragemodus

Spanner bietet zwei Volltextsuchmodi: eine einfache tokenbasierte und dem erweiterten Modus enhance_query. Wenn diese Option aktiviert ist, wird die Suchanfrage um ähnliche Begriffe und Synonyme erweitert. So steigt die Wahrscheinlichkeit, relevante Ergebnisse zu finden.

Wenn Sie diese Option aktivieren möchten, legen Sie das optionale Argument enhance_query=>true in der Funktion SEARCH fest. Die Suchanfrage hotl cal stimmt beispielsweise mit dem Album Hotel California überein.

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'hotl cal', enhance_query=>true)

Der Modus enhance_query ist eine Option zur Abfragezeit. Dies wirkt sich nicht auf die Tokenisierung aus. Sie können denselben Suchindex mit oder ohne enhance_query verwenden.

Google verbessert kontinuierlich die Algorithmen zur Suchanfragenverbesserung. Daher können Abfragen mit enhance_query == true im Laufe der Zeit leicht unterschiedliche Ergebnisse liefern.

Wenn der Modus enhance_query aktiviert ist, kann sich die Anzahl der Begriffe erhöhen, nach denen die Funktion SEARCH sucht, was die Latenz geringfügig erhöhen könnte.

Die folgende Abfrage verwendet beispielsweise ein Zeitlimit von drei Sekunden und schlägt fehl, wenn enhance_query ist nicht verfügbar:

@{require_enhance_query=true, enhance_query_timeout_ms=3000}
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'fast car', enhance_query=>true)

Weitere Informationen zur Verwendung der Option enhance_query finden Sie unter SUCHE-Funktion.

Anforderungen an SQL-Abfragen

Damit ein Suchindex verwendet werden kann, müssen mehrere Bedingungen für eine SQL-Abfrage erfüllt sein. Wenn diese Bedingungen nicht erfüllt sind, wird für die Abfrage entweder ein alternativer Abfrageplan verwendet oder sie schlägt fehl, wenn kein alternativer Plan vorhanden ist.

Abfragen müssen die folgenden Bedingungen erfüllen:

Für SEARCH- und SEARCH_SUBSTRING-Funktionen ist ein Suchindex erforderlich. Spanner unterstützt diese Funktionen nicht in Abfragen an die Basistabelle oder sekundäre Indexe.
Bei partitionierten Indexen müssen alle Partitionsspalten in der WHERE-Klausel der Abfrage durch eine Gleichheitsbedingung gebunden sein.

Wenn beispielsweise ein Suchindex als PARTITION BY x, y definiert ist, Abfrage muss in der WHERE-Klausel von x = <parameter or constant> AND y = <parameter or constant> einen Konjunkt enthalten. Dieser Suchindex wird von der Abfrageoptimierung nicht berücksichtigt, wenn eine solche Bedingung fehlt.

Alle TOKENLIST-Spalten, auf die über SEARCH- und SEARCH_SUBSTRING-Operatoren verwiesen wird, müssen im selben Suchindex indexiert werden.

Betrachten Sie beispielsweise die folgende Tabelle und Indexdefinition:

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);

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

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

Wenn die Sortierreihenfolgenspalte nullable ist, müssen sowohl das Schema als auch die Abfrage Zeilen ausschließen, in denen die Sortierreihenfolgenspalte NULL ist. Weitere Informationen finden Sie unter Sortierreihenfolge des Suchindexes.
Wenn der Suchindex NULL-gefiltert ist, muss die Abfrage denselben Wert NULL-Filterausdruck, der in einem Index verwendet wird. Weitere Informationen finden Sie unter Mit Null gefilterte Suche Indexe .
Suchindexe und Suchfunktionen werden in DML, partitionierter DML oder partitionierten Abfragen nicht unterstützt.
Suchindizes und Suchfunktionen werden in der Regel in schreibgeschützten Transaktionen verwendet. Wenn die Anwendungsanforderungen veraltete Ergebnisse zulassen, empfehlen wir, eine Suche auszuführen. Abfragen mit einer Veralterungsdauer von 10 Sekunden oder mehr Weitere Informationen finden Sie unter Veraltete Daten lesen Dies ist besonders nützlich für große Suchanfragen, die sich auf mehrere Paxos-Gruppen verteilen.

Indexe suchen und Suchfunktionen nicht empfohlen in Lese-Schreib-Transaktionen. Während der Ausführung sperren Suchanfragen eine ganze Indexpartition. Daher kann eine hohe Rate von Suchanfragen in Lese-/Schreibtransaktionen zu Sperrkonflikten führen, die zu Latenzspitzen führen. Standardmäßig werden Suchindexe nicht automatisch in Lese-/Schreibtransaktionen ausgewählt. Wenn für eine Abfrage in einer Lese-Schreib-Transaktion ein Suchindex erzwungen wird, schlägt sie standardmäßig fehl. Außerdem schlägt die Abfrage fehl, wenn sie eine der Suchfunktionen enthält. Dieses Verhalten kann mit @{ALLOW_SEARCH_INDEXES_IN_TRANSACTION=TRUE} überschrieben werden Hinweis auf Anweisungsebene (aber Abfragen sind weiterhin anfällig für Sperrkonflikte).

Sobald die Indexvoraussetzungen erfüllt sind, versucht der Abfrageoptimierer, Abfragebedingungen ohne Text (z. B. Rating > 4) zu beschleunigen. Wenn der Suchindex die entsprechende TOKENLIST-Spalte nicht enthält, wird die Bedingung nicht beschleunigt und bleibt eine Restbedingung.

Abfrageparameter

rquery und andere Parameter wie OFFSET werden entweder als Literal- oder Einen Abfrageparameter Wir empfehlen, für die Volltextsuche Abfrageparameter anstelle von Stringliteralen zu verwenden.

Indexauswahl

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

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

Wenn der angegebene Suchindex nicht infrage kommt, schlägt die Abfrage fehl, auch wenn andere infrage kommende Suchindexe vorhanden sind.

Snippets in Suchergebnissen

Ein Snippet ist ein aus einer bestimmten Zeichenfolge extrahierter Text, der Nutzern einen den Inhalt eines Suchergebnisses und den Grund dafür, die für die Suchanfrage relevant sind.

In Gmail werden z. B. Snippets verwendet, um den Teil einer E-Mail zu kennzeichnen, entspricht der Suchanfrage:

Liste der Snippets

Das Generieren eines Snippets durch die Datenbank bietet mehrere Vorteile:

Praktisch: Zum Generieren von Snippets ist keine Logik erforderlich. aus einer Suchanfrage.
Effizienz: Durch Snippets wird die Ausgabegröße des Servers reduziert.

Das Snippet wird mit der Funktion SNIPPET erstellt. Sie gibt den relevanten Teil des ursprünglichen Stringwerts zusammen mit den Positionen der zu markierenden Zeichen zurück. Der Kunde kann dann auswählen, wie das Snippet für den Endnutzer angezeigt werden soll, z. B. mit hervorgehobenem oder fett formatiertem Text. Mit der Funktion SNIPPET werden alle HTML-Tags aus dem ursprünglichen String entfernt.

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

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