Recommandations Amazon Redshift Advisor

Amazon Redshift Advisor met à votre disposition des recommandations sur la façon d'optimiser votre cluster Amazon Redshift afin d'augmenter ses performances et de réduire les coûts d'exploitation. Vous trouverez des explications sur chaque recommandation dans la console, comme décrit précédemment. Vous trouverez des informations supplémentaires sur ces recommandations dans les sections suivantes :

Compressez les objets de fichier Amazon S3 chargés par COPY

La COPY commande tire parti de l'architecture massively parallel processing (MPP) d'Amazon Redshift pour lire et charger des données en parallèle. Il peut lire des fichiers à partir d'Amazon S3, des tables DynamoDB et des sorties texte à partir d'un ou plusieurs hôtes distants.

Lorsque vous chargez de grandes quantités de données, nous vous recommandons vivement d'utiliser la COPY commande pour charger des fichiers de données compressés depuis S3. La compression de jeux de données volumineux permet de réduire le temps de chargement des fichiers sur Amazon S3. COPYpeut également accélérer le processus de chargement en décompressant les fichiers au fur et à mesure de leur lecture.

Analyse

Les COPY commandes de longue durée qui chargent de grands ensembles de données non compressés permettent souvent d'améliorer considérablement les performances. L'analyse Advisor identifie les COPY commandes qui chargent de grands ensembles de données non compressés. Dans ce cas, Advisor génère une recommandation visant à mettre en œuvre la compression sur les fichiers sources dans Amazon S3.

Recommandation

Assurez-vous que chaque appareil COPY qui charge une quantité importante de données, ou qui s'exécute pendant une longue durée, ingère des objets de données compressés provenant d'Amazon S3. Vous pouvez identifier les COPY commandes qui chargent de grands ensembles de données non compressés depuis Amazon S3 en exécutant la SQL commande suivante en tant que superutilisateur.

SELECT
    wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size) 
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;         
          

Si les données temporaires restent dans Amazon S3 après leur chargement, ce qui est courant dans les architectures de lac de données, leur stockage sous une forme compressée peut réduire vos coûts de stockage.

Conseils d'implémentation

• La taille idéale des objets est de 1 à 128 Mo après compression.

• Vous pouvez compresser vos fichiers à l'aide des formats gzip, lzop ou bzip2.

Isolation de plusieurs bases de données actives

Comme bonne pratique, nous recommandons d'isoler les bases de données dans Amazon Redshift les unes des autres. Les requêtes s'exécutent dans une base de données spécifique et ne peuvent accéder aux données des autres bases de données du cluster. Toutefois, les requêtes que vous exécutez dans toutes les bases de données d'un cluster partagent le même espace de stockage de cluster sous-jacent et les mêmes ressources de calcul. Lorsqu'un cluster unique contient plusieurs bases de données actives, leurs charges de travail sont généralement sans lien.

Analyse

L'analyse Advisor passe en revue toutes les bases de données du cluster à la recherche des charges de travail actives s'exécutant en même temps. Si des charges de travail actives sont exécutées en même temps, Advisor génère une recommandation pour envisager la migration des bases de données vers des clusters Amazon Redshift distincts.

Recommandation

Vous devez envisager de déplacer chaque base de données faisant l'objet de requêtes actives vers un cluster dédié distinct. L'utilisation d'un cluster distinct peut réduire les conflits de ressources et améliorer les performances des requêtes. En effet, cela vous permet de définir la taille de chaque cluster en fonction du stockage, des coûts et des performances attendus pour chaque charge de travail. En outre, les charges de travail non liées utilisent souvent des configurations de gestion de charge de travail différentes.

Pour identifier les bases de données activement utilisées, vous pouvez exécuter cette SQL commande en tant que superutilisateur.

SELECT database,
  COUNT(*) as num_queries,
  AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
  MIN(starttime) as oldest_ts,
  MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;            
         

Conseils d'implémentation

• Étant donné qu'un utilisateur doit se connecter à chaque base de données de façon spécifique et que les requêtes ne peuvent accéder qu'à une seule base de données, le déplacement des bases de données vers d'autres clusters a un impact minimal sur les utilisateurs.

• Pour déplacer une base de données, vous pouvez procéder comme suit :

  1. Restaurez temporairement un instantané du cluster actuel sur un cluster de même taille.

  2. Supprimez toutes les bases de données du nouveau cluster, à l'exception de la base de données cible à déplacer.

  3. Redimensionnez le cluster sur un type de nœud approprié et tenez compte de la charge de travail de la base de données.

