Passaggi di pre-migrazione per le migrazioni dei dati da MongoDB ad Azure Cosmos DB for MongoDB

Articolo
08/15/2024

SI APPLICA A: MongoDB

Importante

Prima di eseguire i passaggi di pre-migrazione, leggere questa guida completa.

Questa guida alla pre-migrazione di MongoDB fa parte della serie sulla migrazione di MongoDB. I passaggi critici per la migrazione di MongoDB sono pre-migrazione, migrazione e post-migrazione, come illustrato in questa guida.

Diagramma dei passaggi di migrazione da pre a post-migrazione.

Panoramica della pre-migrazione

Prima di spostare effettivamente i dati, è fondamentale eseguire una pianificazione iniziale e prendere decisioni riguardo alla migrazione. Il processo decisionale iniziale è definito "pre-migrazione".

Gli obiettivi da prefiggersi nella fase di pre-migrazione sono i seguenti:

Assicurarsi di configurare Azure Cosmos DB per soddisfare i requisiti dell'applicazione.
Pianificare l'esecuzione della migrazione.

Per eseguire una pre-migrazione completa, eseguire questi passaggi

Individuare le risorse di MongoDB esistenti e valutare l'idoneità delle risorse di MongoDB esistenti per la migrazione dei dati
Eseguire il mapping delle risorse di MongoDB esistenti alle nuove risorse di Azure Cosmos DB
Pianificare la logistica del processo di migrazione end-to-end prima di avviare la migrazione completa dei dati

Eseguire quindi la migrazione in base al piano di pre-migrazione.

Eseguire infine i passaggi critici di cutover e ottimizzazione nella fase di post-migrazione.

Tutti i passaggi precedenti sono fondamentali per garantire una corretta migrazione.

Quando si pianifica una migrazione, è consigliabile pianificare il più possibile a livello di risorsa.

Valutazione di pre-migrazione

Il primo passaggio di pre-migrazione consiste nell'individuare le risorse di MongoDB esistenti e nel valutare l'idoneità delle risorse per la migrazione.

L'individuazione comporta la creazione di un elenco completo delle risorse esistenti (database o raccolte) nel patrimonio di dati MongoDB.

La valutazione permette di comprendere se si stanno usando le funzionalità e la sintassi supportate. Consente inoltre di accertarsi di aderire ai limiti e alle quote. L'obiettivo di questa fase è creare un elenco di eventuali incompatibilità e avvisi. Dopo aver ottenuto i risultati della valutazione, è possibile provare a risolvere i risultati nella parte restante della pianificazione della migrazione.

Esistono tre modi per completare la valutazione nella fase di pre-migrazione ed è consigliabile usare l'estensione Migrazione di Azure Cosmos DB per MongoDB.

Estensione Migrazione di Azure Cosmos DB per MongoDB

L'estensione Migrazione di Azure Cosmos DB per MongoDB in Azure Data Studio consente di valutare un carico di lavoro di MongoDB per la migrazione ad Azure Cosmos DB for MongoDB. È possibile usare questa per eseguire una valutazione end-to-end sul carico di lavoro e scoprire le azioni che potrebbero essere necessarie per eseguire facilmente la migrazione dei carichi di lavoro ad Azure Cosmos DB. Durante la valutazione di un endpoint MongoDB, l'estensione segnala tutte le risorse individuate.

Nota

È consigliabile esaminare in dettaglio le funzionalità e la sintassi supportate e i limiti e le quote di Azure Cosmos DB, nonché eseguire un modello di verifica prima della migrazione effettiva.

Individuazione manuale (legacy)

In alternativa, è possibile creare un foglio di calcolo per la migrazione del patrimonio di dati. Lo scopo di questo foglio di calcolo è quello di migliorare la produttività e di facilitare la pianificazione della migrazione end-to-end. Il foglio può inoltre essere usato come documento di verifica durante l'intero processo di migrazione.

Nel foglio è contenuto un elenco completo delle risorse esistenti (database o raccolte) nel patrimonio di dati MongoDB.
Il foglio di calcolo deve essere strutturato come record delle risorse del patrimonio di dati, sotto forma di elenco.
Ogni riga corrisponde a una risorsa (database o raccolta).
Ogni colonna corrisponde a una proprietà della risorsa. Iniziare almeno con nome e dimensione dei dati (GB) come colonne.
Man mano che si procede in questa guida, si userà questo foglio di calcolo come documento di verifica per la pianificazione della migrazione end-to-end, aggiungendo colonne in base alle esigenze.

