Multitenancy e Azure Cosmos DB

Questo articolo descrive le funzionalità di Azure Cosmos DB che è possibile usare per i sistemi multi-tenant. Fornisce indicazioni ed esempi su come usare Azure Cosmos DB in una soluzione multi-tenant.

Requisiti di multiutenza

Quando si pianifica una soluzione multi-tenant, è necessario soddisfare due requisiti chiave:

• Garantire la sicurezza e l'isolamento delle prestazioni tra i tenant. Il provider deve soddisfare i requisiti di sicurezza e assicurarsi che ogni tenant soddisfi i requisiti di prestazioni.

• Mantenere un costo basso per ogni tenant. Come provider, è necessario assicurarsi che il costo per l'esecuzione dell'applicazione rimanga sostenibile man mano che viene ridimensionato.

Questi due requisiti spesso sono in conflitto e richiedono di classificare una priorità rispetto all'altra. Le indicazioni contenute in questo articolo consentono di comprendere questi compromessi e prendere decisioni informate quando si progetta la soluzione multi-tenant.

Modalità di isolamento

Determinare il livello di isolamento necessario tra i tenant. Per la maggior parte delle soluzioni, è consigliabile usare una delle strategie seguenti, a seconda del carico di lavoro:

• Le soluzioni SaaS (Software as a Service) business-to-consumer (B2C) usano in genere una chiave di partizione per ogni tenant. Un esempio di questo tipo di soluzione è un'applicazione chatbot conversazionale che archivia la cronologia delle chat utente in Azure Cosmos DB.

• Le soluzioni SaaS business-to-business (B2B) usano in genere un account di database per ogni tenant. Un esempio di questo tipo di soluzione è un sistema di gestione dei contenuti (CMS) che le aziende acquistano per pubblicare contenuti digitali.

Per scegliere il modello di isolamento maggiormente adatto, prendi in considerazione il modello aziendale e i requisiti degli utenti. Ad esempio, nei modelli B2C, un'azienda vende un prodotto o un servizio direttamente a un singolo cliente. L'isolamento sicuro e delle prestazioni per ogni singolo cliente in genere non è necessario. Per una maggiore efficienza dei costi, queste applicazioni possono archiviare i dati per tutti i tenant nello stesso contenitore e le chiavi di partizione offrono isolamento logico.

Nei modelli B2B, tuttavia, i provider vendono SKU diversi che corrispondono a diversi livelli di prestazioni, garanzie del contratto di servizio o requisiti di isolamento. I provider vogliono offrire ai propri clienti la possibilità di gestire le proprie chiavi di crittografia, note anche come chiavi multi-tenant o gestite dal cliente. Per queste applicazioni, usare un account di database separato per ogni tenant in modo da poter ottimizzare e garantire prestazioni per ogni cliente. Quando si usano account di database separati, è anche possibile fornire chiavi gestite dal cliente. Questa funzionalità è disponibile solo a livello di account di database Azure Cosmos DB.

Modello chiave-di-partizione-per-inquilino

In un modello partition-key-per-tenant, lo stesso contenitore Azure Cosmos DB archivia tutti i dati per i tenant usando una chiave di partizione come /TenantId. I tenant condividono la velocità effettiva del contenitore.

Vantaggi

• Gestione semplificata: Tutti i tenant vengono inseriti in un unico contenitore partizionato dall'ID tenant. Questo approccio crea una sola risorsa fatturabile che fornisce e condivide RU/s tra più tenant. Questo modello è più facile da gestire perché un'unica impostazione RU/s influisce sul costo per l'intero carico di lavoro multi-tenant.

Compromessi e considerazioni

• Contesa delle risorse: La velocità effettiva condivisa (RU/s) tra i tenant dello stesso contenitore può causare contese durante i picchi di utilizzo. Questa contenzione può creare problemi di vicinato rumoroso e problemi di prestazioni se i tenant hanno carichi di lavoro elevati o sovrapposti. Usare questo modello di isolamento per i carichi di lavoro che non necessitano di RU/s garantiti per un singolo tenant e che possono condividere il throughput.

