Ottimizzare i costi per più aree in Azure Cosmos DB

  • Si applica a: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Puoi aggiungere e rimuovere aree nell'account Azure Cosmos DB in qualsiasi momento. La "throughput" che configuri per i vari database e contenitori di Azure Cosmos DB è riservata in ogni regione associata al tuo account. Se il throughput di cui è stato effettuato il provisioning ogni ora, calcolato come la somma delle unità di richiesta al secondo (RU/s) configurate in tutti i database e contenitori per il tuo account Azure Cosmos DB, è T e il numero di regioni Azure associate all'account del database è N, allora il throughput totale con provisioning per il tuo account Azure Cosmos DB, per una determinata ora, è uguale a T x N RU/s.

La velocità effettiva con provisioning con una singola area di scrittura e la velocità effettiva con provisioning con più aree scrivibili possono variare in base al costo. Per altre informazioni, vedere Prezzi di Azure Cosmos DB.

Costi per più aree di scrittura

In un sistema di scrittura multi-area, le UR/s nette disponibili per le operazioni di scrittura aumentano di N volte, dove N è il numero di aree di scrittura. A differenza delle operazioni di scrittura in una singola area, ogni area è ora accessibile in scrittura e supporta la risoluzione dei conflitti. Dal punto di vista della pianificazione dei costi, per eseguire M RU/s di scrittura a livello globale, è necessario configurare M RU/s al livello di un contenitore o di un database. È quindi possibile aggiungere tutte le aree desiderate e usarle per operazioni di scrittura per effettuare M RU/s di scritture in tutto il mondo.

Example

Si consideri che si dispone di un contenitore in uno scenario di scrittura a singola area. Questo contenitore viene sottoposto a provisioning con velocità effettiva di 10K UR/sec e archivia 0.5 TB di dati del mese in corso. Si supponga ora di aggiungere un'altra area con lo stesso spazio di archiviazione e velocità effettiva e si vuole poter scrivere nei contenitori in entrambe le aree dell'app.

In questo esempio viene illustrato il nuovo consumo mensile totale:

Utilizzo mensile
Fatturazione della velocità effettiva per il contenitore in una singola area di scrittura 10K RU/s * 730 hours
Fattura del throughput del contenitore in più regioni di scrittura (due) 2 * 10K RU/s * 730 hours
Tariffazione dell'archiviazione per contenitore in una singola regione di scrittura 0.5 TB (or 512 GB)
Costo di archiviazione per contenitore in due regioni di scrittura 2 * 0.5 TB (or 1,024 GB)

Annotazioni

Questo esempio presuppone 730 ore in un mese.

Migliorare l'uso della velocità effettiva per singola area

Se si dispone di un utilizzo inefficiente, è possibile eseguire le operazioni necessarie per usare al massimo le UR/sec nelle aree di lettura usando il feed di modifiche dall'area di lettura. In alternativa, è possibile passare a un altro secondario se sovrautilizzato. Ad esempio, una o più aree di lettura sottoutilizzate sono considerate inefficienti. È necessario assicurarsi di ottimizzare il throughput provvisto (RU/s) prima di tutto nella regione di scrittura.

Le operazioni di scrittura costano di più rispetto alle letture nella maggior parte dei casi, escludendo le query di grandi dimensioni. Il mantenimento di un utilizzo uniforme può risultare complesso. In generale, monitora il throughput consumato nelle tue regioni e aggiungi o rimuovi regioni su richiesta per scalare il throughput di lettura e scrittura. Assicurarsi di comprendere l'effetto per la latenza delle app distribuite nella stessa area.

Contenuti correlati

  • Last updated on