In-Memory Option. Test Case / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / In-Memory Option. Test Case

17 сообщений из 17, страница 1 из 1

In-Memory Option. Test Case

#39250742

twinplay

Гость

Почитав тесты производительности 12с In-Memory Option, провёл аналогичные на своих данных. У коллег:
oracle 12c inmemory
Хабр
получилось очень сильное ускорение, а у меня пока нет...

Данные для теста - "звезда" из 5 таблиц:
Fact Table - 17 колонок, 17,7 млн. записей, ~1 Гб.
4 Dimension Tables:
- 11 кол., 0,3 млн. записей
- 11 кол., 0,18 млн. записей
- 8 кол., 350 записей
- 7 кол., 35 записей

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

Типовой запрос, который генерирует BI Tool:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

 SELECT
  trunc(ft_contract_assets_im.act_date,'MONTH'),
  dim_currency.CURRENCY_DESCR,
  dim_product.PRODUCT_GROUP_DESCR_L2,
  AVG(ft_contract_assets_im.debt_standard),
  count(*)
FROM st_xf_dm.FT_CONTRACT_ASSETS_IM ft_contract_assets_im
  JOIN st_xf_dm.DIM_CUSTOMER_IM dim_customer ON (ft_contract_assets_im.CUSTOMER_SK = dim_customer.CUSTOMER_SK)
  JOIN st_xf_dm.DIM_PRODUCT_IM dim_product ON (ft_contract_assets_im.PRODUCT_SK = dim_product.PRODUCT_SK)
  JOIN st_xf_dm.DIM_CURRENCY_IM dim_currency ON (ft_contract_assets_im.CURRENCY_SK = dim_currency.CURRENCY_SK)
  JOIN st_xf_dm.DIM_CONTRACT_IM DIM_CONTRACT_IM ON (ft_contract_assets_im.CONTRACT_SK = DIM_CONTRACT_IM.CONTRACT_SK)  
GROUP BY
  trunc(ft_contract_assets_im.act_date,'MONTH'),
  dim_currency.CURRENCY_DESCR,
  dim_product.PRODUCT_GROUP_DESCR_L2

Запрос в моём понимании должен хорошо ускоряться через IM: нужно много данных прочитать, колонок выбираем мало, агрегируем.

Fact Table - Range Partitions по дате, индексов, pk и fk для данного теста нет.

1) Запускаем NO INMEMORY:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.

234 rows selected.

Elapsed: 00:00:27.60

--------------------------------------------------------------------------------------------------------------------------        
| Id  | Operation                | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |        
--------------------------------------------------------------------------------------------------------------------------        
|   0 | SELECT STATEMENT         |                       |    10M|  2514M|       |   131K  (2)| 00:00:06 |       |       |        
|   1 |  HASH GROUP BY           |                       |    10M|  2514M|       |   131K  (2)| 00:00:06 |       |       |        
|*  2 |   HASH JOIN              |                       |    10M|  2514M|       |   130K  (2)| 00:00:06 |       |       |        
|   3 |    TABLE ACCESS FULL     | DIM_CURRENCY_IM       |  2288 |   167K|       |     9   (0)| 00:00:01 |       |       |        
|*  4 |    HASH JOIN             |                       |    10M|  1760M|       |   130K  (1)| 00:00:06 |       |       |        
|   5 |     TABLE ACCESS FULL    | DIM_PRODUCT_IM        |  2288 |   167K|       |     9   (0)| 00:00:01 |       |       |        
|*  6 |     HASH JOIN            |                       |    10M|  1005M|  5264K|   130K  (1)| 00:00:06 |       |       |        
|   7 |      TABLE ACCESS FULL   | DIM_CUSTOMER_IM       |   215K|  2736K|       |   721   (1)| 00:00:01 |       |       |        
|*  8 |      HASH JOIN           |                       |    10M|   875M|  4448K| 79506   (2)| 00:00:04 |       |       |        
|   9 |       TABLE ACCESS FULL  | DIM_CONTRACT_IM       |   182K|  2312K|       |   610   (1)| 00:00:01 |       |       |        
|  10 |       PARTITION RANGE ALL|                       |    10M|   744M|       | 35560   (2)| 00:00:02 |     1 |    14 |        
|  11 |        TABLE ACCESS FULL | FT_CONTRACT_ASSETS_IM |    10M|   744M|       | 35560   (2)| 00:00:02 |     1 |    14 |        
--------------------------------------------------------------------------------------------------------------------------  

Statistics
----------------------------------------------------------                                                                        
        518  recursive calls                                                                                                      
          0  db block gets                                                                                                        
     231696  consistent gets                                                                                                      
     134064  physical reads                                                                                                       
          0  redo size                                                                                                            
      17788  bytes sent via SQL*Net to client                                                                                     
        716  bytes received via SQL*Net from client                                                                               
         17  SQL*Net roundtrips to/from client                                                                                    
         65  sorts (memory)                                                                                                       
          0  sorts (disk)                                                                                                         
        234  rows processed

2) Запускаем INMEMORY. Поколоночное хранение со сжатием в памяти. Запросы по этим таблицам должны летать, но нет..

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.

  ALTER TABLE FT_CONTRACT_ASSETS_IM INMEMORY PRIORITY CRITICAL;
  ALTER TABLE DIM_CUSTOMER_IM INMEMORY PRIORITY CRITICAL;
  ALTER TABLE DIM_PRODUCT_IM INMEMORY PRIORITY CRITICAL;
  ALTER TABLE DIM_CURRENCY_IM INMEMORY PRIORITY CRITICAL;
  ALTER TABLE DIM_CONTRACT_IM INMEMORY PRIORITY CRITICAL;


select 
   s.SEGMENT_NAME,
   s.SEGMENT_TYPE,
   sum(s.INMEMORY_SIZE),
   sum(s.BYTES)
from v$im_segments s
group by 
s.SEGMENT_NAME,
   s.SEGMENT_TYPE

SEGMENT_NAME	SEGMENT_TYPE	SUM(S.INMEMORY_SIZE)	SUM(S.BYTES)
FT_CONTRACT_ASSETS_IM	TABLE PARTITION	472842240	1072955392
DIM_CONTRACT_IM	TABLE	10616832	18612224
DIM_CUSTOMER_IM	TABLE	9568256	22020096
DIM_PRODUCT_IM	TABLE	1179648	262144
DIM_CURRENCY_IM	TABLE	1179648	262144

234 rows selected.

Elapsed: 00:00:29.99

----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                       | 69300 |  5820K|       |   205K  (3)| 00:00:09 |       |       |
|   1 |  HASH GROUP BY                   |                       | 69300 |  5820K|  1630M|   205K  (3)| 00:00:09 |       |       |
|*  2 |   HASH JOIN                      |                       |    17M|  1454M|       | 79218   (4)| 00:00:04 |       |       |
|   3 |    TABLE ACCESS INMEMORY FULL    | DIM_PRODUCT_IM        |   335 |  9045 |       |     1   (0)| 00:00:01 |       |       |
|*  4 |    HASH JOIN                     |                       |    17M|   997M|       | 79040   (4)| 00:00:04 |       |       |
|   5 |     TABLE ACCESS INMEMORY FULL   | DIM_CURRENCY_IM       |    35 |   665 |       |     1   (0)| 00:00:01 |       |       |
|*  6 |     HASH JOIN                    |                       |    17M|   676M|  4400K| 78862   (4)| 00:00:04 |       |       |
|   7 |      TABLE ACCESS INMEMORY FULL  | DIM_CUSTOMER_IM       |   264K|  1292K|       |    31  (13)| 00:00:01 |       |       |
|*  8 |      HASH JOIN                   |                       |    17M|   591M|  2944K| 38831   (6)| 00:00:02 |       |       |
|   9 |       TABLE ACCESS INMEMORY FULL | DIM_CONTRACT_IM       |   177K|   865K|       |    26  (12)| 00:00:01 |       |       |
|  10 |       PARTITION RANGE ALL        |                       |    17M|   507M|       |  3071  (58)| 00:00:01 |     1 |    14 |
|  11 |        TABLE ACCESS INMEMORY FULL| FT_CONTRACT_ASSETS_IM |    17M|   507M|       |  3071  (58)| 00:00:01 |     1 |    14 |
----------------------------------------------------------------------------------------------------------------------------------
     
Statistics
----------------------------------------------------------                                                                        
        272  recursive calls                                                                                                      
          2  db block gets                                                                                                        
        492  consistent gets                                                                                                      
          2  physical reads                                                                                                       
          0  redo size                                                                                                            
      17080  bytes sent via SQL*Net to client                                                                                     
        716  bytes received via SQL*Net from client                                                                               
         17  SQL*Net roundtrips to/from client                                                                                    
         13  sorts (memory)                                                                                                       
          0  sorts (disk)                                                                                                         
        234  rows processed

На других запросах тоже тестировал, на некоторых, например только FT без join, получалось ускорение в 2-3 раза, но не больше. Что не так с моим тестом, где подвох?

...

Рейтинг:

0 / 0

05.06.2016, 01:09:21

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39250746

opatch12c

Гость

У Вас стоит последний IMDB Patch?

Что выводит команда "$ORACLE_HOME/opatch lsinventory"?

...

Рейтинг:

0 / 0

05.06.2016, 02:57:48

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39250770

pihel

Гость

twinplay,

Что не так с моим тестом, где подвох?
С inmemory в живую не работал, но предположу, что затык на hash join.
Преимущество inmemory фильтрации будет лучше видно, если будет какой то фильтр на измерении, с помощью которого oracle сможет создать bloom filter/part join filter на стороне inmemory движка, а в join придут уже сильно отфильтрованные данные.

...

Рейтинг:

0 / 0

05.06.2016, 10:53:31

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39250815

twinplay

Гость

Патчи не установлены. Это может кардинально повлиять?

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

  Oracle Home       : d:\app\oracle\product\12.1.0\dbhome_1
Central Inventory : C:\Program Files\Oracle\Inventory
   from           : n/a
OPatch version    : 12.1.0.1.3
OUI version       : 12.1.0.2.0
Log file location : d:\app\oracle\product\12.1.0\dbhome_1\cfgtoollogs\opatch\opatch2016-06-05_13-56-22PM_1.log

Lsinventory Output file location : d:\app\oracle\product\12.1.0\dbhome_1\cfgtoollogs\opatch\lsinv\lsinventory2016-06-05_13-56-22PM
.txt

--------------------------------------------------------------------------------
Installed Top-level Products (1):

Oracle Database 12c                                                  12.1.0.2.0
There are 1 products installed in this Oracle Home.


There are no Interim patches installed in this Oracle Home.

pihel, тестировал и на других запросах (без hash join и с фильтрами), большой разницы не получается.

...

Рейтинг:

0 / 0

05.06.2016, 14:07:55

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39253907

opatch12c

Гость

twinplayПатчи не установлены. Это может кардинально повлиять?

Может кардинально повлиять.
В январском BP ораклы кардинально что-то переписали, у меня в In-Memory планы поменялись после его установки.
Вот патч: Patch 22899531: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160419 (APR2016)

Это последний - лучше его ставить (он кумулятивный - включает в себя все предыдущие).

...

Рейтинг:

0 / 0

09.06.2016, 20:55:26

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39255526

twinplay

Гость

opatch12ctwinplayПатчи не установлены. Это может кардинально повлиять?

Может кардинально повлиять.
В январском BP ораклы кардинально что-то переписали, у меня в In-Memory планы поменялись после его установки.
Вот патч: Patch 22899531: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160419 (APR2016)

Это последний - лучше его ставить (он кумулятивный - включает в себя все предыдущие).

Тестировал на ноутбуке с Win x64, а для Win, как я понял, апрельский патч ещё не вышел. Придётся с январского (p22310559_121020_MSWIN-x86-64) начинать.

...

Рейтинг:

0 / 0

14.06.2016, 11:01:52

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39256517

Валерий Юринский

Участник

Откуда: Москва, "ФОРС Дистрибуция"

Сообщения: 1 357

Рейтинг: 0 / 0

twinplay,

Этот запрос не покажет особого ускорения, поскольку
- нет фильтрации по условиям >, <, =, IN
- HASH JOIN выполняется без использования ghtbveotcnd In-Memory
- Вы что-то выигрываете на доступе к табличным данным, но очень немного,
поскольку ваши небольшие таблицы лежат в BUFFER CACHE
- Vector Group By в плане отсутствует, то есть In-Memory Aggregation тоже не используется

Верно подмечено 19259284

Поставьте фильтры на данные из таблиц измерений:
- dim_customer
- dim_product
- dim_currency
- DIM_CONTRACT_IM
Чтобы отбиралось из них поменьше строк и посмотрите, что получится.

...

Рейтинг:

0 / 0

15.06.2016, 17:02:53

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39256661

opatch12c

Гость

twinplay... а для Win, как я понял, апрельский патч ещё не вышел. Придётся с январского (p22310559_121020_MSWIN-x86-64) начинать.

Вышел. Даже вышел следующий бандл:
Patch 23179016 WINDOWS DB BUNDLE PATCH 12.1.0.2.160531

...

Рейтинг:

0 / 0

15.06.2016, 21:39:22

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39258161

twinplay

Гость

Валерий Юринскийtwinplay,

Этот запрос не покажет особого ускорения, поскольку
- нет фильтрации по условиям >, <, =, IN
- HASH JOIN выполняется без использования ghtbveotcnd In-Memory
- Вы что-то выигрываете на доступе к табличным данным, но очень немного,
поскольку ваши небольшие таблицы лежат в BUFFER CACHE
- Vector Group By в плане отсутствует, то есть In-Memory Aggregation тоже не используется

Верно подмечено 19259284

Поставьте фильтры на данные из таблиц измерений:
- dim_customer
- dim_product
- dim_currency
- DIM_CONTRACT_IM
Чтобы отбиралось из них поменьше строк и посмотрите, что получится.

Валерий,

