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

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的类型当某些属性是数字而其他属性不是？）

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

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

Answer 2

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

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

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

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

Answer 3

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

使用SQL

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

使用Couchbase

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

底线

如果您拥有大量数据，那么您将很难找到SQL将在任何接近nosql数据库体系结构性能的情况下出现的情况，无论数据的结构如何或非结构化如何。