Extension des requêtes de recherche

Cette page explique comment utiliser l'amélioration des requêtes dans le cadre d'une recherche en texte intégral.

Pour augmenter les chances de trouver des résultats pertinents, Spanner propose des fonctionnalités avancées qui élargissent la requête de recherche pour inclure des termes associés, des synonymes et des corrections orthographiques. Spanner propose les options suivantes pour améliorer les requêtes :

Requête améliorée

Pour utiliser la requête améliorée, définissez enhance_query=>true dans la fonction SEARCH. Spanner développe ensuite automatiquement les requêtes de recherche en incluant des termes associés et des synonymes, en appliquant la racinisation et en corrigeant l'orthographe. Par exemple, lorsque vous utilisez une requête améliorée, la requête de recherche hotl cal correspond à l'album Hotel California.

GoogleSQL 

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

PostgreSQL 

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'hotl cal', enhance_query=>true)

enhance_query est une option au moment de l'exécution de la requête qui n'affecte pas la tokenisation. Vous pouvez utiliser le même index de recherche avec ou sans enhance_query.

Google améliore constamment les algorithmes d'amélioration des requêtes. Par conséquent, une requête avec enhance_query => true peut générer des résultats légèrement différents au fil du temps.

Lorsque enhance_query est utilisé, la latence peut augmenter en raison de la surcharge liée à l'expansion de la requête de recherche et à l'exécution de la requête plus volumineuse qui en résulte.

Dictionnaires personnalisés

Vous pouvez utiliser des dictionnaires personnalisés avec la recherche en texte intégral Spanner pour définir des synonymes pour les termes de votre ensemble de données. Cela permet de capturer les synonymes, les acronymes, les termes équivalents et d'autres variantes de mots pour améliorer la récupération des résultats de recherche.

Créer une table de dictionnaire personnalisée

Un dictionnaire personnalisé est un tableau créé par l'utilisateur, contenant des paires clé-valeur de termes et de leurs synonymes. Pour en créer un, incluez l'option fulltext_dictionary_table = true dans l'instruction CREATE TABLE. La table doit comporter deux colonnes :

  • Key : colonne de chaîne non nullable pour le terme à développer avec des synonymes.
  • Value : colonne de tableau de chaînes non nullables pour un tableau de synonymes de la clé.

Le tableau ne peut contenir que les colonnes Key et Value. Si un terme de recherche correspond à un Key dans le dictionnaire, la recherche est élargie pour inclure tous les synonymes correspondants dans Value, ainsi que le terme clé lui-même. L'exemple suivant crée une table de dictionnaire personnalisé nommée MyCustomDictionary. Vous devez également définir l'option de table fulltext_dictionary_table=true sur cette table lors de sa création.

GoogleSQL 

CREATE TABLE MyCustomDictionary (
  Key STRING(MAX) NOT NULL,
  Value ARRAY<STRING(MAX)> NOT NULL,
) PRIMARY KEY(Key),
OPTIONS (fulltext_dictionary_table = true);

PostgreSQL 

CREATE TABLE mycustomdictionary (
  key character varying  NOT NULL,
  value character varying [] NOT NULL,
  PRIMARY KEY(key)
)  WITH ( type = 'fulltext_dictionary')

Après avoir créé la table, insérez vos synonymes :

GoogleSQL 

INSERT INTO MyCustomDictionary (Key, Value) VALUES
('album', ['vinyl', 'cassette']),
('edm', ['electronic dance music']);

PostgreSQL 

INSERT INTO mycustomdictionary (key, value) VALUES
('album', ARRAY['vinyl', 'cassette']),
('edm', ARRAY['electronic dance music']);

Lorsque vous remplissez le tableau, tenez compte des points suivants :

  • Les clés doivent être des mots uniques.
  • Les valeurs peuvent être des mots uniques ou des expressions composées de plusieurs mots. Si une valeur contient plusieurs mots, elle est traitée comme une recherche d'expression lors de l'extension des requêtes.
  • Toutes les clés et valeurs doivent être en minuscules. Cela permet de s'assurer qu'ils correspondent aux jetons de recherche, qui sont convertis en minuscules par le tokenizer par défaut.

