Progettare il database SQL di Azure per applicazioni native del cloud

Il database SQL di Azure è una piattaforma distribuita come servizio (PaaS) che offre scalabilità elevata, può rappresentare una soluzione ottimale per determinati carichi di lavoro e richiede un impegno di manutenzione minimo.

Il database SQL di Azure è finalizzato allo sviluppo di nuove applicazioni perché offre agli sviluppatori una grande flessibilità nella creazione di nuovi servizi applicazione e opzioni di distribuzione differenziate su larga scala. Il database SQL rappresenta una soluzione di manutenzione ridotta che può essere un'ottima opzione per determinati carichi di lavoro.

Modello di acquisto

Il database SQL è disponibile in due modelli di acquisto principali, basati rispettivamente su vCore e su DTU. Ogni modello di acquisto offre i livelli di servizio seguenti:

Basato su vCore

In questo modello di acquisto, le risorse di calcolo e di archiviazione sono disgiunte. In altre parole, è possibile ridimensionare le risorse di archiviazione e di calcolo in modo indipendente l'una dall'altra. Di seguito sono elencati i livelli di servizio disponibili:

Livello di servizio	Capacità
Utilizzo generico	Questo livello di servizio è progettato per operazioni meno impegnative e offre opzioni di calcolo e archiviazione orientate al budget. Fornisce sia un livello di calcolo con provisioning sia un livello di calcolo serverless.
Essenziale per l'azienda	Questo livello di servizio supporta OLTP in memoria e replica di sola lettura predefinita. Include anche una maggiore quantità di memoria per core e usa l'archiviazione SSD locale, progettata per i carichi di lavoro con particolari requisiti di prestazioni.
Hyperscale	Il livello di servizio Hyperscale introduce funzionalità di scalabilità orizzontale basate su tecniche avanzate per aggiungere nodi di calcolo man mano che aumentano le dimensioni dei dati. È supportato solo in un singolo database SQL. Hyperscale consente di ridimensionare le risorse di archiviazione e di calcolo in modo rilevante rispetto ai limiti disponibili per i livelli di servizio per utilizzo generico e business critical.

Basato su DTU

Nel modello DTU sono disponibili 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 in base a un limite di archiviazione fisso, all'intervallo di conservazione dei backup e al costo.

Se ad esempio il database aumenta fino a raggiungere il limite massimo di archiviazione, è necessario aumentare la capacità di DTU, anche se l'utilizzo delle risorse di calcolo è limitato.

Quando si esegue il ridimensionamento nel database SQL può verificarsi una breve interruzione della connessione al termine dell'operazione. Questo comportamento può essere attivato da due principali modifiche:

• Dopo l'avvio di un'operazione di ridimensionamento che richiede un failover interno.
• Quando si aggiungono o si rimuovono database nel pool elastico.

Per gestire gli errori di connessione è possibile usare una logica di ripetizione dei tentativi appropriata nell'applicazione.

Livello di elaborazione serverless

Nonostante il nome, il livello di calcolo serverless richiede comunque la presenza di un server con il database. L'opzione serverless può essere considerata come una soluzione di scalabilità automatica e sospensione automatica per il database SQL. È efficace per ridurre i costi in ambienti di sviluppo e test. Ad esempio, è possibile configurare una configurazione minima e massima di vCore per il database, in cui viene ridimensionata in modo dinamico in base al carico di lavoro.

La funzionalità ritardo sospensione automatica consente di definire il periodo di tempo in cui il database sarà inattivo prima che venga sospeso automaticamente. La funzionalità di ritardo sospensione automatica può essere configurata da 1 ora a 7 giorni. In alternativa, la funzionalità ritardo sospensione automatica può essere disabilitata.

L'operazione di ripristino viene attivata quando viene eseguito il successivo tentativo di accesso al database. Inoltre, quando il database viene sospeso, vengono applicati solo gli addebiti relativi alle risorse di archiviazione.

L'immagine precedente mostra dove è possibile modificare la scalabilità automatica e le proprietà di sospensione automatica per il livello di elaborazione serverless.

Modello di distribuzione

Esistono due modelli di distribuzione principali per il database SQL in Azure: database singolo e pool elastico. I pool elastici condividono le risorse con altri database dello stesso pool, mentre le risorse dei database singoli vengono gestite in modo indipendente.

