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

Transcription

1 Presented with 第 138 回夜な夜な! なにわオラクル塾 Oracle12c Database In-Memory 入門! 日本オラクル株式会社データベース事業統括ソリューション本部中部 西日本 SC 部 2015 年 01 月 28 日

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

3 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 3

4 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 4

5 Oracle Database In-Memory の開発ゴール リアルタイム OLTP の アプリケーション 最新世代の アナリティクス 高速化 の変更なし H/W を有効活用 100x 2x CPU 5

6 Oracle Database In-Memory Option 既存データベースの概念を根底から覆すテクノロジー お客様の既存資産 ( データとアプリケーション ) の完全なる保護と継承 Oracle Database の卓越した高可用性とセキュリティ機能をそのまま利用可能 完全なるデュアルフォーマットの提供により OLTP と DWH の完全なる融合 情報系からのインデックス排除による開発 運用コストの劇的な削減 6

7 高速な分析をリアルタイム化する新たな技術革新 Database における主要な 2 種類のフォーマット ロー型 vs カラム型 ロー ( 行 ) 型 カラム ( 列 ) 型 売上 売上 OLTP 処理を得意とするロー型 例 : 注文データの挿入と検索 少数の行 ( ロー ) と多数の列 ( カラム ) を高速処理 集計 分析処理を高速化するカラム型 例 : 都道府県毎の売上合計のレポート 少数の列 ( カラム ) と多数の行 ( ロー ) を高速処理 Oracle Database In-Memory テクノロジーは 各特性を持つ 2 つのフォーマットを 両方同時に メモリー上にロードし利用可能 7

8 高速な分析をリアルタイム化する新たな技術革新 インメモリ デュアル フォーマット メモリー メモリー 同一のデータを行型 カラム型双方のフォーマットで保持 インメモリ化指定したもののみ 売上 行型フォーマット 売上 カラム型フォーマット 双方のフォーマットを同時に利用可能トランザクションの一貫性も担保 集計 レポート処理はカラム型フォーマットに対して実行 OLTP 処理は行型フォーマットに対して実行 1 つの Sales 表というオブジェクトに対して 2 つのフォーマット 8

9 OLTP と OLAP の性能向上はトレードオフどちらかを性能向上するとどちらかにオーバーヘッドが発生 OLTP トランザクション性能 OLTP と OLAP を 1 つのデータベースで共存することは難しい OLAP 分析処理性能 9

10 一般的な OLTP と DWH の構成 OLTP と DWH は別の HW で動作し 連携はバッチで同期を取っている DWH 用の HW や Database ライセンスコストがかかる リアルタイムにデータが見れない 夜間バッチのパフォーマンスのためにリソース強化 OLTP 夜間バッチで 1 日 1 回同期 DWH 10

11 Oracle 12c Database In-Memory: デュアル フォーマット Oracle 12c Database In-Memory はデュアル フォーマットなので データベースのオプティマイザが SQL にあわせて最適なフォーマットを選択して SQL を処理します ( 他社のインメモリ機能はハイブリッド型 : オブジェクトをどちらの方式にするか決定する必要あり ) Select * from sales_t Where order_id = ABC123 ; B-Tree 索引を使用した処理 sales_t 表デュアル フォーマット 行型 少数の行の全カラムのデータ取得 Select region, sum(amount) from sales_t Group by region; 一部カラムを使った大量行の集計処理 Oracle データベースオプティマイザ インメモリ検索を使用した処理 カラム型 11

12 アプリケーションの変更は不要 機能性実装容易性互換性マルチテナント - SQLの制限なし - データマイグレーションの必要なし - 全ての既存アプリケーションは改修なく動作 - クラウド対応済み アプリケーションの変更なく インメモリのメリットを享受 12

13 ベクター レジスタ カラム型表は何故分析用クエリーが高速か? ポイント 1: 集計に必要なカラムのみアクセス ポイント 2: 効果的な圧縮技術により圧縮した状態で検索が可能 ( ディクショナリ圧縮 ) C1 C2 C3 C4 C5 C6 ポイント 3: インメモリ ストレージ索引により最小限のユニットのみスキャン 例 ) where storeid > 8 Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 Min 13 Max 15 ポイント 4: 最新のプロセッサで搭載されている SIMD により高速スキャン CPU 複数のデータをロード CA CA CA CA 一度の命令で全ての値をベクター演算 ポイント 5: パラレル クエリーとパーティション表によりさらに高速化可能 13

14 カラム型表は何故分析用クエリーが高速か? ポイント1: 必要なカラムのみアクセス ( 行フォーマット型の場合 ) バッファ キャッシュ X X X X X SELECT COL4 FROM MYTABLE; 行フォーマット 結果 X X X X X 14

15 カラム型表は何故分析用クエリーが高速か? ポイント1: 必要なカラムのみアクセス インメモリ カラム ストア SELECT COL4 FROM MYTABLE; 結果 カラム フォーマット X X X X X 必要なカラムのみアクセス データの読込量少ない 15

16 カラム型表は何故分析用クエリーが高速か? ポイント1: 必要なカラムのみアクセス ( 実行計画 ) インメモリ検索の実行計画例 新しいアクセス方法 TABLE ACCESS INMEMORY FULL インメモリ検索を有効 / 無効化するパラメータ INMEMORY_QUERY = {enable disable} 16

17 カラム型表は何故分析用クエリーが高速か? ポイント2: ディクショナリ圧縮 非圧縮 EMP 表の JOB 列 CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER ANALYST PRESIDENT SALESMAN CLERK CLERK ANALYST CLERK 97 bytes ソートされた値 ディクショナリ (distinct された値 ) カラム値ディクショナリ値ビット表現 ANALYST CLERK MANAGER PRESIDENT SALESMAN カラム値サイズ合計 + ビット値合計 36 bytes + 3bit * 5 = 38 bytes エンコードされた各行の値 ディクショナリ圧縮 ディクショナリ圧縮は圧縮した状態で検索が可能 Where job = MANAGER Where job = 010 に内部的に変換 圧縮状態で検索可能 bit * 14 行 = 5.25bytes = 44 bytes (1/2.2 圧縮 ) 行 17

18 カラム型表は何故分析用クエリーが高速か? ポイント 3: インメモリ ストレージ索引 ( メモリー内に定義される ) 各カラムは複数の IMCU で構成される 各 IMCU で最小値 / 最大値を自動的に記録 Select From sales Where storeid > 8; メモリー IMCU Min 1 Max 3 WHERE 句の条件に合致する領域だけを読み込み IMCU Min 4 Max 7 すべての検索でパーティション プルーニングと同様のパフォーマンスを提供 storeid IMCU Min 8 Max 12 SALES 表カラムフォーマット IMCU Min 13 Max 15 IMCU - In-Memory Compression Unit 18

19 SIMD による効果的な演算 SIMD: Single Instruction Multiple Data ポイント4: 最新のプロセッサで搭載されているSIMD 命令セットにより高速スキャン 通常の命令セットの場合 (1 組のデータ演算から 1 つの結果を算出 ) 4 回の一致比較の場合 レジスタ CPU 命令 A1 B1 C1 A2 B2 C2 A3 B3 C3 A4 B4 C4 CMPEQ CMPEQ CMPEQ CMPEQ IF ( IF ( IF ( IF ( A1 = B1 ) C1 A2 = B2 ) C2 A3 = B3 ) C3 A4 = B4 ) C4 SIMD 命令セットの場合 ( 複数のデータを 1 回の演算命令で高速実行 ) ベクターレジスタ A1 A2 A3 A4 B1 B2 B3 B4 4 回繰返し CPU 命令 CMPEQ (SIMD) 1 回の命令で高速演算 ベクターレジスタ C1 C2 C3 C4 19

20 ベクター レジスタ カラム型表は何故分析用クエリーが高速か? ポイント4: 最新のプロセッサで搭載されているSIMD 命令セットにより高速スキャン インメモリ カラム ストア JOB カラム値ディクショナリ値ビット表現 ANALYST CLERK MANAGER PRESIDENT SALESMAN ディクショナリ圧縮により実データ値をビットデータとして扱うことでより多くのデータを CPU レジスタにロード可能 EMP 表 JOB 複数のデータをロード 例 : MANAGER 職種を検索 (MANAGER 010) SIMD CPU 一度の命令で全ての値をベクター演算 MANAGER 010( エンコード値 ) 20

21 カラム型表は何故分析用クエリーが高速か? ポイント5: インメモリ検索はパラレル クエリー パーティション表によりさらに高速化 インメモリ スキャン = TABLE ACCESS INMEMORY FULL パラレル クエリーでさらに高速化 QS QS QS 一部のパーティションをインメモリ化 パーティション プルーニングにより高速化 QS 基本的に Full Table Scan の発展系 データはインメモリ カラム型で圧縮 必要なカラムのみアクセス インメモリ ストレージ索引により最低限の IMCU スキャン カラム型 行型 P1 P2 P3 P4 21

22 Database In-Memory とパラレル クエリー autodop はインメモリ構成も考慮してパラレル度を決定 メモリー内で並列処理 QS インメモリ カラム ストア (IMC) インメモリ カラム ストアなので対象データはメモリー内にある QS QS In-Memory Parallel Execution と同様の動き (Buffer Cache ではなく IMC 利用 ) + 高速なインメモリ検索 QS クエリースレーブ 必要なカラムのみアクセス 効果的な圧縮 ( 高速検索 ) 効率的な SIMD 利用 インメモリ ストレージ索引 基本的にディスク読込は発生しない 22

23 Type Store ID Store ID Amount インメモリ検索による表の結合処理の高速化複数表の結合処理を内部的に高速カラム検索に変換 ( ベクター結合 ) 例 : 直販店 (outlet) の売上合計を集計 インメモリ カラム ストアにより複数表の結合処理を高速化 店舗 ジョイン フィルタ StoreID in 15, 38, 64 売上 1. ジョイン フィルタと呼ばれるフィルタをカラム検索を使用して作成 店舗表の TYPE= OUTLET に該当する StoreID をリスト 2. 作成したジョイン フィルタの条件にあう売上表の AMOUNT の合計値を計算 Type=Outlet インメモリ固有の機能ではないがインメモリ検索で非常に効果的 合計値 ジョイン フィルタから以下の条件を生成 where StoreID in (15, 38, 64) 上記の条件にヒットする行の売上表単体のカラム検索により高速に AMOUNT 列の合計値を算出 ( SUM(AMOUNT) ) 23

24 Footwear インメモリ検索による表の集計処理の高速化ベクター Group By(Vector Group By) 例 : アウトレットでの靴の売上を集計 店舗表 Outlets 商品表 インメモリ レポートアウトライン $ Outlets $$ $$$ $ 売上表 レポート アウトラインをメモリー上に動的に作成 ( インメモリ配列 ) レポート内の集計値はファクト表のスキャン中に展開 事前定義された多次元キューブを使わずに高速化 Footwear Sales インメモリ固有の機能ではないがインメモリ検索で非常に効果的 24

25 分析基盤におけるインデックスが不要 既存 Oracle Database による分析基盤 インデックスは事前予測可能なパターンのみ高速化 更新処理は 10~20 個のインデックスの更新が必要 パフォーマンス低下の原因 Oracle Database In-Memory の適用 インデックスなしですべてのカラム ( 列 ) の処理を高速化 カラム型ストアはディスク I/O なし 1 ~ 3 OLTP 用インデックス 10 ~ 20 分析用インデックス 1 ~ 3 OLTP インデックス インメモリカラム型ストア 表 表 25

26 スケールアウト構成 RAC との組み合わせ例 1/2 アプリケーションから透過的に表パーティション毎に柔軟な分散配置を構成可能 分散配置 大規模データを各ノードで分割して保持 ROWID もしくはパーティションで分割 インメモリ カラム ストアのスケールアウトが可能 In-Memory Parallel Query と組み合わせによるインメモリ並列処理が可能 複製配置 小規模データを各ノード重複して保持 2 ノードもしくはすべてのノードに複製 ノード耐障害性の向上 In-Memory Parallel Query と組み合わせによるインメモリ並列処理が可能 Real Application Clusters Real Application Clusters 26

27 スケールアウト構成 RAC との組み合わせ例 2/2 アプリから透過的にテーブル パーティション毎に柔軟な分散配置を構成可能 分散 + 複製配置 大規模データを各ノードで分割し保持 インメモリ カラム ストアのスケールアウトが可能 In-Memory Parallel Query と組み合わせによるインメモリ並列処理 各ノードの CPU を有効活用 複製データにより可用性を向上し 障害時の再インメモリ化 ( ポピュレーション ) 時間を削減 スケーラブルな可用性の高い並列分析処理基盤の構築が可能 In-Memory Parallel Query Real Application Clusters 複製データ (Duplicate 2) 27

28 可用性 セキュリティを既存の仕組みで実装可能 既存の Oracle Database の信頼性 可用性 拡張性 セキュリティに関わる機能を Oracle Database In-Memory でも透過的に利用可能 ストレージ フォーマット ロギング バックアップ / リカバリなどの運用管理に影響なし 既存の Oracle Database の可用性機能は透過的に動作 既存の Oracle Database のデータ保護機能も透過的に動作 ノード障害 サイト障害 データ破損 人的エラーなど 28

29 基本導入手順 ( 設定 運用管理 ) 事前調査基本 3 ステップ運用管理 本当に効果があるデータは何か? インメモリ カラム ストアのサイズは? インメモリ カラム化するデータの選択 不要なインデックスを削除 インメモリ カラム ストアの状況監視 29

30 容易な設定作業のみで実装可能 1. 使用するメモリ容量を設定 inmemory_size = XXX GB 2. メモリー上に格納するテーブル パーティションを選択 alter table partition inmemory; 3. インデックスを削除 30

31 TimesTen In-Memory Database 更なる OLTP レイテンシを要求される場面で In-Memory Technology を補完 150 マイクロ秒のネットワーク処理 同アドレス空間 アプリケーション N E T TIMESTEN IN-MEMORY DATABASE 5 マイクロ秒で SQL を実行 Oracle Database アプリケーションとデータベース間のネットワーク レイテンシによる OLTP 処理遅延 - 呼制御 株式トレーディング 他 TimesTen In-Memory Database 非常に軽量で高速なインメモリ DB - 非常に軽量で高速なインメモリデータベース - アプリケーションのアドレス空間で稼働ネットワークレイテンシなし - OLTP 処理を 30 倍高速化 31

32 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 32

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

34 インメモリ カラム ストアの基本構成 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 パラメータ 34

35 インメモリ領域 : SGA 内の新しい領域 INMEMORY_SIZE 初期化パラメータ 100MB が設定可能な最小値 SGA_TARGET に十分な空きが必要 スタティック ( 静的 ) なプール 変更後再起動 確認方法 SELECT * FROM V$SGA; NAME VALUE Fixed Size Variable Size Database Buffers Redo Buffers In-Memory Area

36 インメモリ領域 : 構成 2 つのサブプールで構成 : 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 プールにされる IMCU IMCU IMCU IMCU インメモリ領域 IMCU IMCU IMCU IMCU IMCU プール (1MB) SMU SMU SMU SMU SMU SMU SMU SMU SMU プール (64KB) 36

37 インメモリ領域 : 確認 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; IMCU プール SMU プール 割当領域 使用領域 空き領域 POOL ALLOC_MB USED_MB FREE_MB MB POOL KB POOL

38 インメモリ領域 : 使用状況 空きがある状態 SQL> select * from v$inmemory_area; POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS CON_ID MB POOL DONE 0 64KB POOL DONE 0 通常 64KB Pool の方が " 空き率 " が大きい 空きがない状態 SQL> select pool,alloc_bytes,used_bytes,populate_status from v$inmemory_area; POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS MB POOL OUT OF MEMORY 64KB POOL DONE 64KB Pool の方があふれることはない インメモリ領域があふれる場合 バックグラウンドプロセスの trc ファイルに以下が出力される ORA-64356: in-memory columnar area out-of-space alert.log に以下が出る Insufficient memory to populate table to inmemory area. 38

39 ポピュレーション 39

40 ポピュレーション (population) とは データをディスクからインメモリ カラム ストアへ載せる動作 ポピュレーションは既存データをメモリー中に最適化されたカラム型フォーマットで取り込む ポピュレーションは新しいデータを取り込まない ロギングのためのディスク I/O なし データ更新のオーバーヘッドを極小化 ポピュレーションのリクエストはキューに入れられる 2 分間隔でキューから取り出されタスクが実行される キューは優先度が指定される インメモリ領域 SALES ポピュレーションはバックグラウンドで実行される ORA_W001_orcl プロセス プロセス数は INMEMORY_MAX_POPULATE_SERVERS 初期化パラメータ ( 新規 ) で設定 40

41 ポピュレーション : オブジェクト ( セグメント ) 属性 INMEMORY 新属性 以下のセグメントの種類がサポートされる 表 パーティション サブパーティション マテリアライズド ビュー マテリアライズド ビュー ログ 代表的なサポートされないセグメントの種類 外部表 IOT( インデックス構成表 ) クラスタ化テーブル Out of line LOB SYS スキーマ SYSTEM 表領域, SYSAUX 表領域のオブジェクト Advanced Replication 設定されている表 ALTER TABLE sales INMEMORY; ALTER TABLE sales NO INMEMORY; CREATE TABLE customers PARTITION BY LIST (PARTITION p1 INMEMORY, (PARTITION p2 NO INMEMORY); 41

42 カラム レベルでの指定 (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); Enterprise Manager からも確認 設定可能 EM Cloud Control での設定も可能 42

43 サポートされないカラム LONG Inline でない CLOB, BLOB 4KB 以上の VARCHAR2 ネストされたテーブルカラム 仮想カラムはカラムレベルではサポートされない ORA-64359: INMEMORY clause may not be specified for virtual columns 同一表の中のサポートされないカラム以外はポピュレーションされる 43

44 AWR: インメモリ セグメント統計 AWR レポートにインメモリ セグメント統計が追加 V$IM_HEADER の TIME_TO_POPULATE カラムでポピュレーションにかかった時間を確認可能 44

45 IMCU - カラム型フォーマット 45

46 IMCU: In-Memory Compression Unit カラム型オブジェクトの管理単位 カラム型データをある程度の行数のセットで保持 ( 例 :50 万行程度 ) 格納される行は 1 つ以上の表エクステントから取得 IMCU の実サイズは行サイズ 圧縮率等により変化 ( 固定値ではない ) カラム毎に分離 / 近接したカラム ユニット (CU) として保存 Rowid も同様に 1 つの CU として保存 Extent #13 Blocks IMCU IMCUヘッダーカラム ユニット (CU) ROWID EMPID NAME DEPT SALARY Extent #14 Blocks Extent #15 Blocks

47 行型フォーマットとカラム型フォーマット On-Disk 表領域 : 行型フォーマット In-Memory Area: カラム ストア IMCU = In-Memory Compression Unit CU = Column Unit Data file 1 Data file 2 In-Memory Area IM Segment Data file N Segment Extent Extent Block IM Segment IMCU IMCU Extent Extent Block Block Row Row Row Row 8KB IMCU C U C U C U C U n MB 47

48 IMCU 分割基準 行数 または サイズ 数十万行 数 100MB 程度 行長平均が小さい場合 行数で分割される ポピュレーション時に分割し 1 プロセスが 1 つの IMCU 作成 HCC(Hybrid Columnar Compression) と比較するとユニットサイズは大きい 特別なカラム ユニット (CU) ROWID CU 各カラムの最大最小値エリア 48

49 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 49

50 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; IMCU サイズ IMCU 内行数 カラム数 OBJECT_NAME TSNAME ALLOC_MB NUM_ROWS NUM_COLS CUSTOMER TS_DATA CUSTOMER TS_DATA CUSTOMER TS_DATA DATE_DIM TS_DATA PART TS_DATA PART TS_DATA PART TS_DATA SUPPLIER TS_DATA

51 CU: カラム ユニット (Column Unit) IMCU に格納されている各カラム値の管理単位 全 CU は自動的に最小 / 最大値を保存 インメモリ ストレージ索引 圧縮フォーマット 例 ) ディクショナリ圧縮 CU は実際の値ではなく サイズの小さいディクショナリ ID をデータ値として格納 圧縮した状態で検索が可能 他の圧縮方式と組合わせることも可能 ディクショナリ VALUE ID Audi 0 BMW 1 Cadillac 2 カラム値リスト BMW Audi BMW Cadillac BMW Audi Audi CU Min: Audi Max: Cadillac

52 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; VARCHAR2 型列 :UTL_RAW.CAST_TO_VARCHAR2 DATE 型列 : DBMS_STATS.CONVERT_RAW_VALUE( プロシジャ ) 値の種類数 最小値 表名とスキーマ名とカラム番号の指定 最大値 OBJECT_NAME DICT_ENTRIES MIN_VALUE MAX_VALUE PART PART PART

53 圧縮 53

54 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; 54

55 圧縮動作 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) ポリシーに合わせて検討 55

56 圧縮アドバイザーとインメモリ 内部的にサンプルデータに対し圧縮を試行 6 段階の圧縮レベル対応 COMP_INMEMORY_NOCOMPRESS COMP_INMEMORY_DML COMP_INMEMORY_QUERY_LOW COMP_INMEMORY_QUERY_HIGH COMP_INMEMORY_CAPACITY_LOW COMP_INMEMORY_CAPACITY_HIGH 56

57 プライオリティー 57

58 ポピュレーションの優先度 ( プライオリティー ) 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); 58

59 ポピュレーションの優先度 ( プライオリティー ) 5 段階のプライオリティー 優先レベル CRITICAL HIGH MEDIUM LOW NONE 説明 オブジェクトは データベースのオープン直後に移入されます オブジェクトは すべての CRITICAL オブジェクトの移入後にインメモリ カラム ストアに使用可能な領域が残っている場合 移入されます オブジェクトは すべての CRITICAL オブジェクトと HIGH オブジェクトの移入後にインメモリ カラム ストアに使用可能な領域が残っている場合 移入されます オブジェクトは すべての CRITICAL オブジェクト HIGH オブジェクト および MEDIUM オブジェクトの移入後にインメモリ カラム ストアに使用可能な領域が残っている場合 移入されます オブジェクトは 初回スキャン後にインメモリ カラム ストアに使用可能な領域がある場合のみ移入されます ( デフォルト ) 59

60 Polling によるポピュレーションプライオリティ : LOW / MIDDLE / HIGH / CRITICAL タスク キューが 2 分間隔で poll される システム統計では "CPU: IM Prepopulate と表現される 注意点 : ポピュレートされていないプライオリティが CRITICAL に設定されている表があり インメモリ カラム ストアに空きがない場合でも ポピュレート済みのプライオリティが LOW の表を落とす動作は起こらない Critical High Middle Low IMCO Wnnn ポピュレーションタスク 60

61 オン デマンドのポピュレーション プライオリティ :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; * ERROR at line 1: ORA-03211: The segment does not exist or is not in a valid state 61

62 DML 実行時の動作 (Update / Delete) 従来通り バッファ キャッシュ ( 行型 ) で データ ブロックを更新 トランザクションの一時的な更新情報を Transaction Journal に記録 Commit 時 IMCU 内の該当行に対する Invalidate と Transaction Journal の解放を実施 バッファ キャッシュ update tab1 set c2=3 where c1=***; C1 C2 C3 インメモリ カラム ストア IMCU C1 C2 C3 Commit; 3 Invalid Transaction Journal 行の更新情報 従来の更新操作に加え IMCU 内の行の Invalidation を実施 62

63 DML 実行時の動作 -Insert( 動作イメージ ) 従来通りバッファ キャッシュ ( 行型 )/ ディスク上で行を挿入 トランザクションに関する一時的な情報をトランザクション ジャーナルに記録 新規に挿入された行は 2 分間隔の検知時もしくはクエリー発行時にポピュレーションが行われる バッファ キャッシュ 1 2 Insert IMCU C1 C2 C3 C1 C2 C3 メタデータ Commit; 4 インメモリ カラム ストア 5 Transaction Journal 3 新規 INSERT 分は IMCO の監視タイミング / クエリー発行時にポピュレーション 63

64 IMCU の再ポピュレーション 特定のタイミングで 無効な行を含む IMCU を再作成 ( 再ポピュレーション ) 更新処理とは非同期で実施 以下のタイミングで自動的に実施 多数の行が更新された時 ( 再ポピュレーション ) 2 分間隔 ( トリクル再ポピュレーション ) 手動実行も可能 DBMS_INMEMORY.REPOPULATE プロシージャ 表単位ではなく IMCU 単位で再作成 64

65 Oracle Database In-Memory 技術ポイントのまとめ インメモリ導入の容易性 インメモリ導入事前調査 技術要素 インメモリ カラム ストア 設定の基本 3 ステップ ポピュレーション 1. 使用するメモリ容量を設定 inmemory_size = XXX GB 2. メモリー上に格納するテーブル パーティションを選択 alter table partition inmemory; 3. インデックスを削除 カラム型フォーマット 圧縮 プライオリティー 65

66 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 66

67 OLTP と分析処理をリアルタイムに融合可能な 唯一の 仕組みインメモリ デュアル フォーマット : 高度な仕組み かつシンプルな設計 運用管理 ロー ( 行 ) 型とカラム型を 両方同時に 実現 顧客テーブル売上テーブル Oracle Database In-Memory 同期 処理内容に応じ ロー型 カラム型の適切なメモリを自動的に選択 インデックスは不要 ローとカラムは自動で同期 データフォーマットは 1 種類 VS 一般的なインメモリの仕組み ロー ( 行 ) 型とカラム型の どちらか一方を 選択 処理内容をユーザが意識しアクセスする必要あり ローとカラムはメモリ上では別管理 データフォーマット 2 種類を管理が必要顧客テーブル売上テーブル 67

68 コスト効率性の高いメモリ上へのデータ配置コスト効率と性能を柔軟にバランス ( スモールスタートが可能 ) Oracle Database In-Memory 高速化したいデータのみをメモリ上に展開 一般的なインメモリの仕組み 基本的に全てのデータをメモリ上に展開 頻繁に分析するデータのみをメモリ上に格納可能 VS 全てのデータがメモリ上にある前提で処理 頻繁にアクセスするデータはそれほど多くない 68

69 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 69

70 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) 中間一致検索 ( ユニーク値の列は除く ) 70

71 Database In-Memory の利用効果の大きい処理 ディスク I/O の物理読込 (Physical Reads) 量が大きい SQL とは? インメモリ化によるパフォーマンス改善が期待できる処理 SQL Monitor による確認例 全表走査 Full Table Scan 索引走査 Index Range Scan db file scattered read db file sequential read SQL の処理で多くのディスク アクセスが発生している (User I/O: db file scattered read) ディスクアクセス量大 このような SQL であればインメモリ化によるパフォーマンス改善の効果を期待できる 71

72 Database In-Memory の利用効果の大きい処理 大量行の表を含む結合処理 集計処理でディスクアクセスがある場合と比較 select sum(lo_quantity) from lineorder, customer where lo_custkey = c_custkey and c_nation in ( 'JAPAN', 'CHINA' ) ; Elapsed Time LINEORDER: 3 億件 CUSTOMER: 150 万件 バッファキャッシュ ( 索引 ) ディスクアクセスあり バッファキャッシュ ( 表 ) ディスクアクセスあり インメモリ 108 倍 ( 表 ) 64 倍 ( 索引 ) 高速 16 並列で実行 単位 ( 秒 ) 72

73 Database In-Memory の利用効果の大きい処理 大量行の表を含む結合処理 集計処理でディスクアクセスがある場合と比較 select max(lo_quantity) from lineorder where lo_orderkey between 1 and ; Elapsed Time LINEORDER: 3 億件 バッファキャッシュ ( 表 ) ディスクアクセスあり インメモリ 360 倍高速 5 並列で実行 単位 ( 秒 ) 73

74 Database In-Memory の利用効果の大きい処理 大量行の表に対する中間一致検索でディスクアクセスあり select sum(lo_quantity) from lineorder, customer where lo_custkey = c_custkey and c_region like '%RICA%' ; Elapsed Time LINEORDER: 3 億件 CUSTOMER: 150 万件 バッファキャッシュ ( 表 ) ディスクアクセスあり インメモリ 74 倍高速 16 並列で実行 単位 ( 秒 ) 74

75 Q) 大きなサイズのバッファ キャッシュを確保して 全データをキャッシュ内に 保持して実行すればインメモリ検索と変わらないのか? No 75

76 検証 1) フル キャッシュ ( 行 ) vs インメモリ ( 列 ) 全表スキャン vs 索引スキャン vs インメモリ スキャン バッファ キャッシュに表の全データがキャッシュされている場合とインメモリ検索の場合のパフォーマンスの違いを計測 実行 SQL 3 億行から 5,000 万行を抽出する select sum(lo_quantity) from lineorder where lo_orderkey between 1 and ; SGA バッファ キャッシュ ( 行 ) テーブル + 索引 全テーブル + 索引をキャッシュ vs SGA インメモリ カラム ストア ( 列 ) LINEORDER データ読込み &Pin 3 億行 LINEORDER ポピュレート 76

77 検証 1) フル キャッシュ ( 行 ) vs インメモリ ( 列 ) 3 億行の表から 5,000 万行を抽出する SQL フルバッファキャッシュ ( 索引 ) Database In- Memory Elapsed Time 表 ( フルキャッシュ ) 索引 ( フルキャッシュ ) 読込メモリブロック数 (consistent gets) 224 2,285, ,832 インメモリは圧倒的にメモリ読込量が少ない 索引はシングル ブロック読込なので大量行アクセスには非効率 ディスクアクセスなし フルバッファキャッシュ ( 表 ) インメモリ ディスクアクセスなし 31 倍 ( 表 ) 44 倍 ( 索引 ) 高速 5 並列で実行 単位 6 ( 秒 )

78 Q) インメモリ化すると全ての検索処理を高速化出来るのか? No 78

79 Database In-Memory の利用効果が大きくない処理 1. 索引により最適化されている ( 大きな表から少ない行データを検索する ) 数億 / 数千万行の表から 1~ 数百行取得するような検索 ハードウェア リソースの観点からインメモリ検索の並列度を高く設定出来ない 2. 集計値を別の仕組みで保持している マテリアライズド ビューにより集計値を保持 同一内の別カラム また別表に集計値を保持 79

80 少ない検索結果件数による比較索引 vs インメモリ 6 億行の表から 530 行を検索する SQL ( シリアル実行 ) select lo_quantity from lineorder where lo_custkey = ; 索引 インメモリ Elapsed Time 0.04 秒 0.13 秒 表の格納行数が多く 検索結果件数が少ないほど索引が若干速くなるケースが多い SQL ヒントを指定しないと索引アクセス処理になる 80

81 1. 情報系への適用 (DWH データマート 特定用途分析 ) DWH システムの分析クエリの高速化 ETL 処理の高速化 OLTP システム処理タイプにより両方定義 1 カラム型表による分析クエリの高速化 データウェアハウス (DWH) OLTP データベース OLTP データベース OLTP データベース カラム型表による ETL 処理の高速化 ( 大量の集計演算 ) 2 カラム型表中心に設計 81

82 2. OLTP 系システムの高速化 OLTP システムの分析 レポート処理の高速化 オンライン処理 索引削除で高速化 行型で OLTP カラム型で分析処理 バッチ / 分析処理 バッチ処理 : 集計レポート 日次 / 週次 / 月次レポート 会計期末レポート 原価計算処理 OLTP データベース カラム型で分析処理 ビジネス分析 販売管理ダッシュボード サービス ダッシュボード 82

83 3. リアルタイムデータ活用 OLTP システムで発生したデータをリアルタイムに活用 オンライン処理 索引削除で高速化 リアルタイムデータ活用 行型で OLTP 同期 OLTP& データ活用データベース カラム型でデータ活用 リアルタイム分析 新商品の初動確認 日配品の値下げタイミングの把握 マシン稼働状況の把握 リアルタイムデータ活用 重点商品の自動発注 リアルタイム プロモーション マシン予防保全 83

84 4. RAC を利用した OLTP- バッチ 分析処理の分離 バッチ専用ノードをインメモリ化 バッチ処理 分析 OLTP インスタンス 1 OLTP 処理専用 ( 非インメモリ ) バッファキャッシュ インメモリ カラム ストア INMEMORY_SIZE = 0 インスタンス 2 バッチ 分析処理専用 ( インメモリ ) バッファキャッシュ インメモリ カラム ストア INMEMORY_SIZE = 100GB Exadata 推奨 84

