How to Use the PowerPoint Template...売上インメモリ検索による表の結合処理の高速化

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

免責事項

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。他社名又は製品名は、それぞれ各社の商標である場合があります。

2


Oracle Database 12c Release 1 (12.1.0.2) CoreTech Seminar Oracle Database In-Memory: 検索処理の詳細

日本オラクル株式会社データベース事業統括製品戦略統括本部データベースエンジニアリング本部 Database & Exadata技術部丹羽勝久 2014/08/20


Agenda

カラム型データベースの検索処理の特徴

結合処理(join)

集計演算処理(aggregation)

1

2

3

4


結合処理(join)


2

3


Oracle Database In-Memory テクノロジーは各特性を持つ、2つのフォーマットを“両方同時に”メモリー上にロードし利用可能

高速な分析をリアルタイム化する新たな技術革新

5

DBにおける主要な2種類のフォーマット – ロー型 vs カラム型

ロー (行)型

OLTP処理を得意とするロー型

– 例：注文データの挿入と検索 – 少数の行(ロー)と多数の列(カラム)を高速処理

カラム (列)型

集計、分析処理を高速化するカラム型

– 例：都道府県毎の売上合計のレポート – 少数の列(カラム)と多数の行(ロー)を高速処理

売上

売上

概要再掲


高速な分析をリアルタイム化する新たな技術革新

6

インメモリ・デュアル・フォーマット

概要再掲

同一のデータを行型、カラム型双方のフォーマットで保持

インメモリ化指定したもののみ

双方のフォーマットを同時に利用可能トランザクションの一貫性も担保

集計、レポート処理はカラム型フォーマットに対して実行

OLTP処理は行型フォーマットに対して実行

メモリーメモリー

売上売上

行型フォーマット

カラム型フォーマット

1つのSales表というオブジェクトに対して2つのフォーマット

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 7

行型の表とカラム型の表の構造イメージ

123 ABC 04/02 12 350

789 XYX 12/01 43 720

56 GHI 11/10 2 50

432 SRE 2/22 8 143

PRODID CUSTID ORDATE QTY AMOUNT 123 789 56 432

ABC XYX GHI SRE

04/02 12/01 11/10 2/22

12 43 2 8

350 720 50 143

PRODID

CUSTID

ORDATE

QTY

AMOUNT

行ストア表カラム・ストア表

行列行1

行2

行3

行4

行1 行2 行3 行4


行4

行2

行3

行1

行ストアとカラム・ストアの格納イメージ行アクセスのイメージ

製品

Alpha

Beta

Alpha

Alpha

US

US

JP

UK

国売上

3,000

1,250

700

450

表イメージ行ストア

US Alpha 3,000

US Beta 1,250

JP Alpha 700 UK

Alpha 450

カラム・ストア

製品

売上

国

US US JP UK

Alpha Beta

Alpha Alpha 3,000 1,250 700 450

行

行

Select * from t1 where ……

行ストアは行全体のアクセスが効率的

8


行1

行4

行2

行3

行ストアとカラム・ストアの格納イメージ列アクセスのイメージ

製品

Alpha

Beta

Alpha

Alpha

US

US

JP

UK

国売上

3,000

1,250

700

450

表イメージ行ストア

US Alpha 3,000

US Beta 1,250

JP Alpha 700 UK

Alpha 450


製品

売上

国

US US JP UK

Alpha Beta

Alpha Alpha 3,000 1,250 700 450

列列

Select col1 from t1 ;

カラム・ストアは少数のカラム・アクセスが効率的

9


rowid

行2

行3

行1

行ストアとカラム・ストアの格納イメージ rowid付イメージ

rowid付表イメージ

行ストア

US Alpha 3,000

US Beta 1,250

JP Alpha 700


製品

売上

国

US US JP UK

Alpha Beta

Alpha Alpha 3,000 1,250 700 450

001

002

003

製品

Alpha

Beta

Alpha

Alpha

US

US

JP

UK

国売上

3,000

1,250

700

450

001

002

003

004

rowid

カラム・ストアも行の認識にrowidを利用

001 002 003 004

10


rowid

カラム型データベースの基本カラム・ストアから行データの実体化

sales_t 表：カラム・ストア

rowid付行データ

製品

Alpha

Beta

Alpha

Alpha

US

US

JP

UK

国売上

3,000

1,250

700

450

001

002

003

004

rowid select * from sales_t ;

カラム・ストアも行を特定する rowidを保有する

製品

売上

国

US US JP UK

Alpha Beta

Alpha Alpha 3,000 1,250 700 450

行データの実体化

001 002 003 004

11


SQLから見ると行型もカラム型も透過的

• select col1 from t1; • select * from t1; • select t1.region, t2.prod_type,

sum(t2.amount) from tab_row t1, tab_col t2 where t1.col1 = t2.col1 group by t1.region, t2.prod_type order by 1, 2;

• ….

行型もカラム型もどちらもリレーショナル・モデルを表現することに変わりはないためSQLの変更は必要なく、行型とカラム型表同士の結合処理も可能

※列単位アクセス

※ 行全体アクセス

※ 結合、集計、ソート

行型とカラム型表との結合処理も可能

12


OLTP トランザクション性能

OLAP分析処理性能

どちらかを性能向上するとどちらかにオーバーヘッドが発生

OLTPとOLAPの性能向上はトレードオフ

OLTPとOLAPを1つのデータベースで共存することは難しい

13


Oracle 12c Database In-Memory：デュアル・フォーマット

行型

カラム型

Select * from sales_t Where order_id = ‘ABC123’;

Select region, sum(amount) from sales_t Group by region;

Oracleデータベースオプティマイザ

sales_t表デュアル・フォーマット

Oracle 12c Database In-Memoryはデュアル・フォーマットなので、データベースのオプティマイザがSQLにあわせて最適なフォーマットを選択してSQLを処理します。(他社のインメモリ機能はハイブリッド型：オブジェクトをどちらの方式にするか決定する必要あり)

B-Tree索引を使用した処理

インメモリ検索を使用した処理

少数の行の全カラムのデータ取得

一部カラムを使った大量行の集計処理


Min 1 Max 3

Min 4 Max 7

Min 8 Max 12

Min 13 Max 15

15

カラム型表は何故分析用クエリーが高速か?

C1 C2 C4 C5 C6 C3

ポイント1：集計に必要なカラムのみアクセス＋効果的な圧縮技術により圧縮した状態で検索が可能 (ディクショナリ圧縮)

ポイント3：最新のプロセッサで搭載されているSIMDにより高速スキャン

ポイント4：パラレル・クエリーとパーティション表によりさらに高速化可能

ポイント2：インメモリ・ストレージ索引により最小限のIMCUのみスキャン

例) where storeid > 8

ベクター・レジスタ

複数のデータをロード

一度の命令で全ての値を

ベクター演算

CPU CA

CA CA

CA



SELECT COL4 FROM MYTABLE;

16

X X X X X

結果

行フォーマット

バッファ・キャッシュ

ポイント1-1：必要なカラムのみアクセス

X X X X X



SELECT COL4 FROM MYTABLE;

17

結果

カラム・フォーマット

インメモリ・カラム・ストア

X X X X

ポイント１-１：必要なカラムのみアクセス

データの読込量少ない

必要なカラムのみアクセス

X



非圧縮 ------------------ CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER ANALYST PRESIDENT SALESMAN CLERK CLERK ANALYST CLERK

ディクショナリ圧縮

カラム値ディクショナリ値ビット表現

ANALYST 0 000

CLERK 1 001

MANAGER 2 010

PRESIDENT 3 011

SALESMAN 4 100

001 100 100 010 100 010 010 000 011 100 001 001 000 001

97 bytes エンコードされた各行の値

カラム値サイズ合計＋ビット値合計 → 36 bytes + 3bit * 5 = 38 bytes

3bit * 14行 = 5.25bytes 38 + 5.25 = 44 bytes (1/2.2 圧縮)

ディクショナリ圧縮は圧縮した状態で検索が可能

Where job = ‘MANAGER’

Where job = 010

に内部的に変換 ※圧縮状態で検索可能

EMP表のJOB列

ディクショナリ(distinctされた値)

ソートされた値

行

ポイント1-2：ディクショナリ圧縮

18


各カラムは複数のカラム・ユニット(IMCU)で構成される

各IMCUで最小値/最大値を自動的に記録

WHERE句の条件に合致する領域だけを読み込み

すべての検索でパーティション・プルーニングと同様のパフォーマンスを提供


DRAM Select … From stores Where storeid > 8;

メモリー

SALES表カラム

フォーマット

Min 1 Max 3

Min 4 Max 7

Min 8 Max 12

Min 13 Max 15

IMCU

*1: IMCU - In-Memory Compression Unit

storeid

ポイント2：インメモリ・ストレージ索引 (※メモリー内に定義される)

IMCU

IMCU

IMCU

19


インメモリ・ストレージ索引の確認方法

• カラム内のIMCU数の確認 – V$IM_COL_CU ビュー

20

Select object_name, count(*) from v$im_col_cu, dba_objects Where objd = object_id And object_name = ‘<table name>’ And owner = ‘<owner>’ And column_number = 1 Group by object_name;

オブジェクト内のIMCU数の確認


IMCU内のディクショナリのエントリ数の確認

• IMCU内のディクショナリのエントリ数の確認 – V$IM_COL_CU ビュー

21

select

HEAD_PIECE_ADDRESS Address,

DICTIONARY_ENTRIES Dict_Entries

from v$im_col_cu, dba_objects

where objd = object_id

And object_name = 'PART'

and owner = 'SSB'

and column_number = 5

order by 1 ;

実行結果)

ADDRESS DICT_ENTRIES

---------------- ------------

0000000C41E00028 1000

0000000EC3400028 1000

0000000F7E800000 1000

IMCU内のエントリ数の確認例



• IMCU内のmin/max値の確認例 – V$IM_COL_CU ビュー

22

最小値、最大値はRAW(2000)という型で保持される



• IMCU内のmin/max値の確認例

23

col obj_name for a30

select

HEAD_PIECE_ADDRESS ADDRESS,

(select OBJECT_NAME from dba_objects

where DATA_OBJECT_ID = OBJD) OBJ_NAME,

UTL_RAW.CAST_TO_NUMBER(MINIMUM_VALUE) MIN_VALUE,

UTL_RAW.CAST_TO_NUMBER(MAXIMUM_VALUE) MAX_VALUE

from v$im_col_cu

where objd in ( select object_id from dba_objects

where object_name = ‘LINEORDER’ and owner = ‘SSB’ )

and column_number = 1

order by 1 ;

ADDRESS OBJ_NAME MIN_VALUE MAX_VALUE

---------------- -------------------- ---------- ----------

000000117AF00000 LINEORDER 7077415 297633600

000000117D200000 LINEORDER 8732546 299517094

000000117F500000 LINEORDER 1591875 292205029

0000001181800000 LINEORDER 3767936 294374018

VARCHAR2型列：UTL_RAW.CAST_TO_VARCHAR2 DATE型列： DBMS_STATS.CONVERT_RAW_VALUE (プロシージャ)



• 効果の確認方法 – V$MYSTAT (同一セッション内で確認) / V$SYSSTAT(システムレベル)

24

col display_name for a50

SELECT display_name, value FROM v$mystat m, v$statname n

WHERE m.statistic# = n.statistic# AND display_name IN (

'IM scan segments minmax eligible',

'IM scan CUs pruned',

'IM scan CUs column accessed',

'IM scan CUs predicates optimized' );

DISPLAY_NAME VALUE

----------------------------------------- ----------

IM scan CUs column accessed 585

IM scan CUs predicates optimized 542

IM scan CUs pruned 542

IM scan segments minmax eligible 1124


SIMDによる効果的な演算

SIMD： Single Instruction Multiple Data

通常の命令セットの場合(1組のデータ演算から１つの結果を算出)

SIMD命令セットの場合(複数のデータを1回の演算命令で高速実行)

レジスタ

ベクターレジスタ

CPU命令

CPU命令

A1 C1

CMPEQ

B1 A2 C2

CMPEQ

B2 A3 C3

CMPEQ

B3 A4 C4

CMPEQ

