Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Suddivisione dei dati su più livelli in ElastiCache
ElastiCache per i cluster Valkey o Redis OSS che comprendono un gruppo di replica e utilizzano un tipo di nodo della famiglia r6gd, i dati vengono suddivisi su più livelli tra la memoria e lo storage SSD locale (unità a stato solido). Il data tiering offre una nuova opzione in termini di rapporto prezzo/prestazioni per i carichi di lavoro Valkey o Redis OSS utilizzando unità a stato solido (SSD) a basso costo in ogni nodo del cluster oltre all'archiviazione dei dati in memoria. È ideale per carichi di lavoro che accedono regolarmente fino al 20% del set di dati complessivo e per applicazioni che possono tollerare una latenza aggiuntiva quando si accede ai dati su SSD.
Nei ElastiCache cluster con suddivisione dei dati su più livelli, monitora l'ora dell'ultimo accesso di ogni elemento archiviato. ElastiCache Quando la memoria disponibile (DRAM) è completamente consumata, ElastiCache utilizza un algoritmo utilizzato più di recente (LRU) per spostare automaticamente gli elementi a cui si accede meno frequentemente dalla memoria all'SSD. Quando successivamente si accede ai dati sull'SSD, li riporta ElastiCache automaticamente e in modo asincrono in memoria prima di elaborare la richiesta. Se si dispone di un carico di lavoro che accede regolarmente a un sottoinsieme di dati, il tiering di dati è un modo ottimale per dimensionare la capacità a costi contenuti.
Tieni presente che quando utilizzi il tiering dei dati, le chiavi rimangono sempre in memoria, mentre posizionamento dei valori sulla memoria viene gestito da LRU e non dal disco. In generale, è preferibile che le dimensioni delle chiavi siano inferiori a quelle dei valori quando utilizzi il tiering dei dati.
Il tiering dei dati è progettato per avere un impatto minimo sulle prestazioni dei carichi di lavoro delle applicazioni. Ad esempio, supponendo valori String di 500 byte, è possibile prevedere in media ulteriori 300 microsecondi di latenza per le richieste ai dati archiviati su SSD rispetto alle richieste ai dati in memoria.
Con le dimensioni più grandi dei nodi di tiering di dati (cache.r6gd.16xlarge), è possibile archiviare fino a 1 petabyte in un singolo cluster a 500 nodi (500 TB quando si utilizza 1 replica di lettura). Il tiering dei dati è compatibile con tutti i comandi e le strutture dati Valkey o Redis OSS supportati in. ElastiCache Non è necessaria alcuna modifica lato client per utilizzare questa caratteristica.
**Topics**
+ [Best practice](#data-tiering-best-practices)
+ [Limitazioni](#data-tiering-prerequisites)
+ [Prezzi](#data-tiering-pricing)
+ [Monitoraggio](#data-tiering-monitoring)
+ [Utilizzo del tiering di dati](#data-tiering-enabling)
+ [Ripristino di dati da backup su cluster con tiering di dati abilitato](#data-tiering-enabling-snapshots)
## Best practice
È preferibile seguire le best practice seguenti:
+ Il tiering dei dati è ideale per carichi di lavoro che accedono regolarmente fino al 20% del set di dati complessivo e per applicazioni che possono tollerare una latenza supplementare durante l’accesso ai dati su SSD.
+ Quando utilizzi la capacità SSD disponibile su nodi con tiering di dati, è ti consigliamo una dimensione del valore superiore a quella della chiave. Quando gli elementi vengono spostati tra DRAM e SSD, le chiavi rimarranno sempre in memoria e solo i valori verranno spostati al livello SSD.
## Limitazioni
Il livello di dati presenta le seguenti limitazioni:
+ È possibile utilizzare il tiering di dati solo su cluster che fanno parte di un gruppo di replica.
+ Il tipo di nodo utilizzato deve appartenere alla famiglia r6gd.
+ È necessario utilizzare un motore Valkey 7.2 o successivo oppure Redis OSS 6.2 o successivo.
+ Non è possibile ripristinare un backup di un cluster r6gd in un altro cluster a meno che non utilizzi anche r6gd.
+ Non è possibile esportare un backup su Amazon S3 per cluster con tiering di dati.
+ La migrazione online non è supportata per i cluster in esecuzione sul tipo di nodo r6gd.
+ La scalabilità tra cluster con il tiering dei dati abilitato e il tiering dei dati disabilitato non è supportato. Per migrare i dati da un ElastiCache cluster con la suddivisione dei dati disattivata a un cluster con la suddivisione in livelli dei dati abilitata, è possibile ripristinare un backup in un nuovo cluster con la suddivisione in più livelli dei dati abilitata. Per ulteriori informazioni, consulta [Ridimensionamento ElastiCache](Scaling.md).
+ La scalabilità automatica è supportata sui cluster che utilizzano il tiering dei dati per Valkey versione 7.2 e successive e Redis OSS versione 7.0.7 e successive. Per ulteriori informazioni, consulta [Auto Scaling dei cluster Valkey e Redis OSS](AutoScaling.md)
+ Il tiering di dati supporta solo policy maxmemory `volatile-lru`, `allkeys-lru`, `volatile-lfu`, `allkeys-lfu` e `noeviction`.
+ Il salvataggio senza forkless è supportato per Valkey versione 7.2 e successive e Redis OSS versione 7.0.7 e successive. Per ulteriori informazioni, consulta [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md).
+ Gli elementi più grandi di 128 MiB non vengono spostati su SSD.
+ A partire da Valley 8.1 e versioni successive, un elemento la cui dimensione key\+ value è inferiore a 40 byte non verrà spostato sull'SSD.
## Prezzi
I nodi R6gd hanno una capacità totale 4,8 volte superiore (memoria \+ SSD) e possono contribuire a un risparmio di oltre il 60% quando si esegue al massimo utilizzo rispetto ai nodi R6g (solo memoria). Per ulteriori informazioni, consultare [Prezzi di ElastiCache ](https://aws.amazon.com/elasticache/pricing/).
## Monitoraggio
ElastiCache offre metriche progettate specificamente per monitorare i cluster di prestazioni che utilizzano il tiering dei dati. [Per monitorare il rapporto tra gli elementi in DRAM e quelli SSD, puoi utilizzare la `CurrItems` metrica di Metrics for Valkey e Redis OSS.](CacheMetrics.Redis.md) Puoi calcolare la percentuale come: *(CurrItems con Dimension: Tier = Memory \* 100)/(CurrItems senza filtro dimensionale)*.
Se la politica di sfratto configurata lo consente, ElastiCache inizierà a rimuovere gli articoli quando rimane meno del 5% della memoria disponibile (DRAM). Sui nodi configurati con nessuna politica di espulsione, le operazioni di scrittura riceveranno un errore di esaurimento della memoria.
Si consiglia comunque di prendere in considerazione la scalabilità orizzontale per i cluster abilitati alla modalità cluster o la scalabilità verticale per i cluster disabilitati in modalità cluster quando rimane meno del 5% della memoria disponibile (DRAM). Per ulteriori informazioni sulla scalabilità, vedere. [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md) Per ulteriori informazioni sulle metriche per i cluster Valkey o Redis OSS che utilizzano la suddivisione in più livelli dei dati, consulta. [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md)
## Utilizzo del tiering di dati
### Utilizzo della suddivisione in più livelli dei dati utilizzando Console di gestione AWS
Quando si crea un cluster come parte di un gruppo di replica, il tiering di dati viene utilizzato selezionando un tipo di nodo dalla famiglia r6gd, ad esempio *cache.r6gd.xlarge*. La selezione di quel tipo di nodo abilita automaticamente il tiering di dati.
Per ulteriori informazioni sulla creazione di cluster, consulta [Creazione di un cluster per Valkey o Redis OSS](Clusters.Create.md).
### Abilitazione della suddivisione dei dati su più livelli utilizzando il AWS CLI
*Quando si crea un gruppo di replica utilizzando il AWS CLI, si utilizza il tiering dei dati selezionando un tipo di nodo dalla famiglia r6gd, ad esempio cache.r6gd.xlarge e impostando il parametro.* `--data-tiering-enabled`
Non è possibile disattivare il tiering di dati quando si seleziona un tipo di nodo dalla famiglia r6gd. Se si imposta il parametro `--no-data-tiering-enabled`, l'operazione avrà esito negativo.
Per 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
```
Per 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
```
Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:
```
{
"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
}
}
```
## Ripristino di dati da backup su cluster con tiering di dati abilitato
È possibile ripristinare un backup in un nuovo cluster con il tiering dei dati abilitato utilizzando (Console), () o (API).AWS CLI ElastiCache Quando si crea un cluster utilizzando tipi di nodo nella famiglia r6gd, il tiering di dati è abilitato.
### Ripristino di dati da backup su cluster con tiering di dati abilitato (console)
**Per ripristinare un backup su un nuovo cluster con tiering di dati abilitato (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegliere **Backups (Backup)**.
1. Nell'elenco dei backup, scegli la casella a sinistra del nome di backup da cui desideri eseguire il ripristino.
1. Scegli **Restore** (Ripristina).
1. Completare la finestra di dialogo **Restore Cluster (Ripristina cluster)**. Assicurarsi di completare tutti i campi **Obbligatori** e gli eventuali altri che si desidera modificare rispetto alle impostazioni predefinite.
1. **Cluster ID (ID cluster)** : Obbligatorio. Il nome del nuovo cluster.
1. **Modalità cluster abilitata (scalabilità orizzontale)**: scegli questa opzione per un cluster Valkey o Redis OSS (modalità cluster abilitata).
1. **Tipo di nodo** – Specificare **cache.r6gd.xlarge** o qualsiasi altro tipo di nodo della famiglia r6gd.
1. **Numero di shard**: scegli il numero di shard che desideri nel nuovo cluster (API/CLI: gruppi di nodi).
1. **Replicas per Shard (Repliche per partizioni)** - Scegliere il numero di nodi di replica di lettura desiderato in ognle partizioni.
1. **Slots and keyspaces (Slot e keyspaces)** - Scegliere la modalità di distribuzione delle chiavi tra le partizioni. Se si sceglie di specificare le distribuzioni chiave, completare la tabella specificando gli intervalli chiave per ognle partizioni.
1. **Availability zone(s) (Zone di disponibilità)** - Specificare la modalità di selezione delle zone di disponibilità del cluster.
1. **Porta**: modifica solo se il nuovo cluster deve utilizzare una porta diversa.
1. **Choose a VPC (scegliere un VPC)** : Scegliere il VPC in cui creare questo cluster.
1. **Gruppo di parametri**: scegliete un gruppo di parametri che riservi memoria sufficiente per l'overhead di Valkey o Redis OSS per il tipo di nodo selezionato.
1. Dopo aver selezionato tutte le impostazioni desiderate, scegli **Crea**.
Per ulteriori informazioni sulla creazione di cluster, consulta [Creazione di un cluster per Valkey o Redis OSS](Clusters.Create.md).
### Ripristino dei dati dal backup nei cluster con la suddivisione dei dati su più livelli abilitata (AWS CLI)
*Quando si crea un gruppo di replica utilizzando AWS CLI, per impostazione predefinita viene utilizzato il tiering dei dati su più livelli selezionando un tipo di nodo della famiglia r6gd, ad esempio cache.r6gd.xlarge e impostando il parametro.* `--data-tiering-enabled`
Non è possibile disattivare il tiering di dati quando si seleziona un tipo di nodo dalla famiglia r6gd. Se si imposta il parametro `--no-data-tiering-enabled`, l'operazione avrà esito negativo.
Per 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}}
```
Per 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}}
```
Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:
```
{
"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
}
}
```