Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Estimez la consommation de capacité du débit de lecture et d'écriture dans Amazon Keyspaces Lorsque vous lisez ou écrivez des données dans Amazon Keyspaces, le nombre d'unités de read/write demande (RRUs/WRUs) or read/write capacity units (RCUs/WCUs) consommées par votre requête dépend de la quantité totale de données qu'Amazon Keyspaces doit traiter pour exécuter la requête. Dans certains cas, les données renvoyées au client peuvent être un sous-ensemble des données qu'Amazon Keyspaces a dû lire pour traiter la requête. Pour les écritures conditionnelles, Amazon Keyspaces consomme de la capacité d'écriture même si le contrôle conditionnel échoue. Pour estimer la quantité totale de données traitées pour une demande, vous devez tenir compte de la taille codée d'une ligne et du nombre total de lignes. Cette rubrique présente quelques exemples de scénarios et de modèles d'accès courants pour montrer comment Amazon Keyspaces traite les requêtes et comment cela affecte la consommation de capacité. Vous pouvez suivre les exemples pour estimer les besoins en capacité de vos tables et utiliser Amazon CloudWatch pour observer la consommation de capacité de lecture et d'écriture pour ces cas d'utilisation. Pour plus d'informations sur le calcul de la taille codée des lignes dans Amazon Keyspaces, consultez. [Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md) **Topics** + [Estimez la consommation de capacité des requêtes de plage dans Amazon Keyspaces](range_queries.md) + [Estimer la consommation de capacité de lecture des requêtes limitées](limit_queries.md) + [Estimez la consommation de capacité de lecture des scans de tables](table_scans.md) + [Estimez la consommation de capacité des transactions légères dans Amazon Keyspaces](lightweight_transactions.md) + [Estimation de la consommation de capacité pour les colonnes statiques dans Amazon Keyspaces](static-columns.md) + [Estimer et provisionner la capacité d'une table multirégionale dans Amazon Keyspaces](tables-multi-region-capacity.md) + [Estimez la consommation de capacité de lecture et d'écriture avec Amazon CloudWatch dans Amazon Keyspaces](estimate_consumption_cw.md) # Estimez la consommation de capacité des requêtes de plage dans Amazon Keyspaces Pour examiner la consommation de capacité de lecture d'une requête de plage, nous utilisons le tableau d'exemple suivant qui utilise le mode capacité à la demande. ``` pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value -----+-----+-----+-----+-----+-----+------- a | b | 1 | a | b | 50 | a | b | 1 | a | b | 60 | value_1 a | b | 1 | a | b | 70 | ``` Exécutez maintenant la requête suivante sur cette table. ``` SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70; ``` Vous recevez le jeu de résultats suivant à partir de la requête et l'opération de lecture effectuée par Amazon Keyspaces en consomme 2 RRUs en mode `LOCAL_QUORUM` cohérence. ``` pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value -----+-----+-----+-----+-----+-----+------- a | b | 1 | a | b | 60 | value_1 ``` Amazon Keyspaces en consomme 2 RRUs pour évaluer les lignes contenant les valeurs `ck3=60` et `ck3=70` pour traiter la requête. Cependant, Amazon Keyspaces renvoie uniquement la ligne pour laquelle la `WHERE` condition spécifiée dans la requête est vraie, c'est-à-dire la ligne contenant une valeur. `ck3=60` Pour évaluer la plage spécifiée dans la requête, Amazon Keyspaces lit la ligne correspondant à la limite supérieure de la plage, dans ce cas`ck3 = 70`, mais ne renvoie pas cette ligne dans le résultat. La consommation de capacité de lecture est basée sur les données lues lors du traitement de la requête, et non sur les données renvoyées. # Estimer la consommation de capacité de lecture des requêtes limitées Lors du traitement d'une requête qui utilise la `LIMIT` clause, Amazon Keyspaces lit les lignes jusqu'à la taille de page maximale en essayant de répondre à la condition spécifiée dans la requête. Si Amazon Keyspaces ne trouve pas suffisamment de données correspondantes correspondant à la `LIMIT` valeur de la première page, un ou plusieurs appels paginés peuvent être nécessaires. Pour poursuivre les lectures sur la page suivante, vous pouvez utiliser un jeton de pagination. La taille de page par défaut est de 1 Mo. Pour réduire la capacité de lecture lorsque vous utilisez `LIMIT` des clauses, vous pouvez réduire la taille de page. Pour plus d'informations sur la pagination, consultez[Paginer les résultats dans Amazon Keyspaces](paginating-results.md). À titre d'exemple, examinons la requête suivante. ``` SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1; ``` Si vous ne définissez pas le format de page, Amazon Keyspaces lit 1 Mo de données même s'il ne vous renvoie qu'une seule ligne. Pour qu'Amazon Keyspaces ne lise qu'une seule ligne, vous pouvez définir le format de page sur 1 pour cette requête. Dans ce cas, Amazon Keyspaces ne lira qu'une seule ligne, à condition qu'aucune ligne n'ait expiré en fonction des Time-to-live paramètres ou des horodatages côté client. Le `PAGE SIZE` paramètre détermine le nombre de lignes qu'Amazon Keyspaces analyse depuis le disque pour chaque demande, et non le nombre de lignes renvoyées par Amazon Keyspaces au client. Amazon Keyspaces applique les filtres que vous fournissez, par exemple l'inégalité sur les colonnes non clés ou `LIMIT` après avoir scanné les données sur le disque. Si vous ne le définissez pas explicitement`PAGE SIZE`, Amazon Keyspaces lit jusqu'à 1 Mo de données avant d'appliquer des filtres. Par exemple, si vous utilisez `LIMIT 1` sans spécifier le`PAGE SIZE`, Amazon Keyspaces peut lire des milliers de lignes depuis le disque avant d'appliquer la clause limite et de ne renvoyer qu'une seule ligne. Pour éviter de trop lire, réduisez le `PAGE SIZE` nombre de lignes qu'Amazon Keyspaces analyse à chaque lecture. Par exemple, si vous le `PAGE SIZE` définissez `LIMIT 5` dans votre requête, définissez une valeur comprise entre 5 et 10 afin qu'Amazon Keyspaces ne scanne que 5 à 10 lignes par appel paginé. Vous pouvez modifier ce nombre pour réduire le nombre d'extractions. Pour les limites supérieures à la taille de page, Amazon Keyspaces conserve le nombre total de résultats avec l'état de pagination. Dans le cas d'un fichier `LIMIT` de 10 000 lignes, Amazon Keyspaces peut récupérer ces résultats sur deux pages de 5 000 lignes chacune. La limite de 1 Mo est la limite supérieure de toute taille de page définie. # Estimez la consommation de capacité de lecture des scans de tables Les requêtes qui aboutissent à une analyse complète de la table, par exemple les requêtes utilisant l'`ALLOW FILTERING`option, sont un autre exemple de requêtes qui traitent plus de lectures que ce qu'elles renvoient sous forme de résultats. Et la consommation de capacité de lecture est basée sur les données lues, et non sur les données renvoyées. Pour l'exemple de numérisation de tables, nous utilisons l'exemple de tableau suivant en mode capacité à la demande. ``` pk | ck | value ---+----+--------- pk | 10 | pk | 20 | value_1 pk | 30 | ``` Amazon Keyspaces crée une table en mode capacité à la demande avec quatre partitions par défaut. Dans cet exemple de tableau, toutes les données sont stockées dans une partition et les trois partitions restantes sont vides. Exécutez maintenant la requête suivante sur la table. ``` SELECT * from amazon_keyspaces.example_table_2; ``` Cette requête entraîne une opération d'analyse de table au cours de laquelle Amazon Keyspaces analyse les quatre partitions de la table et en consomme 6 RRUs en mode `LOCAL_QUORUM` cohérence. Tout d'abord, Amazon Keyspaces en consomme 3 RRUs pour lire les trois lignes avec. `pk=‘pk’` Ensuite, Amazon Keyspaces consomme les 3 unités supplémentaires RRUs pour scanner les trois partitions vides de la table. Comme cette requête entraîne une analyse de table, Amazon Keyspaces analyse toutes les partitions de la table, y compris les partitions sans données. # Estimez la consommation de capacité des transactions légères dans Amazon Keyspaces Les transactions légères (LWT) vous permettent d'effectuer des opérations d'écriture conditionnelle sur les données de votre table. Les opérations de mise à jour conditionnelle sont utiles lors de l'insertion, de la mise à jour et de la suppression d'enregistrements en fonction de conditions évaluant l'état actuel. Dans Amazon Keyspaces, toutes les opérations d'écriture nécessitent la cohérence LOCAL\$1QUORUM et leur utilisation est gratuite. LWTs La différence réside dans le fait que lorsqu'une vérification de l'état LWT aboutit`FALSE`, Amazon Keyspaces consomme des unités de capacité d'écriture WCUs () ou des unités de demande d'écriture (). LWTs WRUs Le nombre de lignes WCUs/WRUs consommées dépend de la taille de la ligne. Par exemple, si la taille de la ligne est de 2 Ko, l'écriture conditionnelle échouée consomme deux WCUs/WRUs. Si la ligne n'existe pas actuellement dans la table, l'opération en consomme un WCUs/WRUs. Pour déterminer le nombre de demandes ayant entraîné des échecs de vérification des conditions, vous pouvez surveiller la `ConditionalCheckFailed` métrique dans CloudWatch. ## Estimez les coûts LWT pour les tables avec Time to Live (TTL) LWTs peut nécessiter des unités de capacité de lecture (RCUs) ou des unités de demande de lecture (RRUs) supplémentaires pour les tables configurées avec TTL qui n'utilisent pas d'horodatage côté client. Lorsque la vérification de l'`IF EXISTS`état de nos `IF NOT EXISTS` mots clés est utilisée`FALSE`, les unités de capacité suivantes sont consommées : + RCUs/RRUs – If the row exists, the RCUs/RRUsconsommés sont basés sur la taille de la ligne existante. + RCUs/RRUs – If the row doesn't exist, a single RCU/RRUest consommé. Si la condition évaluée aboutit à une opération d'écriture réussie, WCUs/WRUs ils sont consommés en fonction de la taille de la nouvelle ligne. # Estimation de la consommation de capacité pour les colonnes statiques dans Amazon Keyspaces Dans un tableau Amazon Keyspaces avec des colonnes de regroupement, vous pouvez utiliser le `STATIC` mot clé pour créer une colonne statique. La valeur stockée dans une colonne statique est partagée entre toutes les lignes d'une partition logique. Lorsque vous mettez à jour la valeur de cette colonne, Amazon Keyspaces applique la modification automatiquement à toutes les lignes de la partition. Cette section explique comment calculer la taille codée des données lorsque vous écrivez dans des colonnes statiques. Ce processus est géré séparément du processus qui écrit des données dans les colonnes non statiques d'une ligne. Outre les quotas de taille pour les données statiques, les opérations de lecture et d'écriture sur des colonnes statiques affectent également la capacité de mesure et de débit des tables indépendamment. Pour les différences fonctionnelles avec Apache Cassandra lors de l'utilisation de colonnes statiques et de résultats de lecture par plage paginée, voir. [Pagination](functional-differences.md#functional-differences.paging) **Topics** + [Calculez la taille de colonne statique par partition logique dans Amazon Keyspaces](static-columns-estimate.md) + [Estimez les exigences de capacité et de débit pour les read/write opérations sur des données statiques dans Amazon Keyspaces](static-columns-metering.md) # Calculez la taille de colonne statique par partition logique dans Amazon Keyspaces Cette section explique comment estimer la taille codée des colonnes statiques dans Amazon Keyspaces. La taille codée est utilisée lorsque vous calculez votre facture et votre quota d'utilisation. Vous devez également utiliser la taille codée lorsque vous calculez les exigences de capacité de débit allouées pour les tables. Pour calculer la taille codée des colonnes statiques dans Amazon Keyspaces, vous pouvez suivre les directives suivantes. + 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. Ces octets de métadonnées sont pris en compte dans votre quota de taille de données statiques de 1 Mo par partition. Lorsque vous calculez la taille de vos données statiques, vous devez partir du principe que chaque colonne de clé de partition utilise les 3 octets complets de métadonnées. + Utilisez la taille brute des valeurs de données des colonnes statiques en fonction du type de données. Pour plus d’informations sur les types de données, consultez [Types de données](cql.elements.md#cql.data-types), + Ajoutez 104 octets à la taille des données statiques pour les métadonnées. + Les colonnes de clustering et les colonnes clés ordinaires non primaires ne sont pas prises en compte dans la taille des données statiques. Pour savoir comment estimer la taille des données non statiques au sein des lignes, consultez[Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md). La taille totale codée d'une colonne statique est basée sur la formule suivante : ``` partition key columns + static columns + metadata = total encoded size of static data ``` 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, une colonne normale et une colonne statique. ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2)); ``` Dans cet exemple, nous calculons la taille des données statiques de l'instruction suivante : ``` INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6); ``` Pour estimer le nombre total d'octets requis par cette opération d'écriture, vous pouvez suivre les étapes suivantes. 1. 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\$1col1) : ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. Calculez la taille de la deuxième colonne de la clé de partition (pk\$1col2) : ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. Ajoutez les deux colonnes pour obtenir la taille totale estimée des colonnes clés de partition : ``` 7 bytes + 7 bytes = 14 bytes for the partition key columns ``` 1. Ajoutez la taille des colonnes statiques. Dans cet exemple, nous n'avons qu'une seule colonne statique qui stocke un entier (ce qui nécessite 4 octets). 1. Enfin, pour obtenir la taille totale codée des données des colonnes statiques, additionnez les octets pour les colonnes clés primaires et les colonnes statiques, puis ajoutez les 104 octets supplémentaires pour les métadonnées : ``` 14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes. ``` Vous pouvez également mettre à jour les données statiques et non statiques avec la même instruction. Pour estimer la taille totale de l'opération d'écriture, vous devez d'abord calculer la taille de la mise à jour des données non statiques. Calculez ensuite la taille de la mise à jour de la ligne comme indiqué dans l'exemple sur[Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md), et ajoutez les résultats. Dans ce cas, vous pouvez écrire un total de 2 Mo : 1 Mo est le quota de taille de ligne maximum, et 1 Mo est le quota de taille de données statique maximale par partition logique. Pour calculer la taille totale d'une mise à jour de données statiques et non statiques dans la même instruction, vous pouvez utiliser la formule suivante : ``` (partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row) = total encoded size of data written ``` 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, une colonne normale et une colonne statique. ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, 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, static_col1) values(2,3,4,5,6,7); ``` Pour estimer le nombre total d'octets requis par cette opération d'écriture, vous pouvez suivre les étapes suivantes. 1. Calculez la taille totale codée des données statiques comme indiqué précédemment. Dans cet exemple, il s'agit de 122 octets. 1. Ajoutez la taille de la taille totale codée de la ligne en fonction de la mise à jour des données non statiques, en suivant les étapes décrites dans[Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md). Dans cet exemple, la taille totale de la mise à jour des lignes est de 134 octets. ``` 122 bytes for static data + 134 bytes for nonstatic data = 256 bytes. ``` # Estimez les exigences de capacité et de débit pour les read/write opérations sur des données statiques dans Amazon Keyspaces Les données statiques sont associées à des partitions logiques dans Cassandra, et non à des lignes individuelles. Les partitions logiques d'Amazon Keyspaces peuvent avoir une taille pratiquement indépendante en s'étendant sur plusieurs partitions de stockage physiques. Par conséquent, les compteurs Amazon Keyspaces écrivent les opérations sur les données statiques et non statiques séparément. En outre, les écritures qui incluent à la fois des données statiques et non statiques nécessitent des opérations sous-jacentes supplémentaires pour assurer la cohérence des données. Si vous effectuez une opération d'écriture mixte de données statiques et non statiques, cela entraîne deux opérations d'écriture distinctes, l'une pour les données non statiques et l'autre pour les données statiques. Cela s'applique à la fois aux modes de capacité à la demande et aux modes read/write de capacité provisionnée. L'exemple suivant explique comment estimer les unités de capacité de lecture (RCUs) et d'écriture requises (WCUs) lorsque vous calculez les exigences de capacité de débit allouée pour les tables d'Amazon Keyspaces comportant des colonnes statiques. Vous pouvez estimer la capacité dont votre table a besoin pour traiter les écritures incluant à la fois des données statiques et non statiques à l'aide de la formule suivante : ``` 2 x WCUs required for nonstatic data + 2 x WCUs required for static data ``` Par exemple, si votre application écrit 27 % KBs de données par seconde et que chaque écriture inclut 25,5 % KBs de données non statiques et 1,5 % KBs de données statiques, votre table en nécessite 56 WCUs (2 x 26 WCUs \$1 2 x 2 WCUs). Amazon Keyspaces mesure les lectures de données statiques et non statiques de la même manière que les lectures de plusieurs lignes. Par conséquent, le prix de lecture de données statiques et non statiques au cours d'une même opération est basé sur la taille agrégée des données traitées pour effectuer la lecture. Pour savoir comment surveiller les ressources sans serveur avec Amazon CloudWatch, consultez[Surveillance d'Amazon Keyspaces avec Amazon CloudWatch](monitoring-cloudwatch.md). # Estimer et provisionner la capacité d'une table multirégionale dans Amazon Keyspaces Vous pouvez configurer la capacité de débit d'une table multirégionale de deux manières : + Mode de capacité à la demande, mesuré en unités de demande d'écriture (WRUs) + Mode de capacité provisionnée avec mise à l'échelle automatique, mesurée en unités de capacité d'écriture () WCUs Vous pouvez utiliser le mode capacité provisionnée avec mise à l'échelle automatique ou le mode capacité à la demande pour garantir qu'une table multirégionale dispose d'une capacité suffisante pour effectuer des écritures répliquées pour toutes les tables. Régions AWS **Note** La modification du mode de capacité de la table dans l'une des régions modifie le mode de capacité de toutes les répliques. Par défaut, Amazon Keyspaces utilise le mode à la demande pour les tables multirégionales. Avec le mode à la demande, vous n'avez pas besoin de spécifier le débit de lecture et d'écriture que vous souhaitez que votre application exécute. Amazon Keyspaces s'adapte instantanément à vos charges de travail au fur et à mesure qu'elles augmentent ou diminuent pour atteindre un niveau de trafic atteint précédemment. Si le niveau de trafic d'une charge de travail atteint un nouveau pic, Amazon Keyspaces s'adapte rapidement pour s'adapter à la charge de travail. Si vous choisissez le mode de capacité provisionnée pour une table, vous devez configurer le nombre d'unités de capacité de lecture (RCUs) et d'unités de capacité d'écriture (WCUs) par seconde dont votre application a besoin. Pour planifier les besoins en capacité de débit d'une table multirégionale, vous devez d'abord estimer le nombre de unités WCUs par seconde nécessaires pour chaque région. Vous ajoutez ensuite les écritures provenant de toutes les régions dans lesquelles votre table est répliquée, et vous utilisez la somme pour allouer de la capacité à chaque région. Cela est nécessaire car chaque écriture effectuée dans une région doit également être répétée dans chaque région de réplication. Si la table ne dispose pas d'une capacité suffisante pour gérer les écritures provenant de toutes les régions, des exceptions de capacité se produiront. En outre, les temps d'attente pour la réplication interrégionale augmenteront. Par exemple, si vous avez une table multirégionale dans laquelle vous attendez 5 écritures par seconde dans l'est des États-Unis (Virginie du Nord), 10 écritures par seconde dans l'est des États-Unis (Ohio) et 5 écritures par seconde en Europe (Irlande), vous devez vous attendre à ce que la table en consomme 20 WCUs dans chaque région : États-Unis est (Virginie du Nord), États-Unis est (Ohio) et Europe (Irlande). Cela signifie que dans cet exemple, vous devez en prévoir 20 WCUs pour chacune des répliques de la table. Vous pouvez surveiller la consommation de capacité de votre table à l'aide d'Amazon CloudWatch. Pour de plus amples informations, veuillez consulter [Surveillance d'Amazon Keyspaces avec Amazon CloudWatch](monitoring-cloudwatch.md). Chaque écriture est facturée comme 1 WCU, vous verrez donc un total de 60 unités WCUs facturées dans cet exemple. Pour plus d'informations sur les tarifs, consultez les tarifs [d'Amazon Keyspaces (pour Apache Cassandra](https://aws.amazon.com/keyspaces/pricing)). Pour plus d'informations sur la capacité allouée avec le dimensionnement [Gérez automatiquement la capacité de débit grâce au dimensionnement automatique d'Amazon Keyspaces](autoscaling.md) automatique d'Amazon Keyspaces, consultez. **Note** Si une table s'exécute en mode capacité allouée avec mise à l'échelle automatique, la capacité d'écriture allouée est autorisée à flotter dans les limites de ces paramètres de dimensionnement automatique pour chaque région. # Estimez la consommation de capacité de lecture et d'écriture avec Amazon CloudWatch dans Amazon Keyspaces Pour estimer et surveiller la consommation de capacité de lecture et d'écriture, vous pouvez utiliser un CloudWatch tableau de bord. Pour plus d'informations sur les statistiques disponibles pour Amazon Keyspaces, consultez. [Statistiques et dimensions d'Amazon Keyspaces](metrics-dimensions.md) Pour surveiller les unités de capacité de lecture et d'écriture consommées par une instruction spécifique avec CloudWatch, vous pouvez suivre ces étapes. 1. Création d'une nouvelle table avec des exemples de données 1. Configurez un tableau de bord Amazon Keyspaces pour le CloudWatch tableau. Pour commencer, vous pouvez utiliser un modèle de tableau de bord disponible sur [Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates). 1. Exécutez l'instruction CQL, par exemple à l'aide de l'`ALLOW FILTERING`option, et vérifiez les unités de capacité de lecture consommées pour l'analyse complète du tableau dans le tableau de bord.