免責事項 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle は 米国オラクル コーポレーション及びその子会社 関連会社の米国及びその他の国における登録商標または商標です 他社名又は製品名は それぞれ各社の商標である場合があります 2
Oracle Database 12c Release 1 (12.1.0.2) CoreTech Seminar Oracle Database In-Memory: 検索処理の詳細 日本オラクル株式会社データベース事業統括製品戦略統括本部データベースエンジニアリング本部 Database & Exadata 技術部丹羽勝久 2014/08/20
Agenda 1 2 3 カラム型データベースの検索処理の特徴結合処理 (join) 集計演算処理 (aggregation) 4
高速な分析をリアルタイム化する新たな技術革新 DB における主要な 2 種類のフォーマット ロー型 vs カラム型 概要再掲 ロー ( 行 ) 型 カラム ( 列 ) 型 売上 売上 OLTP 処理を得意とするロー型 例 : 注文データの挿入と検索 少数の行 ( ロー ) と多数の列 ( カラム ) を高速処理 集計 分析処理を高速化するカラム型 例 : 都道府県毎の売上合計のレポート 少数の列 ( カラム ) と多数の行 ( ロー ) を高速処理 Oracle Database In-Memory テクノロジーは各特性を持つ 2 つのフォーマットを 両方同時に メモリー上にロードし利用可能 5
高速な分析をリアルタイム化する新たな技術革新 インメモリ デュアル フォーマット メモリー 売上 行型フォーマット メモリー 売上 カラム型フォーマット 1 つの Sales 表というオブジェクトに対して 2 つのフォーマット 概要再掲 同一のデータを行型 カラム型双方のフォーマットで保持 インメモリ化指定したもののみ 双方のフォーマットを同時に利用可能トランザクションの一貫性も担保 集計 レポート処理はカラム型フォーマットに対して実行 OLTP 処理は行型フォーマットに対して実行 6
行型の表とカラム型の表の構造イメージ 行ストア表 カラム ストア表 行 1 行 2 行 3 行 4 PRODID CUSTID ORDATE QTY AMOUNT 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 行 1 行 2 行 3 行 4 123 789 56 432 ABC XYX GHI SRE 04/02 12/01 11/10 2/22 12 43 2 8 列 AMOUNT 350 720 50 143 7
行ストアとカラム ストアの格納イメージ 行アクセスのイメージ Select * from t1 where 表イメージ 行ストア カラム ストア 国 US US JP UK 製品 Beta 売上 3,000 1,250 700 450 行ストアは行全体のアクセスが効率的 行 1 行 2 行 3 行 4 US 3,000 US Beta 1,250 JP 700 UK 450 行 国 製品 売上 US US JP UK Beta 3,000 1,250 700 450 行 8
行ストアとカラム ストアの格納イメージ 列アクセスのイメージ Select col1 from t1 ; 表イメージ 行ストア カラム ストア 国 US US JP UK 製品 Beta 売上 3,000 1,250 700 450 カラム ストアは少数のカラム アクセスが効率的 行 1 行 2 行 3 行 4 US 3,000 US Beta 1,250 JP 700 UK 450 列 国 製品 売上 US US JP UK Beta 3,000 1,250 700 450 列 9
rowid 001 002 003 004 行ストアとカラム ストアの格納イメージ rowid 付イメージ rowid 付表イメージ 国 US US JP UK 製品 Beta カラム ストアも行の認識に rowid を利用 売上 3,000 1,250 700 450 行 1 行 2 行 3 行ストア 001 US 3,000 002 US Beta 1,250 003 JP 700 rowid 国 製品 売上 カラム ストア 001 002 003 004 US US JP UK Beta 3,000 1,250 700 450 10
カラム型データベースの基本 カラム ストアから行データの実体化 sales_t 表 : カラム ストア rowid 国 製品 売上 001 002 003 004 US US JP UK Beta 3,000 1,250 700 450 select * from sales_t ; 行データの実体化 カラム ストアも行を特定する rowid を保有する rowid 001 002 003 004 rowid 付行データ 国 US US JP UK 製品 Beta 売上 3,000 1,250 700 450 11
SQL から見ると行型もカラム型も透過的 行型もカラム型もどちらもリレーショナル モデルを表現することに変わりはないため 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;. 列単位アクセス 行全体アクセス 結合 集計 ソート 行型とカラム型表との結合処理も可能 12
OLTPとOLAPの性能向上はトレードオフどちらかを性能向上するとどちらかにオーバーヘッドが発生 OLTP トランザクション性能 OLTP と OLAP を 1 つのデータベースで共存することは難しい OLAP 分析処理性能 13
Oracle 12c Database In-Memory: デュアル フォーマット Oracle 12c Database In-Memory はデュアル フォーマットなので データベースのオプティマイザが SQL にあわせて最適なフォーマットを選択して SQL を処理します ( 他社のインメモリ機能はハイブリッド型 : オブジェクトをどちらの方式にするか決定する必要あり ) Select * from sales_t Where order_id = ABC123 ; 少数の行の全カラムのデータ取得 B-Tree 索引を使用した処理 Oracle データベースオプティマイザ sales_t 表デュアル フォーマット 行型 カラム型 Select region, sum(amount) from sales_t Group by region; 一部カラムを使った大量行の集計処理 インメモリ検索を使用した処理 14
ベクター レジスタ カラム型表は何故分析用クエリーが高速か? ポイント 1: 集計に必要なカラムのみアクセス + 効果的な圧縮技術により圧縮した状態で検索が可能 ( ディクショナリ圧縮 ) C1 C2 C3 C4 C5 C6 ポイント 2: インメモリ ストレージ索引により最小限の IMCU のみスキャン 例 ) where storeid > 8 Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 Min 13 Max 15 CPU ポイント 3: 最新のプロセッサで搭載されている SIMD により高速スキャン 複数のデータをロード CA CA CA CA 一度の命令で全ての値をベクター演算 ポイント 4: パラレル クエリーとパーティション表によりさらに高速化可能 15
カラム型表は何故分析用クエリーが高速か? ポイント 1-1: 必要なカラムのみアクセス バッファ キャッシュ 行フォーマット X X X X X SELECT COL4 FROM MYTABLE; 結果 X X X X X 16
カラム型表は何故分析用クエリーが高速か? ポイント 1-1: 必要なカラムのみアクセス インメモリ カラム ストア SELECT COL4 FROM MYTABLE; カラム フォーマット X X X X X 結果 必要なカラムのみアクセス データの読込量少ない 17
カラム型表は何故分析用クエリーが高速か? ポイント 1-2: ディクショナリ圧縮 ------------------ CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER ANALYST PRESIDENT SALESMAN CLERK CLERK ANALYST CLERK 非圧縮 EMP 表の JOB 列 97 bytes ソートされた値 ディクショナリ圧縮 ディクショナリ (distinct された値 ) カラム値ディクショナリ値ビット表現 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 (1/2.2 圧縮 ) 行 18
カラム型表は何故分析用クエリーが高速か? ポイント 2: インメモリ ストレージ索引 ( メモリー内に定義される ) 各カラムは複数のカラム ユニット (IMCU) で構成される 各 IMCU で最小値 / 最大値を自動的に記録 WHERE 句の条件に合致する領域だけを読み込み すべての検索でパーティション プルーニングと同様のパフォーマンスを提供 DRAM Select From stores Where storeid > 8; メモリー SALES 表カラムフォーマット storeid IMCU IMCU IMCU IMCU Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 Min 13 Max 15 *1: IMCU - In-Memory Compression Unit 19
インメモリ ストレージ索引の確認方法 カラム内の IMCU 数の確認 V$IM_COL_CU ビュー オブジェクト内の IMCU 数の確認 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; 20
IMCU 内のディクショナリのエントリ数の確認 IMCU 内のディクショナリのエントリ数の確認 V$IM_COL_CU ビュー IMCU 内のエントリ数の確認例 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 21
インメモリ ストレージ索引の確認方法 IMCU 内の min/max 値の確認例 V$IM_COL_CU ビュー 最小値 最大値は RAW(2000) という型で保持される 22
インメモリ ストレージ索引の確認方法 IMCU 内の min/max 値の確認例 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 ( プロシージャ ) 23
インメモリ ストレージ索引の確認方法 効果の確認方法 V$MYSTAT ( 同一セッション内で確認 ) / V$SYSSTAT( システムレベル ) 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 24
SIMD による効果的な演算 ポイント 3: 最新のプロセッサで搭載されている SIMD 命令セットにより高速スキャン SIMD: Single Instruction Multiple Data 通常の命令セットの場合 (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 25
ベクター レジスタ カラム型表は何故分析用クエリーが高速か? ポイント 3: 最新のプロセッサで搭載されている SIMD により高速スキャン インメモリ カラム ストア JOB カラム値ディクショナリ値ビット表現 ANALYST 0 000 CLERK 1 001 MANAGER 2 010 PRESIDENT 3 011 SALESMAN 4 100 001 100 100 010 100 010 010 000 011 ディクショナリ圧縮により実データ値をビットデータとして扱うことでより多くのデータを CPU レジスタにロード可能 EMP 表 JOB 例 : MANAGER 職種を検索 (MANAGER 010) 複数のデータをロード SIMD 010 100 010 010 001 110 010 100 MANAGER 010 ( エンコード値 ) CPU 一度の命令で全ての値をベクター演算 26
カラム型表は何故分析用クエリーが高速か? ポイント 4: インメモリ検索はパラレル クエリー パーティション表によりさらに高速化 インメモリ検索の実行プラン例 新しいアクセス方法 TABLE ACCESS INMEMORY FULL インメモリ検索を有効 / 無効化するパラメータ INMEMORY_QUERY = {enable disable} 27
カラム型表は何故分析用クエリーが高速か? ポイント 4: インメモリ検索はパラレル クエリー パーティション表によりさらに高速化 インメモリ スキャン = TABLE ACCESS INMEMORY FULL パラレル クエリーでさらに高速化 QS QS QS 一部のパーティションをインメモリ化 パーティション プルーニングにより高速化 QS 基本的に Full Table Scan の発展系 データはインメモリ カラム型で圧縮 必要なカラムのみアクセス インメモリ ストレージ索引により最低限の IMCU スキャン カラム型 行型 P1 P2 P3 P4 28
Database In-Memory とパラレル クエリー autodop はインメモリ構成も考慮してパラレル度を決定 メモリー内で並列処理 QS インメモリ カラム ストア (IMC) インメモリ カラム ストアなので対象データはメモリー内にある QS QS In-Memory Parallel Execution と同様の動き (Buffer Cache ではなく IMC 利用 ) + 高速なインメモリ検索 QS クエリースレーブ 必要なカラムのみアクセス 効果的な圧縮 ( 高速検索 ) 効率的な SIMD 利用 インメモリ ストレージ索引 基本的にディスク読込は発生しない 29
Agenda 1 2 3 カラム型データベースの検索処理の特徴結合処理 (join) 集計演算処理 (aggregation) 30
Type Store ID Store ID Amount インメモリ検索による表の結合処理の高速化 複数表の結合処理を内部的に高速カラム検索に変換 ( ベクター結合 ) 例 : 直販店 (outlet) の売上合計を集計 店舗 Type=Outlet ジョイン フィルタ StoreID in 15, 38, 64 インメモリ固有の機能ではないがインメモリ検索で非常に効果的 売上 合計値 インメモリ カラム ストアにより複数表の結合処理を高速化 1. ジョイン フィルタと呼ばれるフィルタをカラム検索を使用して作成 店舗表の TYPE= OUTLET に該当する StoreID をリスト 2. 作成したジョイン フィルタの条件にあう売上表の AMOUNT の合計値を計算 ジョイン フィルタから以下の条件を生成 where StoreID in (15, 38, 64) 上記の条件にヒットする行の売上表単体のカラム検索により高速に AMOUNT 列の合計値を算出 ( SUM(AMOUNT) ) 31
ベクター結合の実行計画例 実行 SQL) select sum(lo_revenue*lo_discount) from lineorder, date_dim where lo_orderdate = d_datekey and d_year = 1996; 1 ジョイン フィルタ作成 (DATE_DIM) :BF0000 ( ブルーム フィルタ ) 2 ジョイン フィルタ利用した LINEORDER 表のカラム検索 この例はパラレル クエリー実行 32
Type Store ID Store ID Amount Prod ID ProdID Category 複数表のベクター結合の実行イメージ 例 : 直販店 (outlet) の T-Shirts の合計売上を集計 3 つの表のジョイン処理を売上表の単一のカラム検索に変換 売上 店舗 ジョイン フィルタ StoreID in 15, 38, 64 ジョイン フィルタ ProdID in 100, 219, 872 商品 Type=Outlet 合計値 Category=T-Shirts 33
複数表のベクター結合の実行計画例 ジョイン フィルタ作成 ジョイン フィルタ利用 34
Swap Join Input Optimization HASH JOIN を順番に実施 ( 今までの実行プラン ) Left deep tree 3 HASH JOIN 2 HASH JOIN DATEDIM 4 1 HASH JOIN SUPPLIER 3 1 PART LINEORDER 2 35
Swap Join Input Optimization 複数のジョイン フィルタを利用してファクト表の高速カラム検索 right deep tree HASH JOIN 3 何故この機能が重要か? 1 ジョインフィルタ作成 DATEDIM HASH JOIN 2 LINEORDER をマルチプルフィルタを利用して初期スキャンをすることにより上位の実行プランで処理する行数を縮小する 2 SUPPLIER HASH JOIN 1 ジョインフィルタ作成 ジョインフィルタ作成 3 PART LINEORDER 4 複数のジョインフィルタによる LINEORDER 表 ( ファクト表 ) の高速カラム型検索 36
ジョイン フィルタを使ったジョイン処理のイメージ 2 ジョインフィルタの利用 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 ジョインフィルタ ジョインフィルタ ジョインフィルタ 1 ジョインフィルタの作成 フィルタ列カラム検索 ジョイン列のフィルタ生成 フィルタ列カラム検索 ジョイン列のフィルタ生成 フィルタ列カラム検索 ジョイン列のフィルタ生成 4 検索結果を生成するためにジョイン バック 3 フィルタ条件にマッチするファクト表 ( 最大件数表 ) の列 行を抽出 37
通常の結合処理との実行コスト比較 SQL 例 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> / 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 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 ------------------------------------------------------------------------------------------ 39
通常の結合処理との実行コスト比較 インメモリ検索のベクター結合を有効化 SQL> / 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 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 ------------------------------------------------------------------------------------------- 40
Agenda 1 2 3 カラム型データベースの検索処理の特徴結合処理 (join) 集計演算処理 (aggregation) 41
Outlets インメモリ検索による表の集計処理の高速化 ベクター Group By(Vector Group By) 例 : アウトレットでの靴の売上を集計 インメモリ固有の機能ではないがインメモリ検索で非常に効果的 商品表 Footwear 店舗表 インメモリ レポートアウトライン Footwear $ $$ $$$ $ 売上表 レポート アウトラインをメモリー上に動的に作成 ( インメモリ配列 ) レポート内の集計値はファクト表のスキャン中に展開 事前定義された多次元キューブを使わずに高速化 Outlets Sales 42
インメモリ集計 : 詳細イメージ例 )OutletのFootwearの売上をブランド 地域ごとに集計する ストア表 (Stores) ID Name SType Region 1 ABC Dept Store APAC 2 XYZ Outlet NAS 3 CCC Outlet EMEA 商品表 (Products) ID Name Category Brand 1 XS-1234 T-Shirt PUMA 2 AJ-2322 Footwear FILA 3 PW-698 Footwear NIKE Outlet の Footwear の売上をブランド 地域ごとに集計 売上表 (Sales) 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 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) 43
Products DGK (BRAND) インメモリ集計 : 詳細 アニメーション 革新的な技術 : スター スキーマのジョインと集計処理にメモリー上の配列 ( インメモリ配列 ) を使う Stores 1 フィルタ条件 3DGK(Dense Grouping Key) 値で構成される集計値を格納するインメモリ配列の作成 STORE_ID PROD_ID Sales SALES インメモリ レポート アウトライン Stores DGK (REGION) 1 2 3 4 5 6 Products 1 2 10 15 20 3 STORE_ID REGION (Key Vector) PROD_ID BRAND (Key Vector) 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 TIME_ID 2 結合キー +Key Vector 配列を作成しフィルタ条件に一致しない Key Vector 値は 0 を設定 (Key Vector 値 = グループ集計カラム値 ) 44
実行計画から見るベクター Group By (1) DIM_CUST_IMC 表のインメモリ検索をして Key Vector(:KV0001) を作成する この Key Vector は FACT_IMC 表との結合キーとグルーピング列の Key 値を保存する 45
実行計画から見るベクター Group By (2) 次に Vector Group By を実行することで DGK (Dense Grouping Keys) を生成し さらに検索結果表示に必要な他のカラムもあわせて一時表に保存する 46
実行計画から見るベクター Group By (3) 他のディメンジョン表に対しても同様の処理を行う この例では DIM_TIME_IMC 表の Key Vector の作成 Vector Group By による一時表の作成を行う 47
実行計画から見るベクター Group By(4) Key Vector を利用して 結合キーのフィルタを適用しながらファクト表 (FACT_IMC) の単体スキャンを行う 48
実行計画から見るベクター Group By(5) スキャンされたファクト表 (FACT_IMC) の集計対象列による集計処理を行う 集計処理は内部的に作成されたインメモリ配列に随時格納することで行われる 49
実行計画から見るベクター Group By(6) (5) で作成されたインメモリ配列と Vector Group By で作成された一時表をジョイン バックすることでグルーピング列の値を取得して最終結果を生成する 50
ベクター 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; 51
通常の集計処理との実行コスト比較 比較結果 インメモリ検索 - ベクター Group By 無効化 Elapsed: 00:00:51.11 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 52
通常の集計処理との実行コスト比較 比較結果 インメモリ検索 - ベクター Group By 有効化 Elapsed: 00:00:28.57 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 53
まとめ インメモリ検索は分析クエリーが高速 余分なカラム読込なし 効果的な圧縮方法 - 圧縮した状態で高速検索 ( ディクショナリ検索 ) 必要最低限の領域 (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
Appendix 56
単純集計演算処理 12.1.0.2 beta3 使用 使用したSQL (t1 表は50 億件 ) 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; 100 80 60 100 100 100 11g の応答速度を 100 とした場合の 12c インメモリの相対的な値 両方ともパラレル クエリー使用 40 20 0 2.07 4.31 5.23 SUM c1, SUM c1, c2 SUM 11g 12c インメモリ 57
58