AWS ElastiCache / SimpleQueue vs DynamoDB


13

Eu estou pensando sobre a justificativa para usar o ElastiCache / SimpleQueue vs apenas ter as tabelas "Cache" e "Queue" dentro do DynamoDB, respectivamente.

Parece que a latência da rede para os serviços de Cache / Fila superaria muitos dos ganhos de desempenho e que o EC2 tratasse o Dynamo como seu serviço de cache / fila ofereceria a mesma latência e taxa de transferência (já que o Dynamo permite uma latência baixa fixa sob qualquer carga).

É principalmente sobre o preço do dínamo versus outros serviços sob carga?

Alguém tem algum número aproximado de latência comparando o Dynamo com o ElastiCache / SQS?

Faltam outras considerações mais importantes que justificam a complexidade adicional?

Obrigado.

Respostas:


9

Estamos usando o DynamoDB e o ElastiCache Redis por diferentes motivos.

DynamoDB:

  • Tem uma linguagem de consulta capaz de fazer coisas mais complexas (maior que, entre etc.)
  • É alcançável por meio de uma API externa da Internet (regiões diferentes são alcançáveis ​​sem alterações ou infraestrutura própria)
  • Permissões com base em tabelas ou mesmo linhas são possíveis
  • Escalas em termos de tamanho de dados até o infinito
  • Você paga por solicitação -> números baixos de solicitação significa fatura menor, números altos de solicitação significa fatura mais alta
  • Lê e grava são diferentes nos custos
  • Os dados são salvos como redundantes pela AWS em vários recursos
  • O DynamoDB é altamente disponível imediatamente
  • O escalonamento automático está disponível no próprio serviço

ElastiCache Redis:

  • Linguagem de consulta simples - sem recursos complexos
  • Não está pronto para uso (acessível) de outras regiões.
  • Você está sempre limitado à quantidade de memória (ou à soma de todas as instâncias primárias em um cluster)
  • O sharding em várias instâncias só é possível no seu aplicativo - o Redis não faz nada aqui (o cluster Redis ajuda aqui, mas a lógica do sharding ainda está dentro do driver / sdk que você está usando no seu aplicativo) - scale-in and scale- não é possível sem tempo de inatividade no momento
  • Você paga por instância, independentemente da carga ou do número de solicitações.
  • Se você deseja redundância dos dados, precisa configurar a replicação (não é possível entre diferentes regiões)
  • Você precisa usar réplicas para alta disponibilidade
  • Nenhum dimensionamento automático disponível (consulte a parte sobre o dimensionamento acima)

Portanto, nossa configuração na maioria das vezes é: Caches simples com alto volume de solicitações no Redis, suportadas pelo DynamoDB como armazenamento permanente e durável. Com isso, limitamos os custos à medida que obtemos um desconto implícito para nossas leituras pelo modelo de pagamento por instância do Redis, mas também obtemos o benefício da redundância do DynamoDB e até podemos usar a linguagem de consulta do DynamoDB para coisas mais complexas ( se precisarmos).

Espero que ajude!

Atualização: com o anúncio do Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ), passamos a usar o DAX como ele é (no final) exatamente o que estávamos fazendo com o combinação de DynamoDB e Redis. Como o DAX é totalmente gerenciado pela AWS e nos dá a chance de sempre usar a linguagem DynamoDB em nosso aplicativo, mas também obter os benefícios de um cache de gravação como o Redis.


Muito útil, obrigado. O que eu não entendo é como você faz o backup do redis com o dynamodb: esse é um recurso da AWS? ou quando e como você cria o backup? Obrigado, se você pode esclarecer isso!
badera

Meu "respaldado por" não é um backup tradicional. Na verdade, estamos escrevendo para o DynamoDB o tempo todo e usando o Redis para ler primeiro. Portanto, mesmo se o Redis perder dados, temos no DynamoDB disponível. Com o uso do DAX ( aws.amazon.com/de/dynamodb/dax ), este caso de uso ficou muito mais fácil agora!
Osterjour

7

A principal razão pela qual usamos o Elasticache em vez do DynamoDB é a velocidade - você obtém uma latência de ida e volta abaixo de 1ms para objetos pequenos. A caixa está muito perto da sua máquina EC2 e a memória é muito mais rápida que o disco, mesmo o SSD.

Também poderia haver uma vantagem de custo, considerando os diferentes modelos de preços, embora eu não tenha entrado em muitos detalhes por lá.


Ainda é relevante? O DAX não mudou isso?
Dmigo 13/06/19

1
O DAX resolverá muitos dos problemas de latência, sim. Não tenho certeza das diferenças exatas de velocidade - para pequenos objetos, a rede será o principal contribuinte para a latência.
Maximilian

1

Redis / memcached são armazenamentos na memória e geralmente devem ser mais rápidos que o DynamoDB para dados do tipo cache / fila. Eles também têm itens adicionais úteis, como chaves expiradas, Pub / Sub em Redis, etc. que o Dynamo pode não ter.


1
Obrigado. Sei que o cache está na memória, mas li que é possível esperar pelo menos uma viagem de ida e volta de ~ 10ms para atingi-lo e voltar, o que torna as características de desempenho as mesmas do Dynamo. Eu acho que você está certo que pode querer que recursos específicos no memcached não estejam disponíveis no dínamo. Mas, para mim, a principal vantagem de um cache de RAM é o aumento do desempenho de ordens de magnitude em relação a uma loja durável, que parece não se aplicar aqui.
Scott Klarenbach
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.