MySQL 何时使用 MongoDB 或其他面向文档的数据库系统？

When to use MongoDB or other document oriented database systems?

提问by aurora

We offer a platform for video- and audio-clips, photos and vector-grafics. We started with MySQL as the database backend and recently included MongoDBfor storing all meta-information of the files, because MongoDB better fits the requirements. For example: photos may have Exifinformation, videos may have audio-tracks where we to want to store the meta-information of, too. Videos and vector-graphics don't share any common meta-information, etc. so I know, that MongoDB is perfect to store this unstructured data and keep it searchable.

我们为视频和音频剪辑、照片和矢量图提供了一个平台。我们开始使用 MySQL 作为数据库后端，最近加入了MongoDB来存储文件的所有元信息，因为 MongoDB 更符合要求。例如：照片可能有Exif信息，视频可能有我们想要存储元信息的音轨。视频和矢量图不共享任何常见的元信息等。所以我知道，MongoDB 非常适合存储这种非结构化数据并使其可搜索。

However, we continue developing our platform and adding features. Now one of the next steps will be providing a forum for our users. The question that now arises is: use the MySQL database, which would be a good choice for storing forums and forum-posts, etc. or use MongoDB for this, too?

但是，我们会继续开发我们的平台并添加功能。现在下一步将是为我们的用户提供一个论坛。现在出现的问题是：使用 MySQL 数据库，这将是存储论坛和论坛帖子等的不错选择，还是也使用 MongoDB？

So the question is: when to use MongoDB and when to use a RDBMS. What would you take, mongoDB or MySQL, if you had the choice and why would you take it?

所以问题是：何时使用 MongoDB，何时使用 RDBMS。如果可以选择，你会选择 mongoDB 还是 MySQL？为什么要选择它？

回答by Pascal Thivent

In NoSQL: If Only It Was That Easy, the author writes about MongoDB:

在NoSQL: If Only It Was That Easy 中，作者写了关于 MongoDB 的文章：

MongoDB is not a key/value store, it's quite a bit more. It's definitely not a RDBMS either. I haven't used MongoDB in production, but I have used it a little building a test app and it is a very cool piece of kit. It seems to be very performant and either has, or will have soon, fault tolerance and auto-sharding (aka it will scale). I think Mongo might be the closest thing to a RDBMS replacement that I've seen so far. It won't work for all data sets and access patterns, but it's built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don't do any joins (you're just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.

MongoDB 不是键/值存储，它更多。它也绝对不是 RDBMS。我没有在生产中使用过 MongoDB，但我已经使用它构建了一个测试应用程序，它是一个非常酷的工具包。它似乎非常高效，并且具有或即将具有容错和自动分片（也就是它会扩展）。我认为 Mongo 可能是迄今为止我见过的最接近 RDBMS 替代品的东西。它不适用于所有数据集和访问模式，但它是为典型的 CRUD 内容而构建的。大多数人使用关系数据库来存储本质上是一个巨大的哈希值，并能够选择任何这些键。如果您的数据库是 3NF 并且您没有进行任何连接（您只是选择一堆表并将所有对象放在一起，也就是大多数人在 Web 应用程序中所做的），MongoDB 可能会为您服务。

Then, in the conclusion:

然后，在结论中：

The real thing to point out is that if you are being held back from making something super awesome because you can't choose a database, you are doing it wrong.If you know mysql, just use it. Optimize when you actually need to. Use it like a k/v store, use it like a rdbms, but for god sake, build your killer app! None of this will matter to most apps. Facebook still uses MySQL, a lot. Wikipedia uses MySQL, a lot. FriendFeed uses MySQL, a lot. NoSQL is a great tool, but it's certainly not going to be your competitive edge, it's not going to make your app hot, and most of all, your users won't care about any of this.

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I'll start hacking on Maglev. I'll use whatever is best for the job.If I need reporting, I won't be using any NoSQL.If I need caching, I'll probably use Tokyo Tyrant. If I need ACIDity, I won't use NoSQL.If I need a ton of counters, I'll use Redis. If I need transactions, I'll use Postgres.If I have a ton of a single type of documents, I'll probably use Mongo.If I need to write 1 billion objects a day, I'd probably use Voldemort. If I need full text search, I'd probably use Solr. If I need full text search of volatile data, I'd probably use Sphinx.

