Pasos previos a la migración para migraciones de datos de MongoDB a Azure Cosmos DB para MongoDB

Artículo
04/23/2023

SE APLICA A: MongoDB

Importante

Lea toda esta guía antes de llevar a cabo los pasos previos a la migración.

Esta guía previa a la migración de MongoDB forma parte de la serie sobre la migración de MongoDB. Los pasos críticos de la migración de MongoDB son la migración previa, la migración y la migración posterior, como se muestra en esta guía.

Diagram of the migration steps from pre to post migration.

Información general sobre la migración previa

Es fundamental llevar a cabo por adelantado cierto planeamiento y toma de decisiones sobre la migración antes de mover realmente los datos. Este proceso inicial de toma de decisiones es la "migración previa".

Los objetivos de la migración previa son los siguientes:

Asegurarse de configurar Azure Cosmos DB para cumplir los requisitos de la aplicación.
Planificar cómo ejecutar la migración.

Siga estos pasos para realizar una migración previa exhaustiva.

Descubra los recursos de MongoDB existentes y 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.

A continuación, ejecute la migración de acuerdo con el plan previo a la migración.

Por último, realice los pasos críticos de migración total y optimización posteriores a la migración.

Todos los pasos anteriores son críticos para garantizar una migración correcta.

Al planear una migración, se recomienda que, siempre que sea posible, se planee por recurso.

Evaluación previa a la migración

El primer paso previo a la migración es detectar los recursos de MongoDB existentes y evaluar la preparación de los recursos para la migración.

La detección implica la creación de una lista completa de los recursos existentes (bases de datos o colecciones) en el patrimonio de datos de MongoDB.

La evaluación implica averiguar si usa las características y la sintaxis que se admiten. También incluye asegurarse de que cumple a los límites y cuotas. El objetivo de esta fase es crear una lista de incompatibilidades y advertencias, si existen. Una vez que tenga los resultados de la evaluación, puede intentar abordar los resultados durante el resto del planeamiento de la migración.

Hay tres maneras de completar la evaluación previa a la migración, se recomienda usar la extensión Migración de Azure Cosmos DB para MongoDB.

Extensión Migración de Azure Cosmos DB para MongoDB

La extensión Migración de Azure Cosmos DB para MongoDB en Azure Data Studio lo ayuda a evaluar una carga de trabajo de MongoDB para migrar a Azure Cosmos DB for MongoDB. Puede usar esta extensión para ejecutar una valoración integral en la carga de trabajo y descubrir las acciones que puede tener que tomar para migrar sin problemas las cargas de trabajo en Azure Cosmos DB. Durante la evaluación de un punto de conexión de MongoDB, la extensión notifica todos los recursos detectados.

Nota

Se recomienda revisar en detalle las características y la sintaxis admitidas, los límites y las cuotas de Azure Cosmos DB, así como realizar una prueba de concepto antes de la migración real.

Detección manual (heredado)

Como alternativa, puede crear una hoja de cálculo de migración del patrimonio de datos. El propósito de esta hoja de cálculo es mejorar la productividad y ayudarle a planear la migración de un extremo a otro y usarlo como un documento de seguimiento durante todo el proceso de migración.

Esta hoja contiene una lista completa de los recursos existentes (bases de datos o colecciones) en el patrimonio de datos de MongoDB.
La hoja de cálculo debe estructurarse como un registro de los recursos del patrimonio de datos, en forma de lista.
Cada fila corresponde a un recurso (base de datos o colección).
Cada columna se corresponde con una propiedad del recurso; comience con al menos el nombre y el tamaño de los datos (GB) como columnas.
A medida que avance en esta guía, compilará esta hoja de cálculo en un documento de seguimiento para el planeamiento de la migración de un extremo a otro, y agregará columnas según sea necesario.

Estas son algunas herramientas que puede usar para descubrir recursos:

Revise la hoja de cálculo y compruebe detenidamente cada colección con las características y la sintaxis admitidas, y los límites y cuotas de Azure Cosmos DB.

Utilidad Database Migration Assistant (heredada)

Nota

Database Migration Assistant es una utilidad heredada diseñada para ofrecer ayuda con los pasos previos a la migración. Se recomienda usar la extensión Migración de Azure Cosmos DB para MongoDB para todos los pasos previos a la migración.

Puede usar la utilidad Database Migration Assistant (DMA) para que le ayude con los pasos previos a la migración.

Asignación previa a la migración

Una vez completados los pasos de detección y evaluación, habrá terminado con el lado de la ecuación de MongoDB. Ahora es el momento de planear el de Azure Cosmos DB. ¿Cómo tiene pensado instalar y configurar los recursos de producción de Azure Cosmos DB? Realice el planeamiento por recurso, lo que significa que debe agregar las siguientes columnas a la hoja de cálculo de planeamiento:

Asignación de Azure Cosmos DB
Clave de partición
Modelo de datos
Rendimiento dedicado frente a compartido

En las secciones siguientes se proporciona información más detallada.

Planificación de capacidad

¿Intenta planear la capacidad de una migración a Azure Cosmos DB?

Si lo único que sabe es el número de núcleos virtuales y servidores del clúster de bases de datos existente, consulte la información sobre el cálculo de unidades de solicitud mediante núcleos virtuales o CPU virtuales.
Si conoce las tasas de solicitudes típicas de la carga de trabajo de la base de datos actual, obtenga información sobre el cálculo de unidades de solicitud mediante la herramienta de planeamiento de capacidad de Azure Cosmos DB.

Consideraciones al usar la API de Azure Cosmos DB para MongoDB

Antes de planear el patrimonio de datos de Azure Cosmos DB, asegúrese de comprender los siguientes conceptos de Azure Cosmos DB:

Modelo de capacidad: la capacidad de bases de datos en Azure Cosmos DB se basa en un modelo basado a su vez en el rendimiento. Este modelo se basa en Unidades de solicitud por segundo, que es una unidad que representa el número de operaciones de base de datos que se pueden ejecutar en una colección por segundo. Esta capacidad se puede asignar en un nivel de base de datos o de colección y se puede aprovisionar en un modelo de asignación o mediante el rendimiento aprovisionado de escalabilidad automática.
Unidades de solicitud: Cada operación de base de datos tiene un costo de las Unidades de solicitud (RU) en Azure Cosmos DB. Al ejecutarse, las unidades de solicitud se restan del nivel disponible en un segundo dado. Si una solicitud requiere más RU que las RU/s asignadas actualmente, existen dos opciones para resolver el problema: aumentar el número de RU o esperar a que se inicie el próximo segundo y volver a intentar la operación.
Capacidad elástica: la capacidad de una colección o base de datos determinada puede cambiar en cualquier momento. Esta flexibilidad permite a la base de datos adaptarse de forma elástica a los requisitos de rendimiento de su carga de trabajo.
Particionamiento automático: Azure Cosmos DB proporciona un sistema de particionamiento automático que solo requiere una partición (o una clave de partición). El mecanismo de particionamiento automático se comparte entre todas las API de Azure Cosmos DB y permite datos sin problemas y en todo el escalado a través de la distribución horizontal.

Planeación del patrimonio de datos de Azure Cosmos DB

Descubra qué recursos de Azure Cosmos DB va a crear. Este proceso requiere seguir paso a paso la hoja de cálculo de migración del patrimonio de datos y asignar cada recurso de MongoDB existente a un nuevo recurso de Azure Cosmos DB.

