У меня есть прецедент, в котором будет поток данных, и я не могу потреблять его в том же темпе и нужен буфер. Это можно решить с помощью очереди SNS-SQS. Я узнал, что Кинезис решает одну и ту же цель, так в чем же разница? Почему я должен предпочесть (или не должен) Кинезис?Почему я должен использовать Amazon Kinesis, а не SNS-SQS?
На поверхности они смутно похожи, но ваш случай использования определит, какой инструмент подходит. IMO, если вы можете пройти через SQS, тогда вы должны - если он будет делать то, что вы хотите, это будет проще и дешевле, но вот лучшее объяснение из FAQ AWS, в котором приводятся примеры подходящих вариантов использования для обоих инструментов: поможет вам решить:
Самым большим преимуществом для меня является тот факт, что Kinesis является replayable очереди, и SQS не является. Таким образом, вы можете иметь нескольких потребителей одних и тех же сообщений Kinesis (или одного и того же потребителя в разное время), где с SQS, когда сообщение было ack'd, оно исчезло из этой очереди. SQS лучше для рабочих очередей из-за этого.
Kinesis поддерживает несколько возможностей потребителей, что означает, что те же записи данных могут обрабатываться в одно и то же время или в другое время в течение 24 часов у разных потребителей, подобное поведение в SQS может быть достигнуто путем записи в несколько очередей, а потребители могут читать из нескольких очередей , Однако повторная запись в несколько очередей приведет к задержке в секундах в течение нескольких секунд (несколько миллисекунд).
Во-вторых, Kinesis обеспечивает возможность маршрутизации для выборочных записей данных маршрута к различным осколкам с использованием ключа раздела, который может обрабатываться конкретными экземплярами EC2 и может включать вычисление микропакетов {Counting & aggregation}.
Работа с любым программным обеспечением AWS проста, но с SQS проще всего. С Kinesis необходимо заранее предусмотреть достаточное количество осколков, динамически увеличивая количество осколков, чтобы управлять нагрузкой на шип и уменьшать, чтобы сэкономить затраты, необходимые для управления. это боль в Кинезисе. В SQS таких вещей не требуется. SQS бесконечно масштабируема.
Что касается вас объяснение на SQS. Вы можете получить простой способ отправить одно и то же сообщение нескольким SQS с помощью SNS перед ними. –
app -> sns topic ---> sqs1, sqs2, sqs3 ...? – kartik
Да, я имел в виду это точно подход. –
После изучения проблемы в течение некоторого времени, имея тот же вопрос, я обнаружил, что SQS (с SNS) является предпочтительным для большинства случаев использования, если только порядок сообщений не является для вас важным (SQS не гарантирует FIFO Сообщения).
Существует 2 основных преимущества для Kinesis (1), вы можете прочитать одно и то же сообщение из нескольких приложений, и (2) вы можете перечитывать сообщения, если вам нужно.
Оба преимущества могут быть достигнуты за счет использования SNS в качестве вентилятора для SQS. Это означает, что производитель сообщения отправляет только одно сообщение в SNS. Затем SNS разветвляет сообщение на несколько SQS, по одному для каждого потребительского приложения. Таким образом, вы можете иметь столько же, сколько хотите, не думая о способности к помехам.
Кроме того, мы добавили еще один SQS, который подписан на SNS, который будет хранить сообщения в течение 14 дней. В нормальном случае никто не читает этот SQS, но в случае ошибки, из-за которой мы хотим перемотать данные, мы можем легко прочитать все сообщения из этого SQS и отправить их в SNS. В то время как Kinesis предоставляет только 7 дней хранения.
В заключение, SNS + SQS очень прост и обеспечивает большинство возможностей. ИМО вам нужен действительно сильный случай, чтобы выбрать Kinesis над ним.
FYI: Вы можете сохранить Кинезис на срок до 7 дней. –
@ DidierA., Да, они повышают максимальную политику хранения до 7 дней. Я обновлю ответ. Благодарю. –
Недавно AWS анонсировала SQS FIFO [http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html], который может служить для упорядочивания сообщений. – VijeshJain
Kinesis решает проблему части карты в типичном сценарии сокращения карты для потоковой передачи данных. Хотя SQS не делает этого.Если у вас есть потоковые данные, которые необходимо агрегировать по ключу, то кинези гарантирует, что все данные для этого ключа попадают в конкретный осколок, и осколок может потребляться на одном хосте, что упрощает агрегацию по ключу по сравнению с SQS
Я добавлю еще одну вещь, о которой никто еще не упомянул - SQS на несколько порядков дороже.
Вы уверены? По моим расчетам, Kinesis намного дороже, но я никогда не был талантливым с помощью Amazon Simple Price Calculator. –
Глядя на текущие примеры ценообразования на aws: Kinesis с 267M сообщениями составляет около 60 долларов США, при этом количество сообщений через SQS приведет к $ 107. Очевидно, что я просто сделал очень быстрое сравнение, и это сильно отличается от разных вариантов использования, но этот ответ определенно должен заслужить некоторую заслугу. – Moszi
Предположим, вы делаете фанат, чтобы сказать 2 потребителя и 100 миллионов сообщений в день. Стоимость SNS составляет 50 долларов США в день. Стоимость SQS составляет $ 40/день/потребитель или $ 80 в день. Kinesis составляет 1,4 доллара США за день для PUT и 0,36 доллара за тонну. Даже с 100 осколками (100 МБ/с, 200 МБ/с) это всего лишь 3,60 долл. США в день + 1,40 долл. США в день. Таким образом, Kinesis составляет 4 доллара за день против SNS/SQS по цене 130 долларов США в день. –
Другое дело: Кинези может вызвать Лямбду, а SQS не может. Таким образом, с помощью SQS вы либо должны предоставить экземпляр EC2 для обработки сообщений SQS (и справиться с ним, если он не работает), либо у вас должна быть запланированная Лямбда (которая не масштабируется вверх или вниз - вы получаете всего одну минуту) ,
-1 Не согласен. В то время как Kinesis может вызывать лямбда, это не имеет никакого преимущества перед распределенной лямбдой SQS. Последний будет масштабироваться без сбоев (т. Е. Если потребуется больше минуты, вторая лямбда будет развернута). Цена за расчетное время, поэтому нет заметных различий. И если вам нужно более 5 одновременных lambdas, просто добавьте несколько триггеров, запланированных на несколько секунд (используя cron). Это не является основанием для использования Kinesis над SNS/SQS. –
Я не уверен, что согласен с несогласием;] - вы можете запланировать одну лямбда/минуту, что ограничит вас процессом обработки сообщений, которые прибыли на этот интервал.Кинезис позволит вам немедленно прочитать сообщения. Или что-то я неправильно понял? – Moszi
Существует огромная разница между несколькими триггерами облачного экрана и сотнями, когда требуется вызвать тянущуюся лямбду против SQS. –
Отрывок из AWS Documentation:
Мы рекомендуем Amazon KINESIS Streams для случаев использования с требованиями, которые похожи на следующее:
Routing связанные записи в одной и той же звукозаписывающей процессор (как в потоковой передаче MapReduce). Например, подсчет и агрегация проще, когда все записи для данного ключа направляются на один и тот же процессор записи.
Заказ записей. Например, вы хотите перенести данные журнала с хоста приложения на хост обработки/архивирования при сохранении порядка операторов журнала.
Возможность использования несколькими приложениями одного и того же потока одновременно. Например, у вас есть одно приложение, которое обновляет панель мониторинга в реальном времени, а другое - архивирует данные в Amazon Redshift. Вы хотите, чтобы оба приложения потребляли данные из одного и того же потока одновременно и независимо.
Возможность использования записей в том же порядке несколько часов спустя. Например, у вас есть приложение для выставления счетов и приложение для аудита, которое выполняется за несколько часов после приложения биллинга. Поскольку Amazon Kinesis Streams хранит данные на срок до 7 дней, вы можете запустить приложение аудита на срок до 7 дней за биллинговым приложением.
Мы рекомендуем Amazon SQS для случаев применения с требованиями, которые похожи на следующее:
семантику обмена сообщениями (например, на уровне сообщений ACK/сбой) и Тайм-аут видимости. Например, у вас есть очередь рабочих элементов и вы хотите отслеживать успешное завершение каждого элемента независимо. Amazon SQS отслеживает ack/fail, поэтому приложению не нужно поддерживать постоянную контрольную точку/курсор. Amazon SQS удалит отмеченные сообщения и сообщения о неудачных повторных сообщениях после настроенного таймаута видимости.
Индивидуальные сообщения задержка. Например, у вас есть очередь заданий и нужно запланировать отдельные задания с задержкой. С помощью Amazon SQS вы можете настроить отдельные сообщения на задержку до 15 минут.
Динамическое увеличение параллелизма/пропускной способности во время чтения. Например, у вас есть рабочая очередь и вы хотите добавить больше читателей, пока не будет очищено отставание. С Amazon Kinesis Streams вы можете масштабировать до достаточного количества осколков (обратите внимание, однако, что вам нужно заранее предусмотреть достаточное количество осколков).
Использование способности Amazon SQS прозрачно масштабироваться.Например, вы буферизируете запросы и изменения нагрузки в результате случайных скачков нагрузки или естественного роста вашего бизнеса. Поскольку каждый буферизованный запрос может обрабатываться независимо, Amazon SQS может масштабироваться прозрачно для обработки нагрузки без каких-либо инструкций по настройке от вас.
Модель ценообразования различна, поэтому в зависимости от вашего случая использования одной или другой может быть дешевле. Использование простейшего случая (не включая SNS):
Подключив в текущих ценах и не принимая во внимание свободный ярус, если вы отправляете 1 ГБ сообщений в день на максимальный размер сообщения, Kinesis будет стоить гораздо больше, чем SQS ($ 10,82/месяц для Kinesis vs. 0,20 долл. США в месяц для SQS). Но если вы отправляете 1 ТБ в день, Kinesis несколько дешевле ($ 158/месяц против $ 201/месяц для SQS).
Подробнее: SQS взимает $ 0,40 за миллион запросов (по 64 КБ каждый), поэтому 0,00655 долларов США за ГБ. При 1 ГБ в день это составляет менее 0,20 долл. США в месяц; при 1 ТБ в день это составляет чуть более $ 201 в месяц.
Kinesis взимает 0,014 долл. США за миллион запросов (по 25 КБ каждый), поэтому 0,00059 долл. США за ГБ. При 1 ГБ в день это составляет менее 0,02 долл. США в месяц; при 1 ТБ в день, это около 18 долларов в месяц. Однако Кинсис также взимает 0,015 доллара за каждый час. Вам нужно как минимум 1 осколок на 1 МБ в секунду. При 1 ГБ в день 1 осколок будет много, поэтому он добавит еще $ 0,36 в день, общая стоимость составляет 10,82 доллара США в месяц. При 1 ТБ в день вам потребуется как минимум 13 осколков, что добавляет еще 4,68 доллара в день, общая стоимость 158 долларов США в месяц.
Я не полностью понимаю, почему значение экспоненциального увеличения размера здесь. Можете ли вы копать немного больше? Похоже, вы поняли, что хотели бы. * Edit * На самом деле, глядя на ответ Эугенина Фейнгольда, похоже, это довольно решительная дискуссия по этому вопросу (?). – Thomas
Извините, я допустил некоторые ошибки в своих расчетах (исправлено сейчас, надеюсь). –
Семантика этих технологий различны, потому что они были разработаны для поддержки различных сценариев:
Давайте разобраться в различиях на примере.
После того, как обработка одного элемента не может быть отделена от обработки другого, мы должны иметь семантику Kinesis, чтобы безопасно обрабатывать все случаи.
FYI http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-subscribe-queue-sns-topic.html SQS FIFO не работает с SNS –