真正要指出的是，如果您因为无法选择数据库而无法制作超级棒的东西，那您就做错了。如果你知道mysql，就用它。在您真正需要时进行优化。像 ak/v 商店一样使用它，像 rdbms 一样使用它，但看在上帝的份上，构建你的杀手级应用程序！对于大多数应用程序而言，这些都无关紧要。Facebook 仍然大量使用 MySQL。维基百科大量使用 MySQL。FriendFeed 大量使用 MySQL。NoSQL 是一个很棒的工具，但它肯定不会成为您的竞争优势，不会让您的应用程序变得热门，而且最重要的是，您的用户不会关心这些。

我将在什么基础上构建我的下一个应用程序？可能是Postgres。我会使用 NoSQL 吗？也许。我可能还会使用 Hadoop 和 Hive。我可能会将所有内容都保存在平面文件中。也许我会开始对 Maglev 进行黑客攻击。我会使用最适合这份工作的任何东西。如果我需要报告，我不会使用任何 NoSQL。如果我需要缓存，我可能会使用东京暴君。如果我需要 ACIDity，我不会使用 NoSQL。如果我需要大量计数器，我将使用 Redis。如果我需要交易，我会使用 Postgres。如果我有大量单一类型的文档，我可能会使用 Mongo。如果我每天需要写 10 亿个对象，我可能会使用 Voldemort。如果我需要全文搜索，我可能会使用 Solr。如果我需要对易失性数据进行全文搜索，我可能会使用 Sphinx。

I like this article, I find it very informative, it gives a good overview of the NoSQL landscape and hype. But, and that's the most important part, it really helps to ask yourself the right questions when it comes to choose between RDBMS and NoSQL. Worth the read IMHO.

我喜欢这篇文章，我觉得它信息量很大，它很好地概述了 NoSQL 的前景和炒作。但是，这是最重要的部分，在 RDBMS 和 NoSQL 之间进行选择时，问自己正确的问题确实很有帮助。值得一读恕我直言。

Alternate link to article

文章的备用链接

回答by Marquez

After two years using MongoDb for a social app, I have witnessed what it really means to live without a SQL RDBMS.

在将 MongoDb 用于社交应用程序两年后，我亲眼目睹了没有 SQL RDBMS 的生活真正意味着什么。

1. You end up writing jobs to do things like joining data from different tables/collections, something that an RDBMS would do for you automatically.
2. Your query capabilities with NoSQL are drastically crippled. MongoDb may be the closest thing to SQL but it is still extremely far behind. Trust me. SQL queries are super intuitive, flexible and powerful. MongoDb queries are not.
3. MongoDb queries can retrieve data from only one collection and take advantage of only one index. And MongoDb is probably one of the most flexible NoSQL databases. In many scenarios, this means more round-trips to the server to find related records. And then you start de-normalizing data - which means background jobs.
4. The fact that it is not a relational database means that you won't have (thought by some to be bad performing) foreign key constrains to ensure that your data is consistent. I assure you this is eventually going to create data inconsistencies in your database. Be prepared. Most likely you will start writing processes or checks to keep your database consistent, which will probably not perform better than letting the RDBMS do it for you.
5. Forget about mature frameworks like hibernate.

1. 您最终会编写作业来完成诸如连接来自不同表/集合的数据之类的事情，这是 RDBMS 会自动为您完成的事情。
2. 您使用 NoSQL 的查询能力严重受损。MongoDb 可能是最接近 SQL 的东西，但它仍然远远落后。相信我。SQL 查询非常直观、灵活且功能强大。MongoDb 查询不是。
3. MongoDb 查询只能从一个集合中检索数据，并且只能利用一个索引。而 MongoDb 可能是最灵活的 NoSQL 数据库之一。在许多情况下，这意味着需要更多的往返服务器以查找相关记录。然后你开始去规范化数据——这意味着后台作业。
4. 它不是关系数据库的事实意味着您将没有（被某些人认为性能不佳）外键约束来确保您的数据一致。我向您保证，这最终会在您的数据库中造成数据不一致。做好准备。很可能您将开始编写进程或检查以保持数据库的一致性，这可能不会比让 RDBMS 为您做更好的表现。
5. 忘记像 hibernate 这样的成熟框架。

I believe that 98% of all projects probably are way better with a typical SQL RDBMS than with NoSQL.

我相信 98% 的项目使用典型的 SQL RDBMS 可能比使用 NoSQL 好得多。

回答by RameshVel

to store this unstructured data

存储这些非结构化数据