Ecco alcuni strumenti che è possibile usare per l'individuazione delle risorse:

Esaminare il foglio di calcolo e verificare ogni raccolta in dettaglio in base alle funzionalità e alla sintassi supportate e ai limiti e alle quote di Azure Cosmos DB.

Utilità Database Migration Assistant (legacy)

Nota

Database Migration Assistant è un'utilità legacy pensata per facilitare i passaggi di pre-migrazione. Per tutti i passaggi di pre-migrazione è consigliabile usare l'estensione Migrazione di Azure Cosmos DB per MongoDB.

È possibile usare l'utilità Database Migration Assistant (DMA) per facilitare l'esecuzione dei passaggi di pre-migrazione.

Mapping di pre-migrazione

Dopo aver completato i passaggi di individuazione e valutazione, il lato MongoDB dell'equazione è completato. È ora possibile passare alla pianificazione del lato Azure Cosmos DB. Come pianificare la configurazione delle risorse di produzione di Azure Cosmos DB? Eseguire la pianificazione a livello di singola risorsa, ovvero aggiungere le colonne seguenti al foglio di calcolo della pianificazione:

Mapping di Azure Cosmos DB
Chiave partizione
Modello di dati
Velocità effettiva dedicata e condivisa

Nelle sezioni seguenti sono riportati altri dettagli.

Pianificazione capacità

Si sta tentando di pianificare la capacità per una migrazione ad Azure Cosmos DB?

Se si conosce solo il numero di vCore e server nel cluster di database esistente, leggere le informazioni sulla stima delle unità richieste con vCore o vCPU
Se si conosce la frequenza delle richieste tipiche per il carico di lavoro corrente del database, leggere le informazioni sulla stima delle unità richieste con lo strumento di pianificazione della capacità di Azure Cosmos DB

Considerazioni sull'uso dell'API di Azure Cosmos DB per MongoDB

Prima di pianificare il patrimonio di dati di Azure Cosmos DB, assicurarsi di comprendere i concetti di Azure Cosmos DB seguenti:

Modello di capacità: la capacità del database in Azure Cosmos DB si basa su un modello basato sulla velocità effettiva. Questo modello è basato sulle unità richiesta al secondo, ovvero le unità che rappresentano il numero di operazioni di database che possono essere eseguite su una raccolta al secondo. Questa capacità può essere allocata a livello di database o di raccolta ed è possibile effettuarne il provisioning in un modello di allocazione o tramite la velocità effettiva di provisioning a scalabilità automatica.
Unità richiesta: a ogni operazione di database è associato un costo di unità richiesta in Azure Cosmos DB. Quando viene eseguita l'operazione, il costo viene sottratto dal livello delle unità richiesta disponibili in un determinato secondo. Se per una richiesta sono necessarie più UR rispetto alle UR/sec attualmente allocate, è possibile risolvere il problema scegliendo tra due opzioni: aumentare il numero di UR o attendere che abbia inizio il secondo successivo per ripetere l'operazione.
Capacità elastica: la capacità di una raccolta o un database può cambiare in qualsiasi momento. Questa flessibilità consente al database di adattarsi in modo elastico ai requisiti di velocità effettiva del carico di lavoro.
Partizionamento orizzontale automatico: Azure Cosmos DB offre un sistema di partizionamento automatico che richiede solo una partizione (o una chiave di partizione). Il meccanismo di partizionamento automatico viene condiviso tra tutte le API di Azure Cosmos DB e consente la continuità dei dati e la scalabilità della velocità effettiva tramite distribuzione orizzontale.

Pianificare il patrimonio dei dati di Azure Cosmos DB

Determinare le risorse di Azure Cosmos DB da creare. Questo processo richiede l'esame dettagliato del foglio di calcolo per la migrazione del patrimonio di dati e il mapping di ogni risorsa di MongoDB esistente a una nuova risorsa di Azure Cosmos DB.

