Quello che voglio non è un confronto tra Redis e MongoDB. So che sono diversi; le prestazioni e l'API sono totalmente diverse.

Redis è molto veloce, ma l'API è molto "atomica". MongoDB consumerà più risorse, ma l'API è molto molto facile da usare e ne sono molto contento.

Sono entrambi fantastici e voglio usare Redis nella distribuzione il più possibile, ma è difficile da programmare. Voglio usare MongoDB nello sviluppo il più possibile, ma ha bisogno di una macchina costosa.

Allora, cosa ne pensi dell'uso di entrambi? Quando scegliere Redis? Quando scegliere MongoDB?

Direi che dipende dal tipo di team di sviluppo che sei e dalle esigenze della tua applicazione.

Ad esempio, se si richiedono molte query , ciò significa principalmente che sarebbe più lavoro per gli sviluppatori utilizzare Redis, dove i dati potrebbero essere archiviati in una varietà di strutture di dati specializzate, personalizzate per ciascun tipo di oggetto per maggiore efficienza. In MongoDB le stesse query potrebbero essere più semplici perché la struttura è più coerente tra i tuoi dati. D'altra parte, a Redis, pura velocità della risposta a queste domande è il vantaggio per il lavoro extra di gestione della varietà di strutture con cui i dati potrebbero essere archiviati.

MongoDB offre semplicità, curva di apprendimento molto più breve per gli sviluppatori con esperienza DB e SQL tradizionale. Tuttavia, l'approccio non tradizionale di Redis richiede un maggiore sforzo di apprendimento, ma una maggiore flessibilità.

Per esempio. Un livello di cache può probabilmente essere meglio implementato in Redis. Per ulteriori dati che supportano lo schema, MongoDB è migliore. [Nota: sia MongoDB che Redis sono tecnicamente schematici]

Se me lo chiedi, la mia scelta personale è Redis per la maggior parte dei requisiti.

Infine, spero che tu abbia già visto http://antirez.com/post/MongoDB-and-Redis.html

Ho appena notato che questa domanda è piuttosto vecchia. Tuttavia, ritengo che valga la pena aggiungere i seguenti aspetti:

• Usa MongoDB se non sai ancora come interrogare i tuoi dati.

  MongoDB è adatto per Hackathon, startup o ogni volta che non sai come interrogare i dati che hai inserito. MongoDB non fa alcuna ipotesi sullo schema sottostante. Sebbene MongoDB sia privo di schemi e non relazionale, ciò non significa che non vi sia alcuno schema. Significa semplicemente che il tuo schema deve essere definito nella tua app (ad es. Usando Mongoose). Oltre a ciò, MongoDB è ottimo per la prototipazione o la sperimentazione. Le sue prestazioni non sono eccezionali e non possono essere paragonate a Redis.

• Usa Redis per accelerare l'applicazione esistente.

  Redis può essere facilmente integrato come cache LRU . È molto raro usare Redis come sistema di database autonomo (alcune persone preferiscono riferirsi ad esso come un archivio "valore-chiave"). Siti Web come Craigslist utilizzano Redis accanto al loro database principale . Antirez (sviluppatore di Redis) ha dimostrato utilizzando Lamernews che è davvero possibile utilizzare Redis come sistema di database autonomo.

• Redis non fa alcuna ipotesi sulla base dei tuoi dati.

  Redis fornisce una serie di utili strutture di dati (ad esempio set, hash, elenchi), ma è necessario definire esplicitamente come si desidera archiviare i dati. Per farla breve, Redis e MongoDB possono essere utilizzati per ottenere risultati simili. Redis è semplicemente più veloce, ma non adatto alla prototipazione. Questo è un caso d'uso in cui in genere si preferisce MongoDB. Oltre a ciò, Redis è davvero flessibile. Le strutture dati sottostanti che fornisce sono i mattoni di sistemi DB ad alte prestazioni.

Quando usare Redis?

• caching

  La memorizzazione nella cache con MongoDB semplicemente non ha molto senso. Sarebbe troppo lento.

• Se hai abbastanza tempo per pensare al tuo progetto DB.

  Non puoi semplicemente inserire i tuoi documenti in Redis. Devi pensare al modo in cui vuoi archiviare e organizzare i tuoi dati. Un esempio sono gli hash in Redis. Sono abbastanza diversi dagli oggetti nidificati "tradizionali", il che significa che dovrai ripensare il modo in cui memorizzi i documenti nidificati. Una soluzione sarebbe quella di memorizzare un riferimento all'interno dell'hash in un altro hash (qualcosa come key: [id del secondo hash] ). Un'altra idea sarebbe quella di memorizzarlo come JSON, che sembra controintuitivo alla maggior parte delle persone con un * SQL-background.

