Gestire le risorse di calcolo per il pool SQL dedicato
Questo articolo illustra come gestire le risorse di calcolo per il pool SQL dedicato (in precedenza SQL Data Warehouse) in Azure Synapse Analytics. È possibile ridurre i costi sospendo il pool SQL dedicato o ridimensionando il pool SQL dedicato per soddisfare le esigenze di prestazioni.
Informazioni sulla gestione del calcolo
L'architettura del pool SQL dedicato separa le risorse di archiviazione e calcolo consentendo a entrambe di eseguire il ridimensionamento in modo indipendente. Di conseguenza, è possibile ridimensionare il calcolo per soddisfare le esigenze in termini di prestazioni indipendenti dall'archiviazione dei dati. È anche possibile sospendere e riprendere le risorse di calcolo.
Una conseguenza naturale di questa architettura è che i prezzi per il calcolo e l'archiviazione sono separati. Se non è necessario usare il pool SQL dedicato per un periodo di tempo, è possibile sospendere le funzioni di calcolo al fine di risparmiare i costi associati.
Ridimensionamento delle risorse di calcolo
È possibile aumentare o ridurre il numero di istanze di calcolo modificando l'impostazione delle unità data warehouse (DWU) per il pool SQL dedicato. Il caricamento e le prestazioni delle query possono aumentare in modo lineare man mano che si aggiungono altre DWU.
Per la procedura di scalabilità orizzontale, vedere le guide introduttive per le portale di Azure, PowerShell o T-SQL. È anche possibile eseguire operazioni di scalabilità orizzontale usando un'API REST.
Per eseguire un'operazione di scalabilità, il pool SQL dedicato termina prima di tutto tutte le query in ingresso e quindi esegue il rollback delle transazioni per garantire uno stato coerente. Il ridimensionamento ha effetto solo quando il rollback della transazione è completato. Per un'operazione di scalabilità, il sistema scollega il livello di archiviazione dai nodi di calcolo, aggiunge nodi di calcolo e quindi ricollega il livello di archiviazione al livello di calcolo.
Ogni pool SQL dedicato viene archiviato come 60 distribuzioni, distribuite uniformemente ai nodi di calcolo. L'aggiunta di più nodi di calcolo determina un aumento della potenza di calcolo. Con l'aumento del numero di nodi di calcolo si riduce il numero di distribuzioni per ogni nodo di calcolo, con un conseguente incremento della potenza di calcolo per le query. Analogamente, la riduzione delle DWU riduce il numero di nodi di calcolo, riducendo così le risorse di calcolo per le query.
Nella tabella seguente viene illustrato come cambia il numero di distribuzioni per ogni nodo di calcolo man mano che cambiano le DWU. DW30000c fornisce 60 nodi di calcolo e ottiene prestazioni di query molto più elevate rispetto a DW100c.
| Unità di data warehouse | N. di nodi di calcolo | N. di distribuzioni per nodo |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
Ricerca delle dimensioni giuste delle unità di data warehouse
Per ottenere vantaggi della scalabilità orizzontale in termini di prestazioni, in particolare per le unità di warehouse dati di dimensioni maggiori, è necessario usare un set di dati di almeno 1 TB. Per trovare il numero migliore di DWU per il pool SQL dedicato, provare a aumentare e ridurre le prestazioni. Eseguire alcune query con diversi numeri di DWU dopo il caricamento dei dati. Poiché il ridimensionamento è rapido, è possibile provare diversi livelli di prestazioni in un'ora o meno.
Suggerimenti per trovare il numero migliore di DWU:
- Per un pool SQL dedicato in fase di sviluppo, iniziare selezionando un numero minore di DWU. Un buon punto di partenza è DW400c o DW200c.
- Monitorare le prestazioni dell'applicazione, osservare che il numero di DWUs selezionato in relazione alle prestazioni che si osservano.
- Si supponga una scala lineare e determinare quanto è necessario aumentare o diminuire le DWU.
- Continuare ad apportare modifiche finché non si raggiunge un livello di prestazioni ottimale per i propri requisiti aziendali.
Quando aumentare il numero di istanze
La scalabilità orizzontale delle DWU influisce su questi aspetti delle prestazioni:
- Migliora in modo lineare le prestazioni del sistema per analisi, aggregazioni e istruzioni CTAS
- Aumenta il numero di lettori e writer per il caricamento dei dati
- Numero massimo di query simultanee e slot di concorrenza
Consigli per quando aumentare il numero di DWU:
- Prima di eseguire un'operazione di caricamento o di trasformazione di dati con impatto elevato, aumentare il numero di istanze per rendere disponibili i dati più rapidamente.
- Durante le ore lavorative di maggiore picco, aumentare il numero di istanze per gestire un numero maggiore di query simultanee.
Cosa accade se la scalabilità orizzontale non migliora le prestazioni?
L'aggiunta di DWU aumenta il parallelismo. Se il lavoro viene suddiviso uniformemente tra i nodi di calcolo, il parallelismo aggiuntivo migliora le prestazioni delle query. Se la scalabilità orizzontale non modifica le prestazioni, esistono alcuni motivi per cui questo problema può verificarsi. I dati potrebbero essere presenti in modo non uniforme tra le distribuzioni o le query potrebbero introdurre spostamenti dei dati in notevole quantità. Per analizzare i problemi di prestazioni delle query, vedere Risoluzione dei problemi di prestazioni.
Sospendere e riprendere le risorse di calcolo
La sospensione del calcolo causa la disconnessione del livello di archiviazione dai nodi di calcolo. Le risorse di calcolo vengono rilasciate dall'account dell'utente. Non vengono addebitati addebiti per il calcolo mentre il calcolo è in pausa. La ripresa dell'elaborazione ricollega l'archiviazione ai nodi di calcolo e riprende gli addebiti per il calcolo.
Quando si sospende un pool SQL dedicato:
- Le risorse di calcolo e memoria vengono restituite al pool di risorse disponibili nel data center.
- I costi delle unità del data warehouse sono pari a zero durante la pausa.
- L'archiviazione dei dati non è interessata e i dati rimangono intatti.
- Tutte le operazioni in esecuzione o in coda vengono annullate.
- I contatori DMV vengono reimpostati.
Quando si riprende un pool SQL dedicato:
- Il pool SQL dedicato acquisisce risorse di calcolo e memoria per l'impostazione DWU.
- Verranno ripresi gli addebiti per le ore di calcolo di DWU.
- I dati diventano disponibili.
- Dopo che il pool SQL dedicato è online, è necessario riavviare le query del carico di lavoro.
Se si vuole che il pool SQL dedicato sia sempre accessibile, è consigliabile ridimensionarlo fino alle dimensioni più piccole anziché sospendere.
Per i passaggi di sospensione e ripresa, vedere le guide introduttive per l'portale di Azure o PowerShell. È anche possibile usare l'API REST di sospensione o l'API REST di ripresa.
Scaricare le transazioni prima della sospensione o del ridimensionamento
Prima di avviare un'operazione di sospensione o ridimensionamento, è consigliabile consentire il completamento delle transazioni esistenti.
Quando si sospende o si ridimensiona il pool SQL dedicato, in background le query vengono annullate quando si avvia la richiesta di sospensione o scalabilità. L'annullamento di una semplice query SELECT è un'operazione rapida e non ha quasi alcun effetto sul tempo necessario per sospendere o ridimensionare l'istanza. Tuttavia, le query transazionali, che modificano i dati o la struttura dei dati, potrebbero non essere in grado di arrestarsi rapidamente. Le query transazionali, per definizione, devono essere completate interamente oppure è necessario il rollback delle modifiche.
Il rollback del lavoro svolto da una query transazionale può richiedere la stessa quantità di tempo, o anche maggiore, della modifica originale applicata dalla query. Ad esempio, se si annulla una query che elimina righe ed è già in esecuzione per un'ora, potrebbe essere necessaria un'ora di sistema per inserire le righe eliminate. Se si eseguono pause o ridimensionamenti mentre le transazioni sono in esecuzione, la sospensione o il ridimensionamento potrebbe richiedere molto tempo perché la sospensione e il ridimensionamento devono attendere il completamento del rollback prima che possa procedere.
Per altre informazioni, vedere Usare le transazioni e Ottimizzare le transazioni.
Automatizzare la gestione delle risorse di calcolo
Per automatizzare le operazioni di gestione delle risorse di calcolo, vedere Usare Funzioni di Azure per gestire le risorse di calcolo per il pool SQL dedicato.
Ogni operazione di scalabilità orizzontale, sospensione e ripresa può richiedere alcuni minuti. Se si sta ridimensionando, sospendo o riprendendo automaticamente, è consigliabile implementare la logica per assicurarsi che determinate operazioni vengano completate prima di procedere con un'altra azione. Il controllo dello stato del pool SQL dedicato tramite vari endpoint consente di implementare correttamente l'automazione di tali operazioni.
Per controllare lo stato del pool SQL dedicato, vedere le guide introduttive per PowerShell o T-SQL. È anche possibile controllare lo stato del pool SQL dedicato con un'API REST.
Autorizzazioni
Per ridimensionare il pool SQL dedicato sono necessarie le autorizzazioni descritte in ALTER DATABASE. Sospendere e riprendere richiedono il ruolo Collaboratore database SQL, in particolare Microsoft.Sql/servers/databases/action.