Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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 tables
Lorsque vous planifiez votre base de données, certaines décisions clés en matière de conception de table influencent fortement les performances globales des requêtes. Ces choix de conception ont également un effet significatif sur les besoins en stockage, lesquels, à leur tour, affectent les performances des requêtes en réduisant le nombre d'opérations d'I/O et la mémoire requise pour traiter les requêtes.
Cette section résume les plus importantes décisions de conception et les bonnes pratiques d'optimisation des performances des requêtes. [Optimisation automatique des tables](t_Creating_tables.md) fournit des explications et des exemples plus détaillés d'options de conception de table.
**Topics**
+ [Choix de la meilleure clé de tri](c_best-practices-sort-key.md)
+ [Choisir le meilleur style de distribution](c_best-practices-best-dist-key.md)
+ [Laissez COPY choisir les encodages de compression](c_best-practices-use-auto-compression.md)
+ [Définir les contraintes de clé primaire et de clé étrangère](c_best-practices-defining-constraints.md)
+ [Utiliser la plus petite taille de colonne possible](c_best-practices-smallest-column-size.md)
+ [Utiliser date/time des types de données pour les colonnes de date](c_best-practices-timestamp-date-columns.md)
# Choix de la meilleure clé de tri
Amazon Redshift stocke vos données sur le disque dans un ordre trié selon la clé de tri. L'optimiseur de requête Amazon Redshift utilise l'ordre de tri lorsqu'il détermine les plans de requête optimaux.
**Note**
Lorsque vous utilisez l'optimisation automatique des tables, vous n'avez pas besoin de choisir la clé de tri de votre table. Pour plus d'informations, consultez [Optimisation automatique des tables](t_Creating_tables.md).
Voici quelques suggestions pour la meilleure approche :
+ Pour qu'Amazon Redshift choisisse l'ordre de tri approprié, spécifiez `AUTO` pour la clé de tri.
+ Si les données récentes sont interrogées le plus fréquemment, spécifiez la colonne d'horodatage en tant que colonne principale de la clé de tri.
Les requêtes sont plus efficaces, car elles peuvent ignorer des blocs entiers qui ne relèvent pas de la plage de temps.
+ Si vous effectuez le filtrage par plage ou par égalité sur une seule colonne, spécifiez cette colonne comme clé de tri.
Amazon Redshift peut omettre la lecture de blocs entiers de données pour cette colonne. Il peut le faire car il assure le suivi des valeurs de colonne minimales et maximales stockées sur chaque bloc et peut ignorer les blocs qui ne s'appliquent pas à la plage de prédicats.
+ Si vous effectuez fréquemment la jointure d'une table, spécifiez la colonne de jointure à la fois comme clé de tri et comme clé de distribution.
Cela permet à l'optimiseur de requête de choisir une sorte de jointure de fusion triée au lieu d'une jointure de hachage plus lente. Étant donné que les données sont déjà triées sur la clé de jointure, l'optimiseur de requête peut contourner la phase de tri de la jointure de fusion triée.
# Choisir le meilleur style de distribution
Lorsque vous exécutez une requête, l’optimiseur de requête redistribue les lignes sur les nœuds de calcul en fonction des besoins afin d’effectuer les jointures et les agrégations. Le choix d'un style de distribution de table a pour objectif de minimiser l'impact de l'étape de redistribution en plaçant les données où elles doivent être avant que la requête ne soit exécutée.
**Note**
Lorsque vous utilisez l'optimisation automatique des tables, vous n'avez pas besoin de choisir le mode de distribution de votre table. Pour plus d'informations, consultez [Optimisation automatique des tables](t_Creating_tables.md).
Voici quelques suggestions pour la meilleure approche :
1. Distribuez la table des faits et une table de dimension sur leurs colonnes communes.
Votre table de faits peut n’avoir qu’une seule clé de distribution. Toutes les tables qui sont jointes à une autre clé de distribution ne sont pas colocalisées avec la table des faits. Choisissez une dimension pour colocaliser en fonction de la fréquence à laquelle elle est jointe et de la taille des lignes de jointure. Désignez la clé primaire de la table de dimension et la clé étrangère correspondante de la table des faits comme DISTKEY.
1. Choisissez la plus grande dimension en fonction de la taille de l'ensemble de données filtré.
Comme seules les lignes utilisées dans la jointure doivent être distribuées, prenez en compte la taille du jeu de données après filtrage, et non la taille de la table.
1. Sélectionnez une colonne avec cardinalité élevée dans l'ensemble de résultats filtré.
Si vous distribuez une table des ventes sur une colonne date, par exemple, vous obtiendrez probablement une distribution des données assez uniforme, à moins que la plupart de vos ventes ne soient saisonnières. Cependant, si vous utilisez généralement un prédicat à plage restreinte pour filtrer sur une période de dates étroite, la plupart des lignes filtrées se trouvent sur un ensemble limité de tranches et la charge de travail des requêtes est biaisée.
1. Modifiez certaines tables de dimension pour utiliser la distribution ALL.
Si une table de dimension ne peut pas être colocalisée avec la table des faits ou d’autres tables de jointure importantes, il vous est possible d’améliorer considérablement les performances des requêtes en distribuant la totalité de la table sur tous les nœuds. La distribution ALL multiplie les besoins en espace de stockage et augmente les temps de chargement et les opérations de maintenance. Vous devez donc évaluer tous les facteurs avant de choisir la distribution ALL.
Pour demander à Amazon Redshift de choisir le style de distribution approprié, spécifiez `AUTO` pour le style de distribution.
Pour plus d'informations sur le choix des styles de distribution, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
# Laissez COPY choisir les encodages de compression
Vous pouvez spécifier les encodages de compression lorsque vous créez une table, mais, dans la plupart des cas, la compression automatique donne les meilleurs résultats.
ENCODE AUTO est la valeur par défaut pour les tables. Lorsqu’une table est définie sur ENCODE AUTO, Amazon Redshift gère automatiquement l’encodage de compression pour toutes les colonnes de la table. Pour plus d’informations, consultez [CREATE TABLE](r_CREATE_TABLE_NEW.md) et [ALTER TABLE](r_ALTER_TABLE.md).
La commande COPY analyse vos données et applique automatiquement les encodages de compression sur une table vide dans le cadre de l'opération de chargement.
La compression automatique équilibre les performances globales lors du choix des encodages de compression. Les analyses à plage restreinte peuvent mal s’exécuter si les colonnes de clé de tri sont beaucoup plus compressées que les autres colonnes de la même requête. Par conséquent, la compression automatique choisit un encodage de compression moins efficace pour que les colonnes de clé de tri demeurent équilibrées avec les autres colonnes.
Supposons que la clé de tri de la table soit de type date ou timestamp, et que la table utilise de nombreuses colonnes de type varchar. Dans ce cas, vous pourrez obtenir de meilleures performances en ne compressant pas du tout la colonne de la clé de tri. Exécutez la commande [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) sur la table, puis utilisez les encodages pour créer une table, mais excluez l'encodage de compression pour la clé de tri.
L'encodage de compression automatique présente un coût en termes de performances, mais seulement si la table est vide et qu'elle ne possède pas déjà un encodage de compression. Pour les tables de courte durée et les tables que vous créez fréquemment, telles que les tables intermédiaires, chargez la table une fois avec la compression automatique ou exécutez la commande ANALYZE COMPRESSION. Utilisez ensuite ces encodages pour créer des tables. Vous pouvez ajouter les encodages à l'instruction CREATE TABLE, ou utiliser CREATE TABLE LIKE pour créer une table avec le même encodage.
Pour plus d'informations, consultez [Chargement des tables avec compression automatique](c_Loading_tables_auto_compress.md).
# Définir les contraintes de clé primaire et de clé étrangère
Définissez les contraintes de clé primaire et de clé étrangère entre les tables chaque fois que nécessaire. Même si elles n'ont qu'une valeur informative, l'optimiseur de requête utilise ces contraintes pour générer des plans de requête plus efficaces.
Ne définissez pas de contraintes de clé primaire et de clé étrangère à moins que votre application ne les applique. Amazon Redshift n'applique pas les contraintes d'unicité, de clé primaire et de clé étrangère.
Consultez [Contraintes de table](t_Defining_constraints.md) pour obtenir des informations supplémentaires sur la manière dont Amazon Redshift utilise les contraintes.
# Utiliser la plus petite taille de colonne possible
Ne vous habituez pas à utiliser la taille de colonne maximale pour des raisons de commodité.
Au lieu de cela, prenez en compte les valeurs les plus grandes que vous êtes susceptible de stocker dans vos colonnes et dimensionnez ces dernières en conséquence. Par exemple, une colonne CHAR pour stocker les abréviations d’États et de territoires américains utilisées par la poste a uniquement besoin d’être CHAR(2).
# Utiliser date/time des types de données pour les colonnes de date
Amazon Redshift stocke les données DATE et TIMESTAMP de manière plus efficace que CHAR ou VARCHAR, ce qui permet d'améliorer les performances des requêtes. Utilisez le type de données DATE ou TIMESTAMP, en fonction de la résolution dont vous avez besoin, plutôt qu'un type caractère lors du stockage d'informations de type date/time. Pour plus d'informations, consultez [Types datetime](r_Datetime_types.md).