• Se hai bisogno di prestazioni davvero elevate.

  Battere le prestazioni fornite da Redis è quasi impossibile. Immagina che il tuo database sia veloce quanto la tua cache. Ecco come ci si sente ad usare Redis come un vero database.

• Se non vi interessa che molto di ridimensionamento.

  Ridimensionare Redis non è così difficile come una volta. Ad esempio, è possibile utilizzare un tipo di server proxy per distribuire i dati tra più istanze Redis. La replica master-slave non è così complicata, ma la distribuzione delle chiavi tra più istanze Redis deve essere eseguita sul sito dell'applicazione (ad es. Utilizzando una funzione hash, Modulo ecc.). Il confronto di MongoDB in confronto è molto più semplice.

Quando usare MongoDB

• Prototipazione, Startup, Hackathon

  MongoDB è perfettamente adatto per la prototipazione rapida. Tuttavia, le prestazioni non sono così buone. Tieni inoltre presente che molto probabilmente dovrai definire una sorta di schema nella tua applicazione.

• Quando è necessario modificare rapidamente lo schema.

  Perché non esiste uno schema! Modificare le tabelle nel tradizionale DBMS relazionale è dolorosamente costoso e lento. MongoDB risolve questo problema non facendo molte ipotesi sui dati sottostanti. Tuttavia, tenta di ottimizzare il più possibile senza richiedere la definizione di uno schema.

TL; DR : utilizzare Redis se le prestazioni sono importanti e si è disposti a dedicare tempo all'ottimizzazione e all'organizzazione dei dati. - Usa MongoDB se hai bisogno di costruire un prototipo senza preoccuparti troppo del tuo DB.

Ulteriori letture:

• Aspetti interessanti da considerare quando si utilizza Redis come archivio dati primario

