什么时候使用Redis？什么时候使用 MongoDB？

When to Redis? When to MongoDB?

提问by u443966

What I want is not a comparison between Redis and MongoDB. I know they are different; the performance and the API is totally different.

我想要的不是 Redis 和 MongoDB 之间的比较。我知道他们是不同的；性能和 API 完全不同。

Redis is very fast, but the API is very 'atomic'. MongoDB will eat more resources, but the API is very very easy to use, and I am very happy with it.

Redis 非常快，但 API 非常“原子”。MongoDB会吃更多的资源，但是API非常非常好用，我很满意。

They're both awesome, and I want to use Redis in deployment as much as I can, but it is hard to code. I want to use MongoDB in development as much as I can, but it needs an expensive machine.

它们都很棒，我想在部署中尽可能多地使用 Redis，但是很难编码。我想在开发中尽可能多地使用 MongoDB，但它需要一台昂贵的机器。

So what do you think about the use of both of them? When to pick Redis? When to pick MongoDB?

那么对于两者的使用你怎么看呢？什么时候选择Redis？什么时候选择MongoDB？

采纳答案by Shekhar

I would say, it depends on kind of dev team you are and your application needs.

我会说，这取决于您所在的开发团队类型以及您的应用程序需求。

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 speedof 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.

例如，如果您需要大量查询，这主要意味着您的开发人员使用 Redis 会做更多的工作，您的数据可能存储在各种专门的数据结构中，针对每种类型的对象进行定制以提高效率。在 MongoDB 中，相同的查询可能更容易，因为结构在您的数据中更加一致。另一方面，在 Redis 中，对这些查询的绝对响应速度是处理数据可能使用的各种结构的额外工作的回报。

MongoDB offers simplicity, much shorter learning curve for developers with traditional DB and SQL experience. However, Redis's non-traditional approach requires more effort to learn, but greater flexibility.

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

Eg. A cachelayer can probably be better implemented in Redis. For more schema-able data, MongoDB is better. [Note: both MongoDB and Redis are technically schemaless]

例如。一个缓存层很可能在Redis的得到更好的执行。对于更多模式化数据，MongoDB 更好。 [注意：MongoDB 和 Redis 在技术上都是无模式的]

If you ask me, my personal choice is Redis for most requirements.

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

Lastly, I hope by now you have seen http://antirez.com/post/MongoDB-and-Redis.html

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

回答by Alexander Gugel

I just noticed that this question is quite old. Nevertheless, I consider the following aspects to be worth adding:

我只是注意到这个问题已经很老了。尽管如此，我认为以下方面值得补充：

• Use MongoDB if you don't know yet how you're going to query your data.

  MongoDB is suited for Hackathons, startups or every time you don't know how you'll query the data you inserted. MongoDB does not make any assumptions on your underlying schema. While MongoDB is schemaless and non-relational, this does not mean that there is no schema at all. It simply means that your schema needs to be defined in your app (e.g. using Mongoose). Besides that, MongoDB is great for prototyping or trying things out. Its performance is not that great and can't be compared to Redis.

• Use Redis in order to speed up your existing application.

  Redis can be easily integrated as a LRU cache. It is very uncommon to use Redis as a standalone database system (some people prefer referring to it as a "key-value"-store). Websites like Craigslist use Redis next to their primary database. Antirez (developer of Redis) demonstrated using Lamernews that it is indeed possible to use Redis as a stand alone database system.

• Redis does not make any assumptions based on your data.

  Redis provides a bunch of useful data structures (e.g. Sets, Hashes, Lists), but you have to explicitly define how you want to store you data. To put it in a nutshell, Redis and MongoDB can be used in order to achieve similar things. Redis is simply faster, but not suited for prototyping. That's one use case where you would typically prefer MongoDB. Besides that, Redis is reallyflexible. The underlying data structures it provides are the building blocks of high-performance DB systems.

• 如果您还不知道如何查询数据，请使用 MongoDB。

  MongoDB 适用于黑客马拉松、初创公司或每次您不知道如何查询您插入的数据时。MongoDB 不会对您的底层架构做出任何假设。虽然 MongoDB 是无模式和非关系的，但这并不意味着根本没有模式。这只是意味着您的架构需要在您的应用程序中定义（例如使用 Mongoose）。除此之外，MongoDB 非常适合进行原型设计或尝试。它的性能不是那么好，无法与Redis相提并论。

