Multitenancy e database SQL di Azure

Le soluzioni multi-tenant in Azure usano in genere database SQL di Azure. Questo articolo descrive le strategie di partizionamento e tenancy e le funzionalità del database SQL per soluzioni multi-tenant.

Leggere questo articolo insieme a Architectural approaches for storage and data in multitenant solutions, che descrive considerazioni generali e approcci applicabili nei vari servizi dati.

Strategie di partizionamento e tenancy

Scegliere il modello di tenancy che soddisfi i requisiti di scalabilità, isolamento, ripristino, personalizzazione e costi del carico di lavoro. Preferisci il modello più semplice che soddisfi tali requisiti. Il partizionamento orizzontale aggiunge complessità applicativa e operativa, quindi non introdurlo solo per aggirare i limiti che un livello di servizio più grande può soddisfare.

Per confrontare i compromessi architetturali dei modelli comuni di tenancy database SQL di Azure, vedere Come scegliere il modello di tenancy appropriato.

Decidere se usare uno o più database

Un singolo database SQL ha una capacità di archiviazione limitata. La velocità effettiva e la concorrenza sono vincolate dal livello di servizio, dalla configurazione di calcolo, dai limiti di connessione e dalle caratteristiche del carico di lavoro. Valutare i requisiti aggregati e per tenant per archiviazione, velocità effettiva, concorrenza, latenza, isolamento, ripristino e configurazione regionale prima di scegliere un database condiviso, un database per ogni tenant o una topologia partizionata.

Il perimetro del database determina anche la granularità delle operazioni di backup, ripristino, replica geografica e failover. Per altre informazioni, vedere Procedure consigliate per l'architettura per database SQL di Azure.

Un database multi-tenant condiviso può offrire una densità elevata e un costo basso per tenant, ma più database potrebbero essere appropriati prima che un singolo database raggiunga i limiti tecnici se i tenant richiedono un isolamento più forte o operazioni di configurazione e del ciclo di vita indipendenti.

È possibile combinare modelli di tenancy. Ad esempio, è possibile inserire la maggior parte dei tenant nei database condivisi e offrire database dedicati ai tenant con esigenze elevate o regolamentati. Usare un catalogo tenant per instradare ogni tenant al database appropriato.

Valutare il livello di servizio Hyperscale quando le dimensioni del database, la durata di backup e ripristino, la scalabilità in lettura o il ridimensionamento rapido del calcolo determinano la progettazione. Hyperscale supporta la crescita automatica dell'archiviazione fino a 128 TB per un database e fino a 100 TB per un pool elastico Hyperscale. Se un'architettura esistente usa il partizionamento orizzontale solo per aggirare i limiti di archiviazione del database, è consigliabile consolidare le partizioni in un database Hyperscale. Verificare la velocità effettiva di scrittura, i costi, gli obiettivi di ripristino, l'isolamento e i requisiti operativi prima di consolidare.

Database condiviso multi-tenant

In un database condiviso archiviare un identificatore del tenant in ogni tabella contenente i dati di proprietà del tenant. Propaga l'identità autenticata dell'utente e del tenant nel database per ogni richiesta. Stabilisci e convalida questo contesto ogni volta che riutilizzi una connessione in pool anziché basarti sul contesto di una richiesta precedente. Usare la sicurezza a livello di riga come protezione applicata al database contro l'accesso ai dati tra tenant.

Tutti i tenant condividono la configurazione di calcolo, archiviazione, backup, ripristino e dell'area geografica del database. Questo modello è soggetto all'antipattern Noisy Neighbor, in cui il carico di lavoro di un tenant influisce su altri tenant. Il ripristino o lo spostamento di un tenant richiede l'estrazione e la convalida dei dati controllati dall'applicazione. Usare questo modello quando la densità e l'efficienza dei costi del tenant sono più importanti rispetto alla configurazione specifica del tenant o all'isolamento delle prestazioni elevato.

Database per inquilino

Usare un database separato per ogni tenant quando i tenant richiedono un maggiore isolamento dei dati e delle prestazioni, backup e ripristino indipendenti, personalizzazione dello schema, posizionamento a livello di area o attribuzione dei costi più chiara. L'applicazione deve mantenere un mapping affidabile da ogni identificatore del tenant al database e instradare le connessioni di conseguenza.

Posizionare i database con requisiti di prestazioni e ripristino compatibili nei pool elastici per condividere la capacità di calcolo provisionata. Usare Hyperscale o pool elastici Hyperscale quando i singoli database tenant richiedono funzionalità di archiviazione, backup, ripristino o scalabilità in lettura hyperscale.

Database multi-tenant con sharding

Usare i database multi-tenant partizionati quando la distribuzione dei tenant tra più database condivisi soddisfa meglio i requisiti di scalabilità, ripristino, densità dei tenant o costo del carico di lavoro rispetto a un singolo database condiviso o a una topologia database per tenant. Uno shard è un database Azure SQL che archivia uno o più tenant. Usare una chiave di partizione stabile, ad esempio un identificatore di tenant, in modo che l'applicazione possa determinare quale database archivia i dati di un tenant.

Considera il set di dati di ogni tenant come unità di posizionamento. Mantenere tutti i dati per un tenant in uno shard, quando possibile, in modo che le query e le transazioni con ambito tenant rimangano all'interno di un database. Mantenere un mapping da ogni identificatore di tenant al database che contiene i dati.

Una mappatura da tenant a database viene spesso definita shard map. Una mappa di partizionamento è un catalogo che esegue il mapping di ogni chiave di partizione o di un intervallo di chiavi al database in cui sono archiviati i dati associati. Implementa la mappa partizioni come metadati dell'applicazione durevoli che soddisfano i requisiti di disponibilità e coerenza del carico di lavoro. Le istanze dell'applicazione possono memorizzare nella cache le voci della mappa di partizionamento per ridurre la latenza di routing, ma devono aggiornare o invalidare le voci memorizzate nella cache quando i mapping cambiano.

Rendere la mappa di shard autorevole a disponibilità elevata e aggiornarla in modo atomico con le operazioni di migrazione del tenant. L'applicazione deve anche possedere il routing delle connessioni, il provisioning delle partizioni, lo spostamento del tenant, il ribilanciamento e la gestione dei guasti. Pianificare il modo in cui l'applicazione gestisce i mapping non aggiornati durante il cutover e il rollback. Per indicazioni generali sulla progettazione, vedere il modello di sharding.

Pianificare le operazioni su più database

Progettare ogni database come confine indipendente di transazione e integrità:

  • Preservare la localizzazione e l'integrità dei dati: Mantenere nello stesso database i dati che l'applicazione unisce o aggiorna in modo transazionale. Non creare dipendenze di integrità referenziale, trigger o stored procedure tra database. Per le operazioni aziendali che si estendono su database, usare la consistenza eventuale o un altro modello di coordinamento a livello di applicazione.
  • Gestire gli schemi in modo coerente: Usare le stesse tabelle, colonne, indici, viste e stored procedure in ogni partizione in modo che l'applicazione possa usare la stessa logica di accesso ai dati dopo aver instradato una richiesta a qualsiasi partizione. Automatizzare le distribuzioni dello schema nella flotta di database e tenere traccia della versione dello schema di ogni database. Se si supportano intenzionalmente variazioni dello schema, rendere l'applicazione e il processo di distribuzione compatibili con le versioni.
  • Gestire i dati di riferimento deliberatamente: Replicare i dati di riferimento statici o a variazione lenta quando ciò evita operazioni sincrone tra database. Definire il modo in cui l'applicazione propaga gli aggiornamenti e gestisce copie non aggiornate.
  • Bilanciare e posizionare le partizioni: Bilanciare le partizioni in base al volume di dati e al carico delle richieste, non solo in base al numero di tenant. Pianificare un processo automatizzato e recuperabile per spostare i tenant tra gli shard. Posizionare i database in base ai requisiti di latenza, residenza e ripristino di emergenza del tenant.

