DynamoDB Lecturas fuertes versus eventualmente consistentes

Actualiza un elemento, lo vuelve a leer inmediatamente y obtiene el valor anterior. la escritura tuvo éxito: un momento después, la misma lectura devuelve el nuevo valor. No hay nada roto: has accedido a la lectura predeterminada eventualmente consistente predeterminada de DynamoDB y puedes optar por no participar. por solicitud.

Esta es una de las pocas perillas de corrección DynamoDB que te manos directamente y tiene una precio real adjunto. Hacerlo bien significa saber qué garantiza cada modo, qué cuesta y donde las lecturas sólidas simplemente no están disponibles.

¿Cuál es la diferencia entre lecturas fuertemente y finalmente consistentes en DynamoDB?

Cualquier réplica proporciona una lectura eventualmente consistente (la opción predeterminada), por lo que puede devolver brevemente datos obsoletos inmediatamente después de una escritura, pero cuesta la mitad. Una lectura muy consistente, aceptada por solicitud con ConsistentRead=true, se enruta al líder de la partición y siempre refleja cada escritura confirmada, al doble de la capacidad de lectura.

• Eventualmente consistente (el valor predeterminado): puede devolver brevemente datos obsoletos inmediatamente después una escritura. Modo de lectura más económico.
• Fuertemente coherente: siempre refleja cada escritura confirmada antes de la lectura. Regístrese por solicitud con ConsistentRead=true.
• Las lecturas fuertes cuestan 2 veces eventualmente. Una lectura muy consistente consume el doble capacidad de lectura de uno eventualmente consistente para los mismos datos.
• No en todas partes. Obtienes lecturas sólidas en la tabla base y en un Local Índice secundario. Un Índice secundario global es solo eventual: no se puede optar por participar.
• Predeterminado en eventual. Busque fuerza solo cuando lea lo que acaba de escribir. datos y obsoletos por un momento estarían mal.

El problema: una lectura que no ve la última escritura

Digamos que ejecuta cuentas de usuario. Un usuario cambia su correo electrónico de notificación, su aplicación escribe la actualización, y la pantalla de confirmación vuelve a leer inmediatamente el perfil para mostrar el nueva dirección. Con el modo de lectura predeterminado, esa relectura puede aterrizar en una réplica que aún no ha recibido el cambio, por lo que el usuario ve su correo electrónico antiguo y asume el No se pudo guardar.

La ventana es pequeña (normalmente menos de un segundo) y se cierra sola. pero "normalmente correcto" no es suficiente para una confirmación de lectura tras escritura. eso es exactamente el caso para el que existe una fuerte coherencia.

Por qué ocurre la coherencia eventual

DynamoDB almacena cada partición en tres nodes de almacenamiento: uno primario y dos réplicas: en zonas de disponibilidad independientes. Una escritura se reconoce una vez que llega en el primario y una réplica; luego se propaga al tercer node asincrónicamente.

Las lecturas, para distribuir la carga, pueden ser entregadas por cualquier de los tres node. un eventualmente una lectura constante puede llegar a un node que aún no ha recibido su escritura más reciente, por lo que devuelve un valor ligeramente obsoleto. Una lectura fuertemente consistente se enruta al líder de la partición, que siempre contiene los últimos datos confirmados, por lo que nunca devuelve resultados obsoletos.

Ese retraso en la replicación es toda la diferencia. También explica el costo 2×: las lecturas fuertes no se pueden equilibrar la carga entre réplicas de la misma manera que las lecturas eventuales, por lo que DynamoDB les cuesta el doble de capacidad.

El costo, hecho concreto.

Las lecturas se miden en Unidades de capacidad de lectura (RCU), cada una de las cuales cubre hasta 4 KB. Uno RCU compra una lectura fuertemente consistente o dos lecturas eventualmente consistentes de 4 KB artículo. Por lo tanto, invertir ConsistentRead=true en una ruta de lectura activa duplica su costo de lectura, en un endpoint de alto tráfico que es una línea de pedido que notará.

Modele la diferencia para sus propios tamaños de artículos y solicite tarifas con el DynamoDB calculadora de precios antes de realizar fuerte lee su valor predeterminado: rara vez vale la pena pagar dos veces en todos los ámbitos.

Dónde están (y no están) disponibles las lecturas sólidas

Un GSI mantiene su propia copia de los datos, replicada desde la tabla base de forma asincrónica, por lo que nunca podrá ofrecer una lectura sólida. Si un patrón de acceso realmente necesita lectura tras escritura y planeaba entregarlo desde un GSI, esa es una señal para servirlo desde la mesa base o un LSI en su lugar.

Escollos + próximos pasos

• No establezcas lecturas seguras como valor predeterminado. La mayoría de las lecturas toleran un estado obsoleto de menos de un segundo. ventana; Pagar 2× en todas partes es un gasto inútil.
• No espere lectura tras escritura de un GSI. Es eventual por diseño; consulte por qué un GSI es eventualmente consistente.
• Las transacciones se leen fuertemente. TransactGetItems siempre es fuertemente consistente — consulte DynamoDB transacciones.
• La consistencia interactúa con la capacidad. El multiplicador 2× se relaciona directamente con planificación de costos bajo demanda versus aprovisionada.

¿Quiere explorar sus DynamoDB tablas e índices sin escribir API llamadas? Descargue DynoTable e inspeccione sus datos directamente.

Funcionó RCU comparación

Dos lecturas del mismo elemento de 6 KB en la tabla base:

A 1000 lecturas por segundo, el modo fuerte cuesta aproximadamente el doble que el modo bajo demanda. leer gasto del modo eventual: modelar el delta en el calculadora de precios antes de voltear un hot camino hacia ConsistentRead=true globalmente.

BatchGetItem consistencia

Cada entrada de la tabla en BatchGetItem puede configurar ConsistentRead de forma independiente. un El panel que carga un perfil de usuario (fuerte) y configuraciones relacionadas (eventual) puede mezclar indicadores en una llamada por lotes, aún sujeto a la lectura segura por tabla reglas de disponibilidad (no fuertes en GSI).

Lectura tras escritura en el código de la aplicación

Patrón para confirmación de actualización de perfil:

1. UpdateItem con un nuevo correo electrónico.
2. Inmediato GetItem con ConsistentRead: true en la tabla base.

El paso 2 cuesta el doble de RCU de una eventual lectura pero garantiza la confirmación La pantalla coincide con la escritura. Omita lecturas intensas sobre agregaciones en segundo plano que tolerar un retraso inferior a un segundo.

DynoTable valores predeterminados

Las lecturas exploratorias en DynoTable utilizan consultas de tabla base eventualmente consistentes a menos que opte por una semántica más sólida en configuraciones avanzadas, que coincida con la mayoría Casos de uso del tablero. Después de realizar una escritura, la actualización del editor de elementos muestra valores comprometidos de la respuesta exitosa sin una consistencia separada alternar para la ruta común.

Utilice el query constructor para emitir lecturas de muestra con ConsistentRead se establece explícitamente al copiar código SDK en servicios que necesitan Garantías de lectura tras escritura.

Nota de tablas globales

Las tablas globales se replican de forma asincrónica en todas las regiones. Se aplica una fuerte coherencia dentro de la réplica de una región, no globalmente. Una escritura en us-east-1 no es legible al instante en eu-west-1: planifique la UX entre regiones en consecuencia. Consulte las tablas globales para conocer las expectativas de retraso de replicación.