Convertire il numero di vCore o vCPU nel database non relazionale in UR di Azure Cosmos DB

SI APPLICA A: NoSQL

SI APPLICA A: MongoDB

Questo articolo illustra come stimare le unità richiesta (UR/s) di Azure Cosmos DB quando si valuta la migrazione dei dati, ma si conosce solo il numero totale di vCore o vCPU nei set di repliche di database esistenti. Quando si esegue la migrazione di uno o più set di repliche ad Azure Cosmos DB, ogni raccolta contenuta in tali set di repliche verrà archiviata come raccolta di Azure Cosmos DB costituita da un cluster partizionato con un fattore di replica di quattro volte. Per altre informazioni sull'architettura, vedere questa guida al partizionamento e al ridimensionamento. Le unità richiesta sono il modo in cui viene effettuato il provisioning della capacità di velocità effettiva in una raccolta. Per altre informazioni, leggere la guida alle unità richiesta e la guida al provisioning delle UR/sec. Quando si esegue la migrazione di una raccolta, Azure Cosmos DB effettua il provisioning di partizioni sufficienti per gestire le unità richiesta di cui è stato effettuato il provisioning e archiviare i dati. Di conseguenza, la stima delle UR/sec per le raccolte è un passaggio importante per definire la portata del patrimonio di dati di Azure Cosmos DB pianificato prima della migrazione. In base all'esperienza acquisita con migliaia di clienti, ecco una formula che consente di ottenere una stima iniziale approssimativa delle UR/sec dal numero di vCore o vCPU:

Provisioned RU/s = C*T/R

• T: numero totale di vCore e/o vCPU nei set di repliche contenenti i dati del database esistente.
• R: fattore di replica dei set di repliche contenenti i dati esistenti.
• C: provisioning di UR/sec consigliato per vCore o vCPU. Questo valore deriva dall'architettura di Azure Cosmos DB:
  • C = 600 UR/sec/vCore* per Azure Cosmos DB for NoSQL
  • C = 1.000 UR/sec/vCore* per Azure Cosmos DB for MongoDB v4.0
  • C stime per l'API for Cassandra, Gremlin o altre API non sono attualmente disponibili

I valori per C sono indicati sopra. T deve essere determinato esaminando il numero di vCore o vCPU in ogni set di repliche contenente i dati del database esistente e sommandoli per ottenere il totale. Se non è possibile stimare T, è consigliabile seguire la guida per la stima delle UR/sec usando Azure Cosmos DB Capacity Planner anziché questa guida. T non deve includere vCore o vCPU associati al server di routing o al cluster di configurazione del database esistente, se tali componenti sono presenti.

Per R, è consigliabile collegare il fattore di replica medio dei set di repliche del database. Se queste informazioni non sono disponibili, R=3 è una buona regola generale.

Le API di interoperabilità di Azure Cosmos DB vengono eseguite sulla base dell'API for NoSQL e implementano le proprie architetture univoche. Di conseguenza, Azure Cosmos DB for MongoDB v4.0 ha un C diverso rispetto all'API Azure Cosmos DB for NoSQL.

Esempio: stimare le UR/sec per la migrazione di set di repliche singoli

Si consideri un set di repliche singolo con un fattore di replica di R=3 basato su uno SKU server a quattro core. Risultato

• T = 12 vCore
• R = 3

Le unità richiesta consigliate per l'API Azure Cosmos DB for NoSQL sono quindi

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (12 vCores) / (3) = 2,400 RU/s

E le unità richiesta consigliate per l'API Azure Cosmos DB for MongoDB sono quindi

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (12 vCores) / (3) = 4,000 RU/s

Esempio: stimare le UR/sec per la migrazione di un cluster di set di repliche omogenei

Si consideri un cluster partizionato e replicato che comprende tre set di repliche ognuno con un fattore di replica di 3, in cui ogni server è uno SKU a quattro core. Risultato

• T = 36 vCore
• R = 3

Le unità richiesta consigliate per l'API Azure Cosmos DB for NoSQL sono quindi

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

