Tablas globales: cómo funcionan
En las siguientes secciones, se describen los conceptos y el comportamiento de las tablas globales en Amazon DynamoDB.
Conceptos de las tablas globales
Una tabla global es una colección de una o más réplicas de tabla, propiedad de una única cuenta de AWS.
Una réplica de tabla (o réplica) es una única tabla de DynamoDB que funciona como una parte de una tabla global. Cada réplica almacena el mismo conjunto de elementos de datos. Cualquier tabla global solo puede tener una réplica de tabla por región de AWS. Para obtener más información sobre cómo empezar a usar tablas globales, consulte Tutorial: Creación de una tabla global.
Al crear una tabla global de DynamoDB, se compone de varias réplicas de tablas (una por región) que DynamoDB considera como una única unidad. Cada réplica tiene el mismo nombre de tabla y el mismo esquema de clave primaria. Cuando una aplicación escribe datos en una réplica de tabla de una región, DynamoDB propaga automáticamente la operación de escritura en el resto de las réplicas de tabla de las otras regiones de AWS.
Puede agregar réplicas de tablas a la tabla global para que esté disponible en otras regiones.
Con la versión 2019.11.21 (actual), al crear un índice secundario global en una región, este se replica automáticamente en las demás regiones y se rellena automáticamente.
Tareas comunes
Las tareas comunes de las tablas globales funcionan de la siguiente manera.
Puede eliminar la tabla de réplica de una tabla global de la misma manera que una tabla normal. Esto detendrá la replicación en esa región y eliminará la copia de la tabla guardada en dicha región. No puede separar la replicación y tener copias de la tabla que existan como entidades independientes. Puede copiar la tabla global en una tabla local de esa región y, a continuación, eliminar la réplica global de dicha región.
nota
No podrá eliminar una tabla de origen hasta que transcurran al menos 24 horas desde que se haya utilizado para iniciar una nueva región. Si intenta eliminarla demasiado pronto, se producirá un error.
Pueden surgir conflictos si las aplicaciones actualizan el mismo elemento en diferentes regiones aproximadamente al mismo momento. Para garantizar la coherencia final, las tablas globales de DynamoDB usan el método “el último escritor gana”. Todas las réplicas estarán de acuerdo con la última actualización y convergerán en un estado en el cual todas tienen datos idénticos.
nota
Existen varias maneras de evitar los conflictos, entre las que se incluyen:
Solo se permiten escrituras en la tabla de una región.
Enrute el tráfico de usuarios a diferentes regiones de acuerdo con sus políticas de escritura, para garantizar que no haya conflictos.
Evitar el uso de actualizaciones no idempotentes, como Bookmark = Bookmark + 1, en favor de actualizaciones estáticas como Bookmark=25.
Tenga en cuenta que, cuando enrute escrituras o lecturas a una sola región, su aplicación es la que debe asegurarse de que se aplica ese flujo.
Monitoreo de tablas globales
Puede utilizar CloudWatch para observar la métrica ReplicationLatency. Realiza un seguimiento del tiempo transcurrido entre el momento en que un elemento se escribe en una tabla de réplica y el momento en que ese elemento aparece en otra réplica de la tabla global. Se expresa en milisegundos y se emite para cada uno de los pares de región-origen y región-destino. Esta métrica se mantiene en la región de origen. Esta es la única métrica de CloudWatch que proporciona la versión 2 de las tablas globales.
La latencia de replicación que se experimente dependerán de la distancia entre las Regiones de AWSelegidas, así como de otras variables. Si la tabla original estaba en la región Oeste de EE. UU. (Norte de California) (us-west-1), una réplica en una región más cercana, como la región Oeste de EE. UU. (Oregón) (us-west-2), tendría una latencia de replicación más baja en comparación con una réplica en una región mucho más alejada, como la región África (Ciudad del Cabo) (af-south-1).
nota
La latencia de replicación no afecta a la latencia de la API. Si tiene un cliente y una tabla en la región A y agrega una réplica de tablas globales en la región B, el cliente y la tabla de la región A tendrán la misma latencia que antes de agregar la región B. Si llama a la operación de la API PutItem en la región B, se podrá leer en la región A tras un retardo equivalente aproximadamente a la estadística ReplicationLatency disponible en Amazon CloudWatch. Antes de que se replique, recibirás una respuesta vacía y, una vez replicado, recibirás el elemento; ambas llamadas tendrán aproximadamente la misma latencia de la API.
Tiempo de vida (TTL)
Puede utilizar el tiempo de vida (TTL) para especificar un nombre de atributo cuyo valor indique el tiempo de caducidad del elemento. Este valor se indica como un número en segundos desde el inicio del tiempo Unix. Transcurrido ese tiempo, DynamoDB puede eliminar el elemento sin incurrir en costos de escritura.
Con las tablas globales, se configura TTL en una región y esa configuración se replica automáticamente en las demás regiones. Cuando se elimina un elemento mediante una regla de TTL, ese trabajo se realiza sin consumir unidades de escritura en la tabla de origen, pero las tablas de destino incurrirán en costos de unidades de escritura replicadas.
Tenga en cuenta que si las tablas de origen y destino tienen capacidades de escritura aprovisionadas muy bajas, se podría producir una limitación, ya que las eliminaciones de TTL requieren capacidad de escritura.
Flujos y transacciones con tablas globales
Cada tabla global produce un flujo independiente basado en todas sus escrituras, independientemente del punto de origen de dichas escrituras. Puede optar por consumir este flujo de DynamoDB en una región o en todas las regiones de forma independiente.
Si desea procesar escrituras locales pero no escrituras replicadas, puede agregar su propio atributo de región a cada elemento. A continuación, puede utilizar un filtro de eventos de Lambda para invocar únicamente a Lambda para las escrituras en la región local.
Las operaciones transaccionales proporcionan garantías ACID (atomicidad, uniformidad, aislamiento y durabilidad) solo en la región en la que se crea la escritura originalmente. No se admiten las transacciones entre regiones en las tablas globales.
Por ejemplo, si tiene una tabla global con réplicas en las regiones Este de EE. UU. (Ohio) y Oeste de EE. UU. (Oregón) y realiza una operación TransactWriteItems en la región Este de EE. UU. (Ohio), puede observar transacciones completadas parcialmente en la región Oeste de EE. UU. (Oregón) a medida que los cambios se replican. Solo se replicarán los cambios en otras regiones cuando se hayan confirmado en la región de origen.
nota
Las tablas globales “sustituyen” a Acelerador de DynamoDB al actualizar DynamoDB directamente. Como resultado, DAX no sabrá que contiene datos obsoletos. La memoria caché de DAX solo se actualizará cuando caduque el TTL de la memoria caché.
Las etiquetas de las tablas globales no se propagan automáticamente.
Rendimiento de lectura y escritura
Las tablas globales administran el rendimiento de lectura y escritura de las siguientes maneras.
La capacidad de escritura debe ser la misma en todas las instancias de tabla en todas las regiones.
Con la versión 2019.11.21 (actual), si la tabla está configurada para admitir el escalado automático o está en el modo bajo demanda, la capacidad de escritura se mantiene sincronizada automáticamente. Esto significa que un cambio en la capacidad de escritura de una tabla se replica en las demás.
La capacidad de lectura puede diferir de una región a otra porque las lecturas pueden no ser iguales. Al agregar una réplica global a una tabla, se propaga la capacidad de la región de origen. Tras la creación, puede ajustar la capacidad de lectura de una réplica y esta nueva configuración no se transferirá al otro lado.
Coherencia y resolución de conflictos
Cualquier cambio en cualquier elemento de cualquier réplica de tabla se replicará en el resto de réplicas en la misma tabla global. En una tabla global, un elemento que se acaba de escribir se propagará normalmente a todas las réplicas de tabla en cuestión de segundos.
Con una tabla global, cada réplica de tabla almacena el mismo conjunto de elementos de datos. DynamoDB no admite la replicación parcial de solo algunos de los elementos.
Una aplicación puede leer y escribir datos en cualquier réplica de tabla. Si la aplicación solo utiliza operaciones de lectura eventualmente consistentes y solo realiza operaciones de lectura en una región de AWS, funcionará sin ninguna modificación. Sin embargo, si la aplicación requiere operaciones de lectura consistente alta, debe realizar todas las operaciones de escritura y lectura consistente alta en la misma región. DynamoDB no admite lecturas altamente coherentes en todas las regiones. Por lo tanto, si realiza una escritura en una región y una lectura en otra, es posible que la respuesta de la lectura incluya datos anticuados que no reflejen los resultados de las operaciones de escritura completadas recientemente en la otra región.
Pueden surgir conflictos si las aplicaciones actualizan el mismo elemento en diferentes regiones aproximadamente al mismo momento. Para garantizar la consistencia final, las tablas globales de DynamoDB usan la reconciliación gana quien escribe último entre las actualizaciones simultáneas. DynamoDB hace todo lo posible para determinar quién realizó la última escritura. Esto se realiza en el nivel de elemento. Con este mecanismo de resolución de conflictos, todas las réplicas estarán de acuerdo con la última actualización y convergerán en un estado en el cual todas tienen datos idénticos.
Disponibilidad y durabilidad
Si una única región de AWS se encuentra aislada o degradada, la aplicación puede redirigir a otra región y realizar las operaciones de lectura y escritura en una réplica de tabla diferente. Puede aplicar una lógica empresarial personalizada para determinar cuándo deben redirigirse solicitudes a otras regiones.
Si una región se queda aislada o se degrada, DynamoDB realiza un seguimiento de las escrituras que se han realizado pero que no se han propagado a todas las tablas de réplica. Cuando la región vuelva a estar en línea, DynamoDB reanudará la propagación de cualquier operación de escritura pendiente desde esa región a las réplicas de tabla en otras regiones. Asimismo, reanudará la propagación de las escrituras desde otras tablas de réplica a la región que ahora vuelve a estar en línea.
