Condividi tramite

Revisione di Azure Well-Architected Framework - Azure Cosmos DB per NoSQL

  • Articolo

Questo articolo descrive le procedure consigliate per Azure Cosmos DB per NoSQL. Queste procedure consigliate assicurano che sia possibile distribuire soluzioni in Azure Cosmos DB efficienti, affidabili, sicure, ottimizzate per i costi e in modo operativo eccellenti. Questa guida è incentrata sui cinque pilastri dell'eccellenza dell'architettura in Well-Architected Framework:

Questa guida di revisione presuppone che si abbia una conoscenza funzionante di Azure Cosmos DB e che siano ben approfondite con le relative funzionalità. Per altre informazioni, vedere Azure Cosmos DB per NoSQL.

Prerequisiti

Comprendere i pilastri di Well-Architected Framework può contribuire a produrre un'architettura cloud di alta qualità, stabile ed efficiente. È consigliabile iniziare esaminando il carico di lavoro usando la valutazione di revisione di Azure Well-Architected Framework.

Per un maggior contesto, esaminare varie architetture di riferimento che riflettono le considerazioni di questa guida nella progettazione. Queste architetture includono, ma non sono limitate a:

Affidabilità

Come per qualsiasi servizio cloud, gli errori possono verificarsi sia sul lato servizio che sul lato del carico di lavoro. È impossibile evitare tutti i potenziali errori, ma è un obiettivo migliore per ridurre al minimo gli effetti che un singolo componente con errori può avere sull'intero carico di lavoro. Questa sezione include considerazioni e consigli per ridurre al minimo le conseguenze di un errore occasionale.

Elenco di controllo della progettazione

  • Si consideri il modo in cui il livello di coerenza e la modalità di replica selezionati influisce sull'obiettivo del punto di ripristino (RPO) in un'interruzione a livello di area.
  • Progettare la distribuzione dell'account di database in modo che si estenda almeno due aree in Azure. Inoltre, distribuire l'account tra più zone di disponibilità quando vengono offerte all'interno dell'area di Azure.
  • Valutare le strategie di scrittura in più aree e in un'area singola per il carico di lavoro. Per la scrittura in un'area singola, progettare il carico di lavoro in modo che abbia almeno un'area di lettura per il failover. Abilitare il failover automatico per scenari di scrittura e lettura in più aree a singola area. Per la scrittura in più aree, confrontare i compromessi in termini di complessità e coerenza rispetto ai vantaggi della scrittura in più aree. Esaminare le aspettative durante un'interruzione a livello di area per gli account di scrittura in una singola area e in più aree.
  • Abilitare il failover gestito dal servizio per l'account.
  • Progettare un test end-to-end di disponibilità elevata per l'applicazione.
  • Esaminare i processi di backup comuni, tra cui il ripristino temporizzato, il ripristino temporizzato, il ripristino da operazioni distruttive accidentali, il ripristino delle risorse eliminate e il ripristino in un'altra area in un momento specifico. Configurare l'account con il backup continuo, scegliendo il periodo di conservazione appropriato in base ai requisiti aziendali.
  • Esplorare la guida alla progettazione di applicazioni resilienti, esaminare i criteri di ripetizione dei tentativi predefiniti per gli SDK e pianificare la gestione personalizzata per errori temporanei specifici. Queste guide forniscono procedure consigliate per rendere resiliente il codice dell'applicazione agli errori temporanei.

Consigli

Elemento consigliato Vantaggio
Distribuire l'account Azure Cosmos DB tra zone di disponibilità (se disponibili). Le zone di disponibilità offrono potenza, rete e raffreddamento distinti isolando gli errori hardware in un subset delle repliche. Azure Cosmos DB include più repliche che si estendono su una singola zona di disponibilità casuale quando la funzionalità delle zone di disponibilità non viene usata. Se viene usata la funzionalità della zona di disponibilità, le repliche si estendono su più zone di disponibilità.
Configurare l'account Azure Cosmos DB per estendere almeno due aree. L'estensione di più aree impedisce che l'account non sia completamente disponibile se si verifica un'interruzione dell'area isolata.
Abilitare il failover gestito dal servizio per l'account. Il failover gestito dal servizio consente ad Azure Cosmos DB di modificare l'area di scrittura di un account con più aree per mantenere la disponibilità. Questa modifica si verifica senza interazione dell'utente. Comprendere i compromessi con il failover gestito dal servizio e pianificare il failover forzato, se necessario. Per altre informazioni, vedere Creazione di applicazioni a disponibilità elevata.
Convalidare la disponibilità testando manualmente il failover con failover gestito dal servizio temporaneamente disabilitato. La disabilitazione temporanea del failover di gestione del servizio consente di convalidare la disponibilità elevata end-to-end dell'applicazione con un failover manuale avviato usando uno script o il portale di Azure. Successivamente, è possibile riabilitare il failover gestito dal servizio.