• Isolamento limitato: questo approccio fornisce l'isolamento logico, non l'isolamento fisico. Usare questo modello di isolamento per i carichi di lavoro che non richiedono prestazioni garantite per ogni tenant o chiavi gestite dal cliente per ogni tenant.

• Minore flessibilità: Se si isolano i tenant in base alla chiave di partizione, non è possibile personalizzare le funzionalità a livello di account, ad esempio la replica geografica, il ripristino temporizzato e le chiavi gestite dal cliente per ogni tenant.

Funzionalità di Azure Cosmos DB per la multi-tenancy

Azure Cosmos DB offre diverse funzionalità che consentono di ottimizzare le prestazioni e gestire i costi per le soluzioni multi-tenant. Queste funzionalità rispondono a problemi comuni, ad esempio problemi rumorosi vicini e consentono di archiviare i dati in modo efficiente ed eseguire query tra tenant.

Controllo del throughput

Le funzionalità seguenti aiutano a controllare il problema del vicino rumoroso quando si usa una chiave di partizione per isolare i tenant o avere più carichi di lavoro che usano lo stesso contenitore condiviso.

Chiavi di partizione gerarchiche

Per i carichi di lavoro con un numero elevato di operazioni di lettura in cui in genere si esegue una query in base al tenant, è consigliabile usare chiavi di partizione gerarchiche per ottenere i vantaggi seguenti:

• Archiviazione illimitata per ogni tenant: Impostare /TenantId come chiave di primo livello e un campo di cardinalità elevata come /id la chiave di secondo livello per garantire che ogni tenant abbia spazio di archiviazione illimitato. Potrebbe essere presente un'altra gerarchia nel carico di lavoro. Ad esempio, potrebbe essere necessario archiviare i dati per ogni utente in ogni tenant. In questo scenario, impostare /TenantId come chiave di primo livello, /UserId come chiave di secondo livello e /id come chiave di terzo livello per garantire l'archiviazione illimitata per ogni utente in un tenant.

  Nota

  Le funzionalità di Azure Cosmos DB, ad esempio stored procedure e transazioni batch atomiche, sono disponibili solo a livello di chiave di partizione logica completa. Se si usano chiavi di partizione gerarchiche e partizioni /id come chiave di ultimo livello, non è possibile eseguire stored procedure o eseguire una transazione batch atomica a livelli parziali.

  Ad esempio, se si partiziona per /TenantId, /UserId e /id, non è possibile eseguire una stored procedure o eseguire una transazione batch atomica specificando solo /TenantId o solo /TenantId e /UserId. Se è necessario usare queste funzionalità, non impostare /id come chiave di ultimo livello.

• Query efficienti: Le query che specificano /TenantId o sia /TenantId che /UserId vengono instradate in modo efficiente solo al sottoinsieme di partizioni fisiche che contiene i dati pertinenti, evitando una query di fan-out completa. Se il contenitore ha 1.000 partizioni fisiche, ma un valore specifico /TenantId è solo su 5 partizioni fisiche, la query viene instradata al numero inferiore di partizioni fisiche pertinenti.

Usare chiavi di partizione gerarchica quando si ha una cardinalità elevata di valori e una distribuzione uniforme dei volumi di richiesta per le chiavi di primo livello. In un'impostazione multi-tenant è consigliabile avere molti tenant, idealmente nell'ordine di centinaia o migliaia di tenant e i tenant devono avere un modello di utilizzo simile.

Una partizione calda e prestazioni degradate potrebbero verificarsi negli scenari seguenti:

• Tu lavori con pochi clienti.

• Si lavora con un carico di lavoro asimmetrico in cui un singolo tenant usa costantemente più UR/sec rispetto agli altri tenant, anche quando si usano chiavi di partizione gerarchiche.

Non usare chiavi di partizione gerarchiche per i carichi di lavoro in cui non si ha una cardinalità elevata per ogni tenant o quando è necessario ottimizzare le prestazioni di scrittura. In questi scenari, è consigliabile usare chiavi di partizione sintetiche o partizionamento solo da /id. Questi approcci consentono di distribuire le scritture in modo uniforme in tutte le partizioni fisiche.

