Задача оракл dwh
Есть "нормализованная" бд когда в огромных таблицах хранится не поля с большими строками, а циферки, по которым наджойниваешься на огромную таблицу со строками.Можно объединить эти таблицы в кластер, хотя не думаю что проблема в этом.
С датами и даблами таже херь. Тащатся данные соответственно через функции типа "забрать строку такой то номер"
Если я правильно понял суть проблемы, то функция - черный ящик для оптимизатора. Дефакто происходит nested loop join (пройтись по таблице, для каждой строки залезая в другую таблицу), гибельный на больших объемах данных. Надо было использовать вьюхи, чтобы происходил hash join.
Функций разных всего 3, соответственно лезут они в 3 больших таблицы. Просто каждая в строке селекта вызывается раз сто...
Ну сделать промежуточную таблицу, в которой хранится рассчитанные значения функции, и дополнять (например мерджем ), соответственно считать 100 раз не надо.
Функции детерминистик? Может помочь.
А вообще, нужно поконкретней.
Функции детерминистик? Может помочь.
А вообще, нужно поконкретней.
Поконкретнее попробую
Основная таблица.
Ключ плюс 300+ полей типа integer
3 огромные таблицы:
String, mid, index
Data, mid, index
Double, mid, index
3 функции соответственно, которые применяются к каждому полю первой таблицы.
Функции делают следующее. С помощью connect by path из какой- то из трех таблиц выбераются все стринги/даты/ или даблы для конкретного mid, сортируются по индексу и собираются в одну последовательность разделенные ";"
Чо я сделал. Создал еще три таблицы в которых лежат
Mid, aggr где аггр - уже собраная эта херня описанная выше.
Остается триста раз наджойнить эти три новые таблицы на первоначальную и никаких функций. Но может есть менее гомоздкое решение?
То есть когда таких полей десяток - два, то решение суперское, предварительно рассчитанные агрегаты моментально джойнятся и все ок, а вот когда 300 полей - хз
Основная таблица.
Ключ плюс 300+ полей типа integer
3 огромные таблицы:
String, mid, index
Data, mid, index
Double, mid, index
3 функции соответственно, которые применяются к каждому полю первой таблицы.
Функции делают следующее. С помощью connect by path из какой- то из трех таблиц выбераются все стринги/даты/ или даблы для конкретного mid, сортируются по индексу и собираются в одну последовательность разделенные ";"
Чо я сделал. Создал еще три таблицы в которых лежат
Mid, aggr где аггр - уже собраная эта херня описанная выше.
Остается триста раз наджойнить эти три новые таблицы на первоначальную и никаких функций. Но может есть менее гомоздкое решение?
То есть когда таких полей десяток - два, то решение суперское, предварительно рассчитанные агрегаты моментально джойнятся и все ок, а вот когда 300 полей - хз
Ситуация осложнена тем, что несмотря на то, что в исходной таблице 160000 строк, 3 предварительно рассчитанных таблицы с агрегациями по примерно 30 млн строк каждая, соответственно их наджойнивать 300 раз.
Либо же мутить ГТТ таблички мелкие в количестве 300 штук типа одна табличка предварительно расчитанная под каждое поле основной таблицы, тогда каждая будет по 150 000 строк примерно, но это же ебу даться надо, наплодить ради одного куска говна 300 temporary табличек. Хочу простое красивое решение негромоздкое
Либо же мутить ГТТ таблички мелкие в количестве 300 штук типа одна табличка предварительно расчитанная под каждое поле основной таблицы, тогда каждая будет по 150 000 строк примерно, но это же ебу даться надо, наплодить ради одного куска говна 300 temporary табличек. Хочу простое красивое решение негромоздкое
Хочу простое красивое решение негромоздкоеПСЖ.
Но может есть менее гомоздкое решение?Попробуй unpivot/pivot
Ключ плюс 300+ полей типа integerСдается мне, вот тут и есть основная проблема.
Что, реально набор из 300+ чисел одним ключом определяется?
да это неважно
важно то что там насыпаны миды из трех огромных таблиц
в 300+ полей
и надо прицепить три огромные таблицы
к каждому полю
важно то что там насыпаны миды из трех огромных таблиц
в 300+ полей
и надо прицепить три огромные таблицы
к каждому полю
Функции, которые ты вызываешь - конвейерные?
парни вы меня пугаете
употреблением всяких умных слов
да в рот их ебать, конвейерные они или нет
как избавиться от функций с ростом производительности я понимаю
а как наджойнить 300 раз таблицы - нет
употреблением всяких умных слов
да в рот их ебать, конвейерные они или нет
как избавиться от функций с ростом производительности я понимаю
а как наджойнить 300 раз таблицы - нет
а как наджойнить 300 раз таблицы - неттак, а в чем проблема? Джойниться таблицы будут по первичному ключу, так что проблема лишь в том, что данных будет много, запрос можно сгенерить скриптом достаточно быстро (если имена колонок однотипные).
а реально нужно в итоговую выборку включать все 300 показателей да еще и составных? что это за тема такая?
Попробуй так:
1. Unpivot для основной таблиы 2. Join с тремя агрегатными таблицами 3. Pivot того что получилось.
Правда я не уверен что это будет быстрее.
1. Unpivot для основной таблиы 2. Join с тремя агрегатными таблицами 3. Pivot того что получилось.
Правда я не уверен что это будет быстрее.
И ещё вопросы:
1. Как часто меняются данные таблицах?
2. Как часто тебе нужно их забирать?
1. Как часто меняются данные таблицах?
2. Как часто тебе нужно их забирать?
да в рот их ебать, конвейерные они или нетдумать не пытался?
http://bit.ly/1mKpnjp
ясен пень они у тебя тормозят
Крот, дорогой, читай пожалуйста внимательнее то, что я пишу.
я знаю что такое конвейерные функции
я вообще против функций в загрузках DWH
проблема с функциями не стоит, я от них избавился.
проблема в том, что джойнятся не по ключу
а по каждому столбцу
все говно до меня отрабатывало часов 8. я попробовал 40 раз наджойнить таблицы, это заняло 80 минут. попробовал 100, оставил, какой результат - не знаю (ушел вчера домой, плюс 100 эти попробовал не хешем а нестед лупсами с индекс рендж сканом). если он увеличивается пропорционально - это проблема.
Картинко для маштаба
я знаю что такое конвейерные функции
я вообще против функций в загрузках DWH
проблема с функциями не стоит, я от них избавился.
проблема в том, что джойнятся не по ключу
а по каждому столбцу
все говно до меня отрабатывало часов 8. я попробовал 40 раз наджойнить таблицы, это заняло 80 минут. попробовал 100, оставил, какой результат - не знаю (ушел вчера домой, плюс 100 эти попробовал не хешем а нестед лупсами с индекс рендж сканом). если он увеличивается пропорционально - это проблема.
Картинко для маштаба
меняются постоянно, забирать каждый день
меняются постоянно1. Сколько строк в день в среднем:
1. Добавляется/изменяется в основной таблице
2. Удаляется в основной таблице
3. Добавляется/изменяется в дополнительных таблицах
4. Удаляется из дополнительных таблиц
2. Те же параметры, но пиковые значения.
Да, но зачем? (С)
Предложение подумать об инкрементальности вместо полного перекачивания? Подумаю, ок.
Предложение подумать об инкрементальности вместо полного перекачивания? Подумаю, ок.
В общем прописанный руками юз_нл на 270 таблиц отработал за 1400 секунд
Тему можно закрывать )))
слава ораклу, героям слава !
Тему можно закрывать )))
слава ораклу, героям слава !
Оставить комментарий
ppp6663669
Есть "нормализованная" бд когда в огромных таблицах хранится не поля с большими строками, а циферки, по которым наджойниваешься на огромную таблицу со строками. С датами и даблами таже херь. Тащатся данные соответственно через функции типа "забрать строку такой то номер"Ацки тормозит
Когда в запросе несколько вызовов функции, меняю их на джойны с предварительно рассчитанными таблицами и все работает шустро и бодро очень, проблем нет
Наткнулся на запрос, вообще гг, 300 функций в селекте. Таблица откуда селектят 160 000 строк. Функции лезут иерархическим подзапросом в 90 милионные таблицы
Create table as select отрабатывает за часов 8
Как ускорить номально? Неужели 300 джойнов мутить?
Фоточка селекта для маштаба приложу чуть позже