Redis. Diciamo che hai scritto un sito in php; per qualsiasi motivo, diventa popolare ed è in anticipo sui tempi o ha porno su di esso. Ti rendi conto che questo php è così lento, "Perderò i miei fan perché semplicemente non aspetteranno 10 secondi per una pagina". Ti rendi improvvisamente conto che una pagina web ha un url costante (non cambia mai, whoa), una chiave primaria se vuoi, e poi ricordi che la memoria è veloce mentre il disco è lento e php è ancora più lento. :( Quindi crei un meccanismo di archiviazione usando la memoria e questo URL che chiami una "chiave" mentre il contenuto della pagina web decidi di chiamare il "valore". Questo è tutto ciò che hai - chiave e contenuto. Lo chiami "cache meme". Ti piace Richard Dawkins perché è fantastico. Metti in cache il tuo html come gli scoiattoli memorizzano i loro dadi. Non hai bisogno di riscrivere il tuo codice merda php. Tu sei felice. Poi vedi che altri l'hanno fatto, ma scegli Redis perché l'altro ha immagini confuse di gatti, alcune con zanne.

Mongo. Hai scritto un sito. Diamine, ne hai scritti molti e in qualsiasi lingua. Ti rendi conto che gran parte del tuo tempo è trascorso a scrivere quelle puzzolenti clausole SQL. Non sei un dba, eppure eccoti qui, a scrivere stupide dichiarazioni sql ... non solo una, ma impazzendo ovunque. "seleziona questo, seleziona quello". Ma in particolare ti ricordi la clausola WHERE irritante. Dove il cognome è uguale a "thornton" e il film è uguale a "bad santa". Urgh. Pensi "perché questi dbas non fanno semplicemente il loro lavoro e mi danno delle procedure memorizzate?" Quindi dimentichi alcuni campi minori come middlename e quindi devi eliminare la tabella, esportare tutti i 10 G di big data e crearne un altro con questo nuovo campo e importare i dati - e che va avanti 10 volte nei prossimi 14 giorni mentre continua a ricordare merda come saluto, titolo, più l'aggiunta di una chiave esterna con indirizzi. Quindi pensi che il cognome dovrebbe essere lastName. Quasi un cambio al giorno. Allora dici maledetto. Devo andare avanti e scrivere un sito Web / sistema, non importa questo modello di dati bs. Quindi google, "Odio scrivere SQL, per favore niente SQL, fallo smettere" ma fai apparire 'nosql' e poi leggi alcune cose e dice che scarica semplicemente i dati senza alcun schema. Ricordi il fiasco della scorsa settimana che ha lasciato cadere più tavoli e sorridi. Quindi scegli mongo perché alcuni grandi ragazzi come "airbud" lo usano il sito di noleggio apt. Dolce. Niente più modifiche al modello di dati perché hai un modello che continui a cambiare.

Forse questa risorsa è utile per decidere tra entrambi. Discute anche diversi altri database NoSQL e offre un breve elenco di caratteristiche, insieme a una spiegazione di "cosa lo userei per" per ciascuno di essi.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Domanda difficile a cui rispondere: come con la maggior parte delle soluzioni tecnologiche, dipende davvero dalla tua situazione e poiché non hai descritto il problema che stai cercando di risolvere, come si può proporre una soluzione?

Devi testarli entrambi per vedere quale di essi ha soddisfatto le tue esigenze.

Detto questo, MongoDB non richiede hardware costoso. Come qualsiasi altra soluzione di database, funzionerà meglio con più CPU e memoria ma non è certamente un requisito, specialmente per scopi di sviluppo iniziale.

Redis è un archivio di dati in memoria , che può persistere nel suo stato su disco (per abilitare il ripristino dopo il riavvio). Tuttavia, essere un archivio di dati in memoria significa che la dimensione dell'archivio di dati (su un singolo nodo) non può superare lo spazio di memoria totale sul sistema (RAM fisica + spazio di scambio). In realtà, sarà molto meno questo, poiché Redis condivide quello spazio con molti altri processi sul sistema e se esaurisce lo spazio di memoria del sistema sarà probabilmente ucciso dal sistema operativo.

Mongo è un archivio di dati basato su disco , che è più efficiente quando il suo set di lavoro si adatta alla RAM fisica (come tutti i software). Essere dati basati su disco significa che non ci sono limiti intrinseci alle dimensioni di un database Mongo, tuttavia le opzioni di configurazione, lo spazio disponibile su disco e altre preoccupazioni possono comportare che le dimensioni dei database oltre un certo limite possano diventare impraticabili o inefficienti.

Sia Redis che Mongo possono essere raggruppati per elevata disponibilità, backup e per aumentare le dimensioni complessive dell'archivio dati.

Tutte le risposte (al momento della stesura di questo documento) presuppongono che ciascuno di Redis, MongoDB e forse un database relazionale basato su SQL sia essenzialmente lo stesso strumento: "memorizzare i dati". Non considerano affatto i modelli di dati.

MongoDB: dati complessi

MongoDB è un archivio di documenti. Per confrontare con un database relazionale basato su SQL: i database relazionali semplificano i file CSV indicizzati, ogni file essendo una tabella; gli archivi documenti semplificano i file JSON indicizzati, ogni file è un documento, con più file raggruppati insieme.

I file JSON sono simili nella struttura ai file XML e YAML e ai dizionari come in Python, quindi pensa ai tuoi dati in quel tipo di gerarchia. Durante l'indicizzazione, la struttura è la chiave: un documento contiene chiavi denominate, che contengono ulteriori documenti, matrici o valori scalari. Considera il documento seguente.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

Il documento sopra ha una chiave PhoneNumber.Mobile, che ha valore 555 634-5789. Puoi cercare in una raccolta di documenti in cui la chiave PhoneNumber.Mobileha un valore; sono indicizzati.

Ha anche una matrice di Accountscui contiene più indici. È possibile eseguire una query per un documento in cui Accountscontiene esattamente alcuni sottoinsiemi di valori, tutti alcuni sottoinsiemi di valori o uno qualsiasi di alcuni sottoinsiemi di valori. Ciò significa che puoi cercare Accounts = ["379-1111", "379-2574"]e non trovare quanto sopra; puoi cercare Accounts includes ["379-1111"]e trovare il documento sopra; e puoi cercare Accounts includes any of ["974-3785","414-6731"]e trovare quanto sopra e qualunque documento includa l'account "974-3785", se presente.

I documenti vanno in profondità quanto vuoi. PhoneNumber.Mobilepotrebbe contenere un array o persino un documento secondario ( PhoneNumber.Mobile.Worke PhoneNumber.Mobile.Personal). Se i tuoi dati sono altamente strutturati, i documenti rappresentano un grande passo avanti rispetto ai database relazionali.

Se i tuoi dati sono per lo più piatti, relazionali e rigidamente strutturati, stai meglio con un database relazionale. Ancora una volta, il grande segno è se i tuoi modelli di dati si adattano meglio a una raccolta di file CSV correlati o a una raccolta di file XML / JSON / YAML.

Per la maggior parte dei progetti, dovrai scendere a compromessi, accettando una soluzione secondaria in alcune piccole aree in cui SQL o Document Store non si adattano; per alcuni progetti complessi e di grandi dimensioni che archiviano un'ampia gamma di dati (molte colonne; le righe sono irrilevanti), avrà senso archiviare alcuni dati in un modello e altri in un altro modello. Facebook utilizza sia SQL che un database grafico (in cui i dati vengono inseriti nei nodi e i nodi sono collegati ad altri nodi); Craigslist utilizzava MySQL e MongoDB, ma aveva cercato di spostarsi completamente su MongoDB. Questi sono luoghi in cui l'arco e la relazione dei dati affrontano svantaggi significativi se inseriti in un modello.

Redis: valore-chiave

Redis è fondamentalmente un archivio di valori-chiave. Redis ti consente di dargli una chiave e cercare un singolo valore. Redis stesso può memorizzare stringhe, elenchi, hash e poche altre cose; tuttavia, cerca solo per nome.

L'invalidazione della cache è uno dei problemi più difficili dell'informatica; l'altro sta nominando le cose. Ciò significa che utilizzerai Redis quando vuoi evitare centinaia di ricerche in eccesso su un back-end, ma dovrai capire quando hai bisogno di una nuova ricerca.

Il caso più evidente di invalidamento è l'aggiornamento in scrittura: se leggi user:Simon:lingots = NOTFOUND, potresti SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simone archiviare il risultato 100, come SET user:Simon:lingots = 100. Poi, quando si Award Simon 5 lingotti, si legge user:Simon:lingots = 100, SET user:Simon:lingots = 105e UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Ora ne hai 105 nel tuo database e in Redis e puoi ottenerlo user:Simon:lingotssenza interrogare il database.

Il secondo caso è l'aggiornamento delle informazioni dipendenti. Supponiamo che tu generi blocchi di una pagina e memorizzi nella cache il loro output. L'intestazione mostra l'esperienza, il livello e la quantità di denaro del giocatore; la pagina del profilo del giocatore ha un blocco che mostra le sue statistiche; e così via. Il giocatore guadagna esperienza. Bene, ora si dispone di più templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simone così via campi in cui avete memorizzato nella cache l'output di un database di mezza dozzina di query eseguite attraverso un motore di template. Normalmente, quando visualizzi queste pagine, dici:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

Poiché hai appena aggiornato i risultati di GetStatsFromDatabase("Simon"), devi abbandonare templates:*:Simonla cache dei valori-chiave. Quando si tenta di eseguire il rendering di uno di questi modelli, l'applicazione sfornerà il recupero dei dati dal database (PostgreSQL, MongoDB) e l'inserimento nel modello; quindi memorizzerà il risultato in Redis e, si spera, non si preoccuperà di fare query sul database e modelli di rendering la prossima volta che visualizzerà quel blocco di output.

Redis ti consente anche di creare code di messaggi per gli editori e simili. Questo è un altro argomento interamente. Punto qui è Redis è una cache di valori-chiave, che differisce da un database relazionale o da un archivio documenti.

Conclusione

Scegli i tuoi strumenti in base alle tue esigenze. La necessità maggiore è in genere il modello di dati, in quanto determina la complessità e la propensione all'errore del codice. Le applicazioni specializzate si baseranno sulle prestazioni, luoghi in cui si scrive tutto in una miscela di C e Assembly; la maggior parte delle applicazioni gestirà solo il caso generalizzato e utilizzerà un sistema di memorizzazione nella cache come Redis o Memcached, che è molto più veloce di un database SQL ad alte prestazioni o di un archivio documenti.

E non dovresti usare nessuno dei due se hai molta RAM. Redis e MongoDB arrivano al prezzo di uno strumento generico. Questo introduce un sacco di spese generali.

Si diceva che Redis fosse 10 volte più veloce di Mongo. Potrebbe non essere più così vero. MongoDB (se ricordo bene) ha dichiarato di battere memcache per l'archiviazione e la memorizzazione nella cache dei documenti purché le configurazioni di memoria siano le stesse.

Comunque. Redis buono, MongoDB è buono. Se ti interessano le sottostrutture e hai bisogno di aggregazione, scegli MongoDB. Se la memorizzazione di chiavi e valori è la tua principale preoccupazione, è tutto su Redis. (o qualsiasi altro archivio di valori chiave).

Redis e MongoDB sono entrambi database non relazionali ma appartengono a categorie diverse.

Redis è un database chiave / valore e utilizza l'archiviazione in memoria che lo rende super veloce. È un buon candidato per la memorizzazione nella cache di roba e archiviazione temporanea di dati (in memoria) e poiché la maggior parte delle piattaforme cloud (come Azure, AWS) lo supportano, l'utilizzo della memoria è scalabile, ma se lo utilizzerai sui tuoi computer con risorse limitate, considera l'utilizzo della memoria.

MongoDB, d'altra parte, è un database di documenti. È una buona opzione per conservare testi, immagini, video, ecc. Di grandi dimensioni e quasi tutto ciò che si fa con i database ad eccezione delle transazioni. Ad esempio, se si desidera sviluppare un blog o un social network, MongoDB è la scelta giusta. È scalabile con la strategia di ridimensionamento. Utilizza il disco come supporto di archiviazione, quindi i dati sarebbero persistenti.

Se il tuo progetto modificato ti consente di disporre di memoria RAM sufficiente nel tuo ambiente, la risposta è Redis. Soprattutto tenendo conto del nuovo Redis 3.2 con funzionalità cluster.