Aller au contenu principal
Dernière mise à jour le

Index de recherche en texte intégral sur les tables gérées par Unity Catalog

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

Un index de recherche en texte intégral accélère les recherches sur une ou plusieurs colonnes de texte d'une table Delta Lake ou Iceberg gérée. L'index prend en charge la correspondance de sous-chaînes et la correspondance de mots. Lorsque vous interrogez la table avec les fonctions search ou isearch, Databricks utilise l'index pour ignorer les fichiers qui sont garantis de ne pas contenir de lignes correspondantes. Cela réduit considérablement la quantité de données analysées, en particulier pour les recherches sélectives.

important

Les index créés durant la version bêta ne sont pas garantis d'être compatibles avec les versions ultérieures. Lorsque la fonctionnalité atteint l'Aperçu public, vous devez supprimer les index existants et en créer de nouveaux.

Exigences​

Les index de recherche en texte intégral ont des exigences concernant le compute, les autorisations de table de base et de schéma, et la configuration de la table de base.

compute​

Les index de recherche en texte intégral sont disponibles uniquement dans Databricks Runtime 18.2 et versions ultérieures, et vous devez activer cette fonctionnalité Bêta dans les paramètres de votre Workspace. Consultez Gérer les aperçus Databricks.

Autorisations​

Pour créer un index de recherche :

  • Vous devez disposer de l'autorisation MODIFY pour la table référencée dans l'index de recherche.
  • Vous devez disposer de l'autorisation CREATE TABLE sur le schéma parent. Un propriétaire de schéma ou un utilisateur disposant du privilège MANAGE peut vous accorder CREATE TABLE privilèges sur le schéma.

Configuration de la table​

Avant de créer un index de recherche en texte intégral, la table de base doit satisfaire à toutes les conditions suivantes :

  • Vous devez créer l'index dans le même catalogue et le même schéma que la table de base.
  • La table est une table gérée Delta Lake ou une table gérée Iceberg.
  • Le suivi des lignes est activé (delta.enableRowTracking = true). Voir le suivi des lignes dans Databricks.
  • Les colonnes indexées sont de type STRING, VARIANT, STRUCT ou ARRAY. Les colonnes STRING utilisent le classement UTF8_BINARY.
  • Une colonne STRUCT contient au moins un champ feuille STRING, VARIANT ou ARRAY à toute profondeur d'imbrication ; les autres champs feuilles sont ignorés.
  • La table n'utilise aucune des fonctionnalités de la liste de limitations, notamment : OpenSharing, clonage superficiel, contrôles d'accès basés sur les attributs, politiques de sécurité au niveau des lignes et masques de colonne. Consulter Limitations.

Pour plus d'informations sur les exigences du protocole de table, qui s'appliquent aux tables Delta Lake et Iceberg, consultez Compatibilité et protocoles des fonctionnalités de Delta Lake.

Créer un index de recherche en texte intégral​

Vous pouvez créer jusqu'à quatre index sur une seule table, chacun sur une colonne différente.

Utilisez CREATE SEARCH INDEX pour créer un index sur une ou plusieurs colonnes de texte. L'exemple suivant indexe deux colonnes de texte d'une table de logs existante :

SQL
CREATE SEARCH INDEX log_idx
ON logs (message, error_detail);

La syntaxe complète est :

SQL
CREATE SEARCH INDEX [IF NOT EXISTS] index_name
  ON table_name ( column_name [, column_name ...] )
  [OPTIONS ( option_key = option_value [, ... ] )]

index_name doit être unique au sein du schéma et ne peut pas correspondre à un nom de table existant.

Pour contrôler la façon dont le texte est tokenisé, consultez les Options.

attention

Si CREATE SEARCH INDEX et REFRESH INDEX échouent en cours d'exécution, exécutez REFRESH INDEX pour récupérer d'une défaillance partielle.

Options​

La clause OPTIONS accepte les clés suivantes :

Clé

Valeurs

Par défaut

Description

