Tengo experiencia con Redis y MongoDB, pero tampoco lo recomendaría para su caso de uso. Redis es impresionante en todos los aspectos, pero dado que es solo RAM y no tiene características de agrupación (aún, están en desarrollo), no escala muy bien. Nunca volvería a usar MongoDB para nada que necesite algo más que un pequeño conjunto de réplicas.
Básicamente, MongoDB es inmaduro y completamente inadecuado para cualquier tipo de requisitos de alto rendimiento y alto volumen. Tiene un bloqueo de escritura global que se mantiene durante los vaciados del disco, lo que significa que el rendimiento puede variar enormemente según lo que haga. En la práctica, hace que las actualizaciones que hacen crecer los documentos sean imposibles, y también debe tener mucho cuidado con las eliminaciones. Hablando de eliminaciones, fragmentan severamente la base de datos, por lo que si elimina muchas veces, su rendimiento se verá afectado.
La fragmentación en 1.8.0 a 1.8.1 fue un desastre. Hubo errores de show stopper completos que nunca deberían haber llegado a una versión estable. La configuración no se vació correctamente y fue muy fácil hacer que su base de datos quedara en mal estado para que los fragmentos nunca se movieran fuera del fragmento principal. 1.8.2 resuelve la mayoría de ellos y parece más estable, pero no confío ni un poco en la implementación de fragmentación. Agregue a esto que la fragmentación es difícil incluso cuando todo funciona, no siempre es fácil seleccionar una clave de fragmentación natural y, si no lo hace, la fragmentación le causará mucho dolor.
Es realmente fácil trabajar con MongoDB y el conjunto de características es realmente bueno. La documentación, los controladores y la comunidad son geniales. MongoDB funciona muy bien como reemplazo de MySQL, pero no lo use para nada que necesite escalar horizontalmente.
Actualmente estamos considerando mudarnos a Cassandra. Considero que el modelo de dínamo (p. ej., sin nodos maestros; escriba y lea en cualquier lugar; simplemente agregue nodos para hacer crecer el clúster) convincente y las características son más o menos adecuadas para nosotros. El modelo de datos es menos esquema como MongoDB, aunque un poco más limitado (puede elegir entre uno o dos hashes de nivel, básicamente). Estoy seguro de que la comunidad es buena una vez que entras en ella, pero hasta ahora me resulta difícil encontrar buena información sobre cómo resolver problemas comunes, y falta documentación. La mayor parte de la información que encuentra en los blogs tiene un año de antigüedad, y han sucedido muchas cosas desde entonces (la 0.7 y la 0.8 parecen ser actualizaciones realmente significativas, pero la mayoría de las cosas que encuentra son aproximadamente 0.6). Los controladores tampoco son muy maduros ni están bien documentados, por lo que he visto hasta ahora, y todo el mundo parece estar discutiendo sobre si se debe usar Thrift, Avro o CQL (y eso ha cambiado de 0.6 a 0.7 a 0.8) .
Riak es interesante, por las mismas razones que Cassandra, pero para nosotros un almacén de clave-valor puro no es suficiente, necesitamos poder actualizar sin hacer primero una lectura. Con Riak esto no es posible ya que los valores son solo gotas. Sin embargo, parece que no sería un problema para ti.
HBase es otro contendiente. Parece complicado configurarlo y ejecutarlo debido a las muchas piezas diferentes, ZooKeeper, HDFS, etc. Pero el modelo de datos es similar a Cassandra (columnar, es decir, hash de un nivel), que funciona bien para nosotros, pero puede no serlo. importante para ti Parece probado y cierto, pero al igual que con MongoDB, debe tener cuidado con los problemas de fragmentación, debe pensar un poco en sus claves o se meterá en problemas.
También está CouchDB, Project Voldemort y muchas otras opciones posibles. Creo que si te tomas en serio los "volúmenes de datos extremadamente altos", entonces es entre Cassandra, Riak y HBase. Ataca a Riak si el almacenamiento puro de valor-clave no es suficiente. Dependiendo de lo que quiera decir con "replicación totalmente consistente", entonces Cassandra y Riak están fuera, porque existe la posibilidad (no necesariamente grande y ajustable) de leer un valor obsoleto.
Al final, obviamente, debe probarlo en su caso de uso particular, por lo que todo lo que realmente debe llevarse a casa de esta respuesta es:no se moleste con MongoDB.