È possibile costruire una chiave sintetica in modo da ottimizzare per alcune query. Ad esempio, una TenantId_UserId chiave sintetica riduce leggermente la distribuzione uniforme dei dati in tutte le partizioni, ma consente di eseguire query in modo efficiente per un utente specifico in un tenant quando si specifica la chiave di partizione completa. L'ottimizzazione delle query è il vantaggio principale dell'uso di una chiave sintetica anziché di /id.

Tuttavia, se il carico di lavoro ottimizza la velocità effettiva di scrittura, le query potrebbero non essere rilevanti. È possibile partizionare solo /id per semplificare il carico di lavoro.

Se si usano alcuni tenant di grandi dimensioni che richiedono in modo coerente volumi di richieste più elevati rispetto ad altri tenant, è consigliabile isolare tali tenant nei propri account di database. Mantenere i tenant rimanenti in un contenitore condiviso.

Modello database-account-per-tenant

Nel modello database-account-per-tenant i dati di ogni tenant vengono archiviati nel proprio account di database Azure Cosmos DB. All'interno di ogni account, più contenitori per carichi di lavoro o microservizi diversi accedono ai dati per un tenant. Ogni contenitore ha una velocità effettiva dedicata (UR/sec).

Vantaggi

• Alta isolamento: Questo approccio evita problemi di contesa o di vicini rumorosi perché i dati di ogni locatario si trovano nel proprio account dedicato di Azure Cosmos DB. Ogni contenitore all'interno dell'account ha RU/s dedicate.

• Contratti di servizio personalizzati: Ogni tenant ha un proprio account, in modo da poter fornire risorse personalizzate specifiche, contratti di servizio rivolti ai clienti e garanzie, perché è possibile ottimizzare le risorse nell'account di database di ogni tenant in modo indipendente per soddisfare le proprie esigenze di prestazioni.

• Sicurezza avanzata: Questo approccio consente chiavi gestite dal cliente a livello di account di database, in modo che il provider possa offrire chiavi gestite dal cliente per ogni tenant. Se sono necessarie chiavi gestite dal cliente, è necessario usare l'isolamento database-account-per-tenant.

• Flessibilità: È possibile attivare funzionalità a livello di account, ad esempio la replica geografica, il ripristino temporizzato e le chiavi gestite dal cliente a livello di account (account di database) in base alle esigenze.

Compromessi e considerazioni

• Più account da gestire: Questo approccio può essere più complesso perché sono presenti più account Azure Cosmos DB che rappresentano un tenant o un cliente. Tuttavia, è possibile usare Azure Cosmos DB flotta per semplificare la gestione degli account condividendo la velocità effettiva (UR/sec) tra più account di database. È anche possibile usare l'analisi della flotta per monitorare l'utilizzo su larga scala.

• Limitazioni delle query tra tenant: Tutti i tenant si trovano in account diversi, quindi le applicazioni che eseguono query su più tenant richiedono più chiamate all'interno della logica dell'applicazione. In genere, queste query tra tenant non fanno parte del carico di lavoro transazionale principale che fornisce il servizio a ogni tenant. Fanno invece parte di un carico di lavoro analitico che consente al provider di servizi di comprendere meglio le tendenze e l'utilizzo più ampi tra i diversi tenant o clienti. Per questi casi d'uso, usare mirroring in Microsoft Fabric.

Funzionalità di Azure Cosmos DB per la multi-tenancy

