Une entreprise manufacturière collecte des données d'appareils IoT via Amazon Kinesis Data Streams. La charge utile contient l'ID de l'appareil, la date de capture, le type de mesure, la valeur de la mesure et l'ID de l'installation. Le producteur utilise l'ID de l'installation comme clé de partition. L'équipe des opérations a observé de nombreuses exceptions WriteThroughputExceeded : certains shards sont surchargés tandis que d'autres sont inactifs. Comment l'entreprise devrait-elle résoudre ce problème de shard surchargé (hot-shard) ?

La bonne réponse est de changer la clé de partition de l'ID de l'installation à une clé générée aléatoirement. L'ID de l'installation est une clé de partition à faible cardinalité, ce qui signifie qu'il y a un nombre limité de valeurs uniques. Si un petit nombre d'installations génèrent un volume de données beaucoup plus élevé que les autres, cela conduit à des shards surchargés (hot shards) et à des exceptions WriteThroughputExceeded. Utiliser une clé générée aléatoirement, ou une clé composite incluant l'ID de l'appareil et un nombre aléatoire, distribue les enregistrements plus uniformément sur tous les shards, évitant ainsi les surcharges. Augmenter le nombre de shards ne résoudrait pas le problème fondamental de la distribution inégale des données causée par une clé de partition à faible cardinalité. Archiver les données côté producteur réduirait le volume mais ne corrigerait pas la distribution inégale des données restantes. Changer la clé de partition à la date de capture créerait un problème similaire ou pire, car toutes les données d'une même journée seraient dirigées vers un nombre très limité de shards, voire un seul.