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 SEARCH -Funktion, die für Suchindexabfragen verwendet werden soll. 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“ verwendet dann einen Suchindex, um diesen Text zu finden.

Für die Funktion SEARCH sind zwei Argumente erforderlich:

Name eines Suchindexes
Eine unformatierte Suchanfrage

Die Funktion SEARCH funktioniert nur, wenn ein Suchindex definiert ist. Das SEARCH kann mit beliebigen SQL-Konstrukten, wie 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 die domainspezifische Sprache (DSL) namens rquery.

Für die Sprache rquery gelten dieselben Regeln wie für die Nur-Text-Tokenizer wenn Sie den Eingabestring in verschiedene Terme aufteilen. 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 grundlegende tokenbasierte Suche und einen erweiterten Modus namens enhance_query. Wenn diese Option aktiviert ist, wird die Suchanfrage um ähnliche Begriffe und Synonyme erweitert. So steigt die Wahrscheinlichkeit, relevante Ergebnisse zu finden.

Um diese Option zu aktivieren, legen Sie das optionale Argument enhance_query=>true im SEARCH. Beispielsweise stimmt die Suchanfrage hotl cal mit dem Album überein. Hotel California.

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 die Algorithmen für die Suchanfrage-Optimierung kontinuierlich. Daher können Abfragen mit enhance_query == true im Laufe der Zeit leicht unterschiedliche Ergebnisse liefern.

Wenn der enhance_query-Modus aktiviert ist, erhöht sich möglicherweise die Anzahl der Begriffe, nach denen die SEARCH-Funktion sucht. Dies kann die Latenz leicht erhöhen.

In der folgenden Abfrage wird beispielsweise eine Zeitüberschreitung von drei Sekunden verwendet und sie schlägt fehl, wenn enhance_query nicht verfügbar ist:

@{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 in der SUCHfunktion:

Anforderungen an SQL-Abfragen

Eine SQL-Abfrage muss mehrere Bedingungen erfüllen, um einen Suchindex verwenden zu können. 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 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 in SEARCH und SEARCH_SUBSTRING verwiesen wird müssen im selben Suchindex indexiert werden.

Betrachten Sie beispielsweise die folgende Tabellen- 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 für die Spalte für die Sortierreihenfolge Nullwerte zulässig sind, müssen sowohl das Schema als auch die Abfrage Zeilen ausschließen, bei denen die Spalte für die Sortierreihenfolge NULL ist. Weitere Informationen finden Sie unter Sortierreihenfolge des Suchindexes.
Wenn der Suchindex NULL-gefiltert ist, muss die Abfrage denselben NULL-Filterausdruck enthalten, 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 bei großen Suchanfragen, die auf mehrere Paxos ausfächern Gruppen.

Suchindexe und Suchfunktionen werden in Lese-/Schreibtransaktionen nicht empfohlen. Während der Ausführung sperren Suchabfragen eine gesamte Indexpartition. als führt, kann eine hohe Anzahl von Suchanfragen in Lese-Schreib-Transaktionen dazu führen, Sperrkonflikte, 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. Damit schlägt auch fehl, wenn die Abfrage 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 Bedingungen für die Indexeignung erfüllt sind, versucht die Abfrageoptimierung, Nicht-Text-Abfragebedingungen beschleunigen (z. B. Rating > 4). Wenn der Suchindex nicht die entsprechende TOKENLIST-Spalte enthält, ist die Bedingung nicht beschleunigt und ist weiterhin Restzustand.

Abfrageparameter

„rquery“ und andere Parameter wie OFFSET werden entweder als Literal oder als Abfrageparameter angegeben. Wir empfehlen, für die Volltextsuche Suchparameter anstelle von Strings zu verwenden. Literalen.

Indexauswahl

Spanner wählt in der Regel den effizientesten Index für eine Abfrage aus kostenbasierte Modellierung. 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 zulässig ist, schlägt die Abfrage fehl, selbst wenn es andere zulässige Suchindexe gibt.

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 beispielsweise Snippets verwendet, um den Teil einer E-Mail anzugeben, der mit der Suchanfrage übereinstimmt:

Liste der Snippets

Das Generieren eines Snippets durch die Datenbank hat mehrere Vorteile:

Praktisch: Zum Generieren von Snippets ist keine Logik erforderlich. aus einer Suchanfrage.
Effizienz: Mit Snippets wird die Ausgabegröße vom Server 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. Die kann der Kunde festlegen, wie das Snippet für den Endnutzer angezeigt werden soll (z. B. durch hervorgehobenen oder fett formatierten Text). Mit der Funktion SNIPPET werden alle HTML-Tags aus dem ursprünglichen String entfernt.

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

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