Safe Harbor Statement 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではな

第138回夜な夜な! なにわオラクル塾

Oracle12c Database In-Memory

入門！

日本オラクル株式会社

データベース事業統括

ソリューション本部

中部・西日本SC部

2015年01月28日

Presented with

Safe Harbor Statement

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とす

るものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供すること

をコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。

オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標また

は商標です。

他社名又は製品名は、それぞれ各社の商標である場合があります。

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

Oracle Database In-Memoryの開発ゴール

OLTPの

高速化

リアルタイム

アナリティクス

アプリケーション

の変更なし

最新世代の

H/Wを有効活用

CPU

100x

2x

Oracle Database In-Memory Option

既存データベースの概念を根底から覆すテクノロジー

•

お客様の既存資産（データとアプリケーション）の完全なる保護と継承

•

Oracle Databaseの卓越した高可用性とセキュリティ機能をそのまま利用可能

•

完全なるデュアルフォーマットの提供により、OLTPとDWHの完全なる融合

•

情報系からのインデックス排除による開発・運用コストの劇的な削減

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

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

Oracle Database In-Memory テクノロジーは、各特性を持つ

ロー

(行)型



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

–

例：注文データの挿入と検索

–

少数の行(ロー)と多数の列(カラム)を高速処理

カラム

(列)型



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

–

例：都道府県毎の売上合計のレポート

–

少数の列(カラム)と多数の行(ロー)を高速処理

売上

売上

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

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



同一のデータを行型、カラム型双方

のフォーマットで保持



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



双方のフォーマットを同時に利用可能

トランザクションの一貫性も担保



集計、レポート処理はカラム型

フォーマットに対して実行



OLTP処理は行型フォーマットに

対して実行

メモリー

メモリー

売上

売上

行型

フォーマット

フォーマット

カラム型

1つのSales表というオブジェクトに

対して2つのフォーマット

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

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

OLTP

トランザク

ション性能

OLAP分析

処理性能

OLTPとOLAPを1つのデータベースで

共存することは難しい

一般的なOLTPとDWHの構成

•

OLTPとDWHは別のHWで動作し、連携はバッチで同期を取っている

–

DWH用のHWやDatabaseライセンスコストがかかる

–

リアルタイムにデータが見れない

–

夜間バッチのパフォーマンスのためにリソース強化

OLTP

夜間バッチで1日1回 同期

DWH

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索引を

使用した処理

インメモリ検索を

使用した処理

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

取得

アプリケーションの変更は不要

機能性

- SQLの制限なし

実装容易性

- データマイグレーションの必要なし

互換性

- 全ての既存アプリケーションは改修なく動作

マルチテナント

- クラウド対応済み

アプリケーションの変更なく、インメモリのメリットを享受

Min 1

Max 3

Min 4

Max 7

Min 8

Max 12

Min 13

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

C1

C2

C3

C4

C5

C6

ポイント1：

集計に

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

ポイント4：

_{最新のプロセッサで搭載されている}

SIMDにより高速スキャン

ポイント5：

ポイント3：

インメモリ・ストレージ索引により

最小限のユニットのみスキャン

例) where storeid > 8

ベクタ

ー・レジスタ

複数の

データを

ロード

一度の命令で

全ての値を

ベクター演算

CPU

CA

CA

CA

CA

ポイント2：

効果的な圧縮技術により

圧縮した状態で検索が可能

(ディクショナリ圧縮)

ポイント1： 必要なカラムのみアクセス(行フォーマット型の場合)

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

SELECT COL4 FROM MYTABLE;

X

X

X

X

X

結果

行フォーマット

バッファ・キャッシュ

X X X X X

X

X

X

X

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

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

結果

カラム・フォーマット

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

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

ポイント1： 必要なカラムのみアクセス(実行計画)

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

インメモリ検索の実行計画例



新しいアクセス方法

TABLE ACCESS INMEMORY FULL



インメモリ検索を有効／無効化する

パラメータ

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

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

非圧縮

---

CLERK

SALESMAN

SALESMAN

MANAGER

SALESMAN

MANAGER

MANAGER

ANALYST

PRESIDENT

SALESMAN

CLERK

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

ディクショナリ圧縮は

圧縮した状態で検索

が可能

Where job = ‘MANAGER’

Where job = 010

に内部的に変換

※圧縮状態で検索可能

EMP表のJOB列

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

ソ

ー

ト

さ

れ

た

値

行

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

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

•

各カラムは複数のIMCUで構成さ

れる

•

各IMCUで最小値/最大値を

自動的に記録

•

WHERE句の条件に合致する領域

だけを読み込み

•

すべての検索でパーティション・プ

ルーニングと同様の

パフォーマンスを提供

メモリー

SALES表

カラム

フォーマット

Min 1

Max 3

Min 4

Max 7

Min 8

Max 12

Min 13

Max 15

IMCU

storeid

IMCU

IMCU

IMCU

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

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

ベクターレジスタ

A1

＝

B1

) →

C1

A2

＝

B2

) →

C2

A3

＝

B3

) →

C3

A4

＝

B4

) →

C4

4回の一致

比較の場合

