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. # Requêtes parallèles pour Amazon Aurora MySQL Cette rubrique décrit l'optimisation des performances des requêtes parallèles pour Amazon Aurora MySQL-Compatible Edition. Cette fonction utilise un chemin de traitement spécial pour certaines requêtes à usage intensif de données, en tirant parti de l’architecture de stockage partagé d’Aurora. Les requêtes parallèles sont conçues pour les clusters de bases de données Aurora MySQL dont les tables contiennent des millions de lignes et dont le traitement des requêtes analytiques dure plusieurs minutes, voire plusieurs heures. **Topics** + [Présentation des requêtes parallèles pour Aurora MySQL](#aurora-mysql-parallel-query-overview) + [Création d’un cluster de bases de données de requêtes parallèles dans Aurora MySQL](aurora-mysql-parallel-query-creating-cluster.md) + [Activation et désactivation des requêtes parallèles dans Aurora MySQL](aurora-mysql-parallel-query-enabling.md) + [Optimisation des requêtes parallèles dans Aurora MySQL](aurora-mysql-parallel-query-optimizing.md) + [Vérification des instructions utilisant les requêtes parallèles pour Aurora MySQL](aurora-mysql-parallel-query-verifying.md) + [Surveillance des requêtes parallèles pour Aurora MySQL](aurora-mysql-parallel-query-monitoring.md) + [Constructions SQL pour les requêtes parallèles dans Aurora MySQL](aurora-mysql-parallel-query-sql.md) ## Présentation des requêtes parallèles pour Aurora MySQL La requête parallèle Aurora MySQL est une optimisation qui parallélise une partie des calculs impliqués dans le traitement I/O des requêtes gourmandes en données. Les tâches qui sont mises en parallèle incluent la récupération des lignes à partir du stockage, l’extraction des valeurs des colonnes et la détermination des lignes répondant aux conditions définies dans la clause `WHERE` et dans les clauses JOIN. Ces tâches de gestion des gros volumes de données sont déléguées à différents nœuds de la couche de stockage distribué Aurora. Dans le jargon, on parle également d’optimisation de base de données par *pushdown*. Sans la fonction de requête parallèle, chaque requête envoie toutes les données analysées à un même nœud au sein du cluster Aurora MySQL (le nœud principal) et y effectue toutes les tâches de traitement nécessaires. **Astuce** Le moteur de base de données PostgreSQL possède également une fonction appelée « requête parallèle ». Cette fonction n’est pas liée à la requête parallèle Aurora. Lorsque la fonction de requête parallèle est activée, le moteur Aurora MySQL détermine automatiquement quand utiliser cette dernière, sans nécessiter de modifications SQL telles que les indicateurs ou les attributs de table. Dans les sections suivantes, vous découvrirez dans quels cas une requête parallèle est appliquée. Vous découvrirez également comment vous assurer qu’une requête parallèle est appliquée là où il faut. **Note** L’optimisation via des requêtes parallèles est destinée aux requêtes de longue durée dont le traitement prend entre quelques minutes et plusieurs heures. Aurora MySQL n’a généralement pas recours à cette fonction pour des requêtes peu coûteuses. Il n’effectue généralement pas d’optimisation de requête parallèle si une autre technique d’optimisation est plus logique, telle que la mise en cache de requêtes, la mise en cache de groupes de mémoires tampons ou les recherches d’index. Si vous constatez que la requête parallèle n’est pas déclenchée lorsqu’elle le devrait, consultez [Vérification des instructions utilisant les requêtes parallèles pour Aurora MySQL](aurora-mysql-parallel-query-verifying.md). **Topics** + [Avantages](#aurora-mysql-parallel-query-benefits) + [Architecture](#aurora-mysql-parallel-query-architecture) + [Conditions préalables](#aurora-mysql-parallel-query-prereqs) + [Limitations](#aurora-mysql-parallel-query-limitations) + [I/O coûts liés à une requête parallèle](#aurora-mysql-parallel-query-cost) ### Avantages Avec la requête parallèle, vous pouvez exécuter des requêtes analytiques à grand volume de données sur des tables Aurora MySQL. Dans de nombreux cas, l’amélioration des performances est significative par rapport au traitement traditionnel des requêtes. Voici certains des avantages des requêtes parallèles : + I/O Performances améliorées grâce à la parallélisation des demandes de lecture physiques sur plusieurs nœuds de stockage. + Trafic réseau réduit. Aurora ne transmet pas de pages de données entières des nœuds de stockage au nœud principal, et ne filtre pas les lignes et colonnes superflues par la suite. Au lieu de cela, Aurora transmet des tuples compacts contenant uniquement les valeurs de colonne requises pour le jeu de résultats. + Réduction de l’utilisation de l’UC au niveau du nœud principal grâce au traitement de la fonction « pushdown », au filtrage des lignes et à la projection des colonnes pour la clause `WHERE`. + Sollicitation moindre de la mémoire au niveau du groupe de mémoires tampons. Les pages traitées par la requête parallèle ne sont pas ajoutées au groupe de mémoires tampons. Cette approche réduit les risques qu’une analyse à grand volume de données expulse les données fréquemment utilisées du groupe de mémoires tampons. + Réduction potentielle de la duplication des données dans le pipeline ETL (extract, transform, load) grâce à l’exécution, plus pratique, des requêtes analytiques de longue durée au niveau des données existantes. ### Architecture La fonction de requêtes parallèles repose sur les principes architecturaux clés d’Aurora MySQL : découplage du moteur de base de données du sous-système de stockage et réduction du trafic via la rationalisation des protocoles de communication. Aurora MySQL utilise ces techniques pour accélérer les opérations impliquant un grand nombre d’écritures, telles que le traitement des journaux redo. Les requêtes parallèles appliquent les mêmes principes aux opérations de lecture. **Note** L’architecture des requêtes parallèles Aurora MySQL diffère de celle des fonctions dont le nom est similaire dans les autres systèmes de base de données. Les requêtes parallèles Aurora MySQL n’impliquent pas de multitraitement symétrique et ne dépendent donc pas de la capacité d’UC du serveur de base de données. Le traitement parallèle intervient dans la couche de stockage, indépendamment du serveur Aurora MySQL qui joue le rôle de coordinateur de requêtes. Par défaut, sans requête parallèle, le traitement d’une requête Aurora inclut la transmission des données brutes à un même nœud au sein du cluster Aurora (*nœud principal*). Aurora exécute ensuite toutes les autres tâches nécessaires pour cette requête dans un seul thread sur de ce nœud unique. Avec les requêtes parallèles, une grande partie de cette CPU-intensive tâche I/O-intensive et du travail est déléguée aux nœuds de la couche de stockage. Seules les lignes compactes du jeu de résultats sont renvoyées au nœud principal, avec les lignes déjà filtrées et les valeurs de colonne déjà extraites et transformées. L'avantage en termes de performances provient de la réduction du trafic réseau, de la réduction de l'utilisation du processeur sur le nœud principal et de la parallélisation I/O entre les nœuds de stockage. La quantité de parallélisme I/O, de filtrage et de projection est indépendante du nombre d'instances de base de données dans le cluster Aurora qui exécute la requête. ### Conditions préalables Pour pouvoir utiliser toutes les fonctionnalités des requêtes parallèles, vous avez besoin d’un cluster de bases de données Aurora MySQL qui exécute la version 2.09 ou une version ultérieure. Si vous avez déjà un cluster que vous souhaitez utiliser avec une requête parallèle, vous pouvez le mettre à niveau vers une version compatible et activer la requête parallèle par la suite. Dans ce cas, assurez-vous de suivre la procédure de mise à niveau décrite dans [Considérations relatives aux mises à niveau pour les requêtes parallèles](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade), car les noms de paramètre de configuration et les valeurs par défaut sont différents dans ces versions plus récentes. Les instances de base de données de votre cluster doivent utiliser les classes d’instance `db.r*`. Assurez-vous que l’optimisation de jointure par hachage est activée pour votre cluster. Pour savoir comment procéder, consultez [Activation de la jointure par hachage pour les clusters de requête parallèle](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join). Pour personnaliser des paramètres tels que `aurora_parallel_query` et `aurora_disable_hash_join`, vous devez disposer d’un groupe de paramètres personnalisés que vous utilisez avec votre cluster. Vous pouvez spécifier ces paramètres individuellement pour chaque instance de base de données à l’aide d’un groupe de paramètres de base de données. Toutefois, nous vous recommandons de les spécifier dans un groupe de paramètres de cluster de bases de données. De cette façon, toutes les instances de base de données de votre cluster héritent des mêmes choix pour ces paramètres. ### Limitations Les limitations suivantes s’appliquent à la fonction de requête parallèle : + La requête parallèle n’est pas prise en charge avec la configuration de stockage du cluster de bases de données Aurora I/O-Optimized. + Vous ne pouvez pas utiliser les requêtes parallèles avec les classes d’instance db.t2 ou db.t3. Cette limite s’applique même si vous demandez une requête parallèle en utilisant la variable de session `aurora_pq_force`. + La requête parallèle ne s’applique pas aux tables utilisant les formats de ligne `COMPRESSED` ou `REDUNDANT`. Utilisez les formats de ligne `COMPACT` ou `DYNAMIC` pour les tables que vous prévoyez d’utiliser avec une requête parallèle. + Aurora utilise un algorithme basé sur les coûts pour déterminer si le mécanisme de requête parallèle doit être utilisé pour chaque instruction SQL. L’utilisation de certaines constructions SQL dans une instruction peut empêcher la requête parallèle ou rendre celle-ci peu probable pour cette instruction. Pour plus d’informations sur la compatibilité des constructions SQL avec une requête parallèle, consultez [Constructions SQL pour les requêtes parallèles dans Aurora MySQL](aurora-mysql-parallel-query-sql.md). + Chaque instance de base de données Aurora ne peut exécuter qu’un nombre spécifique de sessions de requêtes parallèles à la fois. Si une requête inclut plusieurs parties utilisant une requête parallèle, telles que des sous-requêtes, des clauses JOIN ou des opérateurs `UNION`, ces expressions sont exécutées les unes à la suite des autres. L’instruction n’est considérée que comme une seule session de requête parallèle. Vous pouvez surveiller le nombre de sessions actives via les [variables d’état des requêtes parallèles](aurora-mysql-parallel-query-monitoring.md). Pour vérifier le nombre limite de sessions simultanées pour une instance de base de données déterminée, interrogez la variable de statut `Aurora_pq_max_concurrent_requests`. + La requête parallèle est disponible dans tous les appareils Régions AWS pris en charge par Aurora. Dans la plupart des cas Régions AWS, la version minimale requise d'Aurora MySQL pour utiliser une requête parallèle est 2.09. + La requête parallèle est conçue pour améliorer les performances des requêtes gourmandes en données. Elle n’est pas conçue pour les requêtes courtes. + Nous vous recommandons d’utiliser des nœuds de lecteur pour les instructions SELECT, en particulier pour les instructions gourmandes en données. ### I/O coûts liés à une requête parallèle Si votre cluster Aurora MySQL utilise une requête parallèle, vous pouvez voir une augmentation des valeurs d’`VolumeReadIOPS`. Les requêtes parallèles n’utilisent pas le groupe de mémoires tampons. Ainsi, bien que les requêtes soient rapides, ce traitement optimisé peut entraîner une augmentation des opérations de lecture et des frais associés. Les I/O coûts des requêtes parallèles pour votre requête sont mesurés au niveau de la couche de stockage et seront identiques ou supérieurs si la requête parallèle est activée. Votre avantage réside dans l’amélioration des performances des requêtes. Deux raisons peuvent expliquer les I/O coûts potentiellement plus élevés associés aux requêtes parallèles : + Même si certaines données d'une table se trouvent dans le pool de mémoire tampon, la requête parallèle nécessite que toutes les données soient scannées au niveau de la couche de stockage, ce qui entraîne des coûts I/O . + L’exécution d’une requête parallèle ne réchauffe pas le groupe de mémoires tampons. Par conséquent, les exécutions consécutives d'une même requête parallèle entraînent le I/O coût total.