Jag har erfarenhet av Redis och MongoDB, men skulle inte rekommendera det heller för ditt användningsfall. Redis är fantastiskt i alla avseenden, men eftersom det endast är RAM-minne och inte har några klustringsfunktioner (ännu är de under utveckling), skalar det inte särskilt bra. MongoDB skulle jag aldrig använda igen för något som behöver något annat än ett litet replikset.
I grund och botten är MongoDB omogen och helt olämplig för alla typer av höga volymer och höga prestandakrav. Den har ett globalt skrivlås som hålls under diskspolningar, vilket gör att prestandan kan variera kraftigt beroende på vad du gör. I praktiken omöjliggör det uppdateringar som utökar dokument, och du måste också vara mycket försiktig med borttagningar. På tal om raderingar, de fragmenterar databasen allvarligt, så om du gör många raderingar kommer din prestation att bli lidande.
Sharing i 1.8.0 till 1.8.1 var en katastrof. Det fanns kompletta showstopp-buggar som aldrig borde ha gjort det till en stabil utgåva. Konfigurationen rensades inte ordentligt och det var mycket lätt att få din databas i ett dåligt tillstånd så att bitar aldrig flyttade bort från den primära skärvan. 1.8.2 löser de flesta av dem och verkar mer stabila, men jag litar inte ett dugg på sharding-implementeringen. Lägg till detta att skärning är svårt även när allt fungerar, det är inte alltid lätt att välja en naturlig skärvnyckel, och om du inte gör det kommer det att orsaka dig mycket sorg.
MongoDB är riktigt lätt att arbeta med och funktionsuppsättningen är riktigt snygg. Dokumentationen, förarna och samhället är alla fantastiska. MongoDB fungerar utmärkt som en ersättning för MySQL, men använd den inte för något som behöver skalas ut.
Vi funderar just nu på att flytta till Cassandra. Jag tycker att dynamomodellen (t.ex. inga masternoder; skriv och läs var som helst; lägg bara till noder för att utöka klustret) övertygande och funktionerna är mer eller mindre rätt för oss. Datamodellen är schema mindre precis som MongoDB, även om den är lite mer begränsad (du kan välja mellan en eller två nivås hash, i princip). Jag är säker på att samhället är bra när man väl kommit in i det, men än så länge har jag svårt att hitta bra information om hur man löser vanliga problem, och dokumentationen saknas. Det mesta av informationen du hittar på bloggar är ett år gammal, och mycket har hänt sedan dess (0,7 och 0,8 verkar vara riktigt betydande uppdateringar båda två, men det mesta du hittar är ungefär 0,6). Drivrutinerna är inte heller särskilt mogna eller väldokumenterade, vad jag har sett hittills, och alla verkar tjafsa om huruvida Thrift, Avro eller CQL är det som ska användas (och det har ändrats från 0,6 till 0,7 till 0,8) .
Riak är intressant, av samma anledningar som Cassandra, men för oss räcker det inte med en ren nyckel-värde-butik, vi måste kunna uppdatera utan att först göra en läsning. Med Riak är detta inte möjligt eftersom värdena bara är blobbar. Detta låter som att det inte skulle vara ett problem för dig.
HBase är en annan utmanare. Det verkar vara jobbigt att installera och köra på grund av de många olika delarna, ZooKeeper, HDFS, etc. Men datamodellen liknar Cassandra (kolumn, d.v.s. en nivås hash), vilket fungerar bra för oss, men kanske inte är viktigt för dig. Det verkar beprövat och sant, men precis som med MongoDB måste du se upp för sönderdelningsproblem, du måste tänka på dina nycklar annars hamnar du i problem.
Det finns också CouchDB, Project Voldemort och otaliga andra möjliga val. Jag tror att om du menar allvar med "extremt höga datavolymer" så är det mellan Cassandra, Riak och HBase. Slå till Riak om ren nyckel-värde-lagring inte räcker. Beroende på vad du menar med "fullständigt konsekvent replikering" så är Cassandra och Riak ute, eftersom det finns en möjlighet (inte nödvändigtvis stor och justerbar) att läsa ett inaktuellt värde.
I slutändan måste du uppenbarligen prova det på just ditt användningsfall, så allt du egentligen borde ta hem från det här svaret är:bry dig inte om MongoDB.