2015-06-10 11 views
5

Sono nuovo di Kinesis, quindi questa potrebbe sembrare una domanda molto semplice, ma non sono stato in grado di trovare una risposta chiara a quale sia la differenza effettiva tra una transazione di lettura e scrittura in un flusso Kinesis.Leggere e scrivere transazioni in Amazon Kinesis

parti pertinenti da Amazon Kinesis Limits:

  • GetShardIterator in grado di fornire fino a 5 transazioni al secondo per ogni frammento aperta.
  • GetRecords può recuperare 10 MB di dati.
  • Ogni frammento può supportare fino a 5 transazioni al secondo per le letture, fino a una velocità di lettura dei dati totale massima di 2 MB al secondo.
  • Ogni frammento può supportare fino a 1024 record al secondo per le scritture, fino a una velocità massima di scrittura dei dati di 1 MB al secondo (comprese le chiavi di partizione). Questo limite di scrittura si applica a operazioni come PutRecord e PutRecords.

Esso menziona chiaramente 5 letture e 1024 scrive al secondo per ogni frammento. Perché le letture sono molto più costose delle scritture o c'è un concetto cruciale di Kinesis che non ho afferrato?

risposta

4

Kinesis consente di importare dati granulari in un flusso e di leggere batch di record per elaborare le informazioni. Quindi il volume di megabyte che puoi leggere al secondo è molto più importante del numero di transazioni di lettura che ottieni per frammento. Ad esempio, potresti avere un sito Web occupato a generare migliaia di visualizzazioni al minuto e un cluster EMR per elaborare i registri di accesso. In questo scenario, avrai più eventi in scrittura che leggi eventi. Lo stesso vale per clickstream, le transazioni finanziarie, i social media si nutre, registra, ed eventi location-tracciamento, ecc

+0

Quindi le 5/1024 transazioni al secondo si applicano solo alle singole chiamate GetRecords e PutRecord (s), in cui un singolo GetRecords potrebbe restituire migliaia di dischi da elaborare per me? – KennethJ

+0

Sì. È giusto @KennethJ. –

5

Il caso di utilizzo comune è che più produttori stanno scrivendo i loro eventi a Kinesis. Ad esempio più server Web, più browser o più dispositivi mobili. Ogni produttore può scrivere più eventi, uno per uno o in un lotto di massimo 500 eventi.

D'altra parte i consumatori degli eventi sono un numero limitato di processi. Il caso di utilizzo semplice è che un lettore "lento" sta leggendo batch di eventi dal flusso di Kinesis (ad esempio, 10.000 eventi ogni 10 secondi) e li scrive su S3 come un singolo file di registro.

In tal caso si scrivono migliaia di eventi (principalmente uno per uno), ma si sta leggendo solo una volta al secondo (o 10 secondi nell'esempio sopra) tutti gli eventi che sono stati aggiunti allo stream in questo periodo di tempo. Pertanto, il rapporto tra scritture e letture è 1024: 1.

Nella maggior parte dei casi ci sono un numero limitato di utenti dal flusso di Kinesis e non un singolo lettore. Ad esempio, sopra al lettore "lento" sopra, puoi avere un lettore "veloce" che sta analizzando gli eventi in arrivo e li sta filtrando o riassumendo i loro valori, per essere in grado di reagire in tempo reale. Questo lettore veloce è in grado di identificare le transazioni fraudolente e bloccarle o calcolare contatori in tempo reale per i dashboard operativi.

Ancora il numero di letture sarà piccolo, relativamente al numero di scritture. In tal caso, il lettore "veloce" leggerà ogni 1/4 di secondo per consentire la reazione quasi in tempo reale agli eventi.Pertanto, il rapporto tra le scritture e le letture sarà 1024: 5 (= 1 + 4)

Problemi correlati