Utilisation du partitionnement d'écriture pour une répartition équitable des charges de travail

Une manière de mieux distribuer les écritures sur un espace de clé de partition dans Amazon DynamoDB consiste à développer l'espace. Vous pouvez effectuer cette opération de plusieurs manières. Vous pouvez ajouter un nombre aléatoire aux valeurs de clé de partition pour répartir les éléments entre les partitions. Ou vous pouvez utiliser un nombre qui est calculé en fonction d'une information sur laquelle porte la requête.

Partitionnement à l'aide de suffixes aléatoires

L'ajout d'un nombre aléatoire à la fin des valeurs de clé de partition constitue une stratégie permettant de répartir plus équitablement des charges sur un espace de clé de partition. Vous pouvez alors randomiser les écritures sur l'espace plus important.

Par exemple, dans le cas d'une clé de partition représentant la date du jour, vous pouvez choisir un nombre aléatoire compris entre 1 et 200 et le concaténer en tant que suffixe avec la date. Cela génère des valeurs de clé de partition telles que 2014-07-09.1, 2014-07-09.2, et ainsi de suite jusqu'à 2014-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 tous les éléments d'un jour donné, vous devrez interroger les éléments et rechercher tous les suffixes, puis fusionner les résultats. Par exemple, vous devez d'abord lancer une requête Query pour la valeur de clé de partition 2014-07-09.1. Ensuite, émettez une autre Query pour 2014-07-09.2, et ainsi de suite, jusqu'à 2014-07-09.200. Enfin, votre application doit fusionner les résultats de toutes ces demandes Query.

Partitionnement à l'aide de suffixes calculés

Une stratégie de randomisation peut considérablement améliorer le débit d'écriture. Cependant, il est difficile de lire un élément spécifique, car vous ne connaissez pas la valeur de suffixe utilisée lors de l'écriture de l'élément. Pour faciliter la lecture d'éléments individuels, vous pouvez utiliser une autre stratégie. Plutôt que d'utiliser un nombre aléatoire pour répartir les éléments sur les partitions, utilisez un nombre que vous pouvez calculer selon l'objet sur lequel vous souhaitez faire porter l'interrogation.

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 élément a un attribut OrderId accessible, et que vous devez le plus souvent rechercher des éléments par ID de commande en plus de la date. Avant que votre application n'écrive l'élément sur la table, elle peut calculer un suffixe de hachage en fonction de l'ID de commande et l'ajouter à la date de clé de partition. 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, tel que le produit des valeurs de point de code UTF-8 pour les caractères de l'ID de commande, modulo 200, + 1. La valeur de clé de partition sera alors la date concaténée avec le 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 opération GetItem pour un élément et une date donnés, car vous pouvez calculer la valeur de clé de partition pour une valeur OrderId spécifique.

Pour lire tous les éléments pour un jour donné, vous devez toujours interroger (Query) chacune des clés 2014-07-09.N (où N est 1–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.

Note

Pour une stratégie encore plus efficace conçue spécialement pour gérer des données en séries chronologiques volumineuses, consultez Données de séries temporelles.