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

Question

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

不幸的是，关系数据库使用的严格定义、基于模式的方法...不适合非结构化和半结构化数据 [source]

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

Answer 1

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

假设您有一家销售计算机硬件的网上商店。您的产品数据库看起来如何？

每个产品都有一个name、一个price 和一个vendor。但是CPU有clock rate、cache size和# of cores，监视器有size和resolution，RAM模块有capacity，硬盘也有capacity（不能与 RAM 模块相比）。

您将如何将这些数据存储在关系数据库中？

• 您可以为某些产品可能具有的任何可能属性创建一个包含数百个字段的非常宽的表，但对于大多数产品而言，这些字段中的大部分将为 NULL。
• 您可以为每个产品类别创建一个单独的表格
• 您可以有一个包含product、property 和value 列的巨大表，它将所有属性映射到值（但是当某些属性是数字而其他属性不是时，value 使用什么类型't?)

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

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

Answer 2

我认为问题不应该是非结构化数据与非结构化数据。它更多的是关于大量数据的性能。我有一些尝试将 SQL 数据库变成非结构化数据存储的经验。就我而言，我有一堆需要放入表中的动态 (JSON) 对象。我使用 SQL 是因为对象通过父子关系（即自联接）相互关联。它适用于大约 5,000 个对象的测试数据集。

使用 SQL

但是，我的生产数据库包含大约 3gb 的数据（大约 100 万个对象，给予或接受）。我花了数周时间构建和优化我的 sql 连接和查询。我能够实现大约 10 毫秒的最大性能，以从树中的选定位置返回几个节点。然后，我遇到了奇怪的查询性能问题，只能通过重新构建索引和/或删除并重新创建存储过程来解决。我花在维护该死的 SQL 数据库上的时间与编写应用程序其余部分的时间一样多。不好。 （哦，我应该提一下，我有大约 3 年的 SQL Server 实践 DBA 经验，所以我对这个游戏并不陌生。

使用 Couchbase

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

底线

如果您有大量数据，那么无论数据是结构化还是非结构化数据，您都很难找到 SQL 接近 nosql 数据库架构性能的情况。

Answer 3

这个问题似乎是基于两三个误解。不幸的是，它们在流行的 NoSQL 产品的爱好者中太常见了。

首先信息（不是“数据”）从来都不是真正的非结构化。结构是我们查看数据以查看信息的镜头。结构是数据有用的原因。

其次，此类数据（文档、图像、混合内容）的常用示例非常适合以关系形式存储。

第三，SQL != 关系。 NoSQL 产品的基本原理是需要 SQL 的替代品。这是毫无疑问的。不幸的是，NoSQL 的拥护者倾向于将他们的想法建立在一种误解之上，即 SQL DBMS 的问题和局限性是数据关系模型中固有的问题。远非如此。可以证明最好的 NoSQL DBMS 是一种关系型的。