Réallocation de la mémoire de gestion de la charge de travail (WLM)

Amazon Redshift achemine les requêtes utilisateur vers Manuel de mise en œuvre WLM en vue de leur traitement. La gestion de la charge de travail (WLM) définit la manière dont ces requêtes sont acheminées vers les files d'attente. Amazon Redshift alloue à chaque file d'attente une partie de la mémoire disponible du cluster. La mémoire d’une file d’attente est répartie entre les emplacements de requête de la file d’attente.

Lorsqu'une file d'attente est configurée avec plus d'emplacements que la charge de travail n'en requiert, la mémoire allouée à ces emplacements inutilisés est sous-utilisée. La réduction des emplacements configurés en fonction des exigences de la charge de travail maximale permet de redistribuer la mémoire sous-utilisée aux emplacements actifs et peut améliorer ainsi les performances des requêtes.

Analyse

L'analyse Advisor passe en revue les exigences en matière de simultanéité de la charge de travail afin d'identifier les files d'attente de requêtes ayant des emplacement inutilisés. Advisor génère une recommandation conseillant de réduire le nombre d'emplacements dans une file d'attente lorsqu'il détecte les éléments suivants :

• Une file d'attente avec des emplacements complètement inactifs pendant l'analyse.

• Une file d'attente avec plus de quatre emplacements dont au moins deux sont inactifs pendant l'analyse.

Recommandation

La réduction des emplacements configurés en fonction des exigences de la charge de travail maximale permet de redistribuer la mémoire sous-utilisée aux emplacements actifs. Envisagez de réduire le nombre d'emplacements configurés pour les files d'attente où les emplacements n'ont jamais été totalement utilisés. Pour identifier ces files d'attente, vous pouvez comparer les créneaux horaires de pointe requis pour chaque file d'attente en exécutant la SQL commande suivante en tant que superutilisateur.

WITH
 generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
 apex AS (
     SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
     FROM
         (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
         FROM stl_wlm_query wq
         JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
         JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
         WHERE wq.userid > 1 AND wq.service_class > 5) iq
     GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
     maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                     from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;            
         

La max_service_class_slots colonne représente le nombre maximum de créneaux de WLM requêtes dans la file d'attente de requêtes pour cette heure. S'il existe des files d'attente sous-utilisées, mettez en œuvre l'optimisation de la réduction des créneaux en modifiant un groupe de paramètres, comme décrit dans le Guide de gestion Amazon Redshift.

Conseils d'implémentation

• Si votre charge de travail est fortement variable en volume, veillez à ce que l'analyse capture une période d'utilisation maximale. Si ce n'est pas le cas, exécutez la procédure précédente à SQL plusieurs reprises pour surveiller les exigences de simultanéité de pointe.

• Pour plus de détails sur l'interprétation des résultats des requêtes à partir du SQL code précédent, consultez le script wlm_apex_hourly.sql sur GitHub.

Ignorer l'analyse de compression pendant COPY

Lorsque vous chargez des données dans une table vide dont le codage de compression a été déclaré par la COPY commande, Amazon Redshift applique la compression du stockage. Cette optimisation permet de s'assurer que les données de votre cluster sont stockées efficacement, même lorsqu'elles sont chargées par les utilisateurs finaux. L'analyse requise pour appliquer la compression peut prendre un certain temps.

Analyse

L'analyse Advisor vérifie les COPY opérations qui ont été retardées par une analyse de compression automatique. L'analyse détermine les encodages de compression en échantillonnant les données pendant leur chargement. Cet échantillon est similaire à celui effectué par la commande ANALYZE COMPRESSION.

Lorsque vous chargez des données dans le cadre d'un processus structuré, par exemple dans le cadre d'un batch d'extraction, de transformation, de chargement (ETL) en une nuit, vous pouvez définir la compression à l'avance. Vous pouvez également optimiser vos définitions de table en omettant cette phase de façon permanente sans aucun impact négatif.

Recommandation

Pour améliorer COPY la réactivité en sautant la phase d'analyse de compression, implémentez l'une des deux options suivantes :

• Utilisez le ENCODE paramètre column lorsque vous créez les tables que vous chargez à l'aide de la COPY commande.

• Désactivez complètement la compression en fournissant le COMPUPDATE OFF paramètre dans la COPY commande.

La meilleure solution est généralement d'utiliser l'encodage de colonne lors de la création de table, car cette approche permet également de conserver le bénéfice du stockage des données compressées sur le disque. Vous pouvez utiliser la ANALYZE COMPRESSION commande pour suggérer des codages de compression, mais vous devez recréer la table pour appliquer ces codages. Pour automatiser ce processus, vous pouvez utiliser le AWSColumnEncodingUtility, disponible sur GitHub.

Pour identifier les COPY opérations récentes qui ont déclenché une analyse de compression automatique, exécutez la SQL commande suivante.

  WITH xids AS (
    SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 
    AND querytxt = 'analyze compression phase 1' GROUP BY xid
    INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, 
    a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) 
    starttime, substring(querytxt,1,100) as copy_sql, 
    ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') 
    AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid, 
    ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec 
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt like 'COPY ANALYZE %' 
    OR querytxt like 'analyze compression phase %') 
    GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;
         

