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.
# Bonnes pratiques de modélisation des données : recommandations pour la conception de modèles de données
Une modélisation des données efficace est essentielle pour optimiser les performances et minimiser les coûts lorsque vous travaillez avec Amazon Keyspaces (pour Apache Cassandra). Cette rubrique présente les principales considérations et recommandations relatives à la conception de modèles de données adaptés aux modèles d'accès aux données de votre application.
+ **Conception de la clé de partition** — La clé de partition joue un rôle essentiel dans la détermination de la manière dont les données sont distribuées entre les partitions d'Amazon Keyspaces. Le choix d'une clé de partition appropriée peut avoir un impact significatif sur les performances des requêtes et les coûts de débit. Cette section décrit les stratégies de conception de clés de partition qui favorisent une répartition uniforme des activités de lecture et d'écriture entre les partitions.
+ **Considérations clés :**
+ **Répartition uniforme des activités : visez une activité** de lecture et d'écriture uniforme sur toutes les partitions afin de minimiser les coûts de débit et d'exploiter efficacement la capacité de rafale.
+ **Modèles d'accès** — Alignez le design de votre clé de partition avec les principaux modèles d'accès aux données de votre application.
+ **Taille de partition** : évitez de créer des partitions trop grandes, car cela peut avoir un impact sur les performances et augmenter les coûts.
Pour visualiser et concevoir des modèles de données plus facilement, vous pouvez utiliser le [NoSQL](workbench.md) Workbench.
**Topics**
+ [Comment utiliser efficacement les clés de partition dans Amazon Keyspaces](bp-partition-key-design.md)
# Comment utiliser efficacement les clés de partition dans Amazon Keyspaces
La clé primaire qui identifie de manière unique chaque ligne d'une table Amazon Keyspaces peut être composée d'une ou de plusieurs colonnes de clé de partition, qui déterminent les partitions dans lesquelles les données sont stockées, et d'une ou plusieurs colonnes de clustering facultatives, qui définissent la manière dont les données sont regroupées et triées au sein d'une partition.
Étant donné que la clé de partition définit le nombre de partitions dans lesquelles vos données sont stockées et la manière dont les données sont réparties entre ces partitions, le choix de votre clé de partition peut avoir un impact significatif sur les performances de vos requêtes. En général, vous devez concevoir votre application pour une activité uniforme sur toutes les partitions du disque.
La répartition uniforme des activités de lecture et d'écriture de votre application sur toutes les partitions permet de minimiser les coûts de débit, et cela s'applique aux modes à la demande ainsi qu'aux modes de read/write capacité provisionnée. Par exemple, si vous utilisez le mode capacité provisionnée, vous pouvez déterminer les modèles d'accès dont votre application a besoin et estimer le nombre total d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) requises par chaque table. Amazon Keyspaces prend en charge vos modèles d'accès en utilisant le débit que vous avez fourni, à condition que le trafic sur une partition donnée ne dépasse pas 3 000 ou 1 000. RCUs WCUs
Lorsqu'une partition présente un débit de lecture ou d'écriture élevé et soutenu, en fonction des modèles de trafic, Amazon Keyspaces peut automatiquement diviser la partition en deux nouvelles partitions. Chaque nouvelle partition contient un sous-ensemble des lignes de la partition d'origine, répartissant le débit uniformément entre les deux partitions.
Amazon Keyspaces offre une flexibilité supplémentaire dans le provisionnement du débit par partition en fournissant une capacité de rafale. Pour plus d'informations, consultez. [Utilisez efficacement la capacité de pointe dans Amazon Keyspaces](throughput-bursting.md)
**Topics**
+ [Utilisez le sharding en écriture pour répartir uniformément les charges de travail entre les partitions](bp-partition-key-sharding.md)
# Utilisez le sharding en écriture pour répartir uniformément les charges de travail entre les partitions
L'un des moyens de mieux répartir les écritures sur une partition dans Amazon Keyspaces consiste à étendre l'espace. Vous pouvez effectuer cette opération de plusieurs manières. Vous pouvez ajouter une colonne de clé de partition supplémentaire dans laquelle vous écrivez des nombres aléatoires pour répartir les lignes entre les partitions. Ou vous pouvez utiliser un nombre qui est calculé en fonction d’une information sur laquelle porte la requête.
## Sharding à l'aide de clés de partition composées et de valeurs aléatoires
Une stratégie pour répartir les charges de manière plus uniforme sur une partition consiste à ajouter une colonne de clé de partition supplémentaire dans laquelle vous écrivez des nombres aléatoires. Vous pouvez alors randomiser les écritures sur l’espace plus important.
Par exemple, considérez le tableau suivant qui contient une clé de partition unique représentant une date.
```
CREATE TABLE IF NOT EXISTS tracker.blogs (
publish_date date,
title text,
description int,
PRIMARY KEY (publish_date));
```
Pour répartir plus uniformément ce tableau entre les partitions, vous pouvez inclure une colonne de clé de partition supplémentaire `shard` qui stocke des nombres aléatoires. Par exemple :
```
CREATE TABLE IF NOT EXISTS tracker.blogs (
publish_date date,
shard int,
title text,
description int,
PRIMARY KEY ((publish_date, shard)));
```
Lorsque vous insérez des données, vous pouvez choisir un nombre aléatoire entre `1` et `200` pour la `shard` colonne. Cela produit des valeurs de clé de partition composées telles que `(2020-07-09, 1)``(2020-07-09, 2)`,, et ainsi de suite`(2020-07-09, 200)`. Puisque vous randomisez la clé de partition, les écritures quotidiennes sur la table sont réparties uniformément entre plusieurs partitions. Cela permet un meilleur parallélisme et un débit général plus élevé.
Toutefois, pour lire toutes les lignes d'un jour donné, vous devez rechercher toutes les partitions dans les lignes, puis fusionner les résultats. Par exemple, vous devez d'abord émettre une `SELECT` instruction pour la valeur de la clé de partition`(2020-07-09, 1)`. Émettez ensuite une autre `SELECT` déclaration pour`(2020-07-09, 2)`, et ainsi de suite`(2020-07-09, 200)`. Enfin, votre application devra fusionner les résultats de toutes ces `SELECT` instructions.
## Sharding à l'aide de clés de partition composées et de valeurs calculées
Une stratégie de randomisation peut considérablement améliorer le débit d’écriture. Mais il est difficile de lire une ligne spécifique car vous ne savez pas quelle valeur a été écrite dans la `shard` colonne au moment où la ligne a été écrite. Pour faciliter la lecture des lignes individuelles, vous pouvez utiliser une autre stratégie. Au lieu d'utiliser un nombre aléatoire pour répartir les lignes entre les partitions, utilisez un nombre que vous pouvez calculer en fonction de l'élément sur lequel vous souhaitez effectuer une requête.
Considérons l’exemple précédent, dans lequel une table utilise la date du jour dans la clé de partition. Supposons maintenant que chaque ligne possède une `title` colonne accessible et que vous ayez le plus souvent besoin de rechercher les lignes par titre en plus de leur date. Avant que votre application n'écrive la ligne dans la table, elle peut calculer une valeur de hachage en fonction du titre et l'utiliser pour remplir la `shard` colonne. Le calcul peut se traduire par un nombre compris entre 1 et 200 assez uniformément distribué, à l’image de ce que la stratégie de randomisation produit.
Un simple calcul suffirait probablement, comme le produit des valeurs des points de code UTF-8 pour les caractères du titre, modulo 200, \$1 1. La valeur de la clé de partition composée serait alors la combinaison de la date et du résultat du calcul.
Avec cette stratégie, les écritures sont réparties uniformément entre les valeurs de clé de partition, et de ce fait entre les partitions physiques. Vous pouvez facilement exécuter une `SELECT` instruction pour une ligne et une date spécifiques, car vous pouvez calculer la valeur de la clé de partition pour une `title` valeur spécifique.
Pour lire toutes les lignes d'un jour donné, vous devez toujours `SELECT` chacune des `(2020-07-09, N)` clés (1 `N` à 200), et votre application doit ensuite fusionner tous les résultats. L’avantage est que vous évitez qu’une valeur de clé de partition « critique » ne prenne l’ensemble de la charge de travail.