Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration

O artigo apresenta o Nezha, um sistema de armazenamento distribuído que integra separação de chaves-valor com o protocolo Raft para eliminar a sobrecarga de I/O causada por operações de persistência sobrepostas, resultando em melhorias significativas de desempenho em operações de leitura e escrita.

O essencial

Imagine que você está gerenciando uma biblioteca gigante e caótica onde milhões de pessoas pedem livros (dados) todos os segundos. O problema é que, para garantir que ninguém roube um livro ou que a história seja contada da mesma forma para todos, os bibliotecários precisam seguir regras estritas de segurança (o protocolo Raft).

No entanto, no sistema antigo, para entregar um único livro, o bibliotecário tinha que fazer três cópias do mesmo livro em lugares diferentes apenas para garantir a segurança. Isso deixava o sistema lento, como se fosse um entregador de pizza que tivesse que fazer três viagens para entregar uma única pizza só para "certificar" que a pizza chegou.

O Nezha é o novo sistema de biblioteca que resolveu esse problema de forma inteligente. Aqui está como ele funciona, explicado de forma simples:

1. O Problema: A "Fotocopiadora" Exagerada

Nos sistemas tradicionais de armazenamento de dados (como o que usamos em bancos e redes sociais), quando você salva algo (um "Put"), o sistema faz três coisas pesadas:

1. Escreve um registro de segurança (o "diário" do Raft).
2. Escreve um registro de segurança no banco de dados (o "WAL").
3. Escreve o dado final no disco.

É como se você fosse ao correio para enviar uma carta, mas o carteiro fosse obrigado a fazer três cópias da carta, carimbá-las três vezes e enviá-las por três rotas diferentes antes de finalmente entregar a original. Isso gasta muita energia (I/O) e tempo.

2. A Solução do Nezha: Separar a "Capa" do "Conteúdo"

O Nezha usa uma ideia chamada Separação Chave-Valor. Pense em um livro de receitas:

• A Chave (Key): É o nome da receita (ex: "Bolo de Cenoura").
• O Valor (Value): É a receita em si (os ingredientes e o modo de preparo), que pode ser enorme.

No sistema antigo, eles tentavam guardar a receita inteira junto com o nome, repetidamente.
O Nezha faz algo diferente:

• Ele guarda apenas o nome da receita e um número de página (um "offset") no índice principal.
• A receita completa (o valor grande) é guardada uma única vez em um arquivo especial de "diário" (ValueLog).

A Analogia do Restaurante:
Imagine um restaurante onde o garçom (o sistema) anota no bloco de pedidos apenas: "Mesa 1: Prato X, Página 45 do livro de receitas".
Ele não escreve o prato inteiro no bloco. Ele apenas anota onde encontrar a receita. Isso torna o bloco de pedidos super leve e rápido. O livro de receitas (o valor) só é escrito uma vez, na cozinha, e não precisa ser copiado três vezes para cada pedido.

3. O Grande Desafio: A "Limpeza" (Garbage Collection)

Ao guardar apenas "números de página" e não os dados completos, o sistema cria um problema: se você quiser ler o "Bolo de Cenoura", o sistema precisa ir até a página 45 do livro de receitas. Se os pedidos chegarem em ordem aleatória, o livro fica bagunçado, e o garçom precisa correr de um lado para o outro procurando páginas (o que é lento para ler).

Além disso, quando um livro fica cheio de "rascunhos" de receitas antigas, é preciso limpá-lo. No sistema antigo, essa limpeza poderia travar o restaurante todo.

4. A Magia do Nezha: O "Faxineiro Inteligente" (GC Raft-Aware)

O Nezha tem um faxineiro especial que trabalha sem parar, mas de forma inteligente:

• Durante a limpeza: Ele não para o atendimento. Ele cria uma nova área de trabalho para os novos pedidos, enquanto limpa a área antiga.
• Organização: Ele pega as receitas espalhadas e as reorganiza em ordem alfabética em um novo livro.
• Índice Rápido: Ele cria um mapa (índice) que diz exatamente onde cada receita está, sem precisar vasculhar o livro todo.

