Bonnes pratiques pour la conception de requêtes Amazon Redshift

Cette section fournit une vue d'ensemble des meilleures pratiques en matière de conception de requêtes. Nous vous recommandons de suivre les meilleures pratiques décrites dans cette section pour optimiser les performances et l'efficacité des requêtes.

Évitez d'utiliser l'instruction SELECT * FROM

Nous vous recommandons d'éviter d'utiliser SELECT * FROM cette déclaration. Au lieu de cela, listez toujours les colonnes à analyser. Cela réduit le temps d'exécution des requêtes et analyse les coûts des requêtes Amazon Redshift Spectrum.

Exemple de ce qu'il faut éviter

select * 
from sales;

Exemple de bonne pratique

select sales_date, sales_amt
from sales;

Identifier les problèmes liés aux requêtes

Nous vous recommandons de consulter la vue STL_ALERT_EVENT_LOG pour identifier et corriger les éventuels problèmes liés à votre requête.

Obtenez des informations récapitulatives sur votre requête

Nous vous recommandons d'utiliser les vues SVL_QUERY_SUMMARY et SVL_QUERY_REPORT pour obtenir des informations récapitulatives sur vos requêtes. Vous pouvez utiliser ces informations pour optimiser vos requêtes.

Évitez les jonctions croisées

Nous vous recommandons d'éviter d'utiliser des jonctions croisées, sauf en cas de nécessité absolue. Sans condition de jointure, les jointures croisées produisent le produit cartésien de deux tables. Les jointures croisées sont généralement exécutées sous forme de boucles imbriquées (le type de jointure le plus lent possible).

Exemple de ce qu'il faut éviter

select c.c_name, 
          n.n_name 
from tpch.customer c, 
        tpch.nation n;

Exemple de bonne pratique

select c.c_name, 
           n.n_name 
from tpch.customer c, 
join tpch.nation n
  on n.n_nationkey = c.c_nationkey;

Évitez les fonctions dans les prédicats de requête

Nous vous recommandons d'éviter d'utiliser des fonctions dans les prédicats de requête. L'utilisation de fonctions dans les prédicats de requête peut avoir un impact négatif sur les performances, car les fonctions ajoutent généralement une charge de traitement supplémentaire à chaque ligne et ralentissent l'exécution globale de la requête.

Exemple de ce qu'il faut éviter

select sum(o_totalprice)
from tpch.orders
where datepart(year, o_orderdate) = 1992;

Exemple de bonne pratique

select sum(o_totalprice)
from tpch.orders
where o_orderdate between '1992-01-01' and '1992-12-31';

Évitez les conversions de casting inutiles

Nous vous recommandons d'éviter d'utiliser une conversion par diffusion inutile sur les requêtes, car le casting des types de données prend du temps et des ressources et ralentit l'exécution des requêtes.

Exemple de ce qu'il faut éviter

select sum(o_totalprice)
from tpch.orders
where o_ordertime::date = '1992-01-01';

Exemple de bonne pratique

select sum(o_totalprice)
from tpch.orders
where o_ordertime between '1992-01-01 00:00:00' and '1992-12-31 23:59:59';

Utiliser des expressions CASE pour des agrégations complexes

Nous vous recommandons d'utiliser une expression CASE pour effectuer des agrégations complexes au lieu de sélectionner plusieurs fois dans la même table.

Exemple de ce qu'il faut éviter

select sum(sales_amt) as us_sales
from sales
where country = 'US';

select sum(sales_amt) as ca_sales
from sales
where country = 'CA';

Exemple de bonne pratique

select sum(case when country = 'US' then sales_amt end) as us_sales,
           sum(case when country = 'CA' then sales_amt end) as ca_sales
from sales;

Utiliser des sous-requêtes

Nous vous recommandons d'utiliser des sous-requêtes lorsqu'une table de la requête est utilisée uniquement pour les conditions de prédicat et que la sous-requête renvoie un petit nombre de lignes (moins de 200 environ).

Exemple de ce qu'il faut éviter

Si une sous-requête renvoie moins de 200 lignes :

select sum(order_amt) as total_sales
from sales
where region_key IN
        (select region_key
         from regions
         where state = 'CA');

Exemple de bonne pratique

Si une sous-requête renvoie une valeur supérieure ou égale à 200 lignes :

select sum(o.order_amt) as total_sales
from sales o
join regions r
  on r.region_key = o.region_key
  and r.state = 'CA';

Utiliser des prédicats

Nous vous recommandons d'utiliser des prédicats pour restreindre le jeu de données autant que possible. Les prédicats sont utilisés en SQL pour filtrer et restreindre les données renvoyées dans une requête. En spécifiant des conditions dans un prédicat, vous pouvez spécifier les lignes qui doivent être incluses dans les résultats de la requête en fonction de conditions spécifiées. Cela vous permet de récupérer uniquement les données qui vous intéressent et d'améliorer l'efficacité et la précision de vos requêtes. Pour plus d'informations, consultez la section Conditions dans la documentation Amazon Redshift.

Ajouter des prédicats pour filtrer les tables avec des jointures

Nous vous recommandons d'ajouter des prédicats pour filtrer les tables qui participent aux jointures, même si les prédicats appliquent les mêmes filtres. L'utilisation de prédicats pour filtrer les tables comportant des jointures dans SQL peut améliorer les performances des requêtes en réduisant la quantité de données à traiter et en réduisant la taille du jeu de résultats intermédiaires. En spécifiant les conditions de l'opération de jointure dans la WHERE clause, le moteur d'exécution des requêtes peut éliminer les lignes qui ne répondent pas aux conditions avant leur jointure. Cela se traduit par un ensemble de résultats réduit et une exécution plus rapide des requêtes.

Exemple de ce qu'il faut éviter

select p.product_name, sum(o.order_amt)
from sales o
join product p
   on r.product_key = o.product_key
where o.order_date > '2022-01-01';

Exemple de bonne pratique

select p.product_name, sum(o.order_amt)
from sales o
join product p
  on p.product_key = o.product_key
  and p.added_date > '2022-01-01'
where o.order_date > '2022-01-01';

Utilisez les opérateurs les moins chers pour les prédicats

Dans le prédicat, utilisez les opérateurs les moins chers possibles. Les opérateurs de conditions de comparaison sont préférables aux opérateurs LIKE. LIKEles opérateurs sont toujours préférables aux opérateurs SIMILAR TO ou POSIX.

Utiliser des clés de tri dans les clauses GROUP BY

Utilisez des clés de tri dans la GROUP BY clause afin que le planificateur de requêtes puisse utiliser une agrégation plus efficace. Une requête peut être éligible à une agrégation monophasée lorsque sa GROUP BY liste ne contient que des colonnes de clé de tri, dont l'une est également la clé de distribution. Les colonnes de clé de tri de la GROUP BY liste doivent inclure la première clé de tri, suivie des autres clés de tri que vous souhaitez utiliser dans l'ordre des clés de tri.

Tirez parti des vues matérialisées

Si possible, réécrivez la requête en remplaçant le code complexe par une vue matérialisée, ce qui améliorera considérablement les performances de la requête. Pour plus d'informations, consultez la section Création de vues matérialisées dans Amazon Redshift dans la documentation Amazon Redshift.

Faites attention aux colonnes des clauses GROUP BY et ORDER BY

Si vous utilisez les deux ORDER BY clauses GROUP BY et, assurez-vous de placer les colonnes dans le même ordre dans GROUP BY les deux ORDER BY clauses. GROUP BYexige implicitement que les données soient triées. Si votre ORDER BY clause est différente, les données doivent être triées deux fois.

Exemple de ce qu'il faut éviter

select a, b, c, sum(d)
from a_table
group by b, c, a
order by a, b, c

Exemple de bonne pratique

select a, b, c, sum(d)
from a_table
group by a, b, c
order by a, b, c