Un'azienda manifatturiera raccoglie dati da dispositivi IoT tramite Amazon Kinesis Data Streams. Il payload contiene l'ID del dispositivo, la data di acquisizione, il tipo di misurazione, il valore della misurazione e l'ID della struttura. Il produttore utilizza l'ID della struttura come chiave di partizione. Il team operativo ha riscontrato molte eccezioni WriteThroughputExceeded: alcune shard sono sovraccariche mentre altre sono inattive. Come dovrebbe risolvere l'azienda questo problema di hot-shard?

La risposta corretta è cambiare la chiave di partizione dall'ID della struttura a una chiave generata casualmente. Questo perché una chiave di partizione casuale distribuisce uniformemente i record tra tutte le shard disponibili, risolvendo il problema delle hot-shard (shard sovraccariche) e delle cold-shard (shard inattive) causato dall'uso di un ID di struttura che probabilmente ha un numero limitato di valori e quindi concentra i dati su poche shard. Aumentare il numero di shard non risolverebbe il problema se la chiave di partizione continua a concentrare i dati. Archiviare i dati lato produttore non è una soluzione per le hot-shard in Kinesis. Cambiare la chiave di partizione alla data di acquisizione potrebbe creare un problema simile se i dati sono concentrati in specifici intervalli di tempo.