NoSQL与关系型数据库与可能的混合方式对比

Question

我越来越多地听到NoSQL，但还没有人给我清晰的解释它如何替代关系型数据库。

我读过它不能做左连接，所以我试图弄清楚你如何能够使用这样的数据存储。通过阅读：在 MongoDB 中通过代码保留连接，似乎建议是只需制作一个大表格，就好像您已经在其中进行了连接。

如果上述陈述是正确的，那么我可以看出它如何被使用。然而，我很想知道如何处理重复数据。因为规范化的概念有助于消除冗余并确保数据的一致性（例如大小写，空格等的轻微修改）......

我们是否仅仅为了可扩展的速度而牺牲了数据的一致性，或者我漏掉了什么？

编辑

我进行了更深入的挖掘，并发现以下问题的答案对于澄清我的理解非常有用：

• 为什么谷歌的 BigTable 被称为 NoSQL 数据库？
• 如何在 NoSQL 中跟踪记录关系？

从这些答案中，我对一致性的理解似乎是正确的。看起来 NoSQL 应该用于特定类型的问题，如果需要关系，则应使用关系型数据库。

但这引发了更多问题，例如：

1. 这让我想到了什么时候使用 NoSQL 以及什么时候不使用的实际例子？
2. 通过去规范化数据，您应该能够解决关系型数据库所做的所有相同问题...但是有关如何规范化数据的规则与关系型数据库不同。是否有规则可供使用者帮助他们去规范化数据以使用 NoSQL 解决方案？
3. 何时考虑同时使用 NoSQL 解决方案和关系型数据库的示例？

- James Oravec

---

NoSQL不仅仅是MongoDB。在这个标签下，有许多新的数据库技术，它们有完全不同的哲学和用例，并且它们所共有的东西也与SQL数据库有共同之处。 - Philipp

Answer 1

MongoDB可以包含其他文档的数组，这解决了许多关系数据库中需要关联的情况。

当一张发票有多个条目时，您不会将这些条目放入单独的集合中。相反，您会将它们嵌入到一个数组中。

我想知道什么时候该使用NoSQL，什么时候不应该使用？

有很多不同的NoSQL数据库，每个都是为不同的用例而设计的。但您在标记此问题时使用了MongoDB，因此我认为您特别指的是MongoDB。

MongoDB比关系数据库具有两个主要优点。

首先，它具有良好的扩展性。

当数据库过慢或太大时，您可以通过创建多个分片的群集或副本集轻松添加更多服务器。这在大多数关系数据库中并不起作用。

其次，它允许异构数据。

例如，想象一下计算机硬件商店的产品数据库。产品有哪些属性？所有产品都有价格和供应商。但是CPU具有时钟频率，硬盘和RAM芯片具有容量（这些容量无法比较），显示器具有分辨率等。您会如何在关系数据库中设计这个？您要么创建一个非常长的productID-属性-值表，或者创建一个非常宽且稀疏的product表，其中包含您可以想象到的每个属性，但是大多数产品的大部分属性都为NULL。这两种解决方案都不是非常优雅。但是MongoDB可以更好地解决此问题，因为它允许集合中的每个文档具有不同的属性集。

它不能做什么？

作为一种比较新的技术，关于它的文献并不多。围绕它的软件生态系统也不是很好。您可以为关系数据库获得的工具通常更加亮眼。

还有一些用例不适合MongoDB。

• MongoDB不支持JOIN操作。当你的数据非常关联而且去规范化会适得其反时，MongoDB可能不是你产品的最佳选择。但你可以考虑看看像Neo4j这样更专注于关系比关系数据库的图数据库。更新2016年：MongoDB 3.2现在具有基本的JOIN支持，使用$lookup聚合阶段，但与关系和图数据库相比，其功能仍然非常有限。
• MongoDB不支持事务。至少不支持复杂事务。仅涉及单个文档的某些操作被保证是原子的，但一旦影响多个文档，就不能保证没有其他查询会出现在中间并找到一个不一致的状态。
• MongoDB不适用于自由报表。其数据挖掘选项严重受限。相当新的聚合函数可以帮助，MapReduce也可以在学会巧用后解决一些令人惊讶的复杂问题，但对于此类问题，SQL通常拥有更好的工具。

通过去规范化数据，您应该能够解决关系数据库所做的所有相同问题...但是使用关系数据库规范化数据有规则。有没有规则可用于帮助他们去规范化数据来使用NoSQL解决方案？

关系数据库已经存在了大约40年。它们的理论是计算机科学中一个研究得非常透彻的主题。整个图书馆里都写满了有关其背后理论的书籍。现在每个可以想象的特殊情况都有一本详解书。

但是，另一方面，NoSQL数据库是一项相当新的技术。我们仍在摸索最佳做法。最频繁的建议是："运用自己的头脑。考虑最常执行的查询，并为此优化数据模式。"

何时可以同时考虑使用关系数据库和NoSQL解决方案？

尽可能不建议在同一产品中使用两种不同的数据库技术：

• 任何维护和支持产品的人员都必须熟悉这两种技术
• 故障排除会变得更加困难
• 系统管理员需要保持另一个数据库的运行和更新
• 你有一个额外的故障点，可能导致停机时间

只有在需求不能仅用一种技术实现时，才建议混合使用数据库技术。否则，请选择一种并坚持使用。

- Philipp