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. 减少行数x500次将允许更高效的索引和内存（在此优化之前，该表将包含数亿行）

3. 选择多个指标时，建议的架构将允许对数据进行一次传递，而不是针对每个指标（或OR和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，这仍然是相当新的。