Aumentare il numero di istanze con il database SQL di Azure

È possibile aumentare facilmente il numero di istante dei database SQL di Azure con gli strumenti dei database elastici . Questi strumenti e funzionalità consentono di usare le risorse di database virtualmente illimitate di Database SQL di Azure per creare soluzioni per carichi di lavoro transazionali e soprattutto applicazioni SaaS (Software as a Service). Le funzioni di database elastico sono costituite dai seguenti elementi:

Nel grafico seguente è illustrata un'architettura che include le funzionalità dei database elastici in relazione a una raccolta di database.

In questo grafico, i colori del database rappresentano gli schemi. I database con lo stesso colore condividono gli stessi schemi.

  1. Un set di database SQL di Azure è ospitato in Azure tramite l'architettura di partizionamento orizzontale.
  2. La libreria client di database elastici viene utilizzata per gestire un set di partizioni.
  3. Un subset dei database viene inserito in un pool elastico. Vedere l'articolo su che cos'è un pool.
  4. Un Processo di database elastico esegue gli script T-SQL pianificati o ad-hoc in tutti i database.
  5. Lo strumento di suddivisione-unione viene utilizzato per spostare i dati da una partizione a un’altra.
  6. La query di database elastico consente di scrivere una query che si estende a tutti i database nel set di partizioni.
  7. Transazioni di database elastico è una funzionalità che consente di eseguire transazioni che si estendono su più database.

Strumenti di database elastici

Perché usare gli strumenti?

Il raggiungimento dell’elasticità e della scalabilità delle applicazioni cloud è stato semplice per le VM e l'archiviazione BLOB in quanto è bastato aggiungere o sottrarre le unità nonché aumentare la potenza. Tuttavia, resta una sfida per l’elaborazione dei dati con stato in database relazionali. Sfide emerse in questi scenari:

  • Aumento e riduzione della capacità per la parte del carico di lavoro relativa al database relazionale.
  • Gestione degli hotspot che potrebbero verificarsi interessando un subset specifico di dati, quali ad esempio clienti finali (tenant) particolarmente impegnati.

In genere, questi scenari sono stati affrontati effettuando investimenti in server di database di scala maggiore per supportare l'applicazione. Questa opzione offre però possibilità limitate negli ambienti cloud, in cui l'intera elaborazione viene eseguita su appositi componenti hardware predefiniti. Invece, la distribuzione dei dati e l’elaborazione in molti database strutturati in modo identico (un modello di scalabilità orizzontale noto come "partizionamento orizzontale") fornisce un'alternativa agli approcci tradizionali di scalabilità verticale sia in termini di costi che di elasticità.

Scalabilità orizzontale e verticale

Nella figura seguente vengono illustrate le dimensioni orizzontali e verticali della scalabilità, che sono i metodi di base in cui possono essere ridimensionati i database elastici.

Scalabilità orizzontale e verticale

Per scalabilità orizzontale si intende l’aggiunta o la rimozione di database per regolare le prestazioni complessive o la capacità. Detta anche “scaling out”. Il partizionamento orizzontale, in cui i dati vengono partizionati in una raccolta di database strutturati in modo identico, è un approccio comune per implementare la scalabilità orizzontale .

Per scalabilità verticale si intende l’aumento o la riduzione del livello delle prestazioni di un singolo database ed è nota anche come "scaling up".

La maggior parte delle applicazioni di database su scala cloud utilizzano una combinazione di questi due strategie. Un'applicazione di software come servizio può, ad esempio, utilizzare la scalabilità orizzontale per eseguire il provisioning di nuovi clienti finali e la scalabilità verticale per consentire l’espansione o la riduzione delle risorse del database di ogni cliente finale in base alle esigenze del carico di lavoro.

  • La scalabilità orizzontale è gestita tramite la Libreria client di database elastici.
  • La scalabilità verticale viene eseguita con i cmdlet di Azure PowerShell per modificare il livello di servizio o posizionando i database in un pool elastico.

Partizionamento orizzontale

Partizionamento orizzontale è una tecnica per distribuire grandi quantità di dati strutturati in modo identico tra più database indipendenti. È molto usato dagli sviluppatori cloud che creano offerte Software as a Service (SAAS) per clienti finali o aziende. Questi clienti finali vengono spesso definiti "tenant". Il partizionamento orizzontale può essere necessario per vari motivi:

  • La quantità totale di dati è troppo elevata per un singolo database
  • La velocità effettiva delle transazioni del carico di lavoro complessivo supera le capacità di un singolo database
  • Può essere necessario isolare fisicamente i tenant, quindi predisporre database separati per ogni tenant
  • È possibile che sezioni diverse di un database risiedano in aree geografiche diverse per motivi di conformità, di prestazioni o geopolitici.

