Modos de escritura con tablas globales de DynamoDB

Las tablas globales son siempre activas-activas en el nivel de tabla. No obstante, en especial para las tablas de la MREC, es conveniente tratarlas como activas-pasivas mediante el control del enrutamiento de las solicitudes de escritura. Por ejemplo, podría decidir enrutar las solicitudes de escritura a una sola región para evitar posibles conflictos de escritura que puedan producirse con las tablas de MREC.

Hay tres patrones principales de escritura administrada, como se explica en las tres secciones siguientes. Debe considerar qué patrón de escritura se ajusta a su caso de uso. Esta elección afecta a la forma de enrutar las solicitudes, evacuar una región y gestionar la recuperación de desastres. La guía de las secciones posteriores depende del modo de escritura de la aplicación.

Modo de escritura en cualquier región (no principal)

El modo de escritura en cualquier región (que se ilustra en el diagrama siguiente) es totalmente activo-activo y no impone restricciones sobre dónde puede producirse una escritura. Cualquier región puede aceptar una escritura en cualquier momento. Este es el modo más sencillo. Pero solo se puede utilizar con algunos tipos de aplicaciones. Este modo es adecuado para todas las tablas de la MRSC. Resulta también adecuado para las tablas de MREC cuando todos los escritores son idempotentes y, por lo tanto, repetibles de forma segura para que las operaciones de escritura simultáneas o repetidas en las distintas regiones no entren en conflicto. Por ejemplo, cuando un usuario actualiza sus datos de contacto. Este modo también sirve para un caso especial de ser idempotente, un conjunto de datos de solo adición en el que todas las escrituras son inserciones únicas con una clave principal determinista. Por último, este modo resulta adecuado para MREC cuando el riesgo de escrituras en conflicto sea aceptable.

El modo de escritura en cualquier región es la arquitectura más sencilla de implementar. El enrutamiento es más sencillo porque cualquier región puede ser el destino de escritura en cualquier momento. La conmutación por error es más fácil, porque con las tablas de la MRSC, los elementos siempre están sincronizados y, con las tablas de la MRSC, las escrituras recientes se pueden reproducir cualquier número de veces en cualquier región secundaria. Siempre que sea posible, debe efectuar el diseño para este modo de escritura.

Por ejemplo, varios servicios de transmisión de video utilizan tablas globales para hacer el seguimiento de marcadores, reseñas, marcas de estado de observación, etc. Estas implementaciones utilizan tablas de MREC porque necesitan réplicas repartidas por todo el mundo. Cada réplica proporciona operaciones de lectura y escritura de baja latencia. Estas implementaciones pueden utilizar el modo de escritura en cualquier región siempre y cuando que garanticen que todas las operaciones de escritura sean idempotentes. Esto ocurrirá si todas las actualizaciones (por ejemplo, establecer un código nuevo de última hora, asignar una revisión nueva o establecer un estado de observación nuevo) asignan de manera directa el nuevo estado del usuario y el siguiente valor correcto de un elemento no depende de su valor actual. Si, por casualidad, las solicitudes de escritura del usuario se enrutan a regiones distintas, la última operación de escritura persistirá y el estado global se establecerá de acuerdo con la última asignación. Las operaciones de lectura en este modo acabarán siendo coherentes, retrasadas según el último valor de ReplicationLatency.

En otro ejemplo, una empresa de servicios financieros utiliza tablas globales como parte de un sistema para mantener un recuento continuo de las compras con tarjeta de débito de cada cliente, con el fin de calcular las recompensas en efectivo de ese cliente. Quieren conservar un elemento RunningBalance por cliente. Por naturaleza, este modo de escritura no es idempotente porque, a medida que llegan las transacciones, modifican el saldo mediante una expresión ADD en la que el nuevo valor correcto depende del valor actual. Al utilizar las tablas de la MRSC, pueden seguir escribiendo en cualquier región, ya que cada llamada de ADD siempre funciona con el valor más reciente del elemento.

Un tercer ejemplo es el de una empresa que ofrece servicios de publicación de anuncios en línea. Esta empresa decidió que sería aceptable un bajo riesgo de pérdida de datos para conseguir las simplificaciones de diseño del modo de escritura en cualquier región. Cuando publican anuncios, solo disponen de unos milisegundos para recuperar los metadatos suficientes para determinar qué anuncio mostrar y, a continuación, registrar la impresión del anuncio para que no se repita el mismo anuncio en breve. Utilizan tablas globales para obtener operaciones de lectura de baja latencia para los usuarios finales de todo el mundo y operaciones de escritura de baja latencia. Registran todas las impresiones de anuncios de un usuario en un solo elemento, que se representa como una lista creciente. Utilizan un elemento en lugar de agregarlo a una colección de elementos, por lo que pueden eliminar impresiones de anuncios anteriores como parte de cada operación de escritura sin tener que pagar por una operación de eliminación. Esta operación de escritura no es idempotente. Si el mismo usuario final ve anuncios publicados desde varias regiones casi al mismo tiempo, existe la posibilidad de que una operación de escritura para una impresión de anuncios sobrescriba otra. El riesgo es que un usuario podría ver un anuncio repetido de vez en cuando. Decidieron que es aceptable.

Escritura en una región (única principal)

El modo de escritura en una región, que se muestra en el diagrama siguiente, es activo-pasivo y enruta todas las escrituras de tablas a una sola región activa. Tenga en cuenta que DynamoDB no tiene la noción de una única región activa; el enrutamiento de la aplicación fuera de DynamoDB administra esta situación. El modo de escritura en una región funciona bien para las tablas de MREC que deben evitar conflictos de escritura, ya que garantiza que las operaciones de escritura fluyan solo a una región a la vez. Este modo de escritura es útil cuando quiere utilizar expresiones condicionales y no puede utilizar la MRSC por algún motivo, o cuando debe hacer transacciones. Estas expresiones no son posibles a menos que se sepa que se están procesando los datos más recientes, por lo que es necesario enviar todas las solicitudes de escritura a una sola región que tenga los datos más recientes.

Cuando utilice una tabla de MRSC, puede optar por escribir en general en una región para mayor practicidad. Por ejemplo, esto puede ayudar a minimizar la ampliación de la infraestructura más allá de DynamoDB. El modo de escritura seguiría siendo escribir en cualquier región, ya que con la MRSC se puede escribir de manera segura en cualquier región en cualquier momento sin preocuparse por la resolución de conflictos que haría que las tablas de la MREC eligieran escribir en una región.

Las lecturas coherentes posteriores pueden ir a cualquier región de réplica para obtener latencias más bajas. Las lecturas altamente coherentes deben ir a la única región principal.

A veces, es necesario cambiar la región activa en respuesta a un error regional. Algunos usuarios cambian la región activa en ese momento de manera periódica, por ejemplo, como una implementación del tipo seguir el sol. Esto sitúa la región activa cerca de la zona geográfica con mayor actividad (suele ser donde es de día, de ahí el nombre), lo que supone una latencia mínima en las operaciones de lectura y escritura. También tiene el otro beneficio de llamar al código de cambio de región a diario y garantizar que se haya probado correctamente antes de que haya que realizar una recuperación ante desastres.

Las regiones pasivas pueden mantener un conjunto reducido de infraestructura en torno a DynamoDB que se crea solo si se convierte en la región activa. En esta guía no se abordan los diseños de llama piloto y espera activa. Para obtener más información, consulte Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby.

El modo de escritura en una región funciona bien cuando se utilizan tablas globales para operaciones de lectura distribuidas de manera global y con baja latencia. Un ejemplo es una empresa grande de redes sociales que necesita tener los mismos datos de referencia disponibles en todas las regiones del mundo. No actualizan los datos con frecuencia, pero cuando los actualizan, escriben solo en una región para evitar posibles conflictos de escritura. Las operaciones de lectura siempre se permiten desde cualquier región.

Tomemos como otro ejemplo la empresa de servicios financieros mencionada anteriormente que implementó el cálculo diario de devoluciones en efectivo. Utilizaban el modo de escritura en cualquier región para calcular el saldo, pero utilizaban el modo de escritura en una región para hacer el seguimiento de los pagos. Para ello hay que hacer transacciones, que no son compatibles con las tablas de la MRSC, así que funciona mejor con una tabla de la MREC independiente y el modo de escritura a una región.

Escritura en la región (principal mixta)

El modo de escritura en su región, que se ilustra en el diagrama siguiente, funciona con las tablas de la MREC. Asigna distintos subconjuntos de datos a distintas regiones de origen y permite hacer operaciones de escritura en un elemento solo a través de su región de origen. Este modo es activo-pasivo, pero asigna la región activa según el elemento. Cada región es la principal para su propio conjunto de datos no superpuesto. Las operaciones de escritura deben protegerse para garantizar una ubicación adecuada.

Este modo es similar a escribir en una región, salvo que permite operaciones de escritura con menor latencia, ya que los datos asociados a cada usuario pueden colocarse en una red más cercana a dicho usuario. También distribuye la infraestructura circundante de manera más uniforme entre las regiones y es necesario menos trabajo para crear la infraestructura durante un escenario de conmutación por error, porque todas las regiones tienen una parte de su infraestructura ya activa.

Puede determinar la región de origen de los elementos de varias maneras:

Por ejemplo, imagine que trabaja para una empresa de juegos. Necesita operaciones de lectura y escritura de baja latencia para todos los jugadores del mundo. Asigna a cada jugador a la región más cercana a este. Esa región se encarga de todas sus operaciones de lectura y escritura, lo que garantiza una coherencia alta entre las operaciones de lectura y escritura. Sin embargo, cuando un jugador viaja o si su región de origen sufre una interrupción del servicio, hay una copia completa de sus datos disponible en regiones alternativas, y se le puede asignar al jugador una región de origen distinta.

Por poner otro ejemplo, imagine que trabaja en una empresa de videoconferencias. Los metadatos de cada conferencia telefónica se asignan a una región concreta. Quienes llamen pueden utilizar la región más cercana para obtener la latencia más baja. Si se produce una interrupción en una región, el uso de tablas globales permite una recuperación rápida porque el sistema puede trasladar el procesamiento de la llamada a otra región en la que ya exista una copia replicada de los datos.