tokenizer

ngram, split

ngram

Comment le texte est tokenisé pour l'indexation. Voir Sélectionner un tokenizer pour votre cas d'utilisation.

ngram_size

Entier dans [3, 10]

5

Longueur des n-grammes produits. Valide uniquement lorsque tokenizer = 'ngram'.

min_token_length

entier >= 1

3

Longueur minimale de jetons à conserver. Les jetons plus courts que cela sont supprimés pendant l'indexation. Valide uniquement lorsque tokenizer = 'split'.

Clé

Valeurs

Par défaut

Description

tokenizer

ngram, split

ngram

Comment le texte est tokenisé pour l'indexation. Voir Sélectionner un tokenizer pour votre cas d'utilisation.

ngram_size

Entier dans [3, 10]

5

Longueur des n-grammes produits. Valide uniquement lorsque tokenizer = 'ngram'.

min_token_length

entier >= 1

3

Longueur minimale de jetons à conserver. Les jetons plus courts que cela sont supprimés pendant l'indexation. Valide uniquement lorsque tokenizer = 'split'.

Pour des informations détaillées sur les erreurs d'option non valides, voir condition d'erreur SEARCH_INDEX_INVALID_PARAMETERS.

Sélectionnez un tokenizer pour votre cas d’utilisation​

Les index de recherche ont 2 options de tokenisation disponibles, selon votre cas d'utilisation :

Tokeniseur

Cas d'usage

Description

ngram

Correspondance de sous-chaîne.

Divise le texte en n-grammes chevauchants de longueur ngram_size.

split

Contrôles d'intégration des mots entiers.

Divise le texte en jetons de mots. Un jeton est une séquence de lettres Unicode (\p{L}) et de signes diacritiques combinants (\p{M}) ; tout autre caractère est un délimiteur.

Tokeniseur

Cas d'usage

Description

ngram

Correspondance de sous-chaîne.

Divise le texte en n-grammes chevauchants de longueur ngram_size.

split

Contrôles d'intégration des mots entiers.

Divise le texte en jetons de mots. Un jeton est une séquence de lettres Unicode (\p{L}) et de signes diacritiques combinants (\p{M}) ; tout autre caractère est un délimiteur.

Pour créer un index de n-grammes avec une taille de n-grammes de 4 :

SQL
CREATE SEARCH INDEX log_ngram_idx
  ON logs (message)
  OPTIONS (tokenizer = 'ngram', ngram_size = 4);

Pour créer un index split avec une longueur de jeton minimale de 2 :

SQL
CREATE SEARCH INDEX log_word_idx
  ON logs (message)
  OPTIONS (tokenizer = 'split', min_token_length = 2);

Interroger les données à l'aide de search et isearch​

Databricks dispose de deux fonctions SQL pour vérifier si un modèle de recherche est présent dans une ou plusieurs cibles de texte :

  • search: sensible à la casse.
  • isearch: non sensible à la casse.

Sélectionnez search ou isearch en fonction de votre exigence de sensibilité à la casse. Lorsque les colonnes indexées sont couvertes par un index de recherche en texte intégral, Databricks utilise l'index pour ignorer les fichiers garantis de ne pas contenir de lignes correspondantes. Les index de recherche n’affectent pas les résultats.

Les index accélèrent le plus les requêtes lorsque le modèle de recherche apparaît dans une petite fraction des fichiers de la table.

SQL
search( target [, target ... ] , 'pattern' [, mode => 'substring' | 'word' ] )
isearch( target [, target ... ] , 'pattern' [, mode => 'substring' | 'word' ] )

Arguments​

search et isearch acceptent les arguments suivants :

  • target doit être de type STRING, VARIANT, STRUCT ou ARRAY, les mêmes types que ceux autorisés par l’indexation. Les cibles sont dédupliquées.
  • pattern doit être un littéral de chaîne non nul.
  • mode spécifie comment pattern correspond à chaque target:
    • substring (default) : pattern correspond à une sous-chaîne dans chaque target.
    • word: pattern est divisé en jetons de mots en utilisant la même règle que le tokeniseur split. La fonction renvoie true si chaque mot de pattern apparaît dans au moins une cible, quel que soit l'ordre. Voir Sélectionner un tokenizer pour votre cas d'utilisation.