E le unità richiesta consigliate per l'API Azure Cosmos DB for MongoDB sono quindi

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

Esempio: stimare le UR/sec per la migrazione di un cluster di set di repliche eterogenei

Si consideri un cluster partizionato e replicato che comprende tre set di repliche, in cui ogni server è basato su uno SKU a quattro core. I set di repliche sono "eterogenei" nel senso che ognuno ha un fattore di replica diverso: rispettivamente 3, 1 e 5. L'approccio consigliato consiste nell'usare il fattore di replica medio per il calcolo delle unità richiesta. Risultato

• T = 36 vCore
• R medio = (3+1+5)/3 = 3

Le unità richiesta consigliate per l'API Azure Cosmos DB for NoSQL sono quindi

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

E le unità richiesta consigliate per l'API Azure Cosmos DB for MongoDB sono quindi

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

Suggerimenti per ottenere la stima delle UR/sec più accurata

Migrazione da un database gestito nel cloud: se si usa un database gestito nel cloud, spesso sembra che il provisioning di questi servizi venga effettuato in unità di vCore o vCPU (in altre parole, T), ma in realtà il numero di core di cui si effettua il provisioning imposta il valore di vCore/replica o vCPU/replica (T/R) per un set di repliche con R nodi. Il numero effettivo di core è maggiore di R volte rispetto a quello di cui è stato effettuato il provisioning in modo esplicito. È consigliabile determinare se questa descrizione si applica al database gestito nel cloud corrente e, in tal caso, è necessario moltiplicare il numero nominale di vCore o vCPU di cui è stato effettuato il provisioning per R per ottenere una stima accurata di T.

vCore e vCPU: in questo articolo i termini "vCore" e "vCPU" sono considerati come sinonimi, di conseguenza C ha unità di UR/sec/vCore o UR/sec/vCPU, senza alcuna distinzione. Tuttavia, in pratica, questa semplificazione potrebbe non essere accurata in alcune situazioni. Questi termini possono avere significati diversi. Ad esempio, se le CPU fisiche supportano l'hyperthreading, è possibile che 2 vCPU = 1 vCore con hyperthreading o un altro valore. In generale, la relazione vCore/vCPU dipende dall'hardware ed è consigliabile analizzare qual è la relazione nell'hardware del cluster esistente e se il provisioning delle risorse di calcolo del cluster viene effettuato in termini di vCore o vCPU. Se vCPU e vCore hanno significati diversi nell'hardware in uso, è consigliabile considerare le stime precedenti di C come unità di UR/sec/vCoree, se necessario, convertire T da vCPU a vCore usando il fattore di conversione appropriato per l'hardware corrente.

Riepilogo

La stima di UR/sec da vCore o vCPU richiede la raccolta di informazioni sul numero totale di vCore/vCPU e sul fattore di replica dai set di repliche di database esistenti. È quindi possibile usare le relazioni note tra vCore/vCPU e velocità effettiva per stimare le unità richiesta (UR/sec) di Azure Cosmos DB. Individuare una stima delle unità richiesta è un passaggio importante per prevedere la portata del patrimonio di dati di Azure Cosmos DB dopo la migrazione.

La tabella seguente riepiloga la relazione tra vCore e vCPU per l'API Azure Cosmos DB for NoSQL e l'API for MongoDB v4.0:

vCore	UR/sec (API for NoSQL) (fattore di replica = 3)	UR/sec (API for MongoDB v4.0) (fattore di replica = 3)
3	600	1000
6	1200	2000
12	2400	4000
24	4800	8000
48	9600	16000
96	19200	32000
192	38400	64000
384	76800	128000

Passaggi successivi

• Informazioni sui prezzi di Azure Cosmos DB
• Informazioni su come pianificare e gestire i costi per Azure Cosmos DB
• Pianificare la migrazione ad Azure Cosmos DB for MongoDB. Questo documento include collegamenti a diversi strumenti di migrazione che è possibile usare al termine della pianificazione.