Identifier les requêtes qui peuvent bénéficier de l’optimisation de la recherche¶

Caractéristiques générales des requêtes¶

L’optimisation de la recherche permet d’améliorer les performances des types de requêtes suivants :

• La requête porte sur une ou plusieurs colonnes autres que la clé de cluster principale.

• La requête s’exécute généralement pendant quelques secondes ou plus (avant l’application de l’optimisation de la recherche). Dans la plupart des cas, l’optimisation de la recherche n’améliorera pas sensiblement les performances d’une requête dont le temps d’exécution est inférieur à la seconde.

• Au moins une des colonnes auxquelles l’opération de filtrage de la requête a permis d’accéder comporte au moins 100 000 valeurs distinctes.

  Pour déterminer le nombre de valeurs distinctes, vous pouvez utiliser l’une des méthodes suivantes :

  • Utilisez APPROX_COUNT_DISTINCT pour obtenir le nombre approximatif de valeurs distinctes :

    SELECT APPROX_COUNT_DISTINCT(column1) FROM table1;
    

    Copy

  • Utilisez COUNT(DISTINCT <nom_colonne>) pour obtenir le nombre réel de valeurs distinctes :

    SELECT COUNT(DISTINCT c1), COUNT(DISTINCT c2) FROM test_table;
    

    Copy

  Etant donné que vous n’avez besoin que d’une approximation du nombre de valeurs distinctes, pensez à utiliser APPROX_COUNT_DISTINCT, qui est généralement plus rapide et plus économique que COUNT(DISTINCT <col_name>).

Types de données pris en charge¶

Le service d’optimisation de la recherche prend actuellement en charge les types de données suivants :

• Types de données pour les numéros à virgule fixe (par exemple, INTEGER et NUMERIC)

• Types de données Chaîne et Binaire (par exemple, VARCHAR et BINARY)

• Types de données de date et heure (par exemple, DATE, TIME, et TIMESTAMP)

• Types de données semi-structurées (par exemple, VARIANT, OBJECT, et ARRAY)

• Type de données GEOGRAPHY

Les requêtes qui impliquent d’autres valeurs d’autres types de données (par exemple, FLOAT ou GEOMETRY) n’en bénéficient pas.

Types de prédicats pris en charge¶

L’optimisation de la recherche peut améliorer la performance des requêtes utilisant ce type de prédicats :

• Requêtes de recherche de points utilisant l’égalité et IN.

• Requêtes conjointes.

• Requêtes utilisant des sous-requêtes scalaires.

• Requêtes utilisant des fonctions scalaires.

• Requêtes de données de caractères (texte) à l’aide des fonctions SEARCH et SEARCH_IP.

• Requêtes de sous-chaîne à l’aide de caractères génériques et d’expressions régulières.

• Recherches dans des données semi-structurées.

• Requêtes géospatiales.

• Requêtes utilisant des conjonctions (AND) et des disjonctions (OR).

Prise en charge du classement¶

L’optimisation de la recherche peut améliorer les performances des requêtes sur les colonnes définies avec une clause COLLATE, en fonction de la méthode de recherche :

• Lorsque l’optimisation de la recherche est activée dans une colonne à l’aide de la méthode de recherche EQUALITY, toutes les spécifications de classement sont prises en charge.

• Lorsque l’optimisation de la recherche est activée dans une colonne à l’aide de la méthode de recherche FULL_TEXT ou SUBSTRING, les spécifications de classement 'utf8' ou 'bin' sont prises en charge.

Pour plus d’informations sur les méthodes de recherche, voir ALTER TABLE … ADD SEARCH OPTIMIZATION.

L’optimisation de la recherche ne prend pas en charge les prédicats qui modifient le classement d’une colonne à l’aide de la fonction COLLATE.

Par exemple, créez une table dont les colonnes ont des spécifications de classement et insérez une ligne :

CREATE OR REPLACE TABLE search_optimization_collation_demo (
  en_ci_col VARCHAR COLLATE 'en-ci',
  utf_8_col VARCHAR COLLATE 'utf8');

INSERT INTO search_optimization_collation_demo VALUES (
  'test_collation_1',
  'test_collation_2');

Activez l’optimisation de la recherche pour les prédicats d’égalité dans les deux colonnes de la table :

ALTER TABLE search_optimization_collation_demo
  ADD SEARCH OPTIMIZATION ON EQUALITY(en_ci_col, utf_8_col);

La requête suivante peut bénéficier de l’optimisation de la recherche :

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col = 'test_collation_2';

La requête suivante ne peut pas bénéficier de l’optimisation de la recherche parce qu’elle modifie la spécification de classement de la colonne utf_8_col via la fonction COLLATE :

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col COLLATE 'de-ci' = 'test_collation_2';

