我有使用 Redis 和 MongoDB 的经验，但不推荐用于您的用例。Redis 在各方面都很棒，但由于它仅使用 RAM 并且没有集群功能（但它们正在开发中），因此它的扩展性不是很好。MongoDB 我永远不会再将任何东西用于只需要一个小副本集的任何东西。
基本上，MongoDB 是不成熟的，完全不适合任何类型的大容量、高性能需求。它有一个在磁盘刷新期间持有的全局写锁，这意味着性能可能会因您的操作而有很大差异。在实践中，它使更新文档变得不可能，并且您也需要非常小心删除。说到删除，它们会严重破坏数据库，因此如果您执行大量删除操作，您的性能将会受到影响。
从 1.8.0 到 1.8.1 的分片是一场灾难。有完整的显示阻止错误，本不应该使其成为稳定版本。配置未正确刷新，很容易使您的数据库进入不良状态，因此块永远不会从主分片中移出。1.8.2 解决了大部分问题，看起来更稳定，但我一点也不相信分片实现。此外，即使一切正常，分片也很难，选择一个自然的分片键并不总是那么容易，如果你不分片会给你带来很大的痛苦。
MongoDB 真的很容易使用，而且功能集非常好。文档、驱动程序和社区都很棒。MongoDB 作为 MySQL 的替代品非常有效，但不要将它用于需要扩展的任何东西。
我们目前正在考虑迁移到 Cassandra。我发现 dynamo 模型（例如，没有主节点；随处写入和读取；只需添加节点即可扩展集群）很有吸引力，而且这些功能或多或少适合我们。数据模型不像 MongoDB 那样是模式，尽管有更多的限制（基本上，您可以在一级或二级散列之间进行选择）。我相信一旦你进入社区，社区就会很好，但到目前为止，我发现很难找到关于如何解决常见问题的好信息，而且文档也很缺乏。您在博客上找到的大部分信息都是一年前的，从那时起发生了很多事情（0.7 和 0.8 似乎都是非常重要的更新，但您找到的大多数信息都在 0.6 左右）。从我目前所见，驱动程序也不是很成熟或没有很好的文档记录，
Riak 很有趣，原因与 Cassandra 相同，但对我们来说，纯粹的键值存储是不够的，我们需要能够在不先读取的情况下进行更新。使用 Riak 这是不可能的，因为值只是 blob。不过，这听起来对你来说不是问题。
HBase 是另一个竞争者。由于有很多不同的部分，ZooKeeper、HDFS 等，设置和运行似乎很痛苦。 但是数据模型类似于 Cassandra（列式，即一级散列），这对我们来说效果很好，但可能不是对你很重要。这似乎是经过验证的，但是与 MongoDB 一样，您必须注意分片问题，您必须考虑一下您的密钥，否则您会遇到麻烦。
还有 CouchDB、Project Voldemort 和无数其他可能的选择。我认为，如果您认真对待“极大量的数据”，那么它介于 Cassandra、Riak 和 HBase 之间。如果纯键值存储还不够，请打击 Riak。根据您所说的“完全一致的复制”是什么意思，Cassandra 和 Riak 会被淘汰，因为有可能（不一定大且可调）读取过时的值。
最后，您显然必须在您的特定用例上尝试一下，所以您真正应该从这个答案中得到的答案是：不要打扰 MongoDB。