Question

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

我可以构建数据库中的数据 - 为我收集的每个密钥都有一列。该表最终将是O（100）列宽，放入数据库会很痛苦，如果我开始收集新数据，我将不得不添加新列。但只使用SQL就可以很容易地对数据进行排序/分析。

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

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

Answer 1

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

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

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

Answer 2

我想

performance_data

        host_id
        key
        value
        timestamp

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

Answer 3

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

一个明显的架构设计将是cpuinfo，meminfo，loadavg等各自的表格。您可能最终得到一个miscellaneous_stats表，具体取决于您“包含在”其他一些东西中“。

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

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

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

我有两个基于这个提议的工作假设：

你要对这些数据做一些分析（因为如果你不打算分析它而又费心去收集它？）。
SQL仍然是数据处理的最佳机制，尽管平面文件工具一直在不断改进。

Answer 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

Answer 5

感谢您的建议。

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

我已经从这些原始数据中选择了一些我想要进行长期分析的统计数据，并且我将这些数据存储在一个宽表（很多列）中。这样我就可以轻松渲染趋势图并发现性能问题。

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

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

5 个答案:

performance_data