L'expansion de la recherche ne se produit que lorsqu'un terme de recherche correspond à un Key. Si un terme de recherche correspond à un synonyme dans Value, mais pas à un Key, la recherche n'est pas élargie. Si vous avez besoin d'un mappage bidirectionnel (par exemple, pour que la recherche de vinyl ou cassette trouve également album), vous devez également insérer des mappages inversés dans la table du dictionnaire. L'exemple suivant montre comment insérer des mappages bidirectionnels pour album, vinyl et cassette :

GoogleSQL 

INSERT INTO MyCustomDictionary (Key, Value)
-- 1. Insert album -> vinyl, cassette
SELECT 'album', ['vinyl', 'cassette']
UNION ALL
-- 2. Insert vinyl -> album and cassette -> album
SELECT syn, ['album']
FROM UNNEST(['vinyl', 'cassette']) AS syn;

PostgreSQL 

INSERT INTO mycustomdictionary (key, value)
-- 1. Insert album -> vinyl, cassette
SELECT 'album', ARRAY['vinyl', 'cassette']
UNION ALL
-- 2. Insert vinyl -> album and cassette -> album
SELECT syn, ARRAY['album']
FROM unnest(ARRAY['vinyl', 'cassette']) AS syn;

Utiliser un dictionnaire personnalisé dans les requêtes de recherche

Pour utiliser un dictionnaire personnalisé, spécifiez le nom de la table du dictionnaire dans l'argument dictionary de la fonction SEARCH.

  • Si un terme de recherche est une clé dans le dictionnaire, SEARCH recherche également ses valeurs. Le terme album correspond aux messages contenant vinyl ou cassette.

    GoogleSQL 

    SELECT MessageId, Body
FROM Messages
WHERE SEARCH(Body_Tokens, 'album', dictionary=>'MyCustomDictionary');

    PostgreSQL 

    SELECT messageid, body
FROM messages
WHERE spanner.search(body_tokens, 'album', dictionary=>'mycustomdictionary');

  • Lorsqu'une valeur de dictionnaire contient plusieurs mots, comme electronic dance music pour la clé edm, elle est traitée comme une recherche d'expression. Cela signifie que les termes doivent apparaître de manière adjacente et dans l'ordre exact spécifié pour être considérés comme une correspondance. Par exemple, la requête suivante renvoie les résultats contenant l'expression exacte "musique électronique", mais ne correspond pas à "musique électronique de danse". Cela est principalement utile pour développer les acronymes. Voici comment procéder :

    GoogleSQL 

    SELECT MessageId, Body
FROM Messages
WHERE SEARCH(Body_Tokens, 'edm', dictionary=>'MyCustomDictionary');

    PostgreSQL 

    SELECT messageid, body
FROM messages
WHERE spanner.search(body_tokens, 'edm', dictionary=>'mycustomdictionary');

Obsolescence de la recherche dans le dictionnaire

Par défaut, les entrées du dictionnaire personnalisé sont lues avec une obsolescence maximale de 15 secondes. Cela réduit la surcharge de l'opération de lecture, car la lecture de données légèrement obsolètes est plus efficace que la lecture des données les plus récentes. Par conséquent, les modifications apportées aux entrées du dictionnaire peuvent mettre jusqu'à 15 secondes à s'afficher dans les requêtes de recherche. Vous pouvez ignorer ce comportement de différentes manières :

  • Utiliser l'option de tableau fulltext_dictionary_staleness
  • Utiliser l'indication de requête fulltext_dictionary_staleness pour un contrôle plus précis.

L'indication de requête remplace l'option de table si les deux sont utilisées.

Option de tableau fulltext_dictionary_staleness

Vous pouvez définir l'option fulltext_dictionary_staleness pour la table de dictionnaire. Toutes les requêtes utilisant cette table de dictionnaire utilisent cette valeur d'obsolescence, sauf si elle est remplacée par l'indication de requête.

