Modos de escritura con tablas globales
Las tablas globales son siempre activas-activas en el nivel de tabla. No obstante, es recomendable tratarlas como activas-pasivas mediante el control del enrutamiento de las solicitudes de escritura. Por ejemplo, puede decidir enrutar las solicitudes de escritura a una sola región para evitar posibles conflictos de escritura.
Existen tres categorías principales de patrones de escritura administrados:
Modo de escritura en cualquier región (no principal)
Modo de escritura en una región (principal único)
Modo de escritura en su región (principal mixto)
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. En general, las prácticas recomendadas pueden variar en función 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 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. Solo se puede utilizar con algunos tipos de aplicaciones. Resulta adecuado 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 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 cualquier escritura reciente puede reproducirse 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, los servicios de streaming de vídeo suelen utilizar tablas globales para el seguimiento de marcadores, reseñas, marcas de estado de observación, etc. Estas implementaciones pueden utilizar el modo de escritura en cualquier región siempre que garanticen que cada escritura es idempotente y que el siguiente valor correcto de un elemento no depende de su valor actual. Esto ocurrirá con las actualizaciones de usuario que asignen directamente el nuevo estado del usuario, como establecer un nuevo código de última hora, asignar una nueva revisión o establecer un nuevo estado de observación. Si las solicitudes de escritura del usuario se enrutan a diferentes regiones, 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, tras retrasarse 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. Las nuevas transacciones llegan de todo el mundo y se envían a varias regiones. Para su diseño actual, que no aprovecha las tablas globales, utiliza un único elemento RunningBalance por cliente. Las acciones del cliente actualizan el saldo con una expresión AGREGAR, que no es idempotente porque el nuevo valor correcto depende del valor actual. Esto significa que el saldo no estaba sincronizado si se producían dos operaciones de escritura en el mismo saldo más o menos al mismo tiempo en distintas regiones.
Esta misma empresa podría conseguir un modo de escritura en cualquier región mediante un cuidadoso rediseño con las tablas globales de DynamoDB. El nuevo diseño podría seguir un modelo de “streaming de eventos”, fundamentalmente un libro mayor con un flujo de trabajo de solo adición. Cada acción de cliente añade un nuevo elemento a la colección de elementos que se mantiene para ese cliente. La colección de elementos es el conjunto de elementos que comparten una clave principal con diferentes claves de clasificación. Cada acción de escritura que anexa la acción de cliente es una inserción idempotente, que utiliza el ID de cliente como clave de partición y el ID de transacción como clave de clasificación. Este diseño complica más el cálculo del saldo, ya que requiere una Query para extraer los elementos seguida de algunos cálculos matemáticos en el cliente. Pero la ventaja es que convierte todas las escrituras en idempotentes, lo que proporciona importantes simplificaciones de enrutamiento y de conmutación por error. Para obtener más información, consulte Solicitud de enrutamiento con tablas globales.
En un tercer ejemplo, supongamos que hay un cliente que presenta anuncios en línea. Ha decidido 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 sirve anuncios, solo dispone de unos milisegundos para recuperar los metadatos suficientes para determinar qué anuncio se mostrará y, a continuación, registrar la impresión del anuncio para que no se repita el mismo anuncio a ese usuario. Con las tablas globales puede conseguir tanto lecturas de baja latencia para los usuarios finales en todo el mundo como escrituras de baja latencia. Puede registrar todas las impresiones de anuncios de un usuario en un solo elemento y representarla como una lista que va aumentando. Puede utilizar un elemento en lugar de agregarlo a una colección de elementos, ya que, de este modo, puede eliminar las impresiones de anuncios más antiguas como parte de cada escritura sin tener que pagar por eliminarlas. Esta operación de escritura NO es idempotente, por lo que, si el mismo usuario final ve anuncios servidos desde varias regiones aproximadamente al mismo tiempo, existe la posibilidad de que una escritura de impresión de anuncios sobrescriba la otra. En el caso de la presentación de anuncios en línea, merece la pena contar con este diseño más sencillo y eficaz aunque exista el riesgo de que un usuario vea ocasionalmente un anuncio repetido.
Principal único (“escritura en una región”)
El modo de escritura en una región es activo-pasivo y enruta todas las escrituras de tabla 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 evita conflictos de escritura al garantizar que las escrituras solo fluyan a una región cada vez. Este modo de escritura es útil cuando desee utilizar expresiones o transacciones condicionales, ya que no funcionarán a menos que sepa que está actuando con los datos más recientes. Por lo tanto, el uso de expresiones y transacciones condicionales requiere enviar todas las solicitudes de escritura a la región con los datos más recientes.
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, para ayudar con los datos. Evacuación de una región con tablas globales es un ejemplo de este caso de uso. Algunos clientes cambiarán la región activa según una programación periódica, como una implementación del tipo “seguir el sol”. De este modo, la región activa se sitúa cerca de la ubicación geográfica con más actividad, lo que le proporciona las lecturas y las escrituras de latencia más baja. También tiene el beneficio secundario de llamar diariamente la ruta de código que cambia de región, con lo que se garantiza que está bien probada antes de cualquier recuperación de 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. Si desea un análisis más profundo de los diseños de luz piloto y espera activa, consulte Arquitectura de recuperación de desastres (DR) en AWS, parte III: luz piloto y espera activa
El uso del modo de escritura en una región funciona bien cuando se aprovechan las tablas globales para realizar lecturas distribuidas globalmente de baja latencia. Por ejemplo, una gran empresa de redes sociales tiene millones de usuarios y miles de millones de publicaciones. A cada usuario se le asigna una región en el momento de crear la cuenta, situada geográficamente cerca de su ubicación. En esa tabla no global están todos sus datos. La empresa utiliza una tabla global independiente para mantener la asignación de usuarios a sus regiones de origen, mediante un modo de escritura en una región. Mantiene copias de solo lectura en todo el mundo como ayuda para localizar directamente los datos de cada usuario con la mínima latencia agregada. Las actualizaciones son muy poco frecuentes (solo cuando se mueve de una a otra la región de origen de un usuario) y siempre se escriben en una región para evitar la posibilidad de conflictos de escritura.
Otro ejemplo es el de un cliente de servicios financieros que ha implementado un cálculo diario de devoluciones en efectivo. Utiliza el modo de escritura en cualquier región para calcular el saldo, pero emplea el modo de escritura en una región para realizar el seguimiento de los reembolsos en efectivo. Si quiere recompensar a un cliente con 1 céntimo por cada 10 USD gastados al día, tendrá que usar Query para consultar todas las transacciones del día anterior, calcular el total gastado, escribir la decisión de devolución en una nueva tabla, eliminar el conjunto de elementos consultados para marcarlos como consumidos y reemplazarlos por un solo elemento que almacene cualquier cantidad restante que deba incluirse en los cálculos del día siguiente. Este trabajo requiere transacciones, por lo que funcionará mejor con el modo de escritura en una región. Una aplicación puede combinar modos de escritura, incluso en la misma tabla, siempre que no haya posibilidad de que las cargas de trabajo se solapen.
Principal mixta (“escritura en su región”)
El modo de escritura en su región asigna diferentes subconjuntos de datos a distintas regiones y permite operaciones de escritura solo en los elementos a través de su región de origen. Este modo es activo-pasivo pero asigna la región activa en función del elemento. Cada región es principal para su propio conjunto de datos que no se solapan y las escrituras deben protegerse para garantizar una ubicación adecuada.
Este modo es similar al de escritura en una región, con la excepción de que permite escrituras de menor latencia, ya que los datos asociados a cada usuario final pueden colocarse en una proximidad de red más cercana a dicho usuario. También distribuye la infraestructura circundante de forma más uniforme entre las regiones y requiere menos trabajo para crear la infraestructura durante un escenario de conmutación por error, porque todas las regiones tendrán una parte de su infraestructura ya activa.
Determinar la región de origen de los elementos puede hacerse de varios modos:
Intrínseco: algún aspecto de los datos deja claro cuál es la región de origen, como su clave de partición. Por ejemplo, un cliente y todos los datos sobre ese cliente se marcarían en los datos del cliente como ubicados en una región determinada. Esta técnica se describe en Uso de la asignación de regiones a fin de establecer una región de origen para los elementos de una tabla global de Amazon DynamoDB
. Negociado: la región de origen de cada conjunto de datos se negocia de manera externa, por ejemplo, con un servicio global independiente que mantiene las asignaciones. La asignación puede tener una duración finita, tras la cual está sujeta a renegociación.
Orientado a tablas: en lugar de tener una sola tabla global de replicación, hay tantas tablas globales como regiones de replicación. El nombre de cada tabla indica su región de origen. En las operaciones estándar, todos los datos se escriben en la región de origen, mientras que las demás regiones conservan una copia de solo lectura. Durante una conmutación por error, otra región adoptará temporalmente las tareas de escritura para esa tabla.
Por ejemplo, supongamos que trabaja para una empresa de juegos. Necesita lecturas y escrituras de baja latencia para todos los jugadores del mundo. Puede ubicar a cada jugador en la región más cercana a él. Esa región recibe todas sus lecturas y escrituras, lo que garantiza que siempre haya una sólida coherencia de lectura tras escritura. Sin embargo, si ese jugador viaja o su región de origen sufre una interrupción, habrá una copia completa de sus datos disponible en otras regiones. Por lo tanto, se puede asignar al jugador a otra región de origen, según sea útil.
Otro ejemplo: imagine que trabaja en una empresa de videoconferencias. Los metadatos de cada llamada de conferencia se asignan a una región concreta. Quienes llamen pueden usar 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 rápida recuperación 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.
