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à.
# Stima della dimensione delle righe in Amazon Keyspaces
Amazon Keyspaces fornisce uno storage completamente gestito che offre prestazioni di lettura e scrittura a una cifra di millisecondi e archivia i dati in modo duraturo su più zone di disponibilità. AWS Amazon Keyspaces allega i metadati a tutte le righe e le colonne chiave primarie per supportare un accesso efficiente ai dati e un'elevata disponibilità.
Questo argomento fornisce dettagli su come stimare la dimensione codificata delle righe in Amazon Keyspaces. La dimensione codificata delle righe viene utilizzata per il calcolo della fattura e dell'utilizzo della quota. È inoltre possibile utilizzare la dimensione delle righe codificate per stimare i requisiti di capacità di throughput assegnati per le tabelle.
Per calcolare la dimensione codificata delle righe in Amazon Keyspaces, puoi utilizzare le seguenti linee guida.
**Topics**
+ [Stima la dimensione codificata delle colonne](#calculating-row-size-columns)
+ [Stima la dimensione codificata dei valori dei dati in base al tipo di dati](#calculating-row-size-data-types)
+ [Considera l'impatto delle funzionalità di Amazon Keyspaces sulla dimensione delle righe](#calculating-row-size-features)
+ [Scegli la formula giusta per calcolare la dimensione codificata di una riga](#calculating-row-size-formula)
+ [Esempio di calcolo della dimensione delle righe](#calculating-row-size-example)
## Stima la dimensione codificata delle colonne
Questa sezione mostra come stimare la dimensione codificata delle colonne in Amazon Keyspaces.
+ **Colonne regolari**: per le colonne normali, che sono colonne che non sono chiavi primarie, colonne di clustering o `STATIC` colonne, usa la dimensione grezza dei dati della cella in base al [tipo di dati](cql.elements.md#cql.data-types) e aggiungi i metadati richiesti. I tipi di dati e alcune differenze chiave nel modo in cui Amazon Keyspaces archivia i valori dei tipi di dati e i metadati sono elencati nella sezione successiva.
+ **Colonne chiave di partizione: le** chiavi di partizione possono contenere fino a 2048 byte di dati. Ogni colonna chiave nella chiave di partizione richiede fino a 3 byte di metadati. Quando si calcola la dimensione della riga, è necessario presupporre che ogni colonna della chiave di partizione utilizzi tutti i 3 byte di metadati.
+ **Colonne di clustering: le colonne** di clustering possono memorizzare fino a 850 byte di dati. Oltre alla dimensione del valore dei dati, ogni colonna di clustering richiede fino al 20% della dimensione del valore dei dati per i metadati. Quando si calcola la dimensione della riga, è necessario aggiungere 1 byte di metadati per ogni 5 byte di valore dei dati della colonna di clustering.
**Nota**
Per supportare interrogazioni efficienti e indicizzazione integrata, Amazon Keyspaces memorizza due volte il valore dei dati di ogni chiave di partizione e colonna chiave di clustering.
+ **Nomi di colonna**: lo spazio richiesto per ogni nome di colonna viene memorizzato utilizzando un identificatore di colonna e aggiunto a ciascun valore di dati memorizzato nella colonna. Il valore di archiviazione dell'identificatore di colonna dipende dal numero complessivo di colonne della tabella:
+ 1—62 colonne: 1 byte
+ 63-124 colonne: 2 byte
+ 125-186 colonne: 3 byte
Per ogni 62 colonne aggiuntive aggiungere 1 byte. Tieni presente che in Amazon Keyspaces, è possibile modificare fino a 225 colonne regolari con una singola istruzione `INSERT` or`UPDATE`. Per ulteriori informazioni, consulta [Quote di servizio Amazon Keyspaces](quotas.md#table).
## Stima la dimensione codificata dei valori dei dati in base al tipo di dati
Questa sezione mostra come stimare la dimensione codificata di diversi tipi di dati in Amazon Keyspaces.
+ **Tipi di stringa**: Cassandra `ASCII` e i tipi di dati `VARCHAR` string sono tutti archiviati in Amazon Keyspaces utilizzando Unicode con codifica binaria UTF-8. `TEXT` La dimensione di una stringa in Amazon Keyspaces è uguale al numero di byte con codifica UTF-8.
+ **Tipi numerici**: Cassandra`INT`,, `BIGINT` `SMALLINT``TINYINT`, e `VARINT` i tipi di dati vengono archiviati in Amazon Keyspaces come valori di dati a lunghezza variabile, con un massimo di 38 cifre significative. Gli zero iniziali e finali vengono tagliati. La dimensione di ognuno di questi tipi di dati è di circa 1 byte per due cifre significative \$1 1 byte.
+ **Tipo di blob**: A `BLOB` in Amazon Keyspaces viene archiviato con la lunghezza in byte non elaborata del valore.
+ **Tipo booleano**: la dimensione di uno o più `Boolean` valori è di 1 byte. `Null`
+ **Tipi di raccolta**: colonna che memorizza tipi di dati di raccolta come `LIST` o `MAP` richiede 3 byte di metadati, indipendentemente dal contenuto. La dimensione di un `LIST` or `MAP` è (id della colonna) \$1 sum (dimensione degli elementi annidati) \$1 (3 byte). La dimensione di un `LIST` or vuoto `MAP` è (id di colonna) \$1 (3 byte). Ogni singolo `LIST` `MAP` elemento richiede anche 1 byte di metadati.
+ **Tipi definiti dall'utente**: un [tipo definito dall'utente (UDT)](udts.md) richiede 3 byte per i metadati, indipendentemente dal contenuto. Per ogni elemento UDT, Amazon Keyspaces richiede 1 byte aggiuntivo di metadati.
Per calcolare la dimensione codificata di un UDT, inizia con `field name` e `field value` per i campi di un UDT:
+ **nome di campo**: ogni nome di campo dell'UDT di primo livello viene memorizzato utilizzando un identificatore. Il valore di archiviazione dell'identificatore dipende dal numero complessivo di campi nell'UDT di primo livello e può variare tra 1 e 3 byte:
+ 1—62 campi: 1 byte
+ 63—124 campi: 2 byte
+ 125— numero massimo di campi: 3 byte
+ **valore del campo**: i byte necessari per memorizzare i valori dei campi dell'UDT di primo livello dipendono dal tipo di dati archiviati:
+ **Tipo di dati scalare**: i byte necessari per l'archiviazione sono gli stessi dello stesso tipo di dati archiviato in una colonna normale.
+ **UDT congelato**: per ogni UDT annidato congelato, l'UDT nidificato ha le stesse dimensioni del protocollo binario CQL. Per un UDT nidificato, vengono memorizzati 4 byte per ogni campo (compresi i campi vuoti) e il valore del campo archiviato è il formato di serializzazione del protocollo binario CQL del valore del campo.
+ **Collezioni Frozen:**
+ **LIST** e **SET**: per un ambiente congelato `LIST` o annidato`SET`, vengono archiviati 4 byte per ogni elemento della raccolta più il formato di serializzazione del protocollo binario CQL del valore della raccolta.
+ **MAP** — Per un blocco congelato annidato`MAP`, ogni coppia chiave-valore ha i seguenti requisiti di archiviazione:
+ Per ogni chiave, allocare 4 byte, quindi aggiungere il formato di serializzazione del protocollo binario CQL della chiave.
+ Per ogni valore allocare 4 byte, quindi aggiungere il formato di serializzazione del protocollo binario CQL del valore.
+ **Parola chiave FROZEN**: per le raccolte congelate annidate all'interno di raccolte congelate, Amazon Keyspaces non richiede byte aggiuntivi per i metadati.
+ **Parola chiave STATICA**: i dati `STATIC` delle colonne non vengono conteggiati ai fini della dimensione massima delle righe di 1 MB. Per calcolare la dimensione dei dati delle colonne statiche, vedi[Calcola la dimensione statica delle colonne per partizione logica in Amazon Keyspaces](static-columns-estimate.md).
## Considera l'impatto delle funzionalità di Amazon Keyspaces sulla dimensione delle righe
Questa sezione mostra come le funzionalità di Amazon Keyspaces influiscono sulla dimensione codificata di una riga.
+ **Timestamp lato client: i timestamp** lato client vengono memorizzati per ogni colonna di ogni riga quando la funzionalità è attivata. Questi timestamp occupano circa 20-40 byte (a seconda dei dati) e contribuiscono ai costi di archiviazione e velocità effettiva della riga. Per ulteriori informazioni sui timestamp lato client, vedere. [Timestamp lato client in Amazon Keyspaces](client-side-timestamps.md)
+ **Time to Live (TTL)**: i metadati TTL occupano circa 8 byte per riga quando la funzionalità è attivata. Inoltre, i metadati TTL vengono archiviati per ogni colonna di ogni riga. I metadati TTL occupano circa 8 byte per ogni colonna che memorizza un tipo di dati scalare o una raccolta congelata. Se la colonna memorizza un tipo di dati di raccolta che non è bloccato, per ogni elemento della raccolta TTL richiede circa 8 byte aggiuntivi per i metadati. Per una colonna che memorizza un tipo di dati di raccolta quando il TTL è abilitato, puoi utilizzare la formula seguente.
```
total encoded size of column = (column id) + sum (nested elements + collection metadata (1 byte) + TTL metadata (8 bytes)) + collection column metadata (3 bytes)
```
I metadati TTL contribuiscono al costo di archiviazione e velocità effettiva della riga. Per ulteriori informazioni su TTL, consulta [Fai scadere i dati con Time to Live (TTL) per Amazon Keyspaces (per Apache Cassandra)](TTL.md).
## Scegli la formula giusta per calcolare la dimensione codificata di una riga
Questa sezione mostra le diverse formule che puoi utilizzare per stimare i requisiti di storage o di capacità di throughput per una riga di dati in Amazon Keyspaces.
La dimensione totale codificata di una riga di dati può essere stimata in base a una delle seguenti formule, in base al tuo obiettivo:
+ **Capacità di trasmissione**: per stimare la dimensione codificata di una riga per valutare le unità di read/write richiesta richieste (): RRUs/WRUs) or read/write capacity units (RCUs/WCUs
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
+ **Dimensione di archiviazione**: per stimare la dimensione codificata di una riga e prevederla`BillableTableSizeInBytes`, aggiungi i metadati richiesti per l'archiviazione della riga:
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```
**Importante**
Tutti i metadati delle colonne, ad esempio gli ID delle colonne, i metadati delle chiavi di partizione, i metadati delle colonne di clustering, nonché i timestamp, il TTL e i metadati di riga sul lato client, vengono conteggiati ai fini della dimensione massima delle righe di 1 MB.
## Esempio di calcolo della dimensione delle righe
Considerate il seguente esempio di tabella in cui tutte le colonne sono di tipo intero. La tabella ha due colonne chiave di partizione, due colonne di clustering e una colonna normale. Poiché questa tabella ha cinque colonne, lo spazio richiesto per l'identificatore del nome della colonna è di 1 byte.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
In questo esempio, calcoliamo la dimensione dei dati quando scriviamo una riga nella tabella, come illustrato nella seguente dichiarazione:
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);
```
Per stimare i byte totali richiesti da questa operazione di scrittura, è possibile utilizzare i seguenti passaggi.
1. Calcola la dimensione di una colonna chiave di partizione aggiungendo i byte per il tipo di dati archiviato nella colonna e i byte dei metadati. Ripeti questa operazione per tutte le colonne chiave di partizione.
1. Calcola la dimensione della prima colonna della chiave di partizione (pk\$1col1):
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. Calcola la dimensione della seconda colonna della chiave di partizione (pk\$1col2):
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. Aggiungi entrambe le colonne per ottenere la dimensione totale stimata delle colonne chiave di partizione:
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
1. Calcola la dimensione della colonna di clustering aggiungendo i byte per il tipo di dati archiviato nella colonna e i byte dei metadati. Ripeti l'operazione per tutte le colonne di clustering.
1. Calcola la dimensione della prima colonna della colonna di clustering (ck\$1col1):
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. Calcola la dimensione della seconda colonna della colonna di clustering (ck\$1col2):
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. Aggiungi entrambe le colonne per ottenere la dimensione totale stimata delle colonne di clustering:
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
1. Aggiungi la dimensione delle colonne normali. In questo esempio abbiamo solo una colonna che memorizza un numero intero a una cifra, che richiede 2 byte con 1 byte per l'ID della colonna.
1. Infine, per ottenere la dimensione totale delle righe codificate, sommate i byte per tutte le colonne. Per stimare la dimensione fatturabile per l'archiviazione, aggiungi i 100 byte aggiuntivi per i metadati delle righe:
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```
Per scoprire come monitorare le risorse serverless con Amazon CloudWatch, consulta[Monitoraggio di Amazon Keyspaces con Amazon CloudWatch](monitoring-cloudwatch.md).