GoogleSQL

L'exemple suivant montre comment CREATE une table avec l'option fulltext_dictionary_staleness :

CREATE TABLE MyCustomDictionary (
  Key STRING(MAX) NOT NULL,
  Value ARRAY<STRING(MAX)> NOT NULL,
) PRIMARY KEY(Key),
OPTIONS (
  fulltext_dictionary_table = true,
  fulltext_dictionary_staleness = '5s'
);

L'exemple suivant montre comment ALTER le tableau pour modifier ou définir l'option fulltext_dictionary_staleness :

ALTER TABLE MyCustomDictionary SET OPTIONS (
  fulltext_dictionary_staleness = '60s'
);

PostgreSQL

L'exemple suivant montre comment CREATE une table avec l'option fulltext_dictionary_staleness :

-- Create with 5s staleness
CREATE TABLE mycustomdictionary (
  key character varying NOT NULL,
  value character varying[]  NOT NULL,
  PRIMARY KEY(key)
) WITH (
  type = 'fulltext_dictionary',
  fulltext_dictionary_staleness = '5s'
);

L'interface PostgreSQL n'est pas compatible avec la table ALTER pour modifier ou définir l'option fulltext_dictionary_staleness.

fulltext_dictionary_staleness suggestion de requête

Pour un contrôle plus précis, vous pouvez utiliser l'indication de requête fulltext_dictionary_staleness afin de spécifier une fraîcheur différente pour une requête individuelle. Cet indice remplace le paramètre au niveau de la table.

L'exemple suivant utilise un indice pour effectuer des recherches dans la table de dictionnaire avec une obsolescence nulle. Cela garantit que les entrées de dictionnaire les plus récentes sont lues. Cette approche peut augmenter la latence des requêtes, car la lecture des données les plus récentes est moins efficace que l'acceptation d'une certaine obsolescence.

GoogleSQL 

@{fulltext_dictionary_staleness="0s"}
SELECT MessageId, Body
FROM Messages
WHERE SEARCH(Body_Tokens, 'Bill', dictionary=>'MyCustomDictionary');

PostgreSQL 

/*@ fulltext_dictionary_staleness='0s' */
SELECT messageid, body
FROM messages
WHERE spanner.search(body_tokens, 'Bill', dictionary=>'mycustomdictionary');

Limites connues des tables de dictionnaire personnalisées

  • L'utilisation de l'importation et de l'exportation Spanner avec des tables de dictionnaire personnalisées est limitée.
  • Les tables de dictionnaire personnalisées doivent être créées dans le schéma par défaut et ne peuvent pas l'être dans des schémas nommés.
  • Les tables de dictionnaire personnalisées ne sont compatibles qu'avec le dialecte de requête SEARCH par défaut.

Combiner des dictionnaires personnalisés avec une requête améliorée

Vous pouvez combiner les synonymes du dictionnaire personnalisé avec enhanced query en définissant dictionary et enhance_query=>true dans la fonction SEARCH. L'amélioration des requêtes peut élargir les requêtes avec des synonymes courants ou des corrections orthographiques, tandis que les dictionnaires personnalisés vous permettent de définir vos propres expansions. Par exemple, si enhance_query développe album pour inclure record et que MyCustomDictionary mappe album à ['vinyl', 'cassette'], la requête suivante correspond aux messages contenant album, record, vinyl ou cassette :

GoogleSQL 

SELECT MessageId, Body
FROM Messages
WHERE SEARCH(Body_Tokens, 'album', enhance_query=>true, dictionary=>'MyCustomDictionary');

PostgreSQL 

SELECT messageid, body
FROM messages
WHERE spanner.search(body_tokens, 'album', enhance_query=>true, dictionary=>'mycustomdictionary');

Lorsque les deux améliorations sont activées, elles fonctionnent indépendamment sur les termes de recherche d'origine. Les termes générés par l'une d'elles ne sont pas utilisés comme entrée pour l'autre.

Étapes suivantes