Definizioni dei Criteri di Azure

Sicurezza

La sicurezza è una parte fondamentale di qualsiasi architettura che può essere facilmente trascurata per praticità. Migliorare la sicurezza del carico di lavoro finale considerando diverse procedure consigliate per la sicurezza prima che venga creata la prima risorsa o il modello di verifica. Questa sezione include considerazioni e consigli per ridurre il numero di vulnerabilità di sicurezza per il carico di lavoro finale.

Elenco di controllo della progettazione

  • Ridurre l'area di attacco della superficie progettando l'uso di endpoint privati in base alla baseline di sicurezza per Azure Cosmos DB.
  • Creare ruoli, gruppi e assegnazioni per l'accesso del piano di controllo e del piano dati all'account in base al principio dell'accesso con privilegi minimi. Valutare la possibilità di disabilitare l'autenticazione basata su chiave.
  • Valutare la conformità e le certificazioni a livello di servizio nel contesto dei requisiti dei dati personali globali correnti.
  • Crittografare i dati inattivi o in movimento usando chiavi gestite dal servizio o chiavi gestite dal cliente.
  • Controllare l'accesso utente, le violazioni della sicurezza e le operazioni delle risorse con i log del piano di controllo.
  • Monitorare l'uscita dei dati, le modifiche ai dati, l'utilizzo e la latenza con le metriche del piano dati.

Consigli

Elemento consigliato Vantaggio
Implementare, almeno, le baseline di sicurezza per la protezione dei dati e la gestione delle identità. Esaminare la baseline di sicurezza, tra cui la gestione delle identità e la protezione dei dati. Implementare le raccomandazioni per proteggere l'account Azure Cosmos DB.
Disabilitare gli endpoint pubblici e usare gli endpoint privati quando possibile. Evitare di lasciare gli endpoint pubblici non necessari o inutilizzati disponibili per gli attacchi di superficie all'account.
Usare il controllo degli accessi in base al ruolo per limitare l'accesso del piano di controllo a identità e gruppi specifici e nell'ambito delle assegnazioni ben definite. Usare il controllo degli accessi in base al ruolo per impedire l'accesso imprevisto all'account. Assegnare ruoli e autorizzazioni appropriati a utenti o applicazioni che accedono ad Azure Cosmos DB.
Creare endpoint e regole di rete virtuale per limitare l'accesso all'account. Implementare endpoint servizio di rete virtuale e regole del firewall per limitare l'accesso all'account Azure Cosmos DB. Usare i gruppi di sicurezza di rete (NSG) per controllare il traffico in ingresso e in uscita da e verso le risorse di Azure Cosmos DB. Limitare l'accesso alle reti attendibili e applicare misure di sicurezza di rete appropriate consente di proteggere i dati da accessi non autorizzati.
Seguire le procedure di sviluppo software consigliate per proteggere l'accesso ai dati. Seguire procedure di codifica sicure ed eseguire revisioni del codice sicure durante lo sviluppo di applicazioni che interagiscono con Azure Cosmos DB. Protezione da vulnerabilità di sicurezza comuni, ad esempio attacchi injection, scripting tra siti (XSS) o riferimenti a oggetti diretti non sicuri (IDOR). Implementare la convalida dell'input, le query con parametri e la gestione degli errori appropriata per i codici di stato HTTP comuni per evitare rischi per la sicurezza.
Monitorare i log del piano di controllo per le violazioni. Il monitoraggio consente di tenere traccia dei modelli di accesso e dei log di controllo, assicurandosi che il database rimanga sicuro e conforme alle normative di protezione dei dati pertinenti. Il monitoraggio delle metriche del piano dati può anche aiutare a identificare modelli sconosciuti che potrebbero rivelare una violazione della sicurezza. Per altre informazioni, vedere Elenco di controllo per la sicurezza per i database di Azure.
Abilitare Microsoft Defender per Azure Cosmos DB Microsoft Defender rileva i tentativi di exploit dei database nell'account Azure Cosmos DB per NoSQL. Defender rileva potenziali attacchi SQL injection, modelli di accesso sospetti e altri potenziali sfruttamento.

