Arquitetura híbrida de memória e disco

Objetivos

Nesta aula você vai:

• Desvendar como o Aerospike mantém latência de memória com capacidade de disco
• Conhecer os modos de armazenamento e quando escolher cada um
• Entender o mecanismo de fabric bin e sua relação com replicação

Conteúdo

O dilema clássico: velocidade ou capacidade?

Toda engenharia de dados enfrenta o mesmo drama narrado por Borges: uma biblioteca infinita exige um índice igualmente vasto. Na prática, RAM é rápida e cara; SSD é mais lenta e barata; HDD é lenta e abundante. O Aerospike resolve o enredo com uma arquitetura que separa onde o índice vive de onde os dados persistem.

Enquanto Redis tradicionalmente guarda valores inteiros na memória (com persistência opcional via RDB/AOF), o Aerospike foi desenhado desde a origem para que o índice primário resida em RAM e os registros completos possam residir em SSD, mantendo latências comparáveis a sistemas puramente em memória.

Anatomia de uma escrita

Quando uma aplicação grava um registro no Aerospike, o fluxo interno segue etapas cuidadosamente orquestradas:

Cliente                    Nó primário                    Réplicas
  │                            │                            │
  │── PUT(key, bins) ─────────►│                            │
  │                            │── Atualiza índice (RAM) ──►│
  │                            │── Persiste no SSD ────────►│
  │                            │── Envia fabric bin ───────►│── Aplica réplica
  │◄── Confirmação ────────────│                            │

1. Índice primário (RAM) — estrutura hash que mapeia a chave para a localização do registro no SSD. Permite lookup em microssegundos.
2. Gravação no SSD — o registro serializado é escrito de forma append-only no dispositivo de bloco.
3. Propagação via fabric bin — pacote binário compacto enviado às réplicas para sincronização.

Essa separação é o coração da arquitetura híbrida: a RAM responde "onde está?", o SSD responde "o que contém?".

Modos de armazenamento

O Aerospike oferece flexibilidade por namespace. A escolha define o trade-off entre custo, capacidade e latência:

A configuração ocorre no arquivo aerospike.conf por namespace:

namespace ecommerce {
    replication-factor 2
    memory-size 4G
    storage-engine device {
        file /opt/aerospike/data/ecommerce.dat
        filesize 100G
        data-in-memory false
    }
}

O parâmetro data-in-memory true manteria uma cópia dos dados também na RAM — útil para leituras ainda mais agressivas, ao custo de maior consumo de memória.

O fabric bin: mensageiro entre nós

O fabric bin é o formato binário interno que o Aerospike usa para replicar operações entre nós do cluster. Diferente de replicar o estado completo periodicamente, o fabric transmite operações incrementais — cada PUT, DELETE ou UPDATE — de forma eficiente pela rede.

Analogia literária: imagine que, em vez de fotocopiar livros inteiros entre filiais, a biblioteca envia apenas fichas de alteração — "adicionar exemplar X na prateleira Y" — reduzindo drasticamente o tráfego de rede.

Benefícios práticos:

• Replicação síncrona ou assíncrona configurável por namespace
• Recuperação rápida após falha de nó — réplicas já possuem dados atualizados
• Rebalanceamento — ao adicionar nós, partições migram sem downtime prolongado

Defragmentação e ciclo de vida no SSD

SSD não é RAM: escrita append-only gera fragmentação ao longo do tempo. O Aerospike executa defragmentação em background, compactando blocos obsoletos sem bloquear operações de leitura/escrita — um detalhe de engenharia que separa bancos "de laboratório" de sistemas de produção.

O ciclo típico:

Escrita append-only → Registros obsoletos (updates/deletes) →
Defrag em background → Espaço recuperado → Continuidade operacional

Monitore métricas como device_defrag_q e device_available_pct para antecipar saturação de disco antes que a latência P99 degrade.

Comparando com Redis: persistência lado a lado

Para consolidar o aprendizado, compare as estratégias de persistência:

No Redis, você pode mitigar latência de persistência com:

redis-cli CONFIG SET appendfsync everysec
redis-cli CONFIG GET save

No Aerospike, a persistência é intrínseca ao storage-engine, não um módulo opcional acoplado depois.

Dimensionamento: a arte de equilibrar RAM e SSD

Regra prática para namespaces híbridos:

• RAM (memory-size) — dimensione para o índice primário: aproximadamente 64 bytes por registro + overhead de namespaces e índices secundários
• SSD (filesize) — dimensione para o volume total de dados, com margem de 20–30% para defragmentação
• Réplicas — cada replication-factor multiplica o armazenamento necessário

Exemplo: 100 milhões de registros com média de 500 bytes cada:

Dados brutos:     100M × 500B  = ~50 GB SSD
Índice primário:  100M × 64B   = ~6,4 GB RAM
Com RF=2:         ~100 GB SSD total no cluster

Latência na arquitetura híbrida

Mesmo com SSD, o Aerospike mantém latências competitivas graças ao índice em RAM e à escrita sequencial otimizada:

Compare com Redis em memória pura (P50 ~ 0,1 ms) e perceba o trade-off: Aerospike entrega dezenas de terabytes com latência ainda aceitável para workloads operacionais.

Resumo

• A arquitetura híbrida separa índice em RAM de dados em SSD, combinando velocidade e capacidade
• O fabric bin replica operações incrementalmente entre nós, não snapshots completos
• Escolha o storage-engine conforme volatilidade dos dados: memória pura, híbrido ou disco
• Dimensione RAM para o índice e SSD para o volume de dados, incluindo fator de replicação

Para refletir

Em um e-commerce com 50 milhões de perfis de cliente, cada um com ~2 KB de dados, quanta RAM e SSD você estimaria para um namespace Aerospike com replication-factor 2?