Хранение данных по ценам на акции, ежедневно и еженедельно?

Question

Я сохраняю данные истории цен для 3500 различных акций с 1970 года по настоящее время (с заданием cron, которое обновляет его каждый день).

Каков наилучший способ хранения этих данных? Он будет использоваться для запуска расчетов на основе как ежедневных данных, так и еженедельных данных. В настоящее время я храню его как:

stock_id, date, closing_price, high, low, open, volume 

Так как я хочу еженедельную цену, как хорошо, я должен сделать отдельную таблицу для хранения:

stock_id, week_end_date, weekly_closing_price, weekly_high, weekly_low, week_open_price, average_daily_volume, total_weekly_volume 

Поскольку этого данные все вычисляемый из первой таблицы, является нужно снова хранить его? Единственная причина, по которой я это рассматриваю, заключается в том, что существует множество строк данных для выполнения расчетов .....

Answer 1

Это зависит от того, сколько данных у вас есть и если у вас есть другие ваши транзакционные требования.

Не имеет смысла дублировать эти данные в системе источника/OLTP, если таковая имеется. Я программист SQL Server, а не MySQL, но, я думаю, у них есть функции datepart, такие как все другие РСУБД, поэтому определение номера недели с даты тривиально.

Однако, когда вы получаете доступ к OLAP или отчету, вам может понадобиться сделать еще одну таблицу с данными на уровне детализации на уровне недели. Это сделает отчет намного быстрее, особенно для таких вещей, как агрегаты, которые обычно не работают хорошо, когда они работают против вывода функции.

Оба эти параметра зависят от масштаба ваших данных. Если у вас есть сотни строк в день, для этого может оказаться нецелесообразным делать материализованную еженедельную таблицу. Если у вас есть десятки тысяч записей в день, тогда преимущества производительности, вероятно, сделают это разумным вариантом.

Answer 2

Вы спрашиваете, если это необходимо? Кто знает. Это зависит от того, сколько дискового пространства у вас есть. Однако то, что вы описываете, представляет собой «старомодную» таблицу агрегации и часто используется для повышения эффективности отчетности. При работе с историческими данными нет необходимости пересчитывать такие вещи, как еженедельные итоги, поскольку данные не изменяются.

Фактически, если бы я делал это, я бы также определил «ежемесячные» и «годовые» сводные таблицы для большей гибкости, особенно для такой большой истории. Вы можете рассматривать «стандартизацию» данных таким образом, чтобы каждый период был сопоставим. Календарные месяцы и недели имеют разное количество торговых дней, поэтому такие вещи, как «средний дневной объем», могут вводить в заблуждение.

Если вы действительно хотите получить фантазию, сделайте некоторое исследование решений ROLAP. Это очень широкая тема, но вы можете найти ее полезной.

Answer 3

Поскольку эти данные исчисляются из первой таблицы, необходимо ли ее снова хранить?

Это не необходимо, чтобы суммировать и запомнить его. Вы можете просто создать представление, которое выполняет все итоговые вычисления, и запросить представление.

Если вы собираетесь многократно запускать отчеты по всему спектру данных, имеет смысл обобщить его один раз и сохранить результат. Вы начнете с 40 миллионов строк.(3500 акций * 43 года * около 265 дней в году)

Если бы я был на вашем месте, я бы загружал данные, записывал запрос на недельные цены и тестировал производительность. Если это слишком медленно, вставьте сводные данные в таблицу.