Definizioni dei Criteri di Azure

Ottimizzazione dei costi

Le caratteristiche del carico di lavoro e l'implementazione della soluzione possono influenzare il costo finale dell'esecuzione in Azure. Prendere in considerazione i driver principali, ad esempio la strategia di partizionamento, il livello di coerenza, la replica e il tipo di scrittura durante la progettazione del carico di lavoro. Quando si ridimensiona il carico di lavoro, prendere in considerazione la natura di lettura/scrittura dei dati, le dimensioni degli elementi medi, la normalizzazione e la durata (TTL). Questa sezione include considerazioni e consigli per semplificare i costi per il carico di lavoro.

  • Progettare un criterio di indicizzazione che consideri le operazioni e le query eseguite in genere nel carico di lavoro.
  • Determinare una chiave di partizione o un set di chiavi di partizione con un valore con cardinalità elevata e non cambia. Usare le linee guida e le procedure consigliate esistenti per selezionare una chiave di partizione appropriata. Considerare anche i criteri di indicizzazione quando si determina una chiave di partizione.
  • Selezionare uno schema di allocazione della velocità effettiva appropriato per il carico di lavoro. Esaminare i vantaggi della velocità effettiva standard e a scalabilità automatica distribuita a livello di database o contenitore. Considerare anche serverless, se appropriato. Esaminare i modelli di traffico del carico di lavoro nel contesto della selezione di uno schema di allocazione della velocità effettiva.
  • Prendere in considerazione i livelli di coerenza in relazione al carico di lavoro. Valutare anche se le sessioni client devono modificare il livello di coerenza predefinito.
  • Calcolare l'archivio dati complessivo previsto per il carico di lavoro. Le dimensioni degli elementi e degli indici influenzano tutti i costi di archiviazione dei dati. Calcolare l'impatto della replica e del backup sui costi di archiviazione.
  • Creare una strategia per rimuovere automaticamente gli elementi meno recenti che non vengono più usati o necessari. Se necessario, esportare questi elementi in una soluzione di archiviazione a costi inferiori prima di rimuoverli.
  • Valutare le query più comuni che riducono al minimo le ricerche tra partizioni. Usare queste informazioni per informare il processo di selezione di una chiave di partizione o la personalizzazione di un criterio di indicizzazione.

Consigli

