Configuración del clúster de DAX
El clúster de DAX es un clúster administrado, pero puede ajustar sus configuraciones para adaptarlas a los requisitos de su aplicación. Dada su estrecha integración con las operaciones de la API de DynamoDB, debe tener en cuenta los siguientes aspectos a la hora de integrar su aplicación con DAX.
En esta sección
- Precios de DAX
- Caché de elementos y caché de consultas
- Selección de la configuración de TTL para las cachés
- Almacenamiento en caché de varias tablas con un clúster de DAX
- Replicación de datos en tablas globales de DAX y DynamoDB
- Disponibilidad por región de DAX
- Comportamiento del almacenamiento en caché en DAX
Precios de DAX
El costo de un clúster depende de la cantidad y el tamaño de los nodos que haya aprovisionado. A cada nodo se le factura por cada hora de ejecución en el clúster. Para obtener más información, consulte los precios de Amazon DynamoDB
Los aciertos de caché no incurren en costos de DynamoDB, pero afectan a los recursos del clúster de DAX. Los errores de caché generan costos de lectura de DynamoDB y requieren recursos de DAX. Las escrituras generan costos de escritura de DynamoDB y afectan a los recursos del clúster de DAX para realizar la escritura mediante proxy.
Caché de elementos y caché de consultas
DAX mantiene una caché de elementos y una caché de consultas. Comprender las diferencias entre estas cachés puede ayudarle a determinar las características de rendimiento y coherencia que ofrecen a su aplicación.
| Caché de elementos | Caché de consultas |
|---|---|
| Purpose | |
|
Almacena los resultados de las operaciones de las API GetItem y BatchGetItem. |
Almacena los resultados de las operaciones de las API Query y Scan. Estas operaciones pueden devolver varios elementos en función de las condiciones de la consulta y no de claves de elementos específicas. |
| Access type | |
|
Utiliza el acceso basado en claves. Cuando una aplicación solicita datos mediante |
Utiliza el acceso basado en parámetros. DAX almacena en caché el conjunto de resultados y las operaciones de API |
| Cache invalidation | |
|
DAX replica automáticamente los elementos actualizados en la caché de elementos de los nodos del clúster de DAX en los siguientes casos:
|
La caché de consultas es más difícil de invalidar que la caché de elementos. Es posible que las actualizaciones de los elementos no se asignen directamente a las consultas o análisis en caché. Debe ajustar cuidadosamente el TTL de la caché de consultas para mantener la coherencia de datos. Las escrituras indirectas en DAX o la tabla base no se reflejan en la caché de consultas hasta que caduca el TTL de la respuesta previamente almacenada en caché y DAX realiza una nueva consulta en DynamoDB. |
| Global secondary index | |
Because the GetItem API operation isn't supported on local secondary indexes or global secondary indexes, the item cache only caches reads from the base table. |
Query cache caches queries against both tables and indexes. |
Selección de la configuración de TTL para las cachés
TTL determina el periodo durante el cual los datos se almacenan en la caché antes de que queden obsoletos. Después de este tiempo, los datos se actualizan automáticamente en la siguiente solicitud. La elección de la configuración de TTL adecuada para sus cachés de DAX implica un equilibrio entre la optimización del rendimiento de la aplicación y la coherencia de los datos. Como no existe una configuración de TTL universal que funcione para todas las aplicaciones, la configuración de TTL óptima varía en función de las características y los requisitos específicos de la aplicación. Le recomendamos que empiece por una configuración de TTL conservadora siguiendo estas recomendaciones. A continuación, ajuste la configuración de TTL de forma iterativa en función de los datos y la información sobre el rendimiento de la aplicación.
DAX mantiene una lista de elementos menos usados recientemente (LRU) para la caché de elementos. La lista de LRU registra cuándo se escribieron los elementos por primera vez o se leyeron por última vez de la memoria caché. Cuando la memoria del nodo de DAX está llena, DAX expulsa los elementos más antiguos aunque aún no hayan caducado para dejar sitio a los nuevos. El algoritmo de LRU siempre está habilitado y el usuario no puede configurarlo.
Para establecer una duración TTL adecuada para sus aplicaciones, tenga en cuenta lo siguiente:
Comprensión de los patrones de acceso a los datos
-
Cargas de trabajo con mucho tráfico de lectura: en el caso de las aplicaciones con cargas de trabajo con mucho tráfico de lectura y actualizaciones de datos poco frecuentes, establezca una duración de TTL más larga para reducir el número de errores de caché. Una duración de TTL mayor también reduce la necesidad de acceder a la tabla de DynamoDB subyacente.
-
Cargas de trabajo con mucho tráfico de escritura: en el caso de las aplicaciones con actualizaciones frecuentes que no se escriben de forma indirecta en DAX, establezca una duración de TTL más corta para garantizar que la memoria caché se mantenga coherente con la base de datos. Una duración más corta de TTL también reduce el riesgo de proporcionar datos obsoletos.
Evaluación de los requisitos de rendimiento de su aplicación
-
Sensibilidad a la latencia: si su aplicación requiere una latencia baja más que datos recientes, utilice una duración de TTL más larga. Una duración de TTL más larga maximiza los aciertos de caché, lo que reduce la latencia media de lectura.
-
Rendimiento y escalabilidad: una mayor duración de TTL reduce la carga en las tablas de DynamoDB y mejora el rendimiento y la escalabilidad. Sin embargo, debe equilibrar esto con la necesidad de tener datos actualizados.
Analice la expulsión de la caché y el uso de la memoria
-
Límites de memoria caché: monitorice el uso de memoria de su clúster de DAX. Una duración más larga de TTL podría hacer que se almacenaran más datos en la caché, lo que podría alcanzar los límites de memoria y provocar expulsiones basadas en el LRU.
Uso de métricas y monitorización para ajustar el TTL
Revise periódicamente las métricas, por ejemplo, los aciertos y errores de caché y el uso de la CPU y la memoria. Ajuste la configuración de TTL en función de estas métricas para encontrar un equilibrio óptimo entre el rendimiento y el nivel de actualización de los datos. Si los errores de caché son altos y el uso de memoria es bajo, aumente la duración de TTL para aumentar la tasa de aciertos de caché.
Tenga en cuenta los requisitos empresariales y el cumplimiento
Las políticas de retención de datos pueden dictar la duración máxima de TTL que puede establecer para la información confidencial o personal.
Comportamiento de la caché si establece TTL en cero
Si establece TTL en 0, la caché de elementos y la caché de consultas tienen los siguientes comportamientos:
-
Caché de elementos: los elementos de la caché se actualizan solo cuando se produce una expulsión de LRU o una operación de escritura indirecta.
-
Caché de consultas: las respuestas a las consultas no se almacenan en caché.
Almacenamiento en caché de varias tablas con un clúster de DAX
Para las cargas de trabajo que tienen varias tablas pequeñas de DynamoDB que no necesitan cachés individuales, un único clúster de DAX almacena en caché las solicitudes de estas tablas. Esto proporciona un uso más flexible y eficiente de DAX, especialmente para las aplicaciones que acceden a varias tablas y requieren lecturas de alto rendimiento.
Al igual que las API del plano de datos de DynamoDB, las solicitudes de DAX requieren un nombre de tabla. Si usa varias tablas en el mismo clúster de DAX, no necesita ninguna configuración específica. Sin embargo, debe asegurarse de que los permisos de seguridad del clúster permitan el acceso a todas las tablas almacenadas en caché.
Consideraciones sobre el uso de DAX con varias tablas
Cuando utilice DAX con varias tablas de DynamoDB, debe tener en cuenta lo siguiente:
-
Administración de memoria: cuando utilice DAX con varias tablas, debe tener en cuenta el tamaño total del conjunto de datos de trabajo. Todas las tablas del conjunto de datos compartirán el mismo espacio de memoria del tipo de nodo que haya seleccionado.
-
Asignación de recursos: los recursos del clúster de DAX se comparten entre todas las tablas almacenadas en caché. Sin embargo, una tabla con mucho tráfico puede provocar la expulsión de datos de las tablas más pequeñas vecinas.
-
Economías de escala: agrupe los recursos más pequeños en un clúster de DAX más grande para hacer una media el tráfico y seguir un patrón más estable. Para la cantidad total de recursos de lectura que requiere el clúster de DAX, también resulta económico tener tres o más nodos. Esto también aumenta la disponibilidad de todas las tablas almacenadas en caché en el clúster.
Replicación de datos en tablas globales de DAX y DynamoDB
DAX es un servicio basado en regiones, por lo que un clúster solo ve el tráfico que hay en su Región de AWS. Las tablas globales escriben alrededor de la caché cuando replican datos de otra región.
Una duración más larga de TTL puede provocar que los datos obsoletos permanezcan en la región secundaria durante más tiempo que en la región principal. Esto puede provocar errores de caché en la caché local de la región secundaria.
El siguiente diagrama muestra la replicación de datos que se produce en las tablas globales de la región A de origen. El clúster de DAX de la región B no ve inmediatamente los datos recién replicados de la región A de origen.
Disponibilidad por región de DAX
No todas las regiones que admiten tablas de DynamoDB admiten la implementación de clústeres de DAX. Si su aplicación requiere una latencia de lectura baja a través de DAX, consulte primero la lista de regiones que admiten DAX. A continuación, seleccione una región para la tabla de DynamoDB.
Comportamiento del almacenamiento en caché en DAX
DAX realiza el almacenamiento en caché negativo y de metadatos. Conocer estos comportamientos de almacenamiento en caché le ayudará a administrar eficazmente los metadatos de los atributos de los elementos almacenados en caché y las entradas de caché negativas.
-
Almacenamiento en caché de metadatos: los clústeres de DAX conservan de forma indefinida metadatos sobre los nombres de atributo de los elementos almacenados en caché. Estos metadatos se conservan incluso después de que el elemento caduque o se expulse de la caché.
Con el tiempo, las aplicaciones que utilizan un número ilimitado de nombres de atributos pueden provocar el agotamiento de la memoria en el clúster de DAX. Esta limitación se aplica solo a los nombres de atributos de nivel superior, pero no a los nombres de atributo anidados. Algunos ejemplos de nombres de atributos ilimitados son las marcas temporales, los UUID y los ID de sesión. Aunque puede utilizar las marcas de tiempo y los ID de sesión como valores de atributos, le recomendamos que utilice nombres de atributos más cortos y predecibles.
-
Almacenamiento en caché negativo: si se produce un error en la caché y la lectura de una tabla de DynamoDB no proporciona ningún elemento que coincida, DAX agrega una entrada de caché negativa en la caché de elementos o consultas correspondiente. Esta entrada permanece hasta que caduque la duración de TTL de la caché o se produzca una escritura indirecta. DAX sigue devolviendo esta entrada de caché negativa para futuras solicitudes.
Si el comportamiento negativo del almacenamiento en caché no se ajusta al patrón de su aplicación, lea directamente la tabla de DynamoDB cuando DAX devuelva un resultado vacío. También le recomendamos que establezca una duración de TTL de la caché más baja para evitar que haya resultados vacíos durante mucho tiempo en la caché y mejorar la coherencia con la tabla.
