数据库中的结构化数据与非结构化数据答案

【问题标题】：structured vs. unstructured data in db数据库中的结构化数据与非结构化数据
【发布时间】：2010-05-01 06:17:03
【问题描述】：

问题是设计问题之一。我正在收集大量具有大量键值对的性能数据。 /proc/cpuinfo、/proc/meminfo/、/proc/loadavg 中的几乎所有内容，以及来自数百台主机的一堆其他内容。现在，我只需要在我的 UI 中显示最新的数据块。我可能最终会对收集的数据进行一些分析，以找出未来的性能问题，但这是一个新应用程序，所以我不确定我到底在寻找什么性能方面的。

我可以在数据库中构造数据——我收集的每个键都有一个列。该表最终将是 O(100) 列宽，放入数据库会很痛苦，如果我开始收集新的统计信息，我将不得不添加新列。但仅使用 SQL 就可以轻松对数据进行排序/分析。

或者我可以将我的非结构化数据块转储到表中。可能是三列——主机 ID、时间戳和我的数组的序列化版本，可能在 TEXT 字段中使用 JSON。

我应该怎么做？如果我采用非结构化方法，我会后悔吗？在进行分析时，我是否应该只转换我感兴趣的字段并创建一个新的、更结构化的表？我在这里缺少哪些权衡？

【问题讨论】：

为什么不是一个有四列的表：host_id、key、value、timestamp？
我承认我什至没有考虑过 EAV 模式——我对它有一些经验，我发现做它经常需要的 30 路连接是，ahem，对性能有害。并试图避免 30 路连接会导致心理扭曲和丑陋的代码......
我问了一个有点相关的问题：stackoverflow.com/questions/2672178/…

标签： database database-design serialization structure

【解决方案1】：

我说如果您需要运行 SQL 查询来计算诸如 min/max/avg 之类的东西，或者根据这些值执行排序、限制或连接，那么您应该创建 100 多列。这就是我会做的。

您没有说明您使用的是哪个品牌的数据库，但大多数应该支持一个表中的 100 多列而不存在效率低下的风险。

请不要使用Entity-Attribute-Value 反模式——某些人会建议的键/值设计。将任意键/值对的任意集合插入到这样的设计中既好又容易，但是在每个属性一列的传统表中很容易执行的任何查询在 EAV 设计中变得异常困难和低效。您还会失去使用 SQL 数据库的许多优势，例如数据类型和约束。

【讨论】：

【解决方案2】：

我觉得

性能数据

        host_id
        key
        value
        timestamp

是正确的结构。您将能够在特定时间从特定主机查询特定子集以生成分析。

【讨论】：

在一段时间内为给定 HOST 生成（例如）meminfo 趋势报告将是一个可怕的转变。

【解决方案3】：

这是另一种解决方案：使用多个表。

一个明显的架构设计将是一个表，每个表用于cpuinfo、meminfo、loadavg 等。您最终可能会得到一个miscellaneous_stats 表，具体取决于您在“一堆其他东西”。

这种方法有几个吸引人的特点：

简化的列命名。
易于针对相关的统计数据子集进行报告，例如所有meminfo。性能也可能更好。
添加列的问题较少。如果您开始收集一个新的 cpuinfo 统计数据，它们都会聚集在一起，而在 One Big Yable 中，您最终会得到第 1-15 列和第 94 列。
记录的粒度。例如，您可能不想像meminfo 那样频繁地记录cpuinfo。

您应该有一个 stats_runs 的主表来保存 HOST、TIMESTAMP 等内容，而不是在每个表上复制这些详细信息。

我对这个提议有两个工作假设：

您要对这些数据进行一些分析（因为如果您不打算在收集数据的同时对其进行分析？）。
SQL 仍然是数据处理的最佳机制，尽管平面文件工具一直在改进。

【讨论】：

【解决方案4】：

http://blogs.technet.com/fort_sql/archive/2010/03/26/the-myth-of-unstructured-data.aspx

http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

【讨论】：

【解决方案5】：

感谢您的建议。

在考虑了这个问题之后，我决定采用双表方法。一个表包含原始数据的最新转储，采用与我最初获取它的 JSON 格式相同的格式。我使用它来显示最新的统计信息——最常见的用例——尝试解析会很愚蠢只在有人想查看当前状态时重新组合转储中的所有字段。

我已经从这些原始数据中挑选了一些我想对其进行长期分析的统计数据，并将它们存储在一个宽表（很多列）中。这将使我能够轻松地呈现趋势图并发现性能问题。

根据我使用 EAV 的经验，我认为这不是一个好主意。这使得进行长期分析（40 路 JOIN 或枢轴问题）既不容易，也因为我的数据不是平坦的，它会使存储原始数据变得更加容易。

【讨论】：