Lançamento do DiceDB

• DiceDB é um banco de dados em memória (in-memory) de alto desempenho, reativo e de código aberto
• É usado principalmente como cache e oferece atualizações de dados em tempo real por meio de assinatura de consultas (query subscription)
• É otimizado para hardware moderno, oferecendo alta taxa de transferência e baixa latência
• Fornece uma interface fácil de usar e familiar, além de ser open source
• Benchmark de desempenho
  • Comparação de taxa de transferência e latência de GET/SET com outros bancos de dados em memória em uma máquina Hetzner CCX23 (4 vCPU, 16GB RAM)
  • Taxa de transferência (ops/sec): DiceDB 15655, Redis 12267
  • GET p50(ms): DiceDB 0.227327, Redis 0.270335
  • GET p90(ms): DiceDB 0.337919, Redis 0.329727
  • SET p50(ms): DiceDB 0.230399, Redis 0.272383
  • SET p90(ms): DiceDB 0.339967, Redis 0.331775

[GN⁺]

Comentários no Hacker News

• Este código tem muitos bugs

  • Por exemplo, a função ExpandID não bloqueia o mutex global do pacote ao ler de cycleMap
  • A função NextID bloqueia o mutex global do pacote ao escrever em cycleMap
  • As escritas são sincronizadas entre si, mas não com as leituras, então há possibilidade de condição de corrida em chamadas simultâneas de ExpandID e NextID
  • Tudo bem como projeto de hobby, mas está longe de um sistema pronto para produção

• Tenho algumas perguntas sobre o design ao olhar o codebase do DiceDB

  • Quero entender o objetivo e a lógica de design deste projeto
  • O armazenamento principal em memória parece ser um mapa padrão de Go com lock
  • Fico na dúvida se isso é uma escolha temporária para desenvolvimento iterativo ou se existe um plano de longo prazo para uma estrutura de dados mais otimizada
  • O mecanismo reativo do DiceDB, especialmente a reexecução do comando de observação inteiro, é interessante
  • A função Eval parece executar comandos do lado do cliente, o que parece lançar a base para comandos de observação mais complexos
  • Fico curioso sobre qual é a principal motivação para reexecutar o comando inteiro
  • Como a reexecução pode ser computacionalmente cara, fico curioso sobre como os gargalos de desempenho são resolvidos
  • Fico curioso sobre como essa abordagem de "reexecução" se compara com outros métodos em termos de escalabilidade e consistência
  • Fico curioso se há planos para suportar comandos de observação mais complexos além de GET.WATCH
  • Fico curioso sobre os trade-offs dessa escolha de design e se ela está alinhada com os objetivos do projeto

• Fico curioso se há alguma frase que explique o que essa tecnologia realmente é

• É engraçado usar uma ferramenta do acaso como nome de uma tecnologia de armazenamento de dados

• DiceDB parece nome de banco de dados de piada que retorna resultados aleatórios

• Os resultados de benchmark em 4vCPU e num_clients=4 não são muito diferentes

  • A reatividade parece promissora, mas a utilidade prática como cache parece baixa
  • Por exemplo, se a máquina cair enquanto o cliente estiver inscrito, fico curioso sobre o que acontece com a reatividade

• Comparação de desempenho entre DiceDB e Redis

  • O throughput do DiceDB é 15655 ops por segundo, e o do Redis é 12267 ops
  • Comparação dos tempos de resposta de GET p50 e p90, SET p50 e p90

• Não entendo gastar 20ms em uma requisição GET

  • Não tenho muita experiência com implementações open source existentes, mas no meu emprego anterior os tempos de resposta em memória eram de dezenas a centenas de microssegundos
  • Eu esperaria tempos melhores usando io_uring
  • Ler de NVMe e fazer recuperação em 6 nós pode levar dezenas de milissegundos
  • Não entendo como esses números aparecem em um banco de dados em RAM de nó único

• Fico curioso se alguém tem experiência com armazenamento open source de chave-valor de baixa latência e alto throughput

  • Fico curioso se podem recomendar alguma implementação específica

• Gostaria de saber sobre a semântica de entrega do PubSub

  • Fico curioso se é best effort/no máximo uma vez ou se há tentativas de reenvio
  • Fico curioso sobre em quais cenários uma mensagem pode ser entregue ou falhar

• 15655 ops por segundo em uma máquina Hetzner CCX23 é lento para um banco de dados em memória

  • Não dá para culpar a latência de rede
  • supermassivedb.com é escrito em Go e entrega muito mais desempenho
  • É preciso investigar os gargalos do Dice

• Muito mais lento que o Nubmq