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à.
Query parallela per Amazon Aurora MySQL
Questo argomento illustra l'ottimizzazione delle prestazioni mediante query parallele per Amazon Aurora edizione compatibile con MySQL. Questa funzionalità utilizza un percorso di elaborazione speciale per alcune query che implicano grandi quantità di dati grazie all'architettura di storage condivisa di Aurora. Le query in parallelo forniscono i migliori risultati con cluster di database Aurora MySQL che includono tabelle con milioni di righe e query analitiche la cui elaborazione dura vari minuti o addirittura ore.
Argomenti
Panoramica delle query in parallelo per Aurora MySQL
Le query in parallelo Aurora MySQL sono un'ottimizzazione che parallelizza alcune operazioni di I/O e di calcolo utilizzate nell'elaborazione di query che implicano grandi quantità di dati. Il lavoro che viene parallelizzato include il recupero di righe dalla memoria, l'estrazione dei valori della colonna e la determinazione di quali righe corrispondono alle condizioni nelle clausole join e nella clausola WHERE. Questa attività che implicano grandi quantità di dati sono delegate (in termini di ottimizzazione del database, trasferite) a più nodi nel livello di storage distribuito di Aurora. Senza query parallela, ogni query porta tutti i dati scansionati a un singolo nodo all'interno del cluster Aurora MySQL (il nodo head) ed esegue l'elaborazione in quel nodo.
Suggerimento
Anche il motore di database PostgreSQL ha una funzionalità chiamata "query parallela". Tale caratteristica non è correlata alla query Aurora parallela.
Quando la funzionalità di query in parallelo è abilitata, il motore Aurora MySQL determina automaticamente quando utilizzarla senza richiedere modifiche SQL come hint o attributi di tabella. Nelle sezioni seguenti, viene descritto quando una query in parallelo è applicata a una query. Scoprirai inoltre come assicurarti che una query in parallelo sia applicata dove necessario.
Nota
L'ottimizzazione delle query parallele offre il massimo vantaggio per le query a esecuzione prolungata che richiedono minuti o ore per il completamento. Aurora MySQL generalmente non esegue l'ottimizzazione delle query parallele per query economiche. In genere, inoltre, non esegue l'ottimizzazione delle query parallele se un'altra tecnica di ottimizzazione ha più senso, come la memorizzazione nella cache delle query, la memorizzazione nella cache del pool di buffer o le ricerche degli indici. Consulta se ritieni che le query in parallelo non sono utilizzate dove dovrebber Identificazione delle istruzioni che utilizzano la funzione di query in parallelo per Aurora MySQL.
Vantaggi
Con la query parallela è possibile eseguire query analitiche a uso intensivo di dati sulle tabelle Aurora MySQL. In molti casi, è possibile ottenere un miglioramento delle prestazioni dell'ordine di grandezza rispetto alla divisione tradizionale della manodopera per l'elaborazione delle query.
Alcuni dei vantaggi derivanti dall'uso delle query in parallelo sono:
-
Miglioramento delle prestazioni di I/O a seguito delle parallelizzazione delle richieste di lettura fisiche in molteplici nodi di storage.
-
Traffico di rete ridotto. Aurora non trasmette intere pagine di dati dai nodi di storage al nodo head e quindi non filtra le righe e le colonne superflue in seguito. Aurora trasmette invece tuple compatte contenenti solo i valori di colonna necessari per il set di risultati.
-
Riduzione dell'utilizzo della CPU sul nodo head grazie dell'elaborazione della funzione di trasferimento, al filtraggio delle righe e alla proiezione delle colonne per la clausola
WHERE. -
Riduzione della sollecitazione della memoria a livello del pool di buffer. Le pagine elaborate dalla query parallela non vengono aggiunte al pool di buffer. Questo approccio riduce la possibilità che una scansione intensiva di dati sgomberi i dati utilizzati di frequente dal pool di buffer.
-
Riduzione potenziale della duplicazione dei dati nella pipeline ETL (extract, transform, load), rendendo più pratica l'esecuzione di query analitiche di lunga durata su dati esistenti.
Architettura
La funzionalità di query in parallelo utilizza i principi architetturali chiave di Aurora MySQL: disaccoppiamento del motore di database dal sottosistema di storage e riduzione del traffico di rete mediante la razionalizzazione dei protocolli di comunicazione. Aurora MySQL utilizza queste tecniche per velocizzare le operazioni ad uso intensivo di scrittura, come l'elaborazione dei log di ripristino. La query in parallelo applica gli stessi principi alle operazioni di lettura.
Nota
L'architettura delle query in parallelo Aurora MySQL differisce da quella delle funzionalità con nomi simili in altri sistemi di database. La query parallela Aurora MySQL non comporta l'utilizzo di multiprocessori simmetrici e quindi non dipende dalla capacità della CPU del server di database. L'elaborazione in parallelo avviene nel livello di storage, indipendentemente dal server Aurora MySQL utilizzato come coordinatore di query.
Per impostazione predefinita, senza le query in parallelo, l'elaborazione di una query Aurora comporta la trasmissione di dati non elaborati a un singolo nodo nel cluster Aurora (il nodo head). Aurora esegue quindi tutte le ulteriori elaborazioni per quella query in un singolo thread su quel singolo nodo. Con le query in parallelo, una grande parte di queste attività che implicano un numero elevato di operazioni di I/O e un utilizzo intensivo della CPU viene delegata ai nodi nel livello di storage. Solo le righe compatte del set di risultati sono ritrasmesse al nodo head, con righe già filtrate e valori di colonna già estratti e trasformati. Il miglioramento delle prestazioni risulta dalla riduzione del traffico di rete, da un minore utilizzo della CPU sul nodo head e dalla parallelizzazione delle operazioni di I/O nei nodi di storage. Il volume di operazioni di filtraggio, proiezione e I/O in parallelo non dipende dal numero di istanze database nel cluster Aurora che esegue la query.
Prerequisiti
Per l’utilizzo di tutte le funzionalità della query parallela è necessario un cluster di database Aurora MySQL che esegue la versione 2.09 o successiva. Se si dispone già di un cluster che si desidera utilizzare con query parallela, è possibile aggiornarlo a una versione compatibile e abilitare la query parallela in seguito. In questo caso, assicurarsi di seguire la procedura di aggiornamento in Considerazioni relative agli aggiornamenti per le query in parallelo perché i nomi delle impostazioni di configurazione e i valori predefiniti sono diversi in queste versioni più recenti.
Le istanze database nel cluster devono utilizzare le classi di istanza db.r*.
Assicurati che l'ottimizzazione del join hash sia attivata per il cluster. Per scoprire come, consulta Abilitazione dell'hash join per cluster di query parallele.
Per personalizzare parametri quali aurora_parallel_query e aurora_disable_hash_join, è necessario disporre di un gruppo di parametri personalizzato da utilizzare con il cluster. È possibile specificare questi parametri singolarmente per ogni istanza DB utilizzando un gruppo di parametri DB. Tuttavia, si consiglia di specificarli in un gruppo di parametri cluster DB. In questo modo, tutte le istanze DB nel cluster ereditano le stesse impostazioni per questi parametri.
Limitazioni
Le seguenti limitazioni si applicano alla funzionalità di query in parallelo:
-
La query parallela non è supportata con la configurazione dell'archiviazione del cluster database Aurora I/O-Optimized.
-
Non è possibile utilizzare la query parallela con le classi di istanza db.t2 o db.t3. Questa limitazione si applica anche se si richiede la query parallela utilizzando la variabile di sessione
aurora_pq_force. -
La query parallela non si applica alle tabelle che utilizzano i formati di riga
COMPRESSEDoREDUNDANT. Utilizzare i formati di rigaCOMPACToDYNAMICper le tabelle che si intende utilizzare con la query parallela. -
Aurora utilizza un algoritmo basato sui costi per determinare se utilizzare il meccanismo di query parallela per ogni istruzione SQL. L'utilizzo di determinati costrutti SQL in un'istruzione può impedire query parallele o rendere la query parallela improbabile per tale istruzione. Per informazioni sulla compatibilità dei costrutti SQL con la query parallela, vedere Costrutti SQL per query in parallelo in Aurora MySQL.
-
Ogni istanza database Aurora può eseguire solo un numero specifico di sessioni di query in parallelo simultanee. Se una query comporta più parti che utilizzano una query in parallelo, come sottoquery, join o operatori
UNION, quelle fasi sono eseguite in sequenza. L'istruzione viene considerata solo come singola sessione di query in parallelo. Puoi monitorare il numero di sessioni attive mediante le variabili di stato di query in parallelo. Puoi verificare il limite delle sessioni simultanee per una determinata istanza database eseguendo una query sulla variabile di statoAurora_pq_max_concurrent_requests. -
La query parallela è disponibile in tutte le Regioni Regioni AWS supportate da Aurora. Per la maggior parte delle Regioni Regioni AWS, la versione di Aurora MySQL minima richiesta per utilizzare la query parallela è 2.09.
-
La query parallela è progettata per migliorare le prestazioni delle query a uso intensivo di dati. Non è progettata per eseguire query leggere.
-
Ti consigliamo di utilizzare i nodi di lettura per le istruzioni SELECT, in particolare quelle che richiedono un uso intensivo di dati.
Costi di I/O con la query parallela
Se il tuo cluster Aurora MySQL utilizza una query parallela, potresti vedere un aumento dei valori di VolumeReadIOPS. Le query parallele non utilizzano il pool di buffer. Pertanto, sebbene le query siano veloci, questa elaborazione ottimizzata può comportare un aumento delle operazioni di lettura e degli addebiti associati.
I costi di I/O delle query parallele vengono misurati a livello di archiviazione e sono uguali o maggiori con la query parallela attivata. Il vantaggio sta nel miglioramento delle prestazioni delle query. I motivi per i quali i costi di I/O sono potenzialmente più elevati con la query parallela sono due:
-
Anche se alcuni dei dati di una tabella si trovano nel pool di buffer, la query parallela richiede che tutti i dati vengano scansionati a livello di archiviazione, con conseguenti costi di I/O.
-
L'esecuzione di una query parallela non prepara il pool di buffer. Di conseguenza, le successive esecuzioni della stessa query parallela comportano l'intero costo di I/O.
