Вышлю AWR'ы, только e-mail не нашёл.
Я использовал Benchmark Factory for Databases Freeware v7.0.0.221 (не триал на 15 дней), но не думаю, что это принципиально.
IM у меня был существенно быстрее (в 2-3 раза), когда не хватало памяти (итоговые параметры указаны в статье).
Про индексы. Конечно же каждый кейс (таблица, конкретный индекс, характерные запросы,...) нужно рассматривать индивидуально. Если после включения IM необходимость в индексе пропадает, то удаляем, нет — оставляем. Например, в случае факт таблицы для аналитики актуальность большинства индексов скорее пропадёт.
Аналогичный тест на Vertica есть в планах. SAP HANA в ближайшее время вряд ли.
Результаты теста на MS SQL будет интересно почитать, особенно в части IM и column store.
В бенчмарке TCP-H 22 запроса различной сложности как раз для DSS/OLAP систем. Ваши выводы будут интересны на конкретном примере.
Первое, что я лично ожидал увидеть от Oracle IM на своих кейсах — это значительное ускорение аналитических запросов за счёт compressed column store. Допустим, есть fact таблица из 30 полей и XXX млн. строк, выбираю XX млн. строк и 3 поля. К примеру, СУБД Vertica ускоряет такие запросы минимум на порядок с 1 нодой.
50 Гб конечно интереснее. На какой конфигурации сервера тестировали? Как в буферный кэш все данные отправляли? У меня разница в разы получалась только тогда, когда памяти на кэш не хватало.
Результаты для Q1:
no IM no parallel — 6.62 сек.
no IM parallel(4) — 5.88 сек.
IM no parallel — 6.47 сек.
IM no parallel(4) — 3.15 сек
Момент с количеством параллельных сессий учитывался. Для сравнения вариант с 2-мя сессиями и 12-ю запусками (те же 528 итоговых запуска):
1) 14 мин 13 сек. без IM
2) 13 мин 07 сек. с IM
Разница менее 10%.
Я не совсем понял комментарий. Какие индексы в память не помещаются? Относительно чего не было выигрыша? И что понимаете под аналитическими индексами?
Выше ссылки на ddl таблиц и запросы, просьба уточнить комментарий.
Поделюсь и запросами и ddl скриптами. Кому интересно, могу дать ссылку и на примерные планы выполнения запросов со статистикой.
Bottleneck — CPU.
Пробовал много дополнительных вариантов: несколько видов partitioning, без partitioning, c parallel и без, с компрессией вариант. При этом отдельные запросы специально не оптимизировались (индексами, хинтами,...). Делал это для того, чтобы показать ещё 1-2 быстрых способа оптимизации (например, parallel и/или db_big_table_cache_percent_target). Но на этом тесте и моём CPU интересных результатов не получилось и ограничился только IM Option.
> Тесты на холодную базу запускали?
Да, но так как каждый запрос выполнялся по 24 раза, это особой роли не играло. И 1-е выполнение не в разы было медленнее (диск SSD).
Нагрузку на сервер анализировал, используя Oracle AWR отчёт. И в обоих случаях узким местом был процессор, т.к. оперативной памяти было достаточно для кеширования всего объёма данных. Цель была — оценить, какой прирост производительности можно получить за счёт IM Option. И в этом смысле оба теста имели равные условия.
Я использовал Benchmark Factory for Databases Freeware v7.0.0.221 (не триал на 15 дней), но не думаю, что это принципиально.
IM у меня был существенно быстрее (в 2-3 раза), когда не хватало памяти (итоговые параметры указаны в статье).
Аналогичный тест на Vertica есть в планах. SAP HANA в ближайшее время вряд ли.
Результаты теста на MS SQL будет интересно почитать, особенно в части IM и column store.
Первое, что я лично ожидал увидеть от Oracle IM на своих кейсах — это значительное ускорение аналитических запросов за счёт compressed column store. Допустим, есть fact таблица из 30 полей и XXX млн. строк, выбираю XX млн. строк и 3 поля. К примеру, СУБД Vertica ускоряет такие запросы минимум на порядок с 1 нодой.
Результаты для Q1:
no IM no parallel — 6.62 сек.
no IM parallel(4) — 5.88 сек.
IM no parallel — 6.47 сек.
IM no parallel(4) — 3.15 сек
Планы и статистика по ссылке.
Но по сумме всех запросов IM+parallel мне не давал выигрыш в 2 раза.
Момент с количеством параллельных сессий учитывался. Для сравнения вариант с 2-мя сессиями и 12-ю запусками (те же 528 итоговых запуска):
1) 14 мин 13 сек. без IM
2) 13 мин 07 сек. с IM
Разница менее 10%.
Выше ссылки на ddl таблиц и запросы, просьба уточнить комментарий.
Bottleneck — CPU.
Пробовал много дополнительных вариантов: несколько видов partitioning, без partitioning, c parallel и без, с компрессией вариант. При этом отдельные запросы специально не оптимизировались (индексами, хинтами,...). Делал это для того, чтобы показать ещё 1-2 быстрых способа оптимизации (например, parallel и/или db_big_table_cache_percent_target). Но на этом тесте и моём CPU интересных результатов не получилось и ограничился только IM Option.
> Тесты на холодную базу запускали?
Да, но так как каждый запрос выполнялся по 24 раза, это особой роли не играло. И 1-е выполнение не в разы было медленнее (диск SSD).