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.
Azure DocumentDB offre la possibilità di ridimensionare i cluster sia verticalmente che orizzontalmente. Anche se il livello del cluster di calcolo e il disco di archiviazione dipendono l'uno dall'altro, la scalabilità e il costo di calcolo e archiviazione sono separati.
Scalabilità verticale
La scalabilità verticale offre i vantaggi seguenti:
- I team delle applicazioni potrebbero non avere sempre un percorso chiaro per partizionare logicamente i dati. Inoltre, il partizionamento orizzontale logico è definito per ogni raccolta. In un set di dati con diverse raccolte non partizionate, la modellazione dei dati per partizionare i dati può diventare noiosa. È sufficiente aumentare le prestazioni del cluster per aggirare la necessità di partizionamento orizzontale logico in base alle esigenze di archiviazione e calcolo crescenti dell'applicazione.
- Il ridimensionamento verticale non richiede il ribilanciamento dei dati. Il numero di partizioni fisiche rimane invariato e solo la capacità del cluster viene aumentata senza alcun impatto sull'applicazione.
- L'aumento e la riduzione della scala sono operazioni senza alcun tempo di inattività e senza interruzioni del servizio. Non sono necessarie modifiche all'applicazione e le operazioni di stato costante possono continuare a non essere interrotte.
- Le risorse di calcolo possono anche essere ridimensionate durante le finestre temporali note di attività basse. Anche in questo caso, la riduzione della scala evita la necessità di ribilanciare i dati su meno partizioni fisiche ed è un'operazione senza tempi di inattività e senza interruzioni del servizio. Anche in questo caso non sono necessarie modifiche all'applicazione dopo il ridimensionamento del cluster.
- Soprattutto, il calcolo e l'archiviazione possono essere ridimensionati in modo indipendente. Se sono necessari più core e memoria, le dimensioni del disco possono essere lasciate così come sono e il livello del cluster può essere ridimensionato. Allo stesso modo, se sono necessarie più risorse di archiviazione e operazioni di I/O al secondo, il livello del cluster può essere lasciato così come è e le dimensioni di archiviazione possono essere ridimensionate in modo indipendente. Se necessario, sia il calcolo che l'archiviazione possono essere ridimensionati in modo indipendente per ottimizzare singolarmente i requisiti di ogni componente, senza che i requisiti di elasticità di entrambi i componenti influiscano sull'altro.
Ridimensionamento orizzontale
Infine, l'applicazione cresce fino a un punto in cui il ridimensionamento verticale non è sufficiente. I requisiti del carico di lavoro possono aumentare oltre la capacità del livello del cluster più grande e alla fine sono necessarie più partizioni. La scalabilità orizzontale in Azure DocumentDB offre i vantaggi seguenti:
- I set di dati partizionati logicamente non richiedono l'intervento dell'utente per bilanciare i dati tra le partizioni fisiche sottostanti. Il servizio esegue automaticamente il mapping delle partizioni logiche alle partizioni fisiche. Quando i nodi vengono aggiunti o rimossi, i dati vengono ribilanciati automaticamente nel database sotto le quinte.
- Le richieste vengono indirizzate automaticamente alla partizione fisica pertinente proprietaria dell'intervallo hash per i dati sottoposti a query.
- I cluster con distribuzione geografica hanno una configurazione omogenea a più nodi. Di conseguenza, le mappature logiche su partizioni fisiche sono coerenti attraverso le regioni principali e di replica di un cluster.
Ridimensionamento delle risorse di calcolo e archiviazione
Le risorse di calcolo e memoria influenzano le operazioni di lettura in Azure DocumentDB più delle IOPS del disco.
- Le operazioni di lettura consultano prima la cache nel livello di calcolo e restituiscono il disco quando non è stato possibile recuperare i dati dalla cache. Per i carichi di lavoro con una velocità di lettura superiore al secondo, l'aumento del livello del cluster per ottenere più risorse di CPU e memoria comporta una velocità effettiva maggiore.
- Oltre alla velocità effettiva di lettura, i carichi di lavoro con un volume elevato di dati per operazione di lettura traggono vantaggio anche dal ridimensionamento delle risorse di calcolo del cluster. Ad esempio, i livelli del cluster con più memoria facilitano dimensioni di payload maggiori per documento e un numero maggiore di documenti più piccoli per risposta.
Gli IOPS del disco influiscono sulle operazioni di scrittura in Azure DocumentDB più delle capacità di CPU e memoria delle risorse di calcolo.
- Le operazioni di scrittura persistono sempre i dati su disco (oltre a rendere persistenti i dati in memoria per ottimizzare le letture). I dischi più grandi con più operazioni di I/O al secondo offrono una velocità effettiva di scrittura più elevata, in particolare quando vengono eseguiti su larga scala.
- Il servizio supporta fino a 32 TB di dischi per partizione, con più operazioni di I/O al secondo per partizione per trarre vantaggio dai carichi di lavoro di scrittura elevati, in particolare durante l'esecuzione su larga scala.
Carichi di lavoro pesanti di archiviazione e dischi di grandi dimensioni
Nessun requisito minimo di archiviazione per livello cluster
Come accennato in precedenza, le risorse di archiviazione e di calcolo vengono disaccoppiate per la fatturazione e il provisioning. Anche se funzionano come unità coesa, possono essere ridimensionate in modo indipendente. Il tier del cluster M30 può prevedere dischi da 32 TB. Analogamente, il livello del cluster M200 può avere un provisioning di 32 GB di dischi per ottimizzare sia i costi di archiviazione che di calcolo.
TCO inferiore con dischi di grandi dimensioni (32 TB e versioni successive)
In genere, i database NoSQL limitano l'archiviazione per ogni partizione fisica a 4 TB. Azure DocumentDB offre fino a 8 volte tale capacità con dischi da 32 TB. Per i carichi di lavoro con carico di archiviazione elevato, una capacità di archiviazione di 4 TB per ogni partizione fisica richiede un'enorme flotta di risorse di calcolo solo per sostenere i requisiti di archiviazione del carico di lavoro. Il calcolo è più costoso rispetto all'archiviazione e il sovraprovvedere il calcolo a causa dei limiti di capacità in un servizio può far rapidamente lievitare i costi.
Si consideri ora un carico di lavoro elevato per l'archiviazione con 200 TB di dati.
| Dimensioni di archiviazione per partizione | Numero minimo di partizioni necessarie per sostenere 200 TB |
|---|---|
| 4 TiB | 50 |
| 32 TiB | 7 |
La riduzione dei requisiti di calcolo diminuisce drasticamente con dischi più grandi. Sebbene sia necessario più del numero minimo di partizioni fisiche per sostenere i requisiti di velocità effettiva del carico di lavoro, anche il raddoppio o il tripling del numero di partizioni è più conveniente rispetto a un cluster di partizione da 50 con dischi più piccoli.
Ignorare la suddivisione in livelli dell'archiviazione con dischi di grandi dimensioni
Una risposta immediata ai costi di calcolo negli scenari con elevato utilizzo di archiviazione consiste nello "stratificare" i dati. I dati nel database transazionale sono limitati ai dati "ad accesso frequente", mentre il volume più grande di dati "a freddo" viene scollegato a un archivio a freddo. Ciò causa la complessità operativa. Le prestazioni sono anche imprevedibili e dipendono dal livello dati a cui si accede. Inoltre, la disponibilità dell'intero sistema dipende dalla resilienza degli archivi dati ad accesso frequente e sporadico combinati. Con dischi di grandi dimensioni nel servizio, non è necessaria alcuna risorsa di archiviazione a livelli, perché il costo dei carichi di lavoro di archiviazione massicci è ridotto al minimo.