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

El modo de escritura de escritura en cualquier región es totalmente activo/activo y no impone restricciones sobre dónde puede realizarse una operación de escritura. Cualquier región puede aceptar una solicitud por escrito en cualquier momento. Este es el modo más sencillo; sin embargo, solo se puede utilizar con algunos tipos de aplicaciones. Es adecuado cuando todas las operaciones de escritura son idempotentes. Idempotentes significa que se pueden repetir de forma segura para que las operaciones de escritura simultáneas o repetidas en 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 que solo admite anexos, en el que todas las operaciones de escritura son inserciones únicas bajo una clave primaria determinista, lo que es un caso especial de idempotencia. Por último, este modo es adecuado cuando el riesgo de operaciones de escritura conflictivas es 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 sencilla, ya que cualquier operación de escritura reciente se puede 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 vídeo utilizan tablas globales para hacer un seguimiento de los marcadores, las reseñas, los indicadores de estado de las reproducciones, etc. Estas implementaciones pueden utilizar el modo de escritura en cualquier región siempre que garanticen que cada operación de escritura sea idempotente. Este será el caso si cada actualización (por ejemplo, establecer un nuevo código de última hora, asignar una nueva reseña o establecer un nuevo estado de observación) asigna directamente el nuevo estado del usuario y el siguiente valor correcto de un artículo no depende de su valor actual. Si, por casualidad, las solicitudes de escritura del usuario se dirigen a diferentes regiones, la última operación de escritura persistirá y el estado global se establecerá de acuerdo con la última asignación. Con el tiempo, las operaciones de lectura en este modo se volverán consistentes 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. Las nuevas transacciones llegan de todo el mundo y se envían a varias regiones. Esta firma pudo utilizar el modo de escritura en cualquier región con un cuidadoso rediseño. El boceto de diseño inicial mantuvo un solo RunningBalance artículo por cliente. Las acciones de los clientes actualizaron el saldo con una ADD expresión, que no es idempotente (porque el nuevo valor correcto depende del valor actual), y el saldo se desincronizaba si había dos operaciones de escritura en el mismo saldo aproximadamente a la misma hora en diferentes regiones. El rediseño utiliza la transmisión de eventos, que funciona como un libro de contabilidad con un flujo de trabajo que solo incluye anexos. Cada acción de cliente añade un nuevo elemento a la colección de elementos que se mantiene para ese cliente. (Una colección de elementos es el conjunto de elementos que comparten una clave principal pero tienen diferentes claves de clasificación). Cada operación de escritura es una inserción idempotente que utiliza el ID del cliente como clave de partición y el ID de transacción como clave de clasificación. Este diseño dificulta el cálculo del equilibrio porque requiere extraer los elementos seguidos de algunos cálculos del lado del cliente, pero hace que todas las operaciones de escritura sean idempotentes y logra simplificaciones significativas en el enrutamiento y la conmutación por error. Query (Esto se describe más detalladamente en más detalladamente en más detalladamente en más detalladamente en más detalladamente en más detalladamente

Un tercer ejemplo es el de una empresa que ofrece servicios de colocación de anuncios en línea. Esta empresa decidió que sería aceptable un bajo riesgo de pérdida de datos para lograr las simplificaciones de diseño del modo de escritura en cualquier región. Cuando publican anuncios, solo tienen unos pocos milisegundos para recuperar los metadatos suficientes para determinar qué anuncio mostrar y, a continuación, registrar la impresión del anuncio para no repetir el mismo anuncio pronto. Utilizan tablas globales para obtener operaciones de lectura de baja latencia para 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 añadirlo a una colección de elementos, por lo que pueden eliminar las impresiones de anuncios más antiguas 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 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. El riesgo es que un usuario vea un anuncio repetido de vez en cuando. Decidieron que esto es aceptable.