Isso significa que, mesmo que o sistema esteja "faxinando" (reorganizando dados), ele continua rápido para ler e escrever.

5. O Resultado: Mais Rápido e Mais Barato

Os testes mostraram que o Nezha é um monstro de eficiência:

• Escrever (Salvar): Ficou 460% mais rápido. É como se o entregador de pizza agora entregasse 5 pizzas no tempo que antes levava para entregar 1.
• Ler (Buscar): Ficou 12,5% mais rápido em buscas simples e 72,6% mais rápido em buscas que envolvem vários itens (como "mostre-me todos os bolos").
• Segurança: Apesar de ser mais rápido, ele mantém todas as regras de segurança do protocolo Raft. Ninguém perde dados, e o sistema não quebra se um servidor cair.

Resumo Final

O Nezha é como transformar um sistema de entregas burocrático e lento em uma operação de precisão cirúrgica.

• Ele para de fazer cópias desnecessárias (reduzindo o trabalho repetitivo).
• Ele separa o que é importante (o nome) do que é pesado (o conteúdo).
• Ele organiza a bagunça enquanto o sistema continua funcionando.

Para o usuário final, isso significa que aplicativos de banco, redes sociais e jogos serão muito mais rápidos e responsivos, gastando menos energia e dinheiro em servidores.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration", estruturado conforme solicitado:

1. O Problema

O artigo identifica um gargalo de desempenho crítico em sistemas de armazenamento distribuído de chave-valor (KV) que utilizam o protocolo de consenso Raft combinado com motores de armazenamento baseados em LSM-tree (Log-Structured Merge-tree), como o RocksDB.

O problema central é a sobreposição de operações de persistência (redundância de I/O). Em uma arquitetura tradicional:

1. Persistência do Log Raft: O líder deve persistir as entradas do log no disco para garantir a consistência e a recuperação.
2. WAL do Storage Engine: Após o consenso, o motor de armazenamento (LSM-tree) escreve os dados em seu próprio Write-Ahead Log (WAL).
3. Memtable para SSTable: Quando a Memtable atinge a capacidade, os dados são despejados (flushed) para arquivos SSTable no disco.

Para uma única operação de escrita (Put), isso resulta em pelo menos três escritas em disco distintas para os mesmos dados de valor. Além disso, o processo de compaction do LSM-tree introduz amplificação de escrita adicional. Em ambientes modernos com SSDs NVMe de alto desempenho, essa ineficiência no nível de software (I/O redundante) tornou-se o principal gargalo, limitando a vazão (throughput) e aumentando a latência.

2. Metodologia e Arquitetura

O sistema Nezha propõe uma reestruturação arquitetônica que integra profundamente a separação de chave-valor (Key-Value Separation) diretamente no protocolo Raft, criando um novo protocolo de consenso chamado KVS-Raft.

Principais Componentes da Solução:

• KVS-Raft (Protocolo de Consenso Otimizado):

  • Em vez de persistir o valor completo no estado da máquina e no log do Raft separadamente, o Nezha armazena apenas os valores no arquivo ValueLog (um log de append-only) e persiste apenas ponteiros de deslocamento (offsets) leves no estado da máquina e nos logs de replicação.
  • Isso unifica a persistência do valor com a replicação do log, reduzindo as escritas em disco de três para uma única vez por valor.
  • O líder persiste o valor no ValueLog, obtém o offset e envia apenas o offset para os seguidores e para a máquina de estado.

• Framework de Coleta de Lixo (GC) Consciente do Raft:

  • A separação de chave-valor pode degradar o desempenho de leitura (especialmente varreduras/Scan) devido à desordem dos dados no ValueLog. Para resolver isso, o Nezha implementa um mecanismo de GC adaptativo.
  • O GC reorganiza os dados espalhados em arquivos ordenados (Sorted ValueLog) baseados nas chaves, criando estruturas de índice eficientes (Hash Index para pontos, organização sequencial para intervalos).
  • O GC é dividido em três fases para garantir disponibilidade e consistência durante a reorganização:
    1. Pré-GC: Dados escritos no armazenamento ativo.
    2. Durante-GC: Novas requisições são redirecionadas para um novo módulo de armazenamento (New Storage), enquanto o GC compacta os dados antigos em um módulo final (Final Compacted Storage).
    3. Pós-GC: O sistema troca os módulos, removendo os dados antigos e mantendo apenas os dados compactados e ordenados.

