Quão significativa é a diferença de desempenho entre o armazenamento na memória e o armazenamento do banco de dados [fechado]

Question

Fechado.Essa questão precisa ser mais focado.No momento não está aceitando respostas.

---

Quer melhorar esta questão? Atualize a pergunta para que ela se concentre em apenas um problema, editando esta postagem.

Fechado 5 anos atrás.

Estou criando um aplicativo de chat no Signalr.Atualmente possui alguma funcionalidade de armazenamento em um banco de dados para armazenamento permanente de mensagens.Quero implementar listas de usuários e estou relendo este artigo:

http://www.asp.net/signalr/overview/signalr-20/hubs-api/mapping-users-to-connections#inmemory

Quão significativa é essa diferença entre o armazenamento na memória?É provável que haja mais de um segundo de diferença entre, digamos, 1.000 usuários e 10.000 usuários trocando mensagens entre si a uma taxa normal de, digamos, 1 msg por segundo (eles consumiram muito açúcar)?E quão útil é isso?Quaisquer referências a testes anteriores de desempenho seriam extremamente apreciadas.

Em segundo lugar, posso estar fazendo isso da maneira errada, mas se eu quiser armazenar uma lista de usuários e houver várias salas de bate-papo, presumo que precisarei de um dicionário separado por sala.E se sim, isso é viável, já que quero que os usuários também possam gerar suas próprias salas.Só não vejo como a memória pode ser alcançada dessa maneira.

Obrigado

Answer 1

Detesto fornecer um único link para uma resposta, mas esta sala de bate-papo OSS totalmente funcional https://jabbr.net aborda tudo o que o preocupa.

Fonte: https://github.com/jabbr/jabbr

Para comentar sobre sua principal preocupação na memória versus banco de dados:O banco de dados adiciona a capacidade de persistir dados ou até mesmo expandir seu aplicativo, MAS tem MUITO menos desempenho do que na memória.Agora, não me interpretem mal, mesmo que tenha MUITO menos desempenho, isso não significa que levará segundos para enviar mensagens, dependendo do seu aplicativo...É tudo uma questão de compensações.

Quanto à aplicação de uma arquitetura orientada a banco de dados para 1.000 versus 10.000 usuários, tudo depende de como você a implementa.Por exemplo, o provedor de expansão REDIS executa tudo na memória, mas depois persiste no disco em um intervalo.Obviamente, isso é extremamente rápido, mas permite "alguma" perda de dados.

Answer 2

Isso não está diretamente relacionado à sua pergunta original.

Acho que você não pode salvá-los no armazenamento na memória. O problema é que se o Pool de Aplicativos for reciclado, todas as mensagens armazenadas na memória desaparecerão.

Você não pode prever quando o App Pool será reciclado (no total, você pode definir manualmente um horário específico para reciclagem).Isso pode acontecer em alguns dias ou em algumas horas.

Idealmente, você deseja armazenar em um local persistente como Base de dados.Se você se preocupa com o desempenho do salvamento no banco de dados, você pode assíncrono a tarefa de salvar o banco de dados.

Answer 3

Confira esta comparação:

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

Redis (na memória) supera o MySQL (DB clássico), obviamente, seus campos de aplicação são fortemente diferentes, por isso não podemos dizer que, em geral, o Redis é melhor que o MySQL.Cada projeto de software é o seu próprio mundo e muitas soluções diferentes podem ser aplicadas.Em algumas situações, o Redis e o MySQL são usados ​​juntos para diferentes partes de uma plataforma (por exemplo,Comércio eletrônico Magento)

Cabe a você avaliar se precisa de uma solução na memória ou de um banco de dados padrão.Eu acho que uma taxa de transferência de 1 inserção/segundo pode ser alcançada facilmente através do MySQL, mas isso é apenas uma opinião.Eu sugiro que você escreva uma implementação do seu produto que seja "redisciente do Redis":comece a usar o MySQL, mas use-o através de uma camada de abstração que se adapta tanto ao MySQL quanto ao Redis (não sei se essa camada está disponível em código aberto, mas você pode lançar o seu próprio ...)