Elemento consigliato Vantaggio
Monitorare l'utilizzo e i modelli di UR/s. Usare le metriche per monitorare il consumo di UR fin dall'inizio della soluzione. Usare query e altre tecniche di ricerca dei dati per trovare antipattern nel codice dell'applicazione.
Personalizzare i criteri di indicizzazione per eseguire il mapping al carico di lavoro. Il criterio di indicizzazione predefinito indicizza tutti i percorsi in un elemento e questo criterio può avere un impatto significativo sul consumo e sui costi delle UR. Usare un criterio di indicizzazione progettato in base solo ai percorsi che è necessario indicizzare per le query comuni. Per carichi di lavoro con carichi di lavoro con intensa attività di scrittura, disabilitare l'indicizzazione automatica delle colonne non usate nelle query.
Selezionare la chiave di partizione [s] ideale per il carico di lavoro. La chiave di partizione deve distribuire in modo uniforme l'utilizzo della velocità effettiva e l'archiviazione dei dati tra partizioni logiche. La selezione deve anche ridurre al minimo il numero di query tra partizioni non associate. Evitare partizioni ad accesso frequente che ricevono una quantità sproporzionata di traffico, poiché le partizioni di sbilanciamento possono aumentare i costi di velocità effettiva e gli errori temporanei. Usare le query di ricerca più comuni per determinare la potenziale chiave di partizione che probabilmente esegue solo query a partizione singola o delimitata tra partizioni.
Usare velocità effettiva serverless o con provisioning, provisioning manuale o scalabilità automatica, a livello di database o contenitore quando appropriato per il carico di lavoro. Confrontare i tipi di velocità effettiva con provisioning e selezionare l'opzione appropriata per il carico di lavoro. In genere, carichi di lavoro di sviluppo/test più piccoli possono trarre vantaggio dalla velocità effettiva serverless o dalla velocità effettiva condivisa manuale a livello di database. I carichi di lavoro cruciali di dimensioni maggiori possono trarre vantaggio dalla velocità effettiva con provisioning assegnata a livello di contenitore.
Configurare il livello di coerenza predefinito per l'applicazione. Se appropriato, effettuare il downgrade del livello di coerenza predefinito nelle sessioni client. Potrebbe non essere sempre necessario modificare il livello di coerenza predefinito standard o eseguirne l'override nelle sessioni client. Prendere in considerazione i costi più elevati associati alle letture a livelli di coerenza più elevati.
Per i carichi di lavoro di sviluppo/test, usare l'emulatore di Azure Cosmos DB. L'emulatore di Azure Cosmos DB è un'opzione per sviluppo/test e integrazione continua che consente di risparmiare sui costi di questi carichi di lavoro comuni per il team di sviluppo. L'emulatore è disponibile anche come immagine del contenitore Docker.
Usare operazioni batch transazionali Progettare partizioni per sfruttare i vantaggi delle operazioni batch transazionali all'interno di una chiave di partizione logica per l'inserimento. Usare le operazioni batch in SDK lato client per l'inserimento, l'aggiornamento o l'eliminazione di più documenti in una singola richiesta di transazione. Questo passaggio può ridurre il numero di singole richieste e alla fine può portare a una migliore efficienza della velocità effettiva.
Usare la proiezione per ridurre i costi di velocità effettiva dei set di risultati di query di grandi dimensioni. Creare query per proiettare solo il numero minimo di campi richiesti da un set di risultati. Se i calcoli sui campi sono necessari, valutare il costo della velocità effettiva di esecuzione di tali calcoli sul lato server rispetto al lato client.
Evitare di usare query tra partizioni non associate. Valutare e creare query per assicurarsi di eseguire ricerche all'interno di una singola partizione logica, quando possibile. Usare filtri di query per controllare le partizioni logiche delle destinazioni della query. Se una query deve eseguire la ricerca tra partizioni logiche, associare la query solo a cercare un subset di partizioni logiche anziché un'analisi completa.
Implementare la durata (TTL) per rimuovere gli elementi inutilizzati. Usare TTL per eliminare automaticamente i dati non più necessari. Gestire i costi di archiviazione rimuovendo i dati scaduti o obsoleti. Se necessario, esportare i dati scaduti in una soluzione di archiviazione a costi inferiori.
Si consideri un archivio analitico per le aggregazioni pesanti. L'archivio analitico di Azure Cosmos DB sincronizza automaticamente i dati in un archivio colonne separato per ottimizzare le aggregazioni, i report e le query analitiche di grandi dimensioni.

Definizioni dei Criteri di Azure

Eccellenza operativa

I carichi di lavoro devono essere monitorati dopo la distribuzione per assicurarsi che vengano eseguiti come previsto. Inoltre, il monitoraggio dei carichi di lavoro può aiutare a sbloccare nuove efficienze non immediatamente evidenti durante la fase di pianificazione. In scenari irreversibili, i dati di diagnostica sono la chiave per scoprire perché potrebbe essersi verificato un evento imprevisto con gravità elevata. Questa sezione include considerazioni e consigli per monitorare eventi e caratteristiche dei carichi di lavoro.

Elenco di controllo della progettazione

  • Creare una bozza di strategia di monitoraggio dei log e delle metriche per distinguere i diversi carichi di lavoro, contrassegnare scenari eccezionali, tenere traccia dei modelli in eccezioni/errori e tenere traccia delle prestazioni del computer host.
  • Progettare carichi di lavoro di grandi dimensioni per usare le operazioni bulk quando possibile.
  • Definire più avvisi per monitorare la limitazione, analizzare l'allocazione della velocità effettiva e tenere traccia delle dimensioni dei dati.
  • Progettare una strategia di monitoraggio per la disponibilità della soluzione tra aree.
  • Creare e applicare procedure consigliate per automatizzare la distribuzione dell'account e delle risorse di Azure Cosmos DB per NoSQL.
  • Pianificare le soglie delle metriche previste in base alla progettazione di partizioni e indici. Assicurarsi che sia disponibile un piano per monitorare tali metriche per determinare la loro vicinanza alle soglie pianificate.

Consigli

