Architettura per cache Redis e Mongo per persistenza

Question

Il programma di installazione:
Immagina un servizio "twitter like" in cui un utente invia un post, che viene letto da molti (centinaia, migliaia o più) utenti.

La mia domanda riguarda il modo migliore di architettare il database cache & per ottimizzare l'accesso rapido a & molte letture, ma mantenere comunque i dati storici in modo che gli utenti possano (se lo desiderano) vedere i post precedenti. Il presupposto qui è che il 90% degli utenti sarebbe interessato solo alle nuove cose, e che le vecchie cose saranno accessibili occasionalmente. L'altro presupposto qui è che vogliamo ottimizzare per il 90%, e va bene se il 10% più vecchio richiede un po 'più tempo per essere recuperato.

Con questo in mente, la mia ricerca sembra indicare con forza la direzione di utilizzare una cache per il 90% e quindi anche di archiviare i post in un altro sistema persistente a più lungo termine. Quindi la mia idea è di usare Redis per la cache. Il vantaggio è che Redis è molto veloce, e ha anche costruito in pub/sub che sarebbe perfetto per pubblicare post su molte persone. E poi stavo considerando di utilizzare MongoDB come un archivio di dati più permanente per archiviare gli stessi post a cui si accederà quando scappano da Redis.

Domande:
1. Questa architettura regge l'acqua? C'è un modo migliore per farlo?
2. Per quanto riguarda il meccanismo di memorizzazione dei post in entrambi i Redis & MongoDB, stavo pensando di fare l'app per fare 2 scritture: 1 ° - scrivere su Redis, quindi è immediatamente disponibile per gli abbonati. 2 ° - dopo aver salvato con successo su Redis, scrivere immediatamente a MongoDB. È questo il modo migliore per farlo? Dovrei invece avere Redis a spingere i post scaduti su MongoDB stesso? Ci ho pensato, ma non sono riuscito a trovare molte informazioni su come spingere direttamente MongoDB da Redis.

Answer 1

In realtà è ragionevole associare Redis e MongoDB: sono bravi giocatori di squadra. Troverete maggiori informazioni qui:

MongoDB with redis

Un punto critico è il livello di resilienza è necessario. Sia Redis che MongoDB possono essere configurati per ottenere un livello accettabile di resilienza e queste considerazioni dovrebbero essere discusse in fase di progettazione. Inoltre, può mettere un vincolo sulle opzioni di implementazione: se si desidera la replica master/slave per Redis e MongoDB sono necessari almeno 4 box (Redis e MongoDB non dovrebbero essere distribuiti sulla stessa macchina).

Ora, potrebbe essere un po 'più semplice mantenere Redis per l'accodamento, pub/sub, ecc. E memorizzare i dati utente solo in MongoDB. È logico che non sia necessario progettare percorsi di accesso ai dati simili (la parte difficile di questo lavoro) per due negozi con diversi paradigmi. Inoltre, MongoDB ha scalabilità orizzontale incorporata (set di repliche, auto-sharding, ecc ...) mentre Redis ha solo scalabilità fai-da-te.

Per quanto riguarda la seconda domanda, scrivere su entrambi i negozi sarebbe il modo più semplice per farlo. Non esiste alcuna funzione integrata per replicare l'attività di Redis su MongoDB. Progettare un demone che ascolti una coda Redis (dove l'attività dovrebbe essere pubblicata) e scrivere su MongoDB non è poi così difficile.