Redka - Redis reimplementado com SQLite

• O Redka tem como objetivo reimplementar as vantagens do Redis com SQLite, mantendo compatibilidade com a API do Redis
• Principais características:
  • Os dados não precisam caber no tamanho da RAM
  • Suporte a transações ACID
  • Consulta de dados via views SQL e recursos de relatórios aprimorados
  • Suporte tanto a servidor in-process (API Go) quanto standalone (RESP)
  • Suporte a comandos e protocolo compatíveis com Redis
• Atualmente está em desenvolvimento; para status de suporte e roadmap, consulte a documentação abaixo

Comandos suportados

• O objetivo do Redka é oferecer suporte aos 5 tipos de dados principais do Redis: String, List, Set, Hash e Sorted Set
• String, Hash, gerenciamento de chaves e comandos de transação já são suportados, enquanto List, Set e Sorted Set ainda estão em desenvolvimento
• Para a lista detalhada de comandos, consulte o texto original

Como instalar

Servidor standalone

• Baixe o arquivo binário correspondente ao seu sistema operacional na página de Releases e execute-o
• Se for usar Docker, baixe a imagem com docker pull nalgeon/redka

Módulo Go

• Instale o módulo com go get github.com/nalgeon/redka
• Use github.com/mattn/go-sqlite3 ou modernc.org/sqlite como driver SQLite

Como usar

Servidor standalone

• Execute o binário baixado no formato redka [-h host] [-p port] [db-path]
  • Os valores padrão são host localhost, porta 6379 e nenhum caminho de DB (em memória)
• Ao usar Docker, execute com o comando docker run. Para opções detalhadas, consulte o texto original
• Após iniciar o servidor, é possível conectar com clientes compatíveis com Redis, como redis-cli, redis-py e go-redis

Servidor in-process

• Crie um objeto de banco de dados com a função redka.Open(). É obrigatório importar o driver
• Execute vários comandos chamando os métodos do objeto redka.DB
• Processe transações com os métodos View (somente leitura) e Update (com escrita)

Persistência

• O Redka armazena os dados no banco SQLite usando as tabelas rkey, rstring e rhash
• É possível consultar os dados com SQL por meio de views para cada tipo de dado (vstring, vhash etc.)

Desempenho

• Comparação de desempenho entre Redis e Redka usando a ferramenta redis-benchmark
  • O Redka é cerca de 6 vezes mais lento em SET e 2 vezes mais lento em GET
  • Ainda assim, apresenta desempenho na faixa de 23K writes/s e 57K reads/s
• Pode haver perda de desempenho ao executar em contêineres

Roadmap

• Na versão 1.0, a implementação deve focar principalmente nos recursos centrais da era do Redis 2.x
  • String, Hash, gerenciamento de chaves e suporte a transações já concluídos
  • Sorted Set em desenvolvimento
  • List e Set planejados
• Em versões futuras, estão previstos tipos de dados como Stream, HyperLogLog e Geo, além de funcionalidade Pub/Sub
• Não há planos para implementar scripting em Lua, autenticação/ACL, múltiplos DBs, Watch/Unwatch etc.
• Também não há intenção de implementar recursos de cluster e Sentinel

Opinião do GN⁺

• A abordagem do Redka é interessante por oferecer persistência mantendo ampla compatibilidade com Redis. O suporte a transações ACID também parece ser um ponto positivo.
• Em desempenho, ele não alcança o Redis, mas, quando a persistência é necessária, parece uma alternativa bastante considerável.
• Como ainda está em estágio inicial de desenvolvimento, a estabilidade precisa ser observada com mais cautela, e o fato de várias funcionalidades estarem fora do roadmap é algo a considerar numa adoção real.
• Para uso puramente in-memory, dificilmente superará o Redis, mas pode ser útil como uma camada de persistência baseada em SQLite.
• Hoje há uma demanda crescente por stacks leves em ambientes de edge computing, e esse pode ser um campo em que o Redka seja usado no lugar do Redis.

[yangeok]

Parece que vai ser útil quando for preciso acoplar o Redis ao scheduler haha

[GN⁺]

Comentários no Hacker News

• Há uma reflexão sobre até que ponto seguir o modelo sem concorrência do Redis, em que "tudo é serializado em uma única thread"
• É possível obter melhor desempenho com SQLite usando a biblioteca de baixo nível, ativando WAL, usando uma conexão por goroutine de leitura e enviando lotes de escrita por canais/filas com buffer para uma thread dedicada de escrita
• Isso permite até desativar o mutex embutido por conexão do SQLite, mantendo a segurança de thread, já que cada conexão é usada por apenas uma thread por vez
• Usar buffers grandes no estilo arena, como ao copiar para um buffer os bytes de parâmetros vindos de requisições de rede/sockets ou ao copiar diretamente do SQLite para o socket, pode economizar muito tempo ao reduzir alocações e repasses de strings individuais
• São dicas vindas da experiência de tentar extrair do Go o máximo de throughput de escrita com SQLite
• Gosto tanto de Redis quanto de SQLite, então decidi combinar os dois. SQLite é especializado em muitas consultas pequenas, então parece uma boa combinação, já que um engine relacional chegou o mais perto possível do Redis
• Estou esperando alguém substituir a máquina de estados do TigerBeetle para implementar a API do Redis
• Seria bom ter uma alternativa ao Redis em que não fosse necessário pensar se o conjunto de dados cabe na memória
• Toda a proposta de valor do Redis é operar na memória e oferecer desempenho de memória. Se for para ir ao disco, quase não há motivo para usar Redis
• Quando se adiciona I/O de rede, grande parte do desempenho fantástico do Redis desaparece. Usar um serviço Redis hospedado como SaaS causa uma grande perda de desempenho. Se fosse mais fácil executar em seu próprio cluster um armazenamento chave/valor compatível com Redis, isso seria uma vantagem
• Fico curioso se isto ou o Garnet suporta mais comandos do Redis. Estou tentando embutir no programa um subconjunto de compatibilidade com Redis para fins de depuração local, com uma API intermediária para proteger contra comandos Redis não suportados
• Quando o Foursquare tornou o MongoDB famoso, alguém publicou uma PoC de um banco NoSQL implementado sobre MySQL, mas isso não virou moda. Ainda assim, isso faz pensar em quanto desempenho sacrificamos para não ter de reinventar SQL sempre que precisamos de um banco de dados. Gosto de experimentos como este, e às vezes eles levam a novos projetos
• Uso o Redis como camada de cache na frente do banco de dados. Não entendo esse conceito
• Porém, você está usando SetMaxConnections(1), mas no modo WAL (que está em uso) o SQLite permite escritas que não bloqueiam leituras, então pode haver vantagem em permitir concorrência de leitura