Organización de datos por niveles en ElastiCache - Amazon ElastiCache

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.

Organización de datos por niveles en ElastiCache

ElastiCache en el caso de los clústeres OSS de Valkey o Redis que forman un grupo de replicación y utilizan un tipo de nodo de la familia r6gd, sus datos se agrupan en niveles entre la memoria y el almacenamiento SSD (unidades de estado sólido) local. La organización de datos en niveles ofrece una nueva opción de relación precio-rendimiento para las cargas de trabajo OSS de Valkey o Redis, ya que utiliza unidades de estado sólido () SSDs de menor costo en cada nodo del clúster, además de almacenar los datos en la memoria. Es ideal para cargas de trabajo que acceden regularmente hasta un 20 por ciento de su conjunto de datos general y para aplicaciones que pueden tolerar latencia adicional al acceder a los datos en SSD.

En ElastiCache los clústeres con datos agrupados en niveles, ElastiCache supervisa la hora del último acceso de cada elemento que almacena. Cuando la memoria disponible (DRAM) se agota por completo, ElastiCache utiliza un algoritmo utilizado recientemente (LRU) para mover automáticamente los elementos a los que se accede con poca frecuencia de la memoria a la SSD. Cuando se accede posteriormente a los datos de la SSD, los devuelve a la memoria de ElastiCache forma automática y asíncrona antes de procesar la solicitud. Si tiene una carga de trabajo que solo accede a un subconjunto de sus datos regularmente, la organización de datos en niveles es una forma óptima de escalar su capacidad de forma rentable.

Tenga en cuenta que cuando se utiliza la organización de datos en niveles, las propias claves siempre permanecen en la memoria, mientras que la LRU rige la ubicación de los valores en la memoria frente al disco. En general, recomendamos que los tamaños de las claves sean más pequeños que los tamaños de los valores al usar la organización de datos en niveles.

La organización de datos en niveles está diseñada para tener un impacto mínimo en el rendimiento de las cargas de trabajo Por ejemplo, suponiendo valores de cadena de 500 bytes, puede esperar 300 microsegundos adicionales de latencia en promedio para las solicitudes de datos almacenados en SSD en comparación con las solicitudes de datos de la memoria.

Con el mayor tamaño de nodo de organización de datos en niveles (cache.r6gd.16xlarge), puede almacenar hasta 1 petabyte en un solo clúster de 500 nodos (500 TB cuando se utiliza 1 réplica de lectura). La organización de los datos en niveles es compatible con todos los comandos y estructuras de datos del OSS de Valkey o Redis compatibles. ElastiCache No es necesario cambiar el lado del cliente para usar esta característica.

Prácticas recomendadas

Recomendamos que siga las siguientes prácticas recomendadas:

  • La organización de datos en niveles es ideal para cargas de trabajo que acceden regularmente hasta un 20 % de su conjunto de datos general y para aplicaciones que pueden tolerar latencia adicional al acceder a los datos en SSD.

  • Al utilizar la capacidad de SSD disponible en nodos con niveles de datos, recomendamos que el tamaño del valor sea mayor que el tamaño de la clave. Cuando se mueven elementos entre DRAM y SSD, las claves siempre permanecerán en la memoria y solo los valores se moverán al nivel de SSD.

Limitaciones

La organización de datos en niveles tiene las siguientes restricciones:

  • Solo puede utilizar la organización de datos en niveles en clústeres que forman parte de un grupo de replicación.

  • El tipo de nodo que utilice debe pertenecer a la familia r6gd, que está disponible en las siguientes regiones: us-east-2, us-east-1, us-west-2, us-west-1, eu-west-1, eu-central-1, eu-north-1, eu-west-3, ap-northeast-1, ap-southeast-1, ap-southeast-2, ap-south-1, ca-central-1 y sa-east-1.

  • Debe utilizar un motor que sea Valkey 7.2 o una versión posterior, o Redis OSS 6.2 o una versión posterior.

  • No se puede restaurar una copia de seguridad de un clúster r6gd en otro clúster a menos que utilice también r6gd.

  • No se puede exportar una copia de seguridad a Amazon S3 para clústeres de organización de datos en niveles.

  • La migración en línea no se admite para clústeres que se ejecutan en el tipo de nodo r6gd.

  • No se admite el escalado desde un clúster de organización de datos en niveles (por ejemplo, un clúster que utiliza un tipo de nodo r6gd) a un clúster que no utiliza la organización de datos en niveles (por ejemplo, un clúster que utiliza un tipo de nodo r6g). Para obtener más información, consulte Escalado ElastiCache.

  • El escalado automático se admite en los clústeres que utilizan la organización de datos en niveles para Valkey 7.2 y versiones posteriores y Redis OSS 7.0.7 y versiones posteriores. Para obtener más información, consulte Clústeres de escalado automático de Valkey y Redis OSS

  • La organización de datos en niveles solo admite las políticas maxmemory volatile-lru, allkeys-lru, volatile-lfu, allkeys-lfu y noeviction.

  • Valkey 7.2 y versiones posteriores y Redis OSS 7.0.7 y versiones posteriores admiten el guardado sin ramificaciones. Para obtener más información, consulte Cómo se implementan la sincronización y la copia de seguridad.

  • Los artículos de más de 128 MiB no se mueven a SSD.

Precios

Los nodos R6gd tienen 4,8 veces más capacidad total (memoria + SSD) y pueden ayudarle a ahorrar más del 60 por ciento cuando se ejecuta con la máxima utilización en comparación con los nodos R6g (solo memoria). Para obtener más información, consulte Precios de ElastiCache .

Monitorización

ElastiCache ofrece métricas diseñadas específicamente para monitorear los clústeres de rendimiento que utilizan la organización de datos por niveles. Para supervisar la proporción de elementos en DRAM en comparación con SSD, puede utilizar la métrica CurrItems en Métricas de Valkey y Redis OSS. Puede calcular el porcentaje de la siguiente manera: (CurrItems con dimensión: nivel = memoria * 100)/(CurrItems sin filtro de dimensiones).

Si la política de desalojo configurada lo permite, ElastiCache empezará a desalojar los elementos cuando el porcentaje de elementos en la memoria disminuya por debajo del 5 por ciento. En los nodos configurados con una política de no expulsión, en las operaciones de escritura aparecerá un error de memoria insuficiente.

Se sigue recomendando que considere la posibilidad de escalar horizontalmente los clústeres con el modo de clúster habilitado o de escalar verticalmente los clústeres con el modo de clúster deshabilitado cuando el porcentaje de elementos en memoria disminuya por debajo del 5 %. Para obtener más información sobre el escalado, consulte Escalado de clústeres en Valkey o Redis OSS (modo de clúster habilitado). Para obtener más información sobre las métricas para clústeres de Valkey o Redis OSS que utilizan la organización de datos en niveles, consulte Métricas de Valkey y Redis OSS.

Uso de la organización de datos en niveles

Al crear un clúster como parte de un grupo de replicación, se utiliza la organización de datos en niveles seleccionando un tipo de nodo de la familia r6gd, como cache.r6gd.xlarge. La selección de ese tipo de nodo habilita automáticamente la organización de datos en niveles.

Para obtener más información sobre la creación de clústeres, consulte Creación de un clúster para Valkey o Redis OSS.

Al crear un grupo de replicación mediante el AWS CLI, se utiliza la estratificación de datos seleccionando un tipo de nodo de la familia r6gd, como cache.r6gd.xlarge, y configurando el parámetro. --data-tiering-enabled

No puede excluirse de la organización de datos en niveles al seleccionar un tipo de nodo de la familia r6gd. Si configura el parámetro --no-data-tiering-enabled, la operación no se llevará a cabo correctamente.

Para Linux, macOS o Unix:

aws elasticache create-replication-group \ --replication-group-id redis-dt-cluster \ --replication-group-description "Redis OSS cluster with data tiering" \ --num-node-groups 1 \ --replicas-per-node-group 1 \ --cache-node-type cache.r6gd.xlarge \ --engine redis \ --cache-subnet-group-name default \ --automatic-failover-enabled \ --data-tiering-enabled

Para Windows:

aws elasticache create-replication-group ^ --replication-group-id redis-dt-cluster ^ --replication-group-description "Redis OSS cluster with data tiering" ^ --num-node-groups 1 ^ --replicas-per-node-group 1 ^ --cache-node-type cache.r6gd.xlarge ^ --engine redis ^ --cache-subnet-group-name default ^ --automatic-failover-enabled ^ --data-tiering-enabled

Después de ejecutar esta operación, verá una respuesta parecida a la siguiente:

{ "ReplicationGroup": { "ReplicationGroupId": "redis-dt-cluster", "Description": "Redis OSS cluster with data tiering", "Status": "creating", "PendingModifiedValues": {}, "MemberClusters": [ "redis-dt-cluster" ], "AutomaticFailover": "enabled", "DataTiering": "enabled", "SnapshotRetentionLimit": 0, "SnapshotWindow": "06:00-07:00", "ClusterEnabled": false, "CacheNodeType": "cache.r6gd.xlarge", "TransitEncryptionEnabled": false, "AtRestEncryptionEnabled": false } }