Conseils d'implémentation

• Assurez-vous que toutes les tables de taille significative créées au cours de vos ETL processus (par exemple, les tables intermédiaires et les tables temporaires) déclarent un codage de compression pour toutes les colonnes à l'exception de la première clé de tri.

• Estimez la durée de vie attendue de la table en cours de chargement pour chacune des COPY commandes identifiées par la SQL commande précédente. Si vous êtes sûr que la table restera extrêmement petite, désactivez totalement la compression à l'aide du paramètre COMPUPDATE OFF. Sinon, créez la table avec une compression explicite avant de la charger avec la COPY commande.

Divisez les objets Amazon S3 chargés par COPY

La COPY commande tire parti de l'architecture massively parallel processing (MPP) d'Amazon Redshift pour lire et charger des données à partir de fichiers sur Amazon S3. La COPY commande charge les données en parallèle à partir de plusieurs fichiers, répartissant ainsi la charge de travail entre les nœuds de votre cluster. Afin d'obtenir un débit optimal, nous vous recommandons vivement de fractionner vos données en plusieurs fichiers pour tirer parti du traitement parallèle.

Analyse

L'analyse d'Advisor identifie COPY les commandes qui chargent de grands ensembles de données contenus dans un petit nombre de fichiers stockés dans Amazon S3. Les COPY commandes de longue durée qui chargent des ensembles de données volumineux à partir de quelques fichiers permettent souvent d'améliorer considérablement les performances. Lorsque Advisor identifie que ces COPY commandes prennent beaucoup de temps, il recommande d'augmenter le parallélisme en divisant les données en fichiers supplémentaires dans Amazon S3.

Recommandation

Dans ce cas, nous recommandons les actions suivantes, répertoriées par ordre de priorité :

1. Optimisez COPY les commandes qui chargent moins de fichiers que le nombre de nœuds du cluster.

2. Optimisez COPY les commandes qui chargent moins de fichiers que le nombre de tranches de cluster.

3. Optimisez COPY les commandes dans lesquelles le nombre de fichiers n'est pas un multiple du nombre de tranches de cluster.

Certaines COPY commandes chargent une quantité importante de données ou s'exécutent pendant une durée significative. Pour ces commandes, nous vous recommandons de charger un nombre d'objets de données d'Amazon S3 équivalent à un multiple du nombre de tranches présentes dans le cluster. Pour identifier le nombre d'objets S3 chargés par chaque COPY commande, exécutez le SQL code suivant en tant que superutilisateur.

SELECT
    query, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;   
            
         

Conseils d'implémentation

• Le nombre de tranches par nœud dépend de la taille de nœud du cluster. Pour plus d'informations sur le nombre de tranches dans les différents types de nœuds, consultez la rubrique Clusters et nœuds dans Amazon Redshift dans le Guide de gestion Amazon Redshift.

• Vous pouvez charger plusieurs fichiers en spécifiant un préfixe commun, ou clé de préfixe, pour l’ensemble, ou en indiquant explicitement les fichiers dans un fichier manifeste. Pour plus d'informations sur le chargement des fichiers, consultez Chargement de données à partir de fichiers compressés et non compressés.

• Amazon Redshift ne prend pas en compte la taille des fichiers lors de la répartition de la charge de travail. Fractionnez vos fichiers de données de chargement de telle sorte que les fichiers soient à peu près de taille égale, entre 1 Mo et 1 Go après compression.

Mise à jour des statistiques de table

Amazon Redshift utilise un optimiseur de requêtes basé sur les coûts pour choisir le plan d'exécution optimal des requêtes. Les estimations de coûts sont basées sur les statistiques du tableau recueillies à l'aide de la ANALYZE commande. Lorsque les statistiques sont obsolètes ou manquantes, la base de données peut choisir un plan d'exécution des requêtes moins efficace, en particulier pour les requêtes complexes. Le maintien à jour des statistiques permet d'exécuter des requêtes complexes en un temps minimal.

