In un'applicazione web consumer-consumer, quale dovrebbe essere il processo di pensiero per creare una chiave di partizione per un frammento di stream di kinesis. Supponiamo, ho un flusso kinesis con 16 frammenti, quante chiavi di partizione dovrei creare? Dipende davvero dal numero di frammenti?Come decidere il numero totale di chiavi di partizione nello stream kinesis di AWS?
partizione (o Hash) chiave: parte da 1 fino a 340282366920938463463374607431768211455. consente di dire ~ 34020 * 10^34, io omettere 10^34 per facilità ...
Se si dispone di 30 frammenti, uniformemente diviso , ognuno dovrebbe coprire 1134 * 10^34 chiavi hash. La copertura dovrebbe essere come questa.
Shard-00: 0 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020
E se si dispone di 3 applicazioni consumer (l'ascolto di questi 30 frammenti) ciascuno dovrebbe ascoltare 10 frammenti (ottimale equilibrata).
Ciò spiega anche le operazioni Unisci e Dividi su un flusso.
Shard-31: 0 - 567 Shard-32: 568 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020
Sede, Shard-00 non sarà più accettare nuovi dati. I nuovi record inseriti in Kinesis stream con lo stesso intervallo di chiavi di partizione (come Shard-00) verranno posizionati in Shard-31 o Shard-32.
Durante l'invio di dati a Kinesis (ad esempio lato produttore), non dovresti preoccuparti di "a quale shard i dati vanno". L'invio di un numero casuale (o uuid, o timestamp corrente in millis) sarebbe la soluzione migliore per ridimensionare e distribuire efficacemente i dati sui frammenti. A meno che non siate preoccupati per l'ordine dei record in un singolo frammento, è meglio scegliere un numero casuale/una chiave di partizione che cambia costantemente per la richiesta put_record.
In Java è possibile utilizzare "putRecordsRequestEntry.setPartitionKey(Long.toString(System.currentTimeMillis()))" o "putRecordRequest.setPartitionKey(Long.toString(System.currentTimeMillis()))" possono essere degli esempi.
Abbiamo riscontrato una brutta situazione con ** timestamp **. In millisecondi le differenze di timestamp attuale come chiave di partizione non funzionano come previsto. Pertanto, lo abbiamo modificato con ** uuid **. –
Dipende totalmente dal caso d'uso. Tutto ciò che serve per assicurarsi che tutti i dati rilevanti vadano a un singolo frammento in modo da poter aggregare i dati per una chiave, se necessario.
Se non si dispone di tale requisito utilizzando qualsiasi chiave casuale dovrebbe andare bene.
Dai un'occhiata a questa domanda, forse aiuta; http://stackoverflow.com/a/31377161/1622134 – az3