Risposte:
Redis e MongoDB possono essere usati insieme con buoni risultati. Una società nota per l'esecuzione di MongoDB e Redis (insieme a MySQL e Sphinx) è Craiglist. Guarda questa presentazione di Jeremy Zawodny.
MongoDB è interessante per i dati persistenti, orientati ai documenti, indicizzati in vari modi. Redis è più interessante per dati volatili o dati semi-persistenti sensibili alla latenza.
Ecco alcuni esempi di utilizzo concreto di Redis su MongoDB.
MongoDB precedente alla 2.2 non ha ancora un meccanismo di scadenza. Le raccolte con limite non possono essere utilizzate per implementare un vero TTL. Redis ha un meccanismo di scadenza basato su TTL, che rende conveniente memorizzare i dati volatili. Ad esempio, le sessioni utente vengono comunemente archiviate in Redis, mentre i dati dell'utente verranno archiviati e indicizzati in MongoDB. Si noti che MongoDB 2.2 ha introdotto un meccanismo di scadenza a bassa precisione a livello di raccolta (da utilizzare, ad esempio, per l'eliminazione dei dati).
Redis fornisce un comodo tipo di dati dell'insieme e le sue operazioni associate (unione, intersezione, differenza su più insiemi, ecc ...). È abbastanza facile implementare una ricerca sfaccettata di base o un motore di tagging sopra questa funzione, che è un'aggiunta interessante alle funzionalità di indicizzazione più tradizionali di MongoDB.
Redis supporta efficienti operazioni di blocco pop sugli elenchi. Può essere utilizzato per implementare un sistema di accodamento distribuito ad hoc. È più flessibile dei cursori personalizzabili MongoDB IMO, poiché un'applicazione backend può ascoltare diverse code con un timeout, trasferire elementi a un'altra coda in modo atomico, ecc ... Se l'applicazione richiede un po 'di coda, ha senso memorizzare la coda in Redis e mantieni i dati funzionali persistenti in MongoDB.
Redis offre anche un meccanismo pub / sub. In un'applicazione distribuita, può essere utile un sistema di propagazione degli eventi. Anche questo è un ottimo caso d'uso per Redis, mentre i dati persistenti sono conservati in MongoDB.
Poiché è molto più semplice progettare un modello di dati con MongoDB che con Redis (Redis è di livello più basso), è interessante trarre vantaggio dalla flessibilità di MongoDB per i dati persistenti principali e dalle funzionalità extra fornite da Redis (bassa latenza , scadenza articolo, code, pub / sub, blocchi atomici, ecc ...). È davvero una buona combinazione.
Nota che non dovresti mai eseguire un server Redis e MongoDB sulla stessa macchina. La memoria MongoDB è progettata per essere sostituita, Redis no. Se MongoDB attiva alcune attività di scambio, le prestazioni di Redis saranno catastrofiche. Dovrebbero essere isolati su diversi nodi.
Ovviamente ci sono molte più differenze di questa, ma per una panoramica estremamente alta:
Per casi d'uso:
Tecnicamente:
C'è qualche sovrapposizione, ma è estremamente comune usarli entrambi. Ecco perché:
Redis può essere utilizzato in sostituzione di un datastore tradizionale, ma è più spesso utilizzato con un altro normale archivio dati "lungo", come Mongo, Postgresql, MySQL, ecc.
Redis funziona in modo eccellente con MongoDB come server di cache. Ecco cosa succede.
Ogni volta che la mangusta invia una query nella cache, passerà prima al server della cache.
Il server cache verificherà se quella query esatta è mai stata eseguita prima.
In caso contrario, il server cache prenderà la query, la invierà a mongodb e Mongo eseguirà la query.
Quindi prenderemo il risultato di quella query, quindi torneremo al server della cache, il server della cache memorizzerà il risultato della query su se stesso.
Dirà che ogni volta che eseguo quella query, ricevo questa risposta e quindi manterrà un record tra le query emesse e le risposte che tornano da quelle query.
Il server cache prenderà la risposta e la rimanderà a mongoose, la mongoose la darà a express e alla fine finirà all'interno dell'applicazione.
Ogni volta che viene emessa di nuovo la stessa esatta query, mongoose invierà la stessa query al server cache, ma se il server cache vede che questa query è stata emessa prima non invierà la query a mongodb, invece prenderà la risposta a la query che ha ricevuto l'ultima volta e la rimanda immediatamente a mongoose. Non ci sono indici qui, nessuna scansione completa della tabella, niente.
Stiamo facendo una semplice ricerca per dire che questa query è stata eseguita? Sì? Ok, accetta la richiesta e rispediscila immediatamente e non inviare nulla a mongo.
Abbiamo il server mongoose, il server cache (Redis) e Mongodb.
Sul server della cache potrebbe esserci un datastore con un tipo di valore chiave dell'archivio dati in cui tutte le chiavi sono un tipo di query emessa prima e il valore è il risultato di tale query.
Quindi forse stiamo cercando un mucchio di post sul blog di _id.
Quindi forse le chiavi qui sono l'_id dei record che abbiamo cercato prima.
Quindi immaginiamo che mongoose emetta una nuova query in cui cerca di trovare un post sul blog con _id di 123, la query fluisce nel server della cache, il server della cache controllerà per vedere se ha un risultato per qualsiasi query che stava cercando un _id di 123.
Se non esiste nel server cache, questa query viene presa e inviata all'istanza mongodb. Mongodb eseguirà la query, riceverà una risposta e la rispedirà.
Questo risultato viene rimandato al server cache che prende il risultato e lo invia immediatamente a mongoose in modo da ottenere una risposta il più rapidamente possibile.
Subito dopo, il server della cache prenderà anche la query emessa e la aggiungerà alla sua raccolta di query che sono state emesse, prenderà il risultato della query e lo memorizzerà direttamente sulla query.
Quindi possiamo immaginare che in futuro emettiamo di nuovo la stessa query, colpisce il server cache, guarda tutte le chiavi che ha e dice oh ho già trovato quel post sul blog, non raggiunge mongo, ci vuole solo il risultato della query e lo invia direttamente a mongoose.
Non stiamo facendo una logica di query complessa, nessun indice, niente del genere. È il più veloce possibile. È una semplice ricerca di valori chiave.
Questa è una panoramica di come funziona il server cache (Redis) con MongoDB.
Ora ci sono altre preoccupazioni. Memorizziamo i dati nella cache per sempre? Come si aggiornano i record?
Non vogliamo sempre archiviare dati nella cache e leggere dalla cache.
Il server cache non viene utilizzato per alcuna azione di scrittura. Il livello della cache viene utilizzato solo per la lettura dei dati. Se mai scriviamo dati, la scrittura passerà sempre all'istanza mongodb e dobbiamo assicurarci che ogni volta che scriviamo dati cancelliamo tutti i dati memorizzati sul server cache che sono correlati al record che abbiamo appena aggiornato in Mongo.