AWS ElastiCache / SimpleQueue против DynamoDB

Я задаюсь вопросом об обосновании использования ElastiCache / SimpleQueue по сравнению с наличием таблиц «Cache» и «Queue» внутри DynamoDB соответственно.

Кажется, что сетевая задержка для служб Cache / Queue значительно превысила бы прирост производительности, и что EC2 рассматривает Dynamo, поскольку его служба кэширования / очереди будет предлагать такую ​​же задержку и пропускную способность (поскольку Dynamo допускает фиксированную низкую задержку при любом нагрузка).

Это в основном о цене динамо против других услуг под нагрузкой?

Есть ли у кого-нибудь грубые значения задержки, сравнивающие Dynamo с ElastiCache / SQS?

Есть ли другие, более важные соображения, которые я упускаю, которые оправдывают дополнительную сложность?

Благодарю.

Мы используем DynamoDB и ElastiCache Redis по разным причинам.

DynamoDB:

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

ElastiCache Redis:

• Простой язык запросов - без сложных функций
• Это (из коробки) не достижимо из других регионов.
• Вы всегда ограничены объемом памяти (или суммой всех первичных экземпляров в кластере)
• Разделение на несколько экземпляров возможно только в вашем приложении - Redis здесь ничего не делает (здесь помогает кластер Redis, но логика разделения остается внутри драйвера / sdk, который вы используете в своем приложении) - масштабирование и масштабирование - на данный момент без простоя невозможно
• Вы платите за экземпляр независимо от того, какова нагрузка или количество запросов.
• Если вы хотите избыточность данных, вам нужно настроить репликацию (невозможно между разными регионами)
• Вам нужно использовать реплики для высокой доступности
• Автоматическое масштабирование недоступно (см. Выше раздел «Нет масштабирования»)

Итак, наша установка в большинстве случаев такова: простые кэши с большим объемом запросов в Redis, поддерживаемые DynamoDB как постоянное и долговременное хранилище. Благодаря этому мы ограничиваем затраты, поскольку получаем неявную скидку на наши операции чтения по модели Redis с оплатой за экземпляр, но также получаем преимущество избыточности DynamoDB и даже можем использовать язык запросов DynamoDB для более сложных задач ( если нам это нужно).

Надеюсь, это поможет!

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

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

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

Redis / memcached являются хранилищами в памяти и обычно должны быть быстрее чем DynamoDB для данных типа кеш / очереди. У них также есть удобные дополнительные элементы, такие как истекающие ключи, Pub / Sub в Redis и т. Д., Которые могут отсутствовать у Dynamo.