As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Escolha entre opções de implantação
A Amazon ElastiCache tem duas opções de implantação:
Armazenamento em cache sem servidor
Clusters autoprojetados
Para obter uma lista de comandos aceitos para ambos, consulte Comandos Valkey, Memcached e Redis OSS suportados e restritos.
Armazenamento em cache sem servidor
O Amazon ElastiCache Serverless simplifica a criação de cache e escala instantaneamente para dar suporte aos aplicativos mais exigentes dos clientes. Com o ElastiCache Serverless, você pode criar um cache altamente disponível e escalável em menos de um minuto, eliminando a necessidade de provisionar, planejar e gerenciar a capacidade do cluster de cache. ElastiCache O Serverless armazena automaticamente dados de forma redundante em três zonas de disponibilidade e fornece um Acordo de Nível de Serviço (SLA) de 99,99% de disponibilidade. Os backups de clusters Valkey autoprojetados ou de Redis OSS podem ser restaurados em uma configuração com tecnologia sem servidor.
Clusters autoprojetados
Se você precisar de um controle refinado sobre seu cluster Valkey, Memcached ou Redis OSS, você pode optar por criar seu próprio cluster com. ElastiCache ElastiCache permite operar um cluster baseado em nós, escolhendo o tipo de nó, o número de nós e o posicionamento dos nós nas zonas de AWS disponibilidade do seu cluster. Como ElastiCache é um serviço totalmente gerenciado, ele ajuda a gerenciar o provisionamento de hardware, o monitoramento, as substituições de nós e a aplicação de patches de software para seu cluster. Clusters autoprojetados podem ser projetados para fornecer um SLA de disponibilidade de até 99,99%. Backups de caches Valkey ou Redis OSS de tecnologia sem servidor podem ser restaurados em um cluster autoprojetado.
Escolha entre opções de implantação
Escolha o armazenamento sem servidor se:
Você está criando um cache para workloads novas ou difíceis de prever.
Você tem tráfego de aplicativos imprevisível.
Você deseja a maneira mais fácil de começar a usar um cache.
Escolha criar seu próprio ElastiCache cluster se:
Você já está executando o ElastiCache Serverless e quer um controle mais refinado sobre o tipo de nó que executa Valkey, Memcached ou Redis OSS, o número de nós e o posicionamento desses nós.
Você espera que o tráfego do seu aplicativo seja relativamente previsível e deseja um controle refinado sobre desempenho, disponibilidade e custo.
Você pode prever os requisitos de capacidade para controlar os custos.
Comparar cache com tecnologia sem servidor e clusters autoprojetados
| Atributo | Armazenamento em cache sem servidor | Clusters autoprojetados |
|---|---|---|
|
Configuração de cache |
Crie um cache com apenas um nome em menos de um minuto |
Fornece controle refinado sobre o design do cluster de cache. O usuário pode escolher o tipo de nó, o número de nós e o posicionamento nas zonas AWS de disponibilidade |
|
ElastiCache Versão suportada |
Valkey 7.2 e superior, Redis OSS versão 7.1 e superior, Memcached 1.6.21 e superior |
Valkey 7.2 e superior, Redis OSS versão 4.0 e superior, Memcached 1.4 e superior |
|
Modo Cluster (Valkey e Redis OSS) |
Opera motores somente em |
Pode ser configurado para operar no modo cluster habilitado ou desabilitado. |
|
Escalabilidade |
Escala automaticamente os mecanismos vertical e horizontalmente sem qualquer gerenciamento de capacidade. |
Fornece controle sobre o escalonamento, ao mesmo tempo em que exige monitoramento para garantir que a capacidade atual esteja atendendo adequadamente à demanda. Para Valkey e Redis OSS, você pode escolher escalar verticalmente aumentando ou diminuindo o tamanho do nó de cache quando necessário. Você também pode escalar horizontalmente ao adicionar novos fragmentos ou adicionar mais réplicas aos fragmentos. Esse recurso não está disponível para o Memcached. Com o atributo de ajuste de escala automático, você também pode configurar o dimensionamento com base em uma programação ou em métricas como uso de CPU e memória no cache. |
|
Conexão do cliente |
Os clientes se conectam a um único endpoint. Isso permite que a topologia do nó de cache subjacente (escalonamento, substituições e atualizações) mude sem desconectar o cliente. |
Os clientes se conectam a cada nó de cache individual. Se um nó for substituído, o cliente redescobre a topologia do cluster e restabelece as conexões. |
|
Configure |
Nenhuma configuração refinada disponível. Os clientes podem configurar configurações básicas, incluindo sub-redes que podem acessar o cache, se os backups automáticos estão ativados ou desativados e limites máximos de uso do cache. |
Clusters autoprojetados oferecem opções de configuração refinadas. Os clientes podem usar grupos de parâmetros para um controle refinado. Para uma tabela desses valores de parâmetro por tipo de nó, consulte Parâmetros específicos do mecanismo. |
|
Multi-AZ |
Os dados são replicados de forma assíncrona em várias Zonas de Disponibilidade para maior disponibilidade e melhor latência de leitura. |
Fornece uma opção para projetar o cluster em uma única zona de disponibilidade ou em várias zonas de disponibilidade (AZs). Ao usar o Valkey ou o Redis OSS, são fornecidos clusters Multi-AZ com dados replicados de forma assíncrona em várias zonas de disponibilidade para maior disponibilidade e melhor latência de leitura. |
|
Criptografia em repouso |
Sempre habilitado. Os clientes podem usar uma chave Chave gerenciada pela AWS ou uma chave gerenciada pelo cliente AWS KMS. |
Opção para habilitar ou desabilitar a criptografia em repouso. Quando ativada, os clientes podem usar uma chave Chave gerenciada pela AWS ou uma chave gerenciada pelo cliente AWS KMS. |
|
Criptografia em trânsito (TLS) |
Sempre habilitado. Os clientes devem oferecer suporte à conectividade TLS. |
Opção para habilitar ou desabilitar. |
|
Backups |
Aceita backups automáticos e manuais de caches sem impacto no desempenho. Os backups do Valkey e do Redis OSS são compatíveis entre si e podem ser restaurados em um cache ElastiCache sem servidor ou em um cluster autoprojetado. |
Aceita backups automáticos e manuais para Valkey e Redis OSS. Os clusters podem ter algum impacto sobre o desempenho, dependendo da memória reservada disponível. Para obter mais informações, consulte Gerenciamento de memória reservada para Valkey e Redis OSS. Os backups do Valkey e do Redis OSS são compatíveis entre si e podem ser restaurados em um cache ElastiCache sem servidor ou em um cluster autoprojetado. |
|
Monitoramento |
Support métricas em nível de cache, incluindo taxa de acerto do cache, taxa de erro do cache, tamanho dos dados e ECPUs consumo. ElastiCache O Serverless envia eventos usando EventBridge quando eventos significativos acontecem em seu cache. Você pode escolher monitorar, ingerir, transformar e agir em ElastiCache eventos usando a Amazon EventBridge. Para obter mais informações, consulte Eventos de cache sem servidor. |
ElastiCache clusters autoprojetados emitem métricas em cada nível de nó, incluindo métricas em nível de host e métricas de cache. Clusters autoprojetados emitem notificações de SNS para eventos significativos. Consulte Métricas para o Memcached e Métricas para o Valkey e Redis OSS. |
|
Disponibilidade |
Acordo de Serviço (SLA) |
Clusters autoprojetados podem ser projetados para atingir um Acordo de Serviço (SLA) |
|
Atualizações e correções de software |
Atualiza automaticamente o software de cache para a versão secundária e de patch mais recente, sem impacto no aplicativo. Os clientes recebem uma notificação sobre atualizações de versões principais e podem atualizar para a versão principal mais recente quando quiserem. |
Os clusters autoprojetados oferecem autoatendimento habilitado pelo cliente para atualizações de versões secundárias e de patches, bem como atualizações de versões principais. As atualizações gerenciadas são aplicadas automaticamente durante as janelas de manutenção definidas pelo cliente. Os clientes também podem optar por aplicar um upgrade de versão secundária ou de patch sob demanda. |
|
Global Data Store |
Sem compatibilidade |
Suporta Global Data Store, que permite replicação entre regiões com gravações de região única e leituras multirregionais |
|
Hierarquização de dados |
Sem compatibilidade |
Clusters que são projetados usando nós da família r6gd têm seus dados classificados em níveis entre a memória e o armazenamento local em unidades de estado sólido (Solid state Drives, SSD). O armazenamento de dados em camadas fornece uma opção de preço-desempenho para cargas de trabalho Valkey e Redis OSS, utilizando unidades de estado sólido (SSDs) de baixo custo em cada nó do cluster, além de armazenar dados na memória. |
|
Modelo de definição de preços |
Pay-per-use, com base em dados armazenados em GB-hora e solicitações em Unidades de ElastiCache Processamento (ECPU). Consulte detalhes de preço aqui |
Pay-per-hour, com base no uso do nó de cache. Consulte detalhes de preço aqui |
Tópicos relacionados:
