为什么关系型数据库不适合非结构化数据？

Question

为什么关系型数据库不适合非结构化数据？

sqldatabasenosqlrelational-database

7

我一直在研究NoSQL数据库，一个常见的主题是关系型数据库不适合存储非结构化数据。例如：

“不幸的是，关系型数据库使用的严格定义、基于模式的方法对于非结构化和半结构化数据来说并不合适[来源]。”

我很难理解这是为什么。例如，如果我想在关系型数据库中存储图像或一些原始文本，我不能只将其存储为文本类型（例如，在单列表或键值表中）吗？

- user3187713

5

非结构化数据不是图像或文本文件，它是一组数据，其中一个记录看起来与另一个记录不同。结构化数据假定记录之间存在共同字段，添加图像字段或文本字段没关系，它仍然只是一个字段。搜索文本变得棘手，但是可行...非结构化数据可能是对问题的逐字文本答案序列，您可能希望搜索常见模式（有多少人作出积极回应）。这种类型的搜索并不是SQL的强项。 - Sparky

3个回答

6

该问题似乎基于两到三个误解，不幸的是，这些误解在流行的NoSQL产品的爱好者中都非常普遍。首先，“信息”（而不是“数据”）永远不会真正无结构，结构是我们查看数据以查看信息的镜头，也是数据有用的原因。其次，常见的这种数据示例（文档、图像、混合内容）非常适合以关系形式存储。第三，SQL！= 关系。 NoSQL产品的理论基础是需要替代SQL，这毋庸置疑。不幸的是，NoSQL支持者往往基于这样一个误解来构建他们的思想，即SQL DBMS的问题和限制是数据关系模型固有的问题，这完全不正确。可以强烈地认为，最好的NoSQL DBMS类型将是一种“关系型”的DBMS。

- nvogel

非常周到的评论。对于非结构化数据库还不熟悉。我同意“信息（而不是‘数据’）永远不会真正无结构”。然而，我逐渐意识到，在数据生成时很难为其分配一个结构。这可能需要很长时间才能演变出结构。如果唯一的选择是结构化数据库，那么唯一的选择就是要么丢弃数据，要么将其存储为平面文件。 - alpha_989

另一方面，如果我们有非结构化数据库，可以处理在输入到数据库时没有任何结构的数据，也许将来有人可以找出要分配给该数据的结构（并提取数据中包含的“信息”），这将为收集数据的业务增加价值。你不同意吗？ - alpha_989

5

我认为问题不应该是结构化与非结构化数据之间的选择。而是针对大量数据的性能问题。我曾尝试将SQL数据库转换成非结构化数据存储，因为我的动态（JSON）对象需要放入表中，这些对象通过父子关系彼此相关联（即自连接）。在测试数据集约为5000个对象时，使用SQL工作得很好。

然而，我的生产数据库包含约3GB的数据（大约100万个对象左右）。我花了几周时间构建和优化SQL连接和查询。我能够实现最大约10ms的性能，以从树中选定的位置返回一些节点。然后，我遇到了奇怪的查询性能问题，只有通过重新构建索引和/或删除并重新创建存储过程才能解决。我花费的时间维护SQL数据库与编写应用程序的时间一样多。这不好。（哦，我应该提到我有大约3年的SQL Server DBA实践经验，所以我绝不是新手）。

相比之下，使用Couchbase。

快进18个月。我现在正在使用流行的nosql数据库Couchbase。通过使用视图和map/reduce，我能够从CB获得相同的功能。我花了一周时间使我的CB部署运行起来。查询查找的延迟为亚毫秒级别。最终用户注意到性能显著提高。

底线是，如果您有大量数据，无论数据结构化还是非结构化，都很难找到SQL可以接近nosql数据库体系结构性能的情况。

- theMayer

感谢分享您的经验！您是否将数据库分布在多台机器上？我的理解是，MapReduce 在单台机器上效率很低。 - user3187713

MapReduce/Hadoop主要用于大量数据的处理。如果你可以将数据放入单台机器中，可能其他架构更加有用。 - alpha_989

啊，架构是实用性的函数，而不一定是大小。 - theMayer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Philipp · Accepted Answer

我最喜欢的非结构化数据示例之一，它不适合关系型数据库的是计算机硬件零件数据库。

想象你有一个销售计算机硬件的网店。你的产品数据库会是什么样子呢？

每个产品都有一个名称、一个价格和一个供应商。但是CPU有一个时钟频率、一个缓存大小和一个核心数，显示器有一个尺寸和分辨率，RAM模块有一个容量，硬盘也有一个容量（不能与RAM模块的相比较）。

你会如何在关系型数据库中存储这些数据？

你可以创建一个非常宽的表格，拥有数百个字段，以适应某些产品可能具有的任何可能属性，但对于大多数产品，这些字段中的大多数将为空。
你可以为每个产品类别建立一个单独的表格。
你可以拥有一个巨大的表格，其中包含产品、属性和值列，将所有属性映射到值上（但当某些属性是数字和其他属性不是时，你要使用什么类型来表示值？）

这三个选项都是有效的，但没有一个真正令人满意。

但是，当你拥有一种无严格模式的面向文档的数据库时，它会变得更加简单，因为每个条目都可以具有任何属性集合，这些属性可以具有任何类型的值。