NoSQL 与关系数据库与可能的混合

Question

我听说过更多关于 NoSQL 的信息，但还没有人向我解释如何使用它来代替关系数据库。

我读到它不能做到left joins，所以我试图弄清楚你如何能够使用这样的数据存储。从阅读中：Preserve Joins by code in MongoDB 似乎建议只是制作一个大表，就好像您已经在其上进行了联接一样。

如果上面的说法是真的，那么我可以看看它是如何使用的。但是我很好奇您将如何处理重复数据。作为规范化的概念，可以帮助您消除冗余并确保数据的一致性（例如，大小写、空格等轻微修改）...

我们只是为了可扩展的速度而牺牲了数据的一致性，还是我遗漏了什么？

编辑

我一直在做更多的挖掘工作，发现以下问题的答案有助于澄清我的理解：

• Why Google's BigTable referred as a NoSQL database?
• How do you track record relations in NoSQL?

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

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

1. 这让我想知道现实生活中何时使用 NoSQL 与何时不使用的例子？
2. 通过对数据进行非规范化，您应该能够解决关系数据库所做的所有相同问题......但是对于如何使用关系数据库对数据进行规范化，有一些规则。是否有规则可以帮助他们对数据进行非规范化以使用 NoSQL 解决方案？
3. 任何示例说明您何时可能需要考虑同时使用 NoSQL 解决方案和关系数据库？

Answer 1

MongoDB 能够拥有包含其他文档数组的文档。这解决了许多在理性数据库中存在关系的情况。

当一张发票有多个位置时，您不会将这些位置放入单独的集合中。您可以将它们嵌入为数组。

这让我想知道现实生活中何时使用 NoSQL 与何时不使用的例子？

有许多不同的 NoSQL 数据库，每一种都在设计时考虑了不同的用例。但是您将此问题标记为 MongoDB，所以我假设您特别指的是 MongoDB。

与关系数据库相比，MongoDB 有两个主要优势。

首先，它可以很好地扩展。

当数据库太慢或太大时，您可以通过创建集群或多个分片的副本集轻松添加更多服务器。这在大多数关系数据库中几乎没有效果。

第二，它允许异构数据。

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

它不能做什么？

作为一项相当新的技术，关于它的文献并不多。它周围的软件生态系统也不是很好。您可以获得的用于关系数据库的工具通常更加闪亮。

还有一些 MongoDB 不适合的用例。

• MongoDB 不执行 JOIN。当您的数据非常相关且非规范化时，它会适得其反，这可能是您产品的糟糕选择。但是你可能想看看像 Neo4j 这样的图形数据库，它比关系数据库更关注关系。 2016 年更新： MongoDB 3.2 现在通过 $lookup aggregation stage 提供了基本的 JOIN 支持，但与关系数据库和图形数据库相比，它的功能仍然非常有限。
• MongoDB 不执行事务。至少不是复杂的交易。某些只影响单个文档的操作可以保证是原子的，但是一旦您影响多个文档，您就不能保证中间不会发生其他查询并找到不一致的状态。
• MongoDB 不适合临时报告。它的数据挖掘选项受到严重限制。相当新的聚合函数有帮助，当你学会聪明地使用它时，MapReduce 也可以解决一些令人惊讶的复杂问题，但 SQL 通常有更好的工具来处理这样的事情。

通过对数据进行非规范化，您应该能够解决关系数据库所做的所有相同问题......但是对于如何使用关系数据库对数据进行规范化，有一些规则。是否有规则可以帮助他们对数据进行非规范化以使用 NoSQL 解决方案？

关系数据库已经存在了大约 40 年。他们的理论是计算机科学中一个经过充分研究的课题。有很多关于它们背后的理论的书籍。到目前为止，每个可以想象的极端情况都有一个按规定解决方案。

但另一方面，NoSQL 数据库是一项相当新的技术。我们仍在寻找最佳实践。最常见的建议是：“用你自己的头脑。想想最常执行的查询，并为它们优化你的数据架构。”

关于您何时可能考虑同时使用 NoSQL 解决方案和关系数据库的任何示例？

如果可能，我建议不要在同一产品中使用两种不同的数据库技术：

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

我只建议在满足您的要求时混合使用数据库技术，不这样做不仅会变得困难，而且在物理上是不可能的。否则，请选择并坚持下去。