• 使用 Redis 来加速您现有的应用程序。

  Redis 可以轻松集成为LRU 缓存。将 Redis 用作独立的数据库系统是非常罕见的（有些人更喜欢将其称为“键值”存储）。像 Craigslist 这样的网站在它们的主数据库旁边使用Redis。Antirez（Redis 的开发者）使用 Lamernews 证明确实可以将 Redis 用作独立的数据库系统。

• Redis 不会根据您的数据做出任何假设。

  Redis 提供了一堆有用的数据结构（例如集合、散列、列表），但是您必须明确定义您希望如何存储数据。简而言之，Redis和MongoDB可以用来实现类似的事情。Redis 速度更快，但不适合原型设计。这是您通常更喜欢 MongoDB 的一种用例。除此之外，Redis非常灵活。它提供的底层数据结构是高性能数据库系统的构建块。

When to use Redis?

什么时候使用Redis？

• Caching

  Caching using MongoDB simply doesn't make a lot of sense. It would be too slow.

• If you have enough time to think about your DB design.

  You can't simply throw in your documents into Redis. You have to think of the way you in which you want to store and organize your data. One example are hashes in Redis. They are quite different from "traditional", nested objects, which means you'll have to rethink the way you store nested documents. One solution would be to store a reference inside the hash to another hash (something like key: [id of second hash]). Another idea would be to store it as JSON, which seems counter-intuitive to most people with a *SQL-background.

• If you need reallyhigh performance.

  Beating the performance Redis provides is nearly impossible. Imagine you database being as fast as your cache. That's what it feels like using Redis as a realdatabase.

• If you don't care thatmuch about scaling.

  Scaling Redis is not as hard as it used to be. For instance, you could use a kind of proxy server in order to distribute the data among multiple Redis instances. Master-slave replication is not thatcomplicated, but distributing you keys among multiple Redis-instances needs to be done on the application site (e.g. using a hash-function, Modulo etc.). Scaling MongoDB by comparison is much simpler.

• 缓存

  使用 MongoDB 进行缓存并没有多大意义。会太慢。

• 如果您有足够的时间考虑您的数据库设计。

  您不能简单地将文档放入 Redis。您必须考虑存储和组织数据的方式。一个例子是 Redis 中的哈希。它们与“传统”的嵌套对象完全不同，这意味着您必须重新考虑存储嵌套文档的方式。一种解决方案是在散列中存储对另一个散列的引用（类似于key: [id of second hash]）。另一个想法是将其存储为 JSON，这对于大多数具有 *SQL 背景的人来说似乎是违反直觉的。

• 如果您需要真正的高性能。

  击败 Redis 提供的性能几乎是不可能的。想象一下你的数据库和你的缓存一样快。这就是使用 Redis 作为真正的数据库的感觉。

• 如果你不小心说太多关于缩放。

  扩展 Redis 并不像以前那么难。例如，您可以使用一种代理服务器来在多个 Redis 实例之间分发数据。主从复制并没有那么复杂，但是需要在应用程序站点上完成在多个 Redis 实例之间分配密钥的工作（例如使用散列函数、Modulo 等）。相比之下，扩展 MongoDB 要简单得多。

When to use MongoDB

何时使用 MongoDB

• Prototyping, Startups, Hackathons

  MongoDB is perfectly suited for rapid prototyping. Nevertheless, performance isn't that good. Also keep in mind that you'll most likely have to define some sort of schema in your application.

• When you need to change your schema quickly.

  Because there is no schema! Altering tables in traditional, relational DBMS is painfully expensive and slow. MongoDB solves this problem by not making a lot of assumptions on your underlying data. Nevertheless, it tries to optimize as far as possible without requiring you to define a schema.

• 原型设计、初创公司、黑客马拉松

  MongoDB 非常适合快速原型设计。然而，性能并不是那么好。还要记住，您很可能必须在应用程序中定义某种模式。

• 当您需要快速更改架构时。

  因为没有模式！在传统的关系 DBMS 中更改表非常昂贵且缓慢。MongoDB 通过不对您的基础数据进行大量假设来解决这个问题。尽管如此，它会尽量优化而不需要您定义模式。