Elemento consigliato Vantaggio
Assicurarsi che gli sviluppatori di applicazioni usino la versione più recente dell'SDK per sviluppatori. Ogni AZURE Cosmos DB per NoSQL SDK ha una versione minima consigliata. Per altre informazioni, vedere .NET SDK e Java SDK.
Creare identificatori nell'applicazione client per distinguere i carichi di lavoro. Prendere in considerazione i flag, ad esempio il suffisso user-agent, per identificare il carico di lavoro a cui associare ogni voce di log o metrica.
Acquisire la diagnostica supplementare usando l'SDK per sviluppatori. Usare le tecniche di inserimento di diagnostica per ogni SDK per aggiungere informazioni supplementari sul carico di lavoro insieme a metriche e log predefiniti. Per altre informazioni, vedere .NET SDK e Java SDK.
Creare avvisi associati alle risorse del computer host. Connessione attività e problemi di disponibilità possono verificarsi a causa di problemi del computer host sul lato client. Monitorare risorse come CPU, memoria e archiviazione in computer host con applicazioni client usando gli SDK di Azure Cosmos DB per NoSQL.
Usare le funzionalità in blocco degli SDK client per operazioni di grandi dimensioni. Scenari che richiedono un elevato livello di velocità effettiva traggono vantaggio dall'uso della funzionalità in blocco dell'SDK. La funzionalità bulk gestisce e raggruppa automaticamente le operazioni per ottimizzare la velocità effettiva.
Creare avvisi per la limitazione della velocità effettiva. Usare gli avvisi per tenere traccia della limitazione della velocità effettiva oltre le soglie previste. Nel corso del tempo, esaminare e modificare gli avvisi man mano che si apprendono altre informazioni sul carico di lavoro in relazione ad Azure Cosmos DB. La metrica Normalized UR Consumption è una metrica che misura l'utilizzo percentuale della velocità effettiva con provisioning in un database o in un contenitore. Se questa metrica è coerente al 100%, è probabile che le richieste restituisca un errore temporaneo.
Tenere traccia delle prestazioni delle query usando le metriche. Usare le metriche per tenere traccia delle prestazioni delle query principali nel tempo. Valutare se sono presenti efficienze da trovare aggiornando i criteri di indicizzazione o modificando le query. Se le prestazioni delle query sono scarse, risolvere i problemi relativi alle prestazioni e applicare le procedure consigliate per le query. Per altre informazioni, vedere Suggerimenti sulle prestazioni delle query.
Usare i modelli per distribuire automaticamente le risorse dell'account. Prendere in considerazione i modelli di Azure Resource Manager, Bicep o Terraform per automatizzare la distribuzione dell'account e delle risorse successive. Assicurarsi che il team usi gli stessi modelli per la distribuzione in altri ambienti non di produzione.
Tenere traccia delle metriche chiave per identificare i problemi comuni nel carico di lavoro. Usare metriche specifiche per trovare problemi comuni nel carico di lavoro, tra cui, ma non solo; Utilizzo delle UR, utilizzo delle UR per partizione, limitazione e volumi di richiesta per tipo. Per altre informazioni, vedere Monitorare i dati di riferimento.

Definizioni dei Criteri di Azure

Efficienza prestazionale

  • Definire una baseline di prestazioni per l'applicazione. Misurare il numero di utenti e transazioni simultanei che potrebbe essere necessario gestire. Prendere in considerazione le caratteristiche del carico di lavoro, ad esempio il flusso utente medio, le operazioni comuni e i picchi di utilizzo.
  • Ricercare le query più comuni e più complesse. Identificare le query che usano più ricerche, join o aggregazioni. Prendere in considerazione queste query in qualsiasi considerazione di progettazione per la chiave di partizione o i criteri di indicizzazione.
  • Per le query più comuni, determinare il numero di risultati previsti per pagina. Questo numero consentirà di formalizzare un conteggio degli elementi memorizzati nel buffer per i risultati prelettura.
  • Ricercare gli utenti di destinazione. Determinare le aree di Azure più vicine.
  • Identificare le query che usano uno o più campi di ordinamento. Identificare anche le operazioni che influisce su più campi. Includere questi campi in modo esplicito nella progettazione dei criteri di indicizzazione.
  • Progettare gli elementi in modo che i documenti JSON corrispondenti siano il più piccolo possibile. Se necessario, valutare la possibilità di suddividere i dati tra più elementi.
  • Identificare le query sulle matrici figlio e determinare se sono candidati per sottoquery più efficienti.
  • Determinare se il carico di lavoro richiede un archivio analitico. Prendere in considerazione archivi analitici e servizi come Azure Collegamento a Synapse per query estremamente complesse.
