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à.
Lavorare con i piani Aurora DSQL EXPLAIN
Aurora DSQL utilizza una struttura di piano EXPLAIN simile a quella di PostgreSQL, ma con aggiunte chiave che riflettono l'architettura distribuita e il modello di esecuzione.
In questa documentazione, forniremo una panoramica dei piani 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 il costo di esecuzione delle tue query.
Piani PostgreSQL VS Aurora DSQL EXPLAIN
Aurora SQL si basa sul database PostgreSQL e condivide la maggior parte delle strutture dei piani con PostgreSQL, ma presenta differenze architetturali chiave che influiscono sull'esecuzione e sull'ottimizzazione delle query:
| Funzionalità | PostgreSQL | Aurora DSQL |
|---|---|---|
|
Storage dei dati |
Storage a basso costo |
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 |
Funzionano 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 indice |
Scansione completa, Scansione solo indice, Scansione indice |
|
Esecuzione della query |
Locale rispetto al database |
Distribuito (elaborazione e archiviazione sono separati) |
Aurora DSQL archivia i dati delle tabelle direttamente nell'ordine delle chiavi primarie 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 Index Only Scans nei casi in cui PostgreSQL potrebbe scegliere una scansione sequenziale.
Un'altra differenza fondamentale è che Aurora DSQL separa l'elaborazione dallo storage, consentendo di applicare i filtri nelle prime fasi del percorso di esecuzione per ridurre lo spostamento dei dati e migliorare le prestazioni.
Per ulteriori informazioni sull'utilizzo dei piani EXPLAIN con PostgreSQL, consulta la documentazione di PostgreSQL EXPLAIN. https://www.postgresql.org/docs/current/using-explain.html
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 output consente di ottimizzare le prestazioni delle query.
- Indice Cond
Condizioni utilizzate per navigare nell'indice. Filtraggio più efficiente che riduce i dati scansionati. In Aurora DSQL, le condizioni di indice possono essere applicate a più livelli del piano di esecuzione.
- Proiezioni
Colonne recuperate dall'archiviazione. Un numero inferiore di proiezioni significa prestazioni migliori.
- Filtro di archiviazione
Condizioni applicate a livello di archiviazione. Più efficiente dei filtri dei processori di interrogazione.
- Filtro Query Processor
-
Condizioni applicate a livello di processore di query. Richiede il trasferimento di tutti i dati prima del filtraggio, il che comporta un maggiore sovraccarico di spostamento ed elaborazione dei dati.
Filtri in Aurora DSQL
Aurora DSQL separa l'elaborazione dallo storage, il che significa che il punto in cui i filtri vengono applicati 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 conseguente rapidità delle interrogazioni.
Aurora DSQL può applicare filtri in più fasi del percorso di interrogazione. Comprendere 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 dell'invio al calcolo. Un esempio è rappresentato da un filtro su una colonna include di un indice. Riduce il trasferimento dei dati ma non la quantità letta. |
| 3 | Filtro Query Processor | Applicato dopo che i dati hanno raggiunto il livello di elaborazione. Tutti i dati devono essere prima trasferiti, 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, pertanto alcune query potrebbero essere costrette a ricorrere a questo tipo di filtro. |
