O que são bancos de dados em memória?

Objetivos

Nesta aula você vai:

• Compreender o que caracteriza um banco de dados em memória (in-memory database)
• Comparar armazenamento em RAM com persistência em disco
• Identificar limitações de custo, capacidade e durabilidade

Introdução

Toda aplicação manipula dados temporários na memória RAM durante a execução — variáveis, objetos, buffers. Um banco de dados em memória vai além: é um sistema de gerenciamento projetado para armazenar dados primariamente na RAM, oferecendo interface de banco (comandos, protocolo, replicação) com latência ordens de magnitude menor que sistemas baseados em disco.

A confusão é comum: "Redis é um banco ou um cache?" A resposta honesta é depende do uso. Redis pode funcionar como cache efêmero ou como store com persistência. O que o define como in-memory database é a localização primária dos dados ativos — na memória — e o modelo de acesso otimizado para isso.

Conteúdo

Definição e arquitetura básica

Um banco em memória mantém estruturas de dados — tabelas, documentos, grafos ou chave-valor — diretamente na RAM do servidor (ou em memória compartilhada em clusters). O disco, quando presente, serve como:

• Log de append (como AOF no Redis) para recuperação após falha
• Snapshot periódico (como RDB) para backup
• Tier secundário em soluções híbridas (dados frios no SSD, quentes na RAM)

A hierarquia clássica de armazenamento ilustra o ganho:

Operar na camada RAM significa que um GET ou SELECT evita seek de disco e desserialização pesada — daí a latência consistente em microssegundos.

In-memory database vs cache de aplicação

Um ConcurrentHashMap na JVM resolve cache local; Redis resolve estado compartilhado entre dezenas de pods em Kubernetes.

Volatilidade, consistência e o mito da "perda total"

RAM é volátil: sem energia, o conteúdo desaparece. Por isso, bancos em memória implementam mecanismos de durabilidade assíncronos ou síncronos:

• RDB: snapshot point-in-time em intervalos
• AOF: log de cada comando de escrita
• Replicação: cópia em outro nó antes de confirmar ao cliente (dependendo da configuração)

Nenhum sistema oferece garantias gratuitas: appendfsync always no Redis aumenta durabilidade e reduz throughput. Engenharia de dados em memória é, em grande parte, negociar latência versus durabilidade.

Quando usar e quando evitar

Adequado para:

• Dados com alta taxa de leitura/escrita e baixa latência exigida
• Sessões, tokens, rate limits, feature flags
• Agregações em tempo real, contadores, rankings
• Filas de curta duração e buffers entre sistemas

Evitar como fonte única de verdade para:

• Dados regulatórios que exigem auditoria forte sem backup robusto
• Volumes que excedem RAM disponível sem arquitetura de tiering
• Workloads analíticos massivos (scan de bilhões de linhas) — OLAP em disco/coluna costuma vencer

Exemplos práticos

Verifique o uso de memória e a política de evicção no Redis:

redis-cli INFO memory

Saída relevante inclui used_memory_human, maxmemory e maxmemory_policy. Se maxmemory estiver definido e a política for allkeys-lru, o Redis remove chaves menos usadas quando a RAM enche — comportamento típico de cache, não de banco durável.

Para contrastar latência, um ping simples:

redis-cli --latency

Valores estáveis abaixo de 1 ms em rede local demonstram por que workloads sensíveis a latência migram para memória.

Persistência mínima para não perder tudo após restart:

# No redis.conf ou via CONFIG SET
CONFIG SET save "900 1 300 10 60 10000"
CONFIG SET appendonly yes

Isso transforma um store puramente volátil em sistema com recuperação possível após queda — característica de banco em memória maduro, não de cache local descartável.

Resumo

• Bancos de dados em memória armazenam dados ativos na RAM, com protocolo e recursos de banco (replicação, persistência opcional).
• O ganho principal é latência baixa e previsível; o custo é RAM cara e atenção à volatilidade.
• Diferem de cache em processo por serem compartilhados, operáveis e escaláveis como infraestrutura.
• Durabilidade é configurável — não é tudo-ou-nada — mas envolve trade-offs de performance.
• Use para hot data e tempo real; combine com bancos em disco para cold data e conformidade.