Il database SQL, come le macchine virtuali, può essere distribuito usando modelli di Azure Resource Manager, PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure.

Database singolo

Il database singolo è il modello di distribuzione più semplice del database SQL di Azure. Ognuno dei database viene gestito singolarmente dal punto di vista della scalabilità e della dimensione dei dati. Ogni database distribuito in questo modello ha risorse dedicate, anche se distribuite nello stesso server logico.

È possibile monitorare l'utilizzo delle risorse del database tramite il portale di Azure. Questa funzionalità consente di identificare facilmente le prestazioni del database, come illustrato nell'immagine seguente:

Pool elastico

I pool elastici consentono di allocare le risorse di archiviazione e calcolo a un gruppo di database, anziché dover gestire le risorse singolarmente per ogni database. Inoltre, i pool elastici sono più facili da ridimensionare rispetto ai singoli database, per i quali il ridimensionamento non è più necessario a causa delle modifiche apportate al pool elastico.

I pool elastici offrono una soluzione economicamente vantaggiosa per il modello applicativo di software come un servizio, poiché le risorse vengono condivise tra tutti i database. È possibile configurare le risorse in base al modello di acquisto basato su DTU o al modello di acquisto basato su vCore.

A causa della natura di questa funzionalità, è consigliabile monitorare continuamente le risorse per identificare continuamente i picchi di prestazioni simultanei che potrebbero influire su altri database dello stesso pool elastico. Spesso può essere necessario rivedere la strategia di allocazione per assicurarsi che siano disponibili risorse sufficienti per tutti i database che condividono lo stesso pool elastico.

Il pool elastico è ideale per l'architettura multi-tenant con un utilizzo medio basso, in cui ogni tenant ha una propria copia del database.

Opzioni di rete

Per impostazione predefinita, il database SQL di Azure ha un endpoint Internet pubblico. L'accesso a questo endpoint può essere controllato tramite regole del firewall oppure può essere limitato a reti di Azure specifiche, usando funzionalità come endpoint di Rete virtuale o collegamento privato.

Backup e ripristino

Azure offre semplici funzionalità di backup e ripristino per il database SQL e per Istanza gestita di SQL. Di seguito verranno esaminate alcune delle funzionalità più importanti.

Backup continuo

Con il database SQL è possibile aumentare l'efficienza di amministrazione sapendo che viene eseguito regolarmente il backup dei database e che i backup vengono copiati continuamente in un'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS).

Vengono eseguiti backup completi una volta alla settimana, backup differenziali a intervalli compresi tra 12 e 24 ore e backup dei log delle transazioni a intervalli compresi tra 5 e 10 minuti.

Ripristino geografico

Poiché per il database SQL e Istanza gestita di SQL i backup sono ridondanti geograficamente per impostazione predefinita, è possibile ripristinare facilmente i database in un'area geografica diversa, una soluzione particolarmente utile per gli scenari di ripristino di emergenza meno rigorosi.

L'archiviazione dei backup viene fatturata a parte rispetto alla normale archiviazione dei file di database. Tuttavia, quando si esegue il provisioning di un database SQL, la risorsa di archiviazione dei backup viene creata con la dimensione massima del livello dati selezionato per il database senza costi aggiuntivi.

La durata di un'operazione di ripristino geografico può dipendere da diversi componenti sottostanti, tra cui la dimensione del database, il numero di log delle transazioni coinvolti in un'operazione di ripristino e la quantità di richieste di ripristino simultanee elaborate nell'area di destinazione.

Ripristino temporizzato

È possibile configurare un criterio di conservazione temporizzato specifico per ogni database eseguito in base a un'offerta di database SQL. Come periodo di conservazione del database SQL è possibile impostare un valore compreso tra 1 e 35 giorni. Se questo valore non è specificato, la configurazione predefinita è sette giorni.

È possibile ripristinare i database in un momento specifico in base al periodo di conservazione definito. Tuttavia, il ripristino temporizzato è possibile solo se il database viene ripristinato nello stesso server in cui è stato generato il backup. Per ripristinare un database SQL è possibile usare il portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Azure o l'API REST.

Conservazione a lungo termine (LTR)

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.

