Procedure consigliate per il dimensionamento della velocità effettiva con provisioning (UR/sec)

SI APPLICA A: NoSQL MongoDB Cassandra Gremlin Tabella

Questo articolo descrive le procedure consigliate e le strategie per ridimensionare la velocità effettiva (UR/sec) del database o del contenitore (raccolta, tabella o grafico). I concetti si applicano quando si aumentano le UR/sec manuali di cui è stato effettuato il provisioning o il numero massimo di UR/sec di scalabilità automatica di qualsiasi risorsa per qualsiasi API di Azure Cosmos DB.

Prerequisiti

• Se non si ha familiarità con il partizionamento e il ridimensionamento in Azure Cosmos DB, è consigliabile leggere prima l'articolo partizionamento e scalabilità orizzontale in Azure Cosmos DB.
• Se si prevede di dimensionare le UR/sec a causa di 429 eccezioni, esaminare le indicazioni riportate in Diagnosticare e risolvere i problemi di frequenza delle richieste di Azure Cosmos DB troppo grandi (429) eccezioni. Prima di aumentare le UR/sec, identificare la causa radice del problema e se l'aumento di UR/s è la soluzione corretta.

Informazioni generali sul ridimensionamento di UR/sec

Quando si invia una richiesta per aumentare le UR/sec del database o del contenitore, a seconda delle UR/s richieste e del layout della partizione fisica corrente, l'operazione di aumento delle prestazioni verrà completata immediatamente o in modo asincrono (in genere 4-6 ore).

• Scalabilità immediata
  • Quando le UR/sec richieste possono essere supportate dal layout di partizione fisica corrente, Azure Cosmos DB non deve suddividere o aggiungere nuove partizioni.
  • Di conseguenza, l'operazione viene completata immediatamente e le UR/s sono disponibili per l'uso.
• Scalabilità orizzontale asincrona
  • Quando le UR/sec richieste sono superiori a quelle che possono essere supportate dal layout di partizione fisica, Azure Cosmos DB dividerà le partizioni fisiche esistenti. Ciò si verifica fino a quando la risorsa ha il numero minimo di partizioni necessarie per supportare le UR/sec richieste.
  • Di conseguenza, il completamento dell'operazione può richiedere del tempo, in genere 4-6 ore. Ogni partizione fisica può supportare un massimo di 10.000 UR/sec di velocità effettiva (si applica a tutte le API) e 50 GB di archiviazione (si applica a tutte le API, ad eccezione di Cassandra, con 30 GB di archiviazione).

Nota

Se si esegue un'operazione di failover manuale dell'area o si aggiunge/rimuove una nuova area mentre è in corso un'operazione di aumento delle prestazioni asincrona, l'operazione di aumento delle prestazioni della velocità effettiva verrà sospesa. Verrà ripreso automaticamente al termine dell'operazione di failover o aggiunta/rimozione dell'area.

• Riduzione immediata
  • Per l'operazione di riduzione delle prestazioni, Azure Cosmos DB non deve suddividere o aggiungere nuove partizioni.
  • Di conseguenza, l'operazione viene completata immediatamente e le UR/s sono disponibili per l'uso.
  • Il risultato chiave di questa operazione è che le UR per ogni partizione fisica verranno ridotte.

Come aumentare le UR/sec senza modificare il layout della partizione

Passaggio 1: Trovare il numero corrente di partizioni fisiche.

Passare a Dati analitici>Velocità effettiva>Consumo normalizzato di UR (%) per PartitionKeyRangeID. Contare il numero distinto di PartitionKeyRangeIds.

Nota

Il grafico mostrerà solo un massimo di 50 PartitionKeyRangeIds. Se la risorsa ha più di 50, è possibile usare l'API REST di Azure Cosmos DB per contare il numero totale di partizioni.

Ogni PartitionKeyRangeId esegue il mapping a una partizione fisica e viene assegnato per contenere i dati per un intervallo di possibili valori hash.

Azure Cosmos DB distribuisce i dati tra partizioni logiche e fisiche in base alla chiave di partizione per abilitare il ridimensionamento orizzontale. Durante la scrittura dei dati, Azure Cosmos DB usa l'hash del valore della chiave di partizione per determinare la partizione logica e fisica in cui si trovano i dati.

Passaggio 2: Calcolare la velocità effettiva massima predefinita

