AWS ElastiCache / SimpleQueue vs DynamoDB

Me pregunto la razón para usar ElastiCache / SimpleQueue en lugar de tener tablas "Cache" y "Queue" dentro de DynamoDB respectivamente.

Parece que la latencia de red a los servicios de Cache / Queue superaría muchas de las ganancias de rendimiento, y que EC2 trate a Dynamo como su servicio de caché / cola ofrecería la misma latencia y rendimiento (ya que Dynamo permite una baja latencia fija bajo cualquier carga).

¿Se trata principalmente del precio de dynamo frente a otros servicios bajo carga?

¿Alguien tiene números de latencia aproximada comparando Dynamo con ElastiCache / SQS?

¿Hay otras consideraciones más importantes que me faltan que justifiquen la complejidad adicional?

Gracias.

Estamos usando DynamoDB y ElastiCache Redis por diferentes razones.

DynamoDB:

• Tiene un lenguaje de consulta que puede hacer cosas más complejas (mayor que, entre, etc.)
• Se puede acceder a través de una API externa con conexión a Internet (se puede acceder a diferentes regiones sin cambios ni infraestructura propia)
• Los permisos basados ​​en tablas o incluso filas son posibles
• Escalas en términos de tamaño de datos hasta el infinito
• Usted paga por solicitud -> los números de solicitud bajos significan una factura más pequeña, los números de solicitud altos significan una factura más alta
• Las lecturas y escrituras son diferentes en costos
• AWS guarda los datos de forma redundante en varias instalaciones
• DynamoDB es altamente disponible fuera de la caja
• El escalado automático está disponible en el propio servicio.

ElastiCache Redis:

• Lenguaje de consulta simple: sin características complejas
• Es (fuera de la caja) no accesible desde otras regiones.
• Siempre está limitado a la cantidad de memoria (o la suma de todas las instancias principales en un clúster)
• El fragmentado en varias instancias solo es posible dentro de su aplicación: Redis no hace nada aquí (el clúster de Redis ayuda aquí, pero la lógica de fragmentación todavía está dentro del controlador / sdk que está utilizando en su aplicación) fuera no es posible sin tiempo de inactividad en este momento
• Paga por instancia, sin importar la carga o el número de solicitudes.
• Si desea redundancia de los datos, necesita configurar la replicación (no es posible entre diferentes regiones)
• Necesita usar réplicas para alta disponibilidad
• No hay escalado automático disponible (vea la parte sobre no escalar en absoluto arriba)

Por lo tanto, nuestra configuración la mayor parte del tiempo es: cachés simples con gran volumen de solicitudes en Redis respaldadas por DynamoDB como almacenamiento permanente y duradero. Con esto, limitamos los costos ya que obtenemos un descuento implícito para nuestras lecturas por el modelo de pago por instancia de Redis, pero también obtenemos el beneficio de la redundancia de DynamoDB e incluso podemos usar el lenguaje de consulta DynamoDB para cosas más complejas ( si lo necesitamos)

¡Espero que ayude!

Actualización: con el anuncio de Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ) estamos cambiando para usar DAX, ya que es (al final) exactamente lo que estábamos haciendo con el combinación de DynamoDB y Redis. Como DAX está totalmente administrado por AWS y nos da la oportunidad de usar siempre el lenguaje DynamoDB en nuestra aplicación, pero también obtener los beneficios de un caché de escritura como Redis.

La razón principal por la que usamos Elasticache en lugar de DynamoDB es la velocidad: obtienes una latencia de ida y vuelta inferior a 1 ms para objetos pequeños. La caja está realmente cerca de su máquina EC2, y la memoria es mucho más rápida que el disco, incluso SSD.

También podría haber una ventaja de costos dados los diferentes modelos de precios, aunque no he entrado en tantos detalles allí.

Redis / memcached son almacenes en memoria y, en general, deberían ser más rápidos que DynamoDB para datos de tipo caché / cola. También tienen útiles elementos adicionales como claves que caducan, Pub / Sub en Redis, etc., que Dynamo puede no tener.