Uso de tablas globales de DynamoDB - Amazon DynamoDB

Uso de tablas globales de DynamoDB

Las tablas globales se crean en la huella global de Amazon DynamoDB para proporcionarle una base de datos totalmente administrada, multirregión y multiactiva que puede ofrecer un rendimiento rápido y local, de lectura y de escritura, para aplicaciones globales de escalado masivo. Las tablas globales replican automáticamente las tablas de Amazon DynamoDB en las Regiones de AWS de su elección. No es necesario realizar cambios en la aplicación porque las tablas globales utilizan las API de DynamoDB existentes. No hay costos iniciales ni compromisos por utilizar las tablas globales y solo pagará por los recursos que utilice.

En esta guía se explica cómo utilizar las tablas globales de DynamoDB de forma eficaz. Se proporcionan datos clave sobre las tablas globales, se explican los principales casos de uso de la característica, se describen los dos modos de coherencia, se presenta una taxonomía de tres modelos de escritura diferentes que debe tener en cuenta, se analizan las cuatro opciones principales de enrutamiento de solicitudes que podría implementar, se analizan las formas de evacuar una región activa o una región sin conexión, se explica cómo pensar en la planificación de la capacidad de rendimiento y se proporciona una lista de aspectos que debe tener en cuenta al implementar las tablas globales.

Esta guía se ajusta a un contexto más amplio de las implementaciones multirregión de AWS, tal como se describe en el documento técnico AWS Multi-Region Fundamentals y en el video Data resiliency design patterns with AWS.

Datos clave sobre el diseño de tablas globales de DynamoDB

  • Existen dos versiones de las tablas globales: la versión actual versión 2019.11.21 (actual) de las tablas globales (a veces llamada V2) y Versión 2017.11.29 (heredada) de las tablas globales (a veces llamada V1). Esta guía se centra exclusivamente en la versión actual.

  • DynamoDB (sin tablas globales) es un servicio regional, lo que significa que tiene una alta disponibilidad y es intrínsecamente resistente a los errores de infraestructura, tales como el error de toda una zona de disponibilidad. Una tabla de DynamoDB de una sola región está diseñada para tener una disponibilidad del 99,99 %. Para más información, consulte el acuerdo de nivel de servicio (SLA) de DynamoDB.

  • Una tabla global de DynamoDB replica sus datos entre dos o más regiones. Una tabla de DynamoDB de varias regiones está diseñada para tener una disponibilidad del 99,999 %. Con una planificación adecuada, las tablas globales pueden contribuir a crear una arquitectura que sea resistente a los errores regionales.

  • DynamoDB no dispone de un punto de conexión global. Todas las solicitudes se realizan a un punto de conexión regional que accede a la instancia de tabla global local de esa región.

  • Las llamadas a DynamoDB no deben hacerse entre regiones. Se recomienda que una aplicación que se encuentre en una región acceda de manera directa solo al punto de conexión local de DynamoDB correspondiente a su región. Si se detectan problemas en una región (en la capa de DynamoDB o en la pila circundante), el tráfico de los usuarios finales debe redirigirse a un punto de conexión de aplicación distinto alojado en otra región. Las tablas globales garantizan que la aplicación alojada en todas las regiones tenga acceso a los mismos datos.

Modos de coherencia

Al crear una tabla global, se configura el modo de coherencia. Las tablas globales admiten dos modos de coherencia: coherencia final multirregional (MREC) y coherencia alta multirregional (MRSC) que se ingresó en junio de 2025.

Si no especifica un modo de coherencia al crear una tabla global, esta adoptará de manera predeterminada la MREC. Una tabla global no puede contener réplicas configuradas con distintos modos de coherencia. No puede cambiar el modo de coherencia de una tabla global después de su creación.

Datos clave acerca de la MREC

  • Las tablas globales que utilizan la MRSC emplean un modelo de replicación activa-activa. Desde la perspectiva de DynamoDB, la tabla en cada región tiene la misma capacidad para aceptar solicitudes de lectura y escritura. Después de recibir una solicitud de escritura, la tabla de réplica local replica la operación de escritura en otras regiones remotas participantes en segundo plano.

  • Los elementos se replican de forma individual. Es posible que los elementos que se actualizan en una misma transacción no puedan replicarse juntos.

  • Cada partición de tabla de la región de origen replica sus operaciones de escritura en paralelo con las demás particiones. La secuencia de las operaciones de escritura en la región remota podría no coincidir con la secuencia de las operaciones de escritura que se produjo en la región de origen. Para obtener más información sobre las particiones de tablas, consulte la entrada de blog Escalado de DynamoDB: cómo afectan al rendimiento las particiones, las claves activas y la división por actividad.

  • Un elemento que se acaba de escribir se propagará normalmente a todas las réplicas de tabla en cuestión de segundos. Las regiones cercanas tienden a propagarse más rápido.

  • Amazon CloudWatch proporciona una métrica ReplicationLatency para cada par de regiones. Se calcula mediante la observación de los elementos que llegan, la comparación de su tiempo de llegada con su tiempo de escritura inicial y el cálculo de un promedio. Los tiempos se almacenan en CloudWatch en la región de origen. La visualización de los tiempos medio y máximo puede resultar útil para determinar el retraso medio y en el peor de los casos de la réplica. No hay SLA para esta latencia.

  • Si un elemento individual se actualiza más o menos al mismo tiempo (en este intervalo de ReplicationLatency) en dos regiones distintas y la segunda operación de escritura se produce antes de que se replicara la primera, existe la posibilidad de que se produzcan conflictos de escritura. Las tablas globales que utilizan la MREC resuelven estos conflictos con un mecanismo del último escritor gana, basado en la marca de tiempo de las operaciones de escritura. La primera operación “pierde” frente a la segunda operación. Estos conflictos no se registran en CloudWatch ni en AWS CloudTrail.

  • Cada elemento tiene una marca de tiempo de última escritura que se mantiene como una propiedad de sistema privada. El enfoque del último escritor gana se implementa mediante una operación de escritura condicional que requiere que la marca de tiempo del elemento entrante sea mayor que la marca de tiempo del elemento existente.

  • Una tabla global replica todos los elementos en todas las regiones participantes. Si quiere tener distintos ámbitos de replicación, puede crear varias tablas globales y asignar a cada una distintas regiones participantes.

  • La región local acepta las operaciones de escritura aunque la región de réplica no tenga conexión o crezca ReplicationLatency. La tabla local sigue intentando replicar elementos en la tabla remota hasta que cada elemento lo consigue.

  • En el improbable caso de que una región esté totalmente sin conexión, cuando vuelva a conectarse más tarde, se volverán a intentar todas las réplicas salientes y entrantes pendientes. No es necesaria ninguna acción especial para volver a sincronizar las tablas. El mecanismo del último escritor gana garantiza que, al final, los datos pasan a ser coherentes.

  • En cualquier momento, puede agregar una región nueva a una tabla de la MREC de DynamoDB. DynamoDB gestiona la sincronización inicial y la replicación continua. También puede eliminar una región (incluso la región original), y esto eliminará la tabla local de esa región.

Datos clave acerca de la MRSC

  • Las tablas globales que utilizan la MRSC emplean un modelo de replicación activa-activa. Desde la perspectiva de DynamoDB, la tabla en cada región tiene la misma capacidad para aceptar solicitudes de lectura y escritura. Los cambios de elementos en la réplica de una tabla global de MRSC se replican de manera sincrónica en al menos otra región antes de que la operación de escritura devuelva una respuesta correcta.

  • Las operaciones de lectura altamente coherente en cualquier réplica de MRSC siempre devuelven la versión más reciente de un elemento. Las operaciones de escritura condicionales siempre evalúan la expresión de la condición, ya que la comparan con la versión más reciente de un elemento. Las actualizaciones siempre se llevan a cabo con la última versión de un elemento.

  • Es posible que las operaciones de lectura coherente posterior en una réplica de la MRSC no incluyan los cambios que apenas se hayan producido en otra región y que ni siquiera incluyan los cambios que se produjeron hace muy poco tiempo en la misma región.

  • Una operación de escritura produce un error con una excepción ReplicatedWriteConflictException cuando intenta modificar un elemento que ya se está modificando en otra región. Las operaciones de escritura en las que se produce un error con la excepción ReplicatedWriteConflictException se pueden volver a intentar y se ejecutarán correctamente si el elemento ya no se está modificando en otra región.

  • Con la MRSC, las latencias son más altas para las operaciones de escritura y para las operaciones de lectura altamente coherente. Es necesaria una comunicación entre regiones para estas operaciones. Esta comunicación puede agregar latencia, que aumenta en función de la latencia de ida y vuelta entre la región a la que se accede y la región más cercana que participa en la tabla global. Para más información, consulte la presentación de AWS re:Invent 2024, Multi-Region strong consistency with Amazon DynamoDB global tables. Las operaciones de lectura coherente posterior no tienen latencia adicional. Existe una herramienta de prueba de código abierto que le permite calcular estas latencias de manera experimental con sus regiones.

  • Los elementos se replican de forma individual. Las tablas globales que utilizan la MRSC no admiten las API de transacciones.

  • Una tabla global de MRSC se debe implementar exactamente en tres regiones. Puede configurar una tabla global de MRSC con tres réplicas o con dos réplicas y un testigo. Un testigo es un componente de una tabla global de la MRSC que contiene los datos recientes escritos en las réplicas de las tablas globales. Un testigo proporciona una alternativa opcional a una réplica completa, además de que admite la arquitectura de disponibilidad de la MRSC. No puede realizar operaciones de lectura o escritura en un testigo. Un testigo no genera costos de almacenamiento ni escritura. Un testigo se encuentra en una región distinta de las dos réplicas.

  • Para crear una tabla global de MRSC, agregue una réplica y un testigo o dos réplicas a una tabla de DynamoDB existente que no contenga datos. No puede agregar réplicas adicionales a una tabla global de MRSC existente. No puede eliminar una réplica única o un testigo de una tabla global de la MRSC. Puede eliminar dos réplicas o eliminar una réplica y un testigo de una tabla global de la MRSC. En el segundo escenario se convierte la réplica restante en una tabla de DynamoDB de una sola región.

  • Puede determinar si una tabla global de la MRSC tiene un testigo configurado, y en qué región está configurado, desde la salida de la API DescribeTable. El testigo es responsabilidad de DynamoDB y este lo administra. No aparece en la Cuenta de AWS de la región en la que esté configurado.

  • Las tablas globales de MRSC están disponibles en los siguientes conjuntos de regiones:

    • Conjunto de regiones de EE. UU.: Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Oregón)

    • Conjunto de regiones de la Unión Europea: Europa (Irlanda), Europa (Londres), Europa (París), Europa (Fráncfort)

    • Conjunto de regiones de Asia-Pacífico: Asia-Pacífico (Tokio), Asia-Pacífico (Seúl) y Asia-Pacífico (Osaka).

  • Las tablas globales de la MRSC no pueden abarcar conjuntos de regiones. Por ejemplo, una tabla global de la MRSC no puede contener réplicas de conjuntos de regiones de EE. UU. y de la UE.

  • El Tiempo de vida (TTL) no se admite para las tablas globales de MRSC.

  • Los índices secundarios locales (LSI) no se admiten para las tablas globales MRSC.

  • La información de CloudWatch Contributor Insights solo se comunica para la región en la que se ha producido una operación.

  • La región local acepta todas las operaciones de lectura y escritura siempre y cuando haya una segunda región que aloje una réplica o un testigo para establecer el cuórum. Si una segunda región no está disponible, la región local solo podrá ofrecer operaciones de lectura coherente posterior.

  • En el caso improbable de que una región quede totalmente sin conexión, cuando vuelva a conectarse, se actualizará de manera automática. Hasta que se ponga al día, las operaciones de escritura y las operaciones de lectura altamente coherente solo en la región que se está poniendo al día devolverán errores, mientras que las solicitudes a otras regiones seguirán funcionando con normalidad. Las operaciones de lectura coherente posterior en la región que se está poniendo al día devolverán los datos que hasta ahora se propagaron a la región, con un comportamiento de coherencia local habitual entre el nodo líder y las réplicas locales. No es necesaria ninguna acción especial para volver a sincronizar las tablas.

Casos de uso de tablas globales de DynamoDB de MREC

Las tablas globales de MREC ofrecen los beneficios siguientes:

  • Operaciones de lectura de baja latencia. Coloque una copia de los datos más cerca del usuario final para reducir la latencia de red durante las operaciones de lectura. Los datos se mantienen tan actualizados como el valor de ReplicationLatency.

  • Operaciones de escritura de baja latencia. Puede escribir en una región cercana para reducir la latencia de red y el tiempo necesario para realizar la escritura. El tráfico de escritura debe enrutarse cuidadosamente para garantizar que no haya conflictos. Las técnicas de enrutamiento se describen más detalladamente en Estrategias de enrutamiento de DynamoDB.

  • Migración de región sin problemas. Puede agregar una nueva región y eliminar la antigua para migrar una implementación de una región en otra, todo ello sin tiempo de inactividad en la capa de datos.

Las tablas globales de MREC y MRSC ofrecen este beneficio:

  • Mayor resiliencia y recuperación de desastres. Si el rendimiento de una región ha empeorado o se ha producido una interrupción total, puede evacuarla. Evacuar significa retirar algunas o todas las solicitudes que se dirijan a esa región. El uso de tablas globales aumenta el SLA de DynamoDB respecto del porcentaje de tiempo de actividad mensual del 99,99 % al 99,999 %. El uso de la MREC admite un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) medidos en segundos. El uso de la MRSC admite un RPO igual a cero.

    Por ejemplo, Fidelity Investments presentó en re:Invent 2022 cómo utilizan las tablas globales de DynamoDB para su sistema de administración de pedidos. Su objetivo era lograr un procesamiento con baja latencia de manera fiable a una escala que no podrían alcanzar con el procesamiento en las instalaciones, además de que mantenían la resiliencia ante errores de zona de disponibilidad y de región.

Si el objetivo es la resiliencia y la recuperación ante desastres, las tablas de la MRSC tienen latencias de escritura más altas y latencias de lectura altamente coherentes y más altas, pero admiten un RPO igual a cero. Las tablas globales de MREC admiten un RPO igual al retraso de la replicación entre réplicas, que suele ser de unos pocos segundos, en función de las regiones de las réplicas.

Conclusión y recursos

Las tablas globales de DynamoDB tienen muy pocos controles, aunque todavía es necesario prestarles atención especial. Debe determinar su modo de escritura, el modelo de enrutamiento y los procesos de evacuación. Debe instrumentar la aplicación en todas las regiones y estar preparado para ajustar el enrutamiento o realizar una evacuación para mantener el estado global. La recompensa es disponer de un conjunto de datos distribuidos de manera global con operaciones de lectura y escritura de baja latencia y diseñado para una disponibilidad del 99,999 %.

Para más información acerca de las tablas globales de DynamoDB, consulte los recursos siguientes: