Oracle Database In-Memory

Begin ner
Дата: 15.10.2015 12:19:38
почитал вот здесь:
Такое не забывается — Oracle Database In-Memory
ну, если читать все данные из таблицы (или какие-то определенные столбцы для всего набора данных в таблице), то понятно, за счет чего данные выбираются быстрее. а если у нас запрос с условиями в where по тем столбцам, которые не выбираются? что с того, что данные ПО СТОЛБЦАМ хранятся оптимальным образом? нам ведь надо соотносить ограничения по одним столбцам с выбираемыми данными из других столбцов, т.е. построчное хранение выглядит более оптимальным? короче не понял, откуда такой прирост производительности, о котором идет речь в статье. по семинарам мне некогда ходить. возможно, кто-то все это уже опробывал на работе и сможет объяснить, откуда такой прирост производительности? не получим ли мы прирост производительности для очень ограниченного круга задач? т.е. насколько это востребовано в реальных системах?
j2k
Дата: 15.10.2015 12:37:29
Begin ner, прирост производительности указан при отсутствии индексов. Когда построен индекс по выбираемым столбцам - прирост не так велик. Фишка в том, что данные по столцам хранятся упорядоченно, поэтому когда ты задаешь условие в where он читает только те столбцы, которые необходимы (причем может не читать некоторые блоки, которые не попали в нужный диапазон). Т.е. получается как доступ по индексу, в котором нет ненужных столбцов. Для DWH систем будет очень профитно, если еще учесть, что бизнес любит накладывать фильтры на любой столбец :)

PS Может презентацию, которая была вчера, таки выложат.
Begin ner
Дата: 15.10.2015 14:23:31
у кого Oracle 12c Enterprise? кто может поставить эксперимент и привести результаты, доказывающие, что это так выгодно, как об этом рассказывают?
Begin ner
Дата: 21.01.2016 11:23:54
ну? и как вам новая технология Database In-Memory
Валерий Юринский
Дата: 21.01.2016 12:53:18
Begin ner
ну? и как вам новая технология Database In-Memory
Технология замечательная.
Выборка выполняется очень быстро.
Удаление всех индексов, созданных для ускорение выборки данных,
улучшает скорость выполнения операций DML.

См. также http://www.sql.ru/forum/1145346/oracle-12c-inmemory

Дополнительные изменения и улучшения ожидаются в Oracle Database 12.2,
которая будет выпущена предположительно в первом полугодии 2016 календарного года.
oradb2
Дата: 21.01.2016 13:39:50
Begin ner
ну? и как вам новая технология Database In-Memory


Oracle из IM-кэша :

SQL> select  /*+ parallel(16) inmemory */ l_Shipdate, sum(l_extendedprice),count(*) from tpchusr.lineitem group by l_shipdate order by 1 desc;

L_SHIPDAT SUM(L_EXTENDEDPRICE)   COUNT(*)
--------- -------------------- ----------
01-DEC-98             40686568       1057
30-NOV-98             78270133       2080
...................................................................
...................................................................
03-JAN-92             77673033       2044
02-JAN-92             36724574        978

2526 rows selected.

Elapsed: 00:00:07.20


DB2 BLU c ...диска

db2inst1@hntst:~> time db2 "select l_Shipdate, sum(l_extendedprice),count(*) from c_lineitem group by l_shipdate order by 1 desc"

L_SHIPDATE 2                    3
---------- -------------------- -----------
12/01/1998             40686025        1057
11/30/1998             78269151        2080
11/29/1998            113001802        3014
.............................................................
.............................................................
01/03/1992             77672003        2044
01/02/1992             36724104         978

  2526 record(s) selected.


real    0m7.925s
user    0m0.064s
sys     0m0.092s


Оба на одном хосте. Таблица lineitem 300M строк и DOP=16 в обоих случаях.
Может "инмемори" не всегда и нужно ? ;-)
В im-кеш
Дата: 21.01.2016 14:17:06
oradb2
Oracle из IM-кэша :

 /*+ parallel(16) inmemory */ 
Так, а где статистика использования im и io?
oradb2
Дата: 21.01.2016 14:37:27
В im-кеш
Так, а где статистика использования im и io?


Вот как-то так :

SQL> select  /*+ parallel(16) inmemory */ l_Shipdate, sum(l_extendedprice),count(*) from tpchusr.lineitem group by l_shipdate order by 1 desc;

