Unità richiesta in Azure Cosmos DB

SI APPLICA A: API Api Cassandra API Gremlin API Tabella api Azure Cosmos DB per MongoDB

Azure Cosmos DB supporta un'ampia gamma di API, come SQL, MongoDB, Cassandra, Gremlin e Tabella. Ogni API ha il proprio set di operazioni di database, da semplici operazioni di lettura e scrittura puntuali a query complesse. Ogni operazione di database utilizza le risorse di sistema a seconda della complessità.

Il costo di tutte le operazioni di database viene normalizzato da Azure Cosmos DB ed è espresso in termini di unità richiesta (o in breve UR). L'unità richiesta è una valuta delle prestazioni che astrae le risorse di sistema, ad esempio CPU, operazioni di I/O al secondo e memoria necessarie per eseguire le operazioni di database supportate da Azure Cosmos DB.

Il costo per eseguire una lettura punto (recupero di un singolo elemento in base all'ID e al valore della chiave di partizione) per un elemento da 1 KB è 1 unità richiesta (o 1 UR). In modo analogo, a tutte le altre operazioni di database viene assegnato un costo in termini di UR. I costi vengono sempre misurati in UR, indipendentemente dall'API usata per interagire con il contenitore Azure Cosmos. Sia che l'operazione di database sia una scrittura, una lettura di punti o una query, i costi sono sempre misurati in UR.

Nell'immagine seguente viene illustrata l'idea generale delle UR:

Utilizzo delle unità richiesta da parte delle operazioni di database

Per gestire e pianificare la capacità, Azure Cosmos DB garantisce che il numero di UR per una specifica operazione di database su un determinato set di dati sia deterministico. È possibile esaminare l'intestazione della risposta per tenere traccia del numero di UR utilizzate da qualsiasi operazione di database. Quando si conoscono i fattori che influiscono sugli addebiti delle UR e sui requisiti di velocità effettiva dell'applicazione, è possibile eseguire l'applicazione in modo conveniente.

Il tipo di account Azure Cosmos in uso determina il modo in cui vengono addebitate le unità richiesta (UR) utilizzate. Esistono tre modalità in cui è possibile creare un account:

  1. Modalità Velocità effettiva con provisioning: in questa modalità il provisioning del numero di unità richiesta (UR) per l'applicazione viene effettuato al secondo con incrementi di 100 unità richiesta al secondo. Per dimensionare la velocità effettiva con provisioning per l'applicazione, è possibile aumentare o diminuire il numero di unità richiesta (UR) in qualsiasi momento a incrementi o decrementi di 100 UR. Le modifiche possono essere apportate a livello di codice o tramite il portale di Azure. Viene addebitato su base oraria il numero di UR al secondo di cui è stato effettuato il provisioning. Per altre informazioni, vedere l'articolo Velocità effettiva con provisioning .

    È possibile effettuare il provisioning della velocità effettiva a due diversi livelli di granularità:

  2. Modalità Serverless: in questa modalità non è necessario effettuare il provisioning di alcuna velocità effettiva durante la creazione di risorse nell'account di Azure Cosmos DB. Al termine del periodo di fatturazione, viene fatturato il numero di unità richiesta utilizzate dalle operazioni del database. Per altre informazioni, vedere l'articolo Velocità effettiva serverless .

  3. Modalità di scalabilità automatica: in questa modalità è possibile ridimensionare automaticamente e istantaneamente la velocità effettiva (UR/sec) del database o del contenitore in base all'utilizzo, senza influire sulla disponibilità, la latenza, sulla velocità effettiva o sulle prestazioni del carico di lavoro. Questa modalità è particolarmente adatta per carichi di lavoro cruciali con modelli di traffico variabili o imprevedibili e che richiedono contratti di servizio con prestazioni e scalabilità elevate. Per altre informazioni, vedere l'articolo Velocità effettiva con scalabilità automatica .

Considerazioni sulle unità richiesta

Mentre si stima il numero di UR utilizzate dal carico di lavoro, considerare i fattori seguenti:

  • Dimensioni degli elementi: con l'aumentare delle dimensioni di un elemento, aumenta anche il numero di UR utilizzate per la lettura o la scrittura dell'elemento.

  • Indicizzazione degli elementi: Per impostazione predefinita, ogni elemento viene automaticamente indicizzato. Se si sceglie di non indicizzare alcuni degli elementi in un contenitore, viene utilizzato un numero inferiore di UR.

  • Numero di proprietà degli elementi: supponendo che sia applicata l'indicizzazione predefinita a tutte le proprietà, il numero di UR utilizzate per scrivere un elemento aumenta proporzionalmente al numero delle proprietà dell'elemento.

  • Proprietà indicizzate: I criteri di indicizzazione in ogni contenitore determinano le proprietà che vengono indicizzate per impostazione predefinita. Per ridurre il consumo di UR per le operazioni di scrittura, limitare il numero di proprietà indicizzate.

  • Coerenza dei dati: i livelli di coerenza assoluta e ristretta utilizzano circa due volte più UR durante l'esecuzione di operazioni di lettura rispetto a quella di altri livelli di coerenza rilassata.

  • Tipo di letture: le letture point costano meno UR rispetto alle query.

  • Modelli di query: la complessità di una query influisce sulla quantità di UR utilizzate per un'operazione. I fattori che influiscono sul costo delle operazioni di query sono:

    • Il numero di risultati della query
    • Il numero di predicati
    • La natura dei predicati
    • Il numero di funzioni definite dall'utente
    • Le dimensioni dei dati di origine
    • Le dimensioni del set di risultati
    • Proiezioni

    La stessa query sugli stessi dati costerà sempre lo stesso numero di UR in esecuzioni ripetute.

  • Utilizzo degli script: come per le query, le stored procedure e i trigger utilizzano ur in base alla complessità delle operazioni eseguite. Durante lo sviluppo dell'applicazione, controllare l'intestazione per l'addebito delle richieste per comprendere meglio quanta capacità in termini di UR viene utilizzata da ogni operazione.

Unità richiesta e più aree

Se si effettua il provisioning di UR "R" in un contenitore Cosmos (o in un database), Cosmos DB garantisce che le UR "R" siano disponibili in ogni area associata all'account Cosmos. Non è possibile assegnare in modo selettivo le UR a un'area specifica. Viene effettuato il provisioning delle UR di cui è stato effettuato il provisioning in un contenitore Cosmos (o in un database) in tutte le aree associate all'account Cosmos.

Supponendo che un contenitore Cosmos sia configurato con ur "R" e che siano presenti aree "N" associate all'account Cosmos, le UR totali disponibili a livello globale nel contenitore = R x N.

La scelta del modello di coerenza influisce anche sulla velocità effettiva. È possibile ottenere circa 2 volte la velocità effettiva di lettura per i livelli di coerenza più flessibili (sessione, prefisso coerente e coerenza finale ) rispetto ai livelli di coerenza più elevati (decadimento ristretto o coerenza assoluta ).

Passaggi successivi