Consideraciones y pasos previos a la migración
Hay varias maneras de migrar una base de datos y una aplicación de MongoDB existentes a una cuenta de Azure CosmoDB API para MongoDB. Para garantizar un proceso de migración sin problemas, debemos realizar un planeamiento inicial y tomar decisiones sobre el proceso de migración antes de mover los datos. En esta unidad, veremos algunos de esos pasos previos a la migración más detalladamente.
Información general sobre la migración previa
El proceso inicial de toma de decisiones se denominará migración previa.
Los objetivos de esta migración previa son:
- Asegurarse de configurar Azure Cosmos DB para cumplir los requisitos de la aplicación.
- Planificar cómo ejecutar la migración.
Nuestra migración previa se divide en los cuatro pasos o fases siguientes.
- Descubra los recursos de MongoDB existentes y cree una hoja de cálculo del patrimonio de datos para supervisarlos.
- Evalúe la preparación de los recursos de MongoDB existentes para la migración de datos.
- Asigne los recursos de MongoDB existentes a nuevos recursos de Azure Cosmos DB
- Planee la logística del proceso de migración de un extremo a otro antes de iniciar la migración de datos a escala completa.
Seguir estos cuatro pasos garantizarán una migración correcta. A continuación, veamos estas fases con más detalle.
Nota
Database Migration Assistant (DMA) ayuda con las fases de detección y evaluación del planeamiento.
Detección previa a la migración
El primer paso será crear una hoja de cálculo de migración del patrimonio de datos. Esta hoja de cálculo:
- Contendrá una lista completa de los recursos existentes (bases de datos o colecciones) en el patrimonio de datos de MongoDB.
- Le ayudará a planear la migración de un extremo a otro.
- Debe usarse durante todo el proceso de migración como documento de seguimiento.
Aunque puede realizar una detección manual, en esta unidad se recomienda usar Database Migration Assistant (DMA) para ayudarle con la detección. Esta herramienta es fácil de usar y hará la mayor parte del trabajo por usted.
DMA creará la hoja de migración del patrimonio de datos mediante programación. Usaremos Azure Data Studio para instalar y usar fácilmente la herramienta DMA. Puede ejecutarlo desde cualquier máquina que tenga acceso al entorno de MongoDB de origen.
DMA generará los siguientes archivos que puede usar como hojas de cálculo de migración del patrimonio de datos.
- workload_database_details.csv : proporciona la vista de nivel de base de datos del origen.
- workload_collection_details.csv : muestra una vista de nivel de colección del origen.
Las hojas de cálculo deberán verse como las siguientes.
Evaluación previa a la migración
Una vez que haya completado la detección, debe averiguar qué características del entorno actual de MongoDB podrían no ser compatibles con la versión actual de MongoDB que admite Azure Cosmos DB for MongoDB. También debe tener en cuenta los límites y cuotas de Azure Cosmos DB. Una vez que realice esta evaluación, podrá abordar esos resultados según sea necesario durante el resto del planeamiento de la migración.
Una vez más, usaremos DMA para ayudarnos a recopilar los datos necesarios de esta fase. DMA se ejecutará en los recursos de MongoDB de origen y enumerará los cambios necesarios y recomendados para continuar con la migración. Estos datos se escribirán en el archivo assessment_result.csv.
Asignación previa a la migración
La detección y la evaluación se centraban en nuestro MongoDB de origen, ahora es el momento de pasar a Azure Cosmos DB en las siguientes dos fases. Comencemos con el planeamiento de capacidad.
Planificación de capacidad
Podemos realizar el planeamiento de capacidad de dos maneras.
Convertir núcleos virtuales en RU. - Si la única información que conocemos es el número de servidores o el número de núcleos virtuales en nuestro entorno actual de MongoDB, podemos convertir esos núcleos virtuales en RU. En la unidad anterior, Convertir núcleos virtuales en RU, se ha detallado cómo calcular unidades de solicitud mediante núcleos virtuales o vCPU.
Uso de Azure Cosmos DB Capacity Planner. Si conocemos un estimado de la cantidad de datos que tenemos y el número de operaciones CRUD que hacemos por segundo, podríamos usar la calculadora de capacidad para calcular el número de RU/s que necesitaremos. En el módulo anterior, analizamos este tema en detalle en la unidad [Estimación de capacidad mediante la calculadora de capacidad de Azure Cosmos DB][/training/modules/get-started-mongodb-api-azure-cosmos-db/5-capacity-estimation-use-calculator].
Nota
También puede usar la calculadora de capacidad de Azure Cosmos DB para calcular el costo de propiedad del nuevo recurso de Azure Cosmos DB.
Estimación del rendimiento
Como hemos descrito en la sección de Planeamiento de capacidad, podemos usar la calculadora de capacidad de Azure Cosmos DB para calcular las RU/s que necesitaremos, o podemos calcular las RU mediante la conversión de los núcleos virtuales en RU antes de la migración. Pero una vez que los datos están en Azure Cosmos DB, ¿cómo podemos determinar el costo real de nuestras consultas?
Una vez que nuestros datos están en una colección de Azure Cosmos DB, podemos comprender mejor el costo de nuestras consultas mediante el shell de MongoDB y el uso del comando getLastRequestStastistics para obtener el cargo de solicitud. Primero ejecutaremos nuestra consulta en el shell de MongoDB e, inmediatamente después, ejecutaremos el siguiente comando para obtener esas estadísticas de RU.
db.runCommand({getLastRequestStatistics: 1})
Otra forma de revisar el rendimiento de nuestras consultas es a través del Azure Monitor. Este tema se tratará con más detalle en el siguiente módulo Replicación y supervisión de una cuenta de Azure Cosmos DB for MongoDB.
Planeación del patrimonio de datos de Azure Cosmos DB
Es momento de usar las hojas de cálculo de detalles de carga de trabajo que creamos con DMA. Ahora, es necesario asignar cada recurso de MongoDB a un nuevo recurso de Azure Cosmos DB. Para hacerlo, siga los siguientes pasos:
Asigne cada base de datos de MongoDB a una base de datos de Azure Cosmos DB.
Asigne cada colección de MongoDB a una colección de Azure Cosmos DB.
Si es posible, mantenga los mismos nombres de recursos.
Determine si va a usar colecciones particionadas o sin particiones en Cosmos DB. El particionamiento contribuye a escalado horizontal, lo que es fundamental para el rendimiento de muchas cargas de trabajo. Recuerde que las colecciones sin particiones tienen un límite de 20 GB por colección.
Si usa colecciones particionadas, Azure Cosmos DB se centra en el rendimiento. Esto se logra mediante el uso de la clave de partición correcta, que se beneficiará más de las cargas de trabajo. Dicho esto, es posible que nuestra clave de partición de Azure Cosmos DB no sea la misma clave de partición de colección que usó en el entorno de MongoDB.
Nota
La clave de partición es la opción más importante para optimizar la escalabilidad y el rendimiento de Azure Cosmos DB, y la segunda más importante es el modelado de datos. Ambas opciones son inmutables y no se pueden cambiar una vez establecidas; por lo tanto, es muy importante optimizarlas en la fase de planeamiento.
Azure Cosmos DB tiene dos tipos de colección propios: rendimiento compartido y dedicado.
Nota
El rendimiento compartido frente al rendimiento dedicado es otra decisión crítica e inmutable que es fundamental tomar en la fase de planeamiento.
Nota
Las colecciones que requieren un rendimiento predecible deben tener un rendimiento dedicado en lugar de un rendimiento compartido. Las colecciones que usan el rendimiento compartido deben tener aproximadamente las mismas necesidades de solicitud y almacenamiento.
Algunas decisiones son permanentes
Decisiones inmutables. Es momento de tomar varias decisiones de diseño, no solo porque es necesario planear correctamente la migración, sino también porque no podremos modificar algunas de esas configuraciones una vez se creen los recursos. Para poder tomar de manera correcta las decisiones que no se puede modificar:
Elija la mejor clave de partición : una vez que se crea la colección, no es posible cambiar la clave de partición, por lo que es necesario elegir la correcta desde el principio. Una vez que elijamos la clave de partición de la colección, Azure Cosmos DB administrará el crecimiento horizontal de la colección. En el módulo anterior, profundizamos en este tema en la unidad Modelos y claves de partición. Si desea leer más sobre este tema, consulte los artículos Creación de particiones y escalado horizontal en Azure Cosmos DB y Elección de una clave de partición. Recuerde que el particionamiento también se conoce como creación de particiones.
Elija el modelo adecuado : analizamos este tema con más detalle en la unidad Modelos y claves de partición del módulo anterior. Consulte el artículo Modelado de datos en Azure Cosmos DB para obtener más información.
Elija entre el rendimiento dedicado y el compartido para cada recurso que migrará : para obtener más información, consulte el artículo Optimización del costo de rendimiento aprovisionado en Azure Cosmos DB.
Sugerencia
Si desea revisar un ejemplo real de cómo modelar y particionar los datos, consulte el artículo Procedimientos para modelar y crear particiones de datos en Azure Cosmos DB mediante un ejemplo real.
Planeamiento de la logística previa a la migración
Una vez se han recopilado, asignado y modelado los recursos de Azure Cosmos DB, puede planear la ejecución de la migración en sí.
Logística de ejecución
Es necesario responder algunas preguntas.
- ¿Quién hará la migración? - Dependiendo del tamaño de la migración, deberá designar a una o a varias personas para no solo realizar la migración de los recursos, sino también para supervisar el progreso de la migración de cada recurso que va a migrar.
- ¿Qué herramientas se usarán para realizar la migración? - Se pueden usar muchas herramientas para realizar la migración en línea o sin conexión. Pueden usarse desde herramientas nativas de MongoDB hasta servicios de Azure, como Azure Data Migration Service (DMS), Azure Data Factory (ADF) o Azure Databricks y Spark. En las dos secciones siguientes, veremos con más detalle qué herramientas pueden usarse para migrar una base de datos de MongoDB a Azure Cosmos DB.
- ¿En qué orden se deben migrar los recursos? - Priorizar lo que se va a migrar primero le permitirá realizar la migración según lo previsto. Un procedimiento recomendado es priorizar la migración de los recursos que necesitan más tiempo para trasladarse. La migración de estos recursos en primer lugar aportará el mayor progreso hacia la finalización. Como, por lo general, estos son los recursos más grandes y con la mayor cantidad de datos, migrarlos primero puede ayudar a identificar cualquier problema de migración más rápido.
- ¿Cómo supervisará el proceso de migración? - Debe trabajar el proceso de supervisión con su equipo para que tenga una visión completa de cómo van las migraciones de alta prioridad.
Escenarios de migración admitidos
La mejor opción de la herramienta de migración de MongoDB depende del escenario de migración.
A continuación se muestran las herramientas compatibles para cada escenario de migración:
| Source | Destination | Recomendaciones de proceso |
|---|---|---|
| Offline • Clúster local de MongoDB • Clúster de máquinas virtuales IaaS de MongoDB • Clúster de MongoDB Atlas |
Mongo API de Azure Cosmos DB | • <10 GB de datos: herramientas nativas de MongoDB - < 1 TB de datos: Azure DMS • > Datos de 1 TB: Spark |
| En línea • Clúster local de MongoDB • Clúster de máquinas virtuales IaaS de MongoDB • Clúster de MongoDB Atlas |
Mongo API de Azure Cosmos DB | - < 1 TB de datos: Azure DMS • > Datos de 1 TB: Spark + Mongo ChangeStream |
| • Necesidad de cambiar el esquema durante la migración • Necesitan más flexibilidad que las herramientas mencionadas anteriormente |
Mongo API de Azure Cosmos DB | • ADF es más flexible que DMS, pues admite modificaciones de esquema durante la migración, así como la mayoría de las combinaciones de origen y destino. • DMS será mejor en términos de escala, por ejemplo, para migraciones más rápidas. |
| Archivo JSON | Mongo API de Azure Cosmos DB | Herramientas nativas de MongoDB en específico mongoimport. |
| Archivo CSV | Mongo API de Azure Cosmos DB | Herramientas nativas de MongoDB en específico mongoimport. |
| Archivo BSON | Mongo API de Azure Cosmos DB | Herramientas nativas de MongoDB en específico mongorestore. |
Dado que va realizar la migración desde una versión determinada de MongoDB, a continuación se muestran las herramientas compatibles:
| Versión de origen de Mongo | Versión de destino de Azure Cosmos DB Mongo API | Herramientas admitidas | Herramientas no admitidas |
|---|---|---|---|
| < 2.x, > 4.0 | 3.2, 3.6, 4.0 | Herramientas nativas de MongoDB, Spark | DMS, ADF |
| 3.2, 3.6. 4.0 | 3.2, 3.6, 4.0 | Herramientas nativas de MongoDB, DMF, ADF, Spark | None |
Después de la migración
En la fase anterior a la migración, dedique suficiente tiempo a detallar los pasos posteriores a la migración.
Pasos a seguir:
Transición de la aplicación : debe redirigir la aplicación al entorno de Azure Cosmos DB.
Planificación de las configuraciones posteriores a la migración : se deben planear temas como la indexación, la distribución global y la coherencia. Tenga en cuenta que las configuraciones normalmente se puede cambiar sobre la marcha y lo más probable es que cambien durante la vida útil de las colecciones, pero debe planear dónde quedarán esas configuraciones tras la migración.
Sugerencia
Para obtener más información sobre las migraciones posteriores, consulte los Pasos de optimización posteriores a la migración cuando se usa la API de Azure Cosmos DB para MongoDB.
La migración de una base de datos de MongoDB no es una operación de un solo clic. Debe dedicarle tiempo a la planificación de la migración. En los siguientes dos capítulos, analizaremos en detalle el paso de la migración propiamente dicha.