Nell'immagine precedente viene illustrato come configurare criteri di conservazione a lungo termine tramite il portale di Azure. Dopo aver selezionato il database, viene aperto un nuovo pannello sul lato destro dello schermo in cui è possibile eseguire l'override delle proprietà predefinite.

Per altre informazioni sui backup automatizzati, vedere Backup automatizzati - Database SQL di Azure e Istanza gestita di SQL di Azure.

Ottimizzazione automatica

L'ottimizzazione automatica è una funzionalità predefinita che si basa sulle capacità di regressione di Machine Learning e identifica automaticamente le opportunità di ottimizzazione in base alle prestazioni delle query.

L'ottimizzazione automatica include attualmente le funzioni seguenti:

• Identificazione di query costose
• Utilizzo forzato dell'ultimo piano di esecuzione valido
• Aggiunta di indici
• Rimozione di indici

I servizi di Azure usano una combinazione di funzionalità avanzate predefinite per determinare gli indici ottimali per il modello di query. Questi indici vengono inizialmente testati su una copia del database e infine applicati al database.

Tutti i database ereditano la configurazione dal server padre ed è possibile disabilitare facilmente questa funzionalità in qualsiasi momento.

Query elastica (anteprima)

La funzionalità Query elastica consente di eseguire query T-SQL per connettere più database nel database SQL. Questa funzionalità è utile per le applicazioni che usano nomi costituiti da tre e quattro parti che non sono modificabili. Migliora anche la portabilità in quanto consente la migrazione.

Le query elastiche supportano le strategie di partizionamento seguenti:

Livello di servizio	Capacità
Partizionamento verticale	Questa strategia è detta anche query tra database. I dati vengono partizionati verticalmente tra molti database. Per ogni database vengono usati schemi diversi. Si supponga, ad esempio, di avere un database per i dati dei clienti e un altro database per le informazioni di pagamento. Con l'aiuto del partizionamento verticale, è ora possibile eseguire una query tra entrambi i database.
Partizionamento orizzontale	Con questa strategia i dati vengono partizionati orizzontalmente per distribuire le righe tra diversi database con scalabilità orizzontale. In questa topologia lo schema rimane invariato per tutti i database di partizionamento orizzontale. È supportato un modello con tenant singolo oppure modelli con più tenant.

Lavori elastici

La funzionalità Processo elastico viene usata in sostituzione di SQL Server Agent per il database SQL di Azure. Per certi versi, il processo elastico equivale alla funzionalità Amministrazione multiserver disponibile in un'istanza di SQL Server locale.

È possibile eseguire comandi T-SQL in diverse distribuzioni di destinazione, ad esempio database SQL, pool elastici di database SQL e database SQL in mappe di partizioni. Le risorse del database possono essere eseguite in diverse sottoscrizioni e/o aree di Azure. L'esecuzione avviene in parallelo e questo è utile quando si automatizzano le attività di manutenzione del database.

Database SQL in Fabric

Il database SQL in Microsoft Fabric è una soluzione potente e versatile progettata per integrarsi perfettamente con l'ecosistema Microsoft più ampio. Consente agli utenti di usare le funzionalità dei database SQL all'interno dell'ambiente Microsoft Fabric, offrendo una piattaforma unificata per la gestione e l'analisi dei dati. Questa integrazione consente alle organizzazioni di semplificare i flussi di lavoro dei dati, migliorare la collaborazione e guidare processi decisionali più informati.

Inoltre, il database SQL in Microsoft Fabric supporta un'ampia gamma di casi d'uso, dai carichi di lavoro operativi e transazionali all'analisi avanzata. Questa flessibilità rende la scelta ideale per le organizzazioni che vogliono consolidare l'infrastruttura dei dati e sfruttare il potenziale completo degli asset di dati. Con funzionalità come l'integrazione senza problemi con altri servizi Microsoft, sicurezza avanzata e scalabilità, il database SQL in Microsoft Fabric consente agli utenti di creare e distribuire applicazioni guidate dai dati con facilità.

Il carico di lavoro database in Fabric è progettato per affrontare molti aspetti dei database SQL operativi, consentendo ai data engineer, agli analisti e agli scienziati dei dati di collaborare per creare ed eseguire query sui dati ottimizzati per le proprie esigenze specifiche.