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

Queries that involve other values of other data types (for example, FLOAT, DECFLOAT, or GEOMETRY) don’t benefit.

Supported table types¶

The search optimization service currently supports the following types of tables:

• Standard Snowflake tables

• Interactive tables

• Iceberg tables

• Dynamic tables

• Transient tables

The search optimization service currently doesn’t support the following types of tables:

• External tables

• Hybrid tables

• Temporary tables

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¶

Currently, the search optimization service doesn’t support floating point data types, GEOMETRY, or other data types not already discussed. Snowflake might add support for more data types in the future.

Additionally, the search optimization service doesn’t support the following:

• Some table types.

  For more information, see Supported table types.

• 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).

  Although search optimization supports predicates with implicit and explicit casts on constant values, it doesn’t support predicates that cast values in the actual table column (except for casts from INTEGER and NUMBER to 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

Search optimization doesn’t improve performance of queries that use Time Travel because search optimization works only on active data.