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à.
# Tiering di dati
I cluster che utilizzano un tipo di nodo della famiglia r6gd hanno i dati 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 e Redis OSS utilizzando unità a stato solido () a basso costo in ogni nodo del cluster oltre all'archiviazione dei dati in memoria. SSDs Analogamente ad altri tipi di nodi, i dati scritti sui nodi r6gd vengono archiviati in modo duraturo in un registro delle transazioni Multi-AZ. 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.
Nei cluster con tiering dei dati, MemoryDB monitora l'ultimo orario di accesso di ogni elemento archiviato. Quando la memoria disponibile (DRAM) è completamente consumata, MemoryDB utilizza un algoritmo LRU (Least-Recently Used) per spostare automaticamente gli elementi a cui si accede meno frequentemente dalla memoria all'SSD. Quando successivamente si accede ai dati sull'SSD, MemoryDB li riporta 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 da 500 byte, in genere è possibile aspettarsi una latenza aggiuntiva di 450 microsecondi per le richieste di lettura dei dati archiviati su SSD rispetto alle richieste di lettura dei dati in memoria.
Con la dimensione massima del nodo di tiering dei dati (db.r6gd.8xlarge), è possibile archiviare fino a \$1 500 in un singolo cluster da 500 nodi (250 TB quando si utilizza 1 replica di lettura). TBs Per il data tiering, MemoryDB riserva il 19% della memoria (DRAM) per nodo per uso diverso dai dati. Il tiering dei dati è compatibile con tutti i comandi e le strutture dati OSS Valkey e Redis supportati in MemoryDB. Non è necessaria alcuna modifica lato client per utilizzare questa caratteristica.
**Topics**
+ [Best practice](data-tiering-best-practices.md)
+ [Limitazioni del tiering dei dati](data-tiering-prerequisites.md)
+ [Prezzi del tiering di dati](data-tiering-pricing.md)
+ [Monitoraggio dei dati su più livelli](data-tiering-monitoring.md)
+ [Utilizzo del tiering di dati](data-tiering-enabling.md)
+ [Ripristino dei dati da un'istantanea nei cluster](data-tiering-enabling-snapshots.md)
# 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. La dimensione del valore non può essere superiore a 128 MB, altrimenti non verrà spostato su disco. 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 del tiering dei dati
Il livello di dati presenta le seguenti limitazioni:
+ Il tipo di nodo utilizzato deve appartenere alla famiglia r6gd, disponibile nelle regioni seguenti: `us-east-2`, `us-east-1`, `us-west-2`, `us-west-1`, `eu-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, `ap-southeast-1`, `ap-southeast-2`, `ap-south-1`, `ca-central-1` e `sa-east-1`.
+ Non è possibile ripristinare un'istantanea di un cluster r6gd in un altro cluster a meno che non utilizzi anche r6gd.
+ Non è possibile esportare uno snapshot in Amazon S3 per cluster di dati su più livelli.
+ Il salvataggio senza fork non è supportato.
+ Il dimensionamento non è supportato da dati un cluster di tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6gd) a un cluster che non utilizza il tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6g).
+ Il tiering di dati supporta solo policy maxmemory `volatile-lru`, `allkeys-lru` e `noeviction`.
+ Gli elementi più grandi di 128 MiB non vengono spostati su SSD.
# Prezzi del tiering di dati
I nodi R6gd hanno una capacità totale (memoria\$1SSD) 5 volte superiore e possono aiutare a ottenere risparmi sui costi di storage di oltre il 60% quando vengono eseguiti al massimo utilizzo rispetto ai nodi R6g (solo memoria). [Per ulteriori informazioni, consulta i prezzi di MemoryDB.](https://aws.amazon.com/memorydb/pricing/)
# Monitoraggio dei dati su più livelli
MemoryDB 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 metrica all'indirizzo. `CurrItems` [Metriche per MemoryDB](metrics.memorydb.md) Puoi calcolare la percentuale come:. `(CurrItems with Dimension: Tier = Memory * 100) / (CurrItems with no dimension filter)`
Se la politica di sfratto configurata lo consente, allora MemoryDB inizierà a sfrattare gli elementi quando la percentuale di elementi in memoria scende al di sotto del 5 percento. Sui nodi configurati con nessuna politica di espulsione, le operazioni di scrittura riceveranno un errore di memoria esaurita.
Si consiglia comunque di considerare [Scalabilità dei cluster MemoryDB](scaling-cluster.md) quando la percentuale di elementi in memoria scende al di sotto del 5%. Per ulteriori informazioni, consulta *Metriche per i cluster MemoryDB che utilizzano* il tiering dei dati su. [Metriche per MemoryDB](metrics.memorydb.md)
# Utilizzo del tiering di dati
## Utilizzo della suddivisione dei dati su più livelli utilizzando il Console di gestione AWS
*Quando si crea un cluster, si utilizza il tiering dei dati selezionando un tipo di nodo della famiglia r6gd, ad esempio db.r6gd.xlarge.* La selezione di quel tipo di nodo abilita automaticamente il tiering di dati.
Per ulteriori informazioni sulla creazione di cluster, consulta [Fase 2: creazione di un cluster](getting-started.md#getting-started.createcluster).
## Abilitazione del tiering dei dati su più livelli utilizzando il AWS CLI
Quando si crea un cluster utilizzando il AWS CLI, si utilizza il tiering dei dati selezionando un tipo di nodo dalla famiglia r6gd, ad esempio *db.r6gd.xlarge e impostando il parametro.* `--data-tiering`
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`, l'operazione avrà esito negativo.
Per Linux, macOS o Unix:
```
aws memorydb create-cluster \
--cluster-name my-cluster \
--node-type db.r6gd.xlarge \
--engine valkey \
--acl-name my-acl \
--subnet-group my-sg \
--data-tiering
```
Per Windows:
```
aws memorydb create-cluster ^
--cluster-name my-cluster ^
--node-type db.r6gd.xlarge ^
--engine valkey ^
--acl-name my-acl ^
--subnet-group my-sg
--data-tiering
```
Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:
```
{
"Cluster": {
"Name": "my-cluster",
"Status": "creating",
"NumberOfShards": 1,
"AvailabilityMode": "MultiAZ",
"ClusterEndpoint": {
"Port": 6379
},
"NodeType": "db.r6gd.xlarge",
"EngineVersion": "7.2",
"EnginePatchVersion": "7.2.6",
"Engine": "valkey"
"ParameterGroupName": "default.memorydb-valkey7",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxxxxxxxxx:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"ACLName": "my-acl",
"DataTiering":"true",
"AutoMinorVersionUpgrade": true
}
}
```
# Ripristino dei dati da un'istantanea nei cluster
È possibile ripristinare un'istantanea in un nuovo cluster con il tiering dei dati abilitato utilizzando (Console), (AWS CLI) o (API MemoryDB). Quando si crea un cluster utilizzando tipi di nodo nella famiglia r6gd, il tiering di dati è abilitato.
## Ripristino dei dati da un'istantanea in cluster con la suddivisione dei dati su più livelli abilitata (console)
Per ripristinare un'istantanea in un nuovo cluster con il tiering dei dati abilitato (console), segui i passaggi riportati in [Ripristino da un'istantanea (console)](snapshots-restoring.md#snapshots-restoring-CON)
Tieni presente che per abilitare il tiering dei dati, devi selezionare un tipo di nodo della famiglia r6gd.
## Ripristino dei dati da un'istantanea in cluster con data tiering abilitato (CLI)AWS
Quando si crea un cluster 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 *db.r6gd.xlarge* e impostando il parametro. `--data-tiering`
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`, l'operazione avrà esito negativo.
Per Linux, macOS o Unix:
```
aws memorydb create-cluster \
--cluster-name my-cluster \
--node-type db.r6gd.xlarge \
--engine valkey
--acl-name my-acl \
--subnet-group my-sg \
--data-tiering \
--snapshot-name my-snapshot
```
Per Windows:
```
aws memorydb create-cluster ^
--cluster-name my-cluster ^
--node-type db.r6gd.xlarge ^
--engine valkey ^
--acl-name my-acl ^
--subnet-group my-sg ^
--data-tiering ^
--snapshot-name my-snapshot
```
Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:
```
{
"Cluster": {
"Name": "my-cluster",
"Status": "creating",
"NumberOfShards": 1,
"AvailabilityMode": "MultiAZ",
"ClusterEndpoint": {
"Port": 6379
},
"NodeType": "db.r6gd.xlarge",
"EngineVersion": "7.2",
"EnginePatchVersion": "7.2.6",
"Engine": "valkey"
"ParameterGroupName": "default.memorydb-valkey7",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxxxxxxxxx:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"ACLName": "my-acl",
"DataTiering": "true"
}
```