Unità richiesta in Azure Cosmos DB

  • Articolo

SI APPLICA A: NoSQL MongoDB Cassandra Gremlin Tabella

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à.

Azure Cosmos DB normalizza il costo di tutte le operazioni del database usando unità richiesta (o UR in breve) e misura il costo in base alla velocità effettiva (unità richiesta al secondo, UR/sec).

Un'unità richiesta è una valuta basata sulle prestazioni determinata in base all'astrazione delle 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. Indipendentemente dal fatto che l'operazione di database sia un'operazione di scrittura, lettura punto o query, le operazioni vengono sempre misurate in UR. Ad esempio, 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 è un'unità richiesta (o una UR), indipendentemente dall'API usata per interagire con il contenitore di Azure Cosmos DB. È possibile modellare i costi di velocità effettiva usando il Calcolatore della capacità di Azure Cosmos DB.

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

Database operations consume Request Units

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. Una volta identificati i fattori che influiscono sugli addebiti delle unità richiesta e i requisiti di velocità effettiva dell'applicazione, è possibile eseguire l'applicazione in modo economicamente conveniente.

Il tipo di account Azure Cosmos DB 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 numero di unità richiesta (UR) per l'applicazione viene assegnato 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. La fattura viene generata in base oraria per il numero di UR al secondo di cui è stato effettuato il provisioning. Per altre informazioni, vedere l'articolo Velocità effettiva con provisioning.

    È possibile assegnare la velocità effettiva a due diversi livelli di granularità:

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

  3. Modalità Scalabilità automatica: in questa modalità è possibile dimensionare automaticamente e immediatamente la velocità effettiva (UR/s) del database o del contenitore in base all'utilizzo. Questa operazione di dimensionamento non influisce sulla disponibilità, sulla 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 della dimensione di un elemento, aumenta anche il numero di UR utilizzate per leggere o scrivere l'elemento.

  • Indicizzazione degli elementi: per impostazione predefinita, ogni elemento viene indicizzato automaticamente. 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: durante l'esecuzione di operazioni di lettura, i livelli di coerenza assoluta e con decadimento ristretto utilizzano un numero di UR di due volte maggiore rispetto ad altri livelli di coerenza meno rigidi.

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

  • Modelli di query: la complessità di una query influisce sulla quantità di unità richiesta 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 costa sempre lo stesso numero di UR per esecuzioni ripetute.

  • Utilizzo di script: come le query, le stored procedure e i trigger utilizzano le UR in base alla complessità delle operazioni da eseguire. 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 assegnano "R" UR in un contenitore o un database di Azure Cosmos DB, Azure Cosmos DB garantisce che "R" UR siano disponibili in ogni area associata all'account Azure Cosmos DB. 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 o in un database di Azure Cosmos DB in tutte le aree associate all'account Azure Cosmos DB.

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

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

Passaggi successivi