Estimer la taille codée des colonnes Estimer la taille codée des valeurs de données en fonction du type de données Tenez compte de l'impact des fonctionnalités d'Amazon Keyspaces sur la taille des lignes Choisissez la bonne formule pour calculer la taille codée d'une ligne Exemple de calcul de la taille des lignes

Estimer la taille des lignes dans Amazon Keyspaces

Amazon Keyspaces fournit un stockage entièrement géré qui offre des performances de lecture et d'écriture à un chiffre en millisecondes et stocke les données de manière durable dans plusieurs zones de disponibilité. AWS Amazon Keyspaces associe des métadonnées à toutes les lignes et à toutes les colonnes clés primaires afin de garantir un accès efficace aux données et une haute disponibilité.

Cette rubrique explique comment estimer la taille codée des lignes dans Amazon Keyspaces. La taille de ligne codée est utilisée lors du calcul de votre facture et de votre quota d'utilisation. Vous pouvez également utiliser la taille de ligne codée lors de l'estimation des exigences de capacité de débit allouées pour les tables.

Pour calculer la taille codée des lignes dans Amazon Keyspaces, vous pouvez suivre les directives suivantes.

Rubriques

Estimer la taille codée des colonnes
Estimer la taille codée des valeurs de données en fonction du type de données
Tenez compte de l'impact des fonctionnalités d'Amazon Keyspaces sur la taille des lignes
Choisissez la bonne formule pour calculer la taille codée d'une ligne
Exemple de calcul de la taille des lignes

Estimer la taille codée des colonnes

Cette section explique comment estimer la taille codée des colonnes dans Amazon Keyspaces.

Colonnes normales — Pour les colonnes ordinaires, qui ne sont pas des clés primaires, les colonnes de clustering ou les STATIC colonnes, utilisez la taille brute des données de cellule en fonction du type de données et ajoutez les métadonnées requises. Les types de données et certaines des principales différences dans la façon dont Amazon Keyspaces stocke les valeurs des types de données et les métadonnées sont répertoriés dans la section suivante.
Colonnes de clé de partition : les clés de partition peuvent contenir jusqu'à 2 048 octets de données. Chaque colonne clé de la clé de partition nécessite jusqu'à 3 octets de métadonnées. Lorsque vous calculez la taille de votre ligne, vous devez partir du principe que chaque colonne de clé de partition utilise les 3 octets complets de métadonnées.
Colonnes de clustering : les colonnes de clustering peuvent stocker jusqu'à 850 octets de données. Outre la taille de la valeur des données, chaque colonne de clustering nécessite jusqu'à 20 % de la taille de la valeur des données pour les métadonnées. Lorsque vous calculez la taille de votre ligne, vous devez ajouter 1 octet de métadonnées pour chaque valeur de 5 octets de données de colonne de clustering.

Note
Pour permettre des requêtes efficaces et une indexation intégrée, Amazon Keyspaces stocke deux fois la valeur des données de chaque clé de partition et de chaque colonne de clé de clustering.
Noms de colonne — L'espace requis pour chaque nom de colonne est stocké à l'aide d'un identifiant de colonne et ajouté à chaque valeur de données stockée dans la colonne. La valeur de stockage de l'identifiant de colonne dépend du nombre total de colonnes de votre table :
- 1 à 62 colonnes : 1 octet
- 63 à 124 colonnes : 2 octets
- 125 à 186 colonnes : 3 octets
Pour chaque 62 colonnes supplémentaires, ajoutez 1 octet. Notez que dans Amazon Keyspaces, jusqu'à 225 colonnes normales peuvent être modifiées à l'aide d'une seule instruction INSERT ou UPDATE d'une seule instruction. Pour de plus amples informations, veuillez consulter Quotas de service Amazon Keyspaces.

Estimer la taille codée des valeurs de données en fonction du type de données

Cette section explique comment estimer la taille codée de différents types de données dans Amazon Keyspaces.

Types de chaînes : les types de données Cassandra ASCII et VARCHAR string sont tous stockés dans Amazon Keyspaces en Unicode UTF avec un encodage binaire -8. TEXT La taille d'une chaîne dans Amazon Keyspaces est égale au nombre de UTF -8 octets codés.
Types numériques : CassandraINT, BIGINTSMALLINT, et les types de TINYINT données sont stockés dans Amazon Keyspaces sous forme de valeurs de données de longueur variable, avec un maximum de 38 chiffres significatifs. Les zéros de début et de fin sont tronqués. La taille de chacun de ces types de données est d'environ 1 octet pour deux chiffres significatifs +1 octet.
Type de blob : BLOB dans Amazon Keyspaces, A est stocké avec la longueur d'octet brute de la valeur.
Type booléen — La taille d'une Boolean valeur ou d'une Null valeur est de 1 octet.
Types de collections : colonne qui stocke des types de données de collection tels que LIST ou MAP nécessitant 3 octets de métadonnées, quel que soit leur contenu. La taille d'un LIST or MAP est (identifiant de colonne) + somme (taille des éléments imbriqués) + (3 octets). La taille d'un LIST or vide MAP est (identifiant de colonne) + (3 octets). Chaque individu LIST ou MAP élément nécessite également 1 octet de métadonnées.
Types définis par l'utilisateur — Un type défini par l'utilisateur (UDT) nécessite 3 octets pour les métadonnées, quel que soit son contenu. Pour chaque UDT élément, Amazon Keyspaces a besoin d'un octet supplémentaire de métadonnées.

Pour calculer la taille codée d'unUDT, commencez par le field name et field value pour les champs de a UDT :
- nom de champ — Chaque nom de champ du niveau supérieur UDT est stocké à l'aide d'un identifiant. La valeur de stockage de l'identifiant dépend du nombre total de champs de votre niveau supérieur UDT et peut varier entre 1 et 3 octets :
  - 1 à 62 champs : 1 octet
  - 63 à 124 champs : 2 octets
  - 125— champs maximum : 3 octets