Le UR/s più elevate che è possibile dimensionare senza attivare Azure Cosmos DB per suddividere le partizioni è uguale a Current number of physical partitions * 10,000 RU/s. È possibile ottenere questo valore dal provider di risorse di Azure Cosmos DB. Eseguire una richiesta GET negli oggetti di impostazione della velocità effettiva del database o contenitore e recuperare la proprietà instantMaximumThroughput. Questo valore è disponibile anche nella pagina Scalabilità e impostazioni del database o del contenitore nel portale.

Esempio

Si supponga di avere un contenitore esistente con cinque partizioni fisiche e 30.000 UR/sec di velocità effettiva con provisioning manuale. È possibile aumentare le UR/sec a 5 * 10.000 UR/s = 50.000 UR/sec immediatamente. Analogamente, se si dispone di un contenitore con numero massimo di UR/sec con scalabilità automatica pari a 30.000 UR/sec (scalabilità compresa tra 3000 e 30.000 UR/sec), è possibile aumentare il numero massimo di UR/sec a 50.000 UR/sec in modo istantaneo (scalabilità compresa tra 5000 e 50.000 UR/sec).

Suggerimento

Se si aumentano le UR/sec per rispondere alle eccezioni di frequenza delle richieste troppo grandi (429s), è consigliabile aumentare prima di tutto LE UR/sec al numero massimo di UR/sec supportato dal layout della partizione fisica corrente e valutare se la nuova UR/s è sufficiente prima di aumentare ulteriormente.

Come garantire anche la distribuzione dei dati durante il ridimensionamento asincrono

Background

Quando si aumentano le UR/sec oltre il numero corrente di partizioni fisiche * 10.000 UR/s, Azure Cosmos DB divide le partizioni esistenti fino al nuovo numero di partizioni = ROUNDUP(requested RU/s / 10,000 RU/s). Durante una suddivisione, le partizioni padre vengono suddivise in due partizioni figlio.

Si supponga, ad esempio, di avere un contenitore con tre partizioni fisiche e 30.000 UR/sec di velocità effettiva con provisioning manuale. Se è stata aumentata la velocità effettiva a 45.000 UR/sec, Azure Cosmos DB dividerà due delle partizioni fisiche esistenti in modo che, in totale, ci siano ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 partizioni fisiche.

Nota

Durante una suddivisione, le applicazioni possono sempre inserire dati o eseguire query su di loro. Gli SDK e il servizio client di Azure Cosmos DB gestiscono automaticamente questo scenario e assicurano che le richieste vengano instradate alla partizione fisica corretta, quindi non è necessaria alcuna azione aggiuntiva da parte dell'utente.

Se si dispone di un carico di lavoro molto uniformemente distribuito rispetto all'archiviazione e al volume—delle richieste in genere eseguito partizionando in base a campi di cardinalità elevata come /id—, è consigliabile aumentare le prestazioni, impostare UR/s in modo che tutte le partizioni vengano suddivise in modo uniforme.

Per vedere perché, si prenda un esempio in cui è disponibile un contenitore esistente con 2 partizioni fisiche, 20.000 UR/sec e 80 GB di dati.

Grazie alla scelta di una chiave di partizione valida con cardinalità elevata, i dati vengono distribuiti approssimativamente in entrambe le partizioni fisiche. A ogni partizione fisica viene assegnato circa il 50% dello spazio chiavi, definito come intervallo totale di possibili valori hash.

Azure Cosmos DB distribuisce anche le UR/s in modo uniforme in tutte le partizioni fisiche. Di conseguenza, ogni partizione fisica ha 10.000 UR/s e il 50% (40 GB) dei dati totali. Il diagramma seguente mostra lo stato corrente.

Si supponga ora di voler aumentare le UR/sec da 20.000 UR/sec a 30.000 UR/sec.

Se le UR/sec sono semplicemente aumentate a 30.000 UR/sec, verrà suddivisa solo una delle partizioni. Dopo la divisione, avremo:

• Una partizione che contiene il 50% dei dati (questa partizione non è stata divisa)
• Due partizioni che contengono il 25% dei dati ciascuno (si tratta delle partizioni figlio risultanti dall'elemento padre diviso)

Poiché Azure Cosmos DB distribuisce le UR/s in modo uniforme in tutte le partizioni fisiche, ogni partizione fisica otterrà comunque 10.000 UR/sec. Tuttavia, è ora disponibile un'asimmetria nell'archiviazione e nella distribuzione delle richieste.

Nel diagramma seguente si noterà che le partizioni 3 e 4 (le partizioni figlio della partizione 2) ognuna ha 10.000 UR/s per gestire le richieste per 20 GB di dati, mentre la partizione 1 ha 10.000 UR/s per gestire le richieste per il doppio della quantità di dati (40 GB).

Per mantenere una distribuzione di archiviazione uniforme, è prima possibile aumentare le UR/s per garantire la suddivisione di ogni partizione. Quindi, è possibile abbassare le UR/s fino allo stato desiderato.

Pertanto, se si inizia con due partizioni fisiche, per garantire che le partizioni siano anche dopo la suddivisione, è necessario impostare UR/s in modo che si finirà con quattro partizioni fisiche. A tale scopo, verrà prima impostato UR/s = 4 * 10.000 UR/sec per partizione = 40.000 UR/sec. Al termine della divisione, è possibile abbassare le UR/sec a 30.000 UR/sec.

Di conseguenza, si noterà nel diagramma seguente che ogni partizione fisica ottiene 30.000 UR/s / 4 = 7500 UR/s per gestire le richieste per 20 GB di dati. Nel complesso, viene gestita anche la distribuzione di archiviazione e richiesta tra le partizioni.

Formula generale

Passaggio 1: Aumentare le UR/sec per garantire che tutte le partizioni siano suddivise in modo uniforme

In generale, se si dispone di un numero iniziale di partizioni fisiche P e si vuole impostare SUR/s desiderate:

Aumentare le UR/s a: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). In questo modo, le UR/sec più vicine al valore desiderato garantiranno che tutte le partizioni vengano suddivise in modo uniforme.

Nota

Quando si aumentano le UR/sec di un database o di un contenitore, ciò può influire sulle UR/sec minime che è possibile ridurre in futuro. In genere, il numero minimo di UR/sec è uguale a MAX(400 UR/s, Spazio di archiviazione corrente in GB * 1 UR/s, ur/sec più alto mai sottoposto a provisioning / 100). Ad esempio, se le UR/sec più elevate che hai mai dimensionato sono pari a 100.000 UR/sec, le UR/sec più basse che puoi impostare in futuro sono pari a 1000 UR/sec. Altre informazioni sulle ur/sec minime.

Passaggio 2: Abbassare le UR/sec alle UR/sec desiderate

Si supponga, ad esempio, di avere cinque partizioni fisiche, 50.000 UR/sec e che si voglia dimensionare fino a 150.000 UR/sec. È necessario prima impostare: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200.000 UR/sec e quindi inferiore a 150.000 UR/sec.

Quando sono stati dimensionati fino a 200.000 UR/sec, le UR/sec manuali più basse che è ora possibile impostare in futuro sono 2000 UR/sec. Il numero massimo di UR/sec con scalabilità automatica più bassa che è possibile impostare è di 20.000 UR/s (scale comprese tra 2000 e 20.000 UR/sec). Poiché le UR/sec di destinazione sono pari a 150.000 UR/sec, non sono interessate dalle UR/sec minime.

Come ottimizzare le UR/sec per l'inserimento di dati di grandi dimensioni

Quando si prevede di eseguire la migrazione o l'inserimento di una grande quantità di dati in Azure Cosmos DB, è consigliabile impostare le UR/sec del contenitore in modo che Azure Cosmos DB sottoponga preventivamente a provisioning le partizioni fisiche necessarie per archiviare la quantità totale di dati che si prevede di inserire in anticipo. In caso contrario, durante l'inserimento, Azure Cosmos DB potrebbe dover suddividere le partizioni, che aggiunge più tempo all'inserimento dei dati.

È possibile sfruttare il fatto che durante la creazione del contenitore, Azure Cosmos DB usa la formula euristica di avvio di UR/sec per calcolare il numero di partizioni fisiche da iniziare.

Passaggio 1: Esaminare la scelta della chiave di partizione

Seguire le procedure consigliate per scegliere una chiave di partizione per assicurarsi di avere anche la distribuzione del volume delle richieste e dell'archiviazione dopo la migrazione.