• Mecanismo de Processamento de Requisições em Três Fases:

  • O sistema gerencia requisições de leitura (Get, Scan) de forma diferente dependendo da fase do GC.
  • Para leituras, o sistema realiza consultas paralelas (assíncronas) em múltiplos módulos de armazenamento (ex: New Storage e Active Storage ou Sorted File) para garantir que a versão mais recente dos dados seja retornada sem bloquear o sistema.

3. Contribuições Chave

1. Identificação do Gargalo: Demonstrar que a persistência redundante entre o protocolo de consenso e o motor de armazenamento é um problema fundamental em sistemas modernos, não apenas um detalhe de implementação.
2. KVS-Raft: Proposta de um novo protocolo de consenso que integra nativamente a separação de chave-valor, eliminando a necessidade de duplicar a persistência de valores entre o log do Raft e o WAL do storage engine.
3. GC Consciente do Raft: Design de um framework de coleta de lixo que mantém as propriedades de segurança do Raft (ordem e completude dos logs) enquanto otimiza o layout de dados para leituras rápidas, resolvendo o trade-off clássico da separação de chave-valor.
4. Mecanismo de Transição de Fase: Implementação de um mecanismo robusto de três fases para garantir a consistência e a disponibilidade contínua durante operações de manutenção pesada (GC).

4. Resultados Experimentais

Os autores implementaram o Nezha em Go e realizaram extensas avaliações comparativas contra sistemas como o TiKV, o original (Raft + RocksDB), PASV, LSM-Raft e distribuições de WiscKey.

• Desempenho de Escrita (Put):

  • O Nezha alcançou um aumento de vazão médio de 460,2% em comparação com o sistema tradicional (Original).
  • A latência de escrita foi reduzida em 59,2%.
  • O ganho é mais pronunciado para valores grandes, onde a amplificação de escrita tradicional é mais severa.

• Desempenho de Leitura Ponto (Get):

  • O Nezha superou o sistema original em 12,5% de vazão.
  • A redução de latência foi de 10,3%.
  • Isso demonstra que o mecanismo de GC e os índices hash compensaram eficazmente a sobrecarga de busca de offset inerente à separação de chave-valor.

• Desempenho de Varredura (Scan):

  • O Nezha obteve um aumento de vazão de 72,6% em comparação ao original.
  • A latência de leitura foi reduzida em 39,2%.
  • O sistema transformou I/O aleatório (comum em separação de chave-valor não otimizada) em I/O sequencial através da compactação ordenada.

• Escalabilidade e Recuperação:

  • O sistema manteve desempenho robusto ao aumentar o tamanho do cluster (de 3 para 7 nós).
  • O tempo de recuperação após falhas foi reduzido em aproximadamente 33-35%, pois menos dados precisam ser carregados do disco (apenas offsets no RocksDB e logs compactados).

5. Significado

O trabalho do Nezha é significativo porque redefine a interação entre camadas de consenso e armazenamento em sistemas distribuídos.

• Eficiência de I/O: Ao reduzir as escritas em disco de três para uma, o Nezha libera o potencial dos SSDs modernos, que são limitados por ineficiências de software e não mais por hardware.
• Custo e Consistência: Oferece uma solução que não sacrifica a consistência forte (garantida pelo Raft) nem a durabilidade dos dados, mas elimina o desperdício de recursos de armazenamento e I/O.
• Viabilidade Prática: A demonstração de que a separação de chave-valor pode ser aplicada de forma segura e eficiente em um contexto de consenso distribuído (e não apenas em sistemas single-node como o WiscKey) abre caminho para uma nova geração de bancos de dados distribuídos de alta performance.

Em resumo, o Nezha resolve o problema da "amplificação de escrita" em sistemas distribuídos através de uma co-projeto (co-design) inteligente entre o protocolo de consenso e o mecanismo de armazenamento, oferecendo ganhos de desempenho drásticos tanto para cargas de trabalho de escrita quanto de leitura.