Ho un caso d'uso in cui ci sarà flusso di dati in arrivo e non posso consumarlo allo stesso ritmo e ho bisogno di un buffer. Questo può essere risolto usando una coda SNS-SQS. Sono venuto a sapere che Kinesis risolve lo stesso scopo, quindi qual è la differenza? Perché dovrei preferire (o non dovrei preferire) la Kinesis?
Risposte:
Sulla superficie sono vagamente simili, ma il tuo caso d'uso determinerà quale strumento è appropriato. IMO, se riesci a cavartela con SQS allora dovresti - se farà quello che vuoi, sarà più semplice ed economico, ma ecco una spiegazione migliore dalle FAQ di AWS che fornisce esempi di casi d'uso appropriati per entrambi gli strumenti per aiutarti a decidere:
Tieni presente che questa risposta è stata corretta per giugno 2015
Dopo aver studiato il problema per un po ', avendo in mente la stessa domanda, ho scoperto che SQS (con SNS) è preferito per la maggior parte dei casi d'uso a meno che l'ordine dei messaggi non sia importante per te (SQS non garantisce FIFO sui messaggi).
Ci sono 2 principali vantaggi per Kinesis:
Entrambi i vantaggi possono essere raggiunti usando SNS come fan out per SQS. Ciò significa che il produttore del messaggio invia solo un messaggio a SNS, quindi SNS distribuisce il messaggio a più SQS, uno per ogni applicazione consumer. In questo modo puoi avere tutti i consumatori che vuoi senza pensare alla capacità di condivisione.
Inoltre, abbiamo aggiunto un altro SQ che è abbonato a SNS che conterrà i messaggi per 14 giorni. Nel caso normale nessuno legge da questo SQS ma in caso di un bug che ci fa desiderare di riavvolgere i dati possiamo facilmente leggere tutti i messaggi da questo SQS e rispedirli a SNS. Mentre Kinesis prevede solo una conservazione di 7 giorni.
In conclusione, SNS + SQS è molto più semplice e offre la maggior parte delle funzionalità. IMO hai bisogno di un caso davvero forte per scegliere Kinesis su di esso.
splitin SNS split the message to multiple SQSsquanto non suddivide i messaggi in pezzi ma li copia in più destinazioni.
Kinesis supporta funzionalità di più consumatori, il che significa che gli stessi record di dati possono essere elaborati contemporaneamente o in momenti diversi entro 24 ore presso consumatori diversi, un comportamento simile in SQS può essere ottenuto scrivendo in più code e i consumatori possono leggere da più code. Tuttavia, la scrittura di nuovo in più code aggiungerà la latenza dei secondi secondari {pochi millisecondi} nel sistema.
In secondo luogo, Kinesis fornisce funzionalità di routing per indirizzare selettivamente i record di dati a diversi frammenti utilizzando la chiave di partizione che può essere elaborata da particolari istanze EC2 e può abilitare il calcolo di micro batch {Conteggio e aggregazione}.
Lavorare su qualsiasi software AWS è facile ma con SQS è il più semplice. Con Kinesis, è necessario eseguire il provisioning di frammenti sufficienti in anticipo, aumentando in modo dinamico il numero di frammenti per gestire il carico di picco e diminuirlo per risparmiare sui costi necessari anche per la gestione. è dolore in Kinesis, non sono necessarie cose del genere con SQS. SQS è scalabile all'infinito.
La semantica di queste tecnologie è diversa perché progettata per supportare diversi scenari:
Comprendiamo la differenza con l'esempio.
Una volta che l'elaborazione di un articolo non può essere separata dall'elaborazione di un altro, è necessario disporre della semantica di Kinesis per gestire tutti i casi in modo sicuro.
Estratto dalla documentazione AWS :
Consigliamo Amazon Kinesis Streams per casi d'uso con requisiti simili ai seguenti:
Instradamento dei record correlati allo stesso processore di record (come nello streaming di MapReduce). Ad esempio, il conteggio e l'aggregazione sono più semplici quando tutti i record per una determinata chiave vengono instradati allo stesso processore di record.
Ordine dei record. Ad esempio, si desidera trasferire i dati del registro dall'host dell'applicazione all'host di elaborazione / archiviazione mantenendo l'ordine delle istruzioni del registro.
Possibilità per più applicazioni di utilizzare contemporaneamente lo stesso flusso. Ad esempio, hai un'applicazione che aggiorna una dashboard in tempo reale e un'altra che archivia i dati su Amazon Redshift. Si desidera che entrambe le applicazioni consumino dati dallo stesso flusso contemporaneamente e indipendentemente.
Possibilità di consumare registrazioni nello stesso ordine poche ore dopo. Ad esempio, hai un'applicazione di fatturazione e un'applicazione di controllo che viene eseguita alcune ore dietro l'applicazione di fatturazione. Poiché Amazon Kinesis Streams archivia i dati per un massimo di 7 giorni, è possibile eseguire l'applicazione di controllo fino a 7 giorni dopo l'applicazione di fatturazione.
Consigliamo Amazon SQS per casi d'uso con requisiti simili ai seguenti:
Semantica della messaggistica (come ack / fail a livello di messaggio) e timeout di visibilità. Ad esempio, si dispone di una coda di elementi di lavoro e si desidera tenere traccia del completamento corretto di ciascun elemento in modo indipendente. Amazon SQS tiene traccia di ack / fail, quindi l'applicazione non deve mantenere un checkpoint / cursore persistenti. Amazon SQS eliminerà i messaggi confermati e riconsegnerà i messaggi non riusciti dopo un timeout di visibilità configurato.
Ritardo messaggio individuale. Ad esempio, si dispone di una coda lavori e è necessario pianificare i singoli lavori con un ritardo. Con Amazon SQS, puoi configurare singoli messaggi in modo che abbiano un ritardo fino a 15 minuti.
Aumento dinamico della concorrenza / throughput al momento della lettura. Ad esempio, hai una coda di lavoro e desideri aggiungere altri lettori fino a quando il backlog non viene cancellato. Con Amazon Kinesis Streams, puoi scalare fino a un numero sufficiente di frammenti (nota, tuttavia, che dovrai fornire in anticipo abbastanza frammenti).
Sfruttando la capacità di Amazon SQS di ridimensionare in modo trasparente. Ad esempio, si bufferizzano le richieste e il carico cambia a seguito di picchi di carico occasionali o della crescita naturale della propria attività. Poiché ogni richiesta memorizzata può essere elaborata in modo indipendente, Amazon SQS può ridimensionare in modo trasparente per gestire il carico senza alcuna istruzione di provisioning.
Il vantaggio più grande per me è il fatto che Kinesis è una coda riproducibile e SQS no. Quindi puoi avere più consumatori degli stessi messaggi di Kinesis (o dello stesso consumatore in momenti diversi) in cui con SQS, una volta che un messaggio è stato intercettato, è passato da quella coda. SQS è meglio per le code dei lavoratori a causa di ciò.
Un'altra cosa: Kinesis può innescare una Lambda, mentre SQS no. Quindi con SQS devi fornire un'istanza EC2 per elaborare i messaggi SQS (e gestirla se fallisce), oppure devi avere una Lambda programmata (che non si ingrandisce o diminuisce - ne ottieni solo una al minuto) .
Modifica: questa risposta non è più corretta. SQS può attivare direttamente Lambda a partire da giugno 2018
I modelli di prezzo sono diversi, quindi a seconda del caso d'uso l'uno o l'altro potrebbe essere più economico. Utilizzando il caso più semplice (escluso SNS):
Collegando i prezzi attuali e non tenendo conto del livello gratuito, se si inviano 1 GB di messaggi al giorno alla dimensione massima del messaggio, Kinesis costerà molto più di SQS ($ 10,82 / mese per Kinesis contro $ 0,20 / mese per SQS) . Ma se invii 1 TB al giorno, Kinesis è un po 'più economico ($ 158 / mese contro $ 201 / mese per SQS).
Dettagli: SQS addebita $ 0,40 per milione di richieste (64 KB ciascuno), quindi $ 0,00655 per GB. A 1 GB al giorno, questo è poco meno di $ 0,20 al mese; a 1 TB al giorno, arriva a poco più di $ 201 al mese.
Kinesis addebita $ 0,014 per milione di richieste (25 KB ciascuna), quindi $ 0,00059 per GB. A 1 GB al giorno, questo è inferiore a $ 0,02 al mese; a 1 TB al giorno, è di circa $ 18 al mese. Tuttavia, Kinesis addebita anche $ 0,015 all'ora di shard. Hai bisogno di almeno 1 frammento per 1 MB al secondo. Con 1 GB al giorno, 1 frammento sarà abbondante, quindi aggiungerai altri $ 0,36 al giorno, per un costo totale di $ 10,82 al mese. A 1 TB al giorno, avrai bisogno di almeno 13 frammenti, che aggiungono altri $ 4,68 al giorno, per un costo totale di $ 158 al mese.
Kinesis risolve il problema della parte della mappa in un tipico scenario di riduzione della mappa per lo streaming dei dati. Mentre SQS non ne è sicuro. Se si dispone di dati di streaming che devono essere aggregati su una chiave, kinesis si assicura che tutti i dati per quella chiave vadano su un frammento specifico e il frammento possa essere consumato su un singolo host rendendo l'aggregazione su chiave più semplice rispetto a SQS
Aggiungerò un'altra cosa che nessun altro ha menzionato: SQS è più costoso di molti ordini di grandezza.
Kinesis Use Cases
SQS Use Cases