关系数据库强制执行ACID。因此，您将拥有基于模式的面向事务的数据存储。它被证明适用于99%的现实世界应用程序。您几乎可以使用关系数据库执行任何操作。

但是，当涉及到海量高可用性数据存储时，速度和可伸缩性都受到限制。例如，谷歌和亚马逊在大型数据中心存储了数兆字节的数据。由于RDBMS的阻塞/模式/事务性质，查询和插入在这些场景中无法执行。这就是他们实现自己的数据库(实际上是键值存储)以获得巨大性能和可伸缩性的原因。

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

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

为什么不行？两者都有不同的目的，对吗？

NoSQL解决方案通常旨在解决关系数据库不太适合、使用成本太高(如Oracle)的问题，或者要求您实现一些破坏数据库的关系本质的东西。

优势通常是您的使用所特有的，但是除非您在RDBMS中对数据建模有一些问题，否则我认为您没有理由选择NoSQL。

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

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

• 客户希望在高流量站点上实现99.999的可用性。
• 您的数据在SQL中没有意义，您发现自己在为访问某条信息而执行多个连接查询。
• 您正在破坏关系模型，您有存储非规范化数据的CLOB，并且您生成外部索引来搜索该数据。

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

哦，关于第二个问题，将任何一种技术与另一种技术结合使用是非常好的，所以从我的经验来看，只要MongoDB和MySQL不在同一台机器上，它们就可以很好地一起工作

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

1.您拥有大量数据--尤其是在一台物理服务器上无法容纳所有数据的情况下，因为NoSQL的设计具有良好的伸缩性。
1.Object-relational impedance mismatch-您的域对象不适合关系数据库架构。NoSQL允许您将数据持久化为文档(或图形)，这可能会更紧密地Map到您的数据模型。

NoSQL是一个数据库系统，其中数据被组织成文档(MongoDB)、键-值对(Memcache，Redis)和图形结构形式(Neo4J)。

也许有一些可能的问题和答案，比如什么时候去买NoSQL：

1.需要灵活的模式或处理树状数据？
通常，在敏捷开发中，我们在预先不知道所有需求的情况下开始设计系统，而在以后的整个开发数据库系统中，可能需要适应频繁的设计更改，展示MVP(最小可行产品)。或者您正在处理本质上是动态的数据模式。例如系统日志，非常精确的例子是AWS云跟踪日志。
1.数据集庞大/庞大？
是的，对于这样的应用程序，NoSQL数据库是更好的选择，这些应用程序需要管理数百万甚至数十亿条记录，而不会影响性能和可用性(尽管现代数据库在这里是个例外，因为它允许在可用性上保持可调的一致性，例如Casandra、云提供商数据库CosmosDB、DynamoDB)。
1.在可伸缩性与一致性之间进行权衡
与RDM不同，NoSQL数据库可能最终会使数据集在其他节点上保持一致，这是默认行为，但它很容易在性能和可用性方面进行扩展。例如：这对于在即时消息应用程序中存储在线人员、在数据库中存储API令牌以及记录网站流量统计数据可能很有帮助。
1.地理定位操作：MongoDB Hash丰富支持地理查询和地理定位操作。我真的很喜欢MongoDB的这个特性。PostressSQL也是如此，但实现的简易性取决于用例

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

编辑：更新了关于数据库一致性的答案。

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

在我看来，在不知道背后到底是什么的情况下，根据大胆的流行语做出技术决策是错误的。NoSQL经常因其可伸缩性而受到赞扬。但您还必须知道，水平扩展(跨多个节点)也是有代价的，而且不是免费的。然后，您必须处理eventual consistency之类的问题，并定义在无法在数据库级别解决数据冲突时如何解决它们。但是，这适用于所有分布式数据库系统。

在NoSql用“无模式”一词开发的开发者joy一开始也很大。经过技术分析后，这个流行语很快就不再有吸引力，因为它在写作时正确地不需要图式，但在阅读时起作用。这就是为什么应该正确地将其设置为“读取时架构”。能够自行决定写入数据可能很有诱惑力。但是，如果存在现有数据，但新版本的应用程序需要不同的模式，我该如何处理这种情况呢？

文档模型(例如，在MongoDB中)是数据模型的not suitable，其中数据之间存在许多关系。连接必须在应用程序级别上完成，这是额外的工作，为什么我要编程数据库应该做的事情。

如果你认为谷歌和亚马逊开发了自己的数据库，是因为传统的RDBMS不再能处理海量的数据，你只能说：你不是谷歌和亚马逊。这些公司是先锋，在传统数据库不再适用的情况下，大约0.01%的情况下，但对世界其他地区来说，它们是适用的。

重要的是：SQL已经存在了40多年，在Oracle或Microsoft SQL等大型系统中花费了数百万小时的开发时间。这必须通过一些新的数据库来实现。有时，找到一个SQL管理员比找一个MongoDB管理员更容易。这就带来了维护和管理的问题。这是一个不太吸引人的主题，但这是技术决策的一部分。

处理大量读写操作

当您需要快速扩展时，请考虑使用NoSQL数据库。您通常需要在什么时候快速扩展？

当您的网站上有大量读写操作时，当处理大量数据时，NoSQL数据库最适合这些场景。由于它们能够动态添加节点，因此可以以最小的延迟处理更多的并发流量和海量数据。

数据建模的灵活性

第二个提示是在开发的初始阶段，当您对数据模型、数据库设计不确定时，事情预计会以快速的速度变化。NoSQL数据库为我们提供了更大的灵活性。

最终一致性胜过强一致性

当我们可以放弃强一致性并且不需要事务时，选择NoSQL数据库是更可取的。

一个很好的例子是像Twitter这样的社交网站。当一条名人的推文被炸开，每个人都在点赞，并从世界各地转发它时。点赞数量在短时间内略有上升或下降有关系吗？

这位名人肯定不会在意，如果系统在短时间内将点赞数显示为5250个，而不是实际的5500个赞。

当一个大型应用程序部署在遍布全球的数百台服务器上时，地理上分布的节点需要一些时间才能达成全球共识。

在他们达成共识之前，实体的价值是不一致的。实体的价值在一小段时间后最终变得一致。这就是最终的一致性。

尽管不一致并不意味着存在任何形式的数据丢失。这只是意味着，数据需要很短的时间通过海底的网线在全球范围内传输，以达成全球共识并变得一致。

我们一直都在经历这种行为。尤其是在YouTube上。通常你会看到一段视频有10次观看和15个赞。这怎么可能呢？

不是的。实际的观点已经超过了喜欢的人。这只是点击量不一致，需要很短的时间才能更新。

运行数据分析

NoSQL数据库也最适合数据分析用例，在这些用例中我们必须处理大量涌入的数据。

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

Julian Brown写了一本很好的post，它揭示了分布式系统的约束。这个概念被称为布鲁尔的CAP定理，概括起来就是：
分布式系统的三个要求是：一致性、可用性和分区容错(CAP)。但你一次只能吃两个。

我是这样总结自己的：

如果一致性是您要牺牲的，那么您最好选择NoSQL。

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

不能

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

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

拒绝服务

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

• 需要规模化运行
• 开发方便(与您的技术堆栈更好地集成，不需要ORM等)

更多信息

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

• 7 reasons NOT to NoSQL

• 2 reasons to NoSQL

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