2526 rows selected.

Elapsed: 00:00:08.05

Execution Plan
----------------------------------------------------------
Plan hash value: 2461824725

---------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |          |  2526 | 32838 |  3260  (31)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                   |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (ORDER)              | :TQ10001 |  2526 | 32838 |  3260  (31)| 00:00:01 |  Q1,01 | P->S | QC (ORDER) |
|   3 |    SORT GROUP BY                  |          |  2526 | 32838 |  3260  (31)| 00:00:01 |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                    |          |  2526 | 32838 |  3260  (31)| 00:00:01 |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANGE                | :TQ10000 |  2526 | 32838 |  3260  (31)| 00:00:01 |  Q1,00 | P->P | RANGE      |
|   6 |       HASH GROUP BY               |          |  2526 | 32838 |  3260  (31)| 00:00:01 |  Q1,00 | PCWP |            |
|   7 |        PX BLOCK ITERATOR          |          |   300M|  3719M|  2698  (16)| 00:00:01 |  Q1,00 | PCWC |            |
|   8 |         TABLE ACCESS INMEMORY FULL| LINEITEM |   300M|  3719M|  2698  (16)| 00:00:01 |  Q1,00 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------------

Note
-----
   - Degree of Parallelism is 16 because of hint


Statistics
----------------------------------------------------------
         96  recursive calls
          0  db block gets
       1001  consistent gets
          0  physical reads
          0  redo size
      86363  bytes sent via SQL*Net to client
       2400  bytes received via SQL*Net from client
        170  SQL*Net roundtrips to/from client
         17  sorts (memory)
          0  sorts (disk)
       2526  rows processed

SQL> @/oracle/scripts/im_stat2

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
IM scan CUs cleanout                                                      0
IM scan CUs column not in memory                                          0
IM scan CUs columns accessed                                           7210
IM scan CUs columns decompressed                                          0
IM scan CUs columns theoretical max                                   57680
IM scan CUs failed to reget pin                                           0
IM scan CUs invalid                                                       0
IM scan CUs invalid (all rows are invalid)                                0
IM scan CUs invalid or missing revert to on disk extent                   0
IM scan CUs memcompress for capacity high                                 0
IM scan CUs memcompress for capacity low                                  0

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
IM scan CUs memcompress for dml                                           0
IM scan CUs memcompress for query high                                 3605
IM scan CUs memcompress for query low                                     0
IM scan CUs no cleanout                                                   0
IM scan CUs no memcompress                                                0
IM scan CUs no rollback                                                   0
IM scan CUs optimized read                                                0
IM scan CUs predicates applied                                            0
IM scan CUs predicates optimized                                          0
IM scan CUs predicates received                                           0
IM scan CUs pruned                                                        0

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
IM scan CUs rollback                                                      0
IM scan CUs split pieces                                               3962
IM scan CUs undo records applied                                          0
IM scan blocks cache                                                      0
IM scan bytes in-memory                                          2.3796E+10
IM scan bytes uncompressed                                       6.4080E+10
IM scan fetches journal                                                   0
IM scan found invalid smu                                                 0
IM scan invalid all blocks                                                0
IM scan journal                                                           0
IM scan journal cleanout                                                  0

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
IM scan journal no cleanout                                               0
IM scan rows                                                     2100040677
IM scan rows cache                                                        0
IM scan rows discontinuous                                                0
IM scan rows excluded                                                     0
IM scan rows journal                                                      0
IM scan rows journal total                                                0
IM scan rows optimized                                                    0
IM scan rows projected                                           2119088278
IM scan rows range excluded                                               0
IM scan rows valid                                               2100040677

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
IM scan segments disk                                                   250
IM scan segments minmax eligible                                          0

46 rows selected.

Elapsed: 00:00:00.01
SQL>
Begin ner
Дата: 25.01.2016 12:19:37
Валерий Юринский,

о... спс за презентацию :) выкладывайте еще, если что есть выложить! :)
Валерий Юринский
Дата: 02.06.2016 18:54:49
Валерий Юринский
Дополнительные изменения и улучшения ожидаются в Oracle Database 12.2,
которая будет выпущена предположительно в первом полугодии 2016 календарного года.
Выпуск Oracle Database 12.2 перенесен на второе полугодие 2016 календарного года.