Modelos de consistencia DAX y DynamoDB - Amazon DynamoDB

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.

Modelos de consistencia DAX y DynamoDB

El acelerador de Amazon DynamoDB (DAX) es un servicio de almacenamiento en caché de escritura indirecta (write-through), diseñado para simplificar el proceso de agregar una caché a las tablas de DynamoDB. Dado que DAX funciona por separado de DynamoDB, es importante comprender los modelos de consistencia de DAX y de DynamoDB para conseguir que sus aplicaciones se comporten como se espera de ellas.

En muchos casos de uso, la forma de usar DAX en la aplicación afecta a la consistencia de datos en el clúster de DAX y a la consistencia de datos entre DAX y DynamoDB.

Consistencia entre los nodos de los clúst

Para dotar de alta disponibilidad a la aplicación, recomendamos aprovisionar el clúster de DAX con al menos tres nodos. A continuación, coloque los nodos en varias zonas de disponibilidad de una región.

Cuando el clúster de DAX se está ejecutando, replica los datos entre todos los nodos del clúster (siempre y cuando haya provisionado más de uno). Considere una aplicación que realiza correctamente una solicitudUpdateItemUso de DAX. Esta acción hace que la caché de elementos del nodo principal se modifique con el nuevo valor. A continuación, este valor se replica en todos los demás nodos del clúster. Esta replicación presenta consistencia final y suele tardar menos de un segundo en llevarse a cabo.

