mongodb 我什么时候应该使用 NoSQL 数据库而不是关系数据库？可以在同一个网站上使用吗？

When should I use a NoSQL database instead of a relational database? Is it okay to use both on the same site?

提问by smfoote

What are the advantages of using NoSQL databases? I've read a lot about them lately, but I'm still unsure why I would want to implement one, and under what circumstances I would want to use one.

使用 NoSQL 数据库的优势是什么？我最近阅读了很多关于它们的内容，但我仍然不确定为什么要实现一个，以及在什么情况下我想使用一个。

采纳答案by RameshVel

Relational databases enforces ACID. So, you will have schema based transaction oriented data stores. It's proven and suitable for 99% of the real world applications. You can practically do anything with relational databases.

关系数据库强制执行ACID。因此，您将拥有基于架构的面向事务的数据存储。它已被证明适用于 99% 的现实世界应用程序。您实际上可以对关系数据库做任何事情。

But, there are limitations on speed and scaling when it comes to massive high availability data stores. For example, Google and Amazon have terabytes of data stored in big data centers. Querying and inserting is not performant in these scenarios because of the blocking/schema/transaction nature of the RDBMs. That's the reason they have implemented their own databases (actually, key-value stores) for massive performance gain and scalability.

但是，在涉及海量高可用性数据存储时，速度和扩展性存在限制。例如，谷歌和亚马逊在大数据中心存储了数 TB 的数据。由于 RDBM 的阻塞/模式/事务性质，查询和插入在这些场景中性能不佳。这就是他们实施自己的数据库（实际上是键值存储）以获得大量性能增益和可扩展性的原因。

NoSQL databases have been around for a long time - just the term is new. Some examples are graph, object, column, XML and document databases.

NoSQL 数据库已经存在很长时间了——只是这个术语是新的。一些示例是图形、对象、列、XML 和文档数据库。

For your 2nd question:Is it okay to use both on the same site?

对于您的第二个问题：可以在同一个站点上同时使用两者吗？

Why not? Both serves different purposes right?

为什么不？两者都有不同的用途，对吗？

回答by Asaf

NoSQL solutions are usually meant to solve a problem that relational databases are either not well suited for, too expensive to use (like Oracle) or require you to implement something that breaks the relational nature of your db anyway.

NoSQL 解决方案通常旨在解决关系数据库不适合、使用成本太高（如 Oracle）或要求您实施一些破坏数据库关系性质的问题。

Advantages are usually specific to your usage, but unless you have some sort of problem modeling your data in a RDBMS I see no reason why you would choose NoSQL.

优势通常取决于您的使用情况，但除非您在 RDBMS 中对数据建模时遇到某种问题，否则我认为您没有理由选择 NoSQL。

I myself use MongoDB and Riak for specific problems where a RDBMS is not a viable solution, for all other things I use MySQL (or SQLite for testing).

对于 RDBMS 不是可行解决方案的特定问题，我自己使用 MongoDB 和 Riak，对于我使用 MySQL（或 SQLite 进行测试）的所有其他问题。

If you needa NoSQL db you usually know about it, possible reasons are:

如果你需要一个你通常知道的 NoSQL 数据库，可能的原因是：

• client wants 99.999% availability on a high traffic site.
• your data makes no sense in SQL, you find yourself doing multiple JOIN queries for accessing some piece of information.
• you are breaking the relational model, you have CLOBs that store denormalized data and you generate external indexes to search that data.

• 客户希望在高流量站点上获得 99.999% 的可用性。
• 您的数据在 SQL 中毫无意义，您会发现自己执行多个 JOIN 查询以访问某些信息。
• 您正在打破关系模型，您拥有存储非规范化数据的 CLOB，并生成外部索引来搜索该数据。

If you don't need a NoSQL solution keep in mind that these solutions weren't meant as replacements for an RDBMS but rather as alternatives where the former fails and more importantly that they are relatively new as such they still have a lot of bugs and missing features.

如果您不需要 NoSQL 解决方案，请记住，这些解决方案并不是作为 RDBMS 的替代品，而是作为前者失败的替代品，更重要的是它们相对较新，因此它们仍然有很多错误和缺少功能。

Oh, and regarding the second question it is perfectly fine to use any technology in conjunction with another, so just to be complete from my experience MongoDB and MySQL work fine together as long as they aren't on the same machine

哦，关于第二个问题，将任何技术与另一种技术结合使用是完全没问题的，所以根据我的经验，MongoDB 和 MySQL 可以很好地协同工作，只要它们不在同一台机器上

回答by Despertar

Martin Fowler has an excellent videowhich gives a good explanation of NoSQL databases. The link goes straight to his reasons to use them, but the whole video contains good information.

Martin Fowler 有一个很好的视频，它很好地解释了 NoSQL 数据库。该链接直接指向他使用它们的原因，但整个视频包含了很好的信息。