Prevedere che ogni database di MongoDB diventi un database di Azure Cosmos DB.
Prevedere che ogni raccolta di MongoDB diventi una raccolta di Azure Cosmos DB.
Scegliere una convenzione di denominazione per le risorse di Azure Cosmos DB. La scelta di mantenere gli stessi nomi di risorse è in genere una soluzione ottimale, a meno che non siano presenti modifiche nella struttura dei database e delle raccolte.
Determinare se si usano raccolte partizionate o non partizionate in Azure Cosmos DB. Il limite delle raccolte non partizionate è 20 GB. Il partizionamento orizzontale, d'altra parte, consente di ottenere una scalabilità orizzontale fondamentale per le prestazioni di molti carichi di lavoro.
Se si usano raccolte partizionate, non presupporre che la chiave di partizione della raccolta di MongoDB diventi la chiave di partizione del contenitore di Azure Cosmos DB. Non presupporre che la struttura dei documenti del modello di dati MongoDB esistente debba corrispondere al modello usato in Azure Cosmos DB.
- La chiave di partizione è la singola impostazione più importante per ottimizzare la scalabilità e le prestazioni di Azure Cosmos DB e la modellazione dei dati è il secondo fattore più importante. Entrambe queste impostazioni non sono modificabili e non possono essere modificate una volta impostate. È quindi estremamente importante ottimizzarle nella fase di pianificazione. Per altre informazioni, seguire le indicazioni riportate nella sezione Decisioni non modificabili.
Azure Cosmos DB non riconosce alcuni tipi di raccolte di MongoDB, ad esempio le raccolte limitate. Per queste risorse, è sufficiente creare raccolte normali di Azure Cosmos DB.
Azure Cosmos DB include due tipi di raccolta specifici: con velocità effettiva condivisa e dedicata. La velocità effettiva condivisa e dedicata è un'altra decisione critica e non modificabile che è fondamentale prendere nella fase di pianificazione. Per altre informazioni, seguire le indicazioni riportate nella sezione Decisioni non modificabili.

Decisioni non modificabili

Le scelte di configurazione di Azure Cosmos DB elencate di seguito non possono essere modificate o annullate dopo che una risorsa di Azure Cosmos DB è stata creata. È quindi importante definire queste scelte di configurazione direttamente durante la pianificazione della pre-migrazione, prima di avviare le migrazioni:

Vedere Partizionamento e scalabilità orizzontale in Azure Cosmos DB per scegliere la chiave di partizione ottimale. Il partizionamento, o meglio il partizionamento orizzontale, è un punto essenziale di cui tenere conto prima della migrazione dei dati. Azure Cosmos DB usa il partizionamento completamente gestito per aumentare la capacità di un database in modo da soddisfare i requisiti di archiviazione e di velocità effettiva. Per questa funzionalità non è necessario l'hosting o la configurazione di server di routing.
- In modo analogo, la funzionalità di partizionamento aggiunge automaticamente capacità e ribilancia i dati di conseguenza. Per altre informazioni sulla scelta della chiave di partizione corretta per i dati, vedere Scegliere una chiave di partizione.
Seguire le indicazioni in Modellazione dei dati in Azure Cosmos DB per scegliere un modello di dati.
Seguire le indicazioni in Ottimizzare il costo della velocità effettiva con provisioning in Azure Cosmos DB per scegliere tra velocità effettiva dedicata e condivisa per ogni risorsa di cui si esegue la migrazione.
Come modellare e partizionare i dati in Azure Cosmos DB usando un esempio reale offre un esempio reale di partizionamento orizzontale e modellazione dei dati per facilitare il processo decisionale.

Costo di proprietà

Stimare il costo di proprietà delle nuove risorse di Azure Cosmos DB usando il calcolatore della capacità di Azure Cosmos DB.

Stima della velocità effettiva

In Azure Cosmos DB il provisioning della velocità effettiva viene eseguito in anticipo e misurato in unità richiesta (UR) al secondo. Diversamente dalle macchine virtuali o dai server locali, le UR sono facilmente scalabili in qualsiasi momento. È possibile modificare immediatamente il numero di UR sottoposte a provisioning. Per altre informazioni, vedere Unità richiesta in Azure Cosmos DB.
È possibile usare il calcolatore della capacità di Azure Cosmos DB per determinare il numero di unità richiesta da usare. Questo numero si basa sulla configurazione dell'account del database, sulla quantità di dati, sulla dimensione del documento e sulle operazioni di lettura e scrittura necessarie al secondo.
Di seguito sono elencati i fattori chiave che influiscono sul numero di UR richiesto:
- Dimensione del documento: con l'aumentare delle dimensioni di un elemento/documento, aumenta anche il numero di UR usate per leggere o scrivere l'elemento/documento.
- Numero di proprietà del documento: il numero di UR usate per creare o aggiornare un documento è correlato al numero, alla complessità e alla lunghezza delle relative proprietà. È possibile ridurre l'utilizzo di unità richiesta per operazioni di scrittura limitando il numero di proprietà indicizzate.
- Modelli di query: la complessità di una query influisce sul numero di unità richiesta utilizzate da una query.
Il modo migliore per determinare il costo delle query è quello di usare i dati di esempio in Azure Cosmos DB ed eseguire query di esempio da MongoDB Shell usando il comando getLastRequestStastistics per ottenere l'addebito della richiesta, che restituirà il numero di UR utilizzate:
```
db.runCommand({getLastRequestStatistics: 1})
```
*Con questo comando viene restituito un documento JSON simile all'esempio seguente:
```
{
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}
```
È anche possibile usare le impostazioni di diagnostica per conoscere la frequenza e i modelli delle query eseguite in Azure Cosmos DB. I risultati dei log di diagnostica possono essere inviati a un account di archiviazione, un'istanza di Hub eventi o ad Azure Log Analytics.

Pianificazione della logistica pre-migrazione

Ora che si dispone di una visualizzazione del patrimonio di dati esistente e di un modello per il nuovo patrimonio di dati di Azure Cosmos DB, è possibile pianificare come eseguire il processo di migrazione end-to-end. Ancora una volta, eseguire la pianificazione a livello di singola risorsa, aggiungendo colonne al foglio di calcolo per acquisire le dimensioni logistiche incluse in questa sezione.

Logistica dell'esecuzione

Assegnare i compiti per la migrazione di ogni risorsa esistente da MongoDB ad Azure Cosmos DB. La modalità di assegnazione alle risorse del team per portare a termine la migrazione dipende dalle esigenze dell'organizzazione. Per le migrazioni di piccole dimensioni, è possibile assegnare l'intera migrazione a un unico team e monitorare il suo stato di avanzamento. Per le migrazioni di dimensioni maggiori, è possibile assegnare ai membri del team il compito di migrazione e monitoraggio in base a singole risorse.

Dopo aver assegnato i compiti per la migrazione delle risorse, è ora necessario scegliere gli strumenti appropriati per la migrazione. Per le migrazioni di piccole dimensioni, è possibile usare un unico strumento di migrazione, ad esempio uno strumento nativo di MongoDB o Servizio Migrazione del database di Azure, per eseguire la migrazione di tutte le risorse in una sola volta. Per le migrazioni di dimensioni maggiori o con requisiti speciali, è consigliabile scegliere strumenti di migrazione dedicati per singole risorse.

Prima di pianificare gli strumenti di migrazione da usare, è consigliabile acquisire familiarità con le opzioni disponibili. Il servizio Migrazione del database di Azure per l'API di Azure Cosmos DB per MongoDB offre un meccanismo che semplifica la migrazione dei dati mettendo a disposizione una piattaforma di hosting completamente gestita, opzioni di monitoraggio della migrazione e gestione automatica delle limitazioni. Ecco un elenco completo di opzioni:

Tipo di migrazione	Soluzione	Considerazioni
Online	Servizio Migrazione del database di Azure	• Usa la libreria di esecuzione bulk per Azure Cosmos DB • È adatto per set di dati di grandi dimensioni ed è capace di replicare modifiche in tempo reale • Funziona solo con altre origini MongoDB
Fuori rete	Servizio Migrazione del database di Azure	• Usa la libreria di esecuzione bulk per Azure Cosmos DB • È adatto per set di dati di grandi dimensioni ed è capace di replicare modifiche in tempo reale • Funziona solo con altre origini MongoDB
Offline	Azure Data Factory	• Usa la libreria di esecuzione bulk per Azure Cosmos DB • È adatto per set di dati di grandi dimensioni • È facile da configurare e supporta più origini • La mancanza di checkpoint significa che qualsiasi problema durante la migrazione richiede un riavvio dell'intero processo di migrazione • La mancanza di una coda di messaggi non recapitabili significa che alcuni file non corretti potrebbero arrestare l'intero processo di migrazione • Richiede codice personalizzato per aumentare la velocità effettiva di lettura per determinate origini dati
Fuori rete	Strumenti Mongo esistenti (mongodump, mongorestore, Studio3T)	• È facile da configurare e integrare • Richiede una gestione personalizzata per le limitazioni
Offline/online	Azure Databricks e Spark	• Controllo completo della velocità di migrazione e della trasformazione dei dati • Richiede codice personalizzato

Se la risorsa può tollerare una migrazione offline, usare questo diagramma per scegliere lo strumento di migrazione appropriato:
Se la risorsa richiede una migrazione online, usare questo diagramma per scegliere lo strumento di migrazione appropriato:
Guardare un video con una panoramica e una demo delle soluzioni di migrazione.

