Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo dei piani Aurora DSQL EXPLAIN
Aurora DSQL utilizza una struttura del piano EXPLAIN simile a PostgreSQL, ma con aggiunte chiave che riflettono l'architettura distribuita e il modello di esecuzione.
In questa documentazione, forniremo una panoramica dei piani di Aurora DSQL EXPLAIN, evidenziando le somiglianze e le differenze rispetto a PostgreSQL. Tratteremo i vari tipi di operazioni di scansione disponibili in Aurora DSQL e ti aiuteremo a comprendere i costi di esecuzione delle tue query.
Piani EXPLAIN di PostgreSQL VS Aurora DSQL
Aurora DSQL si basa sul database PostgreSQL e condivide la maggior parte delle strutture del piano con PostgreSQL, ma presenta differenze architettoniche chiave che influiscono sull'esecuzione e l'ottimizzazione delle query:
| Funzionalità | PostgreSQL | Aurora DSQL |
|---|---|---|
|
Storage dei dati |
Archiviazione Heap |
Nessun heap, tutte le righe sono indicizzate da un identificatore univoco |
|
Chiave primaria |
L'indice della chiave primaria è separato dai dati della tabella |
L'indice della chiave primaria è la tabella con tutte le colonne aggiuntive come colonne INCLUDE |
|
Indici secondari |
Indici secondari standard |
Funziona come PostgreSQL, con la possibilità di includere colonne non chiave |
|
Funzionalità di filtraggio |
Condizione dell'indice, filtro Heap |
Condizione dell'indice, filtro di archiviazione, filtro del processore di query |
|
Tipi di scansione |
Scansione sequenziale, scansione dell'indice, scansione solo dell'indice |
Scansione completa, scansione solo indice, scansione indice |
|
Esecuzione della query |
Locale al database |
Distribuito (elaborazione e archiviazione sono separati) |
Aurora DSQL archivia i dati della tabella direttamente nell'ordine della chiave primaria anziché in un heap separato. Ogni riga è identificata da una chiave univoca, in genere la chiave primaria, che consente al database di ottimizzare le ricerche in modo più efficiente. La differenza architetturale spiega perché Aurora DSQL utilizza spesso le scansioni Index Only nei casi in cui PostgreSQL potrebbe scegliere una scansione sequenziale.
Un'altra differenza fondamentale è che Aurora DSQL separa l'elaborazione dallo storage, consentendo l'applicazione di filtri nelle fasi iniziali del percorso di esecuzione per ridurre lo spostamento dei dati e migliorare le prestazioni.
Elementi chiave dei piani Aurora DSQL EXPLAIN
I piani Aurora DSQL EXPLAIN forniscono informazioni dettagliate su come vengono eseguite le query, incluso dove avviene il filtraggio e quali colonne vengono recuperate dallo storage. La comprensione di questo risultato consente di ottimizzare le prestazioni delle query.
- Index Cond
Condizioni utilizzate per navigare nell'indice. Filtraggio più efficiente che riduce i dati scansionati. In Aurora DSQL, le condizioni dell'indice possono essere applicate a più livelli del piano di esecuzione.
- Proiezioni
Colonne recuperate dalla memorizzazione. Un numero inferiore di proiezioni significa prestazioni migliori.
- Filtro di archiviazione
Condizioni applicate a livello di archiviazione. Più efficiente dei filtri del processore di query.
- Filtro del processore di query
-
Condizioni applicate a livello di processore di query. Richiede il trasferimento di tutti i dati prima del filtraggio, il che comporta un maggiore spostamento dei dati e un sovraccarico di elaborazione.
Filtri in Aurora DSQL
Aurora DSQL separa l'elaborazione dallo storage, il che significa che il punto in cui vengono applicati i filtri durante l'esecuzione delle query ha un impatto significativo sulle prestazioni. I filtri applicati prima del trasferimento di grandi volumi di dati riducono la latenza e migliorano l'efficienza. Quanto prima viene applicato un filtro, tanto meno dati devono essere elaborati, spostati e scansionati, con conseguenti query più rapide.
Aurora DSQL può applicare filtri in più fasi del percorso della query. La comprensione di queste fasi è fondamentale per interpretare i piani di interrogazione e ottimizzare le prestazioni.
| Livello | Tipo di filtro | Description |
|---|---|---|
| 1 | Condizione dell'indice |
Applicata durante la scansione dell'indice. Limita la quantità di dati letti dallo storage e riduce i dati inviati al livello di elaborazione. |
| 2 | Filtro di archiviazione | Applicato dopo la lettura dei dati dallo storage ma prima di essere inviati al calcolo. Un esempio qui è un filter su una colonna di inclusione di un indice. Riduce il trasferimento di dati ma non la quantità letta. |
| 3 | Filtro Query Processor | Applicato dopo che i dati raggiungono il livello di elaborazione. Tutti i dati devono essere trasferiti per primi, il che aumenta la latenza e i costi. Attualmente, Aurora DSQL non è in grado di eseguire tutte le operazioni di filtraggio e proiezione sullo storage, quindi alcune query potrebbero essere costrette a ricorrere a questo tipo di filtro. |
