Назад | Перейти на главную страницу

AWS ElastiCache / SimpleQueue против DynamoDB

Мне интересно, почему можно использовать ElastiCache / SimpleQueue вместо того, чтобы просто иметь таблицы «Кэш» и «Очередь» внутри DynamoDB соответственно.

Кажется, что сетевая задержка для служб кэша / очереди будет преобладать над большим приростом производительности, и что, если 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.