TL;DR- Use Redis if performance is important and you are willing to spend time optimizing and organizing your data. - Use MongoDB if you need to build a prototype without worrying too much about your DB.

TL;DR- 如果性能很重要并且您愿意花时间优化和组织数据，请使用 Redis。- 如果您需要构建原型而不用过多担心您的数据库，请使用 MongoDB。

Further reading:

进一步阅读：

• Interesting aspects to consider when using Redis as a primary data store

• 使用Redis 作为主要数据存储时要考虑的有趣方面

回答by Gabe Rainbow

Redis. Let's say you've written a site in php; for whatever reason, it becomes popular and it's ahead of its time or has porno on it. You realize this php is so freaking slow, "I'm gonna lose my fans because they simply won't wait 10 seconds for a page." You have a sudden realization that a web page has a constant url (it never changes, whoa), a primary key if you will, and then you recall that memory is fast while disk is slow and php is even slower. :( Then you fashion a storage mechanism using memory and this URL that you call a "key" while the webpage content you decide to call the "value." That's all you have - key and content. You call it "meme cache." You like Richard Dawkins because he's awesome. You cache your html like squirrels cache their nuts. You don't need to rewrite your crap php code. You are happy. Then you see that others have done it -- but you choose Redis because the other one has confusing images of cats, some with fangs.

