Administración de versiones para ElastiCache

Si slab_chunk_max > max_item_size.

Si max_item_size modulo slab_chunk_max != 0.

Si max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).

El valor (max_cache_memory - memcached_connections_overhead) es la memoria útil del nodo para los datos. Para obtener más información, consulte Capacidad adicional para conexiones de Memcached.

También puede actualizar sus ElastiCache clústeres con versiones anteriores a la 5.0.6. El proceso involucrado es el mismo, pero puede incurrir en un tiempo de conmutación por error más largo durante la propagación de DNS (de 30 s a 1 m).

A partir de Redis OSS 7, ElastiCache permite cambiar entre Valkey o Redis OSS (modo de clúster desactivado) y Valkey o Redis OSS (modo de clúster activado).

El proceso de actualización del motor OSS de Amazon ElastiCache for Redis está diseñado para hacer todo lo posible por conservar los datos existentes y requiere una replicación correcta de Redis OSS.

Al actualizar el motor, ElastiCache finalizará las conexiones de cliente existentes. Para minimizar el tiempo de inactividad durante las actualizaciones del motor, le recomendamos que implemente las prácticas recomendadas para los clientes de Redis OSS, con reintentos de errores y retrocesos exponenciales, así como las prácticas recomendadas para minimizar el tiempo de inactividad durante el mantenimiento.

No puede actualizar directamente de Valkey o Redis OSS (modo de clúster deshabilitado) a Valkey o Redis OSS (modo de clúster habilitado) cuando actualiza su motor. El siguiente procedimiento muestra cómo actualizar de Valkey o Redis OSS (modo de clúster deshabilitado) a Valkey o Redis OSS (modo de clúster habilitado).

Cuando actualiza las versiones principales del motor, por ejemplo de 5.0.6 a 6.0, debe seleccionar un grupo de parámetros nuevo que sea compatible con la versión del motor nueva.

Para los clústeres de OSS de Redis únicos y los clústeres con el OSS Multi-AZ deshabilitado, se recomienda disponer de memoria suficiente para Redis OSS, tal y como se describe en. Forma de garantizar que dispone de memoria suficiente para crear una instantánea de Valkey o Redis OSS En estos casos, el nodo principal no está disponible para las solicitudes de servicio durante el proceso de actualización.

En el caso de los clústeres de OSS de Redis que Multi-AZ estén activados, también recomendamos programar las actualizaciones del motor durante los períodos de bajo tráfico de escritura entrante. Cuando se actualiza a Redis OSS 5.0.6 o a una versión posterior, el clúster principal sigue disponible para atender solicitudes durante el proceso de actualización.

Los clústeres y grupos de reproducción con varias particiones se procesan y se aplican parches de la siguiente manera:

Si el cifrado se encuentra habilitado en su grupo de reproducción o clúster actual, no puede actualizar a una versión del motor que no admita cifrado, como de la versión 3.2.6 a la 3.2.10.

La administración de la versión del motor está diseñada para que pueda tener el mayor control posible sobre cómo se produce la aplicación de parches. Sin embargo, ElastiCache se reserva el derecho de parchear el clúster en su nombre en el improbable caso de que se produzca una vulnerabilidad de seguridad crítica en el sistema o en el software de la memoria caché.

Puesto que el motor de Memcached no es compatible con la persistencia, las actualizaciones de versión del motor de Memcached son siempre un proceso disruptivo que borra todos los datos de caché del clúster.

Full-text búsqueda, agregaciones y búsqueda híbrida: la ElastiCache versión 9.0 de Valkey amplía las capacidades de búsqueda introducidas en Valkey 8.2 con la búsqueda de texto completo, los procesos de agregación y las consultas híbridas que combinan resultados de texto y vectoriales. Crea experiencias de búsqueda potentes directamente en tu caché sin tener que gestionar un motor de búsqueda independiente. Estas capacidades se basan en el proyecto de código abierto valkey-search.

Vencimiento de los campos de hash: establezca los TTL en campos individuales dentro de un hash, lo que le brinda un control detallado del ciclo de vida de los datos sin tener que administrar claves independientes. Expira los campos obsoletos automáticamente y, al mismo tiempo, mantiene intacto el resto del hash. (#2089)

Multi-database compatibilidad en modo clúster: utilice bases de datos numeradas (SELECT 0—15) en configuraciones habilitadas para el modo clúster, lo que elimina una limitación de larga data y simplifica las migraciones de implementaciones independientes a clústeres escalados horizontalmente. (#1671)

Hasta un 40% más de rendimiento con la canalización: el análisis y la captura previa de comandos optimizados en las solicitudes canalizadas ofrecen un rendimiento significativamente mayor para las cargas de trabajo con muchos lotes, lo que permite procesar más operaciones por segundo sin añadir nodos. (#2092)

Polygon-based consultas geoespaciales: la nueva BYPOLYGON opción GEOSEARCHSTORE permite consultar a los miembros dentro de los límites arbitrarios de los polígonos, lo que permite casos de uso del geocercado en el mundo real, como las zonas de entrega, las áreas de servicio y la segmentación regional. GEOSEARCH (#1809)

Más de 100 mejoras adicionales en las versiones 9.0.0 a 9.0.3, incluidas 13 funciones nuevas, 16 optimizaciones del rendimiento con aceleración SIMD, compatibilidad con DELIFEQ, mayor observabilidad con métricas por nodo y por ranura, compatibilidad con redes MPTCP y autenticación automática basada en certificados TLS. Para ver la lista completa, consulte las notas de la versión de Valkey 9.0.

ElastiCache para Valkey, la versión 8.2 ofrece soporte nativo para la búsqueda vectorial, ya que ofrece una latencia de tan solo microsegundos: la búsqueda vectorial con la latencia más baja, el mayor rendimiento y la mejor relación precio-rendimiento, con una tasa de recuperación superior al 95% entre las bases de datos vectoriales más populares. AWS

Una nueva implementación de tabla hash que reduce la sobrecarga de memoria para reducir el uso de memoria hasta en un 20% en el caso de los patrones más comunes key/value .

Compatibilidad nativa con los filtros de Bloom, un nuevo tipo de datos que permite realizar búsquedas utilizando hasta un 98 % menos de memoria en comparación con el tipo de datos Set.

Nuevo comando COMMANDLOG que registra las ejecuciones lentas y las solicitudes y respuestas de gran tamaño.

Nueva compatibilidad con la actualización condicional del comando SET con el argumento IFEQ.

Mejoras del rendimiento, que incluyen una latencia hasta un 45 % menor para el comando ZRANK, un rendimiento hasta 12 veces más rápido para PFMERGE y PFCOUNT, y un rendimiento hasta un 514 % mayor para BITCOUNT.

Mejoras en la eficiencia de la memoria, que permiten a los usuarios almacenar hasta un 20 % más de datos por nodo sin realizar cambios en la aplicación.

Newly-introduced infraestructura de métricas por ranura para clústeres basados en nodos, que proporciona una visibilidad detallada del rendimiento y el uso de recursos de las ranuras individuales.

ElastiCache Serverless for Valkey 8.0 puede duplicar las solicitudes por segundo (RPS) admitidas cada 2 o 3 minutos, hasta alcanzar los 5 millones de RPS por caché desde cero en menos de 13 minutos, con una latencia de lectura constante de p50 por debajo de un milisegundo.

Optimizaciones del rendimiento y la memoria para varios tipos de datos: optimización de la memoria para las teclas de tipo lista y conjunto, optimización de la velocidad para comandos de conjuntos ordenados, optimización del rendimiento para comandos con varias teclas en modo clúster, mejoras en el pub/sub rendimiento, optimización del rendimiento para los comandos SCAN, SSCAN, HSCAN, ZSCAN y muchas otras optimizaciones más pequeñas.

Nueva opción WITHSCORE para los comandos ZRANK y ZREVRANK

CLIENTE NO-TOUCH para que los clientes ejecuten comandos sin afectar a las teclas. LRU/LFU

Nuevo comando CLUSTER MYSHARDID que devuelve el ID de partición del nodo para agrupar los nodos de forma lógica en el modo de clúster en función de la replicación.