Postgres中用于分析表的模式

Question

3

我们使用Postgres进行分析（星型模式）。每隔几秒钟，我们会收到大约500个度量类型的报告。最简单的架构是：

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

我们的数据库管理员提出了一个建议，将所有相同5秒钟内的报告整合成一个：

timestamp   metric1     metric2     ...  metric500
78930890    90.9        20          ...

一些开发人员反对这种做法，认为这会增加开发的复杂性（批处理数据以便一次写入），并且会影响可维护性（仅查看表或添加字段更加复杂）。

在这样的系统中，DBA模型是标准实践吗？还是只有在原始模型明显不够可伸缩时才采用DBA模型？

编辑：最终目标是为用户绘制折线图。因此，查询大多数情况下将选择几个指标，按小时折叠，并选择每小时的最小值/最大值/平均值（或任何其他时间段）。

编辑：DBA的论点如下：

1.从第一天开始就很重要（见下文），但即使不是这样，系统最终也需要执行此操作，并且从另一个架构迁移将非常麻烦。

2.将行数减少500倍将允许更有效的索引和内存使用（在进行此优化之前，表将包含数亿行）。

3.当选择多个指标时，建议的架构将允许一次遍历数据而不是为每个指标选择单独的查询（或一些复杂的OR和GroupBY组合）。

编辑：500个指标是“上限”，但实际上大多数情况下，每5秒只报告约40个指标（尽管不是同样的40个）。

- user2976991

查询模式的作用是什么？为了将度量值相互比较，它们需要做多少工作才能在相同的时间戳下进行比较？ - David Aldridge

你的数据库管理员对这种（过早）去规范化的论点是什么？ - user948581

你的数据库管理员主张500个列？这似乎……对于一个数据库管理员来说有些不寻常。 - bma

所有 - 看一下刚才附上的详细信息 - user2976991

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David Wolever · Accepted Answer

如果度量标准相当固定且合理地分组在一起，DBA的建议并不完全不合理。但是你可能会面临以下几个问题：

相反，您可能需要考虑使用HSTORE列：

CREATE TABLE metrics (
    timestamp INTEGER,
    values HSTORE
)

这将使您在存储属性时具有一定的灵活性，并允许索引。例如，要仅索引其中一个指标：

CREATE INDEX metrics_metric3 ON metrics ((values->'metric3'))

这样做的一个缺点是，值只能是文本字符串...因此，如果您需要进行数字比较，可能也值得考虑使用JSON列：

CREATE TABLE metrics (
    timestamp INTEGER,
    values JSON
)
CREATE INDEX metrics_metric3 ON metrics ((values->'metric3'))

这里的缺点是您需要使用相对较新的Postgres 9.3。