Bonnes pratiques Amazon Redshift pour la conception de requêtes - Amazon Redshift

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques Amazon Redshift pour la conception de requêtes

Afin d'optimiser les performances des requêtes, suivez ces recommandations lors de la création de requêtes.

  • Concevez les tables conformément aux bonnes pratiques pour fournir des bases solides aux performances des requêtes. Pour plus d'informations, consultez Bonnes pratiques Amazon Redshift pour la conception de tables.

  • Évitez l'utilisation de select *. Incluez uniquement les colonnes dont vous avez spécifiquement besoin.

  • Utilisez un Expression conditionnelle CASE pour effectuer des regroupements complexes au lieu de choisir à partir de la même table plusieurs fois.

  • N'utilisez pas les jointures croisées, sauf nécessité absolue. Ces jointures sans condition de jointure se traduisent par le produit cartésien de deux tables. Les jointures croisées sont généralement exécutées comme jointures par boucle imbriquée, qui sont les types de jointures les plus lents possibles.

  • Utilisez les sous-requêtes dans les cas où une table de la requête n'est utilisée que pour les conditions de prédicat et où les sous-requêtes retournent un petit nombre de lignes (inférieur à 200). L'exemple suivant utilise une sous-requête pour éviter de joindre la table LISTING.

    select sum(sales.qtysold) from sales where salesid in (select listid from listing where listtime > '2008-12-26');
  • Utilisez les prédicats afin de limiter le jeu de données autant que possible.

  • Dans le prédicat, utilisez les opérateurs les moins onéreux que vous puissiez. Les opérateurs Condition de comparaison sont préférables aux opérateurs LIKE. Les opérateurs LIKE continuent d'être préférables aux opérateurs SIMILAR TO ou Opérateurs POSIX.

  • Évitez l'utiliser de fonctions dans les prédicats de requête. Leur utilisation peut accroître le coût de la requête en exigeant de grands nombres de lignes pour résoudre les étapes intermédiaires de la requête.

  • Si possible, utilisez la clause WHERE pour limiter l'ensemble de données. Comme le planificateur de requête peut alors utiliser l'ordre des lignes pour aider à déterminer quels enregistrements correspondent aux critères, il peut ignorer l'analyse de grands nombres de blocs de disque. Sans cela, le moteur d'exécution des requêtes doit analyser la totalité des colonnes participantes.

  • Ajoutez des prédicats pour filtrer les tables qui prennent part à des jointures, même si les prédicats appliquent les mêmes filtres. La requête renvoie le même ensemble de résultats, mais Amazon Redshift est capable de filtrer les tables de jonction avant l'étape d'analyse et peut ensuite sauter efficacement l'analyse des blocs de ces tables. Les filtres redondants ne sont pas nécessaires si vous filtrez une colonne utilisée dans la condition de jonction.

    Par exemple, supposons que vous souhaitiez joindre SALES et LISTING pour trouver les ventes de billets pour les billets répertoriés après décembre, regroupés par vendeur. Les deux tables sont triées sur la date. La requête suivante joint les tables sur leur clé commune et filtre les valeurs de listing.listtime postérieures au 1er décembre.

    select listing.sellerid, sum(sales.qtysold) from sales, listing where sales.salesid = listing.listid and listing.listtime > '2008-12-01' group by 1 order by 1;

    Comme la clause WHERE n'inclut pas de prédicat pour sales.saletime, le moteur d'exécution est contraint d'analyser la totalité de la table SALES. Si vous savez que le filtre se traduira par le fait que moins de lignes prennent part à la jointure, ajoutez également le filtre. L'exemple suivant réduit le temps d'exécution de façon significative.

    select listing.sellerid, sum(sales.qtysold) from sales, listing where sales.salesid = listing.listid and listing.listtime > '2008-12-01' and sales.saletime > '2008-12-01' group by 1 order by 1;
  • Utilisez les clés de tri dans la clause GROUP BY afin que le planificateur de requête puisse utiliser l'agrégation plus efficacement. Une requête peut être éligible à une agrégation en une phase lorsque sa liste GROUP BY contient uniquement des colonnes de clé tri, l'une d'elles étant aussi la clé de distribution. Les colonnes de clé de tri de la liste GROUP BY doivent inclure la première clé de tri, puis les autres clés de tri que vous souhaitez utiliser dans l'ordre des clés de tri. Par exemple, vous pouvez parfaitement utiliser la première clé de tri, les première et deuxième clés de tri, les première, deuxième et troisième clés de tri, et ainsi de suite. Vous ne pouvez pas utiliser les première et troisième clés de tri.

    Vous pouvez confirmer l'utilisation de l'agrégation en une phase en exécutant la commande EXPLAIN et en recherchant XN GroupAggregate dans l'étape d'agrégation de la requête.

  • Si vous utilisez les clauses GROUP BY et ORDER BY, assurez-vous d'y placer les colonnes dans le même ordre. Autrement dit, utilisez l'approche suivante :

    group by a, b, c order by a, b, c

    N'utilisez pas l'approche suivante :

    group by b, c, a order by a, b, c