1) Если я поставлю фильтры на таблицы измерений, то у меня запрос будет летать и без IN-MEMORY (с правильными индексами, partitions, parallel). Запрос этот вполне типовой для аналитики. Существенное ускорение в некоторых редких частных случаях я получил. А возможность удалить индексы по-моему не аргумент для покупки дорогой опции.

2) Я, к слову, ещё сравнивал производительность на этих же данных c HP Vertica (column store без in-memory). В Vertica получается значительно быстрее. Очень надеюсь, что опция будет доведена до ума, т.к. идея сама по себе отличная.

...

Рейтинг:

0 / 0

18.06.2016, 00:05:55

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39258163

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

twinplay,

покажи отчеты SQL Monitor'a для обоих вариантов:

Код: plsql

select dbms_sqltune.report_sql_monitor(sql_id => '&1',report_level => 'ALL',type => 'TEXT') sqlmon from dual;

...

Рейтинг:

0 / 0

18.06.2016, 00:38:44

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39258165

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

twinplay,

ну и, безотносительно IM, добавьте FK с rely и установите query_rewrite_integrity=enforced, у вас тогда на 2 таблицы/хэшджойна меньше в запросе будет

...

Рейтинг:

0 / 0

18.06.2016, 00:48:16

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39263549

twinplay

Гость

Установил Patch 23179016 WINDOWS DB BUNDLE PATCH 12.1.0.2.160531.
Ощутимо это не ускорило запрос с IM.

xtendertwinplay,
ну и, безотносительно IM, добавьте FK с rely и установите query_rewrite_integrity=enforced, у вас тогда на 2 таблицы/хэшджойна меньше в запросе будет
Согласен про FK, но не стоит задача ускорить конкретно этот запрос. В данном случае rely disable замедлил запрос (особо не разбирался почему), enable ускорил ~ 1,5 раза (но insert замедляется).

Пока сделал для себя вывод, что IM дает ощутимые ускорения только в каких-то частных случаях и пока не конкурент аналитическим колоночным БД (Vertica, Greenplum). А надежда была :(

...

Рейтинг:

0 / 0

28.06.2016, 11:30:48

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39265042

opatch12c

Гость

xtendertwinplay,
Пока сделал для себя вывод, что IM дает ощутимые ускорения только в каких-то частных случаях и пока не конкурент аналитическим колоночным БД (Vertica, Greenplum). А надежда была :(

Вы на основании своего частного случая делаете такой глобальный вывод ...

...

Рейтинг:

0 / 0

29.06.2016, 22:11:45

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39265061

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

opatch12c,

я думаю, он тупо еще не прогонял такие же тесты на Вертике и Гринплуме

...

Рейтинг:

0 / 0

29.06.2016, 23:08:54

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39265655

twinplay

Гость

opatch12c, xtender,
Есть схема в Oracle 12c EE c несколькими десятками таблиц.
Есть аналогичная схема в HP Vertica 7.2 c теми данными.
Есть полсотни аналитических дэшбордов в BI Tool, взятые с реальных проектов, которые генерируют сотни запросов.

Кто работал с обоими этими СУБД, представляет разницу в производительности в аналитике.

В дополнение была сделана 3-я аналогичная схема с использованием Oracle IM. Приведенный в топике запрос взят, как типовой...

Если кто-то видел объективные бенчмарки Vertica vs Oracle IM, поделитесь ссылкой.

...

Рейтинг:

0 / 0

30.06.2016, 16:02:13

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39265763

ora601

Участник

Сообщения: 785

Рейтинг: 0 / 0

twinplay
Кто работал с обоими этими СУБД, представляет разницу в производительности в аналитике.

Зачем сравнивать кластер с сингл инстанс ?

...

Рейтинг:

0 / 0

30.06.2016, 17:08:10

| Ответить | Цитировать | Написать

In-Memory Option. Test Case

#39266059

twinplay

Гость

ora601twinplayКто работал с обоими этими СУБД, представляет разницу в производительности в аналитике.

Зачем сравнивать кластер с сингл инстанс ?

Тестовая схема развёрнута на Vertica с 1 нодой. Также используются только суперпроекции (т.е. нет доп. проекций для повышения производительности, индексов в Vertica не существует).

...

Рейтинг:

0 / 0

01.07.2016, 09:37:14

| Ответить | Цитировать | Написать

17 сообщений из 17, страница 1 из 1

Форумы / Oracle [игнор отключен] [закрыт для гостей] / In-Memory Option. Test Case

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39265763&tid=1887981]:	0ms
get settings:	14ms
get forum list:	20ms
check forum access:	3ms
check topic access:	3ms
track hit:	54ms
get topic data:	13ms
get forum data:	3ms
get page messages:	76ms
get tp. blocked users:	2ms
others:	230ms

total:	418ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы