Esta página explica los resultados de referencia de la migración de datos de Relational Migrator y proporciona recomendaciones basadas en esos resultados. Puedes utilizar los resultados y las recomendaciones para estimar los plazos de migración, seleccionar las configuraciones de infraestructura adecuadas y planificar los requisitos de recursos para tu migración de relacional a MongoDB.
Descripción general de benchmark
Los puntos de referencia de Relational Migrator midieron el rendimiento de la migración en función de los siguientes factores:
Complejidad del mapeo de esquemas
Tamaño de la base de datos relacional
Tipo de almacenamiento de base de datos relacional
Configuración de la instancia del Relational Migrator
Configuración de MongoDB Atlas
Las pruebas de referencia utilizaron MongoDB Atlas e infraestructura de AWS. Sin embargo, los patrones de rendimiento y recomendaciones se aplican de manera amplia a otros proveedor de nube y a implementaciones on-premises. Para aprender más sobre la infraestructura utilizada en los benchmarks, consulte Configuración de referencia.
Complejidad del mapeo de esquemas
El Relational Migrator permite transformar su esquema relacional en un modelo orientado a documentos. Los siguientes términos describen diferentes niveles de complejidad de mapeo de esquemas de MongoDB utilizados por los benchmarks:
Nivel de complejidad | Descripción |
|---|---|
Uno a uno | Un esquema de MongoDB que coincida con tu esquema relacional: cada tabla se asigna a una sola colección de MongoDB y cada fila se asigna a un solo documento. Uso mínimo de funcionalidades avanzadas. |
Mapas incrustados | Un esquema de MongoDB que contiene algunos arreglos incrustados o documentos incrustados. Un máximo de dos niveles de documentos anidados. |
Avanzado | Un esquema de MongoDB que utiliza muchas funcionalidades avanzadas que pueden aumentar los tiempos de migraciones. Algunos ejemplos de funcionalidades avanzadas incluyen los siguientes:
El esquema avanzado tiene un máximo de tres niveles de documentos anidados. |
Para obtener más información sobre cómo mapear datos relacionales a esquemas de MongoDB, consulte Modelado de datos.
Configuración del Benchmark
La siguiente tabla describe la configuración de cada componente utilizado en las pruebas de referencia:
Componente | Configuración |
|---|---|
Base de datos fuente (Oracle) |
La instancia de Oracle fue aislada y recibió tráfico exclusivamente de la instancia de Relational Migrator. |
Relational Migrator |
|
Base de datos objetivo (MongoDB Atlas) |
|
Resultados de benchmark
La siguiente tabla muestra los resultados de las pruebas de referencia. Los criterios de referencia utilizaron la interfaz de usuario de Atlas o mongostat para supervisar las métricas de los documentos. La columna Average Throughput (MB/s) está redondeada a dos decimales. La columna Cluster Documents/s se redondea a la decena de miles de documentos por segundo más cercana. Para las migraciones One-to-one de larga duración, la columna Cluster Documents/s proporciona un límite inferior y superior observado debido a los cambios de velocidad durante el benchmark.
Nota
La base de datos Oracle no mostró un uso significativo de CPU ni de RAM durante las pruebas de rendimiento.
Tamaño de la base de datos | Complejidad del mapeo | Tipo de almacenamiento Oracle RDS | Nivel de clúster Atlas | Duración de la migración | Rendimiento promedio (MB/s) | Documentos del clúster/s |
|---|---|---|---|---|---|---|
10 GB | Uno a uno | gp2 | M60 | 15 minutos | 11.11 | 80,000 (insert) |
10 GB | Mapas incrustados | gp2 | M60 | 37 minutos | 4.50 | 80,000 (insert), 40,000 (update) |
10 GB | Avanzado | gp2 | M60 | 47 minutos | 3.55 | 90,000 (insert), 40,000 (update) |
100 GB | Uno a uno | gp3 | M60 | 2 horas, 31 minutos | 11.04 | 80,000 a 100,000 (Insertar) |
100 GB | Mapas incrustados | gp3 | M80 | 16 horas, 25 minutos | 1.69 | 90,000 (insert), 40,000 (update) |
100 GB | Avanzado | gp3 | M140 | 15 horas, 47 minutos | 1.76 | 90,000 (insert), 40,000 (update) |
1 TB | Uno a uno | SSD IOPS | M60 | 30 horas, 50 minutos | 9.01 | 85,000 a 100,000 (Insertar) |
El Relational Migrator siempre comienza con una serie de insert operaciones para escribir los documentos iniciales. Luego utiliza la operación update para insertar documentos incrustados o arreglos incrustados. Como resultado, los resultados de criterio One-to-one contienen solo operaciones de inserción, mientras que los resultados de Embedded Mappings y Advanced contienen tanto operaciones de inserción como de actualización.
Estimaciones del rendimiento
Según los resultados de medición comparativa, Relational Migrator puede migrar aproximadamente:
21 GB/hora para esquemas uno a uno.
7 GB/hora para esquemas con hasta dos niveles de asignaciones integradas.
La velocidad de migración de bases de datos para esquemas uno a uno es aproximadamente lineal. Por ejemplo, una migración uno a uno de 100 GB tarda aproximadamente 10 veces más que una migración uno a uno de 10 GB.
La velocidad de migración para esquemas más complejos no escala linealmente con el tamaño de la base de datos. Cuantos más documentos incrustados, arreglos incrustados y otras funcionalidades haya en el esquema, más lento será el proceso de migración.
Recomendaciones
Configuraciones recomendadas
La siguiente tabla proporciona los niveles recomendados de clúster de Atlas y los tipos de almacenamiento de AWS RDS según el tamaño de la base de datos de origen y la complejidad del mapeo.
Tamaño del conjunto de datos fuente | Complejidad del mapeo | Nivel recomendado de clústeres Atlas | Tipo de almacenamiento recomendado de AWS RDS |
|---|---|---|---|
0-50 GB | Uno a uno | M60 | gp2 |
0-50 GB | Mapas incrustados | M60 | gp2 |
0-50 GB | Avanzado | M60 | gp2 |
50 GB-300 GB | Uno a uno | M60 | gp3 |
50 GB-300 GB | Mapas incrustados | M80 | gp3 |
50 GB-300 GB | Avanzado | M80 | gp3 |
300 GB-1 TB | Uno a uno | M60 | gp3 |
300 GB-1 TB | Mapas incrustados | M140 | SSD IOPS |
300 GB-1 TB | Avanzado | M140 | SSD IOPS |
1 TB+ | Uno a uno | M60 | SSD IOPS |
1 TB+ | Mapas incrustados | M200 | SSD IOPS |
1 TB+ | Avanzado | M200 | SSD IOPS |
Aunque la tabla especifica las configuraciones de MongoDB Atlas y AWS RDS, puede aplicar estas recomendaciones a otros proveedores de nube y a implementaciones autogestionadas. Para obtener más información acerca de la configuración de infraestructura asociada con un determinado nivel de clúster de MongoDB Atlas, consulta proveedor de nube. Para obtener más información sobre los tipos de almacenamiento de AWS RDS, consulta la documentación de Tipos de almacenamiento de AWS RDS.
Optimizar la latencia de red
Para minimizar la latencia de la red, asegúrese de que la base de datos de origen, el Relational Migrator y el clúster de destino se estén ejecutando en el mismo centro de datos.
Supervisar los cuellos de botella
Para optimizar el rendimiento de la migración, supervise las métricas para identificar los cuellos de botella en el rendimiento. Como práctica recomendada, sigue el flujo de datos al identificar cuellos de botella en el rendimiento: comienza supervisando la base de datos de origen, luego pasa a Relational Migrator y, finalmente, al clúster de destino.
Cuellos de botella en bases de datos de origen
Si observas IOPS de lectura bajos (< 50), la base de datos de origen podría ser el cuello de botella. Considera tomar las siguientes acciones para mejorar el rendimiento de la base de datos de origen:
AWS RDS: utiliza
Provisioned IOPSo mejora el tipo de almacenamiento.On-premises: Para mejorar el rendimiento, es posible que requiera actualizaciones de almacenamiento físico o una migración a una solución de almacenamiento con mejor rendimiento.
Relational Migrator Cuellos de botella
Si observa que la CPU y la RAM en la instancia del Relational Migrator están completamente utilizadas, Relational Migrator es el cuello de botella. Consider increasing the instancia size to improve migración performance.
Los siguientes resultados de la prueba muestran el impacto de aumentar el número de vCPU y la RAM en la instancia de Relational Migrator en el rendimiento de la migración:
Tamaño de la base de datos de origen | Complejidad del mapeo | 16 vCPU, 32 GB de RAM Duración | 32 vCPU, 64 GB de RAM Duración | Mejora |
|---|---|---|---|---|
10 GB | Uno a uno | 15 minutos | 15 minutos | 0% |
10 GB | Mapas incrustados | 50 minutos | 37 minutos | 26% |
10 GB | Avanzado | 63 minutos | 47 minutos | 25.40% |
100 GB | Uno a uno | 3 horas, 34 minutos | 2 horas, 31 minutos | 29.44% |
100 GB | Mapas incrustados | 18 horas, 24 minutos | 16 horas, 25 minutos | 10.78% |
100 GB | Avanzado | 16 horas, 35 minutos | 15 horas, 47 minutos | 4.82% |
1 TB | Uno a uno | 45 horas, 20 minutos | 30 horas, 50 minutos | 31.99% |
Cuando la instancia de Relational Migrator era el cuello de botella, aumentar el conteo de vCPU y la RAM resultó en una mejora de rendimiento del 25-%30.
Cuellos de botella de la base de datos de destino
Si observa tasas bajas de inserción o actualización de documentos en comparación con la tabla de resultados de referencia, el clúster de MongoDB podría ser el cuello de botella. Considera tomar las siguientes acciones para mejorar el rendimiento de la migración:
Aumentar las IOPS aprovisionadas
Incrementar vCPU o RAM
Incrementa el nivel de clúster
Si observa que las actualizaciones se han limitado debido al atraso de la replicación, aumentar los IOPS aprovisionados tiene el mayor impacto en el rendimiento de la migración.