Spiegare le opzioni di distribuzione
Il database SQL di Azure, una piattaforma distribuita come servizio (PaaS), offre scalabilità elevata a fronte di una manutenzione minima, vantaggi che ne fanno una soluzione eccellente per carichi di lavoro specifici. È adatto per lo sviluppo di nuove applicazioni, poiché offre agli sviluppatori una notevole flessibilità nella creazione di nuovi servizi, oltre a opzioni di distribuzione granulari su larga scala. Questa soluzione a bassa manutenzione è ideale per vari carichi di lavoro e garantisce un’esperienza di sviluppo di applicazioni efficiente ed efficace.
Modelli di distribuzione
Quando si distribuisce il database SQL di Azure, sono disponibili due modelli di distribuzione principali: database singolo e pool elastici. Nel modello basato su pool elastici le risorse vengono condivise tra più database all'interno dello stesso pool, mentre nel modello basato su database singolo le risorse vengono gestite in modo indipendente per ogni database.
Il database SQL, come le macchine virtuali, può essere distribuito usando vari metodi, tra cui PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure.
Database singolo
Il modello di distribuzione basato su database singolo è il modo più semplice di usare il database SQL di Azure. In questo modello ogni database viene gestito singolarmente in termini di scalabilità e dimensioni dei dati. Ogni database ha le sue risorse dedicate, anche se nello stesso server logico sono distribuiti più database.
È possibile monitorare l'utilizzo delle risorse di ogni database tramite il portale di Azure. Questa funzionalità consente di monitorare e valutare facilmente le prestazioni dei database.
Pool elastici
I pool elastici consentono di allocare le risorse di archiviazione e calcolo a un gruppo di database, senza doversi occupare di ogni database singolarmente, semplificando così la gestione. I pool elastici sono più facili da ridimensionare rispetto ai database singoli, in quanto le modifiche apportate al pool elastico regolano automaticamente le risorse per tutti i database inclusi.
Questo modello è economicamente conveniente per le applicazioni Software as a Service (SaaS), in quanto le risorse vengono condivise fra tutti i database. È possibile configurare le risorse usando il modello di acquisto basato su DTU o quello basato su vCore.
È importante monitorare continuamente le risorse per identificare i picchi di prestazioni che potrebbero influire su altri database del pool. La revisione periodica della strategia di allocazione garantisce risorse sufficienti per tutti i database.
I pool elastici sono ideali per architetture multi-tenant con utilizzo medio basso, in cui ogni tenant dispone di una propria copia del database.
Modelli di acquisto
Dopo aver scelto il modello di distribuzione appropriato per il database SQL in uso, il passaggio successivo consiste nel selezionare il modello di acquisto più adatto ai requisiti di carico di lavoro e budget. Il database SQL di Azure offre due modelli di acquisto: il modello vCore e il modello basato su DTU. Ogni modello presenta vantaggi specifici, quindi è fondamentale determinare quale sia quello più in linea con i requisiti del carico di lavoro e con le considerazioni sui costi.
Basato su vCore
Questo è il modello di acquisto consigliato, in cui le risorse di calcolo e di archiviazione sono separate. In altre parole, è possibile ridimensionare le risorse di archiviazione e di calcolo in modo indipendente l'una dall'altra. Grazie a questa flessibilità, è possibile adeguare le risorse alle esigenze specifiche senza influire sugli altri componenti.
Nel modello di acquisto basato su vCore i costi dipendono da diversi fattori, tra cui il livello di servizio, la configurazione hardware, il numero di vCore e la quantità di memoria, lo spazio di archiviazione riservato ai database e l'archivio di backup effettivo.
Nota
Per informazioni dettagliate sui prezzi, vedere la pagina dei prezzi del database SQL di Azure .
Un livello di servizio è una configurazione predefinita che determina le prestazioni, il tipo di archiviazione, la disponibilità elevata, le opzioni di ripristino di emergenza e la disponibilità di determinate funzionalità per il database.
Il modello di acquisto basato su vCore offre tre opzioni per il livello di servizio:
| Livello di servizio | Funzionalità |
|---|---|
| Utilizzo generico | Questo livello di servizio è pensato per operazioni meno complesse e offre un equilibrio tra opzioni di calcolo e archiviazione a livello di costi. Include livelli di calcolo con provisioning e serverless, garantendo la flessibilità necessaria per soddisfare esigenze di carico di lavoro variabili ottimizzando al contempo il budget. |
| Business Critical | Questo livello è ideale per le applicazioni che richiedono un'archiviazione a bassa latenza e a prestazioni elevate. Supporta In-Memory OLTP e include una replica di sola lettura integrata. Offre inoltre una maggiore quantità di memoria per core e usa l'archiviazione SSD locale, pertanto è il livello ideale per i carichi di lavoro con particolari requisiti di prestazioni. |
| Hyperscale | Questo livello è particolarmente adatto per le applicazioni con database di grandi dimensioni e requisiti di velocità effettiva elevata. Hyperscale introduce funzionalità avanzate di scalabilità orizzontale, consentendo l'aggiunta di nodi di calcolo man mano che aumentano le dimensioni dei dati. È supportato esclusivamente in database SQL singoli e consente un notevole ridimensionamento delle risorse di archiviazione e calcolo oltre i limiti dei livelli di servizio per utilizzo generico e business critical. |
Basato su DTU
Nel modello DTU sono presenti tre livelli di servizio: Basic, Standard e Premium. Le risorse di calcolo e di archiviazione dipendono dal livello di DTU e offrono una gamma di funzionalità per le prestazioni con limiti di archiviazione, conservazione dei backup e costi fissi.
Se ad esempio il database raggiunge il limite massimo di archiviazione, è necessario aumentare la capacità di DTU, anche se l'utilizzo delle risorse di calcolo è limitato. Inoltre, le operazioni di ridimensionamento sul database SQL di Azure possono causare brevi interruzioni della connessione alla fine del processo. Ciò può verificarsi in due scenari principali:
- Avvio di un'operazione di ridimensionamento che richiede un failover interno.
- Aggiunta o rimozione di database nel pool elastico.
Nota
Per gestire gli errori di connessione, implementare la logica di ripetizione dei tentativi appropriata nell'applicazione.
La conoscenza dell'interazione tra i modelli di distribuzione e di acquisto è fondamentale per ottimizzare le prestazioni e contenere i costi. La scelta della combinazione corretta garantisce che la distribuzione del database SQL di Azure soddisfi le esigenze dell'applicazione senza superare il budget.
Ad esempio, se si sceglie il modello di distribuzione a database singolo, può essere preferibile il modello di acquisto basato su vCore per la flessibilità che offre nel ridimensionamento indipendente delle risorse di calcolo e di archiviazione. D'altra parte, se si sceglie il modello di distribuzione basato su pool elastici, il modello di acquisto basato su DTU potrebbe essere più conveniente dal punto di vista economico, in quanto consente di condividere le risorse tra più database all'interno del pool.
Eseguire procedure di backup e ripristino
Azure offre semplici funzionalità di backup e ripristino per il database SQL. Ecco alcune delle più importanti:
Backup continuo
Il database SQL di Azure garantisce backup regolari, copiandoli continuamente nello spazio di archiviazione con ridondanza geografica e accesso in lettura (RA-GRS). Vengono eseguiti backup completi ogni settimana, backup differenziali a intervalli compresi tra le 12 e le 24 ore e backup dei log delle transazioni a intervalli compresi tra 5 e 10 minuti.
Ripristino geografico
Grazie ai backup con ridondanza geografica attivati per impostazione predefinita, è possibile ripristinare facilmente i database in aree diverse, funzionalità utile per scenari di ripristino di emergenza meno rigidi. L'archivio di backup viene fatturato separatamente ma creato senza costi aggiuntivi con le dimensioni massime del livello dati selezionato. La durata del ripristino geografico dipende dalle dimensioni del database, dai log delle transazioni e dalle richieste di ripristino simultanee.
Nota
Il ripristino geografico è disponibile quando la proprietà di ridondanza dell'archiviazione di backup è impostata sull'archiviazione di backup con ridondanza geografica.
Ripristino temporizzato
Consente di configurare un criterio di conservazione temporizzato specifico per ogni database, compreso tra 1 e 35 giorni (il valore predefinito è sette giorni). È anche possibile ripristinare i database a un momento specifico nello stesso server usando il portale di Azure, PowerShell, l'interfaccia della riga di comando o l'API REST.
Conservazione a lungo termine
La conservazione a lungo termine è utile per gli scenari che richiedono l'impostazione di criteri di conservazione con tempi più lunghi rispetto a quelli offerti da Azure. È possibile impostare criteri di conservazione per un massimo di 10 anni, anche se questa opzione è disabilitata per impostazione predefinita.
Per altre informazioni sui backup automatizzati, vedere Backup automatizzati - Database SQL di Azure e Istanza gestita di SQL di Azure.
Abilitare l'ottimizzazione automatica
L'ottimizzazione automatica è un’efficace funzionalità predefinita che applica l'apprendimento automatico per ottimizzare le prestazioni delle query. Identifica automaticamente le opportunità di ottimizzazione e le implementa per migliorare l'efficienza del database.
L'ottimizzazione automatica include attualmente le funzionalità seguenti:
- Identificazione di query costose
- Applicazione forzata dell'ultimo piano di esecuzione valido
- Aggiunta di indici
- Rimozione di indici
I servizi di Azure usano algoritmi avanzati per determinare gli indici ottimali per i modelli di query. Questi indici vengono inizialmente testati su una copia del database prima di essere applicati all'ambiente attivo, garantendo un'interruzione minima delle attività.
Tutti i database ereditano la configurazione dal server padre e, se necessario, è possibile disabilitare facilmente questa funzionalità. Questa flessibilità consente agli sviluppatori di mantenere il controllo sfruttando al contempo i miglioramenti automatizzati delle prestazioni.
Usare una query elastica
La funzionalità Query elastica consente di eseguire query T-SQL su più database nel database SQL. Questa funzionalità è utile per le applicazioni che usano nomi composti da tre e quattro parti che non possono essere modificati e migliora la portabilità semplificando la migrazione.
Le query elastiche supportano gli scenari di partizionamento seguenti:
| Livello di servizio | Funzionalità |
|---|---|
| Partizionamento verticale | Detto anche query tra database. I dati vengono partizionati verticalmente tra più database con schemi diversi. Ad esempio, si potrebbe avere un database per i dati dei clienti e un altro per le informazioni di pagamento. Il partizionamento verticale consente di eseguire query tra questi database. |
| Partizionamento orizzontale | Con il partizionamento orizzontale, i dati vengono partizionati orizzontalmente per distribuire le righe tra diversi database con scalabilità orizzontale che condividono tutti lo stesso schema. Questa topologia supporta i modelli sia a tenant singolo che multi-tenant. |
Questa flessibilità fa delle query elastiche uno strumento efficace per la gestione e l'esecuzione di query sui dati di più database.
Configurare processi elastici
La funzionalità processo elastico sostituisce SQL Server Agent per il database SQL di Azure, analogamente alla funzionalità Amministrazione multiserver in un'istanza di SQL Server locale.
I processi elastici consentono di eseguire comandi T-SQL su varie distribuzioni di destinazione, tra cui database SQL, pool elastici di database SQL e database SQL in mappe partizioni. Queste risorse di database possono estendersi a diverse sottoscrizioni e aree di Azure. La funzionalità di esecuzione parallela è utile per automatizzare le attività di manutenzione del database, garantendo efficienza e coerenza tra le distribuzioni.
Spostare i dati con la sincronizzazione dati SQL
La sincronizzazione dati SQL consente la sincronizzazione incrementale dei dati tra più database, sia che siano in esecuzione nel database SQL o in SQL Server locale. Questa funzionalità è utile per eseguire l'offload di carichi di lavoro di produzione intensivi in un database separato per operazioni di analisi o non pianificate.
La sincronizzazione dati si basa su una topologia hub, in cui un database nel gruppo di sincronizzazione funge da hub. Il gruppo di sincronizzazione può includere più database membri e la sincronizzazione avviene tra l'hub e i singoli database membri. Viene tenuta traccia delle modifiche usando trigger di inserimento, aggiornamento ed eliminazione tramite una tabella cronologica creata nel database utente.
Quando si crea un gruppo di sincronizzazione, è necessario specificare un database in cui archiviare i metadati del gruppo di sincronizzazione. Questo database metadati può essere nuovo o esistente, purché si trovi nella stessa area del gruppo di sincronizzazione.
Per altre informazioni su come configurare la sincronizzazione dati SQL, vedere Esercitazione: Configurare la sincronizzazione dati SQL tra database nel database SQL di Azure e SQL Server.