As you said, MongoDB is best suitable to store unstructured data. And this can organize your data into document format. These RDBMS altenatives called NoSQLdata stores (MongoDB, CouchDB, Voldemort) are very useful for applications that scales massively and require faster data access from these big data stores.

正如您所说，MongoDB 最适合存储非结构化数据。这可以将您的数据组织成文档格式。这些称为NoSQL数据存储（MongoDB、CouchDB、Voldemort）的RDBMS 替代方案对于大规模扩展并需要从这些大数据存储中更快访问数据的应用程序非常有用。

And the implementation of these databases are simpler than the regular RDBMS. Since these are simple key-valued or document style binary objects directly serialized into disk. These data stores don't enforce the ACID properties, and any schemas. This doesn't provide any transactionabilities. So this can scale big and we can achieve faster access (both read and write).

并且这些数据库的实现比常规的 RDBMS 更简单。由于这些是直接序列化到磁盘中的简单键值或文档样式的二进制对象。这些数据存储不强制执行ACID 属性和任何模式。这不提供任何交易能力。所以这可以扩展，我们可以实现更快的访问（读取和写入）。

But in contrast, RDBM enforces ACID and schemas on datas. If you wanted to work with structured data you can go ahead with RDBM.

但相比之下，RDBM 对数据强制执行 ACID 和模式。如果您想处理结构化数据，您可以继续使用 RDBM。

I would choose MySQLfor creating forumsfor this kind of stuff. Because this is not going to scale big. And this is a very simple (common) application which has structured relations among the data.

我会选择MySQL来为这类东西创建论坛。因为这不会扩大规模。这是一个非常简单（常见）的应用程序，它在数据之间具有结构化的关系。

回答by Journeyman

Note that Mongo essentially stores JSON. If your app is dealing with a lot of JS Objects (with nesting) and you want to persist these objects then there is a very strong argument for using Mongo. It makes your DAL and MVC layers ultra thin, because they are not un-packaging all the JS object properties and trying to force-fit them into a structure (schema) that they don't naturally fit into.

请注意，Mongo 本质上存储 JSON。如果您的应用程序正在处理大量 JS 对象（带有嵌套）并且您想要持久化这些对象，那么使用 Mongo 是一个非常有力的论据。它使您的 DAL 和 MVC 层变得超薄，因为它们并没有将所有 JS 对象属性解包并试图将它们强制装入一个它们不自然适合的结构（模式）中。

We have a system that has several complex JS Objects at its heart, and we love Mongo because we can persist everything really, really easily. Our objects are also rather amorphous and unstructured, and Mongo soaks up that complication without blinking. We have a custom reporting layer that deciphers the amorphous data for human consumption, and that wasn't that difficult to develop.

我们有一个系统，它的核心是几个复杂的 JS 对象，我们喜欢 Mongo，因为我们可以非常非常轻松地持久化所有内容。我们的对象也相当无定形和非结构化，Mongo 不眨眼就吸收了这种复杂性。我们有一个自定义报告层，可以解密人类消费的无定形数据，开发起来并不难。

回答by mdirolf

