当复述,?什么时候MongoDB ?

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?

你们怎么看待它们的使用?选择复述,什么时候?当选择MongoDB ?

10 个解决方案

#1

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

例如，如果您需要大量的查询，这主要意味着您的开发人员需要使用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 cache layer 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 for most requirements。

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

最后，我希望您已经看到了http://antirez.com/post/mongodb - redis.html。

#2

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。

  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.

  MongoDB适合于黑客马拉松、初创公司，或者每次你不知道如何查询插入的数据。MongoDB并没有对您的基础架构做任何假设。虽然MongoDB是无模式的和非关系的，但这并不意味着根本就没有模式。它只是意味着您的模式需要在应用程序中定义(例如使用Mongoose)。除此之外，MongoDB很适合用于原型开发或尝试解决问题。它的性能不是很好，不能和Redis相比。

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

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

  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可以很容易地集成为LRU缓存。使用Redis作为一个独立的数据库系统是非常少见的(有些人更喜欢将它作为一个“键值”存储)。像Craigslist这样的网站在他们的主数据库旁边使用Redis。Antirez (Redis开发人员)演示了使用Lamernews，它确实可以使用Redis作为独立的数据库系统。

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

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

  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 really flexible. The underlying data structures it provides are the building blocks of high-performance DB systems.

  Redis提供了一组有用的数据结构(例如:set、散列、列表)，但是您必须显式地定义如何存储数据。简而言之，Redis和MongoDB可以用来实现类似的功能。Redis只是更快，但不适合原型开发。这是典型的MongoDB的用例。除此之外，Redis非常灵活。它提供的底层数据结构是高性能数据库系统的构建块。

When to use Redis?

• Caching

  缓存

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

  使用MongoDB进行高速缓存并没有什么意义。那就太慢了。

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

  如果你有足够的时间考虑你的DB设计。

  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.

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

• If you need really high 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 real database.

  Redis提供的性能测试几乎是不可能的。假设您的数据库和缓存一样快。这就是使用Redis作为真实数据库的感觉。

• If you don't care that much 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 that complicated, 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.

  调整Redis并不像以前那么困难。例如，您可以使用一种代理服务器来将数据分布到多个Redis实例中。主从复制不是那么复杂，但是在多个Redis-instances中分配您的密钥需要在应用程序站点上完成(例如，使用hash-function、Modulo等)。通过比较来扩展MongoDB要简单得多。

When to use 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.

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

• 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解决这个问题的方法不是对底层数据做大量的假设。然而，它尽可能地优化，而不需要您定义一个模式。

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.

如果性能很重要，并且愿意花时间优化和组织数据，那么使用Redis博士。-如果你需要构建一个原型而不用担心你的DB，那么就使用MongoDB。

Further reading:

进一步阅读:

• Interesting aspects to consider when using Redis as a primary data store
• 当使用Redis作为主要数据存储时，需要考虑一些有趣的方面。

#3

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.

复述。假设你写了一个php的网站;不管出于什么原因，它变得流行起来，而且它已经超过了它的时代，或者是它的porno。你意识到这个php的速度太慢了，“我要失去我的粉丝了，因为他们根本不会等上10秒钟。”您突然意识到web页面有一个常量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子句。这里的lastname = "thornton"和电影= "bad santa "。呃!。你会想，“那些dba为什么不做他们的工作，给我一些存储过程呢?”然后你忘记一些小领域middlename然后你必须删除的表,导出所有10 g的大数据和创建另一个新领域,并导入数据,继续在接下来的10倍14天为你继续记住废话喜欢称呼,标题,加上添加一个外键与地址。然后您会发现lastname应该是lastname。几乎每天都有一个变化。然后你说darnit。我必须写一个网站/系统，不要介意这些数据模型。所以你谷歌，“我讨厌写SQL，请不要SQL，让它停止”，但是弹出“nosql”，然后你读了一些东西，它说它只是转储没有任何模式的数据。你还记得上周的惨败给你留下了更多的桌子和微笑。然后你选择mongo，因为一些像“airbud”这样的大公司会使用它。甜的。没有更多的数据模型改变，因为你有一个模型，你只是不断地改变。

#4

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

#5

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 your needs.

您需要对它们进行测试，以确保它们满足您的需求。

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和内存，但肯定不是一个要求——特别是对于早期开发的目的。

#6

Redis is an in memory data 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 based data store, that is most efficient when it's working set fits 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都可以集中在高可用性、备份和增加数据存储的整体大小上。

#7

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 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。移动，它的值是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.

它还有一个包含多个索引的帐户数组。可以查询一个文档，其中的帐户包含一些值的子集，所有的值的子集，或任何一个值子集。这意味着你可以搜索帐户=["379-1111"，"379-2574"]，而不是找到上面的;您可以搜索帐户包括["379-1111"]并找到上述文件;你可以搜索账户，包括["974-3785"，"414-6731"]，然后找到上面的和任何文件包括"974-3785"，如果有的话。

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

你想要什么文件就去多少。PhoneNumber。Mobile可以持有一个数组，甚至一个子文档(PhoneNumber.Mobile)。工作和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 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 = 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.

最明显的失效案例是写的更新:如果您阅读了用户:Simon:lingots = NOTFOUND，您可以从Store的内部连接UserProfile u中选择lingots。用户id = u。UserID,u。用户名= Simon，并将结果存储为100，作为设置用户:Simon:lingots = 100。然后，当您授予Simon 5 lingots时，您会阅读用户:Simon:lingots = 100, SET user:Simon:lingots = 105，并更新存储的内部连接UserProfile u。用户id = u。用户id集合s。在哪里?用户名=西蒙。现在您的数据库中有105个，在Redis中，可以得到用户: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:

第二种情况是更新相关信息。假设您生成一个页面的块并缓存它们的输出。标题显示玩家的经验、水平和金额;玩家的个人资料页面有一个显示其统计信息的区块;等等。这个球员获得了一些经验。现在您有了几个模板:Header:Simon，模板: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:*:Simon out 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”)的结果，所以您必须删除模板:*: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是一个键值缓存，它与关系数据库或文档存储区不同。

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数据库或文档存储快得多。

#8

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.

如果你有足够的内存，你也应该使用。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。(或其他任何键值存储)。

#9

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是一个不错的选择。它具有可扩展的扩展策略。它使用磁盘作为存储介质，因此数据将被持久化。

#10

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具有集群功能。