Renvoie​

search et isearch renvoient une valeur BOOLEAN avec une logique à trois valeurs :

  • true si au moins une cible non nulle correspond.
  • null si aucune cible non nulle ne correspond, mais qu'au moins une cible est null.
  • false si toutes les cibles ne sont pas nulles et qu'aucune ne correspond.

Exemples​

Les exemples suivants présentent des query courantes de search et isearch :

SQL
-- Case-insensitive substring search across one column.
SELECT * FROM logs
WHERE isearch(message, 'connection refused');

-- Case-sensitive substring search across multiple columns.
SELECT * FROM logs
WHERE search(message, error_detail, '550e8400-e29b-41d4-a716-446655440000');

-- Word search: matches rows containing all three words, in any order.
SELECT * FROM audit_logs
WHERE search(message, 'user admin login', mode => 'word');

Gérer les index​

important

Les index de recherche en texte intégral ne se mettent pas à jour automatiquement lorsque la table de base change. Consultez refresh an index.

Databricks maintient la cohérence des query, indépendamment de la fraîcheur de l'index. Lorsqu'une table contient des données non indexées, la query utilise l'index existant pour accélérer l'accès aux enregistrements indexés et effectue une analyse de table pour les enregistrements non indexés.

Utilisez les opérations suivantes pour gérer les index de recherche en texte intégral :

Décrire ou afficher un index​

Pour afficher des informations sur un index :

SQL
DESCRIBE INDEX log_idx;

Refresh un index​

Les index de recherche plein texte ne se mettent pas à jour automatiquement lorsque la table de base change.

Pour mettre à jour l'index, en ajoutant des entrées pour les nouvelles lignes :

SQL
REFRESH INDEX log_idx;

REFRESH INDEX est une opération incrémentielle d'ajout uniquement. Il indexe les nouvelles données mais ne supprime pas les entrées pour les lignes supprimées.

Pour mettre à jour l'index, en ajoutant des entrées pour les nouvelles lignes et en supprimant les entrées pour les lignes supprimées, utilisez REFRESH INDEX ... FULL:

SQL
REFRESH INDEX log_idx FULL;

Un refresh complet nécessite plus de Ressources de compute qu'un refresh incrémentiel. Avec le temps, les actualisations incrémentielles accumulent des entrées obsolètes, ce qui augmente la taille de l’index et nuit aux performances.

Supprimer un index​

Pour supprimer un index, exécutez ce qui suit :

SQL
DROP INDEX log_idx;

Pour éviter une erreur pour les index manquants, utilisez :

SQL
DROP INDEX IF EXISTS log_idx;
remarque

Si vous supprimez la table de base, la commande supprime également les index de recherche en texte intégral.

Limitations​

Les index de recherche en texte intégral présentent les limitations suivantes :

  • Le renommage d'une colonne indexée sur la table de base, ou la modification de son type de données, n'est pas pris en charge.
  • Les tables avec OpenSharing ne sont pas prises en charge. Si vous ajoutez la table de base en tant que source ou cible OpenSharing après la création de l'index, Databricks ignore l'index de recherche.
  • Les tables avec des clones superficiels ne sont pas prises en charge. Si vous ajoutez la table de base comme source de clone superficiel après la création de l'index, Databricks ignore l'index de recherche.
  • Les tables avec des contrôles d'accès basés sur les attributs, des masques de colonne ou des politiques de sécurité au niveau des lignes ne sont pas prises en charge. Si vous ajoutez l'un de ces contrôles à une table avec un index de recherche, Databricks ignore l'index de recherche. Voir les concepts de base du contrôle d'accès basé sur les attributs (ABAC).
Sur cette page