У мене є випадок використання, коли надходитимуть потоки даних, і я не можу споживати їх у тому ж темпі та мені потрібен буфер. Це можна вирішити за допомогою черги SNS-SQS. Я дізнався, що Kinesis вирішує ту саму мету, тож у чому різниця? Чому я віддаю перевагу (або не слід віддавати перевагу) кінези?
Відповіді:
На поверхні вони нечітко схожі, але ваш випадок використання визначить, який інструмент підходить. IMO, якщо ви зможете обійтись через SQS, тоді вам слід - якщо він зробить те, що ви хочете, це буде простіше і дешевше, але ось краще пояснення з поширених запитань AWS, яке дає приклади відповідних випадків використання обох інструментів для допоможемо вирішити:
Пам'ятайте, що ця відповідь була правильною для червня 2015 року
Деякий час вивчаючи проблему, маючи на увазі те саме питання, я виявив, що SQS (з SNS) є переважним для більшості випадків використання, якщо порядок повідомлень для вас не важливий (SQS не гарантує FIFO на повідомленнях).
Є дві основні переваги для Kinesis:
Обидві переваги можна досягти, використовуючи SNS як вентилятор SQS. Це означає, що виробник повідомлення надсилає лише одне повідомлення до SNS, тоді вболівальники SNS видають повідомлення на кілька SQS, по одному для кожної програми споживача. Таким чином у вас може бути стільки споживачів, скільки ви хочете, не замислюючись про посилення потужностей.
Крім того, ми додали ще один SQS, який підписаний на SNS, який буде зберігати повідомлення протягом 14 днів. У звичайному випадку ніхто не читає з цього SQS, але у випадку помилки, яка змушує нас захотіти перемотування даних, ми можемо легко прочитати всі повідомлення цього SQS та повторно надіслати їх до SNS. У той час як Kinesis забезпечує лише 7 днів утримання.
На закінчення, SNS + SQS набагато простіше і забезпечує більшість можливостей. ІМО вам потрібен справді вагомий випадок, щоб вибрати Кінезис над ним.
splitв , SNS split the message to multiple SQSsтак як не зламатися повідомлення на шматки , але копії його за кількома напрямками.
Kinesis підтримує можливості декількох споживачів, що означає, що одні і ті ж записи даних можуть бути оброблені одночасно або в різний час протягом 24 годин у різних споживачів, подібну поведінку в SQS можна досягти, записавши в кілька черг, і споживачі можуть читати з декількох черг. Однак повторне записування в декілька черг додасть додаткові затримки {кілька мілісекунд} в системі.
По-друге, Kinesis забезпечує можливість маршрутизації для вибіркових записів даних маршрутів до різних фрагментів, використовуючи ключ розділу, який може бути оброблений окремими екземплярами EC2 і може дозволити мікроскладовий розрахунок {Підрахунок та агрегація}.
Робота над будь-яким програмним забезпеченням AWS проста, але з SQS - це найпростіше. У Kinesis виникає необхідність передбачити достатню кількість осколків заздалегідь, динамічно збільшуючи кількість черепків для управління шиповим навантаженням і зменшуючи, щоб заощадити витрати, необхідні для управління. болі в Кінезі, таких SQS не потрібно. SQS нескінченно масштабується.
Семантика цих технологій відрізняється тим, що вони були розроблені для підтримки різних сценаріїв:
Розберемо різницю на прикладі.
Як тільки обробка одного елемента не може бути відокремлена від обробки іншого, ми повинні мати семантику Kinesis, щоб безпечно обробляти всі випадки.
Витяг з документації AWS :
Ми рекомендуємо Amazon Kinesis Streams для випадків використання із вимогами, подібними до таких:
Маршрутизація пов'язаних записів на той самий процесор запису (як у потоковому перегляді MapReduce). Наприклад, підрахунок та агрегація простіші, коли всі записи для даного ключа перенаправлені до одного і того ж процесора запису.
Впорядкування записів. Наприклад, ви хочете перенести дані журналу з хоста програми на хост обробки / архіву, зберігаючи порядок виписок журналів.
Можливість для декількох додатків одночасно споживати один і той же потік. Наприклад, у вас є одна програма, яка оновлює інформаційну панель у режимі реального часу та інша, яка архівує дані на Amazon Redshift. Ви хочете, щоб обидві програми одночасно та незалежно споживали дані з одного потоку.
Можливість споживати записи в тому ж порядку через кілька годин. Наприклад, у вас є додаток для виставлення рахунків і програма аудиту, яка працює на кілька годин позаду програми виставлення рахунків. Оскільки Amazon Kinesis Streams зберігає дані до 7 днів, ви можете запустити програму аудиту до 7 днів за програмою виставлення рахунків.
Ми рекомендуємо Amazon SQS для випадків використання із вимогами, подібними до таких:
Семантика обміну повідомленнями (наприклад, ack / fail на рівні повідомлення) та час очікування видимості. Наприклад, у вас є черга робочих предметів і ви хочете відстежувати успішне завершення кожного елемента самостійно. Amazon SQS відслідковує ack / fail, тому додатку не потрібно підтримувати стійкий контрольний пункт / курсор. Amazon SQS видалить заблоковані повідомлення та повторно доставить невдалі повідомлення після налаштованого часу очікування видимості.
Індивідуальна затримка повідомлення. Наприклад, у вас є черга на роботу та потрібно планувати окремі завдання із запізненням. За допомогою Amazon SQS ви можете налаштувати окремі повідомлення із затримкою до 15 хвилин.
Динамічно збільшується паралельність / пропускна здатність за час читання. Наприклад, у вас є черга на роботу і ви хочете додати більше читачів, поки не буде видалено відставання. За допомогою Amazon Kinesis Streams ви можете набирати масштаб до достатньої кількості осколків (зауважте, що вам потрібно буде передбачити достатню кількість осколків достроково).
Використання можливості Amazon SQS прозоро масштабувати. Наприклад, ви завантажуєте запити та змінюється навантаження внаслідок періодичних спайок завантаження або природного зростання вашого бізнесу. Оскільки кожен завантажений запит може бути оброблений незалежно, Amazon SQS може прозоро масштабувати обробку вантажу без будь-яких інструкцій щодо надання.
Найбільшою перевагою для мене є той факт, що Kinesis є чергою, що повторюється, а SQS - ні. Таким чином, ви можете мати декількох споживачів одних і тих же повідомлень Kinesis (або одного і того ж споживача в різний час), коли з SQS, як тільки повідомлення було ack'd, воно пішло з цієї черги. SQS краще для черг на працівників через це.
Інша справа: Kinesis може викликати лямбда, тоді як SQS не може. Таким чином, з SQS вам або потрібно надати екземпляр EC2 для обробки SQS-повідомлень (і вирішувати це, якщо він не працює), або вам доведеться мати заплановану лямбда (яка не масштабується вгору або вниз - ви отримуєте лише одну хвилину) .
Редагувати: Ця відповідь більше не є правильною. SQS може безпосередньо запустити Lambda станом на червень 2018 року
Моделі ціноутворення різні, тому залежно від конкретного випадку використання те чи інше може бути дешевшим. Використовуючи найпростіший випадок (не включаючи SNS):
Підключення поточних цін і не враховуючи безкоштовний рівень, якщо ви надсилаєте 1 Гб повідомлень на день при максимальному розмірі повідомлення, Kinesis обійдеться набагато дорожче, ніж SQS (10,82 дол. США на місяць для Kinesis проти 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 доларів на місяць. Однак Kinesis також стягує 0,015 доларів за осколкову годину. Вам потрібно щонайменше 1 осколок за 1 Мб в секунду. При 1 ГБ на день, 1 шматок буде достатньо, так що ви додасте ще $ 0,36 на день, загальною вартістю 10,82 долара на місяць. При 1 ТБ на день вам знадобиться щонайменше 13 черепашок, що додає ще $ 4,68 на день, загальною вартістю 158 доларів на місяць.
Kinesis вирішує проблему частини карти в типовому сценарії зменшення карти для потокової передачі даних. Хоча SQS не впевнений у цьому. Якщо у вас є потокові дані, які потрібно агрегувати по ключу, kinesis гарантує, що всі дані для цього ключа спрямовані на певний фрагмент, а осколок може бути використаний на одному хості, що робить агрегацію ключа ключою легшою порівняно з SQS
Додам ще одну річ, яку ніхто більше не згадував - SQS на кілька порядків дорожча.
Випадки використання кінезу
Випадки використання SQS