.NET BR 🇧🇷

07 May 2025 15:31

Tem um fork do antigo Redis on Windows feito pela MS Open Tech aqui | https://github.com/ServiceStack/redis-windows

.NET BR 🇧🇷

07 May 2025 15:30

Em 2021 a microsoft começou o Garnet um substituito drop-in replacement para o redis, feito em .NET

mas lá em 2014 a mesma MSOpentch havia feito um fork do redis para rodar no windows.

.NET BR 🇧🇷

07 May 2025 15:08

Recomendam algum conteúdo sobre padrões e boas práticas com Redis/Caching em geral?

.NET BR 🇧🇷

07 May 2025 14:55

desses primeiros só o slack não é verificado (não dá para saber se é real)

.NET BR 🇧🇷

07 May 2025 14:51

Isso está mais parecendo uma questão de design de cache mal planejado. Redis não é ideal para armazenar milhões de chaves soltas se você não controlar TTL (Time To Live), agrupamento e acesso, se um dado for raramente acessado, talvez nem precise estar no cache.

.NET BR 🇧🇷

07 May 2025 14:42

Consultas simples, porem muitas chaves. Para serviços de pouco acesso, funciona, mas quem usa cache para poucos acessos?

.NET BR 🇧🇷

07 May 2025 14:40

Aqueles que fracassaram com microsserviços, sequer cogitam que o erro tenha sido deles próprios. Sequer cogitam que o erro vem da falta de profundidade.

.NET BR 🇧🇷

07 May 2025 14:38

Já vi isso acontecer com SOA, com pipelines de CI/CD, com GIT e versionamento em geral, com rabbitmq, redis, kong, a lista é longa...

.NET BR 🇧🇷

07 May 2025 14:35

Exatamente por que não tem condição algo que foi feito para ser extremamente rápido rodando exclusivamente em memória que é utilizado para fazer armazenamento temporário (cache) ser mais lento que um banco relacional "pesado" kkk

.NET BR 🇧🇷

07 May 2025 14:25

Por experiência própria posso atestar uso equivocado em muitos casos.

Todos que vi capotando.

Desde fork utilizado no windows.

mas os principais motivos para lentidão sempre foram:
- Uso equivocado da persistência
- Tempo de vida do cache
- Mal dimensionamento de infra
- uso de redis gerenciado
- configuração de rede errada
- consumo desnecessário

são os alguns dos principais erros e motivos que levam as pessoas a terem experiências ruins.

Uso redis desde 2013, e nunca vi um ambiente otimizado ter problemas. NUNCA. E estamos falando de players grandes.

.NET BR 🇧🇷

07 May 2025 14:06

Tiramos o redis justamente pelo fato de que, chegou um ponto, que valia mais buscar no banco do que esperar o retorno do redis

.NET BR 🇧🇷

07 May 2025 13:58

Ate GPT sabe que usar PostgreSQL como solução de Cache é uma péssima escolha pedir pra ele criar uma analogia que mais se aproxima disso: "PostgreSQL como cache é como usar uma geladeira para manter pipoca quente." 😅

.NET BR 🇧🇷

07 May 2025 13:38

em tempos, que a galera tem preguiça de ler e interpretar, concordo que esse tipo de postagem se torna perigosa, induzindo muita gente a oerro

.NET BR 🇧🇷

07 May 2025 13:34

Entendo o que você quer dizer Luiz, mas na minha colocação e acredito que na do colega acima aí, o ponto é que o título é um puta bait, e que ele mostrou que uma ferrari pode carregar um saco de cimento. Agora, se você deveria fazer isso? Bom, todo mundo vai achar loucura, mas talvez, veja bem TALVEZ, por n motivos em algum momento seja a única forma de se fazer isso. e aí?

.NET BR 🇧🇷

07 May 2025 13:30

O problema é consumir o banco...
O BANCO ...
O BANCO...
🔤 🔤🔤🔤🔤🔤🔤🔤🔤

.NET BR 🇧🇷

07 May 2025 15:30

O que eu vejo também principalmente no .net é problema do lado da implementação. Não entender como multiplexing funciona, como o Redis funciona

.NET BR 🇧🇷

07 May 2025 15:27

há alguns anos, locadora de veículos (a maior) , um amigo era responsável técnico, mas não tinha contato com redis, contratou na cloud "que era friendly" e se lascou. Zero otimização, e para pegar um cluster decente, tinha de deixar um rim por mês.

.NET BR 🇧🇷

07 May 2025 15:05

Cara normal o problema de usar cache distribuído é o mal uso, uma falta de design, definição padrões. Na empresa hoje com 4 instâncias temos um tps de 400k, mas tivemos problemas no passado justamente por não ter feito da forma correta.

