amazon-web-services – AWS ElastiCache / SimpleQueue frente a DynamoDB

Pregunta:

Me pregunto cuál es la razón fundamental para usar ElastiCache / SimpleQueue frente a tener tablas "Cache" y "Queue" dentro de DynamoDB, respectivamente.

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

¿Se trata principalmente del precio de dínamo frente a otros servicios bajo carga?

¿Alguien tiene cifras aproximadas de latencia comparando Dynamo con ElastiCache / SQS?

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

Gracias.

Respuesta:

Usamos DynamoDB y ElastiCache Redis por diferentes motivos.

DynamoDB:

  • Tiene un lenguaje de consulta que puede hacer cosas más complejas (mayor que, entre, etc.)
  • Es accesible a través de una API externa orientada a Internet (se puede acceder a diferentes regiones sin ningún cambio o infraestructura propia)
  • Los permisos basados ​​en tablas o incluso filas son posibles
  • Escala en términos de tamaño de datos hasta el infinito
  • Usted paga por solicitud -> números de solicitud bajos significa factura más pequeña, números de solicitud altos significa factura más alta
  • Las lecturas y escrituras tienen costos diferentes
  • AWS guarda los datos de forma redundante en varias instalaciones
  • DynamoDB tiene una alta disponibilidad lista para usar
  • El ajuste de escala automático está disponible en el propio servicio

ElastiCache Redis:

  • Lenguaje de consulta simple, sin funciones complejas
  • No es (listo para usar) accesible desde otras regiones.
  • Siempre está limitado a la cantidad de memoria (o la suma de todas las instancias primarias en un clúster)
  • La fragmentación 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á usando en su aplicación) – escalar y escalar- 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, debe configurar la replicación (no es posible entre diferentes regiones)
  • Necesita usar réplicas para alta disponibilidad
  • No hay ajuste de escala automático disponible (consulte la parte sobre ningún ajuste de escala más arriba)

Entonces, nuestra configuración la mayor parte del tiempo es: Cachés simples con un gran volumen de solicitudes en Redis respaldados por DynamoDB como almacenamiento permanente y duradero. Con esto, limitamos los costos ya que obtenemos un descuento implícito para nuestras lecturas mediante 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 de 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/ ), cambiaremos para usar DAX tal como es (al final) exactamente lo que estábamos haciendo con el combinación de DynamoDB y Redis. Como DAX está completamente administrado por AWS y nos brinda la oportunidad de usar siempre el lenguaje DynamoDB en nuestra aplicación, pero también de obtener los beneficios de una caché de escritura directa como Redis.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım