AWS ElastiCache / SimpleQueue vs DynamoDB


13

Je m'interroge sur la justification de l'utilisation d'ElastiCache / SimpleQueue par rapport à la simple présence de tables "Cache" et "Queue" à l'intérieur de DynamoDB respectivement.

Il semble que la latence du réseau vers les services de cache / file d'attente l'emporterait sur une grande partie des gains de performances, et qu'EC2 traite Dynamo comme son service de cache / file d'attente offrirait la même latence et le même débit (puisque Dynamo permet une faible latence fixe sous n'importe quel charge).

S'agit-il principalement du prix de la dynamo par rapport aux autres services sous charge?

Quelqu'un a-t-il des chiffres de latence approximatifs comparant Dynamo à ElastiCache / SQS?

Y a-t-il d'autres considérations plus importantes qui me manquent qui justifient la complexité supplémentaire?

Merci.

Réponses:


9

Nous utilisons DynamoDB et ElastiCache Redis pour différentes raisons.

DynamoDB:

  • Possède un langage de requête capable de faire des choses plus complexes (supérieures à, entre etc.)
  • Est accessible via une API externe accessible sur Internet (différentes régions sont accessibles sans aucun changement ni propre infrastructure)
  • Les autorisations basées sur des tables ou même des lignes sont possibles
  • Échelles en termes de taille des données à l'infini
  • Vous payez par demande -> un nombre de demandes faible signifie une facture plus petite, un nombre de demandes élevé signifie une facture plus élevée
  • Les lectures et les écritures ont des coûts différents
  • Les données sont sauvegardées redondantes par AWS dans plusieurs installations
  • DynamoDB est hautement disponible prêt à l'emploi
  • La mise à l'échelle automatique est disponible dans le service lui-même

ElastiCache Redis:

  • Langage de requête simple - pas de fonctionnalités complexes
  • N'est pas (prêt à l'emploi) accessible depuis d'autres régions.
  • Vous êtes toujours limité à la quantité de mémoire (ou à la somme de toutes les instances principales d'un cluster)
  • Le partage sur plusieurs instances n'est possible que dans votre application - Redis ne fait rien ici (le cluster Redis aide ici mais la logique de partage est toujours à l'intérieur du pilote / sdk que vous utilisez dans votre application) - scale-in et scale- la sortie n'est pas possible sans temps d'arrêt pour le moment
  • Vous payez par instance, quelle que soit la charge ou le nombre de demandes.
  • Si vous souhaitez une redondance des données, vous devez configurer la réplication (impossible entre les différentes régions)
  • Vous devez utiliser des répliques pour une haute disponibilité
  • Pas de mise à l'échelle automatique disponible (voir la partie sur aucune mise à l'échelle du tout ci-dessus)

Notre configuration est donc la plupart du temps: des caches simples avec un volume élevé de demandes dans Redis, soutenu par DynamoDB comme stockage permanent et durable. Avec cela, nous limitons les coûts car nous obtenons une remise implicite pour nos lectures par le modèle de paiement à l'instance de Redis, mais bénéficions également de la redondance de DynamoDB et sommes même en mesure d'utiliser le langage de requête DynamoDB pour des choses plus complexes ( si nous en avons besoin).

J'espère que cela pourra aider!

Mise à jour: Avec l'annonce d'Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ), nous passons à l'utilisation de DAX car c'est (à la fin) exactement ce que nous faisions avec le combinaison de DynamoDB et Redis. Comme DAX est entièrement géré par AWS et nous donne la possibilité de toujours utiliser le langage DynamoDB dans notre application, mais aussi de bénéficier des avantages d'un cache d'écriture comme Redis.


Très utile, merci. Ce que je ne comprends pas, c'est comment vous sauvegardez redis avec dynamodb: est-ce une fonctionnalité d'AWS? ou quand et comment créez-vous la sauvegarde? Merci, si vous pouvez clarifier cela!
badera

Mon «soutenu par» n'est pas conçu comme une sauvegarde de manière traditionnelle. Nous écrivons en fait à DynamoDB tout le temps et utilisons Redis pour lire en premier. Donc, même si Redis perd des données, nous les avons dans DynamoDB. Avec l'utilisation de DAX ( aws.amazon.com/de/dynamodb/dax ), ce cas d'utilisation est devenu beaucoup plus facile maintenant!
Osterjour

7

La raison principale pour laquelle nous utilisons Elasticache plutôt que DynamoDB est la vitesse - vous obtenez une latence aller-retour inférieure à 1 ms pour les petits objets. La boîte est vraiment proche de votre machine EC2, et la mémoire est beaucoup plus rapide que le disque, même le SSD.

Il pourrait également y avoir un avantage en termes de coûts compte tenu des différents modèles de tarification, même si je ne suis pas entré dans les détails.


Est-ce toujours d'actualité? DAX n'a-t-il pas changé cela?
dmigo

1
DAX résoudra la plupart des problèmes de latence, oui. Je ne suis pas sûr des différences de vitesse exactes - pour les petits objets, le réseau sera le principal contributeur à la latence.
Maximilian

1

Redis / memcached sont des magasins en mémoire et devraient généralement être plus rapides que DynamoDB pour les données de type cache / file d'attente. Ils ont également des éléments supplémentaires pratiques comme les clés expirantes, Pub / Sub dans Redis, etc. que Dynamo peut ne pas avoir.


1
Merci. Je me rends compte que le cache est en mémoire mais j'ai lu que l'on peut s'attendre à au moins un aller-retour d'environ 10 ms pour atteindre le cache et revenir, ce qui rend les caractéristiques de performances identiques à Dynamo. Je suppose que vous avez raison de vouloir que certaines fonctionnalités spécifiques de memcached ne soient pas disponibles dans la dynamo. Mais pour moi, le principal avantage d'un cache RAM est l'augmentation des performances de l'ordre de grandeur par rapport à un magasin durable, qui ne semble pas s'appliquer ici.
Scott Klarenbach
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.