- valeur du champ — Les octets nécessaires pour stocker les valeurs des champs du niveau supérieur UDT dépendent du type de données stocké :
  - Type de données scalaire — Les octets requis pour le stockage sont les mêmes que pour le même type de données stocké dans une colonne normale.
  - Congelé UDT — Pour chaque imbriqué figéUDT, celui-ci UDT a la même taille que dans le protocole CQL binaire. Pour un champ imbriquéUDT, 4 octets sont stockés pour chaque champ (y compris les champs vides) et la valeur du champ stocké est le format de sérialisation du protocole CQL binaire de la valeur du champ.
  - Collections Frozen :
    
    LISTet SET— Pour un LIST or figé imbriquéSET, 4 octets sont stockés pour chaque élément de la collection, plus le format de sérialisation du protocole CQL binaire de la valeur de la collection.
    MAP— Pour un gelé imbriquéMAP, chaque paire clé-valeur a les exigences de stockage suivantes :
    
    Pour chaque clé, allouez 4 octets, puis ajoutez le format de sérialisation du protocole CQL binaire de la clé.
    Pour chaque valeur, allouez 4 octets, puis ajoutez le format de sérialisation du protocole CQL binaire de la valeur.
FROZENmot-clé — Pour les collections figées imbriquées dans des collections figées, Amazon Keyspaces ne nécessite aucun octet supplémentaire pour les métadonnées.
STATICmot-clé : les données de STATIC colonne ne sont pas prises en compte dans la taille de ligne maximale de 1 Mo. Pour calculer la taille des données des colonnes statiques, consultezCalculez la taille de colonne statique par partition logique dans Amazon Keyspaces.

Tenez compte de l'impact des fonctionnalités d'Amazon Keyspaces sur la taille des lignes

Cette section explique l'impact des fonctionnalités d'Amazon Keyspaces sur la taille codée d'une ligne.

Horodatages côté client — Les horodatages côté client sont stockés pour chaque colonne de chaque ligne lorsque la fonctionnalité est activée. Ces horodatages occupent environ 20 à 40 octets (selon vos données) et contribuent au coût de stockage et de débit de la ligne. Pour plus d'informations sur les horodatages côté client, consultez. Horodatages côté client dans Amazon Keyspaces

Choisissez la bonne formule pour calculer la taille codée d'une ligne

Cette section présente les différentes formules que vous pouvez utiliser pour estimer les exigences de stockage ou de capacité de débit pour une ligne de données dans Amazon Keyspaces.

La taille totale codée d'une ligne de données peut être estimée à l'aide de l'une des formules suivantes, en fonction de votre objectif :

Capacité de débit : pour estimer la taille codée d'une ligne (afin d'évaluer la taille requiseread/write request units (RRUs/WRUs) or read/write capacity units (RCUs/WCUs) :
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
Taille de stockage : pour estimer la taille codée d'une ligne afin de la prévoirBillableTableSizeInBytes, ajoutez les métadonnées requises pour le stockage de la ligne :
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```

Important

Toutes les métadonnées de colonne, par exemple les identifiants de colonne, les métadonnées de clé de partition, les métadonnées de colonne de clustering, ainsi que les horodatages côté client et les métadonnées de ligne sont prises en compte dans la taille de ligne maximale de 1 Mo.

Exemple de calcul de la taille des lignes

Prenons l'exemple suivant d'une table où toutes les colonnes sont de type entier. La table comporte deux colonnes de clé de partition, deux colonnes de clustering et une colonne normale. Comme ce tableau comporte cinq colonnes, l'espace requis pour l'identifiant du nom de colonne est de 1 octet.


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));

Dans cet exemple, nous calculons la taille des données lorsque nous écrivons une ligne dans le tableau, comme indiqué dans l'instruction suivante :


INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);

Pour estimer le nombre total d'octets requis par cette opération d'écriture, vous pouvez suivre les étapes suivantes.

Calculez la taille d'une colonne de clé de partition en ajoutant les octets correspondant au type de données stocké dans la colonne et les octets de métadonnées. Répétez cette opération pour toutes les colonnes clés de partition.
1. Calculez la taille de la première colonne de la clé de partition (pk_col1) :
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
2. Calculez la taille de la deuxième colonne de la clé de partition (pk_col2) :
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
3. Ajoutez les deux colonnes pour obtenir la taille totale estimée des colonnes clés de partition :
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
Calculez la taille de la colonne de clustering en ajoutant les octets correspondant au type de données stocké dans la colonne et les octets de métadonnées. Répétez cette opération pour toutes les colonnes de clustering.
1. Calculez la taille de la première colonne de la colonne de clustering (ck_col1) :
```
(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
```
2. Calculez la taille de la deuxième colonne de la colonne de clustering (ck_col2) :
```
(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
```
3. Ajoutez les deux colonnes pour obtenir la taille totale estimée des colonnes de clustering :
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
Ajoutez la taille des colonnes normales. Dans cet exemple, nous n'avons qu'une seule colonne qui stocke un entier à un chiffre, ce qui nécessite 2 octets dont 1 octet pour l'identifiant de colonne.
Enfin, pour obtenir la taille totale des lignes codées, additionnez les octets de toutes les colonnes. Pour estimer la taille facturable du stockage, ajoutez les 100 octets supplémentaires pour les métadonnées des lignes :
```
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.
```

Pour savoir comment surveiller les ressources sans serveur avec Amazon CloudWatch, consultezSurveillance d'Amazon Keyspaces avec Amazon CloudWatch.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Gestion des ressources sans serveur

Estimation de la consommation de capacité