.NET BR 🇧🇷

07 May 2025 14:54

Ifood, niantic,

.NET BR 🇧🇷

07 May 2025 14:48

Sendo bem pragmático e evitando pré-conceitos:

O MUNDO usa redis para volume e escala.

.NET BR 🇧🇷

07 May 2025 14:41

muito mais de 90% das discussões técnicas que tive sobre microsserviços não passaram da discussão de banco segregado.

As pessoas não entendem o básico!

.NET BR 🇧🇷

07 May 2025 14:39

Infelizmente não escutaram o que falávamos, mas Microsserviço a gente tentou evitar esse fenômeno, mas já era...

o tema já está marcado !!!!

.NET BR 🇧🇷

07 May 2025 14:37

Já ouvi que "rabbitmq não persiste mensagem (que tudo fica em memória)".

já ouvi que "se você colocar 2 consumidores na mesma fila só 1 recebe mensagens".

que não é resiliente... enfim...

já ouvi abobrinha pra xuxu porque no final do dia.

É isso que acontece no mercado.

A ferramenta é culpada, mas pior, os envolvidos naquilo, aqueles que participavam ou estavam perto carregam esse ranço para a carreira.

.NET BR 🇧🇷

07 May 2025 14:27

O problema do nosso mercado é que algumas coisas parecem intuitivas o suficiente para as pessoas não estudarem. Isso acontece com RabbitMQ tb. Já ouvi cada atrocidade....

.NET BR 🇧🇷

07 May 2025 14:14

Milhões de chaves mal distribuídas (sem organização por namespace, por exemplo), Uso excessivo de comandos pesados, Persistência ativada pode deixar lento mesmo, ai tem que ver aonde esta os gargalos porque o Redis também é escalonável.

.NET BR 🇧🇷

07 May 2025 14:04

Como experiencia propria, o redis é um cache depende.

Depende da quantidade de registros. Se tiver muitas chaves, fica bem, bem lento

.NET BR 🇧🇷

07 May 2025 13:43

Com as discussões sobre Cache no PostgreSQL, Filas no PostgreSQL, Arquivos no PostgreSQL, BSON, JSON e XML no PostgreSQL, depois do PostgreSQL full stack, me lembrei de uma época em que a única solução disponível era o banco de dados relacional.

Aliás, devemos também criar uma tabelinha de logs no PostgreSQL e ignorar OpenTelemetry?

Poderíamos evitar o Elastic, talvez.

Sim, cultivo ranço e desprezo sobre essa ideia.

No passado, lá em meados de 2002, era assim. Usávamos o banco para TUDO, de um lado porque não existiam outras soluções.

De outro, porque precisávamos justificar o investimento e bancos proprietários que custavam o preço de uma mansão.

Mas aprendemos com o tempo a delegar e resolver profissionalmente cada um dos problemas.

Isso nos permitiu evoluir, percorrendo mais níveis de maturidade, na medida em que não precisávamos construir e evoluir os mecanismos na mão.

É fácil criar uma fila, mas leva uma vida para criar um rabbitmq ou similar.

Por isso, o olhar minimalista desatento é um risco. É quando o GoHorse se traveste de Ágil que temos as "alucinações humanas".

Vale a reflexão.

Abaixo o texto onde descrevo essa evolução.

𝗢𝘃𝗲𝗿𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴, 𝗕𝗗𝗨𝗙, 𝗖𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝗱𝗮𝗱𝗲 𝗔𝗰𝗶𝗱𝗲𝗻𝘁𝗮𝗹? 𝗣𝗼𝗿 𝗾𝘂𝗲 𝗲𝘀𝘁𝗮𝗺𝗼𝘀 𝘂𝘀𝗮𝗻𝗱𝗼 𝘁𝗮𝗻𝘁𝗮𝘀 𝗳𝗲𝗿𝗿𝗮𝗺𝗲𝗻𝘁𝗮𝘀, 𝘁𝗲𝗰𝗻𝗼𝗹𝗼𝗴𝗶𝗮𝘀 𝗲𝘁𝗰?

https://share.gago.io/YBNJ

.NET BR 🇧🇷

07 May 2025 13:36

Como disse anttes sobre esses baits, odeio isso, e mais ainda se o bait continua no text/vídeo, pq daí sabemos que tem muitas pessoas que não entendem que é bait e levam isso como verdade

.NET BR 🇧🇷

07 May 2025 13:31

é como usar uma Ferrari para carregar saco de cimento.

.NET BR 🇧🇷

07 May 2025 13:30

mas o problema não é lentidão.