I would say use an RDBMS if you need complex transactions. Otherwise I would go with MongoDB - more flexible to work with and you know it can scale when you need to. (I'm biased though - I work on the MongoDB project)

如果您需要复杂的事务，我会说使用 RDBMS。否则我会选择 MongoDB - 使用起来更灵活，你知道它可以在你需要时扩展。（虽然我有偏见 - 我在 MongoDB 项目上工作）

回答by Fred

Who needs distributed, sharded forums? Maybe Facebook, but unless you're creating a Facebook-competitor, just use Mysql, Postgres or whatever you are most comfortable with. If you want to try MongoDB, ok, but don't expect it to do magic for you. It'll have its quirks and general nastiness, just as everything else, as I'm sure you've already discovered if you really have been working on it already.

谁需要分布式、分片的论坛？也许是 Facebook，但除非您正在创建 Facebook 的竞争对手，否则只需使用 Mysql、Postgres 或任何您最喜欢的东西。如果你想尝试 MongoDB，好吧，但不要指望它为你做魔术。它会有它的怪癖和一般的肮脏，就像其他一切一样，我相信你已经发现如果你真的已经在研究它了。

Sure, MongoDB may be hyped and seem easy on the surface, but you'll run into problems which more mature products have already overcome. Don't be lured so easily, but rather wait until "nosql" matures, or dies.

当然，MongoDB 可能被大肆宣传，表面上看起来很简单，但您会遇到更成熟的产品已经克服的问题。不要那么容易被引诱，而是等到“nosql”成熟或死亡。

Personally, I think "nosql" will wither and die from fragmentation, as there are no set standards (almost by definition). So I will not personally bet on it for any long-term projects.

就个人而言，我认为“nosql”会因碎片化而消亡，因为没有固定的标准（几乎根据定义）。因此，我不会亲自为任何长期项目押注。

Only thing that can save "nosql" in my book, is if it can integrate into Ruby or similar languages seamlessly, and make the language "persistent", almost without any overhead in coding and design. That may come to pass, but I'll wait until then, not now, AND it needs to be more mature of course.

在我的书中，唯一可以节省“nosql”的是它是否可以无缝集成到 Ruby 或类似语言中，并使语言“持久化”，几乎没有任何编码和设计开销。这可能会实现，但我会等到那时，而不是现在，当然它需要更加成熟。

Btw, why are you creating a forum from scratch? There are tons of open source forums which can be tweaked to fit most requirements, unless you really are creating The Next Generation of Forums (which I doubt).

顺便说一句，你为什么要从头开始创建一个论坛？有大量的开源论坛可以调整以适应大多数需求，除非您真的在创建下一代论坛（我对此表示怀疑）。

回答by Kazuki Ohta

I've seen at lot of companies are using MongoDB for realtime analytics from application logs. Its schema-freeness really fits for application logs, where record schema tends to change time-to-time. Also, its Capped Collectionfeature is useful because it automatically purges old data to keep the data fit into the memory.

我看到很多公司都在使用 MongoDB 从应用程序日志中进行实时分析。它的无模式非常适合应用程序日志，其中记录模式往往会不时更改。此外，它的Capped Collection功能很有用，因为它会自动清除旧数据以保持数据适合内存。

That is one area I really think MongoDB fits for, but MySQL/PostgreSQL is more recommended in general. There're a lot of documentations and developer resources on the web, as well as their functionality and robustness.

这是我真正认为 MongoDB 适合的领域之一，但通常更推荐使用 MySQL/PostgreSQL。网络上有很多文档和开发人员资源，以及它们的功能和健壮性。

回答by Sushant Gupta

The 2 main reason why you might want to prefer Mongo are

您可能想要更喜欢 Mongo 的两个主要原因是

• Flexibility in schema design (JSON type document store).
• Scalability - Just add up nodes and it can scale horizontally quite well.

• 模式设计的灵活性（JSON 类型文档存储）。
• 可扩展性 - 只需添加节点，它就可以很好地水平扩展。

It is suitable for big data applications. RDBMS is not good for big data.

适用于大数据应用。RDBMS 不适合大数据。

回答by FYA

You know, all this stuff about the joins and the 'complex transactions' -- but it was Monty himself who, many years ago, explained away the "need" for COMMIT / ROLLBACK, saying that 'all that is done in the logic classes (and not the database) anyway' -- so it's the same thing all over again. What is needed is a dumb yet incredibly tidy and fast data storage/retrieval engine, for 99% of what the web apps do.

你知道，所有这些关于连接和“复杂事务”的东西——但是很多年前是蒙蒂自己解释了 COMMIT/ROLLBACK 的“需要”，说“所有这些都是在逻辑类中完成的” （而不是数据库）无论如何' - 所以它又是同样的事情。需要的是一个愚蠢但令人难以置信的整洁和快速的数据存储/检索引擎，用于 99% 的网络应用程序所做的事情。

回答by Adrien Hadj-Salah

Like said previously, you can choose between a lot of choices, take a look at all those choices: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

如前所述，您可以在很多选择之间进行选择，看看所有这些选择：http: //kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

What I suggest is to find your best combination: MySQL + Memcache is really great if you need ACID and you want to join some tables MongoDB + Redis is perfect for document store Neo4J is perfect for graph database

我的建议是找到你最好的组合：如果你需要 ACID 并且你想加入一些表，MySQL + Memcache 真的很棒 MongoDB + Redis 非常适合文档存储 Neo4J 非常适合图形数据库

What i do: I start with MySQl + Memcache because I'm use to, then I start using others database framework. In a single project, you can combine MySQL and MongoDB for instance !

我做什么：我从 MySQl + Memcache 开始，因为我习惯了，然后我开始使用其他数据库框架。例如，在单个项目中，您可以组合 MySQL 和 MongoDB！