B4

4回繰返し

CMPEQ (SIMD) C1 C2 C3 C4 A1 A2 A3 A4

B1 B2 B3 B4

ベクターレジスタ

1回の命令で高速演算

ポイント3：最新のプロセッサで搭載されているSIMD命令セットにより高速スキャン

A1 B1 C1 ＝ ) →

A2 B2 C2 ＝ ) →

A3 B3 C3 ＝ ) →

A4 B4 C4 ＝ ) →

4回の一致比較の場合

IF (

IF (

IF (

IF (

25


インメモリ・カラム・ストア

26

カラム型表は何故分析用クエリーが高速か? ポイント３：最新のプロセッサで搭載されているSIMDにより高速スキャン

ベク

ター

・レ

ジス

タ

複数のデータをロード

一度の命令で全ての値を

ベクター演算

CPU

010

010

例: 「MANAGER」職種を検索 (MANAGER → 010)

001 100 100 010 100 010 010 000 011

100

001

110

100

010

010

MANAGER → 010 (エンコード値)

ディクショナリ圧縮により実データ値をビットデータとして扱うことでより多くのデータをCPUレジスタにロード可能

EMP表

JOB

JOBカラム値ディクショナリ値ビット表現

ANALYST 0 000

CLERK 1 001

MANAGER 2 010

PRESIDENT 3 011

SALESMAN 4 100

SIMD



インメモリ検索の実行プラン例

• 新しいアクセス方法

TABLE ACCESS INMEMORY FULL

• インメモリ検索を有効／無効化するパラメータ

INMEMORY_QUERY = {enable | disable}

ポイント4：インメモリ検索はパラレル・クエリー、パーティション表によりさらに高速化

27


カラム型表は何故分析用クエリーが高速か? ポイント4：インメモリ検索はパラレル・クエリー、パーティション表によりさらに高速化

インメモリ・スキャン＝ TABLE ACCESS INMEMORY FULL

基本的にFull Table Scanの発展系 → データはインメモリ・カラム型で圧縮 → 必要なカラムのみアクセス → インメモリ・ストレージ索引により

最低限のIMCUスキャン

QS

QS

QS

QS

パラレル・クエリーでさらに高速化

一部のパーティションをインメモリ化 → パーティション・プルーニングにより高速化

行型

カラム型

P1 P2 P3 P4


インメモリ・カラム・ストア(IMC)

29

Database In-Memoryとパラレル・クエリー

QS

QS

QS

QS

インメモリ･カラム・ストアなので対象データはメモリー内にある

In-Memory Parallel Executionと同様の動き

(Buffer CacheではなくIMC利用)

高速なインメモリ検索＋ • 必要なカラムのみアクセス

• 効果的な圧縮(高速検索) • 効率的なSIMD利用 • インメモリ・ストレージ索引

メモリー内で並列処理

基本的にディスク読込は発生しない

クエリースレーブ

autoDOPはインメモリ構成も考慮してパラレル度を決定


Agenda


結合処理(join)


1

2

3

30


結合処理(join)


2

3


売上

インメモリ検索による表の結合処理の高速化

インメモリ・カラム・ストアにより複数表の結合処理を高速化

1. ジョイン・フィルタと呼ばれるフィルタをカラム検索を使用して作成

店舗表のTYPE=‘OUTLET’ に該当する StoreIDをリスト

2. 作成したジョイン・フィルタの条件にあう売上表のAMOUNTの合計値を計算

ジョイン・フィルタから以下の条件を生成「where StoreID in (15, 38, 64)」

上記の条件にヒットする行の売上表単体のカラム検索により高速にAMOUNT列の合計値を算出 ( SUM(AMOUNT) )

31

例：直販店(outlet)の売上合計を集計

店舗

Type=Outlet

Sto

re ID

Typ

e

合計値

複数表の結合処理を内部的に高速カラム検索に変換 (ベクター結合)

ジョイン・フィルタ

インメモリ固有の機能ではないがインメモリ検索で非常に効果的

StoreID in 15, 38, 64

Sto

re ID

Am

ou

nt


ベクター結合の実行計画例

①ジョイン・フィルタ作成(DATE_DIM) ※:BF0000 (ブルーム・フィルタ)

②ジョイン・フィルタ利用したLINEORDER表のカラム検索

※この例はパラレル・クエリー実行

実行SQL)

select

sum(lo_revenue*lo_discount)

from lineorder, date_dim

where lo_orderdate = d_datekey

and d_year = 1996;


売上

33

複数表のベクター結合の実行イメージ例：直販店(outlet)のT-Shirtsの合計売上を集計

店舗

Type=Outlet

Sto

re ID

Typ

e

合計値


商品

Category=T-Shirts

Cat

ego

ry

Pro

dID


３つの表のジョイン処理を売上表の単一のカラム検索に変換

Sto

re ID

Am

ou

nt StoreID in

15, 38, 64 ProdID in

100, 219, 872

Pro

d ID


複数表のベクター結合の実行計画例

ジョイン・フィルタ作成

ジョイン・フィルタ利用


Swap Join Input Optimization

Left deep tree

PART

HASH JOIN

LINEORDER

HASH JOIN

SUPPLIER

HASH JOIN

DATEDIM

1 2

3

4

1

2

3

HASH JOINを順番に実施 (今までの実行プラン)

35


Swap Join Input Optimization

right deep tree

PART

HASH JOIN

LINEORDER

HASH JOIN

SUPPLIER

HASH JOIN

DATEDIM

2

3

1

2

3

1

4

複数のジョイン・フィルタを利用してファクト表の高速カラム検索

何故この機能が重要か?

LINEORDERをマルチプルフィルタを利用して初期スキャンを

することにより

上位の実行プランで処理する行数を縮小する

複数のジョインフィルタによる LINEORDER表 (ファクト表)の高速カラム型検索

ジョインフィルタ作成



36


ジョイン・フィルタを使ったジョイン処理のイメージ

0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1

ジョインフィルタ



②ジョインフィルタの利用

フィルタ列カラム検索

ジョイン列のフィルタ

生成



生成



生成

③フィルタ条件にマッチするファクト表(最大件数表)の列、行を抽出

①ジョインフィルタの作成

④検索結果を生成するためにジョイン・バック


通常の結合処理との実行コスト比較

Select p.p_name, sum(l.lo_revenue*1.00212/3.12388832)

From PART p, LINEORDER l

where l.lo_partkey = p.p_partkey

and p.p_name in (

‘hot lavender’ , ‘violet grey‘ , 'rose pink’,

'yellow grey‘ , 'white snow‘ , 'spring olive‘

Group by p.p_name;

38

SQL例


通常の結合処理との実行コスト比較インメモリ検索のベクター結合を無効化

SQL> /

Elapsed: 00:01:18.31

------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 6 | 186 | 79134 (40)| 00:00:04 |

| 1 | HASH GROUP BY | | 6 | 186 | 79134 (40)| 00:00:04 |

|* 2 | HASH JOIN | | 586K| 17M| 79092 (40)| 00:00:04 |

|* 3 | TABLE ACCESS INMEMORY FULL| PART | 1003 | 20060 | 206 (31)| 00:00:01 |

| 4 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 6294M| 74051 (36)| 00:00:03 |

------------------------------------------------------------------------------------------

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.12 0.12 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 76.16 76.16 0 7 0 6

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 76.28 76.28 0 7 0 6


通常の結合処理との実行コスト比較インメモリ検索のベクター結合を有効化

SQL> /

Elapsed: 00:00:13.02

-------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

-------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 6 | 186 | 79134 (40)| 00:00:04 |

| 1 | HASH GROUP BY | | 6 | 186 | 79134 (40)| 00:00:04 |

|* 2 | HASH JOIN | | 586K| 17M| 79092 (40)| 00:00:04 |

| 3 | JOIN FILTER CREATE | :BF0000 | 1003 | 20060 | 206 (31)| 00:00:01 |

|* 4 | TABLE ACCESS INMEMORY FULL| PART | 1003 | 20060 | 206 (31)| 00:00:01 |

| 5 | JOIN FILTER USE | :BF0000 | 600M| 6294M| 74051 (36)| 00:00:03 |

|* 6 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 6294M| 74051 (36)| 00:00:03 |

-------------------------------------------------------------------------------------------

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.12 0.12 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 12.48 12.48 0 7 0 6

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 12.61 12.61 0 7 0 6


Agenda


結合処理(join)


1

2

3

41


結合処理(join)


2

3


インメモリ検索による表の集計処理の高速化

42

ベクターGroup By(Vector Group By)

例: アウトレットでの靴の売上を集計

売上表

店舗表

商品表インメモリ・レポート

アウトライン

Footwear

Ou

tlet

s $ $$

$ $$$

Footwear

Sales Outlets

レポート・アウトラインをメモリー上に動的に作成(インメモリ配列)

レポート内の集計値はファクト表のスキャン中に展開

事前定義された多次元

キューブを使わずに高速化

インメモリ固有の機能ではないがインメモリ検索で非常に効果的


例)OutletのFootwearの売上をブランド、地域ごとに集計する

インメモリ集計: 詳細イメージ

ID Name SType Region …

1 ABC Dept Store APAC …

2 XYZ Outlet NAS …

3 CCC Outlet EMEA …

… … … … …

ストア表(Stores)

ID Name Category Brand …

1 XS-1234 T-Shirt PUMA …

2 AJ-2322 Footwear FILA …

3 PW-698 Footwear NIKE …

… … … … …

商品表(Products)

ID Ord Date Prod_ID Store_id Sales

1 2012/7/2 2 5 10

2 2012/7/14 6 4 20

3 2012/9/25 7 1 8

4 2013/4/8 7 2 5

… … … … …

売上表(Sales)

Select st.region, p.brand, sum( s.sales ) From stores st, products p, sales s Where st.id = s.store_id And p.id = s.prod_id And st.Stype = ‘Outlet’ And p.category = ‘Footwear’ Group by st.region, p.brand

フィルタ条件

グループキー (Key Vector)

OutletのFootwearの売上をブランド、地域ごとに集計

アニメーション

結合キー


1 2 3 4 5 6

1

2

3

インメモリ集計: 詳細

TIME_ID

10

20

15

Stores

Products

革新的な技術: スター・スキーマのジョインと集計処理にメモリー上の配列(インメモリ配列)を使う

Sales

1 2 3 4 5 6 7 …

0 3 1 5 0 4 3 …

1 2 3 4 5 6 7 8 9 10 …

0 1 3 2 1 0 0 0 1 3 …

Stores DGK (REGION)

インメモリ・レポート・アウトライン

Pro

du

cts

DG

K

(BR

AN

D)

PROD_ID

BRAND

(Key Vector)

STORE_ID

REGION (Key Vector)

PROD_ID SALES STORE_ID

①フィルタ条件

②結合キー＋Key Vector配列を

作成しフィルタ条件に一致しないKey Vector値は「0」を設定

(Key Vector値＝グループ集計カラム値)

③DGK(Dense Grouping Key)値で構成される集計値を格納する

インメモリ配列の作成

アニメーション

44


実行計画から見るベクター Group By (1)

DIM_CUST_IMC表のインメモリ検索をしてKey Vector(:KV0001)を作成する。このKey VectorはFACT_IMC表との結合キーとグルーピング列のKey値を保存する。



次にVector Group Byを実行することでDGK (Dense Grouping Keys) を生成し、さらに検索結果表示に必要な他のカラムもあわせて一時表に保存する。



他のディメンジョン表に対しても同様の処理を行う。この例では、DIM_TIME_IMC表のKey Vectorの作成、Vector Group Byによる一時表の作成を行う。


実行計画から見るベクター Group By(４)

Key Vectorを利用して、結合キーのフィルタを適用しながらファクト表(FACT_IMC)の単体スキャンを行う。


実行計画から見るベクター Group By(５)

スキャンされたファクト表(FACT_IMC)の集計対象列による集計処理を行う。集計処理は内部的に作成されたインメモリ配列に随時格納することで行われる。


実行計画から見るベクター Group By(６)

(5)で作成されたインメモリ配列とVector Group Byで作成された一時表をジョイン・バックすることでグルーピング列の値を取得して最終結果を生成する。


ベクター Group By – 実行例 SQL Select d.d_year, c.c_nation, sum(lo_revenue - lo_supplycost) profit From LINEORDER l, DATE_DIM d, PART p, SUPPLIER s, CUSTOMER C Where l.lo_orderdate = d.d_datekey And l.lo_partkey = p.p_partkey And l.lo_suppkey = s.s_suppkey And l.lo_custkey = c.c_custkey And s.s_region = 'AMERICA’ And c.c_region = 'AMERICA’ Group by d.d_year, c.c_nation Order by d.d_year, c.c_nation;


通常の集計処理との実行コスト比較

インメモリ検索－ベクター Group By無効化 Elapsed: 00:00:51.11

52

比較結果

Statistics

----------------------------------------------------------

456 recursive calls

60 db block gets

15602 consistent gets

105 physical reads

0 redo size

8073 bytes sent via SQL*Net to client

673 bytes received via SQL*Net from client

13 SQL*Net roundtrips to/from client

9 sorts (memory)

0 sorts (disk)

175 rows processed


通常の集計処理との実行コスト比較

インメモリ検索－ベクター Group By有効化 Elapsed: 00:00:28.57

53

比較結果

Statistics

----------------------------------------------------------

90 recursive calls

41 db block gets

132 consistent gets

4 physical reads

3792 redo size

8073 bytes sent via SQL*Net to client

673 bytes received via SQL*Net from client

13 SQL*Net roundtrips to/from client

11 sorts (memory)

0 sorts (disk)

175 rows processed


まとめ

• インメモリ検索は分析クエリーが高速 –余分なカラム読込なし

–効果的な圧縮方法－圧縮した状態で高速検索 (ディクショナリ検索)

–必要最低限の領域(IMCU)のみアクセスするインメモリ・ストレージ索引

–SIMDによる高速スキャン

–パラレル・クエリー、パーティション表との相性が良い

• インメモリ化することで結合処理、集計演算も高速 –ベクター結合(ブルーム・フィルタ)による高速結合処理

–ベクターGroup By(Key Vector、インメモリ配列)による高速集計処理

54


リファレンス

• ベクター結合 (Vector Join) – Oracle® Databaseデータ・ウェアハウス・ガイド 12c リリース1 (12.1)

• ベクトル結合を使用した結合パフォーマンスの向上

http://docs.oracle.com/cd/E57425_01/121/DWHSG/ch2logdes.htm#CIHGBAFF

• ベクターGroup By (Vector Group By) – Oracle® Databaseデータ・ウェアハウス・ガイド 12c リリース1 (12.1)

• インメモリ集計

http://docs.oracle.com/cd/E57425_01/121/DWHSG/aggreg.htm#BCGFFGBA

– Oracle® Database SQLチューニング・ガイド 12c リリース1 (12.1) • 5.7 インメモリー集計

http://docs.oracle.com/cd/E57425_01/121/TGSQL/tgsql_transform.htm#BABFGEAE

55

マニュアル・ドキュメント

http://docs.oracle.com/cd/E57425_01/121/DWHSG/ch2logdes.htm

http://docs.oracle.com/cd/E57425_01/121/DWHSG/aggreg.htm

http://docs.oracle.com/cd/E57425_01/121/TGSQL/tgsql_transform.htm

http://docs.oracle.com/cd/E57425_01/121/TGSQL/tgsql_transform.htm


Appendix

56


単純集計演算処理

• 12.1.0.2 beta3使用

57

0

20

40

60

80

100

SUM c1, SUM c1, c2 SUM

100 100 100

2.07 4.31 5.23

11g

12cインメモリ

1. Select SUM(c4) from t1; 2. Select c1, SUM(c4) from t1 group by c1; 3. Select c1, c2, SUM(c4) from t1 group by c1, c2;

使用したSQL (t1表は50億件)

11gの応答速度を100とした場合の 12cインメモリの相対的な値 ※両方ともパラレル・クエリー使用


Documents

How to Use the PowerPoint Template...売上 インメモリ検索による表の結合処理の高速化

How to Use the PowerPoint Template...売上インメモリ検索による表の結合処理の高速化