In altri scenari, ad esempio l'inserimento di dati da dispositivi distribuiti, il partizionamento orizzontale può essere usato per riempire un set di database organizzati secondo una logica temporale. Ad esempio, è possibile destinare un database separato a ogni giorno o settimana. In tal caso, la chiave di partizionamento orizzontale può essere un integer che rappresenta la data (presente in tutte le righe delle tabelle partizionate) e l'applicazione deve instradare le query che recuperano informazioni per un intervallo di date al subset di database che coprono l'intervallo in questione.

Il partizionamento orizzontale rappresenta la scelta ottimale quando tutte le transazioni in un'applicazione possono essere limitate a un singolo valore di una chiave di partizionamento orizzontale. Questo garantisce che tutte le transazioni saranno locali rispetto a uno specifico database.

Multi-tenant e single-tenant

Alcune applicazioni usano l'approccio più semplice di creare un database separato per ogni tenant. Questo è il modello di partizionamento orizzontale per singolo tenant , che offre isolamento, funzionalità di backup e ripristino e scalabilità delle risorse in base alla granularità del tenant. Con il partizionamento orizzontale per singolo tenant, ogni database è associato a uno specifico valore di ID tenant (o valore di chiave del cliente), ma tale chiave non deve essere necessariamente presente nei dati. È responsabilità dell'applicazione indirizzare ogni richiesta al database appropriato e la libreria client può semplificare questa operazione.

Single-tenant e multi-tenant

Altri scenari prevedono di riunire più tenant all'interno dei database, anziché isolarli in database separati. Si tratta di un modello di partizionamento orizzontale multi-tenant tipico e la scelta di un modello di questo tipo può essere dovuta al fatto che un'applicazione gestisce un numero elevato di tenant di dimensioni molto limitate. Nel partizionamento orizzontale multi-tenant, tutte le righe delle tabelle di database sono progettate per contenere una chiave che identifica l'ID tenant o una chiave di partizionamento orizzontale. Anche in questo caso, il livello applicazione è responsabile dell'instradamento delle richieste del tenant al database appropriato e questo può essere supportato dalla libreria client dei database elastici. Inoltre, la sicurezza a livello di riga può essere utilizzata per filtrare le righe a cui ogni tenant può accedere: per informazioni dettagliate, vedere Applicazioni multi-tenant con strumenti di database elastici e sicurezza a livello di riga. Con lo schema di partizionamento orizzontale multi-tenant potrebbe essere necessaria la ridistribuzione dei dati tra database e questa operazione è facilitata dallo strumento di suddivisione-unione dei database elastici. Per altre informazioni sui modelli di progettazione per le applicazioni SaaS mediante pool elastici, vedere Modelli di progettazione per applicazioni SaaS multi-tenant con database SQL di Azure.

Spostare i dati da database a più tenancy a database a singolo tenancy

Quando si crea un'applicazione SaaS, in genere ai clienti potenziali viene offerta una versione di valutazione del software. In questo caso, è conveniente utilizzare un database multi-tenant per i dati. Tuttavia, quando un potenziale cliente diventa un cliente reale, è consigliabile utilizzare un database single-tenant, poiché garantisce prestazioni migliori. Se il cliente ha creato dati durante il periodo di valutazione, utilizzare lo strumento di suddivisione-unione per spostare i dati dal database multi-tenant al nuovo database single-tenant.

Passaggi successivi

Per un'app di esempio che illustra la libreria client, vedere Iniziare a usare gli strumenti di database elastici.

Per convertire i database esistenti e usare gli strumenti, vedere l'articolo sulla migrazione dei database esistenti per aumentare il numero di istanze.

Per visualizzare le specifiche del pool elastico, vedere Considerazioni di prezzo e prestazioni per un pool elastico oppure creare un nuovo pool con pool elastici.

Risorse aggiuntive

Se non si usano gli strumenti di database elastici, vedere la Guida introduttiva. Se ci sono domande, è possibile visitare il forum sul database SQL mentre è possibile inserire le richieste di nuove funzionalità nel forum relativo a commenti e suggerimenti sul database SQL.