Схема для таблицы аналитики в 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 стандартной практикой в ​​таких системах или только в крайнем случае, когда исходная модель явно недостаточно масштабируема?

EDIT: конечная цель - нарисовать линейную диаграмму для пользователей. Таким образом, в основном запросы будут выбирать несколько показателей, складывать их по часам и выбирать min/max/avg per hour (или любой другой период времени).

EDIT: аргументы DBA являются:

1. Это актуально с 1 дня (см ниже), но даже если бы не было это то, что система в конечном итоге нужно будет делать и миграции из другой схемы будет боль

2. Уменьшение количества раз рядов X500 позволит более эффективные индексы и памяти (таблица будет содержать сотни миллионов строк перед этой оптимизации)

3. При выборе множественным меня шегося предложенная схема позволит за один проход над данными вместо отдельного запроса для каждой метрики (или некоторые сложные комбинации OR и GroupBy)

EDIT: 500 метрик является «верхней границы», но на практике большинство из время только ~ 40 метрики представлены на 5 секунд (не то же самое 40, хотя)

Answer 1

предложение АБД не Totally неразумные если метрики справедливо фиксирована, и имеет смысл группировать вместе. Несколько проблем вы, вероятно, столкнуться, хотя:

• 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, который по-прежнему является достаточно новым.