Olá galera, estou desenvolvendo uma aplicação bacana, chamada TreinoSmart ? http://treinosmart.com ela é totalmente Javascript (Node.js + MongoDB) e ao configurá-lo para produção, fui obrigado a configurar um banco de dados para armazenar as Sessions, pois antes estava totalmente In-Memory.
Ai como minha base já é MongoDB acabei configurando a Session para se armazenar em uma tabela do mesmo banco.
Porém vem a dúvida, sobre boa prática, devo configurar um banco de dados separado para armazenar Sessions seja com MongoDB ou Redis ou eu posso deixar do jeito que esta em que no caso apenas criei uma Tabela a parte para Session configurada na mesma base de dados da aplicação?
Nessa sessão vc armazenaria somente o usuário?
Tenho um caso onde minha aplicação compartilha dados de outro servidor (como cliente, permissões, etc), e pretendo usar Redis só pra esse fim. E os dados ‘normais’ da aplicação uso outro banco.
Mas acho que vai de cada caso. Se não for custoso separar, eu iria separar, pra não ‘misturar’ os dados do negócio com os dados de ‘estado’ da app.
j0nny estou apenas armazenando dados de login e permissões do usuario.
No momento ta tudo no mesmo banco de dados, como a aplicação é pequena e não esta no ar ainda pra uso, creio que de inicio não será problema isso, mas tbm penso la na frente em ter um banco de dados dedicado só para sessions.
[quote=caio.ribeiro.pereira]j0nny estou apenas armazenando dados de login e permissões do usuario.
No momento ta tudo no mesmo banco de dados, como a aplicação é pequena e não esta no ar ainda pra uso, creio que de inicio não será problema isso, mas tbm penso la na frente em ter um banco de dados dedicado só para sessions.
Conhece algum PAAS Redis bom e barato pra isso?[/quote]
O mais certo é evoluir sua arquitetura gradativamente, conforme vai precisando.
Pra te falar a verdade, ainda não pesquisei muito sobre o Redis, mas pretendo usar ele ou alguma solução parecida.
No caso minha app vai ser em Rails.
A minha aplicação no começo foi mais para estudar Node.js e MongoDB e agora que a coisa ta ficando séria vou testar se eles darão conta assim que eu finalizar o projeto.
A minha aplicação no começo foi mais para estudar Node.js e MongoDB e agora que a coisa ta ficando séria vou testar se eles darão conta assim que eu finalizar o projeto.[/quote]
Certo!
Quando tiver alguma definição ou a app em produção, volte pra contar os resultados e a solução que optou.
Depois de alguns meses, lembrei desse post e venho a ele apresentar as seguintes conclusões que tive em relação a db dados com db sessions.
Bom como disse no começo, eu fiz com que a tabela de Sessions fosse trabalhada com o mesmo banco de dados do sistema, e isso tem um sério problema que aconteceu comigo, semanas atrás.
O grande vilão é o número de conexões do banco de dados, ou seja, cada novo usuário além de conectar no banco de dados, também utiliza uma outra conexão para trabalhar com Sessions. E isso vai gerar uma queda no sistema quando surgir muitos acessos, visto que cada usuário utiliza 2 conexões ao mesmo tempo.
Com isso, resolvi adicionar o Redis para trabalhar com Sessions e deixei o MongoDB exclusivo para dados e resolveu o problema.
Depois de alguns meses, lembrei desse post e venho a ele apresentar as seguintes conclusões que tive em relação a db dados com db sessions.
Bom como disse no começo, eu fiz com que a tabela de Sessions fosse trabalhada com o mesmo banco de dados do sistema, e isso tem um sério problema que aconteceu comigo, semanas atrás.
O grande vilão é o número de conexões do banco de dados, ou seja, cada novo usuário além de conectar no banco de dados, também utiliza uma outra conexão para trabalhar com Sessions. E isso vai gerar uma queda no sistema quando surgir muitos acessos, visto que cada usuário utiliza 2 conexões ao mesmo tempo.
Com isso, resolvi adicionar o Redis para trabalhar com Sessions e deixei o MongoDB exclusivo para dados e resolveu o problema.[/quote]
Foi o que imaginei, pq dessa forma com os bancos separados, vc pode também utilizar um banco mais rápido, se precisar, para as sessões, e um banco relacional que modele bem os teus modelos, para os dados do sistema.
Tive que aprender com esse erro grave na raça, visto que o sistema caiu em produção por causa disso, mas como estava no ínicio de vida do app, precisei errar e corrigir o quanto antes.