In questa pagina viene descritto come utilizzare una ricerca parziale nell'ambito di una ricerca a testo intero.
Oltre a eseguire ricerche di token esatte utilizzando
SEARCH
e
SEARCH_SUBSTRING
funzioni, Spanner supporta anche le app approssimative (o
fuzzy). Le ricerche fuzzy trovano documenti corrispondenti nonostante piccole differenze tra la query e il documento.
Spanner supporta i seguenti tipi di ricerca parziale:
- Ricerca approssimativa basata su n-grammi
- Ricerca fonetica utilizzando Soundex
Utilizza una ricerca approssimativa basata su n-grammi
La ricerca fuzzy basata su n grammi si basa sullo stesso la tokenizzazione di una sottostringa ricerca di sottostringhe richiede. La configurazione del tokenizzatore è importante in quanto influisce la qualità e le prestazioni delle ricerche. L'esempio seguente mostra come creare un query con errori ortografici o parole con ortografia diversa per trovare corrispondenze approssimative nell'indice di ricerca.
Schema
CREATE TABLE Albums (
AlbumId STRING(MAX) NOT NULL,
AlbumTitle STRING(MAX),
AlbumTitle_Tokens TOKENLIST AS (
TOKENIZE_SUBSTRING(AlbumTitle, ngram_size_min=>2, ngram_size_max=>3,
relative_search_types=>["word_prefix", "word_suffix"])) HIDDEN
) PRIMARY KEY(AlbumId);
CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
STORING (AlbumTitle);
Query
La seguente query trova gli album con i titoli più vicini a "L'odio Kaliphorn", ad esempio "Hotel California".
SELECT AlbumId
FROM Albums
WHERE SEARCH_NGRAMS(AlbumTitle_Tokens, "Hatel Kaliphorn")
ORDER BY SCORE_NGRAMS(AlbumTitle_Tokens, "Hatel Kaliphorn") DESC
LIMIT 10
Ottimizza il rendimento e il richiamo per una ricerca approssimativa basata su n-grammi
La query di esempio nella sezione precedente esegue ricerche in due fasi, utilizzando due funzioni diverse:
SEARCH_NGRAMS
trova tutti gli album candidati che hanno condiviso n-grammi con la query di ricerca. Ad esempio, n-grammi di tre caratteri per "California" includi[cal, ali, lif, ifo, for, orn, rni, nia]
e per "Kaliphorn" includi[kal, ali, lip, iph, pho, hor, orn]
. Gli n-grammi condivisi in questi set di dati sono[ali, orn]
. Per impostazione predefinita,SEARCH_NGRAMS
corrisponde a tutti documenti con almeno due n-grammi condivisi, pertanto "Kaliphorn" corrisponde a "California".SCORE_NGRAMS
classifica le corrispondenze in base alla somiglianza. La somiglianza tra due stringhe viene definita come rapporto tra n-grammi condivisi distinti e n-grammi distinti non condivisi:
Spanner ha tre argomenti di configurazione che possono essere utilizzati con
SEARCH_NGRAMS
:
- Le dimensioni minime e massime degli n-gram specificati in
TOKENIZE_SUBSTRING
oTOKENIZE_NGRAMS
. Sconsigliamo di usare un solo n-grammi di carattere perché corrispondono a un intervallo numero di documenti. D'altra parte, gli n-grammi lunghi causanoSEARCH_NGRAMS
a mancare le parole brevi con errori di ortografia. - Numero minimo di n-grammi che
SEARCH_NGRAMS
deve corrispondere (impostato con gli argomentimin_ngrams
emin_ngrams_percent
inSEARCH_NGRAMS
). Numeri più alti in genere rendono la query più veloce, ma riducono richiamo.
Per ottenere un buon equilibrio tra prestazioni e richiamo, questi argomenti possono essere configurati in base alla query e al carico di lavoro specifici.
Ti consigliamo inoltre di includere un LIMIT
interno per evitare di creare query molto costose quando viene rilevata una combinazione di n-gram popolari:
SELECT AlbumId
FROM (
SELECT AlbumId,
SCORE_NGRAMS(AlbumTitle_Tokens, @p) AS score
FROM Albums
WHERE SEARCH_NGRAMS(AlbumTitle_Tokens, @p)
LIMIT 10000 # inner limit
)
ORDER BY score DESC
LIMIT 10 # outer limit
Ricerca parziale basata su n-grammi e modalità di query avanzata
Oltre alla ricerca fuzzy basata su n-grammi, modalità di query avanzata gestisce anche alcune parole con errori ortografici. Pertanto, esiste una certa sovrapposizione tra i due le funzionalità di machine learning. La seguente tabella riassume le differenze:
ricerca parziale basata su n-grammi | Modalità di query avanzata | |
Costo | Richiede una tokenizzazione di sottostringhe più costosa basata su n-grams | Richiede una tokenizzazione del testo completo meno costosa |
Tipi di query di ricerca | Funziona bene con documenti brevi che contengono poche parole, ad esempio il nome di una persona, di città o di prodotto | Funziona altrettanto bene con documenti di qualsiasi dimensione e con query di ricerca di qualsiasi dimensione. |
Ricerca di parole parziali | Esegue una ricerca di sottostringhe che consente errori ortografici | Supporta solo la ricerca di parole intere (SEARCH_SUBSTRING
non supporta l'argomento enhance_query )
|
Parole con errori ortografici | Supporta parole con errori ortografici nell'indice o nella query | Supporta solo le parole con errori ortografici nella query |
Correzioni | Trova le corrispondenze con errori ortografici, anche se non sono una parola reale | Corregge gli errori ortografici di parole comuni e note |
Eseguire una ricerca fonetica con Soundex
Spanner fornisce la funzione
SOUNDEX
per trovare parole che hanno una grafia diversa, ma che suonano allo stesso modo. Ad esempio, SOUNDEX("steven")
, SOUNDEX("stephen")
eSOUNDEX("stefan")
sono tutti "s315", mentre SOUNDEX("stella")
è "s340". SOUNDEX
è sensibile alle maiuscole e
funziona solo per gli alfabeti latini.
La ricerca fonetica con SOUNDEX
può essere implementata con una colonna generata e un
come mostrato nell'esempio seguente:
CREATE TABLE Singers (
SingerId INT64,
Name STRING(MAX),
Name_Soundex STRING(MAX) AS (LOWER(SOUNDEX(name)))
) PRIMARY KEY(SingerId);
CREATE INDEX SingersPhoneticIndex ON Singers(Name_Soundex);
La seguente query corrisponde a "stefan" a "Steven":
SELECT SingerId
FROM Singers
WHERE Name_Soundex = LOWER(SOUNDEX("stefan"))
Passaggi successivi
- Scopri di più sulla tokenizzazione e sui tokenizzatori di Spanner.
- Scopri di più sugli indici di ricerca.
- Scopri di più sulle query di ricerca full-text.