Redis。假设您已经用 php 编写了一个站点；无论出于何种原因，它变得流行，它超前于时代或有内容。你意识到这个 php 太慢了，“我会失去我的粉丝，因为他们根本不会等待 10 秒的页面。” 你突然意识到一个网页有一个固定的 url（它永远不会改变，哇），一个主键，如果你愿意，然后你回想起内存很快，而磁盘很慢，而 php 更慢。:( 然后你使用内存和这个你称之为“键”的 URL 来设计一个存储机制，而你决定将网页内容称为“值”。这就是你所拥有的 - 键和内容。你称之为“模因缓存”。你喜欢理查德道金斯，因为他很棒。你缓存你的 html 就像松鼠缓存他们的坚果一样。你不” 不需要重写你的垃圾php代码。你很快乐。然后你会看到其他人已经这样做了——但你选择了 Redis，因为另一个人有令人困惑的猫图像，有些有尖牙。

Mongo. You've written a site. Heck you've written many, and in any language. You realize that much of your time is spent writing those stinking SQL clauses. You're not a dba, yet there you are, writing stupid sql statements... not just one but freaking everywhere. "select this, select that". But in particular you remember the irritating WHERE clause. Where lastname equals "thornton" and movie equals "bad santa." Urgh. You think, "why don't those dbas just do their job and give me some stored procedures?" Then you forget some minor field like middlename and then you have to drop the table, export all 10G of big data and create another with this new field, and import the data -- and that goes on 10 times during the next 14 days as you keep on remembering crap like salutation, title, plus adding a foreign key with addresses. Then you figure that lastname should be lastName. Almost one change a day. Then you say darnit. I have to get on and write a web site/system, never mind this data model bs. So you google, "I hate writing SQL, please no SQL, make it stop" but up pops 'nosql' and then you read some stuff and it says it just dumps data without any schema. You remember last week's fiasco dropping more tables and smile. Then you choose mongo because some big guys like 'airbud' the apt rental site uses it. Sweet. No more data model changes because you have a model you just keep on changing.

蒙哥。你写了一个网站。哎呀，你写了很多，用任何语言。您意识到您的大部分时间都花在了编写那些糟糕的 SQL 子句上。您不是 dba，但您在那里，正在编写愚蠢的 sql 语句……不仅是一个，而且到处都是。“选择这个，选择那个”。但特别是你记得令人讨厌的 WHERE 子句。姓氏等于“桑顿”，而电影等于“坏圣诞老人”。呃。你会想，“为什么那些 dbas 不做他们的工作，给我一些存储过程呢？” 然后你忘记了一些次要字段，比如中间名，然后你必须删除表，导出所有 10G 的大数据，并用这个新字段创建另一个，然后导入数据——在接下来的 14 天里，这会像你一样重复 10 次继续记住一些废话，比如称呼、头衔，加上添加地址的外键。然后你认为姓氏应该是姓氏。几乎一天换一次。然后你说达尼特。我必须继续写一个网站/系统，别介意这个数据模型 bs。所以你用谷歌搜索，“我讨厌写 SQL，请不要写 SQL，让它停止”但是弹出'nosql'然后你读了一些东西，它说它只是在没有任何模式的情况下转储数据。你记得上周的惨败，丢了更多的桌子和微笑。然后你选择 mongo，因为一些大家伙喜欢 'airbud' apt 租赁网站使用它。甜的。没有更多的数据模型更改，因为您拥有一个不断更改的模型。所以你用谷歌搜索，“我讨厌写 SQL，请不要写 SQL，让它停止”但是弹出'nosql'然后你读了一些东西，它说它只是在没有任何模式的情况下转储数据。你记得上周的惨败，丢了更多的桌子和微笑。然后你选择 mongo，因为一些大家伙喜欢 'airbud' apt 租赁网站使用它。甜的。没有更多的数据模型更改，因为您拥有一个不断更改的模型。所以你用谷歌搜索，“我讨厌写 SQL，请不要写 SQL，让它停止”但是弹出'nosql'然后你读了一些东西，它说它只是在没有任何模式的情况下转储数据。你记得上周的惨败，丢了更多的桌子和微笑。然后你选择 mongo，因为一些大家伙喜欢 'airbud' apt 租赁网站使用它。甜的。没有更多的数据模型更改，因为您拥有一个不断更改的模型。

回答by stackex

Maybe this resource is useful helping decide between both. It also discusses several other NoSQL databases, and offers a short list of characteristics, along with a "what I would use it for"explanation for each of them.

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

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

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

回答by Bryan Migliorisi

Difficult question to answer - as with most technology solutions, it really depends on your situation and since you have not described the problem you are trying to solve, how can anyone propose a solution?

难以回答的问题 - 与大多数技术解决方案一样，这实际上取决于您的情况，并且由于您没有描述您要解决的问题，那么任何人怎么能提出解决方案呢？

You need to test them both to see which of them satisfied yourneeds.

您需要对它们都进行测试，以查看它们中的哪一个满足了您的需求。

With that said, MongoDB does not require any expensive hardware. Like any other database solution, it will work better with more CPU and memory but is certainly not a requirement - especially for early development purposes.

话虽如此，MongoDB 不需要任何昂贵的硬件。与任何其他数据库解决方案一样，使用更多 CPU 和内存会更好地工作，但肯定不是必需的 - 特别是对于早期开发目的。

回答by aaa90210

Redis is an in memorydata store, that can persist it's state to disk(to enable recovery after restart). However, being an in-memory data store means the size of the data store (on a single node) cannot exceed the total memory space on the system (physical RAM + swap space). In reality, it will be much less that this, as Redis is sharing that space with many other processes on the system, and if it exhausts the system memory space it will likely be killed off by the operating system.

Redis 是一种内存数据存储，可以将其状态持久化到磁盘（以在重启后启用恢复）。但是，作为内存数据存储意味着数据存储的大小（在单个节点上）不能超过系统上的总内存空间（物理 RAM + 交换空间）。实际上，它会少得多，因为 Redis 正在与系统上的许多其他进程共享该空间，如果它耗尽了系统内存空间，它可能会被操作系统杀死。

Mongo is a disk baseddata store, that is most efficient when it's working setfits within physical RAM (like all software). Being a disk based data means there are no intrinsic limits on the size of a Mongo database, however configuration options, available disk space, and other concerns may mean that databases sizes over a certain limit may become impractical or inefficient.

Mongo 是一种基于磁盘的数据存储，当它的工作集适合物理 RAM（就像所有软件一样）时效率最高。作为基于磁盘的数据意味着 Mongo 数据库的大小没有内在限制，但是配置选项、可用磁盘空间和其他问题可能意味着数据库大小超过特定限制可能变得不切实际或效率低下。

Both Redis and Mongo can be clustered for high availability, backup and to increase the overall size of the datastore.

Redis 和 Mongo 都可以集群以实现高可用性、备份和增加数据存储的整体大小。

回答by John Moser

All of the answers (at the time of this writing) assume each of Redis, MongoDB, and perhaps an SQL-based relational database are essentially the same tool: "store data". They don't consider data models at all.

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

MongoDB: Complex Data

MongoDB：复杂数据

MongoDB is a document store. To compare with an SQL-driven relational database: relational databases simplify to indexed CSV files, each file being a table; document stores simplify to indexed JSON files, each file being a document, with multiple files grouped together.

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

JSON files are similar in structure to XML and YAML files, and to dictionaries as in Python, so think of your data in that sort of hierarchy. When indexing, the structure is the key: A document contains named keys, which contain either further documents, arrays, or scalar values. Consider the below document.

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"
}