En esta situación, es posible que dos clientes lean la misma clave del mismo clúster de DAX pero reciban valores distintos, según a qué nodo haya obtenido acceso cada cliente. Todos los nodos serán consistentes cuando la actualización haya terminado de replicarse en todos los nodos del clúster. (Este comportamiento se asemeja al carácter consistente final de DynamoDB.

Si va a crear una aplicación que utiliza DAX, dicha aplicación deberá diseñarse de forma que tolere los datos de consistencia final.

Comportamiento de la caché de elementos de

Cada clúster de DAX tiene dos memorias caché diferentes, unaelementocaché y una solicitudquerycaché. Para obtener más información, consulte DAX: Cómo funciona.

En esta sección se abordan las implicaciones para la consistencia de las lecturas y escrituras en la caché de elementos de DAX.

Consistencia de lectura

Con DynamoDB, elGetItemDe forma predeterminada, con la operación lleva a cabo una lectura consistente final. Suponga que utilizaUpdateItemcon el cliente de DynamoDB. Si inmediatamente después intenta leer el mismo elemento, es posible que los datos aparezcan igual que antes de la actualización. Esto se debe al retraso de propagación entre todas las ubicaciones de almacenamiento de DynamoDB. Normalmente, se logra la coherencia en cuestión de segundos. Si reintenta la lectura, probablemente verá el elemento actualizado.

Cuando se utilizaGetItemCon el cliente de DAX, la operación (en este caso, una lectura consistente final) se lleva a cabo como se muestra a continuación.


                    Diagrama de flujo de trabajo que muestra los pasos con números para actualizar un elemento.
  1. El cliente de DAX emite una solicitudGetItemrequest. DAX intenta leer el elemento solicitado en la caché de elementos. Si el elemento está presente en la caché (acierto de cachéDAX lo devuelve a la aplicación.

  2. Si el elemento no está disponible (Memoria caché), DAX realiza unaGetItemOperación contra DynamoDB.

  3. DynamoDB devuelve el elemento solicitado y DAX lo almacena en la caché de elementos.

  4. DAX devuelve el elemento a la aplicación.

  5. (No se muestra) Si el clúster de DAX contiene más de un nodo, el elemento se replica en todos los demás nodos del clúster.

El elemento permanece en la caché de elementos DAX, de conformidad con la configuración de tiempo de vida (TTL) y el algoritmo usado menos recientemente (LRU) de la caché. Para obtener más información, consulte DAX: Cómo funciona.

Sin embargo, durante este periodo, DAX no vuelve a leer el elemento en DynamoDB. Si otra persona actualiza el elemento utilizando un cliente de DynamoDB, omitiendo DAX por completo, unGetItemusando el cliente DAX produce resultados diferentes de la mismaGetItemmediante el cliente de DynamoDB. En este escenario, DAX y DynamoDB contendrán valores inconsistentes de la misma clave hasta que venza el TTL del elemento de DAX.

Si una aplicación modifica los datos de una tabla de DynamoDB subyacente eludiendo DAX, la aplicación tendrá que prever y tolerar las inconsistencias de datos que surjan.

nota

Además deGetItem, el cliente DAX también admiteBatchGetItemsolicitudes. BatchGetItemEn esencia, es un encapsulador alrededor de uno o variosGetItemLas solicitudes, de modo que DAX trata cada una de ellas como una solicitud individualGetItem.

Consistencia de escritura

DAX es una caché de escritura indirecta (write-through). Esto simplifica el proceso de mantener la consistencia entre la caché de elementos de DAX y las tablas de DynamoDB subyacentes.

El cliente de DAX admite las mismas operaciones de API de escritura que DynamoDB (PutItem,UpdateItem,DeleteItem,BatchWriteItem, yTransactWriteItems). Cuando se utilizan estas operaciones con el cliente de DAX, los elementos se modifican tanto en DAX como en DynamoDB. DAX actualiza los elementos en la caché de elementos, con independencia del valor de TTL que tengan.

Por ejemplo, suponga que emite una solicitudGetItemSolicitud del cliente de DAX para leer un elemento deProductCatalogTabla INTO (La clave de partición es Id y no hay clave de ordenación). Recupera el elemento cuyo Id es 101. LaQuantityOnHandpara ese elemento es42. DAX almacena el elemento en su caché de elementos con un TTL concreto. En este ejemplo, vamos a suponer que el TTL es de diez minutos. Después, 3 minutos más tarde, otra aplicación utiliza el cliente de DAX para actualizar el mismo elemento, de forma que suQuantityOnHandahora es41. Suponiendo que el elemento no se vuelva a actualizar, todas las lecturas posteriores del mismo elemento que tengan lugar en los próximos diez minutos devolverán el valor de QuantityOnHand almacenado en caché (41).

Procesamiento de escrituras en DAX

DAX está pensado para aplicaciones que requieren las lecturas de alto desempeño. Como caché de escritura, DAX pasa las escrituras a DynamoDB de forma sincrónica y, a continuación, replica de forma automática y asíncrona las actualizaciones resultantes a la caché de elementos en todos los nodos del clúster. No es necesario administrar la lógica de invalidación de caché, porque DAX lo hace automáticamente.

DAX admite las siguientes operaciones de escritura: PutItem,UpdateItem,DeleteItem,BatchWriteItem, yTransactWriteItems.

Cuando envía unPutItem,UpdateItem,DeleteItem, o bienBatchWriteItemEn DAX, ocurriría lo siguiente:

  • DAX envía la solicitud a DynamoDB.

  • DynamoDB responde a DAX para confirmar que la escritura se ha llevado a cabo correctamente.

  • DAX escribe el elemento en su caché de elementos.

  • DAX devuelve al solicitante que la escritura se ha realizado correctamente.

Cuando envía unTransactWriteItemsEn DAX, ocurriría lo siguiente:

  • DAX envía la solicitud a DynamoDB.

  • DynamoDB responde a DAX para confirmar que la transacción se ha completado.

  • DAX devuelve al solicitante que la escritura se ha realizado correctamente.

  • En segundo plano, DAX crea unTransactGetItemspara cada elemento en elTransactWriteItemsrequest para almacenar el elemento en la caché de elementos. TransactGetItemsse utiliza para garantizaraislamiento serializable.

Si una escritura en DynamoDB falla por cualquier motivo, incluida la limitación limitada, el elemento no se almacenará en caché en DAX. Se devuelve al solicitante la excepción correspondiente al error. De este modo se garantiza que los datos no se escriban en la caché de DAX a no ser que antes se hayan escrito correctamente en DynamoDB.

nota

Cada escritura en DAX altera el estado de la caché de elementos. Sin embargo, las escrituras en ella no afectan a la caché de consultas. La caché de elementos y la caché de consultas de DAX se utilizan con fines diferentes y funcionan de manera independiente una de la otra.

Comportamiento de la caché de consultas de

DAX almacena en caché los resultados deQueryyScanrequest en su caché de consultas. Sin embargo, estos resultados no afectan en absoluto a la caché de elementos. Cuando su aplicación emite unQueryo bienScansolicitud con DAX, el conjunto de resultados se guarda en la caché de consultas, no en la caché de elementos. No se puede "calentar" la caché de elementos antes de llevar a cabo una operación Scan, ya que la caché de elementos y la caché de consultas son entidades independientes.

Consistencia de consulta-actualización-consulta

Las actualizaciones de la caché de elementos o de la tabla de DynamoDB subyacente no invalidan ni modifican los resultados almacenados en la caché de consultas.

A modo de ejemplo, considere la siguiente situación. Una aplicación está trabajando con la tabla DocumentRevisions, que tiene una clave de partición DocId y una clave de ordenación RevisionNumber.

  1. Un cliente de emite una solicitudQuery: paraDocId 101, para todos los elementos conRevisionNumbermayor o igual que5. DAX almacena el conjunto de resultados en la caché de consultas y se lo devuelve al usuario.

  2. El cliente de emite una solicitudPutItemsolicitarDocId 101con unRevisionNumberValor de20.

  3. El cliente de emite el mismoQuerycomo se describe en el paso 1 (DocId 101yRevisionNumber >=5).

En este caso, el conjunto de resultados almacenado en caché correspondiente a la operación Query emitida en el paso 3 es idéntico al que se almacenó en caché en el paso 1. La razón es que DAX no invalidaQueryo bienScanconjuntos de resultados basados en actualizaciones de elementos individuales. LaPutItemoperación del paso 2 solo se refleja en la caché de consultas de DAX cuando el TTL de la solicitudQueryExpires.

La aplicación debe tener en cuenta el valor de TTL de la caché de consultas y el tiempo durante el cual la aplicación puede tolerar resultados inconsistentes entre las cachés de consultas y de elementos.

Lecturas transaccionales y de consistencia alta

Para realizar una operación deGetItem,BatchGetItem,Query, o bienScan, establece la solicitudConsistentReadtrue. DAX pasa las solicitudes de consistencia alta a DynamoDB. Cuando recibe una respuesta de DynamoDB, DAX devuelve los resultados al cliente, pero no almacena en caché los resultados. DAX no puede atender por sí solo a las lecturas de consistencia alta, porque no está estrechamente acoplado a DynamoDB. Debido a esto, todas las lecturas posteriores de DAX tendrían que ser lecturas consistentes finales, Y las lecturas de consistencia alta posteriores tendrían que pasarse a través de DynamoDB.

Controladores DAXTransactGetItemssolicita la misma manera que administra las lecturas de consistencia alta. DAX pasa todos losTransactGetItemssolicitudes a DynamoDB. Cuando recibe una respuesta de DynamoDB, DAX devuelve los resultados al cliente, pero no almacena en caché los resultados.

Almacenamiento en caché negativo

DAX admite las entradas de caché negativas, tanto en la caché de elementos como en la caché de consultas. AEntrada de caché negativaCuando DAX no encuentra los elementos solicitados en una tabla de DynamoDB subyacente. En lugar de generar un error, DAX almacena en caché un resultado vacío y se lo devuelve al usuario.

Por ejemplo, suponga que una aplicación de envía una solicitudGetItemsolicitud a un clúster de DAX y que no hay ningún elemento coincidente en la caché de elementos de DAX. Esto hacer que DAX lea el elemento correspondiente en la tabla de DynamoDB subyacente. Si el elemento no existe en DynamoDB, DAX almacena un elemento vacío en su caché de elementos y se lo devuelve a la aplicación. Ahora supongamos que la aplicación envía otroGetItemsolicitar el mismo elemento. DAX encuentra el elemento vacío en la caché de elementos y se lo devuelve a la aplicación de inmediato. No consultará DynamoDB en absoluto.

Una entrada de caché negativos se conserva en la caché de elementos de DAX de hasta que vence el TTL del elemento, se invoca su LRU o el elemento se modifica mediantePutItem,UpdateItem, o bienDeleteItem.

La caché de consultas de DAX administra los resultados de caché negativos de forma similar. Si una aplicación realiza unaQueryo bienScanSi esto sucede, pero la caché de consultas de DAX no contiene un resultado almacenado en caché, DAX envía la solicitud a DynamoDB. Si no hay elementos coincidentes en el conjunto de resultados, DAX almacena un conjunto de resultados vacío en la caché de consultas y devuelve el conjunto de resultados vacío a la aplicación. Las solicitudes Query o Scan producen el mismo conjunto de resultados (vacío), hasta que vence su TTL.

Estrategias de escritura

El comportamiento de escritura indirecta (write-through) de DAX es adecuado para muchos patrones de aplicaciones. No obstante, existen algunos patrones de aplicación en los que este modelo de escritura indirecta podría no ser el adecuado.

En las aplicaciones que son sensibles a la latencia, la escritura a través de DAX genera un salto de red más. Por eso, la escritura en DAX es algo más lenta que si se realiza directamente en DynamoDB. Si la aplicación es sensible a la latencia de escritura, puede reducir esa latencia escribiendo directamente en DynamoDB. Para obtener más información, consulte Escritura directa.

Para las aplicaciones con gran intensidad de escrituras (como las que llevan a cabo la carga de datos masivos), no es recomendable escribir todos los datos a través de DAX, puesto que la aplicación solo leerá un pequeño porcentaje de ellos. Cuando se escriben grandes cantidades de datos a través de DAX, debe invocar el algoritmo LRU con el fin de dejar espacio en la caché para los nuevos elementos que hay que leer. Esto reduce la eficacia de DAX como caché de lectura.

Al escribir un elemento en DAX, el estado de la caché de elementos se modifica para dar cabida al nuevo elemento. Por ejemplo, DAX podría tener que expulsar datos antiguos de la caché de elementos con el fin de dejar espacio para el nuevo elemento. El nuevo elemento permanecerá en la caché de elementos, de conformidad con el algoritmo LRU y el ajuste de TTL de esta última. Mientras el elemento persista en la caché de elementos, DAX no volverá a leerlo en DynamoDB.

Escritura indirecta

La caché de elementos de DAX implementa una política de escritura automática. Para obtener más información, consulte Procesamiento de escrituras en DAX.

Al escribir un elemento, DAX se asegura de que el elemento almacenado en caché esté sincronizado con el elemento presente en DynamoDB. Esto resulta útil para las aplicaciones que tienen que volver a leer un elemento inmediatamente después de escribirlo. Sin embargo, si otras aplicaciones escriben directamente en una tabla de DynamoDB, el elemento contenido en la caché de elementos de DAX dejará de estar sincronizada con DynamoDB.

Por ejemplo, tomemos dos usuarios (Alice y Bob) que están utilizando la tabla ProductCatalog. Alice obtiene acceso a la tabla mediante DAX, pero Bob elude DAX y obtiene acceso a la tabla directamente en DynamoDB.


                    Diagrama de flujo de trabajo que muestra los pasos con números de cómo los usuarios Alice y Bob acceden a la tabla con DAX y DynamoDB.
  1. Alice actualiza un elemento enProductCatalogTabla INTO DAX reenvía la solicitud a DynamoDB y la actualización se lleva a cabo correctamente. Después, DAX escribe el elemento en su caché de elementos y devuelve una respuesta correcta a Alice. A partir de ese momento, hasta que el elemento se expulse definitivamente de la caché, cualquier usuario que lo lea en DAX verá el elemento con la actualización de Alice.

  2. Poco después, Bob actualiza el mismo elemento ProductCatalog en el que Alice ha escrito. Sin embargo, Bob actualiza el elemento directamente en DynamoDB. DAX no actualiza automáticamente su caché de elementos en respuesta a las actualizaciones a través de DynamoDB. Por tanto, los usuarios de DAX no ven la actualización de Bob.

  3. Alice vuelve a leer el elemento en DAX. El elemento se encuentra en la caché de elementos, por lo que DAX se lo devuelve a Alice sin obtener acceso a la tabla de DynamoDB.

En este caso, Alice y Bob obtienen representaciones distintas del mismo elemento ProductCatalog. Esto continuará siendo así hasta que DAX expulse el elemento de la caché de elementos o hasta que otro usuario lo vuelva a actualizar mediante DAX.

Escritura directa

Si la aplicación tiene que escribir grandes cantidades de datos (por ejemplo, en una carga de datos masivos), puede ser más lógico eludir DAX y escribir los datos directamente en DynamoDB. Esta estrategia de escritura directa (write-around) reduce la latencia. Sin embargo, la caché de elementos no se mantendrá sincronizada con los datos de DynamoDB.

Si decide utilizar una estrategia de escritura directa, recuerde que DAX rellena su caché de elementos cada vez que las aplicaciones utilizan el cliente de DAX para leer los datos. Esto puede ser beneficioso en algunos casos, ya que garantiza que solo se almacenen en caché los datos que se leen con mayor frecuencia (en lugar de los datos que se escriben con mayor frecuencia).

Tomemos, por ejemplo, que un usuario (Charlie) desea trabajar con una tabla diferente, el parámetroGameScores, utilizando DAX. La clave de partición de GameScores es UserId, por lo que todas las puntuaciones de Charlie tendrían el mismo UserId.


                    Diagrama de flujo de trabajo que muestra los pasos con números de cómo Charlie trabaja con una tabla de DynamoDB mediante DAX.
  1. Charlie desea recuperar todas sus puntuaciones, por lo que envía una solicitudQueryDAX. Suponiendo que esta consulta no se haya emitido antes, DAX se la reenvía a DynamoDB para procesarla. Almacena los resultados en la caché de consultas de DAX y, por último, devuelve los resultados a Charlie. El conjunto de resultados seguirá disponible en la caché de consultas hasta que se expulse.

  2. Ahora, supongamos que Charlie juega a Blasters Meteor y logra una puntuación máxima. Charlie envía una solicitudUpdateItemMoDynamoDB de un elemento enGameScoresTabla INTO

  3. Por último, Charlie decide volver a ejecutar la operación Query anterior para recuperar todos sus datos de GameScores. Charlie no ve su puntuación máxima en Meteor Blasters en los resultados. Esto se debe a que los resultados de la consulta proceden de la caché de consultas, no de la caché de elementos. Las dos cachés son independientes entre sí, de modo que un cambio en una de ellas no afecta a la otra.

DAX no actualiza los conjuntos de resultados de la caché de consultas con los datos más recientes de DynamoDB. Cada conjunto de resultados de la caché de consultas estaba actualizado en el momento de ejecutar la operación Query o Scan. Por lo tanto, los resultados que Charlie obtiene con la operación Query no reflejan su operación PutItem. Esto continuará siendo así hasta que DAX expulse el conjunto de resultados de la caché de consultas.