Elección del tamaño del nodo

¿Espera cargas de trabajo limitadas por el rendimiento con múltiples conexiones de cliente?

Si este es el caso y utiliza la OSS versión 5.0.6 o superior de Redis, puede mejorar el rendimiento y la latencia con nuestra función de E/S mejorada, cuando está disponible, y CPUs se utiliza para reducir la carga de las conexiones de los clientes, en nombre del motor de Redis. OSS Si utiliza la OSS versión 7.0.4 o superior de Redis, además de la E/S mejorada, obtendrá una aceleración adicional con la multiplexación de E/S mejorada, en la que cada subproceso de E/S de red dedicado canaliza los comandos de varios clientes al OSS motor de Redis, aprovechando la capacidad de OSS Redis de procesar los comandos de manera eficiente en lotes. En ElastiCache (RedisOSS) v7.1 y versiones posteriores, ampliamos la funcionalidad mejorada de los subprocesos de E/S para gestionar también la lógica de la capa de presentación. Por capa de presentación, lo que queremos decir es que los subprocesos de E/S mejorados ahora no solo leen las entradas del cliente, sino que también las analizan en el formato de comandos OSS binarios de Redis, que luego se reenvían al subproceso principal para su ejecución, lo que mejora el rendimiento. Consulte la entrada de blog y la página de versiones compatibles para obtener más información.

¿Tiene cargas de trabajo que acceden regularmente a un pequeño porcentaje de sus datos?

Si este es el caso y utiliza la versión 6.2 o posterior OSS del motor Redis, puede aprovechar la organización de los datos por niveles eligiendo el tipo de nodo r6gd. Con la organización de datos por niveles, los datos utilizados menos recientemente se almacenan en. SSD Cuando se recupera, hay un pequeño costo de latencia, que se equilibra con el ahorro de costos. Para obtener más información, consulte Organización de datos por niveles en ElastiCache.

Para obtener más información, consulte Tipos de nodos compatibles.

¿Cuánta memoria total necesita para sus datos?

Para obtener una estimación general, tome el tamaño de los elementos que desea almacenar en la caché. Multiplique este tamaño por el número de elementos que desea conservar en la caché al mismo tiempo. Para obtener una estimación razonable del tamaño de los elementos, serialice los elementos de la caché y cuente los caracteres. A continuación, divida esto entre el número de particiones de su clúster.

Para obtener más información, consulte Tipos de nodos compatibles.

¿Qué versión de Redis utilizas? OSS

OSSLas versiones de Redis anteriores a la 2.8.22 requieren reservar más memoria para la conmutación por error, las instantáneas, la sincronización y la conversión de una réplica a las operaciones principales. Este requisito se debe a que debe disponer de suficiente memoria disponible para todas las operaciones de escritura que se producen durante el proceso.

OSSLa versión 2.8.22 y las posteriores de Redis utilizan un proceso de guardado sin bifurcación que requiere menos memoria disponible que el proceso anterior.

Para más información, consulte los siguientes temas:

¿Qué volumen de operaciones de escritura realiza su aplicación?

Las aplicaciones que realizan un elevado volumen de operaciones de escritura pueden requerir un mayor volumen de memoria disponible (memoria no usada por los datos) a la hora de tomar instantáneas o en casos de conmutación por error. Cuando se aplica el proceso BGSAVE, debe tener suficiente memoria que no sea utilizada por los datos para alojar todas las escrituras que se producen durante el proceso BGSAVE. Algunos ejemplos son cuando se toma una instantánea, cuando se sincroniza un clúster principal con una réplica de un clúster y cuando se habilita la función de solo adjuntar archivos (). AOF Otro ejemplo es cuando se promueve una réplica a principal (si tiene habilitado Multi-AZ). El peor de los casos es cuando todos los datos se reescriben durante el proceso. En este caso, necesita un tamaño de instancia de nodo con el doble de la memoria necesaria solo para los datos.

Para obtener información más detallada, consulte Asegurarse de tener suficiente memoria para hacer una instantánea de Valkey o Redis OSS.

¿Su implementación será un clúster independiente de Valkey o Redis OSS (modo de clúster desactivado), o un clúster de Valkey o Redis OSS (modo de clúster habilitado) con varios fragmentos?

Clúster de Valkey o Redis (modo de clúster desactivado) OSS

Si está implementando un clúster de Valkey o Redis OSS (modo de clúster deshabilitado), su tipo de nodo debe poder acomodar todos sus datos más la sobrecarga necesaria, tal como se describe en el punto anterior.

Por ejemplo, supongamos que estima que el tamaño total de todos los elementos es de 12 GB. En este caso, puede utilizar un nodo de cache.m3.xlarge con 13.3 GB de memoria o un nodo de cache.r3.large con 13.5 GB de memoria. Sin embargo, es posible que necesite más memoria para las operaciones BGSAVE. Si la aplicación tiene un gran volumen de operaciones de escritura, duplique los requisitos de memoria a 24 GB como mínimo. Por lo tanto, utilice un cache.m3.2xlarge con 27.9 GB de memoria o un cache.r3.xlarge con 30.5 GB de memoria.

Valkey o Redis OSS (modo de clúster activado) con varios fragmentos

Si va a implementar un clúster de Valkey o Redis OSS (habilitado para el modo de clúster) con varios fragmentos, el tipo de nodo debe poder alojar bytes de datos. bytes-for-data-and-overhead / number-of-shards

Por ejemplo, suponga que estima que el tamaño total de todos los elementos es de 12 GB y tiene dos particiones. En este caso, puede utilizar un nodo de cache.m3.large con 6.05 GB de memoria (12 GB/2). Sin embargo, es posible que necesite más memoria para las operaciones BGSAVE. Si la aplicación tiene un gran volumen de operaciones de escritura, duplique los requisitos de memoria a 12 GB por partición como mínimo. Por lo tanto, utilice un cache.m3.xlarge con 13.3 GB de memoria o un cache.r3.large con 13.5 GB de memoria.

¿Utiliza Local Zones?

Las Zonas Locales le permiten colocar recursos, como un ElastiCache clúster, en varias ubicaciones cercanas a sus usuarios. Sin embargo, cuando elija el tamaño del nodo, tenga en cuenta que, independientemente de los requisitos de capacidad, los tamaños de nodo disponibles tienen los siguientes límites en este momento:

11 cache.t2.medium nodos con 3,22 GB de memoria y 2 subprocesos en cada uno = 35,42 GB y 22 subprocesos.

6 cache.m4.large nodos con 6,42 GB de memoria y 2 subprocesos en cada uno = 38,52 GB y 12 subprocesos.

3 cache.r4.large nodos con 12,3 GB de memoria y 2 subprocesos en cada uno = 36,90 GB y 6 subprocesos.

3 cache.m4.xlarge nodos con 14,28 GB de memoria y 4 subprocesos en cada uno = 42,84 GB y 12 subprocesos.