| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Многомерные кубы
Jeer © (2007-04-26 16:48:00)Пришлось столкнуться в одной информационно-аналитической системе с многомерными выборками из еще более многомерного куба.
Пример:
SELECT * FROM STATE_YEAR
WHERE YEAR_ID IN (2001 , 2002 , 2003 , 2004 , 2005 , 2006 , 2007)
AND MSR_MODE_ID IN (101 , 100 , 301 , 300)
AND SRC_ID IN (4 , 13)
AND TERR_ID IN (29202 , 29251 , 29204 , 29206 , 29252 , 29253 , 29208 , 29254 , 29255 , 29256 , 29257 , 29210 , 29212 , 29258 , 29213 , 29259 , 29260 , 29215 , 29261 , 29216 , 29262 , 29263 , 29218 , 29223 , 29264 , 29265 , 29225 , 29227 , 29229 , 29232 , 29234 , 29236 , 29238 , 29242 , 29244 , 29266 , 29267 , 29268 , 29246 , 29269 , 29250 , 29401 , 29605 , 29405 , 29214 , 29415 , 29610 , 29410 , 29220 , 29270 , 29271 , 29272 , 29000)
AND BRANCH_ID IN (0)
AND MSR_STATE_CODE IN (1003 , 1004 , 1005 , 1006 , 1007 , 1008 , 1009 , 1010 , 1011 , 1012 , 1013 , 1014 , 1015 , 1016 , 1017 , 1018 , 1002 , 1001 , 1021 , 1022 , 1023 , 1024 , 1025 , 1026 , 1027 , 1028 , 1029 , 1030 , 1031 , 1032 , 1033 , 1034 , 1035 , 1036 , 1020 , 1019 , 1000)
Система практически падает при сближении мерности выборки и куба.
Подозреваю, что выход только один - делать оптимизированные разрезы и получать результат как серию запросов.
Или не прав, или что-то еще ?
P.S.
Про технологии хранения-выборки (MOLAP/ROLAP) не будем, т.к. эта ИА-система на сегодня данность.
Jeer (2007-04-27 10:06:00) [21]clickmaker © (26.04.07 18:36) [2]
СУБД MS-SQL
Johnmen © (26.04.07 21:06) [3]
>Я сильно подозреваю, что это НЕ СПАСЁТ положения.
Эксперименты показали, что острота снижается.
Предположим, что есть измерения:
- время
- территории
- виды деятельности
- источник информации
- показатели.
Т.е. имеем 5-мерный куб.
Значимые по объему выборки проходят по измерениям:
-время
-территории
-показатели
Т.е. имеем 3-мерный срез из 5-мерного куба.
Попытка получить этот срез одним select приводит к значительному времени
исполнения и съеданию ресурсов памяти.
Проведенный эксперимент показал, что зависимость времени выполнения запроса от числа запрашиваемых параметров (ось "параметры") оказалась практически квадратичной.
Таким образом, единственный запрос с числом параметров 60 занимал время 90 сек, а 6 запросов по 10 параметров в каждом заняли в сумме 24 сек.
Учитывая, что число параметров достигает нескольких тысяч - в рамках данной структуры это, пожалуй, единственный выход по снижению временных затрат.
P.S.
Поскольку, в данном случае, я не разработчик, а только пользователь, как бизнес- аналитик, возможности что-либо кардинально изменить не имеется:(
Поэтому инструментарий класса Analysis и OLAP Service пробегает мимо.
Johnmen (2007-04-26 21:06:00) [22]
> Jeer © (26.04.07 16:48)
> Подозреваю, что выход только один - делать оптимизированные
> разрезы и получать результат как серию запросов.
Я сильно подозреваю, что это НЕ СПАСЁТ положения.
А единственный выход не проходит из-за "т.к. эта ИА-система на сегодня данность."
clickmaker (2007-04-26 18:36:00) [23]
> Система практически падает
какая хоть система? ну в смысле СУБД
Правильный Вася (2007-04-26 17:03:00) [24]
> Система практически падает при сближении мерности выборки и куба.
по-русски
| |
Страницы: 