Как повторно использовать результаты со схемой для запасов на конец дня - PullRequest
Новая
       16

Как повторно использовать результаты со схемой для запасов на конец дня

1 голос
/ 21 марта 2010

Я создаю схему базы данных, которая будет использоваться для технического анализа, например, гейнеры с максимальным объемом, гейнеры с максимальной ценой и т. Д. Я проверил здесь ответы на вопросы, например вопрос разработки . Взяв подсказку из ответа boe100 , у меня есть схема, смоделированная в значительной степени, таким образом: 

Symbol -  char 6               //primary
Date -  date                   //primary 
Open -  decimal 18, 4
High -  decimal 18, 4
Low -  decimal 18, 4
Close -  decimal 18, 4
Volume -  int

Сейчас эта таблица, содержащая данные на конец дня (EOD), будет составлять около 3 миллионов строк за 3 года. Позже, когда я получу / мне нужно больше данных, это может быть 20 миллионов строк.

Передний конец будет задавать запросы типа «дайте мне максимальный выигрыш цены на дату X за Y дней». Этот запрос является одним из самых простых, и, как я полагаю, не слишком дорогостоящ, со временем.

Но такой запрос, как «дать мне наибольшую выгоду за последние 10 дней, а предыдущие 100 дней выступают в качестве базового уровня», может стоить в 10-100 раз дороже. Результатом такого запроса будет число с плавающей запятой, которое показывает, во сколько раз вырос объем и т. Д.

У меня есть один вариант - добавить столбец для каждого такого результата. И если пользователь запрашивает увеличение объема за 10 дней в течение 20 дней, для этого потребуется еще один столбец. Общее количество таких столбцов может легко пересечь 100, особенно если я начну добавлять другие результаты в виде столбцов, таких как MACD-10, MACD-100. каждый из которых потребует свой собственный столбец.

Это выполнимое решение?

Другой вариант заключается в том, что я сохраняю результат в кэшированных html-файлах и представляю их пользователю. У меня нет большого опыта в веб-разработке, поэтому для меня это выглядит грязно; но я могу ошибаться (оф!). Это тоже вариант?

Позвольте мне добавить, что я / буду использовать mod_perl для представления ответа пользователю. Большая часть работы над базой данных mysql выполняется с использованием perl. Я хотел бы иметь время отклика 1-2 секунды.

1 Ответ

2 голосов
/ 21 марта 2010

Вы должны максимально нормализовать свои данные и позволить СУБД выполнять свою работу: эффективно выполнять запросы на основе нормализованных данных.

Не думайте, что будет или не будет эффективным; вместо этого оптимизируют только в ответ на конкретные, измеренные неэффективности , как сообщается в объяснителе запросов СУБД.

Допустимые инструменты для оптимизации включают в грубом порядке предпочтения:

  • Нормализация данных далее , чтобы СУБД могла сама решать, как лучше всего ответить на запрос.

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

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

  • Создание дополнительных таблиц для хранения промежуточных предварительно вычисленных результатов для использования в будущих запросах. Это редко хорошая идея, не в последнюю очередь потому, что она полностью нарушает принцип СУХОЙ; Теперь вам нужно выработать стратегию синхронизации дублирующейся информации (исходных и полученных данных), когда СУБД будет работать наилучшим образом при наличии нет дублированных данных.

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

...