Requête parallèle pour Amazon Aurora My SQL - 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ête parallèle pour Amazon Aurora My SQL

Cette rubrique décrit l'optimisation des performances des requêtes parallèles pour Amazon Aurora My SQL -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. La requête parallèle fonctionne mieux avec les clusters Aurora My SQL DB qui comportent des tables comportant des millions de lignes et des requêtes analytiques dont l'exécution prend des minutes ou des heures.

Rubriques

Vue d'ensemble de la requête parallèle pour Aurora My SQL

Aurora My SQL parallel query est une optimisation qui parallélise certaines des E/S et des calculs nécessaires au traitement 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 requête parallèle, chaque requête rassemble toutes les données numérisées vers un seul nœud du SQL cluster Aurora My (le nœud principal) et y exécute tout le traitement des requêtes.

Astuce

Le moteur SQL de base de données Postgre possède également une fonctionnalité appelée « requête parallèle ». Cette fonction n'est pas liée à la requête parallèle Aurora.

Lorsque la fonctionnalité de requête parallèle est activée, le SQL moteur Aurora My détermine automatiquement dans quels cas les requêtes peuvent en bénéficier, sans nécessiter de SQL modifications telles que des indications ou des 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 My n'effectue SQL généralement pas d'optimisation des requêtes parallèles pour les 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, veuillez consulter Vérifier quelles instructions utilisent une requête parallèle pour Aurora My SQL.

Avantages

Avec la requête parallèle, vous pouvez exécuter des requêtes analytiques gourmandes en données sur les tables Aurora MySQL. Dans de nombreux cas, vous pouvez obtenir une amélioration order-of-magnitude des performances par rapport à la division traditionnelle du travail pour le traitement 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 CPU l'utilisation sur le nœud principal, en raison de la réduction du traitement des fonctions, du filtrage des lignes et de la projection des colonnes pour la WHERE clause.

  • 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 votre pipeline d'extraction, de transformation, de chargement (ETL), en simplifiant l'exécution de requêtes analytiques de longue durée sur des données existantes.

Architecture

La fonctionnalité de requête parallèle utilise les grands principes architecturaux d'Aurora My SQL : découpler le moteur de base de données du sous-système de stockage et réduire le trafic réseau en rationalisant les protocoles de communication. Aurora My SQL utilise ces techniques pour accélérer les opérations nécessitant beaucoup d'écriture, telles que le traitement du redo log. Les requêtes parallèles appliquent les mêmes principes aux opérations de lecture.

Note

L'architecture d'Aurora My SQL parallel query est différente de celle des fonctionnalités portant le même nom dans d'autres systèmes de base de données. Aurora My SQL parallel query n'implique pas de multitraitement symétrique (SMP) et ne dépend donc pas de la CPU capacité du serveur de base de données. Le traitement parallèle s'effectue dans la couche de stockage, indépendamment du SQL serveur Aurora My qui sert de coordinateur des 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 ce travail CPU intensif en E/S 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 CPU l'utilisation sur le nœud principal et de la parallélisation des E/S sur 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 utiliser toutes les fonctionnalités de la requête parallèle, vous devez disposer d'un cluster Aurora My SQL DB exécutant la version 2.09 ou supé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 base 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.

Limites

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 s'il convient d'utiliser le mécanisme de requête parallèle pour chaque SQL instruction. L'utilisation de certaines SQL constructions dans une instruction peut empêcher une requête parallèle ou rendre une requête parallèle improbable pour cette instruction. Pour plus d'informations sur la compatibilité des SQL constructions avec les requêtes parallèles, consultezSQLconstructions pour les requêtes parallèles dans Aurora My SQL.

  • 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 de statut 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 requête parallèle est disponible dans toutes les AWS régions prises en charge par Aurora. Pour la plupart des AWS régions, la SQL version minimale requise d'Aurora My 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 lecture pour les SELECT instructions, en particulier pour les instructions gourmandes en données.

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

Si votre SQL cluster Aurora My utilise une requête parallèle, vous constaterez peut-être une augmentation VolumeReadIOPS des valeurs. 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.