Conception de clés de partition pour répartir votre charge de travail dans DynamoDB

La partie clé de partition de la clé primaire d'une table détermine les partitions logiques dans lesquelles les données d'une table sont stockées. Cela a ensuite un impact sur les partitions physiques sous-jacentes. La conception d'une clé de partition qui ne distribue pas efficacement les demandes d'I/O risque de créer des partitions « sensibles » qui limiteront et utiliseront inefficacement votre capacité d'I/O allouée.

L'utilisation optimale du débit alloué d'une table ne dépend pas seulement des modèles de charge de travail des éléments individuels, mais également de la conception de la clé de partition. Cela ne signifie pas que vous devez accéder à toutes les valeurs de clé de partition pour atteindre un niveau de débit efficace, ni même que le pourcentage de valeurs de clé de partition accédées doit être élevé. Cela signifie que plus votre charge de travail accède à des valeurs de clé de partition distinctes, plus ces demandes sont réparties dans l'espace partitionné. En général, vous utiliserez votre débit provisionné de manière plus efficace à mesure que le ratio entre les valeurs de clé de partition consultées et le nombre total de valeurs de clé de partition augmente.

Voici une comparaison de l'efficacité du débit alloué de plusieurs schémas courants de clé de partition.

Valeur de la clé de partition	Uniformité
ID utilisateur, quand l'application a de nombreux utilisateurs.	Bon
Code d'état, où il existe seulement quelques codes d'état possibles.	Mauvaise
Date de création de l'élément, arrondie à la période la plus proche (par exemple, jour, heure ou minute).	Mauvaise
ID d'appareil, où chaque appareil accède aux données à des intervalles relativement similaires.	Bon
ID d'appareil où, même si un grand nombre d'appareils est suivi, l'un est bien plus populaire que tous les autres.	Mauvaise

Si une seule table n'a qu'un petit nombre de valeurs de clé de partition, pensez à répartir vos opérations d'écriture entre des valeurs de clé de partition plus distinctes. En d'autres termes, structurez les éléments de clé primaire pour éviter une valeur de partition « critique » (fortement demandée) qui ralentit les performances globales.

Par exemple, imaginons une table avec une clé primaire composite. La clé de partition représente la date de création de l'élément, arrondie au jour le plus proche. La clé de tri est un identificateur d'élément. Sur un jour donné, disons le 2014-07-09, tous les nouveaux éléments sont écrits sur cette même valeur de clé de partition (et sur la partition physique correspondante).

Si la table s'adapte entièrement à une seule partition (en tenant compte de la croissance de vos données au fil du temps) et si les exigences en débit de lecture et d'écriture de votre application ne dépassent pas les capacités en lecture et en écriture d'une seule partition, votre application ne doit rencontrer aucune limitation inattendue comme résultat du partitionnement.

Pour utiliser No SQL Workbench pour DynamoDB afin de visualiser la conception de votre clé de partition, voir. Création de modèles de données avec No SQL Workbench