什么时候应该使用NoSQL数据库而不是关系数据库？可以在同一站点上同时使用两者吗？

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

关系数据库强制实施ACID。因此，您将拥有基于架构的面向事务的数据存储。它已被证明并适合99％的实际应用。您几乎可以使用关系数据库执行任何操作。

但是，在涉及大量高可用性数据存储时，速度和扩展方面存在限制。例如，Google和Amazon在大数据中心中存储了TB级的数据。由于RDBM的阻塞/架构/事务性质，在这些情况下查询和插入不起作用。这就是为什么他们实施自己的数据库（实际上是键值存储）以获取巨大的性能和可伸缩性的原因。

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

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

为什么不？两者都有不同的目的吧？

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

优势通常是特定于您的用法的，但是除非您在RDBMS中对数据建模有某种问题，否则我没有理由选择NoSQL。

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

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

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

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

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

Martin Fowler的精彩视频很好地解释了NoSQL数据库。链接直接说明了他使用它们的原因，但是整个视频都包含了很好的信息。

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

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

NoSQL是一种数据库系统，其中数据被组织成文档（MongoDB），键值对（MemCache，Redis），图结构形式（Neo4J）。

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

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

2. 数据集庞大/庞大？
   是的NoSQL数据库是需要在不影响性能的前提下管理数百万甚至数十亿条记录的应用程序的最佳选择。

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

4. 执行地理位置操作：MongoDB丰富的哈希支持，用于执行GeoQuerying和Geolocation操作。我真的很喜欢MongoDB的这一功能。

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

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

我认为，在大胆的流行语的基础上做出技术决策而不完全知道背后的含义是错误的。NoSQL的可伸缩性经常受到赞誉。但是您还必须知道，水平缩放（在多个节点上）也有其代价，而且不是免费的。然后，您必须处理最终一致性之类的问题，并定义如果无法在数据库级别解决数据冲突，如何解决数据冲突。但是，这适用于所有分布式数据库系统。

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

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

如果您认为Google和Amazon已经开发了自己的数据库，因为传统的RDBMS不再能够处理大量数据，那么您只能说：您不是Google和Amazon。这些公司是带头人，在传统数据库不再适合，但适用于世界其他地区的情况下，约占0.01％。

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

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

朱利安·布朗（Julian Brown）有一篇很棒的文章，阐明了分布式系统的约束。这个概念称为Brewer的CAP定理，概括而言：

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

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

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

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

不要

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

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

溶解氧

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

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

更多信息

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

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

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

处理大量读写操作

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

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

数据建模的灵活性

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

最终一致性强于一致性

当可以让我们放弃“强一致性”并且不需要事务时，最好选择NoSQL数据库。

像Twitter这样的社交网站就是一个很好的例子。当名人的推文爆炸时，每个人都喜欢并重新发布来自世界各地的推文。点赞次数短暂上升或下降有关系吗？

名人绝对不会在乎，如果系统在短时间内显示的计数为500万个250，而不是实际的500万个“喜欢”。

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

在他们达成共识之前，实体的价值是不一致的。不久之后，实体的价值最终将保持一致。这就是最终的一致性。

尽管不一致并不意味着存在任何类型的数据丢失。这只是意味着数据需要很短的时间才能通过海底互联网电缆在全球范围内传播，从而达成全球共识并变得一致。

我们一直都在经历这种行为。特别是在YouTube上。通常，您会看到一个视频，其中包含10次观看和15个顶。这怎么可能呢？

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

运行数据分析

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