The above document has a key, PhoneNumber.Mobile, which has value 555 634-5789. You can search through a collection of documents where the key, PhoneNumber.Mobile, has some value; they're indexed.

上面的文档有一个键，PhoneNumber.Mobile，它的值为555 634-5789。您可以搜索一组文档，其中键PhoneNumber.Mobile, 具有某些值；他们被索引了。

It also has an array of Accountswhich hold multiple indexes. It is possible to query for a document where Accountscontains exactlysome subset of values, allof some subset of values, or anyof 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.

它还有一个数组，Accounts其中包含多个索引。这是可能的查询，其中一个文件Accounts包含准确值的某个子集，所有值的一些子集，或任何值的一些子集。这意味着您可以搜索Accounts = ["379-1111", "379-2574"]但找不到上述内容；您可以搜索Accounts includes ["379-1111"]并找到上述文档；并且您可以搜索Accounts includes any of ["974-3785","414-6731"]并找到以上内容以及包含帐户“974-3785”的任何文档（如果有）。

Documents go as deep as you want. PhoneNumber.Mobilecould hold an array, or even a sub-document (PhoneNumber.Mobile.Workand PhoneNumber.Mobile.Personal). If your data is highly structured, documents are a large step up from relational databases.

文档可以深入到您想要的深度。 PhoneNumber.Mobile可以保存一个数组，甚至一个子文档（PhoneNumber.Mobile.Work和PhoneNumber.Mobile.Personal）。如果您的数据是高度结构化的，那么文档是关系数据库的一大进步。

If your data is mostly flat, relational, and rigidly structured, you're better off with a relational database. Again, the big sign is whether your data models best to a collection of interrelated CSV files or a collection of XML/JSON/YAML files.

如果您的数据大多是扁平的、关系型的且结构严格，那么最好使用关系型数据库。同样，重要的标志是您的数据模型是最适合一组相互关联的 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.

对于大多数项目，您将不得不妥协，在 SQL 或文档存储不适合的一些小领域接受一个小的解决方法；对于一些存储广泛数据（许多列；行无关）的大型复杂项目，将一些数据存储在一个模型中并将其他数据存储在另一个模型中是有意义的。Facebook 同时使用 SQL 和图数据库（其中数据放入节点，节点连接到其他节点）；Craigslist 曾经使用 MySQL 和 MongoDB，但一直在考虑完全转移到 MongoDB。如果放在一个模型下，这些数据的跨度和关系将面临重大障碍。

Redis: Key-Value

Redis：键值

Redis is, most basically, a key-value store. Redis lets you give it a key and look up a single value. Redis itself can store strings, lists, hashes, and a few other things; however, it only looks up by name.

Redis 基本上是一个键值存储。Redis 允许您给它一个键并查找单个值。Redis 本身可以存储字符串、列表、哈希值和其他一些东西；但是，它只能按名称查找。

Cache invalidation is one of computer science's hard problems; the other is naming things. That means you'll use Redis when you want to avoid hundreds of excess look-ups to a back-end, but you'll have to figure out when you need a new look-up.

缓存失效是计算机科学的难题之一；另一个是命名事物。这意味着当您想避免对后端进行数百次过多的查找时，您将使用 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 = Simonand 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:lingotswithout querying the database.

最明显的失效情况是写入时更新：如果您读取user:Simon:lingots = NOTFOUND，您可能会将SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon结果存储100为SET user:Simon:lingots = 100。然后，当你奖励西蒙5个lingots，你看user:Simon:lingots = 100，SET user:Simon:lingots = 105和UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon。现在您的数据库和 Redis 中有 105 个，并且user:Simon:lingots无需查询数据库即可获得。

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:

第二种情况是更新依赖信息。假设您生成页面块并缓存它们的输出。标题显示玩家的经验、等级和金钱数量；玩家的个人资料页面有一个区块，显示他们的统计数据；等等。玩家获得一些经验。好吧，现在您有几个templates:Header:Simon、templates:StatsBox:Simon、templates:GrowthGraph:Simon等字段，您已经在其中缓存了通过模板引擎运行的六个数据库查询的输出。通常，当您显示这些页面时，您会说：

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

Because you just updated the results of GetStatsFromDatabase("Simon"), you have to drop templates:*:Simonout of your key-value cache. When you try to render any of these templates, your application will churn away fetching data from your database (PostgreSQL, MongoDB) and inserting it into your template; then it will store the result in Redis and, hopefully, not bother making database queries and rendering templates the next time it displays that block of output.

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

Redis also lets you do publisher-subscribe message queues and such. That's another topic entirely. Point here is Redis is a key-value cache, which differs from a relational database or a document store.

Redis 还允许您执行发布者订阅消息队列等。那完全是另一个话题。这里的重点是Redis是一个key-value缓存，区别于关系型数据库或者文档存储。

Conclusion

结论

Pick your tools based on your needs. The largest need is usually data model, as that determines how complex and error-prone your code is. Specialized applications will lean on performance, places where you write everything in a mixture of C and Assembly; most applications will just handle the generalized case and use a caching system such as Redis or Memcached, which is a lot faster than either a high-performance SQL database or a document store.

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

回答by akazemis

Redis and MongoDB are both non-relational databases but they're of different categories.

Redis 和 MongoDB 都是非关系型数据库，但它们属于不同的类别。

Redis is a Key/Value database, and it's using In-memory storage which makes it super fast. It's a good candidate for caching stuff and temporary data storage(in memory) and as the most of cloud platforms (such as Azure,AWS) support it, it's memory usage is scalable.But if you're gonna use it on your machines with limited resources, consider it's memory usage.

Redis 是一个键/值数据库，它使用内存存储，因此速度非常快。它是缓存内容和临时数据存储（在内存中）的一个很好的候选者，并且由于大多数云平台（如 Azure、AWS）都支持它，它的内存使用是可扩展的。但是如果你要在你的机器上使用它有限的资源，考虑它的内存使用情况。

MongoDB on the other hand, is a document database. It's a good option for keeping large texts, images, videos, etc and almost anything you do with databases except transactions.For example if you wanna develop a blog or social network, MongoDB is a proper choice. It's scalable with scale-out strategy. It uses disk as storage media, so data would be persisted.

另一方面，MongoDB 是一个文档数据库。它是保存大文本、图像、视频等以及几乎所有您对数据库所做的除事务之外的任何事情的不错选择。例如，如果您想开发博客或社交网络，MongoDB 是一个不错的选择。它可以通过横向扩展策略进行扩展。它使用磁盘作为存储介质，因此数据将被持久化。

回答by Martin Kersten

And you should use neither if you have plenty of RAM. Redis and MongoDB come to the price of a general purpose tool. This introduce a lot of overhead.

如果您有足够的 RAM，则不应使用两者。Redis 和 MongoDB 的代价是通用工具。这引入了很多开销。

There was the saying that Redis is 10 times faster than Mongo. That might not be that true anymore. MongoDB (if i remember correctly) claimed to beat memcache for storing and caching documents as long as the memory configurations are the same.

有人说 Redis 比 Mongo 快 10 倍。那可能不再那么真实了。MongoDB（如果我没记错的话）声称只要内存配置相同，就可以击败 memcache 来存储和缓存文档。

Anyhow. Redis good, MongoDB is good. If you care about substructures and need aggregation go for MongoDB. If storing keys and values is your main concern its all about Redis. (or any other key value store).

无论如何。Redis 好，MongoDB 好。如果您关心子结构并需要聚合，请选择 MongoDB。如果存储键和值是您主要关心的问题，那就是 Redis。（或任何其他键值存储）。

回答by Denys

If your project budged allows you to have enough RAM memory on your environment - answer is Redis. Especially taking in account new Redis 3.2 with cluster functionality.

如果您的项目预算允许您在您的环境中拥有足够的 RAM 内存 - 答案是 Redis。特别是考虑到具有集群功能的新 Redis 3.2。