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 SQL 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 mettant en évidence les similitudes et les différences par rapport à PostgreSQL. Nous aborderons les différents types d'opérations de scan disponibles dans Aurora DSQL et vous aiderons à comprendre le coût de l'exécution de vos requêtes.
Plans PostgreSQL VS Aurora DSQL EXPLAIN
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 majeures qui ont une incidence sur 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 table |
L'index de clé primaire est la table avec toutes les colonnes supplémentaires sous forme de colonnes INCLUDE |
|
Index secondaires |
Index 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'index, filtre en tas |
État de l'index, filtre de stockage, filtre du processeur de requêtes |
|
Types d’analyse |
Numérisation séquentielle, analyse de l'index, analyse de l'index uniquement |
Scan complet, scan de l'index uniquement, scan de l'index |
|
Exécution de requêtes |
Local dans 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 séparé. 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 scans d'index uniquement dans les cas où PostgreSQL choisit un scan séquentiel.
Autre distinction essentielle : 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.
Éléments clés des plans Aurora SQL 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 Condo
Conditions utilisées pour naviguer dans l'index. Filtrage le plus efficace qui réduit les données numérisé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 une surcharge 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'indice |
Appliqué lors de la numérisation de l'index. Limite la quantité de données lues depuis le stockage et réduit le nombre de 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. Voici un exemple de 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 le temps de latence et les coûts. À l'heure actuelle, Aurora DSQL ne peut pas effectuer toutes les opérations de filtrage et de projection sur le stockage. Certaines requêtes peuvent donc être obligées de recourir à ce type de filtrage. |