• Pool delle flotte di Azure Cosmos DB: Le pool delle flotte consentono ai clienti che creano applicazioni multi-tenant di gestire, monitorare e ottimizzare la flotta di account di database. All'interno di una flotta, è possibile organizzare i tenant o gli account di database in raggruppamenti logici denominati fleetspaces. È anche possibile configurare un pool facoltativo di capienza (RU/s) che tutti gli account di database nell'ambiente fleetspace possono condividere. Questo approccio consente di ottimizzare i costi.

  

  Il diagramma mostra la struttura di una flotta Azure Cosmos DB e i relativi componenti. Nella parte superiore, un'icona dell'edificio etichettata flotta accompagna una didascalia. Il callout spiega che una flotta è un'entità di alto livello che archivia gli spazi di flotta ed esegue il mapping alle app multi-tenant. Sotto l'icona della flotta, una linea orizzontale che indica la velocità effettiva condivisa tra spazi flotta si connette a una scatola etichettata pool della flotta con una capacità di 100.000 RU/s. Il pool di flotta contiene tre settori di flotta. Oltre agli spazi di flotta, un altro callout spiega che gli spazi di flotta sono raggruppamenti logici di account di database all'interno di una flotta, che è possibile distribuire gli spazi di flotta tra più sottoscrizioni e che è possibile usare gli spazi di flotta per raggruppare classi simili di tenant. Il richiamo indica anche che è possibile configurare un pool opzionale per condividere RU/sec. Ogni fleetspace include più icone di database e un'ellissi per indicare ulteriori database. Un altro callout spiega che tutte le risorse in uno fleetspace condividono il pool di RU/s.

  Molti provider creano una flotta per ogni area in cui operano e separano ulteriormente i tenant in spazi di flotta in base ai requisiti di prestazioni del tenant o alla classe di tenant.

  Ad esempio, per la loro flotta East US 2, un provider potrebbe creare un fleetspace per gli account che appartengono a tenant che usano una versione di valutazione gratuita poiché richiedono un minor numero di RU/s del pool. Il provider crea un altro fleetspace per gli account che appartengono ai tenant che firmano un accordo aziendale perché richiedono più RU/s.

  Questi pool consentono di condividere RU/s tra più account, anche se si estendono su diverse sottoscrizioni e gruppi di risorse all'interno di una flotta. Le risorse in ogni account mantengono le proprie UR/sec dedicate e i pool consentono agli account di usare automaticamente UR/sec aggiuntive dal pool condiviso quando necessario. Questo approccio consente di evitare il provisioning eccessivo.

  Anziché effettuare il provisioning dei contenitori di ogni tenant per il picco di UR/sec, che può risultare costoso, è possibile impostare un valore tipico di UR/s per contenitore e usare la capacità condivisa del pool per gestire i picchi.

• Protezione contro i vicini rumorosi: Per progettazione, qualsiasi throughput di cui è stato effettuato il provisioning in un contenitore è dedicato e garantito per essere sempre disponibile a quel contenitore. Altri contenitori non possono usare UR/sec dedicate. Un contenitore che richiede una maggiore velocità effettiva può usare RU/s solo dal pool condiviso.

• Scalabilità automatica: I pool possono sempre essere ridimensionati automaticamente ed è possibile configurare il pool per la scalabilità automatica tra un numero minimo e massimo di UR/sec. Le UR/s del pool hanno lo stesso prezzo unitario delle UR/sec normali di cui si effettua il provisioning in un contenitore, quindi lo spostamento dell'utilizzo in un pool condiviso consente di risparmiare sui costi.

• Analytics: Attiva l'analisi della tua flotta Azure Cosmos DB per monitorare l'utilizzo e tracciare le tendenze cronologiche tra i tenant.

  L'analisi della flotta trasmette i dati sull'utilizzo e sui costi per ogni account di database, database e contenitore all'interno della flotta per Fabric o per un account Archiviazione di Azure, in modo da poter eseguire analisi a lungo termine degli account all'interno della flotta. Usare questi dati per tenere traccia delle tendenze come gli account più attivi, la scalabilità delle risorse nel tempo e la rotazione più recente delle chiavi di accesso. È anche possibile usare dati di telemetria non elaborati per scrivere query personalizzate o creare dashboard Power BI per analizzare i dati di utilizzo dei tenant.

• Funzionalità di sicurezza: Il modello account-per-tenant offre un maggiore isolamento della sicurezza dell'accesso ai dati tramite Azure Role-Based Access Control (RBAC). Questo modello è anche l'unica opzione che fornisce l'isolamento della sicurezza a livello di tenant tramite chiavi gestite dal cliente.

• Configurazione personalizzata: È possibile impostare il percorso dell'account del database in base ai requisiti del tenant. È anche possibile ottimizzare la configurazione delle funzionalità di Azure Cosmos DB, ad esempio la replica geografica e le chiavi di crittografia gestite dal cliente, in base ai requisiti di ogni tenant.

  Quando si usa un account Azure Cosmos DB dedicato per ogni tenant, prendere in considerazione il numero massimo di account Azure Cosmos DB per sottoscrizione di Azure.

