Interrogazione parallela per Amazon Aurora My SQL - Amazon Aurora
Panoramica delle query in parallelo

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à.

Interrogazione parallela per Amazon Aurora My SQL

Questo argomento descrive l'ottimizzazione delle prestazioni delle query parallele per Amazon Aurora My SQL -Compatible Edition. 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 parallele funzionano al meglio con i cluster Aurora My SQL DB che dispongono di tabelle con milioni di righe e query analitiche che richiedono minuti o ore per essere completate.

Argomenti

Panoramica delle interrogazioni parallele per Aurora My SQL

Aurora My parallel query è un'ottimizzazione che SQL parallelizza alcuni degli I/O e del calcolo coinvolti nell'elaborazione di query a uso intensivo 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 parallele, ogni query porta tutti i dati scansionati su un singolo nodo all'interno del cluster Aurora SQL My (il nodo principale) e lì esegue tutta l'elaborazione delle query.

Suggerimento

Il motore di SQL database Postgre ha anche una funzionalità chiamata «query parallela». Tale caratteristica non è correlata alla query Aurora parallela.

Quando la funzionalità di interrogazione parallela è attivata, il SQL motore Aurora My determina automaticamente quando le query possono trarne vantaggio, senza richiedere SQL modifiche come suggerimenti 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 My SQL in genere non esegue l'ottimizzazione delle query parallele per query poco costose. 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 Verifica delle istruzioni che utilizzano la query parallela per Aurora My SQL.

Vantaggi

Con la query parallela, puoi eseguire query analitiche a uso intensivo di dati su Aurora My tables. SQL In molti casi, è possibile ottenere un miglioramento order-of-magnitude delle prestazioni rispetto alla tradizionale divisione del lavoro 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.

  • CPUUtilizzo ridotto sul nodo principale, grazie alla riduzione dell'elaborazione delle funzioni, del filtraggio delle righe e della 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.

  • Potenzialmente ridotta la duplicazione dei dati nella pipeline extract, transform, load (ETL), rendendo pratica l'esecuzione di query analitiche di lunga durata sui dati esistenti.

Architettura

La funzionalità di interrogazione parallela utilizza i principali principi architettonici di Aurora MySQL: disaccoppiamento del motore di database dal sottosistema di archiviazione e riduzione del traffico di rete semplificando i protocolli di comunicazione. Aurora My SQL utilizza queste tecniche per velocizzare le operazioni ad alta intensità di scrittura come l'elaborazione dei redo log. La query in parallelo applica gli stessi principi alle operazioni di lettura.

Nota

L'architettura di Aurora My SQL parallel query è diversa da quella di funzionalità con nomi simili presenti in altri sistemi di database. Aurora La mia query SQL parallela non prevede il multiprocessing simmetrico (SMP) e quindi non dipende dalla CPU capacità del server di database. L'elaborazione parallela avviene nel livello di archiviazione, indipendentemente dal SQL server Aurora My che funge da coordinatore delle 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 parallele, gran parte di questo lavoro ad alta intensità CPU di I/O viene delegato ai nodi del 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 vantaggio in termini di prestazioni deriva dalla riduzione del traffico di rete, dalla riduzione dell'CPUutilizzo sul nodo principale e dalla parallelizzazione dell'I/O tra i 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 utilizzare tutte le funzionalità di query parallela è necessario un cluster Aurora My SQL DB con 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 COMPRESSED o REDUNDANT. Utilizzare i formati di riga COMPACT o DYNAMIC per le tabelle che si intende utilizzare con la query parallela.

  • Aurora utilizza un algoritmo basato sui costi per determinare se utilizzare il meccanismo di interrogazione parallela per ogni istruzione. SQL L'utilizzo di determinati SQL costrutti in un'istruzione può impedire la query parallela o rendere improbabile la query parallela per quell'istruzione. Per informazioni sulla compatibilità dei SQL costrutti con la query parallela, vedereSQLcostrutti per interrogazioni parallele in Aurora My SQL.

  • 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 stato Aurora_pq_max_concurrent_requests.

  • L'interrogazione parallela è disponibile in tutte le AWS regioni supportate da Aurora. Per la maggior parte AWS delle regioni, la SQL versione minima richiesta di Aurora My per utilizzare la query parallela è la 2.09.

  • La query parallela è progettata per migliorare le prestazioni delle query a uso intensivo di dati. Non è progettata per eseguire query leggere.

  • Si consiglia di utilizzare i nodi di lettura per le SELECT istruzioni, in particolare quelle che richiedono un uso intensivo di dati.

Costi di I/O con la query parallela

Se il tuo SQL cluster Aurora My utilizza una query parallela, potresti notare un aumento VolumeReadIOPS dei valori. 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.