Analyse

L'analyse Advisor suit les tables dont les statistiques sont out-of-date ou manquantes. Elle passe en revue les métadonnées d'accès aux tables qui sont associées à des requêtes complexes. Si les tables fréquemment consultées avec des modèles complexes ne contiennent pas de statistiques, Advisor crée une recommandation critique à exécuterANALYZE. Si les tables fréquemment consultées avec des modèles complexes contiennent des out-of-date statistiques, Advisor crée une recommandation suggérée à exécuterANALYZE.

Recommandation

Chaque fois que le contenu du tableau change de manière significative, mettez à jour les statistiques avecANALYZE. Nous vous recommandons de l'exécuter ANALYZE chaque fois qu'un nombre important de nouvelles lignes de données sont chargées dans une table existante avec des INSERT commandes COPY ou. Nous recommandons également de l'exécuter ANALYZE chaque fois qu'un nombre important de lignes sont modifiées à l'aide UPDATE des DELETE commandes or. Pour identifier les tables manquantes ou out-of-date les statistiques, exécutez la SQL commande suivante en tant que superutilisateur. Les résultats sont classés de la plus grande à la plus petite table.

Pour identifier les tables manquantes ou out-of-date les statistiques, exécutez la SQL commande suivante en tant que superutilisateur. Les résultats sont classés de la plus grande à la plus petite table.

SELECT
   ti.schema||'.'||ti."table" tablename,
   ti.size table_size_mb,
   ti.stats_off statistics_accuracy
 FROM svv_table_info ti
 WHERE ti.stats_off > 5.00
 ORDER BY ti.size DESC;          
         

Conseils d'implémentation

Le ANALYZE seuil par défaut est de 10 %. Cette valeur par défaut signifie que la ANALYZE commande ignore une table donnée si moins de 10 % des lignes de la table ont changé depuis la dernièreANALYZE. Par conséquent, vous pouvez choisir d'émettre des ANALYZE commandes à la fin de chaque ETL processus. L'adoption de cette approche signifie qu'elle ANALYZE est souvent ignorée, mais garantit également qu'elle ANALYZE s'exécute en cas de besoin.

ANALYZEles statistiques ont le plus d'impact sur les colonnes utilisées dans les jointures (par exemple,JOIN tbl_a ON col_b) ou comme prédicats (par exemple,WHERE col_b = 'xyz'). Par défaut, ANALYZE collecte les statistiques pour toutes les colonnes de la table spécifiée. Si nécessaire, vous pouvez réduire le temps d'exécution ANALYZE en exécutant ANALYZE uniquement les colonnes où cela a le plus d'impact. Vous pouvez exécuter la SQL commande suivante pour identifier les colonnes utilisées comme prédicats. Vous pouvez également laisser Amazon Redshift choisir les colonnes à analyser en spécifiant ANALYZE PREDICATE COLUMNS.

WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

Pour plus d'informations, consultez Analyse des tables.

Activer l’accélération des requêtes courtes

L'accélération des requêtes courtes (SQA) donne la priorité aux requêtes de courte durée sélectionnées par rapport aux requêtes de longue durée. SQAexécute des requêtes de courte durée dans un espace dédié, de sorte que les SQA requêtes ne soient pas obligées d'attendre dans des files d'attente derrière des requêtes plus longues. SQAdonne la priorité uniquement aux requêtes de courte durée qui se trouvent dans une file d'attente définie par l'utilisateur. AvecSQA, les requêtes de courte durée commencent à s'exécuter plus rapidement et les utilisateurs voient les résultats plus rapidement.

Si vous l'activezSQA, vous pouvez réduire ou éliminer les files d'attente de gestion de la charge de travail (WLM) dédiées à l'exécution de requêtes courtes. En outre, les requêtes de longue durée n'ont pas besoin de se heurter à des requêtes courtes pour les emplacements d'une file d'attente. Vous pouvez donc configurer vos WLM files d'attente pour utiliser moins d'emplacements de requêtes. Lorsque vous utilisez une simultanéité réduite, le débit de requêtes est accru et les performances systèmes globales sont améliorées pour la plupart des charges de travail. Pour plus d'informations, consultez Utilisation de l’accélération des requêtes courtes.

Analyse

