Материализованное представление Vs Temp таблиц в Oracle - PullRequest
2 голосов
/ 18 июня 2019

У меня есть базовая таблица транзакций.Затем у меня есть около 15 промежуточных шагов, где я объединяю таблицы измерений, выполняю некоторую агрегацию и внедряю бизнес-логику.В настоящее время я работаю над созданием временных таблиц для промежуточных этапов и размещением этих 15 шагов, заполняя окончательный результат в физической таблице.Это лучший подход или использование материализованного представления вместо промежуточных временных таблиц.Если использование материализованных представлений для промежуточных шагов является лучшим подходом, пожалуйста, дайте мне знать, почему?

Уже пробовали сценарии обоих подходов, 15 промежуточных шагов в виде глобальной временной таблицы и материализованного представления.Я обнаружил незначительное улучшение производительности в MV по сравнению с временными таблицами, но за счет избыточной физической памяти.Не уверен, что является лучшей практикой и почему

Ответы [ 2 ]

1 голос
/ 18 июня 2019

Временные таблицы записывают на диск, поэтому затраты на ввод / вывод как для чтения, так и для записи. Кроме того, большинство сайтов не управляют своими временными таблицами должным образом, и они попадают во временное табличное пространство по умолчанию, которое является тем же самым табличным пространством TEMP, которое все используют для сортировки и т. Д. Таким образом, существует вероятность конфликта ресурсов.

Материализованные представления предназначены для материализации аспектов нашего набора данных, которые обычно используются многими различными запросами. Вот почему наиболее распространенный вариант использования - для хранения агрегированных данных низкого уровня на более высоком уровне. Это не похоже на вариант использования, который у вас здесь есть. И вот!

Я делаю полное обновление MV, а не добавочное обновление

Так нет.

Затем у меня есть около 15 промежуточных шагов, где я объединяю таблицы измерений, выполняю некоторую агрегацию и внедряю бизнес-логику.

Это ужасно процедурный способ запроса данных. Иногда невозможно избежать этого, особенно в определенных сценариях хранилища данных. Однако из этого не следует, что нам нужно материализовать результаты этих запросов. Альтернативный подход заключается в использовании предложений WITH. Выходные данные одного подзапроса WITH могут передаваться в нижние подзапросы.

    with sq1 as ( 
         select whatever
                , count(*) as t1_tot
         from t1
         group by whatever
   ) , sq2 as (
         select sq1.whatever
                , max(t2.blah) as max_blah
         from sq1
              join t2 on t2.whatever = sq1.whatever
   ) , sq3 as ( 
         select sq2.whatever
                ,(t3.meh + t3.huh) as qty
         from sq2
              join t3 on t3.whatever = sq2.whatever
         where t3.something >= sq2.max_blah
   )
   select sq1.whatever
          ,sq1.t1_tot
          ,sq2.max_blah
          ,sq3.qty
   from sq1
        join sq2 on sq2.whatever = sq1.whatever
        join sq3 on sq3.whatever = sq1.whatever

Не говорю, что это не будет чудовищный запрос, террор департамента. Но он, вероятно, будет работать лучше, чем ваши MViews от GTT. (Oracle может решить материализовать эти промежуточные наборы результатов, но мы можем использовать подсказки, чтобы повлиять на это .)

Вы можете даже обнаружить, что при таком подходе некоторые из ваших шагов не нужны, и вы можете объединить несколько шагов в один запрос. Конечно, в реальной жизни я бы написал свое игрушечное утверждение выше как один запрос, а не как объединение трех подзапросов.

1 голос
/ 18 июня 2019

Из того, что вы сказали, я бы сказал, что лучше использовать временные таблицы (глобальные или частные, в зависимости от используемой версии базы данных). Зачем? Потому что вы что-то «вычисляете», сохраняете результаты этих вычислений в некоторых таблицах и повторно используете их для дополнительной обработки. Все это - если это невозможно сделать без временных таблиц - должно выполняться с таблицами.

Материализованное представление - это, как следует из его названия, представление . Это результат какого-то запроса, но, в отличие от «нормальных» представлений, он на самом деле занимает место. Может обновляться (по требованию, при изменении исходных данных или по расписанию). Да, у него есть свои преимущества, хотя я не вижу ничего в том, что вы сейчас делаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...