ReSQL.ru
     
powered by simpleCommunicator - 2.0.38     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / SQLite [игнор отключен] [закрыт для гостей] / Перепроектировать ли БД
1 сообщений из 1, страница 1 из 1
Перепроектировать ли БД
    #38052139
meneo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
meneo
Гость
Добрый день!

Спроектировал БД, которая хранит исторические данные финансовых рынков.
для каждого нового финансового (сейчас их около 70) созданы 4 таблицы:
имя_инструмента_ week , имя_инструмента_ day , имя_инструмента_ hr1 , имя_инструмента_ 10min , имя_инструмента_ 1min
Код: sql
1.
2.
CREATE TABLE имя_инструмента_врем_интервал
 (DataSource STRING, DateTime TEXT, Open REAL, High REAL, Low REAL, Close REAL)



таблицы 10min и 1min пока не используются
средний размер одной таблицы hr1 в среднем для каждого инструмента 18000 записей.

сразу поясню изначально решено на каждые пару инструмент/временной интервал сделать отдельные таблицы (а не хранить все в одной таблице), потому как в конечном результате будут использоваться и 1min, т.е. для каждого инструмента уже будет по 1млн записей, т.е. в одной таблице это было бы 70млн записей. Я опасался, что будет тормозить...

Не тут-то было... с проблемами подтормаживания и неудобств я столкнулся раньше :)

В конечных отчетах выводимые данные - это расчетные цифры, которые в основном вычисляются по одинаковому принципу: для каждой выводимой записи вычисляется значение на основании предыдущих N записей (максимум за последние 90дней, среднее за последние 90 записей итд).

Конечный SELECT в одном из отчетов для N инструментов выглядит во-первых очень громоздко:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
SELECT 
  q.datetime,
  t_1.Open, t_1.High, t_1.Low, t_1.Close,
    (SELECT tmp.datetime||'~'||tmp.high FROM table_1(day) tmp
     WHERE datetime>=DATETIME(t0.datetime,'-90 day') AND datetime<DATETIME(t0.datetime, '+1 days')
     ORDER BY t1.high DESC, t1.datetime DESC 
     LIMIT 1) as Prev90DaysHigh_1), 
  t_2.Open, t_2.High, t_2.Low, t_2.Close,
    (SELECT tmp.datetime||'~'||tmp.high FROM table_2(day) tmp
     WHERE datetime>=DATETIME(t0.datetime,'-90 day') AND datetime<DATETIME(t0.datetime, '+1 days')
     ORDER BY t1.high DESC, t1.datetime DESC 
     LIMIT 1) as Prev90DaysHigh_2),
......
  t_N.Open, t_N.High, t_N.Low, t_1.Close,
    (SELECT tmp.datetime||'~'||tmp.high FROM table_N(day) tmp
     WHERE datetime>=DATETIME(t0.datetime,'-90 day') AND datetime<DATETIME(t0.datetime, '+1 days')
     ORDER BY t1.high DESC, t1.datetime DESC 
     LIMIT 1) as Prev90DaysHigh_N)
FROM
  (SELECT datetime FROM table_1
   WHERE Datetime>=BegRepDate AND DateTime<=EndRepDate
   UNION
   SELECT datetime FROM table_2
   WHERE Datetime>=BegRepDate AND DateTime<=EndRepDate
   .....
   UNION
   SELECT datetime FROM table_N
   WHERE Datetime>=BegRepDate AND DateTime<=EndRepDate 
  ) as q
LEFT OUTER JOIN table_1 t_1 ON q.datetime=t_1.datetime 
LEFT OUTER JOIN table_2 t_2 ON q.datetime=t_2.datetime
........ 
LEFT OUTER JOIN table_N t_N ON q.datetime=t_N.datetime



Во-вторых, этот отчет содержит ТОЛЬКО ОДИН расчетный параметр Prev90DaysHigh.
Строится он вполне приемлемо по времени, хотя парсить его сложно :)

Если же я добавлю еще пару расчетных параметров, т.е. еще 2*N вложенных селектов, ждать становится менее приятно.
А искать ошибку в select'e не возможно (хотя всегда на время отлаживания можно сделать N=2).

Но меня, конечно, беспокоит производительность на этом этапе. Такая тормозяка, а я минимально использую только часовой интервал...

Итак теперь вопросы :)

Во-первых, очень бы хотелось, чтобы Вы, профессионалы этого дела, своим профессиональным взглядом сказали насколько все запущенно/через одно место сделано :). Если все совсем плохо, посоветуйте, как правильнее перепроектировать БД.
Один из вариантов решения, который мне пришел в голову это сделать ТРИГГЕРЫ, что не сложно.
Если только Вы не подскажете более правильное решение.

Во-вторых, для удобства работы программы и особенно дальнейшего использования было бы удобно написать функции, которые в качестве результата выдают расчет конкретного параметра для конкретной записи (тобишь один SELECT). Тут есть вопрос, что быстрее: выполнять один раздутый SELECT выше или убрать из него подселекты и выполнять их походу построения отчета. Или другими словами оптимизирует ли SQLite этот раздутый SELECT.

В-третьих, учитывая что в конечной перспективе будут использоваться таблицы 1min, подумываю перейти на более серьезные БД. MSSQL же хватит для этих целей? :)
Но прежде чем переходить, хотелось бы понимать, что все сделано не через ж.
...
Рейтинг: 0 / 0
25.11.2012, 14:04
| Ответить | Цитировать | Написать  
1 сообщений из 1, страница 1 из 1
Форумы / SQLite [игнор отключен] [закрыт для гостей] / Перепроектировать ли БД
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=54&msg=38052139&tid=2008957]:
 0ms
get settings:
 11ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 26ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 33ms
get tp. blocked users:
 2ms
others: 274ms
total:  382ms
созд. / загр.: 382ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]