Migración desde una base de datos relacional a DynamoDB
La migración de una base de datos relacional a DynamoDB requiere una planificación cuidadosa para garantizar un resultado satisfactorio. Esta guía lo ayudará a entender cómo funciona este proceso, qué herramientas tiene disponibles y a evaluar las posibles estrategias de migración para elegir la que mejor se adapte a sus necesidades.
Temas
- Razones para migrar a DynamoDB
- Consideraciones al migrar una base de datos relacional a DynamoDB
- Comprensión del funcionamiento de la migración a DynamoDB
- Herramientas que ayudan a migrar a DynamoDB
- Elección de la estrategia adecuada para migrar a DynamoDB
- Migración sin conexión a DynamoDB
- Migración híbrida a DynamoDB
- Migración en línea a DynamoDB mediante la migración de cada tabla de forma individual
- Migración en línea a DynamoDB con una tabla provisional personalizada
Razones para migrar a DynamoDB
La migración a Amazon DynamoDB presenta una serie de ventajas muy interesantes para las empresas y las organizaciones. Estas son algunas de las principales ventajas que convierten a DynamoDB en una opción atractiva para migrar las bases de datos:
-
Escalabilidad: DynamoDB se ha diseñado para gestionar cargas de trabajo masivas y escalar sin complicaciones para adaptarse al crecimiento de los volúmenes de datos y del tráfico. DynamoDB le permite ampliar o reducir fácilmente su base de datos en función de la demanda, lo que garantiza que sus aplicaciones puedan gestionar picos repentinos de tráfico sin que afecte al rendimiento.
-
Rendimiento: DynamoDB ofrece acceso a datos de baja latencia, lo que permite a las aplicaciones recuperar y procesar datos con una velocidad excepcional. Su arquitectura distribuida garantiza que las operaciones de lectura y escritura se distribuyan en varios nodos, lo que ofrece tiempos de respuesta uniformes en milisegundos de un solo dígito, incluso con altas tasas de solicitudes.
-
Totalmente administrado: DynamoDB es un servicio totalmente administrado por AWS. Esto significa que AWS gestiona los aspectos operativos de la administración de bases de datos, incluidos el aprovisionamiento, la configuración, la aplicación de parches, las copias de seguridad y el escalado. Esto le permite centrarse más en el desarrollo de sus aplicaciones y menos en las tareas de administración de bases de datos.
-
Arquitectura sin servidor: DynamoDB admite un modelo sin servidor, conocido como DynamoDB bajo demanda, en el que solo se paga por las solicitudes de lectura y escritura reales que realice la aplicación sin que sea necesario aprovisionar capacidad por adelantado. Este modelo de pago por solicitud ofrece rentabilidad y unos gastos operativos mínimos, ya que solo paga por los recursos que consume sin que sea necesario aprovisionar ni monitorear la capacidad.
-
Flexibilidad NoSQL: a diferencia de las bases de datos relacionales tradicionales, DynamoDB sigue un modelo de datos NoSQL, lo que proporciona flexibilidad en el diseño de esquemas. DynamoDB permite almacenar datos estructurados, semiestructurados y sin estructurar, lo que los hace adecuados para gestionar tipos de datos diversos y en constante evolución. Esta flexibilidad permite ciclos de desarrollo más rápidos y una adaptación más sencilla a los requisitos empresariales en constante cambio.
-
Alta disponibilidad y durabilidad: DynamoDB replica los datos en varias zonas de disponibilidad dentro de una región, lo que garantiza una alta disponibilidad y durabilidad de los datos. Además, gestiona automáticamente la replicación, la conmutación por error y la recuperación, lo que minimiza el riesgo de pérdida de datos o interrupciones en el servicio. DynamoDB ofrece un SLA de disponibilidad de hasta el 99,999 %.
-
Seguridad y conformidad: DynamoDB se integra con AWS Identity and Access Management para controlar el acceso de forma precisa. Proporciona cifrado en reposo y en tránsito, lo que garantiza la seguridad de sus datos. DynamoDB también aplica varios estándares de conformidad, como HIPAA, PCI DSS y RGPD, lo que le permite cumplir con los requisitos normativos.
-
Integración con el ecosistema de AWS: al formar parte del ecosistema de AWS, DynamoDB se integra perfectamente con otros servicios de AWS, como AWS Lambda, AWS CloudFormation y AWS AppSync. Esta integración le permite crear arquitecturas sin servidor, aprovechar la infraestructura como código y crear aplicaciones basadas en datos en tiempo real.
Consideraciones al migrar una base de datos relacional a DynamoDB
Los sistemas de bases de datos relacionales y las bases de datos NoSQL tienen diferentes ventajas y desventajas. Estas diferencias hacen que el diseño de las bases de datos sea muy distinto entre los dos sistemas.
| Base de datos relacional | Base de datos NoSQL | |
|---|---|---|
| Consultar la base de datos | En las bases de datos relacionales, los datos se pueden consultar de manera flexible, pero las consultas son relativamente caras y no escalan bien cuando hay mucho tráfico (consulte Primeros pasos para modelar datos relacionales en DynamoDB). Una aplicación de base de datos relacional puede implementar la lógica empresarial en los procedimientos almacenados, las subconsultas de SQL, las consultas de actualización masiva y las consultas de agregación. | En una base de datos NoSQL como DynamoDB, existe un número limitado de métodos para consultar los datos; si se utiliza cualquier otro método diferente a estos, resultará más costoso y lento realizar las consultas. Las escrituras en DynamoDB son simples. La lógica empresarial de la aplicación que antes se ejecutaba en procedimientos almacenados debe refactorizarse para que se ejecute fuera de DynamoDB en un código personalizado que se ejecute en un host como Amazon EC2 o AWS Lambda. |
| Diseño de la base de datos | El diseño busca la flexibilidad sin preocuparse por los detalles o el rendimiento de la implementación. Por lo general, la optimización de consultas no afecta al diseño del esquema, pero la normalización es importante. | El esquema se diseña específicamente para que las consultas más habituales y más importantes resulten lo más rápidas y económicas que sea posible. Las estructuras de datos se ajustan a los requisitos específicos de los casos de uso de la organización. |
Diseñar para una base de datos NoSQL requiere un cambio de mentalidad respecto al diseño de un sistema de administración de bases de datos relacionales (RDBMS). En un sistema RDBMS, puede crear un modelo de datos normalizados sin pensar en los patrones de acceso. Posteriormente, podrá ampliar este modelo cuando surjan nuevos requisitos sobre preguntas y consultas. Puede organizar cada tipo de datos en su propia tabla.
Sin un diseño NoSQL, no debería comenzar a diseñar su esquema para DynamoDB hasta que sepa las preguntas a las que tendrá que responder. Es esencial comprender los problemas empresariales y los patrones de lectura y escritura de la aplicación. También debería mantener el menor número de tablas posible en una aplicación de DynamoDB. Tener menos tablas hace que las cosas sean más escalables, requiere menos administración de permisos y reduce la sobrecarga de la aplicación de DynamoDB. También puede ayudar a mantener los costos de las copias de seguridad generalmente más bajos.
La tarea de modelar datos relacionales para DynamoDB y crear una nueva versión de la aplicación front-end se tratan en otro tema. En esta guía se da por sentado que tiene una nueva versión de la aplicación creada para usar DynamoDB, pero que aún debe determinar la mejor manera de migrar y sincronizar los datos históricos durante la transición.
Consideraciones sobre el tamaño
El tamaño máximo de cada elemento (fila) que se almacena en una tabla de DynamoDB es de 400 KB. Para obtener más información, consulte Cuotas de tabla, servicio y cuenta en Amazon DynamoDB. El tamaño del elemento viene determinado por el tamaño total de todos los nombres y valores de los atributos de un elemento. Para obtener más información, consulte Tamaños y formatos de elementos de DynamoDB.
Si la aplicación necesita almacenar más datos en un elemento de lo que permite el límite de tamaño de DynamoDB, divida el elemento en una colección de elementos, comprima los datos del elemento o almacene el elemento como un objeto de Amazon Simple Storage Service (Amazon S3) y almacene el identificador de objetos de Amazon S3 en el elemento de DynamoDB. Consulte Prácticas recomendadas para almacenar elementos y atributos grandes. El costo de actualizar un elemento se basa en el tamaño total del elemento. En el caso de las cargas de trabajo que requieren actualizaciones frecuentes de los elementos existentes, actualizar elementos pequeños de uno o dos KB costará menos que los elementos más grandes. Para obtener más información sobre las colecciones de elementos, consulte Colecciones de elementos: cómo modelar relaciones de uno a varios en DynamoDB.
Al elegir los atributos de clave de clasificación y partición, otros ajustes de la tabla, el tamaño y la estructura de los elementos y si se van a crear índices secundarios, asegúrese de revisar la documentación de modelado de DynamoDB y la guía correspondiente para Optimización de los costos en las tablas de DynamoDB. Asegúrese de probar su plan de migración para que la solución de DynamoDB sea rentable y se ajuste a las características y limitaciones de DynamoDB.
Comprensión del funcionamiento de la migración a DynamoDB
Antes de revisar las herramientas de migración disponibles, piense en cómo procesa DynamoDB las escrituras.
nota
DynamoDB fragmenta y distribuye automáticamente los datos a varios servidores y ubicaciones de almacenamiento compartidos, por lo que no existe una forma directa de importar en masa un conjunto de datos grande directamente a un servidor de producción.
La operación de escritura predeterminada y más común es una operación de API PutItem única. Puede realizar una operación PutItem en bucle para procesar conjuntos de datos. DynamoDB admite conexiones simultáneas prácticamente ilimitadas, por lo que, si puede configurar y ejecutar una rutina de carga masiva con varios subprocesos, como MapReduce o Spark, la velocidad de escritura solo está limitada por la capacidad de la tabla de destino (que también suele ser ilimitada).
Al cargar datos en DynamoDB, es importante comprender la velocidad de escritura del cargador. Si los elementos (filas) que está cargando tienen un tamaño de 1 KB o menos, esta velocidad es simplemente el número de elementos por segundo. A continuación, se puede aprovisionar la tabla de destino con suficientes WCU (unidades de capacidad de escritura) para gestionar esta velocidad. Si el cargador supera la capacidad aprovisionada por algún segundo, es posible que las solicitudes adicionales se limiten o se rechacen por completo. Puede comprobar si hay limitaciones en los gráficos de CloudWatch que se encuentran en la pestaña de monitoreo de la consola de DynamoDB.
La segunda operación que se puede realizar es con una API relacionada llamada BatchWriteItem. BatchWriteItem permite combinar hasta 25 solicitudes de escritura en una llamada a la API. El servicio las recibe y las procesa como solicitudes PutItem independientes en la tabla. A la hora de elegir BatchWriteItem, no disfrutará de las ventajas de los reintentos automáticos que se incluyen en el SDK de AWS para realizar llamadas individuales con PutItem. Por lo tanto, si hay algún error (por ejemplo, excepciones de limitación), tendrá que buscar en la lista de escrituras con errores en la llamada de respuesta a BatchWriteItem. Para obtener más información sobre cómo gestionar las advertencias de limitación en caso de que se detecten en los gráficos de limitación de CloudWatch, consulte Problemas de limitación de las tablas de DynamoDB que utilizan el modo de capacidad aprovisionada.
El tercer tipo de importación de datos es posible gracias a la característica Importación de DynamoDB desde S3
Herramientas que ayudan a migrar a DynamoDB
Existen varias herramientas comunes de migración y ETL que puede utilizar para migrar datos a DynamoDB.
Muchos clientes optan por escribir sus propios scripts y trabajos de migración para crear transformaciones de datos personalizadas para el proceso de migración. Si tiene previsto operar una tabla de DynamoDB de gran volumen con mucho tráfico de escritura o con trabajos normales de gran carga masiva, tal vez sea mejor crear herramientas de migración para ganar confianza con el comportamiento de DynamoDB con un tráfico de escritura intenso. Al realizar una migración de práctica, se puede experimentar con situaciones como la gestión de la aceleración y el aprovisionamiento eficiente de tablas al principio del proyecto.
Amazon ofrece una serie de herramientas de datos que puede aprovechar, como AWS Database Migration Service (DMS), AWS Glue, Amazon EMR y Amazon Managed Streaming for Apache Kafka. Todas estas herramientas se pueden utilizar para realizar una migración durante el tiempo de inactividad. Además, algunas herramientas que pueden aprovechar las características de captura de datos de cambios (CDC) en las bases de datos relacionales también pueden admitir las migraciones en línea. Al elegir la mejor herramienta, será útil tener en cuenta el conjunto de habilidades y la experiencia que su organización tiene con cada herramienta, junto con las características, el rendimiento y el costo de cada una de ellas.
Elección de la estrategia adecuada para migrar a DynamoDB
Una aplicación de base de datos relacional grande puede abarcar cien o más tablas y admitir varias funciones de aplicación diferentes. Al realizar una migración grande, considere la posibilidad de dividir la aplicación en componentes o microservicios más pequeños y migrar un conjunto pequeño de tablas a la vez. A continuación, puede migrar componentes adicionales a DynamoDB en oleadas.
Al seleccionar una estrategia de migración, algunos parámetros pueden orientarlo hacia una solución u otra. Podemos presentar estas opciones en un árbol de decisiones para simplificar las opciones disponibles en función de los requisitos y recursos disponibles. Los conceptos se mencionan brevemente aquí (pero se tratarán con más detalle más adelante en la guía):
-
Migración sin conexión: si su aplicación puede tolerar algún tiempo de inactividad durante la migración, se simplificará considerablemente el proceso de migración.
-
Migración híbrida: este enfoque permitiría un tiempo de actividad parcial durante una migración, como permitir lecturas pero no escrituras, o permitir lecturas e inserciones, pero no actualizaciones ni eliminaciones.
-
Migración en línea: las aplicaciones que no requieren ningún tiempo de inactividad durante la migración son más difíciles de migrar y pueden requerir una planificación significativa y un desarrollo personalizado. Una decisión clave consistirá en estimar y sopesar los costos de crear un proceso de migración personalizado frente al costo que supone para la empresa disponer de un período de inactividad durante la transición.
| Si | Y | Entonces | ||||
|---|---|---|---|---|---|---|
| Le parece bien cerrar la aplicación durante algún tiempo durante un período de mantenimiento para realizar la migración de datos, esta migración se denomina migración sin conexión |
Utilice AWS DMS y realice una migración sin conexión con una tarea de carga completa. Si lo desea, dé forma previamente a los datos de origen con un SQL |
|||||
| Le parece bien ejecutar la aplicación en modo de solo lectura durante la migración, entonces la denominamos migración híbrida | Desactive las escrituras en la aplicación o en la base de datos de origen. Utilice AWS DMS y realice una migración sin conexión con una tarea de carga completa. | |||||
| Le parece bien ejecutar la aplicación con lecturas e inserciones de nuevos registros, pero sin actualizarla ni eliminarla, durante la migración, entonces la denominamos migración híbrida | Tiene conocimientos de desarrollo de aplicaciones y puede actualizar la aplicación relacional existente para realizar escrituras duales, incluso en DynamoDB, para todos los registros nuevos | Utilice AWS DMS y realice una migración sin conexión con una tarea de carga completa. Al mismo tiempo, despliegue una versión de la aplicación existente que permita leer y realizar escrituras duales. | ||||
| Necesita una migración con un tiempo de inactividad mínimo, esta migración se denomina migración en línea | Está migrando las tablas de origen una por una a DynamoDB sin cambios importantes en el esquema | Utilice AWS DMS para realizar una migración de datos en línea. Ejecute una tarea de carga masiva seguida de una tarea de sincronización de CDC. | ||||
| Combina tablas de origen en menos tablas de DynamoDB según la filosofía de una sola tabla | Tiene habilidades de desarrollo de bases de datos de back-end y capacidad sobrante en el host de SQL | Cree la tabla lista para NoSQL en la base de datos SQL. Rellénela y sincronícela con elementos JOIN, UNION, VIEW, desencadenadores y procedimientos almacenados. | ||||
| No tiene habilidades de desarrollo de bases de datos de back-end ni capacidad sobrante en el host de SQL | Considere la migración híbrida o sin conexión. | |||||
| Le parece bien omitir la migración de los datos históricos de transacciones o puede archivarlos en Amazon S3 en lugar de migrarlos. Solo tiene que migrar unas cuantas tablas estáticas pequeñas | Escriba un script o utilice cualquier herramienta ETL para migrar las tablas. Si lo desea, dé forma previamente a los datos de origen con un SQL VIEW. |
|||||
Migración sin conexión a DynamoDB
Las migraciones sin conexión son adecuadas cuando se puede permitir un período de inactividad para realizar la migración. Las bases de datos relacionales suelen tener un tiempo de inactividad cada mes para realizar trabajos de mantenimiento y de aplicación de parches, o incluso tiempos de inactividad más largos en caso de actualizaciones de hardware o versiones importantes.
Amazon S3 se puede utilizar como área provisional durante una migración. Los datos almacenados en formato CSV (valores separados por comas) o JSON de DynamoDB se pueden importar automáticamente a una nueva tabla de DynamoDB con la característica Importación de DynamoDB desde S3.
Plan
Realizar una migración sin conexión desde Amazon S3
Herramientas
-
Un trabajo ETL para extraer y transformar datos SQL y almacenarlos en un bucket de S3, como:
-
AWS Glue
-
Amazon EMR
-
Su propio código personalizado
-
-
Característica Importación de DynamoDB desde S3
Pasos de la migración sin conexión:
-
Cree un trabajo ETL que pueda consultar la base de datos SQL, transformar los datos de las tablas en formato JSON o CSV de DynamoDB y guardarlos en un bucket de S3.
-
La característica Importación de DynamoDB desde S3 se invoca para crear una tabla nueva y cargar automáticamente los datos desde el bucket de S3.
La migración total sin conexión es sencilla y directa, pero puede que no sea muy popular entre los propietarios y los usuarios de las aplicaciones. Los usuarios se beneficiarían si la aplicación pudiera ofrecer niveles de servicio reducidos durante la migración, en lugar de no ofrecer ningún servicio.
Podría añadir una funcionalidad para desactivar las escrituras durante la migración sin conexión y, al mismo tiempo, permitir que las lecturas continuaran con normalidad. Los usuarios de la aplicación podrían seguir navegando y consultando los datos existentes de forma segura mientras se migran los datos relacionales. Si esto es lo que busca, siga leyendo para obtener más información sobre las migraciones híbridas.
Migración híbrida a DynamoDB
Si bien todas las aplicaciones de bases de datos realizan operaciones de lectura y escritura, se deben tener en cuenta los tipos de operaciones de escritura que se realizan al planificar una migración híbrida o en línea. Las escrituras en bases de datos se pueden clasificar en tres grupos: inserciones, actualizaciones y eliminaciones. Algunas aplicaciones no actualizan los registros existentes. Es posible que otras aplicaciones no requieran que se procesen las eliminaciones inmediatamente y podrían aplazarlas para someterlas a un proceso de limpieza masiva al final del mes, por ejemplo. Estos tipos de aplicaciones pueden ser más fáciles de migrar y, al mismo tiempo, requieren un tiempo de actividad parcial.
Plan
Realizar una migración híbrida en línea y sin conexión con escrituras duales de aplicaciones
Herramientas
-
Un trabajo ETL para extraer y transformar datos SQL y almacenarlos en un bucket de S3, como:
-
AWS Glue
-
Amazon EMR
-
Su propio código personalizado
-
Pasos de la migración híbrida:
-
Cree una tabla de DynamoDB de destino. Esta tabla recibirá tanto datos masivos históricos como datos nuevos y activos.
-
Cree una versión de la aplicación heredada que tenga desactivadas las eliminaciones y actualizaciones y, al mismo tiempo, realice todas las inserciones como escrituras duales tanto en la base de datos SQL como en DynamoDB.
-
Comience el trabajo ETL para migrar los datos existentes e implementar la nueva versión de la aplicación al mismo tiempo.
-
Cuando se complete el trabajo ETL, DynamoDB dispondrá de todos los registros nuevos y existentes y estará listo para la transición de la aplicación.
nota
El trabajo ETL escribe directamente desde SQL a DynamoDB. No podemos utilizar la característica de importación de S3 como en el ejemplo de migración sin conexión, ya que la tabla de destino no se hace pública ni está disponible para otras escrituras hasta que se complete toda la importación.
Migración en línea a DynamoDB mediante la migración de cada tabla de forma individual
Muchas bases de datos relacionales tienen una característica llamada Captura de datos de cambios (CDC), que permite a los usuarios solicitar una lista de los cambios realizados en una tabla y que se han realizado antes o después de un momento específico. La CDC utiliza registros internos para activar esta característica y no requieren que la tabla tenga ninguna columna con fecha y hora para que funcione.
Al migrar un esquema de tablas SQL a una base de datos NoSQL, es posible que desee combinar y cambiar la forma de los datos en menos tablas. Esto le permitirá recopilar datos en un solo lugar y evitar tener que unir manualmente los datos relacionados en operaciones de lectura de varios pasos. Sin embargo, no siempre es necesario dar forma a los datos de una sola tabla y, a veces, las tablas se migran una por una a DynamoDB. Estas migraciones de tablas individuales una por una son menos complicadas, ya que se puede aprovechar la característica CDC de la base de datos de origen con las herramientas ETL habituales que admiten este tipo de migración. Es posible que los datos de cada fila se sigan transformando en nuevos formatos, pero el alcance de cada tabla sigue siendo el mismo.
Considere la posibilidad de migrar tablas SQL una por una a DynamoDB, con la salvedad de que no hay uniones del lado del servidor.
Plan
Realizar una migración en línea de cada tabla a DynamoDB con AWS DMS
Herramientas
-
AWS Database Migration Service (DMS), una herramienta ETL que puede cargar datos históricos de forma masiva y, además, aprovechar la CDC para sincronizar las tablas de origen y destino
Pasos de la migración en línea:
-
Identifique las tablas del esquema de origen que se van a migrar.
-
Cree el mismo número de tablas en DynamoDB con una estructura de claves similar.
-
Cree un servidor de replicación en AWS DMS y configure los puntos de conexión de origen y destino.
-
Defina cualquier transformación por fila que sea necesaria (como columnas concatenadas o la conversión de fechas al formato de cadena ISO-8601).
-
Cree una tarea de migración para cada tabla para la carga completa y la captura de datos de cambios.
-
Supervise estas tareas hasta que comience la fase de replicación en curso.
-
Llegados a este punto, puede realizar cualquier auditoría de validación y, a continuación, cambiar los usuarios a la aplicación que lee y escribe en DynamoDB.
Migración en línea a DynamoDB con una tabla provisional personalizada
Es posible que desee combinar tablas para aprovechar patrones de acceso NoSQL únicos (por ejemplo, transformar cuatro tablas heredadas en una sola tabla de DynamoDB). Por lo general, una solicitud de documento con un único valor clave o una consulta de una colección de elementos agrupados previamente tienen una mejor latencia que una base de datos SQL que realiza una unión de varias tablas. Sin embargo, esto dificulta la tarea de migración. Un SQL VIEW podría hacer el trabajo dentro de la base de datos de origen para preparar un único conjunto de datos que represente las cuatro tablas de un conjunto.
Esta vista podría crear tablas JOIN en una forma desnormalizada o, en su lugar, mantener las entidades normalizadas y apilar las tablas mediante un SQL UNION. En este vídeo
Sin embargo, para las migraciones en línea con datos cambiantes y activos, no podrá aprovechar las característica de la CDC, ya que solo se admiten para consultas de una sola tabla, no desde dentro de una VIEW. Si sus tablas incluyen una columna de marca de tiempo actualizada por última vez y estas se incorporan a la VIEW, puede crear un trabajo ETL personalizado que las utilice para lograr una carga masiva con la sincronización.
Un enfoque novedoso para este desafío sería utilizar características SQL estándar, como vistas, procedimientos almacenados y desencadenadores, para crear una nueva tabla SQL con el formato final NoSQL de DynamoDB deseado.
Si el servidor de base de datos puede asignar una cantidad adicional de espacio de almacenamiento, puede crear esta tabla provisional única antes de que comience la migración. Esto se lograría escribiendo un procedimiento almacenado que lea las tablas existentes, transforme los datos según sea necesario y escriba en la nueva tabla provisional. Se podría añadir un conjunto de desencadenadores para replicar los cambios de las tablas en la tabla provisional en tiempo real. Si la política de la empresa no admite los desencadenadores, los cambios en los procedimientos almacenados pueden arrojar el mismo resultado. Usted añadiría unas cuantas líneas de código a cualquier procedimiento que escriba datos para, además, escribir los mismos cambios en la tabla provisional.
Disponer de esta tabla provisional, totalmente sincronizada con las tablas de aplicaciones heredadas, le proporcionará un excelente punto de partida para una migración en directo. Las herramientas que utilizan la CDC de base de datos para realizar migraciones en tiempo real, como AWS DMS, ahora se pueden utilizar en esta tabla. Una ventaja de este enfoque es que utiliza habilidades y características de SQL muy conocidas disponibles en el motor de bases de datos relacionales.
Plan
Realizar una migración en línea con una tabla provisional de SQL mediante AWS DMS
Herramientas
-
Procedimientos o desencadenadores de SQL almacenados y personalizados
-
AWS Database Migration Service (DMS), una herramienta ETL que puede migrar una tabla provisional en directo a DynamoDB
Pasos de la migración en línea:
-
En el motor de base de datos relacional de origen, asegúrese de que haya espacio en disco y capacidad de procesamiento adicionales.
-
Cree una nueva tabla provisional en la base de datos SQL, con las marcas de tiempo o las características CDC activadas.
-
Escriba y ejecute un procedimiento almacenado para copiar los datos de la tabla relacional existente en la tabla provisional.
-
Implemente desencadenadores o modifique los procedimientos existentes para realizar una escritura doble en la nueva tabla provisional y, al mismo tiempo, realizar escrituras normales en las tablas existentes.
-
Ejecute AWS DMS para migrar y sincronizar esta tabla de origen con una tabla de DynamoDB de destino.
Esta guía presenta varias consideraciones y enfoques para migrar datos de bases de datos relacionales a DynamoDB, centrándose en minimizar el tiempo de inactividad y utilizar herramientas y técnicas de bases de datos comunes. Para más información, consulte los siguientes temas:
