Quote del servizio Azure Cosmos DB
SI APPLICA A: NoSQL MongoDB Cassandra Gremlin Tabella
Questo articolo fornisce una panoramica delle quote predefinite offerte a risorse diverse in Azure Cosmos DB.
Dopo aver creato un account Azure Cosmos DB nella propria sottoscrizione, è possibile gestire i dati nell'account creando database, contenitori ed elementi.
È possibile allocare la velocità effettiva a livello di contenitore o di database in termini di unità richiesta (UR/sec o UR). La tabella seguente elenca i limiti relativi all'archiviazione e alla velocità effettiva per ogni contenitore o database. L'archiviazione fa riferimento alla quantità combinata di archiviazione di dati e indici.
Conto risorse | Limite |
---|---|
Numero massimo di UR per ogni contenitore (modalità di provisioning con velocità effettiva dedicata) | 1.000.000 ¹ |
Numero massimo di UR per ogni database (modalità di provisioning con velocità effettiva condivisa) | 1.000.000 ¹ |
Numero massimo di UR per ogni chiave di partizione (logica e fisica) | 10,000 |
Dimensione massima di archiviazione per tutti gli elementi per ogni chiave di partizione (logica) | 20 GB ² |
Numero massimo di chiavi di partizione (logica) distinte | Nessun limite |
Spazio di archiviazione massimo per contenitore | Nessun limite |
Dimensioni massime degli allegati per ogni account (la funzionalità relativa agli allegati verrà deprecata) | 2 GB |
Numero minimo di UR richieste per 1 GB | 1 UR/sec |
¹ È possibile aumentare il numero massimo di UR per contenitore o database creando un ticket di supporto tecnico in Azure.
² Per informazioni sulle procedure consigliate per la gestione dei carichi di lavoro con chiavi di partizione che richiedono limiti più elevati per l'archiviazione o la velocità effettiva, vedere Creare una chiave di partizione sintetica. Se il carico di lavoro ha già raggiunto il limite di 20 GB per le partizioni logiche nell'ambiente di produzione, è consigliabile riprogettare l'applicazione con una chiave di partizione diversa come soluzione a lungo termine. Per concedere il tempo necessario per riordinare l'applicazione, è possibile richiedere un aumento temporaneo del limite della chiave di partizione logica per l'applicazione esistente. Creare un ticket di supporto tecnico in Azure e selezionare il tipo di quota Aumento temporaneo delle dimensioni della chiave di partizione logica del contenitore. La richiesta di un aumento temporaneo è destinata a una mitigazione temporanea e non è consigliata come soluzione a lungo termine, poiché le garanzie del contratto di servizio non vengono rispettate quando il limite è aumentato. Per rimuovere la configurazione, inoltrare un ticket di supporto e selezionare il tipo di quota Ripristinare le dimensioni predefinite della chiave di partizione logica del contenitore (20 GB) . La creazione del ticket di supporto può essere eseguita dopo aver eliminato i dati per soddisfare il limite di 20 GB per le partizioni logiche o avere riprogettato l'applicazione con una chiave di partizione diversa.
Un contenitore di Azure Cosmos DB (o un database con velocità effettiva condivisa) che usa una velocità effettiva standard (manuale) deve avere una velocità effettiva minima di 400 UR/sec. Man mano che il contenitore cresce, Azure Cosmos DB richiede una velocità effettiva minima per garantire che la risorsa (database o contenitore) disponga di risorse sufficienti per le operazioni.
La velocità effettiva corrente e minima di un contenitore o di un database può essere recuperata dal portale di Azure o dagli SDK. Per altre informazioni, vedere Allocare la velocità effettiva per i contenitori e i database.
Il numero minimo di UR/s effettivo può variare a seconda della configurazione dell'account. È possibile usare le metriche di Monitoraggio di Azure per visualizzare la cronologia della velocità effettiva allocata (UR/sec) e dell'archiviazione in una risorsa.
Usare questa sezione per stimare la velocità effettiva minima in un contenitore.
Per stimare le UR/sec minime necessarie per un contenitore con velocità effettiva manuale, trovare il valore massimo di:
- 400 UR/sec
- Archiviazione corrente in GB * 1 UR/s
- Numero massimo di RU/sec di cui è mai stato effettuato il provisioning nel contenitore / 100
Si supponga di avere un contenitore a cui sono stati allocati 400 UR/sec e 0 GB di spazio di archiviazione. La velocità effettiva viene aumentata a 50.000 UR/sec e vengono importati 20 GB di dati. Le UR/sec minime sono ora MAX(400, 20 * 1 RU/s per GB, 50,000 RU/s / 100)
= 500 UR/sec. Nel corso del tempo, lo spazio di archiviazione aumenta fino a 2.000 GB. Le UR/sec minime sono ora MAX(400, 2000 * 1 RU/s per GB, 50,000 / 100)
= 2.000 UR/sec.
Per stimare il numero massimo di UR/sec di scalabilità automatica minima necessario per un contenitore con velocità effettiva di scalabilità automatica, trovare il valore massimo di:
- 1000 UR/s
- Archiviazione corrente in GB * 10 UR/s
- Numero massimo di UR/sec di cui è mai stato effettuato il provisioning nel contenitore / 10
Si supponga di avere un contenitore a cui sono stati allocati 1.000 UR/sec e 0 GB di spazio di archiviazione. La velocità effettiva viene aumentata a 50.000 UR/sec e vengono importati 20 GB di dati. Il numero massimo UR/sec minime è ora MAX(1000, 20 * 10 RU/s per GB, 50,000 RU/s / 10)
= 5.000 UR/sec. Nel corso del tempo, lo spazio di archiviazione aumenta fino a 2.000 GB. Il numero massimo UR/sec minime è ora MAX(1000, 2000 * 10 RU/s per GB, 50,000 / 10)
= 20.000 UR/sec.
Usare questa sezione per stimare la velocità effettiva minima in una velocità effettiva di condivisione del database tra contenitori.
Per stimare le UR/sec minime richieste da un database con velocità effettiva condivisa con velocità effettiva manuale, trovare il valore massimo di:
- 400 UR/sec
- Archiviazione corrente in GB * 1 UR/s
- Numero massimo di RU/s di cui è mai stato effettuato il provisioning nel database / 100
- 400 + MAX(numero di contenitori - 25, 0) * 100 UR/sec
Si supponga di avere un database a cui sono allocati 400 UR/sec, 15 GB di spazio di archiviazione e 10 contenitori. Le UR/sec minime sono MAX(400, 15 * 1 RU/s per GB, 400 / 100, 400 + 0 )
= 400 UR/sec. Se nel database sono presenti 30 contenitori, le UR/s minime saranno pari a 400 + MAX(30 - 25, 0) * 100 RU/s
= 900 UR/sec.
Per stimare il numero massimo di UR/sec di scalabilità automatica minima necessario per un database con velocità effettiva condivisa con velocità effettiva di scalabilità automatica, trovare il valore massimo di:
- 1000 UR/s
- Archiviazione corrente in GB * 10 UR/s
- Numero massimo di RU/s di cui è mai stato effettuato il provisioning nel database / 10
- 1000 + MAX(numero di contenitori - 25, 0) * 1.000 UR/sec
Si supponga di avere un database a cui sono allocati 1.000 UR/sec, 15 GB di spazio di archiviazione e 10 contenitori. Il numero massimo di UR/sec minime per il database di scalabilità automatica è MAX(1000, 15 * 10 RU/s per GB, 1000 / 10, 1000 + 0 )
= 1.000 UR/sec. Se nel database sono presenti 30 contenitori, il numero massimo di UR/s minime sarà pari a 1000 + MAX(30 - 25, 0) * 1000 RU/s
= 5.000 UR/sec.
In sintesi, di seguito sono riportati i limiti minimi di provisioning delle UR quando si usa la velocità effettiva allocata.
Tipo di provisioning | Conto risorse | Limite |
---|---|---|
Velocità effettiva manuale | Numero minimo di UR per contenitore (modalità di provisioning con velocità effettiva dedicata e velocità effettiva manuale) | 400 |
Velocità effettiva manuale | Numero minimo di UR per database (modalità di provisioning con velocità effettiva condivisa e velocità effettiva manuale) | 400 UR/sec per i primi 25 contenitori. |
Velocità effettiva con scalabilità automatica | Numero massimo di UR minime per contenitore (modalità di provisioning con velocità effettiva dedicata e velocità effettiva a scalabilità automatica) | 1000 |
Velocità effettiva con scalabilità automatica | Numero massimo di UR minime per database (modalità di provisioning con velocità effettiva condivisa e velocità effettiva a scalabilità automatica) | 1.000 UR/sec per i primi 25 contenitori. |
Azure Cosmos DB supporta l'aumento/riduzione programmatico della velocità effettiva (UR/sec) per ogni contenitore o database tramite gli SDK o il portale.
A seconda delle UR/sec allocate e delle impostazioni della risorsa correnti, ogni risorsa può essere ridimensionata in modo sincrono e immediatamente tra le UR/sec minime fino a 100 volte il valore delle UR/sec minime. Se il valore della velocità effettiva richiesta non rientra nell'intervallo, il ridimensionamento viene eseguito in modo asincrono. Il ridimensionamento asincrono può richiedere minuti o ore, a seconda della velocità effettiva richiesta e della dimensione di archiviazione dei dati nel contenitore. Altre informazioni.
La tecnologia serverless consente di usare le risorse di Azure Cosmos DB in base al consumo. La tabella seguente elenca i limiti relativi all'archiviazione e alla possibilità di burst della velocità effettiva per ogni contenitore o database. Non è possibile aumentare i limiti. È consigliabile allocare account serverless aggiuntivi per ottenere più spazio di archiviazione.
Conto risorse | Limite |
---|---|
Numero massimo di UR/sec per container | 20.000* |
Dimensione massima di archiviazione per tutti gli elementi per ogni chiave di partizione (logica) | 20 GB |
Spazio di archiviazione massimo per contenitore | 1 TB |
*La disponibilità del numero massimo di UR/sec dipende dai dati archiviati nel contenitore. Vedere Prestazioni serverless
Azure Cosmos DB gestisce un provider di risorse che offre un livello di gestione per creare, aggiornare ed eliminare risorse nell'account Azure Cosmos DB. Il provider di risorse si interfaccia con il livello complessivo di Azure Resource Manager, ovvero il servizio di distribuzione e gestione per Azure. È possibile creare e gestire le risorse di Azure Cosmos DB usando il portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Azure, i modelli di Azure Resource Manager e Bicep, l'API REST, gli SDK di Gestione di Azure e gli strumenti di terze parti, ad esempio Terraform e Pulumi.
È anche possibile accedere a questo livello di gestione dagli SDK del piano dati di Azure Cosmos DB usati nelle applicazioni per creare e gestire le risorse all'interno di un account. Gli SDK del piano dati effettuano anche richieste del piano di controllo durante la connessione iniziale al servizio per eseguire operazioni come l'enumerazione di database e contenitori, nonché la richiesta di chiavi dell'account per l'autenticazione.
Per ogni account Azure Cosmos DB è presente un oggetto master partition
che contiene tutti i metadati per un account. Dispone anche di una piccola quantità di velocità effettiva per supportare le operazioni del piano di controllo. Le richieste del piano di controllo che creano, leggono, aggiornano o eliminano tali metadati utilizzano questa velocità effettiva. Quando la quantità di velocità effettiva utilizzata dalle operazioni del piano di controllo supera quella allocata, la frequenza delle operazioni viene limitata, come per le operazioni del piano dati all'interno di Azure Cosmos DB. Tuttavia, a differenza della velocità effettiva per le operazioni sui dati, non è possibile aumentare la velocità effettiva per la partizione master.
Alcune operazioni del piano di controllo non utilizzano la velocità effettiva della partizione master, ad esempio Ottieni o Elenca chiavi. Tuttavia, a differenza delle richieste sui dati all'interno dell'account Azure Cosmos DB, i provider di risorse all'interno di Azure non sono progettati per volumi di richieste elevati. Le operazioni del piano di controllo che superano i limiti documentati a livelli sostenuti per periodi consecutivi di 5 minuti potrebbero riscontrare una limitazione delle richieste, nonché operazioni non riuscite o incomplete nelle risorse di Azure Cosmos DB.
Le operazioni del piano di controllo possono essere monitorate passando alla scheda Informazioni dettagliate per un account Azure Cosmos DB. Per altre informazioni, vedere Monitorare le richieste del piano di controllo. Gli utenti possono anche personalizzarle, usare Monitoraggio di Azure e creare una cartella di lavoro per monitorare richieste di metadati e impostare avvisi.
Nella tabella seguente sono elencati i limiti delle risorse per sottoscrizione o account.
Conto risorse | Limite |
---|---|
Numero massimo di account per sottoscrizione | 250 per impostazione predefinita ¹ |
Numero massimo di database e contenitori per account | 500 ² |
Velocità effettiva massima supportata da un account per le operazioni sui metadati | 240 UR/sec |
¹ I limiti predefiniti variano per i clienti interni di Microsoft. È possibile aumentare questi limiti creando una richiesta di supporto di Azure fino a un massimo di 1.000. Cosmos DB si riserva il diritto di eliminare tutti gli account di database vuoti, ad esempio nessun database o nessuna raccolta. ² Questo limite non può essere aumentato. Conteggio totale di entrambi con un account. (1 database e 499 contenitori, 250 database e 250 contenitori e così via)
Nella tabella seguente sono elencati i limiti delle richieste per intervallo di 5 minuti, per account, se non diversamente specificato.
Operazione | Limite |
---|---|
Numero massimo di richieste di elenco o recupero delle chiavi | 500 ¹ |
Numero massimo di richieste di creazione di database e contenitori | 500 |
Numero massimo di richieste di elenco o recupero di database e contenitori | 500 ¹ |
Numero massimo di richieste di aggiornamento della velocità effettiva di provisioning | 25 |
Numero massimo di richieste di failover a livello di area | 10 all'ora ² |
Numero massimo di richieste per tutte le operazioni (PUT, POST, PATCH, DELETE, GET) non definite in precedenza | 500 |
¹ Gli utenti devono usare il client singleton per le istanze dell'SDK e memorizzare nella cache le chiavi e i riferimenti a database e contenitori tra le richieste per la durata dell'istanza. ² I failover a livello di area si applicano solo ad account di scrittura su singola area. Gli account di scrittura su più aree non richiedono o consentono la modifica dell'area di scrittura.
Azure Cosmos DB esegue automaticamente il backup dei dati a intervalli regolari. Per informazioni dettagliate sugli intervalli e sulle finestre di conservazione del backup, vedere Backup online e ripristino dei dati su richiesta in Azure Cosmos DB.
Di seguito è riportato un elenco di limiti per account.
Conto risorse | Limite |
---|---|
Numero massimo di database e contenitori per account | 500¹ |
Numero massimo di contenitori per ogni database con velocità effettiva condivisa | 25 |
Numero massimo di aree | Nessun limite (tutte le aree di Azure) |
Conto risorse | Limite |
---|---|
Numero massimo di database e contenitori per account | 500 |
Numero massimo di aree | 1 (qualsiasi area di Azure) |
A seconda dell'API usata, un contenitore di Azure Cosmos DB può rappresentare una raccolta, una tabella o un grafo. I contenitori supportano le configurazioni per vincoli di chiave univoca, stored procedure, trigger e UDF e criteri di indicizzazione. La tabella seguente elenca i limiti specifici delle configurazioni all'interno di un contenitore.
Conto risorse | Limite |
---|---|
Lunghezza massima del nome del database o del contenitore | 255 |
Numero massimo di stored procedure per contenitore | 100 ¹ |
Numero di funzioni definite dall'utente per contenitore | 50 ¹ |
Numero massimo di chiavi univoche per ogni contenitore | 10 ¹ |
Numero massimo di percorsi per ogni vincolo di chiave univoca | 16 ¹ |
Valore massimo durata TTL | 2147483647 |
È possibile aumentare questi limiti per contenitore creando una richiesta di supporto di Azure.
Un elemento di Azure Cosmos DB può rappresentare un documento in una raccolta, una riga in una tabella o un nodo o un arco in un grafo, a seconda dell'API usata. La tabella seguente mostra i limiti per ogni elemento in Azure Cosmos DB.
Conto risorse | Limite |
---|---|
Dimensione massima di un elemento | 2 MB (lunghezza UTF-8 della rappresentazione JSON) ¹ |
Lunghezza massima del valore della chiave di partizione | 2048 byte (101 byte se la chiave di partizione di grandi dimensioni non è abilitata) |
Lunghezza massima del valore ID | 1023 byte |
Caratteri consentiti per il valore ID | Sono consentiti tutti i caratteri Unicode sul lato servizio, ad eccezione di '/' e '\'. AVVISO: per una migliore interoperabilità È CONSIGLIABILE usare solo caratteri ASCII alfanumerici nel valore ID. Esistono diverse limitazioni note in alcune versioni di Cosmos DB SDK, nei connettori (Azure Data Factory, Spark, Kafka e così via) e nei driver HTTP/librerie e così via, che possono impedire la corretta elaborazione quando il valore ID contiene caratteri ASCII non alfanumerici. Per aumentare l'interoperabilità, codificare quindi il valore ID, ad esempio tramite Base 64 + codifica personalizzata di caratteri speciali consentiti in Base 64. - se è necessario supportare caratteri ASCII non alfanumerici nell'applicazione o nel servizio. |
Numero massimo di proprietà per ogni elemento | Nessun limite pratico |
Lunghezza massima del nome della proprietà | Nessun limite pratico |
Lunghezza massima del valore della proprietà | Nessun limite pratico |
Lunghezza massima del valore della proprietà stringa | Nessun limite pratico |
Lunghezza massima del valore della proprietà numerica | IEEE754 a precisione doppia (64 bit) |
Livello massimo di annidamento per oggetti/matrici incorporati | 128 |
Valore massimo durata TTL | 2147483647 |
Precisione/intervallo massimo per i numeri in JSON (per garantire l'interoperabilità sicura) | IEEE 754 binary64 |
¹ Le dimensioni elevate di documenti fino a 16 MB sono supportate solo con Azure Cosmos DB for MongoDB. Vedere la documentazione della funzionalità per altre informazioni.
Non sono previste restrizioni per i payload dell'elemento come il numero di proprietà e la profondità di annidamento, ad eccezione delle limitazioni di lunghezza per la chiave di partizione e i valori ID e la restrizione delle dimensioni complessive di 2 MB. Potrebbe essere necessario configurare i criteri di indicizzazione per i contenitori con strutture di elementi grandi o complesse per ridurre il consumo di UR. Per un esempio reale e modelli per la gestione di elementi di grandi dimensioni, vedere Modellazione di elementi in Azure Cosmos DB.
Azure Cosmos DB supporta operazioni di query e CRUD su risorse quali contenitori, elementi e database. Supporta inoltre richieste batch transazionali sugli elementi con la stessa chiave di partizione in un contenitore.
Conto risorse | Limite |
---|---|
Tempo massimo di esecuzione per una singola operazione (ad esempio, l'esecuzione di una stored procedure o un recupero di pagine con singola query) | 5 Secondi |
Dimensione massima della richiesta (ad esempio, stored procedure, CRUD) | 2 MB |
Dimensione massima della risposta (ad esempio, query impaginata) | 4 MB |
Numero massimo di operazioni in un batch transazionale | 100 |
Azure Cosmos DB supporta l'esecuzione di trigger durante le operazioni di scrittura. Il servizio supporta al massimo un pre-trigger e un post-trigger per ogni operazione di scrittura.
Non appena un'operazione come una query raggiunge il timeout di esecuzione o il limite della dimensione della risposta, restituisce al client una pagina di risultati e un token di continuazione per riprendere l'esecuzione. Non esiste un limite pratico per la durata di esecuzione di una singola query tra pagine/continuazioni.
Azure Cosmos DB usa HMAC (Hash-based Message Authentication Code) per l'autorizzazione. È possibile usare una chiave primaria per il controllo di accesso con granularità fine alle risorse. Queste risorse possono includere contenitori, chiavi di partizione o elementi. La tabella seguente elenca i limiti relativi ai token di autorizzazione in Azure Cosmos DB.
Conto risorse | Limite |
---|---|
Tempo di scadenza massimo del token primario | 15 min |
Tempo di scadenza minimo del token di risorsa | 10 min |
Tempo di scadenza massimo del token di risorsa | 24 ore per impostazione predefinita ¹ |
Massimo sfasamento di orario per l'autorizzazione con token | 15 min |
¹ È possibile aumentarlo creando un ticket di supporto di Azure
Per una spiegazione più dettagliata della velocità effettiva e dei limiti di archiviazione con la scalabilità automatica, vedere l'articolo relativo alla scalabilità automatica e le domande frequenti.
Conto risorse | Limite |
---|---|
Numero massimo di UR/sec in base al quale può essere ridimensionato il sistema | Tmax , il numero massimo di UR/sec per la scalabilità automatica impostato dall'utente |
Numero minimo di UR/sec in base al quale può essere ridimensionato il sistema | 0.1 * Tmax |
Numero di UR/sec correnti in base al quale viene ridimensionato il sistema | 0.1*Tmax <= T <= Tmax , in base all'utilizzo |
Numero minimo di UR/sec fatturabili all'ora | 0.1 * Tmax La fatturazione viene effettuata su base oraria. Viene addebitato il numero massimo di UR/sec utilizzato dal sistema nel corso dell'ora o 0.1*Tmax , a seconda del valore più alto. |
Numero massimo di UR/sec per la scalabilità automatica minima per un contenitore | MAX(1000, highest max RU/s ever provisioned / 10, current storage in GB * 10) , arrotondato al migliaio di UR/sec più vicino |
Numero massimo di UR/sec per la scalabilità automatica minima per un database | MAX(1000, highest max RU/s ever provisioned / 10, current storage in GB * 10, 1000 + (MAX(Container count - 25, 0) * 1000)) , arrotondato al migliaio di UR/sec più vicino. Nota: se il database ha più di 25 contenitori, il sistema incrementa di 1000 UR/sec il numero massimo di UR/sec per la scalabilità automatica minima per ogni contenitore in più. Se, ad esempio, sono presenti 30 contenitori, il numero massimo di UR/sec per la scalabilità automatica minima che è possibile impostare è 6.000 UR/sec (con scalabilità compresa tra 600 e 6.000 UR/sec). |
Azure Cosmos DB supporta l'esecuzione di query sugli elementi tramite SQL. Nella tabella seguente vengono descritte le restrizioni relative alle istruzioni di query, ad esempio in termini di numero di clausole o di lunghezza della query.
Conto risorse | Limite |
---|---|
Lunghezza massima della query SQL | 512 KB |
Numero massimo di JOIN per ogni query | 10 ¹ |
Numero massimo di UDF per ogni query | 10 ¹ |
Numero massimo di punti per ogni poligono | 4096 |
Numero massimo di percorsi inclusi in modo esplicito per contenitore | 1500 ¹ |
Numero massimo di percorsi esclusi in modo esplicito per contenitore | 1500 ¹ |
Numero massimo di proprietà in un indice composto | 8 |
Numero massimo di percorsi in un indice composto | 100 |
¹ È possibile aumentare questi limiti per le query SQL creando una richiesta di supporto di Azure.
Azure Cosmos DB supporta il protocollo di collegamento MongoDB per le applicazioni scritte in MongoDB. Le versioni supportate dei comandi e del protocollo sono disponibili in Funzionalità e sintassi di MongoDB supportate.
Nella tabella seguente sono elencati i limiti specifici per il supporto di funzionalità di MongoDB. Altri limiti del servizio indicati per l'API for NoSQL si applicano anche all'API for MongoDB.
Conto risorse | Limite |
---|---|
Dimensioni massime di un documento | 16 MB (lunghezza UTF-8 della rappresentazione JSON) ¹ |
Dimensioni di memoria query MongoDB massime (questo limite è solo per la versione server 3.2) | 40 MB |
Tempo massimo di esecuzione per le operazioni di MongoDB (per la versione server 3.2) | 15 secondi |
Tempo massimo di esecuzione per le operazioni MongoDB (per la versione del server 3.6 e 4.0) | 60 secondi |
Livello massimo di annidamento per oggetti/matrici incorporati nelle definizioni degli indici | 6 |
Timeout della connessione inattiva per la chiusura della connessione lato server ² | 30 minuti |
Limite di tempo per la shell MongoDB nel portale di Azure | 120 minuti in un periodo di 24 ore |
¹I documenti con dimensioni fino a 16 MB richiedono l'abilitazione della funzionalità nel portale di Azure. Vedere la documentazione della funzionalità per altre informazioni.
² È consigliabile che le applicazioni client impostino il timeout della connessione inattiva nelle impostazioni del driver su 2-3 minuti perché il timeout predefinito per Azure Load Balancer è di 4 minuti. Questo timeout garantisce che le connessioni inattive non siano chiuse da un servizio di bilanciamento del carico intermedio tra il computer client e Azure Cosmos DB.
La tabella seguente elenca i limiti relativi alla versione di valutazione gratuita di Azure Cosmos DB.
Conto risorse | Limite |
---|---|
Durata della versione di valutazione | 30 giorni (è possibile richiedere una nuova versione di valutazione dopo la scadenza) Dopo la scadenza, le informazioni archiviate vengono eliminate. |
Numero massimo di contenitori per sottoscrizione (SQL, Gremlin, API for Table) | 1 |
Numero massimo di contenitori per sottoscrizione (API for MongoDB) | 3 |
Velocità effettiva massima per ogni contenitore | 5000 |
Velocità effettiva massima per ogni database con velocità effettiva condivisa | 20000 |
Dimensione massima di archiviazione totale per ogni account | 10 GB |
Prova Azure Cosmos DB supporta la distribuzione globale solo nelle aree Stati Uniti centrali, Europa settentrionale e Asia sud-orientale. Non è possibile creare ticket di supporto di Azure per gli account della versione di valutazione gratuita di Azure Cosmos DB. Viene tuttavia fornito il supporto per i sottoscrittori con piani di supporto esistenti.
La tabella seguente elenca i limiti relativi agli account Azure Cosmos DB di livello gratuito.
Conto risorse | Limite |
---|---|
Numero di account di livello gratuito per ogni sottoscrizione di Azure | 1 |
Durata dello sconto per il livello gratuito | Durata dell'account. È necessario fornire il consenso esplicito durante la creazione dell'account. |
Numero massimo di UR/sec gratuiti | 1000 UR/s |
Dimensione massima di archiviazione gratuita | 25 GB |
Numero massimo di database con velocità effettiva condivisa | 5 |
Numero massimo di contenitori in un database con velocità effettiva condivisa | 25 Negli account di livello gratuito, il numero minimo di UR/sec per un database con velocità effettiva condivisa contenente fino a 25 contenitori è 400 UR/sec. |
Oltre alla tabella precedente, i limiti per account si applicano anche agli account del livello gratuito. Per altre informazioni, vedere l'articolo su come creare un account del livello gratuito.