Rearquitetando: migração de Redis para SQLite

Contexto

• A Wafris é uma empresa de firewall de aplicações web open source que oferece um cliente de middleware para Rails
• O cliente v1 inicial exigia um armazenamento de dados local em Redis, mas agora a empresa lançou o cliente v2 usando SQLite
• Este texto aborda o processo de decisão da migração de Redis para SQLite, considerações de desempenho e mudanças de arquitetura

Resumo

• SQLite, Redis e RDBMS tradicionais (Postgres/MySQL) têm, cada um, vantagens e desvantagens
• Esses armazenamentos de dados não são intercambiáveis, e tentar tratá-los assim pode causar problemas
• Este texto explica o processo de reestruturar o cliente v1 baseado em Redis para um cliente v2 baseado em SQLite

O que forçou essa mudança?

• O objetivo da Wafris é permitir que desenvolvedores protejam seus sites com facilidade
• O cliente v1 usava Redis como armazenamento de dados, mas muitos usuários enfrentavam problemas ao implantar o Redis
• A mudança para SQLite foi feita para reduzir a carga de os usuários terem de atuar como administradores de Redis

O que é velocidade?

• O Redis é rápido em comparação com RDBMS tradicionais, mas ainda há muitos elementos para administrar
• Em ambientes de nuvem, a latência de rede é um grande problema
• O SQLite pode oferecer desempenho melhor ao reduzir o tempo de ida e volta na rede

Suposições monolíticas

• Muitas aplicações distribuídas causam problemas no uso de Redis
• A arquitetura foi repensada para reduzir a complexidade do uso de Redis

Adoção do SQLite

• O SQLite reduz gargalos de IO de rede
• O SQLite compete com a abertura de arquivos (fopen()) e não com bancos de dados cliente/servidor

Benchmarking de SQLite e Redis

• Em casos de uso específicos, o SQLite é cerca de 3 vezes mais rápido que o Redis
• Mesmo sem considerar a latência de rede, o SQLite é mais rápido

O que está faltando nos gráficos

• Mesmo que o desempenho do SQLite seja pior nos benchmarks, em ambientes reais ele pode ser mais rápido por causa da latência de rede
• O SQLite facilita a escalabilidade horizontal e reduz a carga de instalação e configuração para os usuários

Construindo uma arquitetura de sincronização

• No v1 (Redis), quando o usuário atualizava as regras, elas eram atualizadas no armazenamento de dados Redis
• No v2 (SQLite), o cliente verifica periodicamente se há regras atualizadas e baixa um novo banco de dados SQLite

Arquitetura distribuída com SQLite

• O problema de gargalo do banco de dados é resolvido sincronizando o banco SQLite com cada instância de computação

Conclusão

• A arquitetura v2 baseada em SQLite ajuda muitos sites a resistirem a ataques e permanecerem online
• Ela impõe menos carga aos usuários e oferece uma internet mais segura e mais protegida

Resumo do GN⁺

• Este texto explica o processo de migração de Redis para SQLite e os motivos dessa decisão
• O SQLite melhora o desempenho ao reduzir a latência de rede e diminui a carga de instalação e configuração para o usuário
• A arquitetura distribuída com SQLite resolve problemas de gargalo do banco de dados
• Este texto oferece insights sobre como implantar um firewall de aplicações web com facilidade e fazê-lo operar rapidamente

[GN⁺]

Comentários do Hacker News

• Há interesse em um modelo em que cada servidor de aplicação copia um arquivo de banco de dados SQLite e o substitui periodicamente

  • Usado para regras de firewall de aplicação web
  • Também pode ser usado para configuração de feature flags
  • Tudo bem se as feature flags levarem alguns segundos para serem atualizadas

• A latência de leitura/escrita do Redis é proporcional ao número de chaves consultadas

  • Um app monolítico usando Postgres e Redis funcionou bem
  • Como o Redis é single-threaded, recursos de leitura em massa podem deixar outras tarefas mais lentas
  • O Redis é bom para ler e escrever uma chave ou um pequeno conjunto fixo de chaves
  • Foi interessante que o SQLite teve bom desempenho em comparação com uma instância local do Redis

• O conjunto de dados parece ter 1,2 milhão de itens, mas na prática não é grande

  • Endereços IPv4 ocupam 4,8MB e podem ficar ainda menores com compressão simples
  • Se o Ruby suportasse mmap, seria melhor usar a lista de IPs diretamente

• Em um hackathon interno da Neon, foi escrito um servidor Node.js que converte o protocolo do Redis em consultas Postgres

  • Foi um projeto de hacking divertido

• No RailsWorld 2023, havia um clima negativo em relação ao Redis

  • Havia a suposição de que era necessário um servidor Redis
  • Como houve pouca experiência com Redis, ficou a dúvida se o ecossistema atual está se voltando contra o Redis

• O SQLite parece um caso de uso de nicho que funciona bem no lado do servidor sem replicação

  • Outra alternativa seria usar arquivos estáticos carregados em memória
  • O SQLite é uma boa alternativa

• Existe um projeto chamado Redka que implementa Redis sobre SQLite

• A melhor citação: "SQLite não compete com bancos de dados cliente/servidor. SQLite compete com fopen()."

• O Redis é rápido em comparação com RDBMS tradicionais, mas exige administração

  • Todo banco de dados exige algum nível de administração
  • Se você não se preocupar com joins, inserção e busca de linhas também são muito rápidas

• Benchmarking é uma arte obscura de enganar a si mesmo com números extremamente precisos