Passaggio 2: Calcolare il numero di partizioni fisiche necessarie

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Ogni partizione fisica può contenere un massimo di 50 GB di spazio di archiviazione (30 GB per l'API per Cassandra). Il valore che è necessario scegliere per Target data per physical partition in GB dipende dal modo in cui le partizioni fisiche devono essere completamente compresse e dalla quantità di spazio di archiviazione che si prevede di aumentare dopo la migrazione.

Ad esempio, se si prevede che l'archiviazione continuerà a crescere, è possibile scegliere di impostare il valore su 30 GB. Supponendo di aver scelto una chiave di partizione valida che distribuisca in modo uniforme l'archiviazione, ogni partizione sarà completa del 60% (30 GB su 50 GB). Man mano che vengono scritti i dati futuri, possono essere archiviati nel set esistente di partizioni fisiche, senza richiedere al servizio di aggiungere immediatamente altre partizioni fisiche.

Al contrario, se si ritiene che l'archiviazione non aumenterà significativamente dopo la migrazione, è possibile scegliere di impostare il valore più alto, ad esempio 45 GB. Ciò significa che ogni partizione sarà piena circa il 90% (45 GB su 50 GB). Ciò riduce al minimo il numero di partizioni fisiche distribuite tra i dati, il che significa che ogni partizione fisica può ottenere una frazione maggiore del totale delle UR/sec di cui è stato effettuato il provisioning.

Passaggio 3: Calcolare il numero di UR/sec da iniziare con per tutte le partizioni

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition.

Si inizierà con un esempio con un numero arbitrario di UR/sec di destinazione per partizione fisica.

• Initial throughput per physical partition = 10.000 UR/sec per partizione fisica quando si usano database con scalabilità automatica o velocità effettiva condivisa
• Initial throughput per physical partition = 6000 UR/sec per partizione fisica quando si usa la velocità effettiva manuale

Esempio

Si supponga di avere 1 TB (1000 GB) di dati che si prevede di inserire e si vuole usare la velocità effettiva manuale. Ogni partizione fisica in Azure Cosmos DB ha una capacità di 50 GB. Si supponga di voler comprimere le partizioni in modo che siano complete dell'80% (40 GB), lasciandoci spazio per la crescita futura.

Ciò significa che per 1 TB di dati saranno necessari 1000 GB / 40 GB = 25 partizioni fisiche. Per assicurarsi di ottenere 25 partizioni fisiche, se si usa la velocità effettiva manuale, si effettua prima il provisioning di 25 * 6000 UR/s = 150.000 UR/sec. Quindi, dopo aver creato il contenitore, per velocizzare l'inserimento, si aumentano le UR/sec a 250.000 UR/s prima dell'inizio dell'inserimento (si verificano immediatamente perché sono già presenti 25 partizioni fisiche). In questo modo ogni partizione può ottenere il massimo di 10.000 UR/sec.

Se si usa la velocità effettiva di scalabilità automatica o un database con velocità effettiva condivisa, per ottenere 25 partizioni fisiche, è necessario effettuare prima il provisioning di 25 * 10.000 UR/s = 250.000 UR/sec. Poiché le UR/sec più elevate possono essere supportate con 25 partizioni fisiche, non si aumentano ulteriormente le UR/s di cui è stato effettuato il provisioning prima dell'inserimento.

In teoria, con 250.000 UR/s e 1 TB di dati, se si presuppongono documenti da 1 KB e 10 UR necessarie per la scrittura, L'inserimento può essere completato teoricamente in: 1000 GB * (1.000.000 KB / 1 GB) * (1 documento / 1 kb) * (10 UR/documento) * (1 sec / 250.000 UR) * (1 ora / 3600 secondi) = 11,1 ore.

Questo calcolo è una stima presupponendo che il client che esegue l'inserimento possa saturare completamente la velocità effettiva e distribuire le scritture in tutte le partizioni fisiche. Come procedura consigliata, è consigliabile "riassegnare casualmente" i dati sul lato client. In questo modo, ogni secondo, il client scrive in molte partizioni logiche distinte (e quindi fisiche).

Una volta completata la migrazione, è possibile ridurre le UR/sec o abilitare la scalabilità automatica in base alle esigenze.

Passaggi successivi

• Monitorare il consumo di UR/sec normalizzato del database o del contenitore.
• Diagnosticare e risolvere i problemi relativi alle eccezioni di frequenza delle richieste troppo grandi (429).
• Abilitare la scalabilità automatica in un database o in un contenitore.