Dopo aver scelto gli strumenti di migrazione per ogni risorsa, il passaggio successivo consiste nel classificare in ordine di priorità le risorse di cui si eseguirà la migrazione. Una buona definizione delle priorità può aiutare a completare la migrazione nei tempi previsti. Una buona pratica è quella di dare priorità alla migrazione delle risorse che richiedono più tempo per essere spostate. Eseguendo prima la migrazione di queste risorse, si possono compiere più passi avanti verso il completamento. Inoltre, poiché queste migrazioni dispendiose in termini di tempo comportano in genere più dati, richiedono un maggiore utilizzo di risorse per lo strumento di migrazione e quindi hanno maggiori probabilità di evidenziare tempestivamente eventuali problemi con la pipeline di migrazione. Questa procedura riduce al minimo la probabilità che la pianificazione slitti a causa di problemi con la pipeline di migrazione.
Pianificare il monitoraggio dello stato di avanzamento della migrazione dopo l'avvio. Se si coordina il lavoro di migrazione dei dati tra i membri di un team, pianificare anche una sincronizzazione del team con cadenza regolare, in modo da avere una visione completa del modo in cui procedono le migrazioni ad alta priorità.

Scenari di migrazione supportati

La scelta dello strumento di migrazione MongoDB migliore dipende dallo scenario di migrazione.

Tipi di migrazioni

Ecco un elenco di strumenti compatibili per ogni scenario di migrazione:

Source (Sorgente)	Destination	Consigli per il processo
• Cluster MongoDB locale • Cluster MongoDB su macchina virtuale IaaS • Cluster MongoDB Atlas: offline	API Mongo di Azure Cosmos DB	• <10 GB di dati: strumenti nativi di MongoDB • < 1 TB di dati: Servizio Migrazione del database di Azure • > 1 TB di dati: Spark
• Cluster MongoDB locale • Cluster MongoDB su macchina virtuale IaaS • Cluster MongoDB Atlas: online	API Mongo di Azure Cosmos DB	• < 1 TB di dati: Servizio Migrazione del database di Azure • >1 TB di dati: Spark + Mongo Changestream
• Necessità di modificare lo schema durante la migrazione Bisogno di maggiore flessibilità rispetto agli strumenti menzionati in precedenza	API Mongo di Azure Cosmos DB	• Azure Data Factory è più flessibile rispetto a Servizio Migrazione del database, supporta le modifiche dello schema durante la migrazione e anche la maggior parte delle combinazioni origine/destinazione • Servizio Migrazione del database è migliore in termini di scalabilità (ad esempio, consente una migrazione più veloce)
• File JSON	API Mongo di Azure Cosmos DB	• Strumenti nativi di MongoDB, in particolare mongoimport
• File CSV	API Mongo di Azure Cosmos DB	• Strumenti nativi di MongoDB, in particolare mongoimport
• File BSON	API Mongo di Azure Cosmos DB	• Strumenti nativi di MongoDB, in particolare mongorestore

Supporto degli strumenti per le versioni di MongoDB

Dato che si sta eseguendo la migrazione da una versione specifica di MongoDB, di seguito sono riportati gli strumenti supportati per ogni versione:

Versione di origine di MongoDB	Versione di destinazione di Azure Cosmos DB for MongoDB	Strumenti supportati	Strumenti non supportati
<2.x, >4.0	3.2, 3.6, 4.0	Strumenti nativi MongoDB, Spark	Servizio Migrazione del database, Azure Data Factory
3.2, 3.6, 4.0	3.2, 3.6, 4.0	Strumenti nativi di MongoDB, Servizio Migrazione del database di Azure, Azure Data Factory, Spark	None

Dopo la migrazione

Nella fase di pre-migrazione dedicare del tempo per pianificare i passaggi da eseguire per la migrazione e l'ottimizzazione delle app dopo la migrazione.

Nella fase di post-migrazione si esegue un cutover dell'applicazione per usare Azure Cosmos DB in sostituzione del patrimonio di dati MongoDB esistente.
Compiere il massimo sforzo per pianificare l'indicizzazione, la distribuzione globale, la coerenza e altre proprietà modificabili di Azure Cosmos DB a livello di singola risorsa. Tuttavia, queste impostazioni di configurazione di Azure Cosmos DB possono essere modificate in un secondo momento, quindi si dovrà prevedere di apportarvi modifiche in un secondo momento. Queste configurazioni modificabili vengono applicate dopo la migrazione.
Per una guida alla post-migrazione, vedere Passaggi di ottimizzazione post-migrazione quando si usa l'API Azure Cosmos DB for MongoDB.

Passaggi successivi

Eseguire la migrazione ad Azure Cosmos DB for MongoDB

Condividi tramite