Riepilogo dei modelli di isolamento consigliati

Modelli di isolamento non consigliati

È consigliabile usare i modelli di isolamento partition-key-per-tenant e database-account-per-tenant per la maggior parte degli scenari multi-tenant. L'isolamento per contenitore o database è possibile, ma questi approcci hanno in genere compromessi che i modelli di isolamento consigliati affrontano in modo più efficace.

Modello contenitore per tenant

È possibile effettuare il provisioning di contenitori dedicati, ognuno con le proprie RU/s, per ciascun tenant e inserirli in un account di database di Azure Cosmos DB. Ogni account di database può contenere solo un numero limitato di contenitori, pertanto potrebbero essere necessari più account per contenere i dati per tutti i tenant. È necessario tenere traccia dell'account di database contenente i dati per ogni cliente, che aggiunge complessità all'applicazione.

Azure Cosmos DB limita anche il throughput per le operazioni sui metadati e il numero di database o contenitori per ogni account. Le operazioni sui metadati includono la lettura dell'elenco di database o contenitori in un account e la lettura e l'aggiornamento delle impostazioni del contenitore. A causa di questi limiti, questo modello non è consigliato. Se un singolo account ha più tenant, il volume delle operazioni sui metadati aumenta e potrebbe non essere ridimensionato in modo efficace. Questo modello potrebbe anche richiedere la gestione di più account per bilanciare molti tenant, aumentando la complessità della soluzione multi-tenant.

È possibile usare il modello container-per-tenant per ottenere l'isolamento delle prestazioni per ogni tenant configurando RU/s dedicate a livello di contenitore. È anche possibile migliorare la sicurezza usando Azure controllo degli accessi in base al ruolo. Ma il modello contenitore per tenant non supporta le chiavi gestite dal cliente. Le chiavi gestite dal cliente sono disponibili solo a livello di account di database.

Se disponi di molti contenitori in un account di database e hai bisogno di usare il controllo degli accessi in base al ruolo per il piano dati di Azure Cosmos DB per assegnare un ruolo a ogni contenitore, potresti incontrare limiti sul numero di assegnazioni di ruolo per account.

Se è necessario l'isolamento delle prestazioni o le chiavi gestite dal cliente, è consigliabile usare il modello database-account-per-tenant e i pool di flotta per ottimizzare i costi per ogni tenant. Se queste funzionalità non sono necessarie, è consigliabile usare il modello partition-key-per-tenant.

Modello di database per inquilino

È possibile effettuare il provisioning dei database per ogni tenant e inserirli nello stesso account di database. Analogamente al modello container-per-tenant, potrebbero essere necessari più account di database per contenere i dati per tutti i tenant e la logica dell'applicazione personalizzata per tenere traccia dell'account di database a cui appartiene un tenant.

È possibile usare il modello di database per tenant per ottenere l'isolamento delle prestazioni per ogni tenant configurando UR/sec condivise a livello di database o UR/sec dedicate per ogni contenitore. È anche possibile migliorare la sicurezza usando Azure controllo degli accessi in base al ruolo. Ma il modello di database per tenant non supporta le chiavi gestite dal cliente. In genere non è consigliabile usare UR/sec condivise a livello di database per carichi di lavoro con traffico elevato perché le prestazioni per ogni contenitore nel database non sono garantite.

Se è necessario l'isolamento delle prestazioni o le chiavi gestite dal cliente, è consigliabile usare il modello database-account-per-tenant e i pool di flotta per ottimizzare i costi per ogni tenant. Se queste funzionalità non sono necessarie, è consigliabile usare il modello partition-key-per-tenant.

Analogamente al modello contenitore per tenant, questo modello non è consigliato a causa dei limiti di Azure Cosmos DB per throughput per le operazioni sui metadati e il numero di database o contenitori per ogni account.

Azure Cosmos DB funzionalità a supporto della multitenancy

Usare le funzionalità di Azure Cosmos DB seguenti nella soluzione multi-tenant.

Partizionamento

