Ho esperienza con Redis e MongoDB, ma non lo consiglierei nemmeno per il tuo caso d'uso. Redis è fantastico sotto ogni aspetto, ma poiché è solo RAM e non ha funzionalità di clustering (ancora, sono in fase di sviluppo), non si adatta molto bene. MongoDB non lo userei mai più per qualsiasi cosa abbia bisogno di nient'altro che un piccolo set di repliche.
Fondamentalmente, MongoDB è immaturo e completamente inadatto a qualsiasi tipo di requisito ad alto volume e prestazioni elevate. Ha un blocco di scrittura globale che viene mantenuto durante lo svuotamento del disco, il che significa che le prestazioni possono variare notevolmente a seconda di ciò che fai. In pratica rende impossibili gli aggiornamenti che fanno crescere i documenti e devi stare molto attento anche con le eliminazioni. A proposito di eliminazioni, frammentano gravemente il database, quindi se esegui molte eliminazioni le tue prestazioni ne risentiranno.
Lo sharding da 1.8.0 a 1.8.1 è stato un disastro. C'erano bug completi di blocco dello spettacolo che non avrebbero mai dovuto essere trasformati in una versione stabile. La configurazione non è stata scaricata correttamente ed è stato molto facile portare il database in uno stato errato in modo che i blocchi non si spostassero mai dallo shard primario. 1.8.2 risolve la maggior parte di essi e sembra più stabile, ma non mi fido un po' dell'implementazione dello sharding. Aggiungi a questo che lo sharding è difficile anche quando tutto funziona, non è sempre facile selezionare una chiave di shard naturale e se non lo sharding ti causerà molto dolore.
MongoDB è davvero facile da usare e il set di funzionalità è davvero bello. La documentazione, i driver e la community sono tutti fantastici. MongoDB funziona in modo eccellente come sostituto di MySQL, ma non usarlo per tutto ciò che deve essere ridimensionato.
Attualmente stiamo pensando di trasferirci a Cassandra. Trovo che il modello della dinamo (es. nessun nodo master; scrivi e leggi ovunque; aggiungi semplicemente nodi per far crescere il cluster) avvincente e le funzionalità sono più o meno adatte a noi. Il modello di dati è meno schema proprio come MongoDB, anche se un po' più limitato (in pratica puoi scegliere tra uno o due hash di livello). Sono sicuro che la community è buona una volta che ci si entra, ma finora trovo difficile trovare buone informazioni su come risolvere i problemi comuni e la documentazione è carente. La maggior parte delle informazioni che trovi sui blog risalgono a un anno fa e da allora sono successe molte cose (0,7 e 0,8 sembrano essere aggiornamenti davvero significativi entrambi, ma la maggior parte delle cose che trovi sono circa 0,6). Anche i driver non sono molto maturi o ben documentati, da quello che ho visto finora, e tutti sembrano litigare sul fatto che Thrift, Avro o CQL sia ciò che dovrebbe essere usato (e questo è cambiato da 0,6 a 0,7 a 0,8) .
Riak è interessante, per le stesse ragioni di Cassandra, ma per noi un puro key-value-store non basta, bisogna sapersi aggiornare senza prima fare una lettura. Con Riak questo non è possibile poiché i valori sono solo blob. Sembra che non sarebbe un problema per te.
HBase è un altro contendente. Sembra difficile da configurare ed eseguire a causa dei molti pezzi diversi, ZooKeeper, HDFS, ecc. Ma il modello di dati è simile a Cassandra (colonnare, ovvero hash di un livello), che funziona bene per noi, ma potrebbe non essere importante per te. Sembra provato e vero, ma come con MongoDB devi fare attenzione ai problemi di sharding, devi riflettere sulle tue chiavi o finisci nei guai.
C'è anche CouchDB, Project Voldemort e innumerevoli altre possibili scelte. Penso che se sei seriamente intenzionato a "volumi estremamente elevati di dati", allora è tra Cassandra, Riak e HBase. Colpisci Riak se la pura memorizzazione del valore-chiave non è sufficiente. A seconda di cosa intendi per "replica completamente coerente", Cassandra e Riak sono fuori, perché c'è la possibilità (non necessariamente grande e regolabile) di leggere un valore non aggiornato.
Alla fine ovviamente devi provarlo sul tuo caso d'uso particolare, quindi tutto ciò che dovresti davvero portare a casa da questa risposta è:non preoccuparti di MongoDB.