IF (

IF (

IF (

IF (

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

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

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

ベ

ク

タ

ー

・

レ

ジ

スタ

複数の

データを

ロード

一度の命令で

全ての値を

ベクター演算

CPU

010

010

例: 「MANAGER」職種を検索

(MANAGER → 010)

001 100 100 010 100 010 010 000 011

100

001

110

100

010

010

ディクショナリ圧縮により

実データ値をビットデータとして

扱うことで

より多くのデータを

CPUレジスタにロード可能

EMP表

JOB

JOBカラム値

ディクショナリ値

ビット表現

ANALYST

0

000

CLERK

1

001

MANAGER

2

010

PRESIDENT

3

011

SALESMAN

4

100

SIMD

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

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

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

基本的にFull Table Scanの発展系

→ データはインメモリ・カラム型で圧縮

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

QS

QS

QS

QS

パラレル・クエリーで

さらに高速化

一部のパーティションをインメモリ化

→ パーティション・プルーニングにより高速化

カラム

型

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

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

QS

QS

QS

QS

インメモリ･カラム・ストアなので

対象データはメモリー内にある

In-Memory Parallel

Executionと同様の動き

(Buffer CacheではなくIMC利用)

高速なインメモリ検索

＋



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



効果的な圧縮(高速検索)



効率的なSIMD利用

インメモリ・ストレージ索引

メモリー内で

並列処理

基本的にディスク

読込は発生しない

クエリー

スレーブ

autoDOPはインメモリ構成も

考慮してパラレル度を決定

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

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

売上



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

複数表の結合処理を高速化

1. ジョイン・フィルタと呼ばれるフィルタを

カラム検索を使用して作成

 店舗表のTYPE=‘OUTLET’ に該当する

StoreIDをリスト

2. 作成したジョイン・フィルタの条件にあう

売上表のAMOUNTの合計値を計算

 ジョイン・フィルタから以下の条件を生成

「where StoreID in (15, 38, 64)」

 上記の条件にヒットする行の売上表

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

店舗

Type=Outlet

St

or

e

ID

Typ

e

ジョイン・フィルタ

StoreID in

15, 38, 64

St

or

e I

D

Amoun

t

ベクターGroup By(Vector Group By)

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

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

売上表

商品表

店舗表

インメモリ・レポート

アウトライン

Outlets

Footw

ear

$

_$$

$

$$$

Outlets

Sales

Footwear



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

上に動的に作成(インメモリ配列)



レポート内の集計値は

ファクト表のスキャン中に展開



事前定義された多次元

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

インメモリ固有の機能ではないが

インメモリ検索で非常に効果的

分析基盤におけるインデックスが不要

•

既存Oracle Databaseによる分析基盤

–

インデックスは事前予測可能な

パターンのみ高速化

–

更新処理は10～20個のインデックスの更新が必要

•

パフォーマンス低下の原因

•

Oracle Database In-Memoryの適用

–

インデックスなしですべての

カラム(列)の処理を高速化

–

カラム型ストアはディスクI/Oなし

表

1 ～ 3

OLTP用

インデックス

10 ～ 20

分析用

インデックス

表

インメモリ

カラム型

ストア

1 ～ 3

OLTP

インデックス

スケールアウト構成 – RACとの組み合わせ例 1/2

アプリケーションから透過的に表パーティション毎に柔軟な分散配置を構成可能

•

分散配置

–

大規模データを各ノードで分割して保持

–

ROWIDもしくはパーティションで分割

–

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

スケールアウトが可能

–

In-Memory Parallel Queryと組み合わせによるインメモリ

並列処理が可能

•

複製配置

–

小規模データを各ノード重複して保持

–

2ノードもしくはすべてのノードに複製

–

ノード耐障害性の向上

–

In-Memory Parallel Queryと組み合わせによるインメモリ

並列処理が可能

Real Application Clusters

スケールアウト構成 – RACとの組み合わせ例 2/2

アプリから透過的にテーブル・パーティション毎に柔軟な分散配置を構成可能

•

分散＋複製配置

–

大規模データを各ノードで分割し保持

•

インメモリ・カラム・ストアのスケールアウトが可能

–

In-Memory Parallel Queryと組み合わせによる

インメモリ並列処理

•

各ノードのCPUを有効活用

–

複製データにより可用性を向上し、

障害時の再インメモリ化(ポピュレーション)時間

を削減

–

スケーラブルな可用性の高い

並列分析処理基盤の構築が可能

Real Application Clusters

In-Memory Parallel Query

複

製

デ

ー

タ

（

Dup

lic

at

e

2

可用性・セキュリティを既存の仕組みで実装可能

•

既存のOracle Databaseの信頼性・可用性・拡張性・セキュリティに

関わる機能をOracle Database In-Memoryでも透過的に利用可能

•

ストレージ・フォーマット、ロギング、

バックアップ/リカバリなどの運用管理に

影響なし

•

既存のOracle Databaseの可用性機能は

透過的に動作

•

既存のOracle Databaseのデータ保護機能も

透過的に動作

–

ノード障害、サイト障害、データ破損、

人的エラーなど

基本導入手順（設定・運用管理）

本当に効果が

あるデータは

何か？

インメモリ・カラ

ム・ストアの

サイズは？

インメモリ・カラ

ム化する

データの選択

不要な

インデックスを

削除

インメモリ・カラ

ム・ストアの

状況監視

事前調査

基本３ステップ

運用管理

容易な設定作業のみで実装可能

1.

使用するメモリ容量を設定

inmemory_size = XXX GB

2.

メモリー上に格納するテーブル、パーティションを選択

alter table | partition … inmemory;

TimesTen In-Memory Database

更なるOLTPレイテンシを要求される場面でIn-Memory Technologyを補完

150マイクロ秒の

ネットワーク処理

アプリケーション

同アドレス空間

N

E

T

5マイクロ秒で

SQLを実行

TIMESTEN

IN-MEMORY DATABASE

アプリケーションとデータベース間の

ネットワーク・レイテンシによるOLTP

処理遅延

-

_{呼制御、 株式トレーディング、他}

TimesTen In-Memory Database

非常に軽量で高速なインメモリDB

-

_{非常に軽量で高速なインメモリデータベース}

-

_{アプリケーションのアドレス空間で稼働}

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

インメモリ・カラム・ストアの基本構成

•

SGA内の新たな領域として、

インメモリ領域を追加

•

INMEMORY_SIZE

パラメータによりサイズ設定

–

最小値は100MB

•

SGA_TARGET は十分に

大きな値の設定が必要

•

静的プールとして確保

System Global Area (SGA)

Buffer Cache

Shared Pool

Redo Buffer

Large Pool

Other shared

Memory

Components

In-Memory

Area

INMEMORY_SIZE

パラメータ

インメモリ領域: SGA内の新しい領域

•

INMEMORY_SIZE

初期化パラメータ

•

100MB が設定可能な最小値

•

SGA_TARGET に十分な

空きが必要

•

スタティック(静的) なプール

•

変更後再起動

SELECT * FROM V$SGA;

NAME

VALUE

--- ---

Fixed Size 2927176

Variable Size 570426808

Database Buffers 4634022912

Redo Buffers 13848576

In-Memory Area 10244836480

確認方法

インメモリ領域: 構成

•

２つのサブプールで構成:

–

IMCU(1MB)プール:

IMCU(In-Memory Compression Units)を格納

•

1MBの倍数単位で使われる

•

連続領域、エクステント

–

SMU(64KB)プール:

SMU(Snapshot Metadata Units)を格納

•

64KB 1 つの中で完結

•

更新時に使用量が増える

•

IMCUはカラム書式のデータを格納

•

SMUはメタデータとトランザクション情報を格納

–

1 IMCU の管理情報を格納する SMU Extentが1個作られる

–

inmemory_size パラメータで指定したサイズの約 20 %が自

動で 64KB プールにされる

インメモリ領域

SMU SMU

SMU SMU

SMU SMU

SMU SMU

IMCU

IMCU

IMCU

IMCU

IMCU

IMCU

IMCU

IMCU

IMCUプール(1MB)

SMUプール

(64KB)

インメモリ領域：確認

•

V$INMEMORY_AREA:

現状の各プールのサイズと状態を表示

col pool for a10

col status for a20

select pool, alloc_bytes/1024/1024 alloc_MB,

used_bytes/1024/1024 used_MB,

(alloc_bytes - used_bytes)/1024/1024 free_MB

from v$inmemory_area;

POOL ALLOC_MB USED_MB FREE_MB

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

1MB POOL 57338 42153 15185

割当領域

使用領域

空き領域

インメモリ領域：使用状況

•

空きがある状態

–

通常 64KB Pool の方が "空き率" が大きい。

•

空きがない状態

–

64KB Pool の方があふれることはない

SQL> select * from v$inmemory_area;

POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID

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

1MB POOL 171781914624 81371594752

DONE

0

64KB POOL 42932895744 298975232

DONE

0

SQL> select pool,alloc_bytes,used_bytes,populate_status from v$inmemory_area;

POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS

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

1MB POOL 8186232832 8186232832

OUT OF MEMORY

64KB POOL 2063597568 26345472 DONE

• インメモリ領域があふれる場合

‐

バックグラウンドプロセスの trc ファイルに以下が出力される

•

ORA-64356: in-memory columnar area out-of-space

‐

alert.log に以下が出る

ポピュレーション(population) とは

•

データをディスクからインメモリ・カラム・ストアへ

載せる動作

•

ポピュレーションは既存データをメモリー中に

最適化されたカラム型フォーマットで取り込む

–

ポピュレーションは新しいデータを取り込まない

•

ロギングのためのディスクI/Oなし

•

データ更新のオーバーヘッドを極小化

–

ポピュレーションのリクエストはキューに入れられる

•

2分間隔でキューから取り出されタスクが実行される

•

キューは優先度が指定される

•

ポピュレーションはバックグラウンドで実行される

–

ORA_W001_orcl プロセス

•

プロセス数はINMEMORY_MAX_POPULATE_SERVERS

初期化パラメータ(新規)で設定

SALES

インメモリ領域

ポピュレーション : オブジェクト(セグメント)属性

•

INMEMORY 新属性

•

以下のセグメントの種類がサポートされる

–

表

–

パーティション

–

サブパーティション

–

マテリアライズド・ビュー、マテリアライズド・ビュー・ログ

•

代表的なサポートされないセグメントの種類

–

外部表

–

IOT(インデックス構成表)

–

クラスタ化テーブル

–

Out of line LOB

–

CREATE TABLE customers ……

PARTITION BY LIST

(PARTITION p1 ……

INMEMORY

,

(PARTITION p2 ……

NO INMEMORY

);

ALTER TABLE sales

INMEMORY

;

カラム・レベルでの指定(selective column機能)

•

列単位でのインメモリ指定が可能

–

Alter Table文で指定

•

V$IM_COLUMN_LEVEL ビュー で確認

–

select table_name, column_name, inmemory_compression from v$im_column_level

•

パーティション毎に異なる設定はできない

–

ORA-14049: invalid ALTER TABLE MODIFY PARTITION option

ALTER TABLE sales

INMEMORY

NO INMEMORY

(PROD_ID);

EM Cloud Control での設定も可能

サポートされないカラム

•

LONG

•

Inline でない CLOB, BLOB

•

4KB 以上の VARCHAR2

•

ネストされたテーブルカラム

•

仮想カラムはカラムレベルではサポートされない

–

ORA-64359: INMEMORY clause may not be specified for virtual columns

AWR: インメモリ・セグメント統計

•

AWR レポートにインメモリ・

セグメント統計が追加

–

V$IM_HEADER の

TIME_TO_POPULATE カラムで

ポピュレーションにかかった

時間を確認可能

IMCU： In-Memory Compression Unit

•

カラム型オブジェクトの管理単位

–

カラム型データをある程度の行数のセットで

保持（例：50万行程度）

–

格納される行は１つ以上の

表エクステントから取得

•

IMCUの実サイズは行サイズ、

圧縮率等により変化

（固定値ではない）

•

カラム毎に分離／近接した

カラム・ユニット(CU)として保存

–

Rowidも同様に１つのCUとして保存

IMCUヘッダー

Extent #13

Blocks 20-120

Extent #14

Blocks 82-182

Extent #15

Blocks 201-301

ROWID

E

MP

ID

NAME

DEPT

SALARY

カラム・ユニット(CU)

IMCU

行型フォーマットとカラム型フォーマット

On-Disk 表領域: 行型フォーマット

Data file 1

Data file 2

Data file N

Segment

Extent

Extent

Extent

Extent

Block

Block

Row

In-Memory Area

IM Segment

IMCU

IMCU

In-Memory Area: カラム・ストア

IMCU = In-Memory Compression Unit

CU = Column Unit

IMCU 分割基準

•

行数、または、サイズ

–

数十万行、数100MB程度

–

行長平均が小さい場合、行数で分割される

•

ポピュレーション時に分割し１プロセスが １つの IMCU作成

•

HCC(Hybrid Columnar Compression) と比較するとユニットサイズは大きい

•

特別なカラム・ユニット(CU)

–

ROWID CU

IMCUの確認(1) – 各オブジェクトのIMCU数

•

V$IM_HEADER:

現在のインメモリ・カラム・ストア内のIMCU数の確認

col object_name for a20

SELECT OBJECT_NAME, count(*) NUM_IMCU

FROM V$IM_HEADER i, DBA_OBJECTS o

WHERE i.objd = o.object_id

group by object_name order by 1;

OBJECT_NAME NUM_IMCU

--- ---

CUSTOMER 3

DATE_DIM 1

LINEORDER 563

IMCU数

IMCUの確認(2)

•

V$IM_HEADER:

現在のインメモリ・カラム・ストア内のIMCUのリスト

col object_name for a20

col tsname for a15

SELECT OBJECT_NAME,ts.NAME TSNAME,ALLOCATED_LEN/1024/1024 ALLOC_MB,NUM_ROWS, NUM_COLS

FROM V$IM_HEADER i, DBA_OBJECTS o, v$tablespace ts

WHERE i.objd = o.object_id and i.tsn = ts.ts#

order by 1, 2;

OBJECT_NAME TSNAME ALLOC_MB NUM_ROWS NUM_COLS

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

CUSTOMER TS_DATA 39 495602 8

CUSTOMER TS_DATA 33 415593 8

CUSTOMER TS_DATA 47 588805 8

DATE_DIM TS_DATA 1 2556 17

PART TS_DATA 1 14807 9

PART TS_DATA 14 591442 9

PART TS_DATA 14 593751 9

SUPPLIER TS_DATA 8 100000 7

IMCUサイズ IMCU内行数 カラム数

CU：カラム・ユニット (Column Unit)

•

IMCUに格納されている各カラム値の

管理単位

•

全CUは自動的に最小／最大値を保存

–

インメモリ・ストレージ索引

•

圧縮フォーマット

–

例）ディクショナリ圧縮

CUは実際の値ではなく、サイズの小さい

ディクショナリIDをデータ値として格納

→ 圧縮した状態で検索が可能

–

他の圧縮方式と組合わせることも可能

CU

2

0

2

1

2

0

BMW

Audi

BMW

Cadillac

BMW

Audi

カラム値リスト

VALUE ID

Audi 0

BMW 1

Cadillac 2

_{Max: Cadillac}

Min: Audi

CUの確認方法

•

V$IM_COL_CU：

CUに関する情報の確認例

col obj_name for a20

select OBJECT_NAME, DICTIONARY_ENTRIES Dict_Entries,

UTL_RAW.CAST_TO_NUMBER

(MINIMUM_VALUE) MIN_VALUE,

UTL_RAW.CAST_TO_NUMBER

(MAXIMUM_VALUE) MAX_VALUE

from v$im_col_cu, dba_objects

where objd = object_id

and object_name = 'PART’ and owner = 'SSB'

and column_number = 1

order by 1;

OBJECT_NAME DICT_ENTRIES MIN_VALUE MAX_VALUE

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

PART 14807 927875 942681

PART 591442 336433 927874

PART 593751 1 1200000

VARCHAR2型列：UTL_RAW.CAST_TO_VARCHAR2

DATE型列： DBMS_STATS.CONVERT_RAW_VALUE（プロシジャ）

表名とスキーマ名と

カラム番号の指定

最小値

最大値

値の種類数

6段階の圧縮

圧縮方式

特徴

NO MEMCOMPRESS

圧縮なし

MEMCOMPRESS FOR DML

カラムの値が全て同じ場合のみ圧縮

MEMCOMPRESS FOR QUERY LOW

デフォルト圧縮レベル(ディクショナリ圧縮)、最高のパフォーマンス

MEMCOMPRESS FOR QUERY HIGH

パフォーマンスに重点が置かれた圧縮とパフォーマンス間のバランスをとる

MEMCOMPRESS FOR CAPACITY LOW

容量に重点が置かれた圧縮とパフォーマンス間のバランスをとる

MEMCOMPRESS FOR CAPACITY HIGH 最大容量を対象。可能な場所では一般的な gzipなどに近い手法を適用

ALTER MATERIALIZED VIEWmv1

INMEMORY

MEMCOMPRESS FOR QUERY

;

CREATE TABLE trades

(Name varchar(20),

Desc varchar(200))

圧縮動作

•

IMCU毎、かつ、カラム毎に圧縮される

•

圧縮率は 2 – 20 倍 (1/2 から 1/20) 程度

–

Exadata HCC と比較すると圧縮率は低い。

•

パーティション毎に圧縮率を変えることができる

–

6 段階のレベル

•

"FOR DML" , “NO MEMCOMPRESS"

DML頻度が多いパーティションや表に設定

•

“FOR QUERY” (Low/High)

多くの表/partitionに最適（デフォルト）

•

"FOR CAPACITY" (Low/High)

圧縮アドバイザーとインメモリ

•

_内部的に

サンプルデータに対し圧縮を試行

•

_{6段階の圧縮レベル対応}

COMP_INMEMORY_NOCOMPRESS

COMP_INMEMORY_DML

COMP_INMEMORY_QUERY_LOW

COMP_INMEMORY_QUERY_HIGH

COMP_INMEMORY_CAPACITY_LOW

COMP_INMEMORY_CAPACITY_HIGH

ポピュレーションの優先度（プライオリティー）

5段階のプライオリティー

•

NONE

–

該当テーブルへのアクセス時にポピュレーション

がトリガーされる

•

LOW、MEDIUM、HIGH、CRITICAL

–

CREATE/ALTER TABLE 時にポピュレートタスクが

キューイングされる

–

プライオリティー別のキューが4本存在

–

Database起動時も同じようにキューイング

•

ポピュレーション完了後にDatabaseをオープンするモードはない

•

ポピュレーション の速度には影響しない

CREATE TABLE orders

(c1 number,

c2 varchar(20),

c3 number)

INMEMORY PRIORITY CRITICAL

NO INMEMORY

(c1);

ポピュレーションの優先度（プライオリティー）

5段階のプライオリティー

優先レベル 説明

CRITICAL

オブジェクトは、データベースのオープン直後に移入されます

HIGH

オブジェクトは、すべてのCRITICALオブジェクトの移入後にインメモリ・カラム・ストアに使用可能な領域が残ってい

る場合、移入されます

MEDIUM

オブジェクトは、すべてのCRITICALオブジェクトとHIGHオブジェクトの移入後にインメモリ・カラム・ストアに使用可能

な領域が残っている場合、移入されます

LOW

オブジェクトは、すべてのCRITICALオブジェクト、HIGHオブジェクト、およびMEDIUMオブジェクトの移入後にインメモ

リ・カラム・ストアに使用可能な領域が残っている場合、移入されます

NONE

オブジェクトは、初回スキャン後にインメモリ・カラム・ストアに使用可能な領域がある場合のみ移入されます（デ

フォルト）

Pollingによるポピュレーション

プライオリティ: LOW / MIDDLE / HIGH / CRITICAL

•

タスク・キューが2分間隔でpollされる

•

システム統計では"CPU: IM Prepopulate“

と表現される

–

注意点:

ポピュレートされていないプライオリティ

がCRITICALに設定されている表があり、インメモ

リ・カラム・ストアに空きがない場合でも、ポピュ

レート済みのプライオリティがLOWの表を落とす

動作は起こらない

IMCO

_Wnnn

ポピュレーション

タスク

Critical

High

Middle

Low

オン・デマンドのポピュレーション

•

プライオリティ:NONE

•

該当テーブルにFULL SCANされると

きにポピュレーションされる

–

SELECT文によるクエリーが索引のみで

結果が返される場合、ポピュレーショ

ンはトリガーされない

•

FULLヒントを付けることで明示的にポピュ

レーションを発生させられる

•

SELECT /*+ FULL(表名) */

–

システム統計では"CPU: IM Populate"

と表現される

•

プロシージャによる明示的なポピュ

レーション

–

dbms_inmemory パッケージ

–

INMEMORY 属性がない表ではエラー

になる

SQL> alter table COMPTEST.TAB1 inmemory;

Table altered.

SQL> exec dbms_inmemory.populate('COMPTEST','TAB1');

PL/SQL procedure successfully completed.

SQL> alter table COMPTEST.TAB1 no inmemory;

Table altered.

SQL> exec dbms_inmemory.populate('COMPTEST','TAB1');

BEGIN dbms_inmemory.populate('COMPTEST','TAB1'); END;

DML 実行時の動作 (Update / Delete)

•

従来通り、バッファ・

キャッシュ(行型)で、

データ・ブロックを更新

•

トランザクションの一時的

な更新情報を Transaction

Journal に記録

•

Commit 時、IMCU 内の

該当行に対する

Invalidateと Transaction

Journal の

解放を実施

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

バッファ・キャッシュ

C1 C2 C3

IMCU

Transaction

_Journal

C1 C2 C3

update tab1 set c2=3 where c1=***;

3

Invalid

行の更新情報

Commit;

DML実行時の動作-Insert(動作イメージ)

•

従来通りバッファ・キャッシュ

(行型)/ディスク上で行を挿入

•

トランザクションに関する

一時的な情報を

トランザクション・ジャーナル

に記録

•

新規に挿入された行は

2分間隔の検知時もしくは

クエリー発行時に

ポピュレーションが行われる

C1 C2 C3

IMCU

C1 C2 C3

メタデータ

Commit;

Insert

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

バッファ・キャッシュ

①

②

④

⑤

Transaction

Journal

③

IMCUの再ポピュレーション

•

特定のタイミングで、無効な行を含むIMCUを

再作成 (再ポピュレーション)

•

更新処理とは非同期で実施

•

以下のタイミングで自動的に実施

–

多数の行が更新された時(再ポピュレーション)

–

2分間隔(トリクル再ポピュレーション)

•

手動実行も可能

–

DBMS_INMEMORY.REPOPULATEプロシージャ

•

表単位ではなくIMCU単位で再作成

Oracle Database In-Memory技術ポイントのまとめ

設定の基本３ステップ

インメモリ導入の容易性

インメモリ導入事前調査

1.

使用するメモリ容量を設定

inmemory_size = XXX GB

2.

メモリー上に格納するテーブル、

パーティションを選択

alter table | partition … inmemory;

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

カラム型フォーマット

ポピュレーション

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

OLTPと分析処理をリアルタイムに融合可能な“唯一の”仕組み

インメモリ・デュアル・フォーマット：高度な仕組み、かつシンプルな設計・運用管理



ロー(行)型とカラム型を

”両方同時に”

実現

Oracle Database In-Memory

処理内容に応じ、

ロー型・カラム型の

適切なメモリを自動的に選択

ローとカラムは

自動で同期

同期

インデックスは不要

データフォーマットは

VS

一般的なインメモリの仕組み



ロー(行)型とカラム型の

”どちらか一方を“

選択

処理内容をユーザが

意識しアクセスする

必要あり

データフォーマット

ローとカラムは

メモリ上では別管理

コスト効率性の高いメモリ上へのデータ配置

コスト効率と性能を柔軟にバランス(スモールスタートが可能)

Oracle Database In-Memory

VS

一般的なインメモリの仕組み



高速化したいデータのみをメモリ上に展開

頻繁に分析するデータのみを

メモリ上に格納可能

頻繁にアクセスするデータは

それほど多くない



基本的に全てのデータをメモリ上に展開

全てのデータがメモリ

上にある前提で処理

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

Database In-Memoryの利用効果の大きい処理

少数列に対する大量行の処理に効果大

大量データの全表走査（Full Table Scan）

大量データの索引走査（Index Range Scan/Bitmap Index Scan）

1. 処理特性

ディスクI/Oの物理読込（Physical Reads）量が大きいもの

2. SQLの特徴

大量行の表を含む分析クエリ

複数表を利用した結合処理とフィルタ条件（WHERE xxx = :abc）

集計演算処理（特に MAX, MIN, COUNT）

Database In-Memoryの利用効果の大きい処理

ディスクI/Oの物理読込（Physical Reads）量が大きいSQLとは？

全表走査

Full Table Scan

索引走査

Index Range Scan

db file sequential read

db file scattered read

SQL Monitorによる確認例

SQLの処理で多くのディスク・アクセスが発生している

(User I/O: db file scattered read)

このようなSQLであればインメモリ化による

インメモリ化によるパフォーマンス改善が

期待できる処理

Database In-Memoryの利用効果の大きい処理

大量行の表を含む結合処理、集計処理でディスクアクセスがある場合と比較

select sum(lo_quantity) from lineorder, customer

where lo_custkey = c_custkey and c_nation in ( 'JAPAN', 'CHINA' ) ;

0

20

40

60

80

100

120

インメモリ

バッファキャッシュ（表）

バッファキャッシュ（索引）

Elapsed Time

108倍（表）、 64倍（索引）高速

16並列で実行

ディスクアクセスあり

ディスクアクセスあり

単位（秒）

LINEORDER: 3億件

CUSTOMER: 150万件

Database In-Memoryの利用効果の大きい処理

大量行の表を含む結合処理、集計処理でディスクアクセスがある場合と比較

インメモリ

バッファキャッシュ（表）

Elapsed Time

360倍高速

ディスクアクセスあり

5並列で実行

select max(lo_quantity) from lineorder

where lo_orderkey between 1 and 50000000 ;

Database In-Memoryの利用効果の大きい処理

大量行の表に対する中間一致検索でディスクアクセスあり

0

50

100

150

200

250

インメモリ

バッファキャッシュ（表）

Elapsed Time

74倍高速

ディスクアクセスあり

単位（秒）

select sum(lo_quantity) from lineorder, customer

where lo_custkey = c_custkey and c_region like '%RICA%' ;

LINEORDER: 3億件

CUSTOMER: 150万件

Q)大きなサイズのバッファ・キャッシュを

確保して、全データをキャッシュ内に

保持して実行すればインメモリ検索と

変わらないのか？

検証１）フル・キャッシュ（行） vs インメモリ（列）

全表スキャン vs 索引スキャン vs インメモリ・スキャン

バッファ・キャッシュに表の全データがキャッシュされている場合とインメモリ検索の場合のパフォーマンスの違いを計測

vs

SGA

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

LINEORDER

ポピュレート

select sum(lo_quantity) from lineorder

where lo_orderkey between 1 and 50000000 ;

実行SQL

3億行

3億行から5,000万行を

抽出する

SGA

バッファ・キャッシュ（行）

LINEORDER

全テーブル＋索引をキャッシュ

データ読込み＆Pin

テーブル

索引

＋

検証１）フル・キャッシュ（行） vs インメモリ（列）

3億行の表から5,000万行を抽出するSQL

インメモリ

フルバッファキャッシュ（表）

フルバッファキャッシュ（索引）

Elapsed Time

31倍（表）、 44倍（索引）高速

ディスクアクセスなし

ディスクアクセスなし

Database

In-Memory

表（フルキャッシュ）

索引（フルキャッシュ）

読込メモリブロック数(consistent gets)

₂₂₄

_2,285,176

_497,832

5並列で実行

インメモリは圧倒的にメモリ

読込量が少ない

索引はシングル・ブロック

読込なので大量行アクセス

には非効率

Q)インメモリ化すると全ての検索処理を

高速化出来るのか？

Database In-Memoryの利用効果が大きくない処理

数億／数千万行の表から 1～数百行取得するような検索

1. 索引により最適化されている

（大きな表から少ない行データを検索する）

ハードウェア・リソースの観点からインメモリ検索の

並列度を高く設定出来ない

マテリアライズド・ビューにより集計値を保持

2. 集計値を別の仕組みで保持している

少ない検索結果件数による比較

索引 vs インメモリ

•

6億行の表から530行を検索するSQL （シリアル実行）

→ 表の格納行数が多く、検索結果件数が少ないほど

索引が若干速くなるケースが多い

select lo_quantity from lineorder where lo_custkey = 1499999 ;

索引

インメモリ

Elapsed Time

0.04秒

0.13秒

1. 情報系への適用（DWH、データマート、特定用途分析）

DWHシステムの分析クエリの高速化、 ETL処理の高速化

データウェアハウス（DWH）

OLTP

データベース

OLTP

データベース

OLTP

データベース

カラム型表による

ETL処理の高速化

（大量の集計演算）

カラム型表による

分析クエリの高速化

OLTPシステム

処理タイプにより両方定義

②

①

2. OLTP系システムの高速化

OLTPシステムの分析、レポート処理の高速化

OLTP

データベース

バッチ処理：集計レポート

• 日次／週次／月次レポート

• 会計期末レポート

• 原価計算処理

ビジネス分析

• 販売管理ダッシュボード

• サービス・ダッシュボード

・

・

・

オンライン処理

バッチ／分析処理

カラム型で分析処理

行型でOLTP

カラム型で分析処理

索引削除で高速化

3. リアルタイムデータ活用

OLTPシステムで発生したデータをリアルタイムに活用

OLTP＆

データ活用

データベース

リアルタイム分析

• 新商品の初動確認

• 日配品の値下げタイミングの

把握

• マシン稼働状況の把握

・

・

・

オンライン処理

リアルタイムデータ活用

カラム型で

データ活用

行型でOLTP

同期

リアルタイムデータ活用

• 重点商品の自動発注

• リアルタイム・プロモーション

• マシン予防保全

索引削除で高速化

4. RACを利用したOLTP－バッチ・分析処理の分離

バッチ専用ノードをインメモリ化

インスタンス1

OLTP処理専用（非インメモリ）

バッファ

キャッシュ

インメモリ・

カラム・ストア

INMEMORY_SIZE

= 0

インメモリ・

カラム・ストア

INMEMORY_SIZE

= 100GB

インスタンス2

バッチ・分析処理専用（インメモリ）

バッファ

キャッシュ

OLTP

バッチ処理

分析

→ Exadata推奨

Program Agenda

1

2

3

4

開発の背景と概要

技術ポイント

他社インメモリDBとの違い

利用用途例

まとめ

5

高速にアクセス出来る理由

インメモリ・スキャンの高速フィルタリング

Table Access Inmemory Full

全表走査

2. 効果的な圧縮技術により

圧縮した状態で検索が可能

(ディクショナリ圧縮)

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

Min 1

Max 3

Min 4

Max 7

Min 8

Max 12

Min 13

Max 15

ベクター・

レジ

スタ

複数の

データを

ロード

一度の命令で

全ての値を

ベクター演算

CPU

CA

CA

CA

CA

3. インメモリ・ストレージ索引により

最小限のIMCUのみスキャン

4. 最新のプロセッサで搭載されて

いるSIMDにより高速スキャン

（ベクター・スキャン）

データ読込み

（インメモリ・スキャン）

フィルタリング

Oracle Database In-Memory Option による影響

想定される既存システムへの影響と変化

次世代 インメモリ・アーキテクチャ

想定される変化

変化しない事

意思決定の精度向上

今現在の大量データを用いたリアルタイム

分析によるビジネスの俊敏性と正確性向上

システム・アーキテクチャのシンプル化

多様なワークロードを１つのDatabaseで処理

開発生産性・運用管理性の更なる向上

集約率の更なる向上によるTCO削減



既存膨大なアプリケーション資産

インメモリ・

データベース

集計・

分析処理

超高速

トランザクション

処理

インメモリ・

ミドルウェア

インメモリ処理が

アーキテクチャの中心へ

高速

トランザクション

処理

Oracle Database In-Memory

リアルタイム・エンタープライズの促進



究極の高速化: 分析とOLTP



容易な導入手法



究極のスケールアウトとアップ



究極の可用性



完全なるセキュリティ

AGILE

EFFICIENT

DATA-DRIVEN

オブジェクト毎のインメモリ定義の確認

•

USER_TABLES: オブジェクト毎のインメモリ定義

column table_name format a20

column PRIORITY format a15

column DISTRIBUTE format a15

column COMPRESSION format a20

Select table_name,

inmemory_priority priority,

inmemory_distribute distribute,

inmemory_compression compression

From user_tables;

TABLE_NAME PRIORITY DISTRIBUTE COMPRESSION

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

LINEORDER CRITICAL AUTO FOR QUERY LOW

PART NONE AUTO FOR QUERY LOW

CUSTOMER NONE AUTO FOR QUERY LOW

オブジェクト毎のポピュレーションの状態確認

•

V$IM_SEGMENTS: オブジェクト毎のポピュレーションの状態

column name format a20

column owner format a10

column status format a15

column No_Pop_Bytes format 999,999,999,999

SELECT v.owner, v.segment_name name, v.populate_status status,

inmemory_size/1024/1024 IM_MB, v.bytes_not_populated No_Pop_Bytes

FROM v$im_segments v;

OWNER NAME STATUS IM_MB NO_POP_BYTES

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

SSB SUPPLIER COMPLETED 16.125 0

SSB LINEORDER STARTED 23975.75 15,753,846,784

SSB CUSTOMER COMPLETED 240.4375 0

SSB DATE_DIM COMPLETED 1.125 0

SSB PART COMPLETED 34.25 0

ポピュレート未完了の

オブジェクト

インメモリ内サイズ

未完了のバイト数

オブジェクト毎のインメモリ内のサイズと圧縮率の確認

•

V$IM_SEGMENTS: オブジェクト毎のインメモリサイズと圧縮率

column name format a20

Select v.segment_name name,

v.bytes/1024/1024 orig_MB,

v.inmemory_size/1024/1024 in_mem_MB,

v.bytes/v.inmemory_size comp_ratio

From v$im_segments v

where v.owner = 'SSB'

Order by 4;

NAME ORIG_MB IN_MEM_MB COMP_RATIO

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

CUSTOMER 256 240.4375 1.06472576

PART 128 34.25 3.73722628

SUPPLIER 64 16.125 3.96899225

インメモリサイズ

圧縮率

元サイズ

Database In-Memoryのチューニング

1.

基本的にほとんどチューニング項目はない

–

ポピュレート完了の状態、パフォーマンス統計などの確認等

2.

パラレル度の指定とパーティションの活用方法

–

CPUのネックにならないように検索のパラレル度を調整する

–

表サイズが大きい場合はパーティションを効果的に利用し

インメモリスキャンのスキャンサイズを小さくする

3.

Attribute Clusterも限定的に利用検討する

–

検索条件頻度の高いカラムには「Attribute Cluster」の機能の適用を検討する

•

インメモリ・ストレージ索引の効果を高める可能性大

–

Attribute Clusterの仕様を理解したうえで利用する

Database In-Memoryでもパーティション表は効果的

IMCU

IMCU

IMCU

In-Memory

P1: ORDER_STATUS=‘OPEN

’

P2: ORDER_STATUS=‘CLOSED’

リストパーティション（ SALES表）

ローカル索引

パーティション単位に

最適なSQL実行計画を

選択可能

→ 最適なパフォーマンス

実行したインメモリ検索の速度が妥当か？

物理I/Oアクセスがないかをチェック

•

対応が必要なもの

–

ポピュレートが未完了

–

PGA領域不足（大量ソート、結合） ※通常のデータベース・チューニング

–

Oracle RAC構成の場合でインターノード・パラレルクエリ

•

パラレル度ポリシーの設定（AutoDOP）： PARALLEL_DEGREE_POLICY = AUTO

•

対応が特に不要なもの

–

ハード・パースによるアクセス（2回目以降なくなる）