Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le risorse di calcolo di Azure DocumentDB 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.
Lo spazio di archiviazione viene usato per i file di database, i file temporanei, i log delle transazioni e i log del server di database. È possibile selezionare le impostazioni di calcolo e archiviazione in modo indipendente. I valori di calcolo e archiviazione selezionati si applicano a ogni partizione del cluster.
Calcolo in Azure DocumentDB
La quantità totale di RAM in una singola partizione si basa sul numero selezionato di vCore.
| Livello cluster | vCores | Una partizione, GiB RAM |
|---|---|---|
| M10 | 1 (con possibilità di burst) | 2 |
| M20 | 2 (burstable) | 4 |
| M25 | 2 (con possibilità di burst) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Archiviazione in Azure DocumentDB
La quantità totale di spazio di archiviazione assegnata definisce anche la capacità di I/O disponibile per ogni partizione nel cluster.
| Dimensioni 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 IOPS (operazioni di input/output al secondo) con bursting del disco libero. Archiviazione fino a 512 GiB inclusivi con possibilità di bursting del disco gratuito abilitato.
Massimizzare gli IOPS per la configurazione di calcolo e archiviazione.
Ogni configurazione di calcolo ha un limite di operazioni di I/O al secondo che dipende dal numero di vCore. Assicurarsi di selezionare la configurazione di calcolo per il cluster per usare completamente le operazioni di I/O al secondo nella risorsa di archiviazione selezionata.
| Dimensioni dello spazio di archiviazione | IOPS di archiviazione, fino a | Livello di calcolo minimo | Numero minimo di vCore |
|---|---|---|---|
| Fino a 0,5 TiB | 3,500† | M30 | 2 vCore |
| 1 TiB (tebibyte, unità di misura per lo spazio di archiviazione digitale) | 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 possibilità di bursting del disco gratuito. Archiviazione fino a 512 GiB inclusivi con possibilità di bursting del disco gratuito abilitato.
Ad esempio, se sono necessari 8 TiB di archiviazione per ogni partizione o più, assicurarsi di selezionare 16 vCore o più per la configurazione di calcolo del nodo. Questa selezione consente di ottimizzare l'utilizzo delle operazioni di I/O al secondo fornite dall'archiviazione selezionata.
Considerazioni per il calcolo e l'archiviazione
Quando si configura il cluster Azure DocumentDB, è importante comprendere in che modo le scelte di calcolo e archiviazione influiscono sulle prestazioni, sui costi e sulla scalabilità per il carico di lavoro specifico.
Considerazioni sul working set e sulla memoria
In Azure DocumentDB il working set fa riferimento alla parte dei dati a cui si accede di frequente e usata dalle applicazioni. Include sia i dati che gli indici che vengono letti o scritti regolarmente in durante le operazioni tipiche dell'applicazione. Il concetto di working set è importante per l'ottimizzazione delle prestazioni perché MongoDB, come molti database, offre prestazioni ottimali quando il working set si adatta alla RAM.
Per definire e comprendere il working set di database MongoDB, considerare i componenti seguenti:
- Dati a cui si accede di frequente: questi dati includono documenti letti o aggiornati regolarmente dall'applicazione.
- Indici: gli indici usati nelle operazioni di query fanno anche parte del working set perché devono essere caricati in memoria per garantire un accesso rapido.
- Modelli di utilizzo delle applicazioni: l'analisi dei modelli di utilizzo dell'applicazione consente di identificare le parti dei dati a cui si accede più frequentemente.
Mantenendo il working set in RAM, è possibile ridurre al minimo le operazioni di I/O del disco più lente, migliorando così le prestazioni del database MongoDB. Se il working set supera la RAM disponibile, prendere in considerazione l'ottimizzazione del modello di dati, l'aggiunta di più RAM al cluster o l'uso del partizionamento orizzontale per distribuire i dati tra più nodi.
Scegliere una configurazione ottimale per un carico di lavoro
Determinare la configurazione di calcolo e archiviazione corretta per il carico di lavoro di Azure DocumentDB 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:
Comprendere 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 eseguire la migrazione del carico di lavoro ad Azure. Dopo aver distribuito il carico di lavoro MongoDB in un cluster di Azure DocumentDB, continuare a monitorare usando le metriche di monitoraggio di Azure.
- 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 working set (dati e indici a cui si accede di frequente) si adatti alla RAM. Se le dimensioni del working set superano la memoria disponibile, è consigliabile aggiungere più 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. I carichi di lavoro a elevato utilizzo di CPU potrebbero richiedere più core. Usare la metrica "percentuale di utilizzo della CPU" con l'aggregazione "Max" sul cluster di Azure DocumentDB per visualizzare i modelli di utilizzo di calcolo nel tempo.
- IOPS di archiviazione: selezionare uno storage con IOPS 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, soprattutto per le configurazioni distribuite. Assicurarsi di aver configurato l'host per l'applicazione MongoDB per supportare tecnologie di rete accelerate , ad esempio SR-IOV.
Ridimensionare in modo appropriato
-
Scalabilità verticale: consente di aumentare e ridurre le risorse di calcolo/RAM e aumentare le risorse di archiviazione.
- Calcolo: aumentare il vCore/RAM in un cluster se il carico di lavoro richiede un aumento temporaneo o spesso supera 70% di utilizzo della CPU per periodi prolungati.
- Assicurarsi di disporre della conservazione dei dati appropriata nel database di Azure DocumentDB. 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 dello spazio di archiviazione quando la dimensione del carico di lavoro supera il 70% dell'utilizzo.
- Scalabilità orizzontale: è consigliabile usare più partizioni per il cluster per distribuire i dati in più nodi di Azure DocumentDB per ottenere miglioramenti delle prestazioni e migliorare la gestione della capacità man mano che aumenta il carico di lavoro. Questa scalabilità è particolarmente utile per set di dati di grandi dimensioni (oltre 2-4 TiB) e per applicazioni a velocità effettiva elevata.
-
Scalabilità verticale: consente di aumentare e ridurre le risorse di calcolo/RAM e aumentare le risorse di archiviazione.
Testare ed eseguire l'iterazione
- Benchmarking: eseguire la misurazione per le query usate più di frequente con configurazioni diverse per determinare l'effetto sulle prestazioni. Usare le 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 di Azure DocumentDB e regolare le risorse in base 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. Ecco alcune considerazioni sulle dimensioni di archiviazione in Azure DocumentDB:
Stimare le dimensioni dei dati:
- Calcolare le dimensioni previste dei dati di Azure DocumentDB. Considera:
- Dimensioni correnti dei dati: 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 del documento: Comprendere lo schema dei dati e le dimensioni dei documenti, in quanto influiscono sull'efficienza di archiviazione.
- Calcolare le dimensioni previste dei dati di Azure DocumentDB. Considera:
Fattore negli indici:
- Azure DocumentDB usa gli indici per eseguire query efficienti. Gli indici utilizzano spazio su disco aggiuntivo.
- Stimare le dimensioni degli indici in base a:
- Numero di indici.
- Dimensioni 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. Considera:
- Velocità effettiva di I/O: IOPS, ovvero operazioni di input/output al secondo, è il numero di richieste inviate ai dischi di archiviazione in un secondo. Le dimensioni di archiviazione più grandi hanno un numero maggiore di operazioni di I/O al secondo. Garantire una velocità effettiva adeguata per le operazioni di lettura/scrittura. Usare la metrica "IOPS" con l'aggregazione "Max" per monitorare gli IOPS utilizzati sul tuo cluster.
- Latenza: La latenza è il tempo necessario per un'applicazione per ricevere una singola richiesta, inviarla ai dischi di archiviazione e inviare la risposta al client. La latenza è una misura critica delle prestazioni di un'applicazione oltre alle operazioni di I/O al secondo e alla velocità effettiva. Il tipo di archiviazione usato e la configurazione di archiviazione definiscono in gran parte la latenza. In un servizio gestito come Azure DocumentDB, l'archiviazione veloce, ad esempio i dischi SSD Premium, viene usata con le 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. Considera:
Crescita e scalabilità future:
- Pianificare future esigenze di crescita e scalabilità dei dati.
- Allocare più spazio su disco oltre le esigenze correnti per supportare la crescita senza frequenti espansioni di archiviazione.
Calcolo di esempio:
- Si supponga che le dimensioni iniziali dei dati siano pari a 500 GiB.
- Con gli indici, potrebbe 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 le esigenze generali, di crescita e operative.
- Si potrebbe voler iniziare con uno spazio di archiviazione da 1 TiB oggi e espanderlo a 2 TiB una volta che la sua dimensione cresce oltre 800 GiB.
La scelta delle dimensioni di archiviazione prevede una combinazione di stima delle esigenze dei dati correnti e future, 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.
Che cos'è il calcolo con possibilità di burst?
Il livello burstable offre una soluzione intelligente personalizzata per piccoli carichi di lavoro di database. Fornendo prestazioni minime della CPU durante i periodi di inattività, questi cluster ottimizzano l'utilizzo delle risorse. Tuttavia, la reale brillantezza risiede nella capacità di aumentare facilmente la potenza della CPU fino a raggiungere la massima potenza della CPU in risposta a un aumento del traffico o delle richieste del carico di lavoro. Questa adattabilità offre prestazioni di picco esattamente quando necessario, offrendo un notevole risparmio sui costi.
Riducendo il punto di prezzo iniziale del servizio, il livello cluster burstable di Azure DocumentDB mira a facilitare l'onboarding e l'esplorazione degli utenti di Azure DocumentDB a prezzi ridotti. Questa democratizzazione dell'accesso consente alle aziende di tutte le dimensioni di sfruttare la potenza di Azure DocumentDB senza spendere una fortuna. Che si tratti di una startup, di una piccola azienda o di un'azienda, questo livello offre nuove possibilità di scalabilità conveniente.
Il provisioning di un livello con possibilità di burst è semplice quanto il provisioning di livelli standard; è sufficiente scegliere "M10," "M20," or "M25" nell'opzione del livello cluster. Ecco una guida introduttiva che offre istruzioni dettagliate su come configurare un cluster di Azure DocumentDB .