Postgres 中分析表的架构

Question

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

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

我们的 DBA 提出了一个建议，将相同 5 秒的所有报告扁平化为：

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

一些开发人员反驳说这增加了开发的巨大复杂性（批处理数据以便一次性编写）和可维护性（仅查看表格或添加字段更复杂）。

DBA 模型是此类系统中的标准做法，还是仅在原始模型明显不够可扩展时才采取的最后手段？

编辑：最终目标是为用户绘制折线图。所以查询主要是选择几个指标，按小时折叠它们，然后选择每小时（或任何其他时间段）的最小/最大/平均。

编辑：DBA 参数是：

1. 这与第 1 天相关（见下文），但即使这不是系统最终需要做的事情，从另一个架构迁移也会很痛苦

2. 将行数减少 500 倍将允许更高效的索引和内存（在此优化之前该表将包含数亿行）

3. When selecting multiple metrics the suggested schema will allow one pass over the data instead of separate query for each metric (or some complex combinations of OR and GroupBY)

编辑：500 个指标是“上限”，但实际上大多数时候每 5 秒只报告约 40 个指标（虽然不是相同的 40 个）

Answer 1

DBA 的建议并非完全不合理如果指标是相当固定的，并且组合在一起是有意义的。不过，您可能会遇到几个问题：

• Postgres has a limit of between 250 and 1,600 columns（取决于数据类型）
• 开发人员很难使用该表，尤其是当您经常只想查询属性的子集时
• 添加新列会很慢

相反，您可能要考虑使用 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，它还是相当新的。