3

我们使用 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 个）

4

1 回答 1

3

如果指标是相当固定的，那么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，它仍然是相当新的。

于 2013-11-10T23:53:51.077 回答