Performance

Amazon Redshift assure une exécution extrêmement rapide des requêtes en utilisant ces fonctions de performance.

Traitement massivement parallèle

Le traitement massivement parallèle (MPP) permet l’exécution rapide des requêtes les plus complexes œuvrant sur de grandes quantités de données. Plusieurs nœuds de calcul gèrent tout le traitement des requêtes conduisant à l’agrégation du résultat final, avec chaque cœur de chaque nœud exécutant les mêmes segments de requêtes compilés sur des parties de l’ensemble des données.

Amazon Redshift distribue les lignes d’une table aux différents nœuds de calcul afin que les données puissent être traitées en parallèle. En sélectionnant une clé de distribution appropriée pour chaque table, vous pouvez optimiser la distribution des données pour équilibrer l’application et réduire le mouvement de données d’un nœud à un autre. Pour plus d'informations, consultez Choisir le meilleur style de distribution.

Le chargement de données à partir de fichiers plats tire parti du traitement en répartissant la charge de travail entre plusieurs nœuds, tout en assurant des lectures simultanées à partir de plusieurs fichiers. Pour plus d’informations sur le chargement des données dans les tables, consultez Bonnes pratiques de chargement des données sur Amazon Redshift.

Stockage des données en colonnes

Le stockage en colonnes des tables de base de données réduit considérablement les exigences globales d’I/O disque et constitue un facteur important dans l’optimisation des performances des requêtes analytiques. Le stockage des informations de table de base de données en mode colonnes réduit le nombre de requêtes d’I/O disque, ainsi que la quantité de données que vous devez charger depuis le disque. Le fait de charger moins de données en mémoire permet à Amazon Redshift d’effectuer davantage de traitement en mémoire lors de l’exécution des requêtes. Consultez Stockage en colonnes pour une description plus détaillée.

Lorsque les colonnes sont triées de manière adéquate, le processeur de requêtes est capable de filtrer rapidement un large sous-ensemble de blocs de données. Pour plus d'informations, consultez Choix de la meilleure clé de tri.

Compression des données

La compression des données réduit les besoins en stockage et, de ce fait, les I/O disque, ce qui améliore les performances des requêtes. Lorsque vous exécutez une requête, les données compressées sont lues en mémoire, puis décompressées au cours de l’exécution des requêtes. Le fait de charger moins de données en mémoire permet à Amazon Redshift d’allouer plus de mémoire à l’analyse des données. Comme le stockage en colonnes stocke des données similaires de manière séquentielle, Amazon Redshift est en mesure d’appliquer des encodages de compression adaptatifs spécifiquement liés aux types de données en colonnes. Le meilleur moyen d’activer la compression des données sur les colonnes de la table est de permettre à Amazon Redshift d’appliquer des encodages de compression optimaux lorsque vous chargez la table avec des données. Pour en savoir plus sur l’utilisation de la compression automatique des données, consultez Chargement des tables avec compression automatique.

Optimiseur de requête

Le moteur d’exécution des requêtes Amazon Redshift intègre un optimiseur de requête qui prend en charge le traitement hautement parallèle et tire aussi parti du stockage de données orienté colonnes. L’optimiseur de requête Amazon Redshift met en œuvre des améliorations et des extensions importantes pour le traitement des requêtes analytiques complexes qui incluent souvent les jointures de plusieurs tables, les sous-requêtes et l’agrégation. Pour en savoir plus sur l’optimisation des requêtes, consultez Réglage de performances des requêtes.

Mise en cache du résultat

Pour raccourcir le temps d’exécution des requêtes et améliorer les performances du système, Amazon Redshift met en cache le résultat de certains types de requêtes dans la mémoire du nœud principal. Quand un utilisateur envoie une requête, Amazon Redshift recherche une copie valide du résultat de la requête dans le cache. Si une correspondance est trouvée dans le cache des résultats, Amazon Redshift utilise les résultats mis en cache et n’exécute pas la requête. La mise en cache du résultat est totalement transparente pour l’utilisateur.

La mise en cache du résultat est activée par défaut. Pour désactiver la mise en cache du résultat sur la séance en cours, définissez le paramètre de configuration enable_result_cache_for_session sur off.

Amazon Redshift utilise les résultats mis en cache quand il reçoit une nouvelle requête si l’ensemble des conditions suivantes sont satisfaites :

• L’utilisateur qui soumet la requête a des autorisations d’accès sur les objets concernés par la requête.

• La table ou les vues incluses dans la requête n’ont pas été modifiées.

• La requête n’utilise pas une fonction qui nécessite une évaluation à chaque exécution (ex. : GETDATE).

• La requête ne fait pas référence à des tables externes Amazon Redshift Spectrum.

• Les paramètres de configuration qui pourraient affecter le résultat de la requête n’ont pas été modifiés.

• La syntaxe de la requête correspond à celle mise en cache.

Pour maximiser l’efficacité du cache et l’utilisation efficace des ressources, Amazon Redshift ne met pas en cache certains grands ensembles de résultats de requêtes. Amazon Redshift détermine s’il faut mettre en cache les résultats des requêtes en fonction d’un certain nombre de facteurs. Le nombre d’entrées en cache et le type d’instance de votre cluster Amazon Redshift entrent notamment en jeu.

Pour savoir si une requête exploite le cache de résultats, interrogez la vue système SVL_QLOG. Si la requête utilise le cache de résultats, la colonne source_query indique l’ID de la requête source. Si la mise en cache n’a pas été utilisée, la valeur indiquée est NULL.

L’exemple suivant montre que les requêtes soumises par les ID utilisateur 104 et 102 exploitent les résultats en cache des requêtes exécutées par l’ID utilisateur 100.

select userid, query, elapsed, source_query from svl_qlog 
where userid > 1
order by query desc;

userid | query  | elapsed  | source_query
-------+--------+----------+-------------
   104 | 629035 |       27 |       628919
   104 | 629034 |       60 |       628900
   104 | 629033 |       23 |       628891
   102 | 629017 |  1229393 |             
   102 | 628942 |       28 |       628919
   102 | 628941 |       57 |       628900
   102 | 628940 |       26 |       628891
   100 | 628919 | 84295686 |             
   100 | 628900 | 87015637 |             
   100 | 628891 | 58808694 |             

Code compilé

Le nœud principal répartit le code compilé entièrement optimisé entre tous les nœuds d’un cluster. La compilation de la requête réduit le traitement associé à un interpréteur et, par conséquent, augmente la vitesse d’exécution, en particulier pour les requêtes complexes. Le code compilé est mis en cache et partagé entre les séances du même cluster. Par conséquent, les exécutions futures de la même requête seront plus rapides, souvent même avec des paramètres différents.

Le moteur d’exécution de requête compile un code différent pour les protocoles de connexion JDBC et ODBC, si bien que deux clients utilisant chacun un protocole différent supportent le coût initial de compilation du code. En revanche, les clients qui utilisent le même protocole bénéficient du partage du code mis en cache.