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.
Utilisation des plans Aurora DSQL EXPLAIN
Aurora DSQL utilise une structure de plan EXPLAIN similaire à celle de PostgreSQL, mais avec des ajouts clés qui reflètent son architecture distribuée et son modèle d'exécution.
Dans cette documentation, nous allons fournir un aperçu des plans Aurora DSQL EXPLAIN, en soulignant les similitudes et les différences par rapport à PostgreSQL. Nous aborderons les différents types d'opérations de numérisation disponibles dans Aurora DSQL et vous aiderons à comprendre le coût de l'exécution de vos requêtes.
Les plans d'explication de PostgreSQL contre Aurora DSQL
Aurora DSQL repose sur la base de données PostgreSQL et partage la plupart des structures de plan avec PostgreSQL, mais présente des différences architecturales clés qui affectent l'exécution et l'optimisation des requêtes :
| Fonctionnalité | PostgreSQL | Aurora DSQL |
|---|---|---|
|
Stockage des données |
Stockage en tas |
Pas de tas, toutes les lignes sont indexées par un identifiant unique |
|
Clé primaire |
L'index de clé primaire est distinct des données de la table |
L'index de clé primaire est le tableau avec toutes les colonnes supplémentaires sous forme de colonnes INCLUDE |
|
Index secondaires |
Indices secondaires standard |
Fonctionne de la même manière que PostgreSQL, avec la possibilité d'inclure des colonnes non clés |
|
Capacités de filtrage |
État de l'indice, filtre Heap |
État de l'index, filtre de stockage, filtre du processeur de requêtes |
|
Types d’analyse |
Balayage séquentiel, scan d'index, scan d'index uniquement |
Numérisation complète, Analyse de l'index uniquement, Analyse de l'index |
|
Exécution de requêtes |
Local à la base de données |
Distribué (le calcul et le stockage sont séparés) |
Aurora DSQL stocke les données des tables directement dans l'ordre des clés primaires plutôt que dans un tas distinct. Chaque ligne est identifiée par une clé unique, généralement la clé primaire, qui permet à la base de données d'optimiser les recherches de manière plus efficace. Cette différence architecturale explique pourquoi Aurora DSQL utilise souvent des analyses d'index uniquement dans les cas où PostgreSQL choisit un scan séquentiel.
Une autre distinction essentielle est qu'Aurora DSQL sépare le calcul du stockage, ce qui permet d'appliquer des filtres plus tôt dans le processus d'exécution afin de réduire le mouvement des données et d'améliorer les performances.
Pour en savoir plus sur l'utilisation des plans EXPLAIN avec PostgreSQL, consultez la documentation PostgreSQL EXPLAIN.
Principaux éléments des plans Aurora DSQL EXPLAIN
Les plans Aurora DSQL EXPLAIN fournissent des informations détaillées sur la manière dont les requêtes sont exécutées, notamment sur l'emplacement du filtrage et sur les colonnes extraites du stockage. La compréhension de ce résultat vous permet d'optimiser les performances des requêtes.
- Indice Cond
Conditions utilisées pour naviguer dans l'index. Le filtrage le plus efficace qui réduit le nombre de données scannées. Dans Aurora DSQL, les conditions d'index peuvent être appliquées à plusieurs couches du plan d'exécution.
- Projections
Colonnes extraites du stockage. Moins de projections sont synonymes de meilleures performances.
- Filtre de stockage
Conditions appliquées au niveau du stockage. Plus efficace que les filtres du processeur de requêtes.
- Filtre du processeur de requêtes
-
Conditions appliquées au niveau du processeur de requêtes. Nécessite le transfert de toutes les données avant le filtrage, ce qui entraîne une augmentation des mouvements de données et des frais de traitement.
Filtres dans Aurora DSQL
Aurora DSQL sépare le calcul du stockage, ce qui signifie que le moment où les filtres sont appliqués pendant l'exécution des requêtes a un impact significatif sur les performances. Les filtres appliqués avant le transfert de gros volumes de données réduisent la latence et améliorent l'efficacité. Plus un filtre est appliqué tôt, moins les données doivent être traitées, déplacées et numérisées, ce qui accélère les requêtes.
Aurora DSQL peut appliquer des filtres à plusieurs étapes du chemin de requête. Il est essentiel de comprendre ces étapes pour interpréter les plans de requêtes et optimiser les performances.
| Niveau | Type de filtre | Description |
|---|---|---|
| 1 | État de l'index |
Appliqué lors de la numérisation de l'index. Limite la quantité de données lues depuis le stockage et réduit les données envoyées à la couche de calcul. |
| 2 | Filtre de stockage | Appliqué après la lecture des données depuis le stockage, mais avant leur envoi au calcul. Un exemple est un filtre sur une colonne d'inclusion d'un index. Réduit le transfert de données mais pas la quantité lue. |
| 3 | Filtre du processeur de requêtes | Appliqué une fois que les données ont atteint la couche de calcul. Toutes les données doivent d'abord être transférées, ce qui augmente la latence et les coûts. Aurora DSQL ne peut actuellement pas effectuer toutes les opérations de filtrage et de projection sur le stockage. Certaines requêtes peuvent donc être obligées de revenir à ce type de filtrage. |
