Arquitetura e desempenho

Objetivos

Nesta aula você vai:

• Entender como o DragonflyDB paraleliza operações sem sacrificar consistência por chave
• Conhecer estruturas internas como dashtable e o modelo de snapshot eficiente
• Ler resultados de benchmark com olhar crítico, separando marketing de evidência

Introdução

Toda grande obra literária esconde uma arquitetura: capítulos, narradores, linhas do tempo entrelaçadas. Por fora, o leitor vê fluidez; por dentro, há engenharia de ritmo. O DragonflyDB funciona assim. Na superfície, responde GET e SET como um Redis educado. Nas entranhas, uma orquestra de threads divide o trabalho com regras rígidas para que duas mãos nunca escrevam no mesmo parágrafo ao mesmo tempo.

Esta aula abre o livro pela encadernação: como o motor multithread foi construído e por que os números de desempenho fazem sentido — ou não — no seu ambiente.

Conteúdo

Modelo de concorrência: shared-nothing por shard

O princípio central é o sharding interno de chaves. Cada chave é mapeada para um shard (partição lógica) via hash. Cada shard possui:

• Um conjunto de estruturas de dados próprias
• Um thread (ou conjunto de threads) responsável por processar comandos que afetam chaves daquele shard

Esse desenho evita locks globais: o gargalo de um mutex único — comum em tentativas ingênuas de "paralelizar o Redis" — não aparece aqui porque o escopo de exclusão é local ao shard.

Dashtable: a estante compacta

O DragonflyDB substitui tabelas hash tradicionais por estruturas chamadas dashtable (dash + hashtable), otimizadas para:

• Menor overhead por entrada — mais chaves na mesma RAM
• Melhor localidade de cache da CPU — menos misses de L1/L2
• Crescimento incremental sem rehash catastrófico

Em workloads com milhões de chaves pequenas (sessões, tokens, flags), a economia de memória pode equivaler a adiar a compra de RAM — ou reduzir instâncias no cluster.

Pipeline de rede e threads de I/O

Conexões TCP não bloqueiam o processamento de outras conexões da mesma forma que num modelo estritamente single-thread. Threads dedicados a I/O alimentam filas de comandos; threads de execução consomem essas filas por shard.

Fluxo simplificado:

Cliente → [Thread I/O] → Fila de comandos → [Thread Shard N] → Resposta

O ganho aparece quando centenas de milhares de comandos simples chegam por segundo: enquanto um shard processa HGETALL pesado, outros shards continuam atendendo GET/SET leves.

Snapshotting e persistência

DragonflyDB oferece persistência via snapshots (RDB-like) com técnicas para minimizar pausa durante o dump. O snapshot paralelo — capturando shards de forma coordenada — contrasta com o fork + copy-on-write do Redis, que em datasets grandes pode causar picos de latência e pressão de memória.

Consulte a documentação da versão que você usa: recursos de persistência evoluem rapidamente em projetos jovens.

Lendo benchmarks com senso crítico

Benchmarks publicados pelo projeto mostram ganhos de 10x–25x em throughput em hardware de muitos núcleos. Antes de reproduzir o entusiasmo no slide para a diretoria, pergunte:

1. Qual o mix de comandos? SET/GET puro favorece throughput; Lua scripts longos ou MULTI complexos reduzem paralelismo
2. Qual o tamanho dos valores? Valores grandes shiftam o gargalo para memória e serialização
3. Quantas conexões? Pipeline com poucas conexões vs. milhares de clientes muda o perfil
4. Qual hardware? Ganhos multithread exigem CPUs com muitos núcleos reais, não apenas VMs pequenas

Ferramentas como memtier_benchmark e redis-benchmark (compatível) ajudam a gerar dados no seu ambiente:

memtier_benchmark -s localhost -p 6379 --ratio=1:0 -n 100000 -t 8 -c 50

Compare DragonflyDB e Redis na mesma máquina, com mesma versão de cliente e mesma configuração de rede.

Limites do desenho multithread

Nem toda carga se beneficia:

• Hot keys: uma chave super popular concentra tráfego em um único shard — o paralelismo não ajuda
• Scripts Lua longos: executam de forma atômica e podem bloquear o shard
• Operações multi-key frequentes: coordenação entre shards adiciona latência

O arquiteto experiente mapeia o padrão de acesso antes de escolher a ferramenta — como um crítico literário identifica se a narrativa é linear ou polifônica antes de julgar o ritmo.

Resumo

• DragonflyDB paraleliza via sharding interno de chaves, mantendo consistência por chave dentro do mesmo shard
• Estruturas como dashtable reduzem overhead de memória e melhoram localidade de cache
• Snapshotting paralelo busca minimizar pausas de persistência em datasets grandes
• Benchmarks impressionam em cargas paralelizáveis; hot keys, scripts longos e transações multi-key limitam ganhos reais
• Meça no seu hardware e com seu mix de comandos — desempenho de laboratório raramente replica produção sem adaptação