Anticipe que cada base de datos de MongoDB se convertirá en una base de datos de Azure Cosmos DB.
Anticipe que cada colección de MongoDB se convertirá en una colección de Azure Cosmos DB.
Elija una convención de nomenclatura para sus recursos de Azure Cosmos DB. Mantener los mismos nombres de recursos suele ser una buena opción, a menos que haya cambios en la estructura de las bases de datos y colecciones.
Determine si va a usar colecciones particionadas o sin particiones en Azure Cosmos DB. El límite de las colecciones sin particiones es de 20 GB. El particionamiento, por otro lado, ayuda a lograr la escala horizontal que es fundamental para el rendimiento de muchas cargas de trabajo.
Si usa colecciones particionadas, no suponga que la clave de partición de la colección de MongoDB se convierte en la clave de partición del contenedor de Azure Cosmos DB. No suponga que la estructura de documentos del modelo de datos de MongoDB existente debe ser el mismo modelo que emplea en Azure Cosmos DB.
- 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. Siga las instrucciones de la sección Decisiones inmutables para obtener más información.
Azure Cosmos DB no reconoce ciertos tipos de colección de MongoDB, como las colecciones limitadas. Para estos recursos, solo tiene que crear colecciones de Azure Cosmos DB normales.
Azure Cosmos DB tiene dos tipos de colección propios: rendimiento compartido y dedicado. El rendimiento compartido frente al rendimiento dedicado es otra decisión crítica e inmutable que es fundamental tomar en la fase de planeamiento. Siga las instrucciones de la sección Decisiones inmutables para obtener más información.

Decisiones inmutables

Las siguientes opciones de configuración de Azure Cosmos DB no se pueden modificar ni deshacer una vez que se ha creado un recurso de Azure Cosmos DB; por lo tanto, es importante definir estas opciones de configuración correctamente durante el planeamiento previo a la migración, antes de iniciar las migraciones:

Consulte Creación de particiones y escalado horizontal en Azure Cosmos DB para elegir la mejor clave de partición. La creación de particiones, también conocida como particionamiento, es un punto clave de consideración antes de migrar los datos. Azure Cosmos DB usa una creación de particiones totalmente administrada para aumentar la capacidad de una base de datos a fin de cumplir los requisitos de almacenamiento y rendimiento. Esta característica no necesita el hospedaje ni la configuración de los servidores de enrutamiento.
- De forma similar, la funcionalidad de creación de particiones agrega capacidad automáticamente y vuelve a equilibrar los datos en consecuencia. Para obtener más información sobre cómo elegir la clave de partición adecuada para los datos, consulte Elección de una clave de partición.
Siga la guía Modelado de datos en Azure Cosmos DB para elegir un modelo de datos.
Siga la guía Optimización del costo de rendimiento aprovisionado en Azure Cosmos DB para elegir entre rendimiento dedicado y compartido para cada recurso que migra
En Procedimientos para modelar y crear particiones de datos en Azure Cosmos DB mediante un ejemplo real se incluye un ejemplo real de particionamiento y modelado de datos que sirve de ayuda para el proceso de toma de decisiones.

Costo de propiedad

Calcule el costo de propiedad de los nuevos recursos de Azure Cosmos DB mediante la calculadora de capacidad de Azure Cosmos DB.

Estimación del rendimiento

En Azure Cosmos DB, el rendimiento se aprovisiona de antemano y se mide en Unidades de solicitud (RU) por segundo. A diferencia de las máquinas virtuales o servidores locales, las Unidades de solicitud se pueden escalar y reducir verticalmente fácilmente en cualquier momento. Puede cambiar el número de RU aprovisionadas de forma inmediata. Para más información, consulte Unidades de solicitud en Azure Cosmos DB.
Puede usar la calculadora de capacidad de Azure Cosmos DB para determinar el número de unidades de solicitud que debe usar. Este número se basa en la configuración de la cuenta de la base de datos, cantidad de datos, tamaño de los documentos y las lecturas y escrituras necesarias por segundo.
Estos son factores clave que afectan al número de Unidades de solicitud necesarias:
- Tamaño del documento: a medida que el tamaño de un elemento o documento aumenta, también lo hace el número de RU consumidas para leer o escribir el elemento o documento.
- Recuento de propiedades del documento: el número de RU consumidas para crear o actualizar un documento está relacionado con el número, la complejidad y la longitud de sus propiedades. Puede reducir el consumo de Unidades de solicitud para operaciones de escritura limitando el número de las propiedades indexadas.
- Modelos de consulta: la complejidad de una consulta afecta a la cantidad de unidades de solicitud que consume una consulta.
La mejor manera de comprender el costo de las consultas es usar los datos de ejemplo en Azure Cosmos DB y ejecutar consultas de ejemplo desde el Shell de MongoDB mediante el comando getLastRequestStastistics para obtener el cargo de solicitud, lo que generará el número de Unidades de solicitud consumidas:
```
db.runCommand({getLastRequestStatistics: 1})
```
*Este comando generará un documento JSON similar al ejemplo siguiente:
```
{
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}
```
También puede usar la configuración de diagnóstico para comprender la frecuencia y los patrones de las consultas ejecutadas en Azure Cosmos DB. Los resultados de los registros de diagnóstico se pueden enviar a una cuenta de almacenamiento, una instancia de Event Hubs o Azure Log Analytics.

Planeamiento de la logística previa a la migración

Por último, ahora que tiene una vista del patrimonio de datos existente y un diseño para el nuevo patrimonio de datos de Azure Cosmos DB, está listo para planear cómo ejecutar el proceso de migración de un extremo a otro. Una vez más, realice el planeamiento por recurso y agregue columnas a la hoja de cálculo para capturar las dimensiones logísticas incluidas en esta sección.

Logística de ejecución

Asigne la responsabilidad de migrar cada recurso existente de MongoDB a Azure Cosmos DB. La forma de aplicar los recursos del equipo para guiar la migración hasta completarla es decisión suya. En el caso de las migraciones pequeñas, puede hacer que un equipo inicie la migración completa y supervise su progreso. Para migraciones más grandes, podría asignar responsabilidad a los miembros del equipo por recurso para migrar y supervisar ese recurso.

Una vez que haya asignado la responsabilidad de migrar los recursos, ahora debe elegir las herramientas de migración correctas para la migración. En el caso de migraciones pequeñas, es posible que pueda usar una herramienta de migración, como una herramienta nativa de MongoDB o Azure DMS, para migrar todos los recursos de una sola vez. En el caso de migraciones más grandes o con requisitos especiales, puede elegir herramientas de migración con una granularidad por recurso.

Antes de planear qué herramientas de migración usar, se recomienda familiarizarse con las opciones disponibles. Azure Database Migration Service para la API de Azure Cosmos DB para MongoDB proporciona un mecanismo que simplifica la migración de datos facilitando una plataforma de hospedaje totalmente administrada, opciones de supervisión de la migración y control de limitaciones automático. Esta es una lista completa de opciones:

Tipo de migración	Solución	Consideraciones
En línea	Azure Database Migration Service	• Usa la biblioteca BulkExecutor para Azure Cosmos DB • Es adecuada para grandes conjuntos de datos y se encarga de replicar cambios en directo. • Solo funciona con otros orígenes de MongoDB.
Sin conexión	Azure Database Migration Service	• Usa la biblioteca BulkExecutor para Azure Cosmos DB • Es adecuada para grandes conjuntos de datos y se encarga de replicar cambios en directo. • Solo funciona con otros orígenes de MongoDB.
Sin conexión	Azure Data Factory	• Usa la biblioteca BulkExecutor para Azure Cosmos DB • Es adecuada para grandes conjuntos de datos. • Es fácil de configurar y compatible con varios orígenes. • Faltan puntos de comprobación: significa que, si se produce un problema durante la migración, es necesario reiniciar todo el proceso de migración • Carece de una cola de mensajes fallidos, lo que implica que la presencia de varios archivos erróneos puede detener todo el proceso de migración. • Necesita código personalizado para aumentar el rendimiento de lectura de determinados orígenes de datos.
Sin conexión	Herramientas existentes de Mongo (mongodump, mongorestore, Studio3T)	• Es fácil de configurar e integrar. • Necesita un control personalizado de las limitaciones.
Sin conexión o en línea	Azure Databricks y Spark	• Ofrece control total de la velocidad de migración y la transformación de datos. • Requiere código personalizado.

Si el recurso puede tolerar una migración sin conexión, use este diagrama para elegir la herramienta de migración adecuada:
Si el recurso requiere una migración en línea, use este diagrama para elegir la herramienta de migración adecuada:
Vea un vídeo con información general y una demostración de las soluciones de migración.

Una vez que haya elegido las herramientas de migración para cada recurso, el siguiente paso es priorizar los recursos que va a migrar. Una buena priorización puede ayudar a mantener la migración según la programación. 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. Además, dado que estas migraciones que consumen mucho tiempo suelen implicar más datos, normalmente suponen un mayor consumo de recursos para la herramienta de migración y, por lo tanto, es más probable que estén expuestas a problemas con la canalización de migración al principio. Esta práctica minimiza la posibilidad de que la programación falle debido a las dificultades con la canalización de migración.
Planee cómo supervisará el progreso de la migración una vez iniciado. Si está coordinando el trabajo de migración de datos entre un equipo, planee también una cadencia regular de sincronizaciones del equipo para tener una visión completa del progreso de 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.

Tipos de migraciones

Esta es una lista de herramientas compatibles para cada escenario de migración:

Source	Destination	Recomendaciones de proceso
• Clúster local de MongoDB • Clúster de máquinas virtuales en IaaS de MongoDB • Clúster de MongoDB Atlas: sin conexión	Mongo API de Azure Cosmos DB	• <10 GB de datos: herramientas nativas de MongoDB • < Datos de 1 TB: Azure DMS • > Datos de 1 TB: Spark
• Clúster local de MongoDB • Clúster de máquinas virtuales en IaaS de MongoDB • Clúster de MongoDB Atlas: sin conexión	Mongo API de Azure Cosmos DB	• < Datos de 1 TB: 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 es mejor en términos de escala (por ejemplo, migración más rápida)
• Archivo JSON	Mongo API de Azure Cosmos DB	• Herramientas nativas de MongoDB específicamente mongoimport
• Archivo CSV	Mongo API de Azure Cosmos DB	• Herramientas nativas de MongoDB específicamente mongoimport
• Archivo BSON	Mongo API de Azure Cosmos DB	• Herramientas nativas de MongoDB específicamente mongorestore

Compatibilidad con herramientas de las versiones de MongoDB

Dado que va realizar la migración desde una versión determinada de MongoDB, a continuación se incluyen las herramientas compatibles para cada versión:

Versión de origen de MongoDB	Azure Cosmos DB para MongoDB está destinado a la versión 4.2	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, DMS, ADF, Spark	Ninguno

Después de la migración

En la fase previa a la migración, dedique algo de tiempo para planear los pasos que realizará para la migración de aplicaciones y la optimización posterior a la migración.

En la fase posterior a la migración, ejecutará una migración total de la aplicación para usar Azure Cosmos DB en lugar del patrimonio de datos de MongoDB existente.
Haga todo lo posible para planificar la indexación, la distribución global, la coherencia y otras propiedades mutables de Azure Cosmos DB a nivel de recurso. Sin embargo, estas opciones de configuración de Azure Cosmos DB se pueden modificar más adelante, por lo que espera realizar ajustes en esta configuración más adelante. Aplique estas configuraciones mutables después de la migración.
Para obtener una guía con los pasos posteriores a la migración, consulte Pasos de optimización posteriores a la migración cuando se usa la API de Azure Cosmos DB para MongoDB.

Pasos siguientes

Migración a Azure Cosmos DB for MongoDB