NoSQL 与关系数据库与可能的混合
Posted
技术标签:
【中文标题】NoSQL 与关系数据库与可能的混合【英文标题】:NoSQL vs. Relational Databases vs. Possible Hybrid 【发布时间】:2013-10-29 05:35:49 【问题描述】:我听说过更多关于 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 应该用于特定的问题类型,如果你需要关系,你应该使用关系数据库。
但这会引发更多问题,例如:
-
这让我想知道现实生活中何时使用 NoSQL 与何时不使用的例子?
通过对数据进行非规范化,您应该能够解决关系数据库所做的所有相同问题......但是对于如何使用关系数据库对数据进行规范化,有一些规则。是否有规则可以帮助他们对数据进行非规范化以使用 NoSQL 解决方案?
任何示例说明您何时可能需要考虑同时使用 NoSQL 解决方案和关系数据库?
【问题讨论】:
NoSQL 不仅仅是 MongoDB。有一大堆新的数据库技术以完全不同的理念和用例分组在标签下,它们的共同点是它们与 SQL 数据库也有共同点。 【参考方案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 解决方案和关系数据库的任何示例?
如果可能,我建议不要在同一产品中使用两种不同的数据库技术:
维护和支持产品的任何人都必须熟悉这两种技术 故障排除变得更加困难 系统管理员需要保持额外的数据库运行和更新 您还有一个可能导致停机的额外故障点我只建议在满足您的要求时混合使用数据库技术,不这样做不仅会变得困难,而且在物理上是不可能的。否则,请选择并坚持下去。
【讨论】:
以上是关于NoSQL 与关系数据库与可能的混合的主要内容,如果未能解决你的问题,请参考以下文章