Restauración de datos desde copias de seguridad en clústeres con la organización de datos en niveles

Puede restaurar una copia de seguridad en un clúster nuevo con la organización de datos en niveles habilitada mediante la (consola), () o (API).AWS CLI ElastiCache Cuando crea un clúster mediante tipos de nodos de la familia r6gd, se habilita la organización de datos en niveles.

Para restaurar una copia de seguridad a un nuevo clúster con la organización de datos en niveles habilitada (consola)
  1. Inicie sesión en AWS Management Console y abra la ElastiCache consola en https://console.aws.amazon.com/elasticache/.

  2. En el panel de navegación, seleccione Backups (Copias de seguridad).

  3. En la lista de copias de seguridad, active la casilla situada a la izquierda del nombre de la copia de seguridad que desea restaurar.

  4. Elija Restore (Restaurar).

  5. Complete el cuadro de diálogo Restore Cluster. Asegúrese de completar todos los campos Required (Obligatorios) y los demás campos cuyos valores predeterminados desee modificar.

    1. ID del clúster: obligatorio. Se trata del nombre del nuevo clúster.

    2. Modo de clúster habilitado (escalado horizontal): elija esta opción para clústeres de Valkey o Redis OSS (modo de clúster habilitado).

    3. Tipo de nodo: especificar cache.r6gd.xlarge o cualquier otro tipo de nodo de la familia r6gd.

    4. Number of Shards: elija el número de fragmentos que desea en el nuevo clúster (API/CLI: grupos de nodos).

    5. Replicas per Shard: elija el número de nodos de réplica de lectura que desea en cada fragmento.

    6. Ranuras y espacios de claves: elija cómo desea que se distribuyan las claves entre las particiones. Si decide especificar las distribuciones de claves, complete la tabla especificando los rangos de claves para cada fragmento.

    7. Availability zone(s): especifique cómo desea que se seleccionen las zonas de disponibilidad del clúster.

    8. Port: modifique este valor solo si desea que el nuevo clúster use un puerto distinto.

    9. Choose a VPC: elija la VPC en la que va a crear este clúster.

    10. Grupo de parámetros: elija un grupo de parámetros que reserve memoria suficiente para la sobrecarga de Valkey o Redis OSS del tipo de nodo que haya seleccionado.

  6. Cuando esté conforme con los ajustes, elija Crear.

Para obtener más información sobre la creación de clústeres, consulte Creación de un clúster para Valkey o Redis OSS.

Al crear un grupo de replicación mediante el AWS CLI, la organización de datos por niveles se utiliza de forma predeterminada. Para ello, se selecciona un tipo de nodo de la familia r6gd, como cache.r6gd.xlarge, y se establece el parámetro. --data-tiering-enabled

No puede excluirse de la organización de datos en niveles al seleccionar un tipo de nodo de la familia r6gd. Si configura el parámetro --no-data-tiering-enabled, la operación no se llevará a cabo correctamente.

Para Linux, macOS o Unix:

aws elasticache create-replication-group \ --replication-group-id redis-dt-cluster \ --replication-group-description "Redis OSS cluster with data tiering" \ --num-node-groups 1 \ --replicas-per-node-group 1 \ --cache-node-type cache.r6gd.xlarge \ --engine redis \ --cache-subnet-group-name default \ --automatic-failover-enabled \ --data-tiering-enabled \ --snapshot-name my-snapshot

Para Linux, macOS o Unix:

aws elasticache create-replication-group ^ --replication-group-id redis-dt-cluster ^ --replication-group-description "Redis OSS cluster with data tiering" ^ --num-node-groups 1 ^ --replicas-per-node-group 1 ^ --cache-node-type cache.r6gd.xlarge ^ --engine redis ^ --cache-subnet-group-name default ^ --automatic-failover-enabled ^ --data-tiering-enabled ^ --snapshot-name my-snapshot

Después de ejecutar esta operación, verá una respuesta parecida a la siguiente:

{ "ReplicationGroup": { "ReplicationGroupId": "redis-dt-cluster", "Description": "Redis OSS cluster with data tiering", "Status": "creating", "PendingModifiedValues": {}, "MemberClusters": [ "redis-dt-cluster" ], "AutomaticFailover": "enabled", "DataTiering": "enabled", "SnapshotRetentionLimit": 0, "SnapshotWindow": "06:00-07:00", "ClusterEnabled": false, "CacheNodeType": "cache.r6gd.xlarge", "TransitEncryptionEnabled": false, "AtRestEncryptionEnabled": false } }