Respostas:
Redis e MongoDB podem ser usados juntos com bons resultados. Uma empresa conhecida por executar MongoDB e Redis (junto com MySQL e Sphinx) é a Craiglist. Veja esta apresentação de Jeremy Zawodny.
O MongoDB é interessante para dados persistentes, orientados a documentos e indexados de várias maneiras. O Redis é mais interessante para dados voláteis ou dados semi-persistentes sensíveis à latência.
Aqui estão alguns exemplos de uso concreto do Redis em cima do MongoDB.
O MongoDB pré-2.2 ainda não tem um mecanismo de expiração. Coleções limitadas não podem realmente ser usadas para implementar um TTL real. O Redis tem um mecanismo de expiração baseado em TTL, tornando conveniente o armazenamento de dados voláteis. Por exemplo, as sessões do usuário são normalmente armazenadas no Redis, enquanto os dados do usuário são armazenados e indexados no MongoDB. Observe que o MongoDB 2.2 introduziu um mecanismo de expiração de baixa precisão no nível de coleção (para ser usado para limpar dados, por exemplo).
O Redis fornece um tipo de dados de conjunto conveniente e suas operações associadas (união, interseção, diferença em conjuntos múltiplos, etc ...). É muito fácil implementar uma pesquisa facetada básica ou mecanismo de marcação em cima desse recurso, que é uma adição interessante aos recursos de indexação mais tradicionais do MongoDB.
O Redis oferece suporte a operações pop de bloqueio eficientes em listas. Isso pode ser usado para implementar um sistema de enfileiramento distribuído ad-hoc. É mais flexível do que os cursores disponíveis IMO do MongoDB, pois um aplicativo de back-end pode escutar várias filas com um tempo limite, transferir itens para outra fila atomicamente, etc ... Se o aplicativo requer algum enfileiramento, faz sentido armazenar a fila no Redis e manter os dados funcionais persistentes no MongoDB.
O Redis também oferece um mecanismo de publicação / assinatura. Em um aplicativo distribuído, um sistema de propagação de eventos pode ser útil. Este é novamente um excelente caso de uso para Redis, enquanto os dados persistentes são mantidos no MongoDB.
Como é muito mais fácil projetar um modelo de dados com MongoDB do que com Redis (Redis é mais de baixo nível), é interessante se beneficiar da flexibilidade do MongoDB para dados persistentes principais e dos recursos extras fornecidos pelo Redis (baixa latência , expiração de item, filas, pub / sub, blocos atômicos, etc ...). Na verdade, é uma boa combinação.
Observe que você nunca deve executar um servidor Redis e MongoDB na mesma máquina. A memória do MongoDB foi projetada para ser trocada, o Redis não. Se o MongoDB acionar alguma atividade de troca, o desempenho do Redis será catastrófico. Eles devem ser isolados em nós diferentes.
Obviamente, existem muito mais diferenças do que isso, mas para uma visão geral extremamente elevada:
Para casos de uso:
Tecnicamente:
Há alguma sobreposição, mas é extremamente comum usar os dois. Aqui está o porquê:
Redis pode ser usado como um substituto para um armazenamento de dados tradicional, mas é mais frequentemente usado com outro armazenamento de dados "longo" normal, como Mongo, Postgresql, MySQL, etc.
O Redis funciona perfeitamente com o MongoDB como servidor de cache. Aqui está o que acontece.
Sempre que o mangusto emitir uma consulta de cache, ela irá primeiro para o servidor de cache.
O servidor de cache verificará se aquela consulta exata já foi emitida antes.
Se não tiver, o servidor de cache assumirá a consulta, envie-a para mongodb e o Mongo executará a consulta.
Em seguida, pegaremos o resultado dessa consulta, ele então voltará para o servidor de cache, o servidor de cache armazenará o resultado da consulta em si mesmo.
Ele dirá que sempre que eu executar essa consulta, recebo essa resposta e, portanto, manterá um registro entre as consultas que são emitidas e as respostas que retornam dessas consultas.
O servidor de cache pegará a resposta e a enviará de volta para o mangusto, o mangusto a dará para expressar e ela eventualmente terminará dentro do aplicativo.
Sempre que a mesma consulta exata for emitida novamente, o mongoose enviará a mesma consulta para o servidor de cache, mas se o servidor de cache perceber que essa consulta foi emitida antes, ele não enviará a consulta para mongodb, em vez disso, levará a resposta para a consulta obtida da última vez e imediatamente enviada de volta para o mangusto. Não há índices aqui, nenhuma varredura completa da tabela, nada.
Estamos fazendo uma pesquisa simples para dizer se esta consulta foi executada? Sim? Ok, aceite o pedido e envie-o de volta imediatamente e não envie nada para o mongo.
Temos o servidor mongoose, o servidor de cache (Redis) e o Mongodb.
No servidor de cache pode haver um armazenamento de dados com o tipo de valor de chave de armazenamento de dados onde todas as chaves são algum tipo de consulta emitida antes e o valor é o resultado dessa consulta.
Então, talvez estejamos procurando um monte de postagens de blog de _id.
Então, talvez as chaves aqui sejam o _id dos registros que procuramos antes.
Então, vamos imaginar que o mongoose emita uma nova consulta onde tenta encontrar uma postagem do blog com _id de 123, a consulta flui para o servidor de cache, o servidor de cache verificará se há um resultado para alguma consulta que estava procurando por _id de 123.
Se não existir no servidor de cache, esta consulta é obtida e enviada para a instância mongodb. O Mongodb executará a consulta, obterá uma resposta e a enviará de volta.
Esse resultado é enviado de volta para o servidor de cache, que pega esse resultado e o envia imediatamente de volta para o mongoose, para que obtenhamos uma resposta o mais rápido possível.
Em seguida, o servidor de cache também pegará a consulta emitida e a adicionará à sua coleção de consultas que foram emitidas e pegará o resultado da consulta e armazenará diretamente na consulta.
Então podemos imaginar que no futuro emitiremos a mesma consulta novamente, ela atinge o servidor de cache, olha todas as chaves que possui e diz oh, eu já encontrei aquela postagem do blog, ela não chega ao mongo, apenas leva o resultado da consulta e o envia diretamente para o mangusto.
Não estamos fazendo uma lógica de consulta complexa, sem índices, nada disso. É o mais rápido possível. É uma pesquisa de valor de chave simples.
Esta é uma visão geral de como o servidor de cache (Redis) funciona com o MongoDB.
Agora, existem outras preocupações. Estamos armazenando dados em cache para sempre? Como atualizamos os registros?
Não queremos sempre armazenar dados no cache e ler o cache.
O servidor de cache não é usado para nenhuma ação de gravação. A camada de cache é usada apenas para leitura de dados. Se algum dia gravarmos dados, a gravação sempre irá para a instância mongodb e precisamos garantir que, sempre que gravarmos dados, limpemos todos os dados armazenados no servidor de cache que estão relacionados ao registro que acabamos de atualizar no Mongo.