Advisor vérifie les modèles de charge de travail et indique le nombre de requêtes récentes SQA susceptibles de réduire le temps de latence ainsi que le temps d'attente quotidien pour les requêtes SQA éligibles.

Recommandation

Modifiez la WLM configuration pour l'activerSQA. Amazon Redshift utilise un algorithme de machine learning pour analyser chaque requête éligible. Les prédictions s'améliorent au fur et SQA à mesure que vous apprenez de vos modèles de requêtes. Pour plus d'informations, consultez Configuration de la gestion de la charge de travail.

Lorsque vous l'activezSQA, WLM définit le temps d'exécution maximal pour les requêtes courtes sur dynamique par défaut. Nous vous recommandons de conserver le paramètre dynamique pour SQA une durée d'exécution maximale.

Conseils d'implémentation

Pour vérifier s'il SQA est activé, exécutez la requête suivante. Si la requête renvoie une ligne, elle SQA est activée.

select * from stv_wlm_service_class_config 
where service_class = 14;

Pour de plus amples informations, veuillez consulter Surveillance SQA.

Modifier les clés de distribution sur les tables

Amazon Redshift distribue les lignes de la table dans le cluster selon le style de distribution de la table. Les tables avec KEY distribution nécessitent une colonne comme clé de distribution (DISTKEY). Une ligne de table est affectée à une tranche de nœud d'un cluster en fonction de la valeur de sa DISTKEY colonne.

Un nœud approprié DISTKEY place un nombre similaire de lignes sur chaque tranche de nœud et est fréquemment référencé dans les conditions de jointure. Une jointure optimisée se produit lorsque des tables sont jointes sur leurs DISTKEY colonnes, ce qui accélère les performances des requêtes.

Analyse

Advisor analyse la charge de travail de votre cluster afin d'identifier la clé de distribution la plus appropriée pour les tables qui peuvent bénéficier de manière significative d'un style de KEY distribution.

Recommandation

Advisor fournit des ALTER TABLE déclarations qui modifient la DISTSTYLE fin DISTKEY d'un tableau en fonction de son analyse. Pour obtenir un avantage significatif en termes de performances, veillez à implémenter toutes les SQL instructions au sein d'un groupe de recommandations.

La redistribution d'une table volumineuse ALTER TABLE consomme les ressources du cluster et nécessite des verrouillages de table temporaires à différents moments. Implémentez chaque groupe de recommandations lorsque les autres charges de travail du cluster sont légères. Pour plus d'informations sur l'optimisation des propriétés d'une distribution de table, consultez l'article Amazon Redshift Engineering's Advanced Table Design Playbook : Distribution Styles and Distribution Keys.

Pour plus d'informations sur ALTER DISTSYLE etDISTKEY, voirALTER TABLE.

Note

Si vous ne voyez pas de recommandation, cela ne signifie pas nécessairement que les styles de distribution actuels sont les plus appropriés. Advisor s'abstient de formuler des recommandations lorsqu'il n'y a pas suffisamment de données ou que les avantages escomptés de la redistribution sont faibles.

Les recommandations d'Advisor s'appliquent à une table particulière et ne s'appliquent pas nécessairement à une table contenant une colonne portant le même nom. Les tables qui partagent un nom de colonne peuvent avoir des caractéristiques différentes, à moins que les données à l'intérieur des tables soient les mêmes.

Si vous voyez des recommandations relatives aux tables intermédiaires créées ou supprimées par des ETL tâches, modifiez vos ETL processus pour utiliser les clés de distribution recommandées par Advisor.

Modification des clés de tri au niveau des tables

Amazon Redshift trie les lignes des tables en fonction de leur clé de tri. Le tri des lignes de table repose sur les valeurs des colonnes de clé de tri.

Le tri d'une table en fonction d'une clé de tri appropriée peut accélérer les performances des requêtes, en particulier celles dont les prédicats sont limités à la plage, en réduisant le nombre de blocs de table à lire à partir du disque.

Analyse

Advisor analyse la charge de travail de votre cluster sur plusieurs jours afin d'identifier une clé de tri utile pour vos tables.

Recommandation

Advisor propose deux groupes d'ALTERTABLEinstructions qui modifient la clé de tri d'une table en fonction de son analyse :

• Instructions qui modifient une table qui ne possède actuellement pas de clé de tri pour ajouter une clé de COMPOUND tri.

