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

Question

我听到了更多关于 NoSQL 的消息，但还没有人给我一个关于如何使用它而不是关系数据库的清晰解释。

我读过它不能做 left joins ，所以我试图弄清楚如何使用这样的数据存储。来自阅读:Preserve Joins by code in MongoDB似乎建议只制作一张大 table ，就好像您已经在上面进行了连接一样。

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

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

编辑

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

Why Google's BigTable referred as a NoSQL database?

How do you track record relations in NoSQL?

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

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

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

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

关于何时考虑将 NoSQL 解决方案与关系数据库并行使用的任何示例？

Answer 1

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

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

It makes me wonder about real life examples of when to use NoSQL versus when not to?

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

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

首先，它的伸缩性很好。

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

其次，它允许异构数据。

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

它不能做什么？

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

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

MongoDB 不执行 JOIN。当您的数据非常相关并且非规范化时，它会适得其反，这对您的产品来说可能是一个糟糕的选择。但是你可能想看看像 Neo4j 这样的图形数据库，它比关系数据库更关注关系。 2016 年更新: MongoDB 3.2 现在通过 $lookup aggregation stage 有了基本的 JOIN 支持，但与关系数据库和图形数据库相比，它的功能仍然非常有限。

MongoDB 不做交易。至少不是复杂的交易。某些仅影响单个文档的操作被保证是原子的，但是一旦您影响多个文档，您就不能保证在两者之间不会发生其他查询并发现不一致的状态。

MongoDB 不适合临时报告。它用于数据挖掘的选择受到严重限制。当您学会巧妙地使用 MapReduce 时，相当新的聚合函数会有所帮助，而且 MapReduce 还可以解决一些令人惊讶的复杂问题，但 SQL 通常具有更好的工具来解决此类问题。

By denormalizing the data, you should be able to solve all of the same problems that relational databases do... But there are rules on how to normalize data with relational databases. Are there rules that one can use to help them denormalize the data to use a NoSQL solution?

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

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

Any examples on when you might want to consider using both a NoSQL solution in parallel with a relational database?

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

任何维护和支持产品的人都必须熟悉这两种技术

故障排除变得更加困难

系统管理员需要保持一个额外的数据库运行和更新

您还有一个可能导致停机的额外故障点

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