Usare le partizioni con i contenitori di Azure Cosmos DB in modo da creare contenitori che più tenant condividono. In genere, si usa l'identificatore del tenant come chiave di partizione, ma è anche consigliabile usare più chiavi di partizione per un singolo tenant. Una strategia di partizionamento ben pianificata implementa efficacemente il modello di partizionamento orizzontale. Quando si hanno contenitori di grandi dimensioni, Azure Cosmos DB distribuisce i tenant in più nodi fisici per ottenere un livello elevato di scalabilità.

È consigliabile usare chiavi di partizione gerarchica per migliorare le prestazioni della soluzione multi-tenant. Usare chiavi di partizione gerarchica per creare una chiave di partizione che include più valori. Ad esempio, è possibile usare una chiave che include l'ID tenant come chiave di primo livello e un campo di cardinalità elevata, ad /id esempio per il livello successivo per garantire l'archiviazione illimitata per ogni tenant. In alternativa, è possibile specificare una chiave di partizione gerarchica che include una proprietà che viene frequentemente utilizzata per le query. Questo approccio consente di evitare query tra partizioni. Usare chiavi di partizione gerarchiche per superare il limite logico della partizione di 20 GB per ciascun valore della chiave di partizione e limitare le query di fan-out costose. Le chiavi di partizione gerarchiche funzionano meglio quando si ha una cardinalità elevata di tenant (clienti) ed è necessario ottimizzare per un carico di lavoro di lettura elevato.

Per ulteriori informazioni, vedi le seguenti risorse:

• Partizionamento e scalabilità orizzontale in Azure Cosmos DB
• Chiavi di partizione gerarchica

Pool di flotta

Usare pool di flotte, una funzionalità delle flotte di Azure Cosmos DB, per ottenere i vantaggi dell'isolamento delle prestazioni e della sicurezza offerti dal modello database-account-per-tenant. È possibile ottimizzare i costi condividendo unità di richiesta al secondo (RU/s) tra più account nello stesso gruppo. Raggruppare tipi simili di clienti nello stesso pool e configurare il pool per scalare automaticamente tra un numero minimo e massimo di RU/s.

I contenitori in ogni account mantengono le UR/sec dedicate, ma quando si trovano in un pool usano automaticamente UR/sec aggiuntive dal pool condiviso quando necessario. Questo approccio consente di evitare il provisioning eccessivo. Anziché effettuare il provisioning dei contenitori di ogni tenant per il picco di UR/sec, che può risultare costoso, è possibile impostare un valore tipico di UR/sec per contenitore e usare la capacità condivisa del pool per gestire i picchi. Per proteggersi dai vicini rumorosi, qualsiasi capacità di cui è stato effettuato il provisioning in un contenitore è dedicata e garantita per essere sempre disponibile a tale contenitore. Se un contenitore ha bisogno di più throughput, può utilizzare RU/s dal pool condiviso.

Per ulteriori informazioni, vedi le seguenti risorse:

• Azure Cosmos DB Fleets
• Pool flotta di Azure Cosmos DB

Analisi della flotta (anteprima)

Usare fleet analytics, una funzionalità di Azure Cosmos DB fleet, per analizzare le tendenze a lungo termine negli account di database nella flotta. L'analisi delle flotte offre dati sulle prestazioni, l'utilizzo e i costi come tabelle open source Apache Delta Lake in Azure Data Lake Storage e Microsoft OneLake a intervalli orari.

Usare questi dati per tenere traccia delle tendenze come gli account più attivi, il modo in cui le risorse vengono ridimensionate nel tempo, quali account di database o tenant hanno il costo più elevato e la rotazione più recente delle chiavi di accesso. È anche possibile usare i dati per scrivere query personalizzate o creare dashboard Power BI per analizzare la flotta.

Gestione RU

Il modello di determinazione prezzi di Azure Cosmos DB si basa sul numero di UR/sec di cui si effettua il provisioning o l'utilizzo. Azure Cosmos DB offre diverse opzioni per il provisioning del throughput. In un ambiente multi-tenant, la selezione influisce sulle prestazioni e sul prezzo delle risorse di Azure Cosmos DB.

