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 CASEexpression conditionnelle 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 LISTING table.

    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. LIKEles opérateurs sont toujours préférables à SIMILARÀ ouPOSIXopérateurs.

  • É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 une WHERE clause pour restreindre 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;

    La WHERE clause n'inclut pas de prédicat poursales.saletime, de sorte que le moteur d'exécution est obligé de scanner la SALES table entière. 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 des clés de tri dans la clause GROUP BY 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 liste GROUP BY 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 liste GROUP PAR 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 à la fois des clauses GROUP ORDER BY et BY, veillez à placer les colonnes dans le même ordre dans les deux cas. 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