Será que você precisa de Redis? Quando o PostgreSQL oferece filas, locks e pub/sub (2021)

• Caso de uso 1: fila de tarefas

  • O Redis é frequentemente usado em serviços web para coordenar tarefas em segundo plano.
  • Desde a versão 9.5 do PostgreSQL, é possível implementar filas de tarefas com a opção SKIP LOCKED.
  • Essa opção permite selecionar tarefas sem esperar por locks, garantindo que vários workers não processem a mesma tarefa ao mesmo tempo.

• Caso de uso 2: locks de aplicação

  • O Redis é frequentemente usado para locks distribuídos.
  • É possível implementar a mesma funcionalidade usando advisory locks do PostgreSQL.
  • Advisory locks permitem aproveitar o mecanismo interno de locks do PostgreSQL para finalidades definidas pela aplicação.

• Caso de uso 3: Pub/Sub

  • O Redis é usado para enviar eventos a clientes ativos.
  • Desde a versão 9 do PostgreSQL, as instruções LISTEN e NOTIFY fornecem funcionalidade de Pub/Sub.
  • Clientes PostgreSQL podem assinar canais de mensagens específicos, e quando outro cliente envia uma mensagem para esse canal, todos os assinantes recebem a notificação.

• Aproveitando o PostgreSQL ao máximo

  • O Redis é usado para fins diferentes do PostgreSQL e se destaca em cache de dados com TTL e armazenamento temporário de dados.
  • O PostgreSQL oferece mais do que um banco de dados SQL, e há a possibilidade de substituir pelo PostgreSQL tarefas normalmente feitas com Redis.
  • Isso pode ser uma escolha valiosa para reduzir a complexidade de usar vários serviços de dados e cortar custos operacionais.

[GN⁺]

Opiniões do Hacker News

• O Redis oferece tempos de resposta muito rápidos quando roda na mesma máquina que a aplicação. Isso permite coisas diferentes do Postgres

  • Um armazenamento de chave-valor em memória é adequado para tarefas que exigem as características de desempenho da RAM
  • É óbvio que não se obtém o desempenho da RAM por meio de uma conexão de rede

• O PostgreSQL oferece mais do que um simples banco de dados SQL

  • Se você usa o banco de dados apenas por trás de um ORM, pode acabar perdendo funcionalidades
  • Em vez de adicionar um serviço como o Redis, pode ser melhor aproveitar o banco de dados que já está configurado

• O PGQueuer é uma alternativa mínima que usa PostgreSQL para fornecer fila de tarefas, bloqueios e notificações em tempo real

  • Reduz a necessidade de Redis

• O Postgres é um banco de dados poderoso

  • O Redis tem baixa barreira de entrada, oferece alto desempenho e reduz a carga sobre o banco de dados principal
  • O cache de respostas de API também é possível no Postgres, mas usar Redis é mais simples
  • Usar um sistema separado tem desvantagens, mas no caso do Redis elas não são tão grandes

• A maioria dos projetos só precisa de uma fila de tarefas simples, e é importante simplificar uma stack complexa

  • Existem várias alternativas diferentes com interesses comerciais por trás

• O Postgres tem algumas limitações

  • É possível lidar com KV store, filas, pub/sub, bloqueios etc., mas não de forma simples

• É melhor começar com PostgreSQL e migrar para Redis quando necessário

  • É importante minimizar o número de partes móveis

• Uma grande desvantagem do pub/sub do Postgres é que o tamanho das mensagens é limitado a 8000 bytes

  • Há a opção de armazenar os dados no banco e enviar o ID, mas isso exige trabalho extra

• O cache, uma das aplicações mais importantes do Redis, é mais complexo no Postgres

  • Atualizações no Postgres custam mais do que inserções, e garantias de durabilidade não são importantes para cache

• Ao usar esses recursos no Postgres, atualizações e replicação ficam mais difíceis

  • É possível, mas prefiro focar nos recursos mais amplamente usados do Postgres