Oracle12c Database In

Presented with
第138回夜な夜な! なにわオラクル塾
Oracle12c Database In-Memory
入門！
日本オラクル株式会社
データベース事業統括
ソリューション本部
中部・西日本SC部
2015年01月28日
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とす
るものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供すること
をコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。
オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標また
は商標です。
他社名又は製品名は、それぞれ各社の商標である場合があります。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
2
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
3
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
4
Oracle Database In-Memoryの開発ゴール
リアルタイム
アナリティクス
100x
アプリケーション
の変更なし
OLTPの
高速化
最新世代の
H/Wを有効活用
CPU
2x
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
5
Oracle Database In-Memory Option
既存データベースの概念を根底から覆すテクノロジー
• お客様の既存資産（データとアプリケーション）の完全なる保護と継承
• Oracle Databaseの卓越した高可用性とセキュリティ機能をそのまま利用可能
• 完全なるデュアルフォーマットの提供により、OLTPとDWHの完全なる融合
• 情報系からのインデックス排除による開発・運用コストの劇的な削減
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
6
高速な分析をリアルタイム化する新たな技術革新
Databaseにおける主要な2種類のフォーマット – ロー型 vs カラム型
売上
ロー
(行)型
– 例：注文データの挿入と検索
– 少数の行(ロー)と多数の列(カラム)を高速処理
売上
カラム
(列)型
 OLTP処理を得意とするロー型
 集計、分析処理を高速化するカラム型
– 例：都道府県毎の売上合計のレポート
– 少数の列(カラム)と多数の行(ロー)を高速処理
Oracle Database In-Memory テクノロジーは、各特性を持つ
2つのフォーマットを“両方同時に”メモリー上にロードし利用可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
7
高速な分析をリアルタイム化する新たな技術革新
インメモリ・デュアル・フォーマット
メモリー
メモリー
 同一のデータを行型、カラム型双方
のフォーマットで保持
 インメモリ化指定したもののみ
売上
行型
フォーマット
売上
カラム型
フォーマット
 双方のフォーマットを同時に利用可能
トランザクションの一貫性も担保
 集計、レポート処理はカラム型
フォーマットに対して実行
 OLTP処理は行型フォーマットに
対して実行
1つのSales表というオブジェクトに
対して2つのフォーマット
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
8
OLTPとOLAPの性能向上はトレードオフ
どちらかを性能向上するとどちらかにオーバーヘッドが発生
OLTPとOLAPを1つのデータベースで
共存することは難しい
OLTP
トランザク
ション性能
OLAP分析
処理性能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
9
一般的なOLTPとDWHの構成
• OLTPとDWHは別のHWで動作し、連携はバッチで同期を取っている
– DWH用のHWやDatabaseライセンスコストがかかる
– リアルタイムにデータが見れない
– 夜間バッチのパフォーマンスのためにリソース強化
OLTP
夜間バッチで1日1回 同期
DWH
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
10
Oracle 12c Database In-Memory： デュアル・フォーマット
Oracle 12c Database In-Memoryはデュアル・フォーマットなので、データベース
のオプティマイザがSQLにあわせて最適なフォーマットを選択してSQLを処理し
ます。(他社のインメモリ機能はハイブリッド型：オブジェクトをどちらの方式に
するか決定する必要あり)
Select * from sales_t
Where order_id = ‘ABC123’;
少数の行の全カラムのデータ
取得
Select region, sum(amount)
from sales_t
Group by region;
sales_t表
デュアル・フォーマット
行型
B-Tree索引を
使用した処理
Oracleデータベース
オプティマイザ
カラム型
インメモリ検索を
使用した処理
一部カラムを使った大量行の
集計処理
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
11
アプリケーションの変更は不要
機能性
実装容易性
互換性
マルチテナント
- SQLの制限なし
- データマイグレーションの必要なし
- 全ての既存アプリケーションは改修なく動作
- クラウド対応済み
アプリケーションの変更なく、インメモリのメリットを享受
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
12
カラム型表は何故分析用クエリーが高速か?
ポイント2：
効果的な圧縮技術により
圧縮した状態で検索が可能
(ディクショナリ圧縮)
C1 C2 C3 C4 C5 C6
ポイント3：
インメモリ・ストレージ索引により
最小限のユニットのみスキャン
例) where storeid > 8
Min 1
Max 3
Min 4
Max 7
ポイント4：
最新のプロセッサで搭載されている
SIMDにより高速スキャン
CPU
複数の
データを
ロード
Min 8
Max 12
Min 13
Max 15
ベクター・レジスタ
ポイント1：
集計に必要なカラムのみアクセス
CA
CA
CA
一度の命令で
全ての値を
ベクター演算
CA
ポイント5：
パラレル・クエリーとパーティション表
によりさらに高速化可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
13
カラム型表は何故分析用クエリーが高速か?
ポイント1： 必要なカラムのみアクセス(行フォーマット型の場合)
バッファ・キャッシュ
SELECT COL4 FROM MYTABLE;
X
X
X
X
X
行フォーマット
結果
X X X X X
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
14
カラム型表は何故分析用クエリーが高速か?
ポイント1： 必要なカラムのみアクセス
インメモリ・カラム・ストア
SELECT COL4 FROM MYTABLE;
結果
カラム・フォーマット
X
X
X
X
X
必要なカラムのみアクセス
データの読込量少ない
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
15
カラム型表は何故分析用クエリーが高速か?
ポイント1： 必要なカラムのみアクセス(実行計画)
インメモリ検索の実行計画例

新しいアクセス方法

インメモリ検索を有効／無効化する
パラメータ
TABLE ACCESS INMEMORY FULL
INMEMORY_QUERY = {enable | disable}
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
16
カラム型表は何故分析用クエリーが高速か?
ポイント2： ディクショナリ圧縮
非圧縮
EMP表のJOB列
-----------------CLERK
SALESMAN
SALESMAN
MANAGER
SALESMAN
MANAGER
MANAGER
ANALYST
PRESIDENT
SALESMAN
CLERK
CLERK
ANALYST
CLERK
ディクショナリ圧縮
ディクショナリ(distinctされた値)
ソ
ー
ト
さ
れ
た
値
97
bytes
カラム値
ディクショナリ値
ビット表現
ANALYST
0
000
CLERK
1
001
MANAGER
2
010
PRESIDENT
3
011
SALESMAN
4
100
カラム値サイズ合計＋ビット値合計
→ 36 bytes + 3bit * 5 = 38 bytes
ディクショナリ圧縮は
圧縮した状態で検索
が可能
Where job = ‘MANAGER’
Where job = 010
に内部的に変換
※圧縮状態で検索可能
エンコードされた各行の値
行
001 100 100 010 100 010 010 000 011 100 001 001 000 001
3bit * 14行 = 5.25bytes  38 + 5.25 = 44 bytes
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(1/2.2 圧縮)
17
カラム型表は何故分析用クエリーが高速か?
ポイント3： インメモリ・ストレージ索引 (※メモリー内に定義される)
Select … From sales Where storeid > 8;
• 各カラムは複数のIMCUで構成さ
れる
メモリー
• 各IMCUで最小値/最大値を
自動的に記録
• WHERE句の条件に合致する領域
だけを読み込み
• すべての検索でパーティション・プ
ルーニングと同様の
パフォーマンスを提供
IMCU
Min 1
Max 3
IMCU
Min 4
Max 7
IMCU
Min 8
Max 12
IMCU
Min 13
Max 15
storeid
SALES表
カラム
フォーマット
IMCU - In-Memory Compression Unit
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
18
SIMD※による効果的な演算
※ SIMD： Single Instruction Multiple Data
ポイント4：最新のプロセッサで搭載されているSIMD命令セットにより高速スキャン
通常の命令セットの場合(1組のデータ演算から１つの結果を算出)
4回の一致
比較の場合
レジスタ
CPU命令
A1 B1
C1
CMPEQ
IF ( A1 ＝ B1 ) → C1
IF ( A2 ＝ B2 ) → C2
IF ( A3 ＝ B3 ) → C3
IF ( A4 ＝ B4 ) → C4
A2 B2
C2
A3 B3
CMPEQ
C3
A4 B4
CMPEQ
C4
CMPEQ
4回繰返し
SIMD命令セットの場合(複数のデータを1回の演算命令で高速実行)
ベクター
レジスタ
A1 A2 A3 A4
CPU命令
CMPEQ (SIMD)
B1 B2 B3 B4
ベクターレジスタ
C1 C2 C3 C4
1回の命令で高速演算
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
19
カラム型表は何故分析用クエリーが高速か?
0
000
CLERK
1
001
MANAGER
2
010
PRESIDENT
3
011
SALESMAN
4
100
001 100 100 010 100 010 010 000 011
ディクショナリ圧縮により
実データ値をビットデータとして
扱うことでより多くのデータを
CPUレジスタにロード可能
SIMD
ベクター・レジスタ
ANALYST
JOB
ポイント4：最新のプロセッサで搭載されているSIMD命令セットにより高速スキャン
EMP表
インメモリ・カラム・ストア
例: 「MANAGER」職種を検索
JOBカラム値
ディクショナリ値
ビット表現
(MANAGER → 010)
複数の
データを
ロード
CPU
010
100
010
010
001
110
010
100
一度の命令で
全ての値を
ベクター演算
MANAGER → 010(エンコード値)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
20
カラム型表は何故分析用クエリーが高速か?
ポイント5：インメモリ検索はパラレル・クエリー、パーティション表によりさらに高速化
パラレル・クエリーで
さらに高速化
インメモリ・スキャン ＝ TABLE ACCESS INMEMORY FULL
QS
QS
QS
QS
一部のパーティションをインメモリ化
→ パーティション・プルーニングにより高速化
基本的にFull Table Scanの発展系
→ データはインメモリ・カラム型で圧縮
→ 必要なカラムのみアクセス
→ インメモリ・ストレージ索引により
最低限のIMCUスキャン
カラム
型
行型
P1
P2
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
P3
P4
21
Database In-Memoryとパラレル・クエリー
メモリー内で
並列処理
autoDOPはインメモリ構成も
考慮してパラレル度を決定
QS
インメモリ･カラム・ストアなので
対象データはメモリー内にある
QS
In-Memory Parallel
Executionと同様の動き
(Buffer CacheではなくIMC利用)
QS
＋
高速なインメモリ検索
インメモリ・カラム・ストア(IMC)
QS
クエリー
スレーブ




必要なカラムのみアクセス
効果的な圧縮(高速検索)
効率的なSIMD利用
インメモリ・ストレージ索引
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
基本的にディスク
読込は発生しない
22
インメモリ検索による表の結合処理の高速化
複数表の結合処理を内部的に高速カラム検索に変換 (ベクター結合)
例： 直販店(outlet)の売上合計を集計

インメモリ・カラム・ストアにより
複数表の結合処理を高速化
売上
店舗
1. ジョイン・フィルタと呼ばれるフィルタを
Type=Outlet
インメモリ固有の機能ではないが
インメモリ検索で非常に効果的
 店舗表のTYPE=‘OUTLET’ に該当する
StoreIDをリスト
Amount
StoreID in
15, 38, 64
カラム検索を使用して作成
Store ID
Store ID
Type
ジョイン・フィルタ
合計値
2. 作成したジョイン・フィルタの条件にあう
売上表のAMOUNTの合計値を計算
 ジョイン・フィルタから以下の条件を生成
「where StoreID in (15, 38, 64)」
 上記の条件にヒットする行の売上表
単体のカラム検索により高速にAMOUNT
列の合計値を算出
( SUM(AMOUNT) )
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
23
インメモリ検索による表の集計処理の高速化
ベクターGroup By(Vector Group By)
例: アウトレットでの靴の売上を集計
店舗表
インメモリ・レポート
アウトライン
売上表
Footwear
Footwear
商品表
$
$$
$$$
上に動的に作成(インメモリ配列)
 レポート内の集計値は
ファクト表のスキャン中に展開
Outlets
Outlets
 レポート・アウトラインをメモリー
 事前定義された多次元
$
キューブを使わずに高速化
Sales
インメモリ固有の機能ではないが
インメモリ検索で非常に効果的
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
24
分析基盤におけるインデックスが不要
• 既存Oracle Databaseによる分析基盤
• Oracle Database In-Memoryの適用
– インデックスは事前予測可能な
パターンのみ高速化
– インデックスなしですべての
カラム(列)の処理を高速化
– 更新処理は10～20個のインデックスの更新が必要
– カラム型ストアはディスクI/Oなし
• パフォーマンス低下の原因
1～3
OLTP用
インデックス
表
1～3
OLTP
インデックス
10 ～ 20
分析用
インデックス
インメモリ
カラム型
ストア
表
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
25
スケールアウト構成 – RACとの組み合わせ例 1/2
アプリケーションから透過的に表パーティション毎に柔軟な分散配置を構成可能
• 分散配置
– 大規模データを各ノードで分割して保持
– ROWIDもしくはパーティションで分割
Real Application Clusters
– インメモリ・カラム・ストアの
スケールアウトが可能
– In-Memory Parallel Queryと組み合わせによるインメモリ
並列処理が可能
• 複製配置
– 小規模データを各ノード重複して保持
– 2ノードもしくはすべてのノードに複製
Real Application Clusters
– ノード耐障害性の向上
– In-Memory Parallel Queryと組み合わせによるインメモリ
並列処理が可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
26
スケールアウト構成 – RACとの組み合わせ例 2/2
アプリから透過的にテーブル・パーティション毎に柔軟な分散配置を構成可能
• 分散＋複製配置
In-Memory Parallel Query
– 大規模データを各ノードで分割し保持
• インメモリ・カラム・ストアのスケールアウトが可能
– In-Memory Parallel Queryと組み合わせによる
インメモリ並列処理
– 複製データにより可用性を向上し、
障害時の再インメモリ化(ポピュレーション)時間
を削減
– スケーラブルな可用性の高い
並列分析処理基盤の構築が可能
Real Application Clusters
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
複製データ（Duplicate 2)
• 各ノードのCPUを有効活用
27
可用性・セキュリティを既存の仕組みで実装可能
• 既存のOracle Databaseの信頼性・可用性・拡張性・セキュリティに
関わる機能をOracle Database In-Memoryでも透過的に利用可能
• ストレージ・フォーマット、ロギング、
バックアップ/リカバリなどの運用管理に
影響なし
• 既存のOracle Databaseの可用性機能は
透過的に動作
• 既存のOracle Databaseのデータ保護機能も
透過的に動作
– ノード障害、サイト障害、データ破損、
人的エラーなど
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
28
基本導入手順（設定・運用管理）
基本３ステップ
事前調査
本当に効果が
あるデータは
何か？
インメモリ・カラ
ム・ストアの
サイズは？
インメモリ・カラ
ム化する
データの選択
運用管理
不要な
インデックスを
削除
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
インメモリ・カラ
ム・ストアの
状況監視
29
容易な設定作業のみで実装可能
1. 使用するメモリ容量を設定
inmemory_size = XXX GB
2. メモリー上に格納するテーブル、パーティションを選択
alter table | partition … inmemory;
3. インデックスを削除
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
30
TimesTen In-Memory Database
更なるOLTPレイテンシを要求される場面でIn-Memory Technologyを補完
同アドレス空間
TIMESTEN
IN-MEMORY DATABASE
アプリケーション
150マイクロ秒の
ネットワーク処理
N
E
T
アプリケーションとデータベース間の
ネットワーク・レイテンシによるOLTP
処理遅延
- 呼制御、 株式トレーディング、他
5マイクロ秒で
SQLを実行
TimesTen In-Memory Database
非常に軽量で高速なインメモリDB
- 非常に軽量で高速なインメモリデータベース
Oracle
Database
- アプリケーションのアドレス空間で稼働
ネットワークレイテンシなし
- OLTP処理を30倍高速化
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
31
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
32
インメモリ・カラム・ストアの基本構成
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
33
インメモリ・カラム・ストアの基本構成
• SGA内の新たな領域として、
インメモリ領域を追加
• INMEMORY_SIZE
パラメータによりサイズ設定
– 最小値は100MB
System Global Area (SGA)
Buffer Cache
Shared Pool
Redo Buffer
Large Pool
Other shared
Memory
Components
In-Memory
Area
• SGA_TARGET は十分に
大きな値の設定が必要
• 静的プールとして確保
INMEMORY_SIZE
パラメータ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
34
インメモリ領域: SGA内の新しい領域
• INMEMORY_SIZE
初期化パラメータ
• 100MB が設定可能な最小値
• SGA_TARGET に十分な
空きが必要
• スタティック(静的) なプール
• 変更後再起動
確認方法
SELECT * FROM V$SGA;
NAME
-----------------Fixed Size
Variable Size
Database Buffers
Redo Buffers
In-Memory Area
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
VALUE
--------2927176
570426808
4634022912
13848576
10244836480
35
インメモリ領域: 構成
• ２つのサブプールで構成:
– IMCU(1MB)プール:
IMCU(In-Memory Compression Units)を格納
インメモリ領域
• 1MBの倍数単位で使われる
IMCU
IMCU
IMCU
IMCU
• 連続領域、エクステント
– SMU(64KB)プール:
SMU(Snapshot Metadata Units)を格納
• 64KB 1 つの中で完結
• 更新時に使用量が増える
IMCU
• IMCUはカラム書式のデータを格納
• SMUはメタデータとトランザクション情報を格納
– 1 IMCU の管理情報を格納する SMU Extentが1個作られる
– inmemory_size パラメータで指定したサイズの約 20 %が自
動で 64KB プールにされる
IMCU
IMCU
IMCU
SMU
SMU
SMU
SMU
SMU
SMU
SMU
SMU
SMUプール
(64KB)
IMCUプール(1MB)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
36
インメモリ領域：確認
• 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
---------- ---------- ---------- ---------57338
42153
15185
IMCUプール 1MB POOL
14320
589.3125 13730.6875
SMUプール 64KB POOL
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
37
インメモリ領域：使用状況
• 空きがある状態
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
– 通常 64KB Pool の方が "空き率" が大きい。
• 空きがない状態
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
– 64KB Pool の方があふれることはない• インメモリ領域があふれる場合
‐
‐
バックグラウンドプロセスの trc ファイルに以下が出力される
• ORA-64356: in-memory columnar area out-of-space
alert.log に以下が出る
• Insufficient memory to populate table to inmemory area.
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
38
ポピュレーション
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
39
ポピュレーション(population) とは
• データをディスクからインメモリ・カラム・ストアへ
載せる動作
インメモリ領域
• ポピュレーションは既存データをメモリー中に
最適化されたカラム型フォーマットで取り込む
– ポピュレーションは新しいデータを取り込まない
• ロギングのためのディスクI/Oなし
• データ更新のオーバーヘッドを極小化
– ポピュレーションのリクエストはキューに入れられる
• 2分間隔でキューから取り出されタスクが実行される
• キューは優先度が指定される
SALES
• ポピュレーションはバックグラウンドで実行される
– ORA_W001_orcl プロセス
• プロセス数はINMEMORY_MAX_POPULATE_SERVERS
初期化パラメータ(新規)で設定
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
40
ポピュレーション : オブジェクト(セグメント)属性
• INMEMORY 新属性
• 以下のセグメントの種類がサポートされる
ALTER TABLE sales INMEMORY;
– 表
ALTER TABLE sales NO INMEMORY;
– パーティション
– サブパーティション
– マテリアライズド・ビュー、マテリアライズド・ビュー・ログ
• 代表的なサポートされないセグメントの種類
– 外部表
– IOT(インデックス構成表)
– クラスタ化テーブル
CREATE TABLE
PARTITION BY
(PARTITION
(PARTITION
customers ……
LIST
p1 …… INMEMORY,
p2 …… NO INMEMORY);
– Out of line LOB
– SYS スキーマ、SYSTEM 表領域, SYSAUX 表領域のオブジェクト
– Advanced Replication 設定されている表
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
41
カラム・レベルでの指定(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
Enterprise Managerからも確認・設定可能
ALTER TABLE sales INMEMORY
NO INMEMORY (PROD_ID);
EM Cloud Control での設定も可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
42
サポートされないカラム
• LONG
• Inline でない CLOB, BLOB
• 4KB 以上の VARCHAR2
• ネストされたテーブルカラム
• 仮想カラムはカラムレベルではサポートされない
– ORA-64359: INMEMORY clause may not be specified for virtual columns
※ 同一表の中のサポートされないカラム以外はポピュレーションされる
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
43
AWR: インメモリ・セグメント統計
• AWR レポートにインメモリ・
セグメント統計が追加
– V$IM_HEADER の
TIME_TO_POPULATE カラムで
ポピュレーションにかかった
時間を確認可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
44
IMCU - カラム型フォーマット
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
45
IMCU： In-Memory Compression Unit
IMCU
IMCUヘッダー
• カラム型オブジェクトの管理単位
カラム・ユニット(CU)
– カラム型データをある程度の行数のセットで
保持（例：50万行程度）
– 格納される行は１つ以上の
表エクステントから取得
ROWID
EMPID
NAME
DEPT
SALARY
• IMCUの実サイズは行サイズ、
圧縮率等により変化
（固定値ではない）
• カラム毎に分離／近接した
カラム・ユニット(CU)として保存
– Rowidも同様に１つのCUとして保存
Extent #13
Blocks 20-120
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Extent #14
Blocks 82-182
Extent #15
Blocks 201-301
46
IMCU = In-Memory Compression Unit
CU = Column Unit
行型フォーマットとカラム型フォーマット
In-Memory Area: カラム・ストア
On-Disk 表領域: 行型フォーマット
In-Memory Area
Data file 1
IM Segment
Data file 2
Data file N
IM Segment
Segment
Extent
Block
Extent
Extent
Block
IMCU
IMCU
Extent
Row
Row
Row
Row
Block
8KB
IMCU
C
U
C
U
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
C
U
C
U
n MB
47
IMCU 分割基準
• 行数、または、サイズ
– 数十万行、数100MB程度
– 行長平均が小さい場合、行数で分割される
• ポピュレーション時に分割し１プロセスが １つの IMCU作成
• HCC(Hybrid Columnar Compression) と比較するとユニットサイズは大きい
• 特別なカラム・ユニット(CU)
– ROWID CU
– 各カラムの最大最小値エリア
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
48
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;
IMCU数
OBJECT_NAME
NUM_IMCU
-------------------- ---------CUSTOMER
3
DATE_DIM
1
LINEORDER
563
PART
3
SUPPLIER
1
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
49
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
-------------------CUSTOMER
CUSTOMER
CUSTOMER
DATE_DIM
PART
PART
PART
SUPPLIER
IMCUサイズ IMCU内行数
カラム数
TSNAME
ALLOC_MB
NUM_ROWS
NUM_COLS
--------------- ---------- ---------- ---------TS_DATA
39
495602
8
TS_DATA
33
415593
8
TS_DATA
47
588805
8
TS_DATA
1
2556
17
TS_DATA
1
14807
9
TS_DATA
14
591442
9
TS_DATA
14
593751
9
TS_DATA
8
100000
7
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
50
CU：カラム・ユニット (Column Unit)
• IMCUに格納されている各カラム値の
管理単位
• 全CUは自動的に最小／最大値を保存
– インメモリ・ストレージ索引
• 圧縮フォーマット
– 例）ディクショナリ圧縮
CUは実際の値ではなく、サイズの小さい
ディクショナリIDをデータ値として格納
→ 圧縮した状態で検索が可能
– 他の圧縮方式と組合わせることも可能
ディクショナリ
VALUE
Audi
BMW
Cadillac
ID
0
1
2
カラム値リスト
CU
Min: Audi
Max: Cadillac
BMW
2
Audi
0
BMW
2
Cadillac
1
BMW
2
Audi
0
Audi
0
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
51
CUの確認方法
• V$IM_COL_CU：
CUに関する情報の確認例
VARCHAR2型列：UTL_RAW.CAST_TO_VARCHAR2
DATE型列： DBMS_STATS.CONVERT_RAW_VALUE（プロシジャ）
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
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
52
圧縮
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
53
6段階の圧縮
圧縮方式
特徴
NO MEMCOMPRESS
圧縮なし
MEMCOMPRESS FOR DML
カラムの値が全て同じ場合のみ圧縮
MEMCOMPRESS FOR QUERY LOW
デフォルト圧縮レベル(ディクショナリ圧縮)、最高のパフォーマンス
MEMCOMPRESS FOR QUERY HIGH
パフォーマンスに重点が置かれた圧縮とパフォーマンス間のバランスをとる
MEMCOMPRESS FOR CAPACITY LOW
容量に重点が置かれた圧縮とパフォーマンス間のバランスをとる
MEMCOMPRESS FOR CAPACITY HIGH
最大容量を対象。可能な場所では一般的な gzipなどに近い手法を適用
CREATE TABLE trades
(Name varchar(20),
Desc varchar(200))
INMEMORY MEMCOMPRESS FOR DML;
ALTER MATERIALIZED VIEWmv1
INMEMORY MEMCOMPRESS FOR QUERY;
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
54
圧縮動作
• IMCU毎、かつ、カラム毎に圧縮される
• 圧縮率は 2 – 20 倍 (1/2 から 1/20) 程度
– Exadata HCC と比較すると圧縮率は低い。
• パーティション毎に圧縮率を変えることができる
– 6 段階のレベル
• "FOR DML" , “NO MEMCOMPRESS"
DML頻度が多いパーティションや表に設定
• “FOR QUERY” (Low/High)
多くの表/partitionに最適（デフォルト）
• "FOR CAPACITY" (Low/High)
アクセスの少ない表。クエリーは上記より低速に
– ILM(Information Lifecycle Management)ポリシーに合わせて検討
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
55
圧縮アドバイザーとインメモリ
• 内部的に
サンプルデータに対し圧縮を試行
• 6段階の圧縮レベル対応 COMP_INMEMORY_NOCOMPRESS
COMP_INMEMORY_DML
COMP_INMEMORY_QUERY_LOW
COMP_INMEMORY_QUERY_HIGH
COMP_INMEMORY_CAPACITY_LOW
COMP_INMEMORY_CAPACITY_HIGH
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
56
プライオリティー
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
57
ポピュレーションの優先度（プライオリティー）
5段階のプライオリティー
• NONE
– 該当テーブルへのアクセス時にポピュレーション
がトリガーされる
• LOW、MEDIUM、HIGH、CRITICAL
CREATE TABLE orders
(c1 number,
c2 varchar(20),
c3 number)
INMEMORY PRIORITY CRITICAL
NO INMEMORY (c1);
– CREATE/ALTER TABLE 時にポピュレートタスクが
キューイングされる
– プライオリティー別のキューが4本存在
– Database起動時も同じようにキューイング
• ポピュレーション完了後にDatabaseをオープンするモードはない
• ポピュレーション の速度には影響しない
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
58
ポピュレーションの優先度（プライオリティー）
5段階のプライオリティー
優先レベル
説明
CRITICAL
オブジェクトは、データベースのオープン直後に移入されます
HIGH
オブジェクトは、すべてのCRITICALオブジェクトの移入後にインメモリ・カラム・ストアに使用可能な領域が残ってい
る場合、移入されます
MEDIUM
オブジェクトは、すべてのCRITICALオブジェクトとHIGHオブジェクトの移入後にインメモリ・カラム・ストアに使用可能
な領域が残っている場合、移入されます
LOW
オブジェクトは、すべてのCRITICALオブジェクト、HIGHオブジェクト、およびMEDIUMオブジェクトの移入後にインメモ
リ・カラム・ストアに使用可能な領域が残っている場合、移入されます
NONE
オブジェクトは、初回スキャン後にインメモリ・カラム・ストアに使用可能な領域がある場合のみ移入されます（デ
フォルト）
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
59
Pollingによるポピュレーション
プライオリティ: LOW / MIDDLE / HIGH / CRITICAL
• タスク・キューが2分間隔でpollされる
• システム統計では"CPU: IM Prepopulate“
と表現される
Critical
High
– 注意点: ポピュレートされていないプライオリティ
がCRITICALに設定されている表があり、インメモ
リ・カラム・ストアに空きがない場合でも、ポピュ
レート済みのプライオリティがLOWの表を落とす
動作は起こらない
Middle
Low
IMCO
Wnnn
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
ポピュレーション
タスク
60
オン・デマンドのポピュレーション
• プライオリティ:NONE
• プロシージャによる明示的なポピュ
レーション
• 該当テーブルにFULL SCANされると
– dbms_inmemory パッケージ
きにポピュレーションされる
– SELECT文によるクエリーが索引のみで
結果が返される場合、ポピュレーショ
ンはトリガーされない
• FULLヒントを付けることで明示的にポピュ
レーションを発生させられる
• SELECT /*+ FULL(表名) */
– システム統計では"CPU: IM Populate"
と表現される
– 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;
*
ERROR at line 1:
ORA-03211: The segment does not exist or is not in a valid state
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
61
DML 実行時の動作 (Update / Delete)
• 従来通り、バッファ・
キャッシュ(行型)で、
データ・ブロックを更新
バッファ・キャッシュ
• トランザクションの一時的
な更新情報を Transaction
Journal に記録
• Commit 時、IMCU 内の
該当行に対する
Invalidateと Transaction
Journal の
解放を実施
update tab1 set c2=3 where c1=***;
C1
C2
C3
インメモリ・カラム・ストア
IMCU
C1 C2
Transaction
Journal
C3
行の更新情報
Commit;
3
Invalid
従来の更新操作に加え、IMCU内の行 の Invalidation を実施
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
62
DML実行時の動作-Insert(動作イメージ)
• 従来通りバッファ・キャッシュ
(行型)/ディスク上で行を挿入
• トランザクションに関する
一時的な情報を
トランザクション・ジャーナル
に記録
• 新規に挿入された行は
2分間隔の検知時もしくは
クエリー発行時に
ポピュレーションが行われる
バッファ・キャッシュ
インメモリ・カラム・ストア
①
Insert
C1
C2
IMCU
C1 C2
C3
Transaction
Journal
C3
メタデータ
③
⑤
②
Commit;
④
新規INSERT分はIMCOの監視タイミング/クエリー発行時に ポピュレーション
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
63
IMCUの再ポピュレーション
• 特定のタイミングで、無効な行を含むIMCUを
再作成 (再ポピュレーション)
• 更新処理とは非同期で実施
• 以下のタイミングで自動的に実施
– 多数の行が更新された時(再ポピュレーション)
– 2分間隔(トリクル再ポピュレーション)
• 手動実行も可能
– DBMS_INMEMORY.REPOPULATEプロシージャ
• 表単位ではなくIMCU単位で再作成
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
64
Oracle Database In-Memory技術ポイントのまとめ
インメモリ導入の容易性
技術要素
インメモリ導入事前調査
インメモリ・カラム・ストア
設定の基本３ステップ
1.
2.
3.
使用するメモリ容量を設定
inmemory_size = XXX GB
メモリー上に格納するテーブル、
パーティションを選択
alter table | partition … inmemory;
ポピュレーション
カラム型フォーマット
圧縮・プライオリティー
インデックスを削除
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
65
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
66
OLTPと分析処理をリアルタイムに融合可能な“唯一の”仕組み
インメモリ・デュアル・フォーマット：高度な仕組み、かつシンプルな設計・運用管理
一般的なインメモリの仕組み
Oracle Database In-Memory
 ロー(行)型とカラム型の”どちらか一方を“選択
ロー(行)型とカラム型を”両方同時に”実現
処理内容に応じ、
ロー型・カラム型の
適切なメモリを自動的に選択
処理内容をユーザが
意識しアクセスする
必要あり
VS
同期
インデックスは不要
ローとカラムは
メモリ上では別管理
ローとカラムは
自動で同期
顧客テーブル
売上テーブル
データフォーマットは
１種類
データフォーマット
2種類を管理が必要
顧客テーブル 売上テーブル
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
67
コスト効率性の高いメモリ上へのデータ配置
コスト効率と性能を柔軟にバランス(スモールスタートが可能)
一般的なインメモリの仕組み
Oracle Database In-Memory
高速化したいデータのみをメモリ上に展開
頻繁に分析するデータのみを
メモリ上に格納可能
 基本的に全てのデータをメモリ上に展開
VS
全てのデータがメモリ
上にある前提で処理
頻繁にアクセスするデータは
それほど多くない
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
68
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
69
Database In-Memoryの利用効果の大きい処理
少数列に対する大量行の処理に効果大
1. 処理特性
ディスクI/Oの物理読込（Physical Reads）量が大きいもの
大量データの全表走査（Full Table Scan）
大量データの索引走査（Index Range Scan/Bitmap Index Scan）
2. SQLの特徴
大量行の表を含む分析クエリ
複数表を利用した結合処理とフィルタ条件（WHERE xxx = :abc）
集計演算処理（特に MAX, MIN, COUNT）
中間一致検索（ユニーク値の列は除く）
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
70
Database In-Memoryの利用効果の大きい処理
ディスクI/Oの物理読込（Physical Reads）量が大きいSQLとは？
インメモリ化によるパフォーマンス改善が
期待できる処理
全表走査
Full Table Scan
索引走査
Index Range Scan
db file scattered read
db file sequential read
SQL Monitorによる確認例
SQLの処理で多くのディスク・アクセスが発生している
(User I/O: db file scattered read)
ディスクアクセス量大
このようなSQLであればインメモリ化による
パフォーマンス改善の効果を期待できる
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
71
Database In-Memoryの利用効果の大きい処理
大量行の表を含む結合処理、集計処理でディスクアクセスがある場合と比較
select sum(lo_quantity) from lineorder, customer
LINEORDER: 3億件
CUSTOMER: 150万件
where lo_custkey = c_custkey and c_nation in ( 'JAPAN', 'CHINA' ) ;
Elapsed Time
ディスクアクセスあり
バッファキャッシュ（索引）
ディスクアクセスあり
バッファキャッシュ（表）
108倍（表）、 64倍（索引）高速
インメモリ
0
20
40
60
80
単位（秒）
100
16並列で実行
120
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
72
Database In-Memoryの利用効果の大きい処理
大量行の表を含む結合処理、集計処理でディスクアクセスがある場合と比較
select max(lo_quantity) from lineorder
LINEORDER: 3億件
where lo_orderkey between 1 and 50000000 ;
Elapsed Time
ディスクアクセスあり
バッファキャッシュ（表）
360倍高速
インメモリ
5並列で実行
0
20
40
単位（秒）
60
80
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
73
Database In-Memoryの利用効果の大きい処理
大量行の表に対する中間一致検索でディスクアクセスあり
select sum(lo_quantity) from lineorder, customer
where lo_custkey = c_custkey and c_region like '%RICA%' ;
LINEORDER: 3億件
CUSTOMER: 150万件
Elapsed Time
バッファキャッシュ（表）
ディスクアクセスあり
74倍高速
インメモリ
0
50
16並列で実行
100
150
単位（秒）
200
250
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
74
Q)大きなサイズのバッファ・キャッシュを
確保して、全データをキャッシュ内に
保持して実行すればインメモリ検索と
変わらないのか？
→ No
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
75
検証１）フル・キャッシュ（行） vs インメモリ（列）
全表スキャン vs 索引スキャン vs インメモリ・スキャン
バッファ・キャッシュに表の全データがキャッシュされている場合とインメモリ検索の場合のパフォーマンスの違いを計測
実行SQL select sum(lo_quantity) from lineorder
3億行から5,000万行を
抽出する
where lo_orderkey between 1 and 50000000 ;
SGA
インメモリ・カラム・ストア（列）
SGA
バッファ・キャッシュ（行）
索引
テーブル
＋
全テーブル＋索引をキャッシュ
vs
ポピュレート
データ読込み＆Pin
LINEORDER
3億行
LINEORDER
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
76
検証１）フル・キャッシュ（行） vs インメモリ（列）
3億行の表から5,000万行を抽出するSQL
読込メモリブロック数(consistent gets)
インメモリは圧倒的にメモリ
読込量が少ない
Database InMemory
表（フルキャッシュ）
索引（フルキャッシュ）
224
2,285,176
497,832
索引はシングル・ブロック
読込なので大量行アクセス
には非効率
Elapsed Time
ディスクアクセスなし
フルバッファキャッシュ（索引）
ディスクアクセスなし
フルバッファキャッシュ（表）
5並列で実行
31倍（表）、 44倍（索引）高速
インメモリ
0
2
4
単位（秒）
6
8
10
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
12
77
Q)インメモリ化すると全ての検索処理を
高速化出来るのか？
→ No
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
78
Database In-Memoryの利用効果が大きくない処理
1. 索引により最適化されている
（大きな表から少ない行データを検索する）
数億／数千万行の表から 1～数百行取得するような検索
ハードウェア・リソースの観点からインメモリ検索の
並列度を高く設定出来ない
2. 集計値を別の仕組みで保持している
マテリアライズド・ビューにより集計値を保持
同一内の別カラム、また別表に集計値を保持
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
79
少ない検索結果件数による比較
索引 vs インメモリ
• 6億行の表から530行を検索するSQL （シリアル実行）
select lo_quantity from lineorder where lo_custkey = 1499999 ;
Elapsed Time
索引
0.04秒
インメモリ
0.13秒
→ 表の格納行数が多く、検索結果件数が少ないほど
索引が若干速くなるケースが多い
→ SQLヒントを指定しないと索引アクセス処理になる
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
80
1. 情報系への適用（DWH、データマート、特定用途分析）
DWHシステムの分析クエリの高速化、 ETL処理の高速化
①
OLTPシステム
処理タイプにより両方定義
カラム型表による
分析クエリの高速化
データウェアハウス（DWH）
OLTP
OLTP
データベース
OLTP
データベース
データベース
カラム型表による
ETL処理の高速化
（大量の集計演算）
②
カラム型表中心に設計
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
81
2. OLTP系システムの高速化
OLTPシステムの分析、レポート処理の高速化
オンライン処理
行型でOLTP
・
・
・
バッチ／分析処理
索引削除で高速化
カラム型で分析処理
バッチ処理：集計レポート
• 日次／週次／月次レポート
• 会計期末レポート
• 原価計算処理
OLTP
データベース
カラム型で分析処理
ビジネス分析
• 販売管理ダッシュボード
• サービス・ダッシュボード
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
82
3. リアルタイムデータ活用
OLTPシステムで発生したデータをリアルタイムに活用
オンライン処理
カラム型で
データ活用
行型でOLTP
・
・
・
リアルタイムデータ活用
索引削除で高速化
同期
OLTP＆
データ活用
データベース
リアルタイム分析
• 新商品の初動確認
• 日配品の値下げタイミングの
把握
• マシン稼働状況の把握
リアルタイムデータ活用
• 重点商品の自動発注
• リアルタイム・プロモーション
• マシン予防保全
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
83
4. RACを利用したOLTP－バッチ・分析処理の分離
バッチ専用ノードをインメモリ化
バッチ処理
分析
OLTP
インスタンス1
OLTP処理専用（非インメモリ）
バッファ
キャッシュ
インメモリ・
カラム・ストア
INMEMORY_SIZE
=0
インスタンス2
バッチ・分析処理専用（インメモリ）
バッファ
キャッシュ
インメモリ・
カラム・ストア
INMEMORY_SIZE
= 100GB
→ Exadata推奨
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
84
Program Agenda
1
開発の背景と概要
2
技術ポイント
3
他社インメモリDBとの違い
4
利用用途例
5
まとめ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
85
高速にアクセス出来る理由
インメモリ・スキャンの高速フィルタリング
1. 必要なカラムのみアクセス
全表走査
2. 効果的な圧縮技術により
圧縮した状態で検索が可能
(ディクショナリ圧縮)
Table Access Inmemory Full
フィルタリング
CPU
複数の
データを
ロード
Min 8
Max 12
Min 4
Max 7
Min 13
Max 15
ベクター・レジスタ
データ読込み
（インメモリ・スキャン）
Min 1
Max 3
3. インメモリ・ストレージ索引により
最小限のIMCUのみスキャン
CA
CA 一度の命令で
CA 全ての値を
ベクター演算
CA
4. 最新のプロセッサで搭載されて
いるSIMDにより高速スキャン
（ベクター・スキャン）
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
86
Oracle Database In-Memory Option による影響
想定される既存システムへの影響と変化
想定される変化
意思決定の精度向上
今現在の大量データを用いたリアルタイム
分析によるビジネスの俊敏性と正確性向上
システム・アーキテクチャのシンプル化
多様なワークロードを１つのDatabaseで処理
開発生産性・運用管理性の更なる向上
集約率の更なる向上によるTCO削減
変化しない事
 既存膨大なアプリケーション資産
次世代 インメモリ・アーキテクチャ
インメモリ処理が
アーキテクチャの中心へ
インメモリ・
ミドルウェア
インメモリ・
データベース
超高速
トランザクション
処理
高速
トランザクション
処理
集計・
分析処理
 アプリを書き変える事なく移行が可能
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
87
Oracle Database In-Memory
リアルタイム・エンタープライズの促進
DATADRIVEN
AGILE





究極の高速化: 分析とOLTP
容易な導入手法
究極のスケールアウトとアップ
究極の可用性
完全なるセキュリティ
EFFICIENT
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
88
Appendix
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
90
オブジェクト毎のインメモリ定義の確認
• USER_TABLES: オブジェクト毎のインメモリ定義
column
column
column
column
table_name format a20
PRIORITY format a15
DISTRIBUTE format a15
COMPRESSION format a20
Select table_name,
inmemory_priority priority,
inmemory_distribute distribute,
inmemory_compression compression
From user_tables;
ポピュレート優先度
ノード間分散方式
TABLE_NAME
PRIORITY
DISTRIBUTE
-------------------- --------------- --------------LINEORDER
CRITICAL
AUTO
PART
NONE
AUTO
CUSTOMER
NONE
AUTO
SUPPLIER
NONE
AUTO
DATE_DIM
NONE
AUTO
圧縮モード
COMPRESSION
-------------------FOR QUERY LOW
FOR QUERY LOW
FOR QUERY LOW
FOR QUERY LOW
FOR QUERY LOW
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
91
オブジェクト毎のポピュレーションの状態確認
• V$IM_SEGMENTS: オブジェクト毎のポピュレーションの状態
column
column
column
column
name format a20
owner format a10
status format a15
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
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
92
オブジェクト毎のインメモリ内のサイズと圧縮率の確認
• 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
DATE_DIM
64
1.125 56.8888889
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
93
Database In-Memoryのチューニング
1. 基本的にほとんどチューニング項目はない
–
ポピュレート完了の状態、パフォーマンス統計などの確認等
2. パラレル度の指定とパーティションの活用方法
–
–
CPUのネックにならないように検索のパラレル度を調整する
表サイズが大きい場合はパーティションを効果的に利用し
インメモリスキャンのスキャンサイズを小さくする
3. Attribute Clusterも限定的に利用検討する
–
検索条件頻度の高いカラムには「Attribute Cluster」の機能の適用を検討する
•
–
インメモリ・ストレージ索引の効果を高める可能性大
Attribute Clusterの仕様を理解したうえで利用する
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
94
Database In-Memoryでもパーティション表は効果的
リストパーティション（ SALES表）
P1: ORDER_STATUS=‘OPEN’
P2: ORDER_STATUS=‘CLOSED’
In-Memory
IMCU
パーティション単位に
最適なSQL実行計画を
選択可能
IMCU
ローカル索引
IMCU
P1: インメモリスキャンが最適
→ 最適なパフォーマンス
P2: 索引スキャンが最適
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
95
実行したインメモリ検索の速度が妥当か？
物理I/Oアクセスがないかをチェック
• 対応が必要なもの
– ポピュレートが未完了
– PGA領域不足（大量ソート、結合） ※通常のデータベース・チューニング
– Oracle RAC構成の場合でインターノード・パラレルクエリ
• パラレル度ポリシーの設定（AutoDOP）： PARALLEL_DEGREE_POLICY = AUTO
• 対応が特に不要なもの
– ハード・パースによるアクセス（2回目以降なくなる）
– Adaptive Plan、Dynamic Samplingによるアクセス（２，３回目以降なくなる）
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
96
ポピュレートが未完了
オブジェクトのポピュレートがまだ完了していない場合
POPULATE_STATUSが
「STARTED」で、
BYTES_NOT_POPULATED列に
値が表示される場合は未完了
SQL> select segment_name, populate_status, inmemory_priority, inmemory_size, bytes_not_populated from
v$im_segments;
SEGMENT_NAME POPULATE_STATUS INMEMORY_PRIORITY INMEMORY_SIZE
BYTES_NOT_POPULATED
------------ --------------- ----------------- ------------- ------------------ACCOUNTS STARTED
HIGH
196606
2434886912
SALES
COMPLETED
CRITICAL
135790592 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
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
インメモリ・カラム・ストアの
領域不足の場合に
「OUT OF MEMORY」が
表示される
97
PGA領域が不足している（大量ソート、結合など）
SQL Monitorより
待機イベント・サマリで
TEMP領域の書込発生
結合とソート処理で
ディスクI/Oあり
インメモリ・スキャンはCPUのみ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
98
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
99