La requête suivante ne peut pas non plus bénéficier de l’optimisation de la recherche. Sur la base de l”ordre de priorité des règles de classement, la requête applique la spécification de classement 'de-ci' à la colonne utf_8_col à l’aide de la fonction COLLATE.

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col = 'test_collation_2' COLLATE 'de-ci';

Prise en charge des tables Apache Iceberg™¶

L’optimisation de la recherche peut améliorer la performance des requêtes sur les tables Apache Iceberg™. Pour plus d’informations sur la configuration de l’optimisation de la recherche pour les tables Iceberg, voir ALTER ICEBERG TABLE.

Les limites suivantes s’appliquent à la prise en charge de “optimisation de la recherche pour les tables Iceberg :

• L’optimisation de la recherche ne peut pas être ajoutée pour les colonnes ayant des types de données que les tables Iceberg ne prennent pas en charge, notamment les types de données semi-structurées et géospatiales. Pour plus d’informations, voir Types de données des tables Apache Iceberg™.

• Le service d’optimisation de la recherche ne prend pas en charge les colonnes avec des types de données structurées.

• Si les fichiers Apache Parquet™ sont trop volumineux (par exemple, des centaines de mégaoctets compressés), les requêtes risquent de ne pas bénéficier pleinement du service d’optimisation de la recherche dans certains scénarios.

Les autres limites qui s’appliquent à l’optimisation de la recherche pour les tables Snowflake s’appliquent également aux tables Iceberg. Pour plus d’informations, voir Requêtes qui ne bénéficient pas d’une optimisation de la recherche.

Améliorations potentielles pour les vues¶

Le service d’optimisation de la recherche peut indirectement améliorer les performances des vues (y compris les vues sécurisées). Si l’optimisation de la recherche est activée dans une table de base pour une vue et si la requête utilise un prédicat sélectif pour cette table, le service d’optimisation de la recherche peut améliorer les performances lors du filtrage des lignes. Voir Types de prédicats pris en charge.

L’optimisation de la recherche n’a pas besoin d’être activée sur toutes les tables de la vue. L’optimisation de la recherche est effectuée sur chaque table indépendamment.

Requêtes qui ne bénéficient pas d’une optimisation de la recherche¶

Actuellement, le service d’optimisation de la recherche ne prend pas en charge les types de données à virgule flottante, GEOMETRY ou d’autres types de données non répertoriés ci-dessus. Snowflake pourrait prendre en charge d’autres types de données à l’avenir.

En outre, le service d’optimisation de la recherche ne prend pas en charge les éléments suivants :

• Tables externes.

• Vues matérialisées.

• Concaténation de colonnes.

• Expressions analytiques.

• Correspond aux colonnes de la table (sauf pour les nombres à virgule fixe convertis en chaînes de caractères).

  Bien que l’optimisation de la recherche prenne en charge les prédicats avec des conversions implicites et explicites sur les valeurs constantes, elle ne prend pas en charge les prédicats qui convertissent des valeurs dans la colonne de table réelle (sauf pour les conversions de INTEGER et NUMBER à VARCHAR).

  Par exemple, les prédicats suivants sont pris en charge, car ils utilisent des conversions implicites et explicites sur des valeurs constantes (et non des valeurs dans la colonne du tableau) :

  -- Supported predicate
  -- (where the string '2020-01-01' is implicitly cast to a date)
  WHERE timestamp1 = '2020-01-01';
  
  -- Supported predicate
  -- (where the string '2020-01-01' is explicitly cast to a date)
  WHERE timestamp1 = '2020-01-01'::date;
  

  Copy

  Le prédicat suivant n’est pas pris en charge, car il utilise une conversion sur des valeurs dans la colonne de table :

  -- Unsupported predicate
  -- (where values in a VARCHAR column are cast to DATE)
  WHERE to_date(varchar_column) = '2020-01-01';
  

  Copy

  Le service d’optimisation de la recherche prend en compte les valeurs de colonne d’origine et non les valeurs après la conversion. Par conséquent, le service d’optimisation de la recherche n’est pas utilisé pour les requêtes avec ces prédicats.

Comme nous l’avons mentionné précédemment, l’exception à cette règle est la conversion de valeurs NUMBER ou INTEGER en des valeurs VARCHAR dans la colonne de la table. Le service d’optimisation de la recherche prend en charge ce type de prédicat :

-- Supported predicate
-- (where values in a numeric column are cast to a string)
WHERE cast(numeric_column as varchar) = '2'

Copy

L’optimisation de la recherche n’améliore pas les performances des requêtes qui utilisent Time Travel, car l’optimisation de la recherche ne fonctionne que sur les données actives.