Blog de Amazon Web Services (AWS)

DynamoDB Streams – Casos de Uso y Patrones de Diseño

Por Gowri Balasubramanian ,  Senior Manager de AWS

 

En esta publicación se describen algunos casos de uso comunes que puede encontrar, junto con opciones de diseño y soluciones, al migrar datos de bases de datos relacionales a Amazon DynamoDB.

Consideraremos como manejar los siguientes escenarios:

  • ¿Cómo se configura una relación entre varias tablas en las que, en función del valor de un elemento de una tabla, se actualiza el elemento en una segunda tabla?
  • ¿Cómo se dispara un evento basado en un cambio de elemento en particular?
  • ¿Cómo se auditan o archivan los datos?
  • ¿Cómo se replican los datos en varias tablas (similar a lo que sucede en vistas materializadas/flujos de datos/replicación en bases de datos relacionales)?

Puede utilizar DynamoDB Streams para abordar todos estos casos de uso. DynamoDB Streams es un poderoso servicio que puede combinar con otros servicios de AWS para resolver muchos problemas similares. Cuando se habilita DynamoDB Streams, se captura una secuencia ordenada en el tiempo de modificaciones a nivel de elemento en una tabla de DynamoDB y se almacena la información de forma duradera durante un período de hasta 24 horas. Las aplicaciones pueden acceder a una serie de registros de secuencia, que contienen cada uno un cambio de elemento, desde una secuencia de DynamoDB en tiempo real.

AWS mantiene puntos de conexión (DNS endpoints) independientes para DynamoDB y DynamoDB Streams. Para trabajar con tablas e índices de base de datos, la aplicación debe tener acceso a un punto de conexión de DynamoDB. Para leer y procesar registros de DynamoDB Streams, la aplicación debe tener acceso a un punto de conexión de DynamoDB Streams en la misma región.

 

Figura 1: Accediendo a DynamoDB y DynamoDB Streams

 

DynamoDB Streams soporta las siguientes vistas de registro de secuencias:

  • KEYS_ONLY—Solo los atributos claves del ítem modificado
  • NEW_IMAGE—Todos los atributos del ítem modificado con los valores posteriores a la modificación del ítem o registro.
  • OLD_IMAGE—Todos los atributos del ítem modificado con los valores previos a la modificación del ítem o registro.
  • NEW_AND_OLD_IMAGES—Ambas imágenes del ítem o registro (antes y después de la modificación).

Puede procesar DynamoDB Streams de varias maneras. Los enfoques más comunes utilizan AWS Lambda o una aplicación independiente que utiliza Kinesis Client Library (KCL) con el adaptador de Kinesis de DynamoDB Streams. KCL es una librería del lado cliente que proporciona una interfaz para procesar cambios provenientes de DynamoDB Streams.

Lambda ejecuta el código basándose en un evento de DynamoDB Streams (insertar/actualizar/eliminar un elemento). En este escenario, Lambda sondea el DynamoDB Stream y, cuando detecta un nuevo registro, invoca la función de Lambda y pasa uno o más eventos.

 

Patrones de diseño de DynamoDB Streams

La siguiente figura describe una arquitectura que se puede tomar como referencia para diferentes casos de uso que utilizan DynamoDB Streams y otros servicios de AWS.

Consideremos un caso de uso de ejemplo de almacenamiento y recuperación de transacciones de facturas en una tabla de DynamoDB denominada InvoiceTransactions. Una sola factura puede contener miles de transacciones por cliente. InvoiceNumber es la clave de partición y TransactionIdentifier es la clave de ordenamiento para formar una clave primaria compuesta y proporcionar capacidades de consulta mediante InvoiceNumber. En la tabla siguiente se muestra el diseño del esquema.

Tabla: InvoiceTransactions

Clave de Partición Clave de Ordenamiento Atributo1 Atributo2 Atributo3 Atributo4
Número de Factura Identificador de transacción Monto País Fecha Documento
1212121 Client1_trans1xxxx $100 USA 06062016 {JSON Doc1}
1212121 Client1_trans2xxxx $500 USA 06062016 {JSON Doc2}
1212122 Client2_trans1xxx $200 UK 06062016 {JSON Doc3}
1212121 Client2_trans1xxxx $500 China 06062016 {JSON Doc4}

Ahora, consideremos la inserción del siguiente elemento (item).

1212123 Client3_trans1xxx $1000 USA

Al completarse la inserción del nuevo elemento (ítem), DynamoDB Streams muestra los siguientes registros.

Tipo de Vista Valores
NEW_IMAGE TransactionIdentifier= Client3_trans1xxx,InvoiceNumber=1212123,Amount-$1000,Trans_country=USA
KEYS_ONLY InvoiceNumber=1212123, TransactionIdentifier= Client3_trans1xxx

Ahora, supongamos que, debido a la naturaleza de este caso de uso, la aplicación requiere capacidades de auditoría, búsqueda, archivado, notificaciones y agregación cada vez que ocurre un cambio en la tabla InvoiceTransactions. Examinemos cómo puede procesar los datos de DynamoDB Streams para abordar diferentes tipos de casos de uso.

 

Implementando capacidades transaccionales con múltiples tablas

DynamoDB soporta transacciones para implementar lógica de negocios que requiere el tratamiento de múltiples operaciones sobre diferentes tablas como una sola acción que ejecuta todas o ninguna de esas operaciones de manera coordinada. Se puede hacer uso de las API de transacciones del lado del servidor de DynamoDB para abordar esos casos de uso que requieren un modelo de consistencia de datos fuerte (strong consistency).

Sin embargo, si necesita utilizar DynamoDB como una vista materializada de los datos almacenados de una o más tablas para una búsqueda o validación rápidas, puede utilizar DynamoDB Streeam para realizar dichas acciones. Estas tablas de vista materializadas suelen tener diferentes patrones de acceso y características operativas. Tenga en cuenta que puede aplicar los cambios solo de una manera eventualmente consistente. Los siguientes son algunos ejemplos:

  • Agregación: Considere un escenario en el que necesita mantener el monto total de la factura en dólares para la factura dada para fines de informes. Esto debe actualizarse dinámicamente cuando se insertan nuevos elementos en InvoiceTransactions u otras tablas relacionadas y mantenerse actualizados. Para capturar el total, cree una nueva tabla con el siguiente diseño.

Tabla: InvoiceTotal

Clave de Partición Atributo Numérico Atributo Alfanumérico
Número de Factura Total Fecha Actualización
1212121 $1100 06062016
1212122 $200 06072016

Cada vez que hay un cambio en la tabla InvoiceTransactions, se actualiza el total. Intentemos hacerlo usando una expresión de actualización como la siguiente.

"TableName": "InvoiceTotal",
"Key": {"InvoiceNumber": 1212121 }
UpdateExpression = "ADD Total :Amount SET update_date = :date"

El valor :Amount se puede leer desde el DynamoDB Stream cada vez que se agrega un nuevo elemento a la tabla InvoiceTransactions, y :date puede ser la fecha actual. El token ADD es el token de comando. Para un atributo numérico, agrega el valor especificado al atributo. SET es otro token de comando. Significa que todos los atributos que siguen tendrán los valores establecidos en el comando.

  • Agregación condicional: considere un escenario en el que debe registrar el número de transacciones por ubicación para aquellas facturas en las que se asigna un propietario para la verificación. En este caso, se crea una nueva tabla denominada InvoiceAction con el siguiente diseño.

Tabla: InvoiceAction

Número de Factura (clave de partición) País Transacción       (clave de ordenamiento) Acción de Verificación
1212121 USA admin@com
1212121 UK admin@co.uk
1212121 China

Cada vez que hay una nueva transacción en la tabla InvoiceTransactions, se actualiza el total mediante una expresión de actualización con una operación de escritura condicional como la siguiente.

"TableName": "InvoiceAction",
"Key": {"InvoiceNumber": 1212121, Trans_country=”USA” }
UpdateExpression = "SET Total_Trans = Total_trans+1"
ConditionExpression = “attribute_exists(verify_action)”
 Esta operación falla con 
       ConditionalCheckFailedException  para aquellos países donde no hay ningún propietario asignado, por ejemplo, China en este escenario. 
       

  • Replicación: en bases de datos relacionales como Oracle, existe un concepto de vistas materializadas que normalmente se utiliza para replicar datos de una tabla maestra a tablas secundarias con fines de consulta (descarga de consultas/replicación de datos). Del mismo modo, con DynamoDB Streams, puede replicar la tabla InvoiceTransactions en diferentes regiones para obtener informes de baja latencia y recuperación ante desastres. Puede utilizar tablas globales de DynamoDB para replicar los datos en otras regiones de AWS. Las tablas globales utilizan DynamoDB Streams para propagar cambios entre réplicas en diferentes regiones de AWS.

Archivando/auditando

Caso de Uso: Supongamos que existe un requisito de negocios para almacenar todas las transacciones de facturas durante un total de siete años para cumplir con requisitos de auditoría. Además, los usuarios deben poder ejecutar consultas ad hoc sobre estos datos.

Solución: DynamoDB es ideal para almacenar datos en tiempo real (calientes) a los que se accede con frecuencia. Después de un tiempo, dependiendo del caso de uso, los datos ya no están calientes y, por lo general, se archivan en sistemas de almacenamiento como Amazon S3. Puede diseñar una solución utilizando Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose y Amazon S3. Kinesis Data Firehose es un servicio administrado que puede utilizar para cargar los datos provenientes de un “stream” a Amazon S3, Amazon Redshift o Amazon OpenSearch Service a través de simples llamadas a la API. También puede agrupar, comprimir, transformar y cifrar los datos antes de cargarlos, lo que minimiza la cantidad de almacenamiento utilizado en el destino y aumenta la seguridad de la solución.

Los siguientes pasos describen las acciones requeridas para implementar esta solución:

  • Crear un nuevo flujo de datos (data stream) en Kinesis Data Streams (por ejemplo, ddbarchive).
  • Habilite un flujo de datos a Kinesis en una tabla de DynamoDB mediante la consola o la API. Cada vez que se crean, actualizan o eliminan elementos en la tabla InvoiceTransactions, DynamoDB envía un registro de datos a Kinesis.
  • Cree un flujo de entrega de datos de Kinesis Data Firehose para procesar los registros de ddbarchive y almacenar registros en un destino como Amazon S3, para almacenar los datos de flujo desde DynamoDB. De manera automática, Kinesis Data Firehose agrega un prefijo de hora UTC en el formato AAAA/MM/DD/HH en la carpeta antes de colocar objetos en Amazon S3. Puede modificar esta estructura de carpetas agregando la carpeta de nivel superior con una barra diagonal (por ejemplo, Factura/AAAA/MM/DD/HH para almacenar las transacciones de facturas).
  • Kinesis Data Firehose agrupa los datos y los almacena en Amazon S3 en función del tamaño del búfer (1-128 MB) o del intervalo del búfer (60-900 segundos). El criterio que se cumple primero dispara la entrega de datos a Amazon S3.
  • Implemente políticas de ciclo de vida de S3 para mover los datos más antiguos a S3-IA (para acceso poco frecuente) o Amazon Glacier para reducir aún más el costo
  • También puede utilizar DynamoDB Time to Live (TTL), que simplifica el archivado mediante la eliminación automática de elementos en función del atributo de marca de tiempo. Por ejemplo, puede designar Invoice_dt como atributo TTL almacenando el valor en el formato epoch de Unix. Para obtener un ejemplo de implementación, consulte Archivar automáticamente elementos en S3 mediante DynamoDB TTL con AWS Lambda y Amazon Kinesis Firehose.
  • Como otra opción alternativa, también puede utilizar la característica nativa de DynamoDB para exportar a S3 sin escribir ningún código. Una vez almacenados los datos en el repositorio (bucket) de S3, puede utilizar Amazon Athena para la consulta ad hoc de los datos con fines de auditoría y cumplimiento de regulaciones.

 

Reportes

Caso de Uso: ¿Cómo puedo ejecutar una búsqueda rápida en tiempo real en DynamoDB?

Solución: diseñe el esquema de la tabla de DynamoDB en función de los requisitos de generación de informes y los patrones de acceso. Por ejemplo, si necesita realizar informes en tiempo real de las transacciones por facturas, puede acceder a los datos de facturas o transacciones desde una tabla de DynamoDB directamente mediante las llamadas a la API Query o GetItem. Diseñe su esquema con una clave de partición adecuada (o clave de partición y ordenamiento) para fines de consulta. Además, puede crear índices secundarios locales e índices secundarios globales para admitir consultas que utilicen diferentes atributos en la tabla.

Ejemplo: Las siguientes consultas son buenas candidatas para reportes/paneles en tiempo real. En este ejemplo, la tabla invoiceTotal contiene los atributos total, update_date, etc., y se particiona por invoice_number. La tabla invoiceTransactions contiene InvoiceNumber y TransactionIdentifier. La tabla está particiona por ambos atributos, utilizando InvoiceNumber  como clave de partición y TransactionIdentifier como clave de ordenamiento (clave primaria compuesta). Para sus informes en tiempo real, tiene los siguientes requisitos:

  1. Reportar todas las transacciones para un InvoiceNumber
    Solución: invoque la API Query utilizando InvoiceNumber como clave de partición sin ninguna condición para la de clave de ordenamiento.
  2. Reportar todas las transacciones para un InvoiceNumber determinado donde TransactionIdentifier  comienza con xxx.
    Solución: invoque la API Query  utilizando InvoiceNumber  como clave de partición y una expresión de condición de clave para TransactionIdentifier.
  3. Reportar el total por InvoiceNumber.
    Solución: invoque la API GetItem con InvoiceNumber como clave

Caso de Uso: ¿Cómo se ejecutan consultas analíticas sobre datos almacenados en DynamoDB?

Solución: para casos de uso de baja frecuencia, puede utilizar Amazon Athena Federated Query o Amazon EMR con HiveQL para realizar consultas directamente en DynamoDB. DynamoDB está optimizado para uso transaccional en línea, donde se espera que la mayoría de las operaciones de datos estén completamente indexadas (y materializadas, para evitar la variabilidad en el rendimiento). Para un uso analítico frecuente, generalmente es mejor exportar datos de DynamoDB (periódicamente o mediante propagación continua basada en DynamoDB Streams) a una base de datos como Amazon Redshift, que es un servicio de bases de datos columnar optimizado para servir de manera eficiente agregaciones sobre grandes conjuntos de datos.

Los siguientes puntos resumen esta solución:

  • Amazon Redshift es un servicio administrado de data warehousing diseñado especialmente para ejecutar consultas analíticas complejas.
  • Habilite un flujo de datos (streaming) en la tabla de DynamoDB, que permite la captura de eventos a tiempo real en un flujo de datos de Kinesis. Cree el flujo de entrega de Firehose para consumir los registros del flujo de datos configurando Amazon Redshift como destino.
  • Kinesis Data Firehose utiliza un repositorio (bucket) intermedio de S3 y el comando COPY para cargar los datos en Amazon Redshift
  • Utilice Amazon QuickSight o herramientas de inteligencia de negocios comerciales para ejecutar consultas en Amazon Redshift.
  • Para obtener información adicional sobre la implementación de un flujo de datos utilizando Kinesis Firehose, Amazon Redshift y Amazon QuickSight, consulte Amazon Kinesis – Configuración de un flujo de datos.

Opciones alternas

Ejemplo: Consultas como las siguientes se atienden mejor desde Amazon Redshift.

  • Obtener el nivel de facturación diario registrado en la tabla invoiceTransactions en los últimos tres años.
  • Obtener max(invoice_amount)sum(total_amount), y count(invoice_trans) de la tabla Invoice Transactions agrupando resultados por día.

Notificaciones/mensajería

Caso de uso: Supongamos un escenario en el que se tiene la tabla InvoiceTransactions , y si exisrte un valor cero insertado o actualizado en el atributo de importe de la factura, se debe notificar inmediatamente al equipo encargado para que tome medidas.

Solución: Crear una solución con DynamoDB Streams, Lambda y Amazon SNS para manejar estos escenarios

Los siguientes pasos describen de manera sucinta la solución propuesta:

  • Definir un tópico y subscriptores (correo electrónico o SMS) en Amazon SNS
  • Utilizar Lambda para leer el canal de DynamoDB Stream correspondiente y comprobar si el importe de la factura es cero. A continuación, publicar un mensaje en el tópico SNS. Por ejemplo: “Tome medidas inmediatas para el número de factura 1212121 ya que el valor cero ha sido reportado como importe en la tabla InvoiceTransactions en fecha YYMMHH24MISS.”
  • Subscriptores recibirán notificaciones a tiempo real y podrán tomar las acciones apropiadas.

Para más información acerca de esta implementación, consulte el blog Desarrollando triggers en una base de datos NoSQL con Amazon DynamoDB y AWS Lambda

Caso de uso: Supongamos un escenario en el que si hay una nueva entrada para una factura, los datos deben enviarse a otro sistema de procesamiento de pagos.

Solución: Puede crear una solución con DynamoDB Streams, Lambda, Amazon SNS y Amazon SQS para gestionar estos escenarios. Supongamos que el sistema de procesamiento de pagos espera que un mensaje SQS active un flujo de trabajo de pago.

Los siguientes pasos describen de manera sucinta la solución propuesta:

  • Utilizar Lambda para leer el DynamoDB Stream apropiado, comprobar si hay una nueva transacción de factura, y enviar un mensaje vía Amazon SNS.
  • El mensaje SNS entrega el mensaje a la cola de SQS.
  • Tan pronto como llega el mensaje, la aplicación de procesamiento de pagos puede sondear la cola de SQS y disparar una acción de procesamiento.

Búsquedas (search)

Caso de uso: ¿Cómo se realizan búsquedas de texto libre en DynamoDB? Por ejemplo, suponga que la tabla InvoiceTransactions  contiene un atributo InvoiceDoc con tipo de datos Map para almacenar el documento JSON como se describe en la tabla siguiente. ¿Cómo se filtra la transacción concreta del cliente o se consultan los datos (cantidad para impresoras/escritorios, nombres de proveedores como %1%, etc.) dentro del atributo almacenado como documento en DynamoDB?

Clave de Partición Clave de Ordenamiento Atributo4
InvoiceNumber TransactionIdentifier InvoiceDoc
1212121 Client1_trans1xxxx

Partition Key   Sort Key Attribute4

InvoiceNumber   TransactionIdentifier         InvoiceDoc

1212121 Client1_trans1xxxx      {

“Vendor Name”: “Vendor1 Inc”,   “NumberofItems”: “5”,

“ItemsDesc”: [

{  “laptops”: {         “Quantity”: 2 },

“desktops”: {         “Quantity”: 1      },

“printer”: {         “Quantity”: 2      }     }

] }

Solución: DynamoDB no es el servicio adecuado para la búsqueda de texto libre en grandes volúmenes de datos. Recomendamos utilizar Amazon OpenSearch Service (Amazon OS) para abordar dichos requerimientos.

Los siguientes pasos describen de manera sucinta la solución propuesta:

  • En este diseño, la tabla InvoiceTransactionsde DynamoDB se utiliza como almacén de datos principal. Un clúster de Amazon ES se utiliza para atender todo tipo de búsquedas mediante la indexación de la Tabla InvoiceTransactions.
  • Al utilizar DynamoDB Streams, cualquier elemento nuevo de inserción, actualización o eliminación de la tabla principal se captura y procesa mediante AWS Lambda. Lambda después realiza las llamadas adecuadas a Amazon ES para indexar los datos en tiempo real.
  • Para más detalles relacionados a esta arquitectura lea el artículo Indexando contenido de Amazon DynamoDB con el servicio Amazon OpenSearch y AWS Lambda.
  • Alternativamente, puede aprovechar la funcionalidad de DynamoDB Streams para enviar los cambios a Amazon ES a través de Amazon Kinesis Data Firehose. Antes de cargar datos en Amazon ES, es posible que deba realizar transformaciones en los datos. Puede utilizar funciones de Lambda para realizar esta tarea; para obtener más información, vea Transformación de datos.

OpenSearch también admite todo tipo de consultas de texto libre, incluida la clasificación y agregación de resultados. Otra ventaja de este enfoque es la extensibilidad. OpenSearch Query se puede modificar fácilmente para agregar nuevos filtros, y Amazon OS lo hace sin requerir ningún tipo de configuración adicional. Por ejemplo, si agrega un nuevo atributo en DynamoDB, está disponible automáticamente para realizar consultas en Amazon ES.

Prácticas recomendadas para trabajar con DynamoDB Streams

Tenga en cuenta las siguientes prácticas recomendadas al diseñar soluciones que utilicen DynamoDB Streams:

  • DynamoDB Streams le permite crear soluciones mediante la sincronización de datos casi en tiempo real. Sin embargo, no garantiza consistencia transaccional en múltiples tablas. Esto es algo que debe manejarse a nivel de aplicación. Además, tenga en cuenta la latencia involucrada (fracciones de segundo) en el procesamiento de datos de flujo a medida que los datos se propagan dentro de DynamoDB Streams. Esto le ayuda a definir el SLA con respecto a la disponibilidad de datos para sus aplicaciones aguas abajo y usuarios finales.
  • Todos los cambios a nivel de elemento estarán en la secuencia, incluidas las eliminaciones. La aplicación debe poder controlar eliminaciones, actualizaciones y creaciones.
  • Diseñe su capa de procesamiento de flujo de datos para manejar diferentes tipos de fallas. Asegúrese de almacenar los datos de la secuencia en una cola de mensajes fallidos como SQS o S3, para su posterior procesamiento en caso de error
  • Pueden producirse errores en la aplicación que lee los eventos de la secuencia. Puede diseñar la aplicación para minimizar el riesgo y el radio de explosión. Con ese fin, intente no actualizar demasiadas tablas con el mismo código. Además, puede diseñar las tablas para actualizar varios atributos de un solo elemento (en lugar de cinco elementos diferentes, por ejemplo). También puede definir su procesamiento como idempotente, lo que puede permitirle volver a intentarlo de forma segura. También debe detectar diferentes excepciones en su código y decidir si desea volver a intentar o ignorar estos registros y ponerlos en una cola de mensajes fallidos para su posterior análisis.
  • Tenga en cuenta siguientes limitaciones mientras diseña aplicaciones de consumo:
    • La retención de datos en DynamoDB Streams es un máximo de 24 horas.
    • No más de dos procesos deben leer de un fragmento de flujo (stream shard) al mismo tiempo.
  • Le recomendamos que considere Lambda para el procesamiento de DynamoDB Streams siempre que sea posible, ya que el servicio es serverless y, por lo tanto, no requiere invertir tiempo en configuración y administración. En primer lugar, evalúe si se puede utilizar Lambda. Si no es factible, use la librería de cliente de Kinesis (Kinesis Client Library). La siguiente tabla comparativa puede ayudarle a decidir.
Parámetros AWS Lambda Kinesis Client Library
Despliegue Lambda sondea DynamoDB Streams e invoca la función/código tan pronto como detecta el nuevo registro. La aplicación se escribe utilizando la librería KCL con DynamoDB Streams Kinesis Adapter y se aloja en una instancia EC2.
Manejo Lambda escala automáticamente en función del rendimiento requerido.

Debe administrar los fragmentos (shards), el monitoreo, el escalado y el proceso de comprobación de acuerdo con las prácticas recomendadas de KCL.

(Para obtener más información, consulte esta entrada de blog de diseño y esta entrada de blog de supervisión).

Cómo Funciona For every DynamoDB partition, there is a corresponding shard and a Lambda function poll for events in the stream (shard). Based on the batch size you specify, it fetches the records, processes it, and then fetches the next batch. Para cada partición de DynamoDB, hay un fragmento (shard) correspondiente y una función Lambda de sondeo para los eventos de la secuencia (fragmento). Según el tamaño de lote que especifique, obtiene los registros, los procesa y, a continuación, obtiene el siguiente lote.
  • Enumera las particiones de la secuencia.
  • Coordina las asociaciones de fragmentos con otros trabajadores (si los hubiera).
  • Crea una instancia de un procesador de registros para cada fragmento (shard) que administra.
  • Extrae registros del DynamoDB Stream.
  • Envía los registros al procesador de registros correspondiente.
  • Ejecuta puntos de control sobre registros procesados.
Tiempo de Ejecución La duración máxima de ejecución de Lambda por solicitud es de 900 segundos. No hay restricciones
Disponibilidad Lambda es un servicio administrado y es altamente disponible. No se requieren ventanas de mantenimiento ni tiempos de inactividad programados. La aplicación debe estar alojada en un grupo de EC2 Auto Scaling para alta disponibilidad.
Otras Consideraciones Tenga en cuenta el impacto del límite de carga útil de Lambda en el uso de Lambda para consumir mensajes de DynamoDB Streams. Cualquiera de los tipos _IMAGE puede excederlo, especialmente para elementos más grandes. Por lo tanto, debe especificar el tamaño del lote en consecuencia.

Resúmen

DynamoDB Streams es un poderoso servicio administrado de AWS que puede combinar con otros servicios como AWS Lambda y Kinesis, entre otros, para crear soluciones prácticas de migración de almacenes de datos relacionales a DynamoDB. En esta publicación se describen algunos casos de uso y soluciones comunes, junto con algunas prácticas recomendadas que debe seguir al trabajar con DynamoDB Streams.

 

Este artículo fue traducido del Blog de AWS en Inglés.

 


Sobre el autor

Gowri Balasubramanian es un senior manager en Amazon Web Services. Él Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica tanto en servicios de bases de datos relacionales como NoSQL, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.

 

 

 

Sobre el traductor

Camilo Leon es un senior solutions architect especializado en bases de datos en Amazon Web Services. Él Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.

 

 

 

Conozca más contenidos sobre base de datos en la página de sesiones bajo demanda.

Acceda >