85 Program Agenda 開発の背景と概要技術ポイント他社インメモリDBとの違い利用用途例まとめ 85

86 ベクター レジスタ 高速にアクセス出来る理由インメモリ スキャンの高速フィルタリング 全表走査 Table Access Inmemory Full 1. 必要なカラムのみアクセス 2. 効果的な圧縮技術により圧縮した状態で検索が可能 ( ディクショナリ圧縮 ) データ読込み ( インメモリ スキャン ) フィルタリング CPU 複数のデータをロード Min 1 Max 3 Min 4 Max 7 CA CA CA CA Min 8 Max 12 Min 13 Max 15 一度の命令で全ての値をベクター演算 3. インメモリ ストレージ索引により最小限の IMCU のみスキャン 4. 最新のプロセッサで搭載されている SIMD により高速スキャン ( ベクター スキャン ) 86

87 Oracle Database In-Memory Option による影響想定される既存システムへの影響と変化 想定される変化 意思決定の精度向上 今現在の大量データを用いたリアルタイム分析によるビジネスの俊敏性と正確性向上 システム アーキテクチャのシンプル化 多様なワークロードを 1 つの Database で処理 開発生産性 運用管理性の更なる向上 集約率の更なる向上による TCO 削減 変化しない事 既存膨大なアプリケーション資産 アプリを書き変える事なく移行が可能 次世代インメモリ アーキテクチャ インメモリ ミドルウェア インメモリ データベース インメモリ処理がアーキテクチャの中心へ 超高速トランザクション処理 高速トランザクション処理 集計 分析処理 87

88 Oracle Database In-Memory リアルタイム エンタープライズの促進 DATA- DRIVEN EFFICIENT AGILE 究極の高速化 : 分析とOLTP 容易な導入手法 究極のスケールアウトとアップ 究極の可用性 完全なるセキュリティ 88

89

90 Appendix 90

91 オブジェクト毎のインメモリ定義の確認 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 SUPPLIER NONE AUTO FOR QUERY LOW DATE_DIM NONE AUTO FOR QUERY LOW 91

92 オブジェクト毎のポピュレーションの状態確認 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 SSB LINEORDER STARTED ,753,846,784 SSB CUSTOMER COMPLETED SSB DATE_DIM COMPLETED SSB PART COMPLETED

93 オブジェクト毎のインメモリ内のサイズと圧縮率の確認 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 PART SUPPLIER DATE_DIM

94 Database In-Memory のチューニング 1. 基本的にほとんどチューニング項目はない ポピュレート完了の状態 パフォーマンス統計などの確認等 2. パラレル度の指定とパーティションの活用方法 CPU のネックにならないように検索のパラレル度を調整する 表サイズが大きい場合はパーティションを効果的に利用しインメモリスキャンのスキャンサイズを小さくする 3. Attribute Cluster も限定的に利用検討する 検索条件頻度の高いカラムには Attribute Cluster の機能の適用を検討する インメモリ ストレージ索引の効果を高める可能性大 Attribute Cluster の仕様を理解したうえで利用する 94

95 Database In-Memory でもパーティション表は効果的 IMCU リストパーティション ( SALES 表 ) P1: ORDER_STATUS= OPEN P2: ORDER_STATUS= CLOSED In-Memory IMCU IMCU ローカル索引 パーティション単位に最適な SQL 実行計画を選択可能 最適なパフォーマンス P1: インメモリスキャンが最適 P2: 索引スキャンが最適 95

96 実行したインメモリ検索の速度が妥当か? 物理 I/O アクセスがないかをチェック 対応が必要なもの ポピュレートが未完了 PGA 領域不足 ( 大量ソート 結合 ) 通常のデータベース チューニング Oracle RAC 構成の場合でインターノード パラレルクエリ パラレル度ポリシーの設定 (AutoDOP): PARALLEL_DEGREE_POLICY = AUTO 対応が特に不要なもの ハード パースによるアクセス (2 回目以降なくなる ) Adaptive Plan Dynamic Sampling によるアクセス (2,3 回目以降なくなる ) 96

97 ポピュレートが未完了 オブジェクトのポピュレートがまだ完了していない場合 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 SALES COMPLETED CRITICAL SQL> select pool, alloc_bytes, used_bytes, populate_status from v$inmemory_area; POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS MB POOL OUT OF MEMORY 64KB POOL DONE インメモリ カラム ストアの領域不足の場合に OUT OF MEMORY が表示される 97

98 PGA 領域が不足している ( 大量ソート 結合など ) SQL Monitor より 待機イベント サマリで TEMP 領域の書込発生 結合とソート処理でディスク I/O あり インメモリ スキャンは CPU のみ 98

99 99

100