Requêtes parallèles pour Amazon Aurora MySQL - Amazon Aurora
Présentation des requêtes parallèles

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 via les requêtes parallèles pour Édition compatible avec Amazon Aurora MySQL. 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.

Rubriques

Présentation des requêtes parallèles pour Aurora MySQL

Une requête parallèle Aurora MySQL est une optimisation qui met en parallèle une partie des I/O et du calcul impliqués dans le traitement des requêtes à usage intensif de 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 pools 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.

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 :

  • Amélioration des performances des I/O grâce à la mise en parallèle des requêtes de type « physical read » 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 pool de mémoires tampons. Les pages traitées par la requête parallèle ne sont pas ajoutées au pool 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 pool 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 une requête parallèle, une grande partie des tâches impliquant un usage intensif de l’UC et un grand nombre d’I/O 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’amélioration des performances découle de la réduction du trafic réseau, d’une utilisation moindre de l’UC au niveau du nœud principal et de la mise en parallèle des I/O entre les nœuds de stockage. Le volume d’I/O parallèles, de filtrage et de projection n’est pas lié au nombre d’instances de base de données du cluster Aurora qui exécute la requête.

Prérequis

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, 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.

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.

  • 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. 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 fonction de requêtes parallèles est disponible dans toutes les Régions AWS prises en charge par Aurora. Pour la plupart des Régions AWS, la version minimale requise d’Aurora MySQL pour utiliser les requêtes parallèles 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.

Coûts d’E/S liés aux requêtes parallèles

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 pool 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 coûts d’E/S 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. Les coûts d’E/S potentiellement plus élevés liés aux requêtes parallèles peuvent s’expliquer par deux raisons :

  • 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 analysées au niveau de la couche de stockage, ce qui entraîne des coûts d’E/S.

  • L’exécution d’une requête parallèle ne réchauffe pas le pool de mémoire tampon. Par conséquent, les exécutions consécutives de la même requête parallèle entraînent le coût intégral des E/S.