• Instructions qui transforment une clé de tri en clé de tri en clé INTERLEAVED de tri COMPOUND ou en absence de clé de tri.

  L'utilisation de clés de tri composé réduit de façon importante la charge de maintenance. Les tables dotées de clés de tri composées ne nécessitent pas les VACUUM REINDEX opérations coûteuses nécessaires aux tris entrelacés. En pratique, les clés de tri composées sont plus efficaces que les clés de tri entrelacées pour la grande majorité des charges de travail d'Amazon Redshift. Toutefois, si une table est petite, il est plus efficace de ne pas avoir de clé de tri pour éviter les frais généraux de stockage des clés de tri.

Lorsque vous triez une grande table avec le ALTERTABLE, les ressources du cluster sont consommées et des verrouillages de table sont nécessaires à différents moments. Mettez en œuvre chaque recommandation lorsque la charge de travail d'un cluster est modérée. Pour plus d'informations sur l'optimisation des configurations des clés de tri de table, consultez l'article Amazon Redshift Engineering's Advanced Table Design Playbook: Compound and Interleaved Sort Keys.

Pour plus d'informations sur ALTERSORTKEY, voirALTER TABLE.

Note

Si vous ne voyez pas de recommandation pour une table, cela ne signifie pas nécessairement que la configuration actuelle est la plus appropriée. Advisor s'abstient de formuler des recommandations lorsqu'il n'y a pas suffisamment de données ou que les avantages escomptés du tri sont faibles.

Les recommandations d'Advisor s'appliquent à une table particulière et pas nécessairement à une table contenant une colonne présentant les mêmes nom et type de données. Les tables qui partagent des noms de colonne peuvent faire l'objet de recommandations différentes en fonction de leurs données et de la charge de travail.

Modifier les encodages de compression sur les colonnes

La compression est une opération au niveau des colonnes qui réduit la taille des données lorsque celles-ci sont stockées. La compression est utilisée dans Amazon Redshift pour conserver l'espace de stockage et améliorer les performances des requêtes en réduisant la quantité des I/O sur le disque. Nous recommandons un encodage de compression optimal pour chaque colonne en fonction de son type de données et des modèles de requête. Avec une compression optimale, les requêtes peuvent s'exécuter plus efficacement et la base de données peut occuper un espace de stockage minimal.

Analyse

Advisor analyse en permanence la charge de travail de votre cluster et le schéma de la base de données afin d'identifier l'encodage de compression optimal pour chaque colonne de la table.

Recommandation

Advisor fournit des ALTER TABLE instructions qui modifient le codage de compression de colonnes spécifiques, en fonction de son analyse.

Le changement des encodages de compression des colonnes avec ALTER TABLE consomme des ressources du cluster et nécessite des verrous de table à différents moments. Il est préférable de mettre en œuvre les recommandations lorsque la charge de travail du cluster est légère.

Pour référence, ALTERTABLEexemples présente plusieurs instructions qui modifient l'encodage d'une colonne.

Note

Advisor s'abstient de formuler des recommandations lorsqu'il n'y a pas assez de données ou que le bénéfice attendu d'un changement de codage est faible.

Recommandations sur les types de données

Amazon Redshift possède une bibliothèque de types de SQL données pour différents cas d'utilisation. Il s'agit notamment de types entiers comme INT et de types destinés à stocker des personnages, comme VARCHAR. Redshift stocke les types de manière optimisée afin de fournir un accès rapide et de bonnes performances de requête. De plus, Redshift fournit des fonctions pour des types spécifiques, que vous pouvez utiliser pour formater ou effectuer des calculs sur des résultats de requête.

Analyse

Advisor analyse en permanence la charge de travail de votre cluster et le schéma de la base de données afin d'identifier les colonnes susceptibles de bénéficier considérablement d'un changement de type de données.

Recommandation

Advisor fournit une instruction ALTER TABLE qui ajoute une nouvelle colonne avec le type de données suggéré. Une instruction UPDATE d'accompagnement copie les données de la colonne existante vers la nouvelle colonne. Après avoir créé la nouvelle colonne et chargé les données, modifiez vos requêtes et vos scripts d'ingestion pour accéder à la nouvelle colonne. Exploitez ensuite les fonctionnalités et fonctions spécialisées dans le nouveau type de données, que l'on trouve dans SQLréférence des fonctions.

La copie de données existantes dans la nouvelle colonne peut prendre du temps. Nous vous recommandons d'implémenter chaque recommandation d'Advisor lorsque la charge de travail du cluster est légère. Consultez la liste des types de données disponibles à l'adresse Types de données.

Notez qu'Advisor s'abstient de formuler des recommandations lorsqu'il n'y a pas assez de données ou que le bénéfice attendu d'un changement de type de données est faible.