Ich habe einen Anwendungsfall, in dem Datenströme kommen, und ich kann sie nicht im gleichen Tempo verbrauchen und benötige einen Puffer. Dies kann mithilfe einer SNS-SQS-Warteschlange gelöst werden. Ich habe erfahren, dass die Kinesis denselben Zweck löst. Was ist also der Unterschied? Warum sollte ich Kinesis bevorzugen (oder nicht bevorzugen)?
Antworten:
An der Oberfläche sind sie sich vage ähnlich, aber Ihr Anwendungsfall bestimmt, welches Werkzeug geeignet ist. IMO, wenn Sie mit SQS auskommen können, sollten Sie - wenn es das tut, was Sie wollen, wird es einfacher und billiger, aber hier ist eine bessere Erklärung aus den AWS-FAQ, die Beispiele für geeignete Anwendungsfälle für beide Tools enthält helfen Ihnen bei der Entscheidung:
Beachten Sie, dass diese Antwort für Juni 2015 korrekt war
Nachdem ich das Problem eine Weile untersucht hatte und dieselbe Frage im Auge hatte, stellte ich fest, dass SQS (mit SNS) für die meisten Anwendungsfälle bevorzugt wird, es sei denn, die Reihenfolge der Nachrichten ist für Sie wichtig (SQS garantiert kein FIFO für Nachrichten).
Kinesis bietet zwei Hauptvorteile:
Beide Vorteile können durch die Verwendung von SNS als Fan-Out für SQS erzielt werden. Dies bedeutet, dass der Produzent der Nachricht nur eine Nachricht an SNS sendet. Anschließend fächert der SNS die Nachricht an mehrere SQSs auf, eine für jede Verbraucheranwendung. Auf diese Weise können Sie so viele Verbraucher haben, wie Sie möchten, ohne über die Sharding-Kapazität nachzudenken.
Darüber hinaus haben wir einen weiteren SQS hinzugefügt, der den SNS abonniert hat und 14 Tage lang Nachrichten enthält. Im Normalfall liest niemand von diesem SQS, aber im Falle eines Fehlers, der uns dazu bringt, die Daten zurückzuspulen, können wir problemlos alle Nachrichten von diesem SQS lesen und erneut an den SNS senden. Während Kinesis nur eine 7-tägige Aufbewahrung bietet.
Zusammenfassend ist SNS + SQS viel einfacher und bietet die meisten Funktionen. IMO brauchen Sie einen wirklich starken Fall, um Kinesis darüber zu wählen.
splitin SNS split the message to multiple SQSsda sie Nachrichten in Stücke nicht abreißt , sondern kopiert sie an mehrere Ziele.
Kinesis unterstützt Funktionen für mehrere Verbraucher, dh, dieselben Datensätze können zur gleichen Zeit oder zu unterschiedlichen Zeiten innerhalb von 24 Stunden bei verschiedenen Verbrauchern verarbeitet werden. Ein ähnliches Verhalten in SQS kann durch Schreiben in mehrere Warteschlangen erreicht werden, und Verbraucher können aus mehreren Warteschlangen lesen. Wenn Sie jedoch erneut in mehrere Warteschlangen schreiben, wird die Latenz im System um einige Sekunden (einige Millisekunden) verlängert.
Zweitens bietet Kinesis Routing-Funktionen zum selektiven Weiterleiten von Datensätzen an verschiedene Shards mithilfe eines Partitionsschlüssels, der von bestimmten EC2-Instanzen verarbeitet werden kann und die Berechnung von Mikrobatches {Counting & Aggregation} ermöglicht.
Die Arbeit an jeder AWS-Software ist einfach, mit SQS jedoch am einfachsten. Bei Kinesis müssen im Voraus genügend Shards bereitgestellt werden, wodurch die Anzahl der Shards dynamisch erhöht wird, um die Spitzenlast zu verwalten, und verringert werden muss, um Kosten zu sparen, die auch für die Verwaltung erforderlich sind. Es ist Schmerz in Kinesis. Bei SQS sind solche Dinge nicht erforderlich. SQS ist unendlich skalierbar.
Die Semantik dieser Technologien ist unterschiedlich, da sie unterschiedliche Szenarien unterstützen sollen:
Lassen Sie uns den Unterschied anhand eines Beispiels verstehen.
Sobald die Verarbeitung eines Elements nicht von der Verarbeitung eines anderen getrennt werden kann, müssen wir über eine Kinesis-Semantik verfügen, um alle Fälle sicher behandeln zu können.
Auszug aus der AWS-Dokumentation :
Wir empfehlen Amazon Kinesis Streams für Anwendungsfälle mit ähnlichen Anforderungen:
Weiterleiten verwandter Datensätze an denselben Datensatzprozessor (wie beim Streaming von MapReduce). Das Zählen und Aggregieren ist beispielsweise einfacher, wenn alle Datensätze für einen bestimmten Schlüssel an denselben Datensatzprozessor weitergeleitet werden.
Bestellung von Aufzeichnungen. Beispielsweise möchten Sie Protokolldaten vom Anwendungshost auf den Verarbeitungs- / Archivierungshost übertragen, während Sie die Reihenfolge der Protokollanweisungen beibehalten.
Möglichkeit für mehrere Anwendungen, denselben Stream gleichzeitig zu verwenden. Sie haben beispielsweise eine Anwendung, die ein Echtzeit-Dashboard aktualisiert, und eine andere, die Daten in Amazon Redshift archiviert. Sie möchten, dass beide Anwendungen gleichzeitig und unabhängig voneinander Daten aus demselben Stream verwenden.
Möglichkeit, einige Stunden später Datensätze in derselben Reihenfolge zu verwenden. Sie haben beispielsweise eine Abrechnungsanwendung und eine Überwachungsanwendung, die einige Stunden hinter der Abrechnungsanwendung ausgeführt werden. Da Amazon Kinesis Streams Daten bis zu 7 Tage speichert, können Sie die Überwachungsanwendung bis zu 7 Tage hinter der Abrechnungsanwendung ausführen.
Wir empfehlen Amazon SQS für Anwendungsfälle mit ähnlichen Anforderungen:
Messaging-Semantik (z. B. Bestätigung / Fehler auf Nachrichtenebene) und Zeitlimit für Sichtbarkeit. Sie haben beispielsweise eine Warteschlange mit Arbeitselementen und möchten den erfolgreichen Abschluss jedes Elements unabhängig verfolgen. Amazon SQS verfolgt die Bestätigung / den Fehler, sodass die Anwendung keinen dauerhaften Prüfpunkt / Cursor verwalten muss. Amazon SQS löscht bestätigte Nachrichten und liefert fehlgeschlagene Nachrichten nach einem konfigurierten Zeitlimit für die Sichtbarkeit erneut.
Verzögerung einzelner Nachrichten. Sie haben beispielsweise eine Jobwarteschlange und müssen einzelne Jobs verzögert planen. Mit Amazon SQS können Sie einzelne Nachrichten mit einer Verzögerung von bis zu 15 Minuten konfigurieren.
Dynamisch steigende Parallelität / Durchsatz zum Zeitpunkt des Lesens. Sie haben beispielsweise eine Arbeitswarteschlange und möchten weitere Leser hinzufügen, bis das Backlog gelöscht ist. Mit Amazon Kinesis Streams können Sie auf eine ausreichende Anzahl von Shards skalieren (beachten Sie jedoch, dass Sie im Voraus genügend Shards bereitstellen müssen).
Nutzung der Fähigkeit von Amazon SQS, transparent zu skalieren. Beispielsweise puffern Sie Anforderungen und die Last ändert sich aufgrund gelegentlicher Lastspitzen oder des natürlichen Wachstums Ihres Unternehmens. Da jede gepufferte Anforderung unabhängig verarbeitet werden kann, kann Amazon SQS transparent skaliert werden, um die Last ohne Bereitstellungsanweisungen von Ihnen zu bewältigen.
Der größte Vorteil für mich ist die Tatsache, dass Kinesis eine wiederholbare Warteschlange ist und SQS nicht. Sie können also mehrere Konsumenten derselben Nachrichten von Kinesis (oder denselben Konsumenten zu unterschiedlichen Zeiten) haben, wobei mit SQS eine Nachricht aus dieser Warteschlange entfernt wurde, sobald sie bestätigt wurde. Aus diesem Grund ist SQS besser für Worker-Warteschlangen geeignet.
Eine andere Sache: Kinesis kann ein Lambda auslösen, SQS nicht. Bei SQS müssen Sie entweder eine EC2-Instanz bereitstellen, um SQS-Nachrichten zu verarbeiten (und diese zu verarbeiten, wenn dies fehlschlägt), oder Sie müssen einen geplanten Lambda haben (der nicht vergrößert oder verkleinert wird - Sie erhalten nur einen pro Minute). .
Bearbeiten: Diese Antwort ist nicht mehr korrekt. SQS kann Lambda ab Juni 2018 direkt auslösen
Die Preismodelle sind unterschiedlich, sodass je nach Anwendungsfall das eine oder andere möglicherweise günstiger ist. Verwenden Sie den einfachsten Fall (ohne SNS):
Wenn Sie die aktuellen Preise eingeben und die kostenlose Stufe nicht berücksichtigen und 1 GB Nachrichten pro Tag mit der maximalen Nachrichtengröße senden, kostet Kinesis viel mehr als SQS (10,82 USD / Monat für Kinesis gegenüber 0,20 USD / Monat für SQS). . Wenn Sie jedoch 1 TB pro Tag senden, ist Kinesis etwas billiger (158 USD / Monat gegenüber 201 USD / Monat für SQS).
Details: SQS berechnet 0,40 USD pro Million Anfragen (jeweils 64 KB), also 0,00655 USD pro GB. Bei 1 GB pro Tag sind dies knapp 0,20 USD pro Monat. Bei 1 TB pro Tag sind es etwas mehr als 201 US-Dollar pro Monat.
Kinesis berechnet 0,014 USD pro Million Anfragen (jeweils 25 KB), also 0,00059 USD pro GB. Bei 1 GB pro Tag sind dies weniger als 0,02 USD pro Monat. Bei 1 TB pro Tag sind es ungefähr 18 US-Dollar pro Monat. Kinesis berechnet jedoch auch 0,015 USD pro Shard-Stunde. Sie benötigen mindestens 1 Shard pro 1 MB pro Sekunde. Bei 1 GB pro Tag ist 1 Shard ausreichend, sodass weitere 0,36 USD pro Tag hinzukommen, was einem Gesamtpreis von 10,82 USD pro Monat entspricht. Bei 1 TB pro Tag benötigen Sie mindestens 13 Shards, was weitere 4,68 USD pro Tag ergibt, was einem Gesamtpreis von 158 USD pro Monat entspricht.
Kinesis löst das Problem des Kartenteils in einem typischen Szenario zur Kartenreduzierung für das Streaming von Daten. Während SQS dies nicht sicherstellt. Wenn Sie Streaming-Daten haben, die auf einem Schlüssel aggregiert werden müssen, stellt kinesis sicher, dass alle Daten für diesen Schlüssel zu einem bestimmten Shard gehen und der Shard auf einem einzelnen Host verwendet werden kann, was die Aggregation auf dem Schlüssel im Vergleich zu SQS vereinfacht
Ich werde noch etwas hinzufügen, das noch niemand erwähnt hat - SQS ist um mehrere Größenordnungen teurer.
Kinesis-Anwendungsfälle
SQS-Anwendungsfälle