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

Question

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

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

我很难理解为什么会这样.例如,如果我想在关系数据库中存储图像或原始文本,我是否可以将其存储为文本类型(例如,在单个列表或键值表中)？

Answer 1

我最喜欢的非结构化数据的例子是计算机硬件部件数据库,它不适合关系数据库.

想象一下,你有一个销售计算机硬件的网店.您的产品数据库看起来如何？

每个产品都有a name,a price和a vendor.但CPU有一个clock rate,一个cache size和一个# of cores,监视器有一个size和resolution,RAM模块有一个capacity和硬盘驱动器也有一个capacity(这是无法与RAM模块相比).

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

• 您可以为一些产品可能具有的任何可能属性创建一个包含数百个字段的非常宽的表,但对于大多数产品,大多数这些字段将为NULL.
• 您可以为每个产品类别设置单独的表
• 您可以拥有一个包含列的大表product,property并将value所有属性映射到值(但是value当某些属性是数字而其他属性不是？时,您使用什么类型？)

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

但是当你有一个没有严格模式的面向文档的数据库时,它变得更加简单,因为每个条目都可以有任何属性集,可以包含任何类型的值.

Answer 2

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

使用 SQL

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

使用 Couchbase

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

底线

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

Answer 3

这个问题似乎是基于两三个误解.不幸的是,他们在时尚的NoSQL产品爱好者中非常普遍.

首先,信息(不是"数据")永远不是真正的非结构化.结构是我们通过其查看数据以查看信息的镜头.结构是数据有用的原因.

其次,这些数据(文档,图像,混合内容)的常用例子是非常适合以关系形式存储的候选者.

第三,SQL!=关系.NoSQL产品的基本原理是需要SQL的替代品.这是毋庸置疑的.不幸的是,NoSQL倡导者倾向于将他们的想法建立在一种误解上,即SQL DBMS的问题和局限性是数据关系模型中固有的问题.这不是真的.可以说,最好的NoSQL DBMS是关系型的.