Ridimensionare in modo dinamico le risorse di database con tempo di inattività minimo

Si applica a: Database SQL di Azure Istanza gestita di SQL di Azure

Azure SQL Database e Istanza gestita di SQL consentono di aggiungere dinamicamente più risorse al database con tempi di inattività minimi. Tuttavia, esiste un passaggio nel periodo in cui la connettività viene persa al database per un breve periodo di tempo, che può essere ridotto usando la logica di ripetizione dei tentativi.

Panoramica

Quando la domanda per l'app aumenta da pochi dispositivi e clienti a milioni, Azure SQL Database e Istanza gestita di SQL scalabilità in tempo reale con tempi di inattività minimi. La scalabilità è una delle caratteristiche più importanti della piattaforma come servizio (PaaS) che consente di aggiungere dinamicamente altre risorse al servizio quando necessario. Database SQL di Azure consente di modificare facilmente le risorse allocate per i database (potenza della CPU, memoria, velocità effettiva IO e storage).

È possibile limitare i problemi di prestazione, causati da un maggiore utilizzo dell'applicazione, che non possono essere risolti utilizzando l'indicizzazione o con i metodi di query. L'aggiunta di altre risorse consente di una reazione rapida quando il database raggiunge i limiti delle risorse correnti e richiede più energia per gestire il carico di lavoro in ingresso. Database SQL di Azure consente inoltre di ridurre le risorse non necessarie all'abbassamento dei costi.

Non è necessario preoccuparsi di acquistare hardware e modificare l'infrastruttura sottostante. La scalabilità di un database può essere eseguita facilmente tramite il portale di Azure usando un dispositivo di scorrimento.

Prestazioni del ridimensionamento del database

Azure SQL Database offre il modello di acquisto basato su DTU e il modello di acquisto basato su vCore, mentre Istanza gestita di SQL di Azure offre solo il modello di acquisto basato su vCore.

  • Il modello di acquisto basato su DTU offre una combinazione di risorse di calcolo, memoria e I/O in tre livelli di servizio per supportare carichi di lavoro di database con peso elevato: Basic, Standard e Premium. I livelli delle prestazioni di ogni livello forniscono una diversa combinazione di queste risorse, a cui è possibile aggiungere altre risorse di archiviazione.
  • Il modello di acquisto basato su vCore consente di scegliere il numero di vCore, la quantità di memoria e la quantità e la velocità della risorsa di archiviazione. Questo modello di acquisto offre tre livelli di servizio: per utilizzo generico, business critical e Hyperscale.

Il livello di servizio, il livello di calcolo e i limiti delle risorse per un database, un pool elastico o un'istanza gestita possono essere modificati in qualsiasi momento. Ad esempio, è possibile creare la prima app in un singolo database usando il livello di calcolo serverless e quindi modificare manualmente o a livello di codice il livello di servizio in qualsiasi momento, al livello di calcolo con provisioning, per soddisfare le esigenze della soluzione.

Nota

Eccezioni significative in cui non è possibile modificare il livello di servizio di un database:

  • I database che usano funzionalità disponibili solo nei livelli di servizio business critical/Premium, non possono essere modificati per usare il livello di servizio per utilizzo generico/Standard.
  • I database creati originariamente nel livello di servizio Hyperscale non possono essere migrati ad altri livelli di servizio. Se si esegue la migrazione di un database esistente in Azure SQL Database al livello di servizio Hyperscale, è possibile eseguire la migrazione al livello di servizio per utilizzo generico entro 45 giorni dalla migrazione originale a Hyperscale. Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio business critical, eseguire prima la migrazione inversa al livello di servizio per utilizzo generico, eseguire una successiva migrazione. Altre informazioni in Come invertire la migrazione da Hyperscale.

È possibile modificare le risorse allocate al database modificando l'obiettivo del servizio o il ridimensionamento per soddisfare le esigenze del carico di lavoro. Ciò consente anche di pagare solo le risorse necessarie, quando sono necessarie. Si prega di fare riferimento alla nota sull'impatto potenziale che un'operazione di scalabilità potrebbe avere in un'applicazione.

Nota

La scalabilità dinamica è diversa dalla scalabilità automatica. La scalabilità automatica è quando un servizio viene ridimensionato automaticamente in base ai criteri, mentre la scalabilità dinamica consente la scalabilità manuale con tempi di inattività minimi. I database singoli in Azure SQL database possono essere ridimensionati manualmente o, nel caso del livello Serverless, impostare per ridimensionare automaticamente le risorse di calcolo. I pool elastici, che consentono ai database di condividere le risorse in un pool, possono attualmente essere ridimensionati manualmente.

Azure SQL Database offre la possibilità di ridimensionare dinamicamente i database:

  • Con un Database singolo è possibile usare sia i modelli DTU o vCore per definire la quantità massima di risorse che verranno assegnate a ogni database.
  • I pool elastici consentono di definire il limite massimo di risorse per ogni gruppo di database nel pool.

Istanza gestita di SQL di Azure consente anche di ridimensionare:

  • Istanza gestita di SQL usa la modalità vCore e consente di definire i core CPU massimi e il massimo di archiviazione allocati all'istanza. Tutti i database all'interno dell'istanza condivideranno le risorse allocate all'istanza.

Impatto delle operazioni di aumento o riduzione delle prestazioni

Avviare un'azione di scalabilità orizzontale o ridimensionare, in uno dei tipi indicati in precedenza, riavvia il processo del motore di database e lo sposta in una macchina virtuale diversa, se necessario. Lo spostamento del processo del motore di database in una nuova macchina virtuale è un processo online durante il quale è possibile continuare a usare il servizio database Azure SQL esistente. Una volta che il motore di database di destinazione è pronto per elaborare le query, aprire le connessioni al motore di database corrente verrà terminato e le transazioni non inviate verranno eseguito il rollback. Verranno effettuate nuove connessioni al motore di database di destinazione.

Nota

Non è consigliabile ridimensionare l'istanza gestita se una transazione a esecuzione prolungata, ad esempio l'importazione dei dati, i processi di elaborazione dei dati, la ricompilazione dell'indice e così via, è in esecuzione o se si dispone di una connessione attiva nell'istanza. Per evitare che il ridimensionamento richiede più tempo per il completamento del normale, è necessario ridimensionare l'istanza al completamento di tutte le operazioni a esecuzione prolungata.

Nota

È possibile prevedere un'interruzione di connessione breve al termine del processo di scalabilità/riduzione delle scalabilità. Se è stata implementata la logica di ripetizione dei tentativi per gli errori temporanei standard, non si noterà il failover.

Metodi alternativi di scalabilità

La scalabilità delle risorse è il modo più semplice e più efficace per migliorare le prestazioni del database senza modificare il codice del database o dell'applicazione. In alcuni casi, anche i livelli di servizio più elevati, le dimensioni di calcolo e le ottimizzazioni delle prestazioni potrebbero non gestire il carico di lavoro in modo efficace e conveniente. In questo caso sono disponibili queste opzioni aggiuntive per ridimensionare il database:

  • La scalabilità orizzontale di lettura è una funzionalità disponibile in cui si ottiene una replica di sola lettura dei dati in cui è possibile eseguire query di sola lettura richieste, ad esempio i report. Una replica di sola lettura gestirà il carico di lavoro di sola lettura senza influire sull'utilizzo delle risorse nel database primario.
  • Il Partizionamento di database è un set di tecniche che consente di dividere i dati in diversi database e di ridimensionarli in modo indipendente.

Passaggi successivi