Elemento consigliato Vantaggio
Configurare la velocità effettiva in base alla baseline delle prestazioni. Usare strumenti come il calcolatore della capacità per determinare la quantità di velocità effettiva necessaria per la baseline delle prestazioni. Usare funzionalità come la scalabilità automatica per ridimensionare la velocità effettiva effettiva in modo che corrisponda maggiormente al carico di lavoro effettivo. Monitorare il consumo effettivo della velocità effettiva in seguito e apportare modifiche.
Usare tecniche di ottimizzazione sui lati client e server, se appropriato. Sfruttare i vantaggi della cache integrata predefinita. Configurare l'SDK per gestire il numero di elementi prelettura (memorizzati nel buffer) e restituiti per ogni pagina.
Distribuire Azure Cosmos DB per NoSQL nelle aree più vicine agli utenti finali. Ridurre la latenza distribuendo Azure Cosmos DB per NoSQL alle aree più vicine agli utenti finali il più possibile. Sfruttare i vantaggi della replica in lettura per offrire prestazioni di lettura elevate indipendentemente dalla modalità di configurazione della scrittura (singola o più aree). Configurare l'SDK (.NET/Java) per preferire le aree più vicine all'utente finale.
Configurare l'SDK per la modalità diretta. La modalità diretta è l'opzione preferita per ottenere prestazioni ottimali. Questa modalità consente al client di aprire le connessioni TCP direttamente alle partizioni nel servizio e inviare richieste direttamente senza gateway intermedio. Questa modalità offre prestazioni migliori perché sono presenti meno hop di rete.
Disabilitare l'indicizzazione per le operazioni bulk. Se sono presenti molte operazioni di inserimento/sostituzione/upsert, disabilitare l'indicizzazione per migliorare la velocità dell'operazione durante l'uso del supporto bulk dell'SDK corrispondente. L'indicizzazione può essere riattivata immediatamente in un secondo momento.
Creare indici compositi per i campi usati in operazioni complesse. Gli indici compositi possono aumentare l'efficienza delle operazioni su più campi in base agli ordini di grandezza. In molti casi, usare indici compositi per ORDER BY le istruzioni con più campi.
Ottimizzare i computer client host per gli SDK. Per il caso più comune, usare almeno 4 core e 8 GB di memoria in computer host a 64 bit usando gli SDK (.NET/Java). Abilitare anche la rete accelerata nei computer host.
Usare il modello singleton per la CosmosClient classe nella maggior parte degli SDK. Usare la classe client nella maggior parte degli SDK come singleton. La classe client gestisce il proprio ciclo di vita ed è progettata per non essere eliminata. La creazione costante e l'eliminazione di istanze possono comportare una riduzione delle prestazioni.
Mantenere le dimensioni degli elementi inferiori a 100 KB . Maggiore velocità effettiva dei consumer di elementi per operazioni comuni di lettura e scrittura. Anche le query su elementi di dimensioni maggiori che proiettano tutti i campi possono avere un costo significativo per la velocità effettiva.
Usare sottoquery in modo strategico per ottimizzare le query che aggiungono set di dati di grandi dimensioni. Le query che aggiungono matrici figlio possono aumentare la complessità se sono coinvolte più matrici e non filtrate. Ad esempio, una query che unisce più di due matrici di almeno 10 elementi ognuno può espandersi a 1.000 tuple+ . Ottimizzare le espressioni self-join usando sottoquery per filtrare le matrici prima di unire matrici all'interno dell'elemento. Per le query tra partizioni, ottimizzare la query in modo da includere un filtro sulla chiave di partizione per ottimizzare il routing della query al minor numero possibile di partizioni.
Usare i carichi di lavoro analitici per le query più complesse. Se si eseguono aggregazioni frequenti o si aggiungono query su contenitori di grandi dimensioni, è consigliabile abilitare l'archivio analitico ed eseguire query in Azure Synapse Analytics.

Definizioni dei Criteri di Azure

Risorse aggiuntive

Prendere in considerazione altre risorse correlate ad Azure Cosmos DB per NoSQL.

Linee guida del Centro architetture di Azure

Linee guida di Cloud Adoption Framework

Passaggi successivi

Distribuire un account Azure Cosmos DB per NoSQL usando un modello Bicep