如果你的项目预算允许你有足够的RAM内存在你的环境-答案是Redis。尤其是考虑到新的Redis 3.2的集群功能。

如果你的项目预算允许你有足够的RAM内存在你的环境-答案是Redis。尤其是考虑到新的Redis 3.2的集群功能。

也许这个资源可以帮助你在两者之间做出选择。 它还讨论了其他几个NoSQL数据库，并提供了一个简短的特征列表，以及对每个数据库的“我将使用它做什么”的解释。

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

我想说的是，这取决于你所在的开发团队以及你的应用程序需求。

For example, if you require a lot of querying, that mostly means it would be more work for your developers to use Redis, where your data might be stored in variety of specialized data structures, customized for each type of object for efficiency. In MongoDB the same queries might be easier because the structure is more consistent across your data. On the other hand, in Redis, sheer speed of the response to those queries is the payoff for the extra work of dealing with the variety of structures your data might be stored with.

MongoDB为具有传统DB和SQL经验的开发人员提供了简单、更短的学习曲线。然而，Redis的非传统方法需要更多的努力去学习，但更大的灵活性。

如。缓存层可能在Redis中可以更好地实现。对于更多可模式的数据，MongoDB更好。[注:MongoDB和Redis在技术上都是无模式的]

如果你问我，我个人对大多数需求的选择是Redis。

最后，我希望你现在已经看到http://antirez.com/post/MongoDB-and-Redis.html

所有的答案(在撰写本文时)都假设Redis、MongoDB和基于sql的关系数据库本质上都是相同的工具:“存储数据”。他们根本不考虑数据模型。

MongoDB:复杂数据

MongoDB是一个文档存储。与sql驱动的关系数据库相比:关系数据库简化为索引的CSV文件，每个文件都是一个表;文档存储简化为索引的JSON文件，每个文件都是一个文档，多个文件分组在一起。

JSON文件在结构上类似于XML和YAML文件，也类似于Python中的字典，所以要将数据考虑到那种层次结构中。索引时，结构是键:文档包含命名键，命名键包含进一步的文档、数组或标量值。考虑下面的文档。

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

上面的文档有一个键PhoneNumber。移动，值为555 634-5789。您可以搜索一个文档集合，其中键PhoneNumber。移动，有一定的价值;他们的索引。

It also has an array of Accounts which hold multiple indexes. It is possible to query for a document where Accounts contains exactly some subset of values, all of some subset of values, or any of some subset of values. That means you can search for Accounts = ["379-1111", "379-2574"] and not find the above; you can search for Accounts includes ["379-1111"] and find the above document; and you can search for Accounts includes any of ["974-3785","414-6731"] and find the above and whatever document includes account "974-3785", if any.

你想要多深就有多深。PhoneNumber。Mobile可以保存一个数组，甚至一个子文档(PhoneNumber.Mobile。Work和PhoneNumber.Mobile.Personal)。如果您的数据是高度结构化的，文档是关系数据库的一大进步。

如果您的数据主要是平面的、关系的和结构严格的，那么最好使用关系数据库。同样，重要的标志是您的数据模型最适合于相互关联的CSV文件的集合还是XML/JSON/YAML文件的集合。

For most projects, you'll have to compromise, accepting a minor work-around in some small areas where either SQL or Document Stores don't fit; for some large, complex projects storing a broad spread of data (many columns; rows are irrelevant), it will make sense to store some data in one model and other data in another model. Facebook uses both SQL and a graph database (where data is put into nodes, and nodes are connected to other nodes); Craigslist used to use MySQL and MongoDB, but had been looking into moving entirely onto MongoDB. These are places where the span and relationship of the data faces significant handicaps if put under one model.

复述:键值

Redis基本上是一个键值存储。Redis允许你给它一个键，然后查找一个单独的值。Redis本身可以存储字符串、列表、散列和其他一些东西;但是，它只能根据名称查找。

缓存失效是计算机科学的难题之一;另一个是命名。这意味着当你想要避免数百个多余的后端查询时，你会使用Redis，但你必须弄清楚什么时候你需要一个新的查询。

The most obvious case of invalidation is update on write: if you read user:Simon:lingots = NOTFOUND, you might SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon and store the result, 100, as SET user:Simon:lingots = 100. Then when you award Simon 5 lingots, you read user:Simon:lingots = 100, SET user:Simon:lingots = 105, and UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Now you have 105 in your database and in Redis, and can get user:Simon:lingots without querying the database.

The second case is updating dependent information. Let's say you generate chunks of a page and cache their output. The header shows the player's experience, level, and amount of money; the player's Profile page has a block that shows their statistics; and so forth. The player gains some experience. Well, now you have several templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, and so forth fields where you've cached the output of a half-dozen database queries run through a template engine. Normally, when you display these pages, you say:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

因为您刚刚更新了GetStatsFromDatabase("Simon")的结果，所以必须从键值缓存中删除模板:*:Simon。当你试图呈现这些模板中的任何一个，你的应用程序将从你的数据库(PostgreSQL, MongoDB)获取数据，并将其插入到你的模板;然后，它将结果存储在Redis中，希望在下次显示该输出块时，不必费心进行数据库查询和渲染模板。

Redis还允许你做发布者订阅消息队列等等。那完全是另一个话题了。这里的要点是Redis是一个键值缓存，它不同于关系数据库或文档存储。

结论

根据需要选择工具。最大的需求通常是数据模型，因为这决定了您的代码有多复杂和易出错。专门的应用程序将依赖于性能，在这些应用程序中，您可以混合使用C和汇编编写所有内容;大多数应用程序只会处理一般情况，并使用缓存系统，如Redis或Memcached，这比高性能SQL数据库或文档存储要快得多。

如果你有足够的RAM，你应该使用这两种方法。Redis和MongoDB达到了通用工具的价格。这会带来很多开销。

有一种说法是Redis比Mongo快10倍。这可能不再是真的了。MongoDB(如果我没记错的话)声称只要内存配置相同，就可以在存储和缓存文档方面击败memcache。

不管怎样。Redis不错，MongoDB也不错。如果你关心子结构并且需要聚合，那么就选择MongoDB。如果存储键和值是你主要关心的，它都是关于Redis。(或任何其他键值存储)。