Introdução ao Aerospike

Objetivos

Nesta aula você vai:

• Entender a origem e o propósito do Aerospike no panorama de sistemas de alta performance
• Conhecer o vocabulário fundamental: cluster, namespace, set, bin e key
• Posicionar o Aerospike frente a outras soluções que você já estudou no módulo

Conteúdo

Uma biblioteca que nunca fecha

Imagine uma biblioteca municipal projetada para atender milhões de leitores simultâneos, onde cada consulta ao catálogo deve retornar em menos de um milissegundo — não importa se o livro está na estante da memória ou no porão dos arquivos. Essa é a promessa do Aerospike: um banco de dados NoSQL distribuído, otimizado para leituras e escritas de altíssima velocidade em escala global.

Criado em 2009 (originalmente como Citrusleaf) e renomeado em 2012, o Aerospike nasceu em um momento em que a internet já exigia infraestrutura capaz de sustentar publicidade em tempo real, perfis de usuário massivos e decisões automatizadas sobre milhões de eventos por segundo. Diferente de um cache efêmero, o Aerospike combina persistência durável com latência próxima à da RAM.

O que o Aerospike não é

Antes de avançar, vale desfazer três equívocos comuns:

O Aerospike ocupa um nicho específico: armazenamento operacional de baixa latência em escala, frequentemente como sistema primário para perfis, sessões, inventário em tempo real ou feature stores de machine learning.

Modelo de dados: namespaces, sets e bins

O vocabulário do Aerospike lembra uma organização bibliotecária em camadas:

• Namespace — equivalente a um "andar" ou departamento inteiro da biblioteca. Define políticas de replicação, retenção e armazenamento (memória, disco ou híbrido).
• Set — uma coleção lógica dentro do namespace, semelhante a uma estante temática (ex.: usuarios, sessoes, produtos).
• Key — o identificador único do registro, como o código de barras de um exemplar.
• Bins — campos nomeados que compõem o registro. Diferente de colunas rígidas em SQL, bins são flexíveis e tipados em tempo de escrita.

Um registro típico pode ser representado assim:

namespace: ecommerce
set: clientes
key: cliente-48291
bins:
  nome: "Mariana Costa"
  email: "mariana@exemplo.com"
  ultimo_acesso: 1719878400
  tier: "premium"

Arquitetura em alto nível

O cluster Aerospike é composto por nós que se comunicam via protocolo proprietário otimizado. Cada nó participa do particionamento automático dos dados (4096 partitions por padrão) e pode atuar como primário ou réplica de partições específicas.

┌─────────────────────────────────────────────────┐
│              Cluster Aerospike                   │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐        │
│  │  Nó 1   │  │  Nó 2   │  │  Nó 3   │        │
│  │ Primary │  │ Replica │  │ Primary │  ...   │
│  │ + SSD   │  │ + SSD   │  │ + SSD   │        │
│  └─────────┘  └─────────┘  └─────────┘        │
└─────────────────────────────────────────────────┘
         ▲                    ▲
         │                    │
    Aplicações           Clientes (Java, Go, Python...)

A combinação de índice em memória com dados em SSD permite que o sistema mantenha latências na casa de sub-milissegundos mesmo com datasets que excedem a RAM disponível — tema que exploraremos na próxima aula.

Primeiro contato com a ferramenta

Embora o Aerospike use seu próprio protocolo (não redis-cli), é útil comparar mentalmente com comandos Redis que você já conhece:

Exemplo com aql (Aerospike Query Language), o cliente de linha de comando:

# Conectar ao cluster local
aql

# Inserir um registro de sessão
INSERT INTO ecommerce.sessoes (PK, usuario_id, expira_em) VALUES ('sess-abc', 'user-42', 1720000000)

# Consultar
SELECT * FROM ecommerce.sessoes WHERE PK='sess-abc'

# Atualizar um bin específico
UPDATE ecommerce.sessoes SET tier='gold' WHERE PK='sess-abc'

Para quem vem do ecossistema Redis, o paralelo é claro: ambos priorizam acesso por chave. A diferença está na durabilidade nativa, no particionamento automático e na escalabilidade horizontal sem resharding manual.

Quando considerar o Aerospike

O Aerospike brilha em cenários onde latência P99 abaixo de 5 ms e milhões de operações por segundo são requisitos de negócio, não luxo técnico:

• Publicidade programática — lances em leilões de milissegundos
• Telecomunicações — perfis de assinante e políticas de roteamento
• E-commerce em escala — carrinhos, inventário e recomendações em tempo real
• Fraud detection — scoring instantâneo com histórico recente

Se o seu sistema cabe confortavelmente em um único nó Redis com poucos gigabytes de dados, o Aerospike pode ser excessivo. Se você precisa de durabilidade + escala + latência previsível, ele merece avaliação séria.

Métricas que importam desde o início

Ao estudar qualquer sistema de cache ou banco em memória, evite olhar apenas para a média. O Aerospike, como Redis em produção, deve ser avaliado por percentis de latência:

Uma média de 0,5 ms pode esconder picos de 50 ms que arruínam a experiência do usuário. Guardaremos esse vocabulário para as aulas de performance.

Resumo

• Aerospike é um banco NoSQL distribuído focado em baixa latência, alta vazão e persistência durável
• O modelo de dados usa namespaces, sets, keys e bins — flexível e orientado a chave
• Diferencia-se de Redis e Memcached pela combinação de escala horizontal nativa com armazenamento em SSD
• Avalie sempre latência por percentis (P50, P95, P99), não apenas pela média

Para refletir

"A velocidade sem durabilidade é um sussurro; a durabilidade sem velocidade é um arquivo morto. O Aerospike tenta ser a voz que o sistema operacional ouve em tempo real."

Pense em um sistema que você conhece: quais dados poderiam viver no Aerospike e quais definitivamente pertencem a um banco relacional?