Configurazioni delle risorse di calcolo e archiviazione per i cluster vCore di Azure Cosmos DB for MongoDB
SI APPLICA A: 
MongoDB vCore
Le risorse di calcolo vengono fornite come vCore, che rappresentano la CPU logica dell'hardware sottostante. Le dimensioni delle risorse di archiviazione per il provisioning si riferiscono alla capacità disponibile per gli shard nel cluster. Le risorse di archiviazione vengono usate per file di database, file temporanei, log di transazioni e log del server MySQL. È possibile selezionare le impostazioni delle risorse di calcolo e archiviazione in modo indipendente. I valori delle risorse di calcolo e archiviazione selezionati si applicano a ogni shard del cluster.
Risorse di calcolo in vCore di Azure Cosmos DB for MongoDB
La quantità totale di RAM in un singolo shard si basa sul numero selezionato di vCore.
| Livello cluster | vCore | Una partizione, GiB RAM |
|---|---|---|
| M25 | 2 (possibilità di burst) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Risorse di archiviazione in vCore di Azure Cosmos DB for MongoDB
Le risorse di archiviazione totali di cui si effettua il provisioning definiscono anche la capacità I/O disponibile per il server.
| Dimensioni delle risorse di archiviazione, GiB | Numero massimo di IOPS |
|---|---|
| 32 | 3.500† |
| 64 | 3.500† |
| 128 | 3.500† |
| 256 | 3.500† |
| 512 | 3.500† |
| 1.024 | 5,000 |
| 2.048 | 7.500 |
| 4.095 | 7.500 |
| 8,192 | 16.000 |
| 16,384 | 18.000 |
| 32.767 | 20.000 |
† Numero massimo di operazioni di I/O al secondo con bursting del disco gratuito. Archiviazione fino a 512 GiB inclusivi con bursting del disco gratuito abilitato.
Numero massimo di operazioni di I/O al secondo per la configurazione delle risorse di calcolo/archiviazione
La configurazione di ogni risorsa di calcolo ha un limite di operazioni di I/O al secondo che dipende dal numero di vCore. Assicurarsi di selezionare la configurazione delle risorse di calcolo per il cluster per usare completamente le operazioni di I/O al secondo nelle risorse di archiviazione selezionate.
| Dimensioni dello spazio di archiviazione | IOPS di archiviazione, max | Livello minimo delle risorse di calcolo | Numero minimo vCore |
|---|---|---|---|
| Fino a 0,5 TiB | 3.500† | M30 | 2 vCore |
| 1 TiB | 5,000 | M40 | 4 vCore |
| 2 TiB | 7.500 | M50 | 8 vCore |
| 4 TiB | 7.500 | M50 | 8 vCore |
| 8 TiB | 16.000 | M60 | 16 vCore |
| 16 TiB | 18.000 | M60 | 16 vCore |
| 32 TiB | 20.000 | M60 | 16 vCore |
† Numero massimo di operazioni di I/O al secondo con bursting del disco gratuito. Archiviazione fino a 512 GiB inclusivi con bursting del disco gratuito abilitato.
Ad esempio, se sono necessari almeno 8 TiB di archiviazione per shard, assicurarsi di selezionare almeno 16 vCore per la configurazione delle risorse di calcolo del nodo. Questa selezione consente di possibile ottimizzare l'utilizzo delle operazioni di I/O al secondo fornite dalla risorsa di archiviazione selezionata.
Considerazioni sulle risorse di calcolo e archiviazione
Considerazioni sul set di lavoro e sulla memoria
In vCore di Azure Cosmos DB for MongoDB, il set di lavoro si riferisce alla parte dei dati a cui si accede di frequente per l'uso con le applicazioni. Include sia i dati che gli indici che vengono letti o scritti regolarmente in durante le operazioni tipiche dell'applicazione. Il concetto di set di lavoro è importante per l'ottimizzazione delle prestazioni, perché MongoDB, come molti database, funziona meglio quando il set di lavoro è adatto alla RAM.
Per definire e comprendere il set di lavoro del database MongoDB, considerare i componenti seguenti:
- Dati a cui si accede di frequente: questi dati includono documenti letti o aggiornati regolarmente dall'applicazione.
- Indici: anche gli indici usati in operazioni di query fanno parte del set di lavoro, perché devono essere caricati in memoria per garantire un accesso rapido.
- Modelli di utilizzo dell'applicazione: l'analisi dei modelli di utilizzo dell'applicazione consente di identificare le parti dei dati a cui si accede più frequentemente.
Mantenendo il set di lavoro in RAM, è possibile ridurre al minimo le operazioni di I/O del disco più lente, migliorando così le prestazioni del database MongoDB. Se si rileva che il set di lavoro è superiore alla RAM disponibile, è consigliabile ottimizzare il modello di dati, aumentare la RAM o usare il partizionamento orizzontale per distribuire i dati tra più nodi.
Scelta della configurazione ottimale per un carico di lavoro
La determinazione della corretta configurazione delle risorse di calcolo e archiviazione per il carico di lavoro vCore di Azure Cosmos DB for MongoDB comporta la valutazione di diversi fattori correlati ai requisiti e ai modelli di utilizzo dell'applicazione. I passaggi chiave e le considerazioni per determinare la configurazione ottimale includono:
Conoscere il carico di lavoro
- Volume di dati: stimare le dimensioni totali dei dati, inclusi gli indici.
- Rapporto lettura/scrittura: determinare il rapporto tra operazioni di lettura e operazioni di scrittura.
- Modelli di query: analizzare i tipi di query eseguite dall'applicazione. Ad esempio, letture semplici, aggregazioni complesse.
- Concorrenza: valutare il numero di operazioni simultanee che il database deve gestire.
Monitorare le prestazioni correnti
- Utilizzo delle risorse: usare gli strumenti di monitoraggio per tenere traccia dell'utilizzo della CPU, della memoria, dell'I/O del disco e della rete prima di spostare il carico di lavoro in Azure e lemetriche di monitoraggio dopo aver avviato l'esecuzione del carico di lavoro di MongoDB in un cluster vCore di Azure Cosmos DB for MongoDB.
- Metriche delle prestazioni: monitorare le metriche delle prestazioni chiave, ad esempio latenza, velocità effettiva e rapporti di riscontri nella cache.
- Colli di bottiglia: identificare eventuali colli di bottiglia delle prestazioni, ad esempio utilizzo elevato della CPU, utilizzo elevato di memoria o I/O lento del disco.
Stimare i requisiti delle risorse
- Memoria: assicurarsi che il set di lavoro (dati e indici a cui si accede di frequente) si adatto alla RAM. Se le dimensioni del set di lavoro sono superiori alla memoria disponibile, è consigliabile aumentare la RAM o ottimizzare il modello di dati.
- CPU: scegliere una configurazione della CPU in grado di gestire i requisiti di carico e concorrenza delle query. Carichi di lavoro a elevato utilizzo di CPU possono richiedere più core. Usare la metrica "percentuale CPU" con aggregazione "Max" nel cluster vCore di Azure Cosmos DB for MongoDB per visualizzare i modelli di utilizzo storico delle risorse di calcolo.
- IOPS di archiviazione: selezionare risorse di archiviazione con operazioni di I/O al secondo sufficienti per gestire le operazioni di lettura e scrittura. Usare la metrica "IOPS" con aggregazione "Max" nel cluster per visualizzare l'utilizzo storico delle operazioni di I/O al secondo delle risorse di archiviazione.
- Rete: garantire una larghezza di banda di rete adeguata per gestire il trasferimento dei dati tra l'applicazione e il database, in particolare per le configurazioni distribuite. Assicurarsi di aver configurato l'host per l'applicazione di MongoDB per il supporto delle tecnologie della rete accelerata, ad esempio SR-IOV.
Eseguire il ridimensionamento in modo appropriato
- Ridimensionamento verticale: aumentare le risorse di calcolo / la RAM e ridurre e aumentare le risorse di archiviazione.
- Risorse di calcolo: aumentare la vCore / la RAM in un cluster se il carico di lavoro richiede un aumento temporaneo o spesso supera il 70% dell'utilizzo della CPU per periodi prolungati.
- Assicurarsi di disporre di una conservazione dei dati appropriata nel database vCore di Azure Cosmos DB for MongoDB. La conservazione consente di evitare l'uso di risorse di archiviazione non necessarie. Monitorare l'utilizzo dell'archiviazione impostando avvisi sulle metriche "Percentuale archiviazione" e/o "Archiviazione usata" con l'aggregazione "Max". Considerare l'aumento delle risorse di archiviazione quando le dimensioni del carico di lavoro superano il 70% di utilizzo.
- Ridimensionamento orizzontale: considerare l'uso di più shard per il cluster per distribuire i dati in più nodi vCore di Azure Cosmos DB for MongoDB per migliorare le prestazioni e la gestione della capacità mano a mano che il carico di lavoro aumenta. Ciò è particolarmente utile per set di dati di grandi dimensioni (oltre 2-4 TiB) e applicazioni a velocità effettiva elevata.
- Ridimensionamento verticale: aumentare le risorse di calcolo / la RAM e ridurre e aumentare le risorse di archiviazione.
Test e iterazione
- Benchmarking: eseguire la misurazione per le query usate più di frequente con configurazioni diverse per determinare l'impatto sulle prestazioni. Usare metriche CPU/RAM e IOPS e il benchmarking a livello di applicazione.
- Test di carico: eseguire test di carico per simulare i carichi di lavoro di produzione e convalidare le prestazioni della configurazione scelta.
- Monitoraggio continuo: monitorare continuamente la distribuzione vCore di Azure Cosmos DB for MongoDB e adattare le risorse alle esigenze in base alla modifica dei carichi di lavoro e dei modelli di utilizzo.
Valutando sistematicamente questi fattori e monitorando e modificando continuamente la configurazione, è possibile assicurarsi che la distribuzione di MongoDB sia ottimizzata correttamente per il carico di lavoro specifico.
Considerazioni sull'archiviazione
La scelta delle dimensioni di archiviazione appropriate per il carico di lavoro comporta diverse considerazioni per garantire prestazioni e scalabilità ottimali. Di seguito sono riportate alcune considerazioni sulle dimensioni di archiviazione in vCore di Azure Cosmos DB for MongoDB:
Stimare le dimensioni dei dati:
- Calcolare le dimensioni previste dei dati vCore di Azure Cosmos DB for MongoDB. Prendere in considerazione:
- Dimensioni dei dati correnti: se si esegue la migrazione da un database esistente.
- Tasso di crescita: stimare la quantità di dati che verranno aggiunti nel tempo.
- Dimensioni e struttura dei documenti: valutare lo schema dei dati e le dimensioni dei documenti, in quanto influiscono sull'efficienza di archiviazione.
- Calcolare le dimensioni previste dei dati vCore di Azure Cosmos DB for MongoDB. Prendere in considerazione:
Fattore negli indici:
- vCore di Azure Cosmos DB for MongoDB usa indici per eseguire query efficienti. Gli indici utilizzano spazio su disco aggiuntivo.
- Stimare le dimensioni degli indici in base a:
- Numero di indici.
- Dimensione dei campi indicizzati.
Considerazioni sulle prestazioni:
- Le prestazioni del disco influiscono sulle operazioni del database, in particolare per i carichi di lavoro che non possono adattarsi al set di lavoro in RAM. Prendere in considerazione:
- Velocità effettiva I/O: IOPS, o operazioni di input/output al secondo, è il numero di richieste inviate ai dischi di archiviazione in un secondo. Maggiori dimensioni di archiviazione più grandi comportano un numero maggiore di IOPS. Garantire una velocità effettiva adeguata per le operazioni di lettura/scrittura. Usare la metrica "IOPS" con aggregazione "Max" per monitorare le operazioni di I/O al secondo usate nel cluster.
- Latenza: la latenza è il tempo necessario perché un'applicazione riceva una singola richiesta, la invii ai dischi di archiviazione e invii la risposta al client. La latenza è una misura essenziale delle prestazioni di un'applicazione, oltre a IOPS e velocità effettiva. La latenza è in gran parte definita dal tipo di risorsa di archiviazione usato e dalla relativa configurazione. In un servizio gestito come Azure Cosmos DB for MongoDB, l'archiviazione veloce, ad esempio dischi SSD Premium, viene usata con impostazioni ottimizzate per ridurre la latenza.
- Le prestazioni del disco influiscono sulle operazioni del database, in particolare per i carichi di lavoro che non possono adattarsi al set di lavoro in RAM. Prendere in considerazione:
Crescita e scalabilità future:
- Pianificare i requisiti di crescita e scalabilità dei dati futuri.
- Allocare più spazio su disco oltre le esigenze correnti per supportare la crescita senza espansioni frequenti delle risorse di archiviazione.
Esempio di calcolo:
- Si supponga che le dimensioni iniziali dei dati siano 500 GiB.
- Con gli indici, potrebbero crescere fino a 700 GiB.
- Se si prevede di raddoppiare i dati in due anni, pianificare 1,4 TiB (700 GiB * 2).
- Aggiungere un buffer per i requisiti generali, di crescita e operativi.
- Al presente potrebbe essere opportuno iniziare con 1 TiB di archiviazione e aumentare fino a 2 TiB una volta che le dimensioni aumentano oltre 800 GiB.
La decisione sulle dimensioni delle risorse archiviazione richiede una stima combinata dei requisiti di dati attuali e futuri, considerando l'indicizzazione e la compressione e garantendo prestazioni e scalabilità adeguate. Anche il monitoraggio e la regolazione regolari in base alle tendenze di utilizzo e crescita effettive sono fondamentali per mantenere prestazioni ottimali di MongoDB.