1. You have large amounts of data - especially if you cannot fit it all on one physical server as NoSQL was designed to scale well.

2. Object-relational impedance mismatch- Your domain objects do not fit well in a relaitional database schema. NoSQL allows you to persist your data as documents (or graphs) which may map much more closely to your data model.

1. 您拥有大量数据 - 特别是如果您无法将所有数据都放在一台物理服务器上，因为 NoSQL 旨在很好地扩展。

2. 对象-关系阻抗不匹配- 您的域对象不适合关系数据库模式。NoSQL 允许您将数据保存为文档（或图形），这些文档（或图形）可以更紧密地映射到您的数据模型。

回答by Hrishikesh

NoSQL is database system where data is organised into the document (MongoDB), key-value pair (MemCache, Redis), graph structure form(Neo4J).

NoSQL 是将数据组织成文档（MongoDB）、键值对（MemCache、Redis）、图结构形式（Neo4J）的数据库系统。

Maybe here are possible questions and answer for "When to go for NoSQL":

也许这里是“何时使用 NoSQL”可能的问题和答案：

1. Require flexible schema or deal with tree like data?
   Generally, in agile development we start designing system without knowing all requirement in upfront, where later on throughout development database system may need accommodate frequent design changes, showcasing MVP (Minimal Viable product). Or you are dealing with data schema which is dynamic in nature. e.g. System logs, very precise example is AWS cloudwatch logs.

2. Data set is vast/big?
   Yes NoSQL database are the better candidate for applications where database needs to manage million or even billions of records without compromising over performance.

3. Trade off between scaling over consistency
   Unlike RDMS, NoSQL database may lose small data here and there(Note: probability is .x%), but its easy to scale in terms of performance. Example: This may good for storing people who are online in instant messaging app, tokens in db, logging web site traffic stats.

4. Performing Geolocation Operations: MongoDB hash rich support for doing GeoQuerying & Geolocation operations. I really loved this feature of MongoDB.

1. 需要灵活的模式或处理树状数据？
   通常，在敏捷开发中，我们在事先不知道所有需求的情况下开始设计系统，然后在整个开发过程中数据库系统可能需要适应频繁的设计更改，展示 MVP（最小可行产品）。或者您正在处理本质上是动态的数据模式。例如系统日志，非常精确的例子是 AWS cloudwatch 日志。

2. 数据集庞大/大？
   是的，NoSQL 数据库更适合那些需要在不影响性能的情况下管理数百万甚至数十亿条记录的应用程序。

3. 在扩展性与一致性之间的权衡
   与 RDMS 不同，NoSQL 数据库可能会在这里和那里丢失小数据（注意：概率为 .x%），但它在性能方面易于扩展。示例：这可能有助于在即时消息应用程序中存储在线人员、在 db 中存储令牌、记录网站流量统计信息。

4. 执行地理定位操作：MongoDB 散列丰富支持执行地理查询和地理定位操作。我真的很喜欢 MongoDB 的这个特性。

In nutshell, MongoDB is great fit for applications where you can store dynamic structured data at large scale.

简而言之，MongoDB 非常适合可以大规模存储动态结构化数据的应用程序。

回答by Stefan Prugg

Some essential information is missing to answer the question: Which use cases must the database be able to cover? Do complex analyses have to be performed from existing data (OLAP) or does the application have to be able to process many transactions (OLTP)? What is the data structure? That is far from the end of question time.

缺少一些基本信息来回答这个问题：数据库必须能够覆盖哪些用例？是否必须从现有数据 ( OLAP)执行复杂分析，或者应用程序是否必须能够处理许多事务 ( OLTP)？什么是数据结构？这离提问时间的结束还很远。

In my view, it is wrong to make technology decisions on the basis of bold buzzwords without knowing exactly what is behind them. NoSQL is often praised for its scalability. But you also have to know that horizontal scaling (over several nodes) also has its price and is not free. Then you have to deal with issues like eventual consistencyand define how to resolve data conflicts if they cannot be resolved at the database level. However, this applies to all distributed database systems.

在我看来，根据大胆的流行语做出技术决策而不确切知道它们背后是什么是错误的。NoSQL 经常因其可扩展性而受到称赞。但是您还必须知道水平扩展（在多个节点上）也有其价格并且不是免费的。然后，您必须处理诸如最终一致性之类的问题，并定义如果无法在数据库级别解决数据冲突，则如何解决这些冲突。但是，这适用于所有分布式数据库系统。

The joy of the developers with the word "schema less" at NoSQL is at the beginning also very big. This buzzword is quickly disenchanted after technical analysis, because it correctly does not require a schema when writing, but comes into play when reading. That is why it should correctly be "schema on read". It may be tempting to be able to write data at one's own discretion. But how do I deal with the situation if there is existing data but the new version of the application expects a different schema?

开发人员在 NoSQL 中用“schema less”这个词的喜悦在一开始也很大。这个流行语在经过技术分析后很快就被消解了，因为它在写作时不需要模式是正确的，但在阅读时会起作用。这就是为什么它应该正确地是“读取模式”。能够自行决定写入数据可能很诱人。但是，如果存在现有数据但应用程序的新版本需要不同的架构，我该如何处理？

The document model (as in MongoDB, for example) is not suitablefor data models where there are many relationships between the data. Joins have to be done on application level, which is additional effort and why should I program things that the database should do.

文档模型（例如在 MongoDB 中）不适用于数据之间存在许多关系的数据模型。连接必须在应用程序级别完成，这是额外的工作，为什么我应该编写数据库应该做的事情。

If you make the argument that Google and Amazon have developed their own databases because conventional RDBMS can no longer handle the flood of data, you can only say: You are not Google and Amazon. These companies are the spearhead, some 0.01% of scenarios where traditional databases are no longer suitable, but for the rest of the world they are.

如果你说谷歌和亚马逊开发了自己的数据库是因为传统的 RDBMS 无法处理海量的数据，你只能说：你不是谷歌和亚马逊。这些公司是先锋，传统数据库不再适用的场景中约有 0.01%，但对于世界其他地方它们却是。

What's not insignificant: SQLhas been around for over 40 years and millions of hours of development have gone into large systems such as Oracle or Microsoft SQL. This has to be achieved by some new databases. Sometimes it is also easier to find an SQL admin than someone for MongoDB. Which brings us to the question of maintenance and management. A subject that is not exactly sexy, but that is a part of the technology decision.

重要的是：SQL已经存在 40 多年，数百万小时的开发已经投入到大型系统中，例如 Oracle 或 Microsoft SQL。这必须通过一些新的数据库来实现。有时，寻找 SQL 管理员也比寻找 MongoDB 的人更容易。这就把我们带到了维护和管理的问题上。一个并不完全性感的主题，但这是技术决策的一部分。

回答by Jermin Bazazian

I came across this question while looking for convincing grounds to deviate from RDBMS design.

我在寻找偏离 RDBMS 设计的令人信服的理由时遇到了这个问题。

There is a great postby Julian Brown which sheds lights on constraints of distributed systems. The concept is called Brewer's CAP Theorem which in summary goes:

Julian Brown发表了一篇很棒的文章，它阐明了分布式系统的约束。这个概念被称为布鲁尔的 CAP 定理，总结起来就是：

The three requirements of distributed systems are : Consistency, Availability and Partition tolerance (CAP in short). But you can only have two of them at a time.

分布式系统的三个要求是：一致性、可用性和分区容错性（简称CAP）。但是你一次只能有两个。

And this is how I summarised it for myself:

这就是我为自己总结的方式：

You better go for NoSQL if Consistency is what you are sacrificing.

如果您要牺牲一致性，则最好选择 NoSQL。

回答by Alex Klaus

I designed and implemented solutions with NoSQL databases and here is my checkpoint list to make the decision to go with SQLor document-oriented NoSQL.

我使用 NoSQL 数据库设计并实现了解决方案，这里是我的检查点列表，用于决定使用SQL还是面向文档的 NoSQL。

DON'Ts

不要做

SQL is not obsolete and remains a better tool in some cases. It's hard to justify use of a document-oriented NoSQL when

SQL 并没有过时，在某些情况下仍然是更好的工具。在以下情况下很难证明使用面向文档的 NoSQL 是合理的

• Need OLAP/OLTP
• It's a small project / simple DB structure
• Need ad hoc queries
• Can't avoid immediate consistency
• Unclear requirements
• Lack of experienced developers

• 需要OLAP/OLTP
• 这是一个小项目/简单的数据库结构
• 需要临时查询
• 无法避免立即一致性
• 要求不明确
• 缺乏经验丰富的开发人员

DOs

DO

If you don't have those conditions or can mitigate them, then here are 2 reasons where you may benefit from NoSQL:

如果您没有这些条件或可以缓解它们，那么您可以从 NoSQL 中受益的两个原因：

• Need to run at scale
• Convenience of development (better integration with your tech stack, no need in ORM, etc.)

• 需要大规模运行
• 开发的便利性（更好地与您的技术堆栈集成，无需 ORM 等）

More info

更多信息

In my blog posts I explain the reasons in more details:

在我的博客文章中，我更详细地解释了原因：

• 7 reasons NOT to NoSQL
• 2 reasons to NoSQL

• 不使用 NoSQL 的 7 个理由
• 使用 NoSQL 的 2 个理由

Note:the above is applicable to document-oriented NoSQL only. There are other typesof NoSQL, which require other considerations.

注意：以上仅适用于面向文档的 NoSQL。还有其他类型的 NoSQL，需要其他考虑。