Tenho experiência com Redis e MongoDB, mas também não recomendaria para o seu caso de uso. O Redis é incrível em todos os aspectos, mas como é somente RAM e não possui recursos de cluster (ainda estão em desenvolvimento), ele não é dimensionado muito bem. MongoDB eu nunca mais usaria para qualquer coisa que precise de algo além de um pequeno conjunto de réplicas.

Basicamente, o MongoDB é imaturo e completamente inadequado para qualquer tipo de requisitos de alto volume e alto desempenho. Ele tem um bloqueio de gravação global que é mantido durante as liberações de disco, o que significa que o desempenho pode variar muito dependendo do que você faz. Na prática, isso impossibilita as atualizações que aumentam os documentos, e você também precisa ter muito cuidado com as exclusões. Falando em exclusões, elas fragmentam severamente o banco de dados, então se você fizer muitas exclusões, seu desempenho será prejudicado.

A fragmentação de 1.8.0 a 1.8.1 foi um desastre. Houve bugs completos que nunca deveriam ter chegado a uma versão estável. A configuração não foi liberada corretamente e foi muito fácil colocar seu banco de dados em um estado ruim para que os fragmentos nunca saíssem do shard primário. 1.8.2 resolve a maioria deles e parece mais estável, mas não confio nem um pouco na implementação de sharding. Acrescente a isso que o sharding é difícil mesmo quando tudo funciona, nem sempre é fácil selecionar uma chave de shard natural e, se você não o sharding, causará muito sofrimento.

O MongoDB é muito fácil de trabalhar e o conjunto de recursos é muito bom. A documentação, os drivers e a comunidade são ótimos. O MongoDB funciona super como um substituto para o MySQL, mas não o use para nada que precise escalar horizontalmente.

No momento, estamos pensando em nos mudar para Cassandra. Acho o modelo do dínamo (por exemplo, sem nós mestres; escrever e ler em qualquer lugar; basta adicionar nós para aumentar o cluster) atraente e os recursos são mais ou menos adequados para nós. O modelo de dados é menos esquema como o MongoDB, embora um pouco mais limitado (você pode escolher entre um ou dois hashes de nível, basicamente). Tenho certeza de que a comunidade é boa quando você entra nela, mas até agora acho difícil encontrar boas informações sobre como resolver problemas comuns, e a documentação está faltando. A maioria das informações que você encontra em blogs tem um ano, e muitas coisas aconteceram desde então (0,7 e 0,8 parecem ser atualizações realmente significativas, mas a maioria das coisas que você encontra são cerca de 0,6). Os drivers também não são muito maduros ou bem documentados, pelo que vi até agora, e todos parecem estar brigando sobre se Thrift, Avro ou CQL é o que deve ser usado (e isso mudou de 0,6 para 0,7 para 0,8) .

Riak é interessante, pelos mesmos motivos que Cassandra, mas para nós um armazenamento de chave-valor puro não é suficiente, precisamos ser capazes de atualizar sem primeiro fazer uma leitura. Com Riak isso não é possível, pois os valores são apenas blobs. Isso parece que não seria um problema para você.

HBase é outro concorrente. Parece difícil configurar e executar por causa das muitas peças diferentes, ZooKeeper, HDFS, etc. Mas o modelo de dados é semelhante ao Cassandra (colunar, ou seja, hashes de um nível), que funciona bem para nós, mas pode não ser importante para você. Parece comprovado, mas, como no MongoDB, você precisa ficar atento a problemas de fragmentação, deve pensar um pouco em suas chaves ou terá problemas.

Há também CouchDB, Project Voldemort e inúmeras outras opções possíveis. Eu acho que se você leva a sério "volumes extremamente altos de dados", então é entre Cassandra, Riak e HBase. Ataque Riak se o armazenamento de valor-chave puro não for suficiente. Dependendo do que você quer dizer com "replicação totalmente consistente", Cassandra e Riak estão fora, porque há uma possibilidade (não necessariamente grande e ajustável) de ler um valor obsoleto.

No final, você obviamente tem que experimentá-lo em seu caso de uso específico, então tudo o que você realmente deve levar para casa desta resposta é:não se preocupe com o MongoDB.