Per i tenant che richiedono un isolamento garantito delle prestazioni e della sicurezza, è consigliabile isolare i tenant in base all'account del database, allocare UR/sec dedicate al tenant e usare pool di flotta per gestire esigenze di capacità aggiuntive. Per i tenant con requisiti meno rigorosi, è consigliabile isolare i tenant in base alla chiave di partizione. Utilizzare questo modello per condividere le RU/s tra i tenant e ottimizzare il costo per ciascun tenant.

Azure Cosmos DB offre anche un livello serverless, adatto ai carichi di lavoro con traffico intermittente o imprevedibile.

Per monitorare e gestire i costi associati a ogni tenant, tenere presente che ogni operazione che usa l'API Azure Cosmos DB include le UR utilizzate. È possibile usare queste informazioni per aggregare e confrontare le UR effettive utilizzate da ogni tenant. È quindi possibile identificare i tenant con caratteristiche di prestazioni diverse. Se alcuni tenant hanno requisiti di prestazioni o isolamento significativamente superiori, è consigliabile isolarli nel proprio account, con RU/s di contenitori dedicati. È possibile usare un contenitore partizionato in base all'ID tenant per archiviare i dati per i tenant rimanenti.

Funzionalità di governance delle risorse

Esplorare le funzionalità che consentono di controllare il problema del vicino rumoroso quando si usa una chiave di partizione per isolare i tenant.

Per ulteriori informazioni, vedi le seguenti risorse:

• Provisioning velocità effettiva
• Scalare automaticamente la capacità di elaborazione
• Misura l'addebito RU di una richiesta
• Quote del servizio Azure Cosmos DB

Chiavi gestite dal cliente

Alcuni tenant potrebbero dover usare le proprie chiavi di crittografia. Azure Cosmos DB offre una funzionalità chiave gestita dal cliente. Questa funzionalità viene applicata solo al livello di un account Azure Cosmos DB. Se i tenant richiedono chiavi di crittografia personalizzate, è necessario usare account di Azure Cosmos DB dedicati per distribuire i tenant.

Per altre informazioni, vedere Impostare chiavi gestite dal cliente per l'account Azure Cosmos DB usando Azure Key Vault.

Collaboratori

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

Autori principali:

• Tara Bhatia | Program Manager
• Paul Burpo | Ingegnere Cliente Principale, FastTrack per Azure
• Deborah Chen | Principal Program Manager
• John Downs | Principal Software Engineer, Azure Patterns & Pratiche
• Sergiy Smyrnov | Principal Program Manager, Azure Cosmos DB

Altri contributori:

• Mark Brown | Principal PM Manager, Azure Cosmos DB
• Vic Perdana | Cloud Solution Architect, Azure ISV
• Theo van Kraay | Senior Program Manager, Azure Cosmos DB
• Arsen Vladimirskiy | Ingegnere principale per i clienti, FastTrack per Azure
• Thomas Weiss | Principal Program Manager

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

Passaggi successivi

Per altre informazioni su multi-tenancy e Azure Cosmos DB, guardare i video seguenti:

• Designare livelli dati scalabili per app multi-tenant con Azure Cosmos DB: una sessione alla build 2025 che illustra come progettare la multi-tenancy in Azure Cosmos DB. Informazioni sulle procedure consigliate da un fornitore di software indipendente reale.

• Applicazioni multitenant con Azure Cosmos DB: una sessione alla Build 2019 che copre l'isolamento delle prestazioni, la gestione dei costi, la coerenza, la latenza, i compromessi in termini di disponibilità e i modelli di sicurezza per le applicazioni multitenant.

• Costruire una piattaforma SaaS multi-tenant su Azure Cosmos DB e Azure: un caso di studio reale su come Whally, una startup SaaS multi-tenant, ha creato una piattaforma moderna da zero su Azure Cosmos DB e Azure. Whally prende decisioni di progettazione e implementazione correlate al partizionamento, alla modellazione dei dati, alla multi-tenancy sicura, alle prestazioni e allo streaming in tempo reale dal feed di modifiche a SignalR. Tutte queste soluzioni usano ASP.NET Core nel servizio app Azure.

Risorse correlate

Per esaminare altri scenari architetturali Azure Cosmos DB, vedere gli articoli seguenti:

• Approcci di archiviazione e dati per la multitenancy
• Modello Outbox transazionale con Azure Cosmos DB