AWS ElastiCache/SimpleQueue против DynamoDB
Я задаюсь вопросом об обосновании использования ElastiCache/SimpleQueue по сравнению с наличием таблиц "Cache" и "Queue" внутри DynamoDB соответственно.
Кажется, что сетевая задержка для служб Cache/Queue значительно превысила бы прирост производительности, и что EC2 рассматривает Dynamo, поскольку его служба кэширования / очереди будет предлагать такую же задержку и пропускную способность (поскольку Dynamo допускает фиксированную низкую задержку при любом нагрузка).
Это в основном о цене динамо против других услуг под нагрузкой?
Есть ли у кого-нибудь грубые значения задержки, сравнивающие Dynamo с ElastiCache/SQS?
Есть ли другие, более важные соображения, которые я упускаю, которые оправдывают дополнительную сложность?
Благодарю.
3 ответа
Мы используем DynamoDB и ElastiCache Redis по разным причинам.
DynamoDB:
- Имеет язык запросов, который может делать более сложные вещи (больше, чем, между и т. Д.)
- Доступен через внешний API для доступа в Интернет (различные регионы доступны без каких-либо изменений или собственной инфраструктуры)
- Возможны разрешения на основе таблиц или даже строк
- Масштабируется с точки зрения размера данных до бесконечности
- Вы платите за запрос -> низкие номера запроса означают меньший счет, высокие номера запроса означают более высокий счет
- Читает и пишет разные по стоимости
- Данные сохраняются избыточно с помощью AWS на нескольких объектах
- DynamoDB очень доступен из коробки
- Автомасштабирование доступно в самом сервисе
ElastiCache Redis:
- Простой язык запросов - без сложных функций
- Это (из коробки) не достижимо из других регионов.
- Вы всегда ограничены объемом памяти (или суммой всех первичных экземпляров в кластере)
- Разделение на несколько экземпляров возможно только в вашем приложении - Redis здесь ничего не делает (здесь помогает кластер Redis, но логика разделения остается внутри драйвера /sdk, который вы используете в своем приложении) - масштабирование и масштабирование на данный момент без простоя невозможно
- Вы платите за экземпляр независимо от того, какова нагрузка или количество запросов.
- Если вы хотите избыточность данных, вам нужно настроить репликацию (невозможно между разными регионами)
- Вам необходимо использовать реплики для высокой доступности
- Автоматическое масштабирование недоступно (см. Выше раздел "Нет масштабирования")
Итак, наша установка в большинстве случаев такова: простые кэши с большим объемом запросов в Redis, поддерживаемые DynamoDB как постоянное и долговременное хранилище. Благодаря этому мы ограничиваем затраты, поскольку получаем неявную скидку на наши операции чтения с помощью модели Redis с оплатой за экземпляр, но также получаем преимущество избыточности DynamoDB и даже можем использовать язык запросов DynamoDB для более сложных задач (если нам это нужно).
Надеюсь, это поможет!
Обновление: с объявлением об ускорении Amazon DynamoDB ( 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.