|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.12.2004, 19:06
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
Проблему анализа пытаюсь решить тем что на основании существующих таблиц поддерживаю актуальную таблицу фактов и применяю схему "звезда" пользуюсь стандартными средствами СУБД, т.е. результат получается в результате выполнения SQL запроса с group by "измерения", проблема заключается в том, что данные в таблице фактов сильно разреженны, например из 500 000 строк таблицы, group by по всем измерениям дает 400 000 строк, можно ли провести какую нибудь оптимизацию направленную на уменьшение размера таблицы фактов не удаляя из анализа измерения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.12.2004, 20:38
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
Michail DalakovПроблему анализа пытаюсь решить тем что на основании существующих таблиц поддерживаю актуальную таблицу фактов и применяю схему "звезда" пользуюсь стандартными средствами СУБД, т.е. результат получается в результате выполнения SQL запроса с group by "измерения", проблема заключается в том, что данные в таблице фактов сильно разреженны, например из 500 000 строк таблицы, group by по всем измерениям дает 400 000 строк, можно ли провести какую нибудь оптимизацию направленную на уменьшение размера таблицы фактов не удаляя из анализа измерения? А в чем собственно проблема и что Вы хотит получить в результате оптимизации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.12.2004, 21:40
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
В результате оптимизации хочу уменьшить количество уникальных комбинаций в таблице фактов, это важно для быстродействия т.к. особенность заключается в том что группировке подвергается не вся таблица фактов а только часть, чем меньше будет уникальных комбинаций тем меньше строк будет подвергаться группировке и быстрее будет получен результат, основные тормоза связаны сгруппиовкой, например проведенный мной анализ показал, что поиск строк которые необходимо группировать занимает ~0.3 c, а их группировка ~15с ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2004, 10:28
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
Для уменьшения времени группировки надо оптимизировать запрос и индексы. С этим вопросом вам прекрасно помогут в формуе по MS SQL, Oracle или какая у вас СУБД? Для уменьшения строк в таблице фактов можно создать хранилище (хотя бы из одной таблицы). Тогда таблицей фактов у вас будет физическая таблица, данные в которой в точности соответствуют view, и для построения куба не надо будет проводить расчётов и групировок на уровне СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2004, 10:45
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
oracle насчет индексов хочу сказать что они никак не влияют на группировку т.к. для того чтобы сгруппировать надо просканировать всю таблицу насчет второй части совсем не понял в результате чего таблица фактов уменьшится ведь она по сути дела является уже пре-сгруппированой таблицей на основании данных физической таблицы и по количеству записей естествено меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2004, 11:50
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
Michail DalakovВ результате оптимизации хочу уменьшить количество уникальных комбинаций в таблице фактов, это важно для быстродействия т.к. особенность заключается в том что группировке подвергается не вся таблица фактов а только часть, чем меньше будет уникальных комбинаций тем меньше строк будет подвергаться группировке и быстрее будет получен результат, основные тормоза связаны сгруппиовкой, например проведенный мной анализ показал, что поиск строк которые необходимо группировать занимает ~0.3 c, а их группировка ~15с С каким OLAP продуктом вы работаете? Какой тип OLAP хранилища ROLAP или MOLAP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2004, 12:16
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
Michail Dalakovнасчет индексов хочу сказать что они никак не влияют на группировку т.к. для того чтобы сгруппировать надо просканировать всю таблицу Не просто просканировать, а сначала отсортировать. А индексы на это дело очень сильно влияют. В любой СУБД, где они есть. Michail Dalakov насчет второй части совсем не понял в результате чего таблица фактов уменьшится ведь она по сути дела является уже пре-сгруппированой таблицей на основании данных физической таблицы и по количеству записей естествено меньше Внимательно прочитайте свой же первый пост Michail Dalakovданные в таблице фактов сильно разреженны, например из 500 000 строк таблицы, group by по всем измерениям дает 400 000 строк Вот за счёт того, что во вновь созданной таблице будет на 100 000 строк меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2004, 12:57
|
|||
|---|---|---|---|
|
|||
оптимизация разреженных данных |
|||
|
#18+
А в чём, собственно, заключается "проблема анализа"? Постановка вопроса звучит как-то не очень понятно. Не могли бы уточнить? А ещё неплохо было бы привести скрипт создания таблицы и запрос. А то, не очень понятно, что оптимизируем. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=49&mobile=1&tid=1871966]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
86ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 263ms |
| total: | 464ms |
| 0 / 0 |
