db中的结构化数据与非结构化数据

Question

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

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

或者我可以直接将我的非结构化数据blob转储到表中。可能有三列--主机id、时间戳和我的数组的序列化版本，可能在文本字段中使用JSON。

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

Answer 1

谢谢你的建议。

在进一步考虑这个问题之后，我决定采用两表方法。一个表保存了原始数据的最新转储，格式与我最初获取它的JSON格式相同。我使用它来显示最新的统计数据--最常见的用例--尝试解析出转储中的所有字段，然后在有人想要查看当前状态时重新组合它们，这是很愚蠢的。

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

根据我使用EAV的经验，我认为这不是一个好主意。它既不容易进行长期分析(40路连接或透视问题)，也不会因为我的数据不是平面的而更容易存储原始数据。

Answer 2

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

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

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

Answer 3

我认为

performance_data

        host_id
        key
        value
        timestamp

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