AWS ElastiCache / SimpleQueue проти DynamoDB

Мені цікаво обґрунтування використання ElastiCache / SimpleQueue vs просто наявності таблиць "Cache" та "Queue" всередині DynamoDB відповідно.

Схоже, що затримка в мережі до служб кешу / черги призведе до значного підвищення продуктивності, а також те, що EC2 ставиться до "Динамо" як до служби кеш / черги, пропонує однакові затримки та пропускну спроможність (оскільки "Динамо" дозволяє фіксувати низьку затримку під будь-якими навантаження).

Це головним чином про ціну "Динамо" проти інших послуг під навантаженням?

Хто-небудь має грубі затримки порівняння "Динамо" з ElastiCache / SQS?

Чи є інші важливіші міркування, які мені не вистачають, які виправдовують додаткову складність?

Дякую.

Ми використовуємо DynamoDB та ElastiCache Redis з різних причин.

ДинамоДБ:

• Має мову запитів, яка може робити більш складні речі (більше, між тощо)
• Доступний через зовнішній інтерфейс API (різні регіони доступні без змін або власної інфраструктури)
• Можливі дозволи на основі таблиць або навіть рядків
• Шкала за розміром даних до нескінченності
• Ви платите за запит -> низькі номери запитів означає менший рахунок, високий номер запиту означає більш високий рахунок
• Читання та записи відрізняються за вартістю
• Дані зберігаються надмірними AWS у кількох об'єктах
• DynamoDB дуже доступний у продажу
• Автоматичне масштабування доступне в самому сервісі

ElastiCache Redis:

• Проста мова запитів - без складних функцій
• Не доступний для інших регіонів.
• Ви завжди обмежені обсягом пам'яті (або сумою всіх первинних екземплярів у кластері)
• Шардування над декількома екземплярами можливе лише у вашій програмі - Redis тут нічого не робить (кластер Redis тут допомагає, але логіка загострення все ще знаходиться в драйвері / SDK, який ви використовуєте у вашому додатку) - масштаб і масштаб- наразі неможливо без простоїв на даний момент
• Ви платите за екземпляр незалежно від того, наскільки завантаження чи кількість запитів.
• Якщо ви бажаєте надмірності даних, вам потрібно встановити реплікацію (неможливо між різними регіонами)
• Для високої доступності потрібно використовувати репліки
• Немає автоматичного масштабування (див. Частину про відсутність масштабування взагалі вище)

Отже, наша настройка більшість часу така: Прості кеші з великим обсягом запитів у Redis, підтримувані DynamoDB як постійне і довговічне сховище. Завдяки цьому ми обмежуємо витрати, оскільки ми отримуємо неявну знижку на свої читання за моделлю Redis з оплатою за екземпляр, але також отримуємо перевагу надмірності DynamoDB і навіть можемо використовувати мову запитів DynamoDB для більш складних матеріалів ( якщо нам це потрібно).

Сподіваюся, що це допомагає!

Оновлення: Оголошуючи Amace DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ), ми переходимо на використання DAX, оскільки це (зрештою) саме те, що ми робили з поєднання DynamoDB і Redis. Оскільки DAX є повністю керованим AWS і дає нам можливість завжди використовувати мову DynamoDB у нашому додатку, а також отримувати переваги від кешу, що записує, як Redis.

Основна причина, по якій ми використовуємо Elasticache, а не DynamoDB, - це швидкість - ви отримуєте нижню затримку в зворотному напрямку для невеликих об'єктів. Коробка справді близька до вашої машини EC2, а пам'ять набагато швидша, ніж диск, навіть SSD.

Зважаючи на різні моделі ціноутворення, можна також отримати перевагу за витратами, хоча я там ще не дуже детально описувався.

Redis / memcached - це сховища пам'яті і, як правило, швидше, ніж DynamoDB для даних типу кешу / черги. У них також є зручні додаткові елементи, такі як ключі, що закінчуються, Pub / Sub у Redis тощо, яких у "Динамо" може не бути.