Usare Elastic jobs per modifiche pianificate dello schema, manutenzione, raccolta di dati di telemetria e altre operazioni tra gruppi di database. Per la creazione di report e l'analisi tra database tenant, usare un archivio analitico centralizzato, ad esempio Microsoft Fabric tramite mirroring per database SQL di Azure o una pipeline di estrazione, trasformazione e caricamento (ETL), ad esempio Azure Data Factory. Se un'applicazione richiede query di fanout sincrone, compilare un livello di query e aggregazione che definisce il timeout, i tentativi, l'errore parziale e il comportamento di unione dei risultati.

Funzionalità del database SQL che supportano la multi-tenancy

Il database SQL include molte funzionalità che supportano la multi-tenancy.

Pool di elasticità

I pool elastici condividono un set configurato di risorse di calcolo tra più database nello stesso server logico. I pool possono ridurre i costi quando i database tenant hanno un utilizzo medio ridotto e picchi di utilizzo poco frequenti e non sovrapposti. I database con utilizzo persistente da medio ad alto potrebbero essere più adatti alla capacità di calcolo dedicata. È possibile impostare limiti minimi e massimi delle risorse per i singoli database in pool per limitare il consumo delle risorse, ma tutti i database condividono comunque la capacità totale del pool. Monitorare sia l'utilizzo aggregato del pool che l'utilizzo dei singoli database.

Per altre informazioni, vedere le risorse seguenti:

Hyperscale

database SQL di Azure Hyperscale separa le risorse di calcolo dall'archiviazione in modo che sia possibile ridimensionarle in modo indipendente. Usare Hyperscale quando un database multi-tenant condiviso o un singolo database tenant richiede limiti di archiviazione più elevati, backup e ripristino rapidi o scalabilità orizzontale in lettura.

Per altre informazioni, vedere le risorse seguenti:

Lavori elastici

Usare processi Elastic per eseguire script Transact-SQL pianificati (T-SQL) e attività di manutenzione su uno o più database. I gruppi di destinazione possono includere database singoli, server logici, pool elastici e database in sottoscrizioni diverse. Gli usi multi-tenant comuni includono la distribuzione delle modifiche dello schema, la gestione delle credenziali, la raccolta di dati di telemetria e l'esecuzione di attività di elaborazione dati batch in una flotta di database.

I processi Elastic non forniscono un livello di query dell'applicazione sincrono. Se una richiesta di applicazione deve eseguire query su più database e aggregare immediatamente i risultati, implementare tale comportamento in un'applicazione o in un livello analitico.

Per altre informazioni, vedere Processi elastici nel database SQL di Azure.

Sicurezza a livello di riga

La sicurezza a livello di riga consente di applicare l'isolamento a livello di tenant nelle tabelle condivise. Per altre informazioni, vedere Implementazione della sicurezza a livello di riga in Azure SQL.

Gestione delle chiavi

database SQL di Azure usa la crittografia dati trasparente (TDE) per crittografare i dati a riposo. Se i tenant devono fornire le proprie chiavi di crittografia, usare database separati e configurare chiavi TDE gestite dal cliente a livello di database. Usare Always Encrypted quando il motore di database e i relativi operatori non devono avere accesso a valori in chiaro in colonne sensibili specifiche. Verificare la compatibilità delle applicazioni e delle query perché Always Encrypted limita alcune operazioni sulle colonne crittografate.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

  • Paul Burpo | Ingegnere Principale per i Clienti, FastTrack per Azure
  • John Downs | Ingegnere Software Principale, Azure Principi e Pratiche

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

  • Ultimo aggiornamento: