Modo de escritura en cualquier región (no principal) - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

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

El modo de escritura en cualquier región, que se ilustra en el siguiente diagrama, es totalmente activo-activo y no impone restricciones en cuanto al lugar en el que se puede realizar una operación de escritura. Cualquier región puede aceptar una solicitud de escritura en cualquier momento. Este es el modo más simple; sin embargo, solo se puede usar con algunos tipos de aplicaciones. Este modo es adecuado para todas las tablas MRSC. También es adecuado para tablas MREC cuando todas las operaciones de escritura son idempotentes. Idempotentes significa que se pueden repetir de forma segura, de modo que las operaciones de escritura simultáneas o repetidas en todas las regiones no entren en conflicto, por ejemplo, cuando un usuario actualiza sus datos de contacto. También funciona bien para un conjunto de datos solo anexado en el que todas las operaciones de escritura son inserciones únicas bajo una clave principal determinista, lo que constituye un caso especial de idempotencia. Por último, este modo es adecuado para MREC, donde el riesgo de operaciones de escritura conflictivas es aceptable.

No hay modo de escritura principal en las tablas globales de DynamoDB.

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, ya que en las tablas MRSC los elementos están siempre sincronizados y, en las tablas MREC, cualquier operación de escritura reciente se puede reproducir el número de veces que se desee en cualquier región secundaria. Siempre que sea posible, debe efectuar el diseño para este modo de escritura.

Por ejemplo, varios servicios de streaming de vídeo utilizan tablas globales para realizar un seguimiento de los marcadores, las reseñas, los indicadores de estado de las reproducciones, etc. Estas implementaciones utilizan tablas MREC porque necesitan réplicas repartidas por todo el mundo, y 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 que garanticen que todas las operaciones de escritura sean idempotentes. Este será el caso si cada actualización (por ejemplo, si se establece un nuevo código de tiempo más reciente, se asigna una nueva opinión o se establece un nuevo estado de visualización) se asigna directamente 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 redirigen a distintas regiones, la última operación de escritura persistirá y el estado global se liquidará en función de la última asignación. Las operaciones de lectura en este modo acabarán siendo coherentes y se retrasarán según el último ReplicationLatency valor.

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 RunningBalance artículo por cliente. Este modo de escritura no es idempotente por naturaleza, ya que, a medida que las transacciones fluyen, modifican el saldo mediante una ADD expresión en la que el nuevo valor correcto depende del valor actual. Al usar tablas MRSC, pueden seguir escribiendo en cualquier región, ya que cada ADD llamada siempre funciona con el valor más reciente del artículo.

Un tercer ejemplo es el de una empresa que ofrece servicios de colocación de anuncios en línea. Esta empresa decidió que un bajo riesgo de pérdida de datos sería aceptable para lograr las simplificaciones de diseño del modo de escritura a cualquier región. Cuando publican anuncios, solo disponen de unos pocos milisegundos para recuperar los metadatos suficientes para determinar qué anuncio mostrar y, a continuación, registrar la impresión del anuncio para que no repitan el mismo anuncio pronto. Utilizan tablas globales para realizar 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 único elemento, que se representa como una lista creciente. Utilizan un elemento en lugar de añadirlo a una colección de artículos, por lo que pueden eliminar las impresiones de anuncios antiguas como parte de cada operación de redacción 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 en varias regiones aproximadamente al mismo tiempo, existe la posibilidad de que una operación de escritura para una impresión de anuncio sobrescriba a otra. Existe el riesgo de que un usuario vea un anuncio repetido de vez en cuando. Decidieron que esto es aceptable.