データベースMeetup～Vol.2 HANAのOLTPのからくり
•Download as PPTX, PDF•
3 likes•1,175 views
2018年2月6日、TECHPLAY渋谷で行われたデータベースMeetup Vol.2より、インメモリーデータベースSAP HANAのOLTP機能の解説です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to データベースMeetup～Vol.2 HANAのOLTPのからくり
Similar to データベースMeetup～Vol.2 HANAのOLTPのからくり (20)
データベースMeetup～Vol.2 HANAのOLTPのからくり
- 3. Page | 3 3 • HANAのカラムストア→辞書エンコーディング 前回の復習 見かけは表形式の構造で、リ レーショナルテーブルの特性 やSQLによる処理をサポート しています テーブルはカラム単位に分解され、値を もつDictionaryと、各ローの値をポイント するValueID配列という２つの配列構造か ら成ります。基本的には1カラムに対する インデックスも作成可能です。 3 4 5 4 2x2 1 4 … Value ID配列 (bit fields) さらに、デー タは圧縮され ます。
- 4. Page | 4 4 • インメモリーデータベースの永続化の仕組みについて • データストア編 • トランザクション編 • カラムストアの更新を高速化する手法～OLTP&OLAP • Wite最適化ストア、Read最適化ストア • インサート・オンリー更新 • コンシスタントビュー • デルタマージ • ワークロード管理機能概要 • システム構成、アーキテクチャによる対応 本日のアジェンダ
- 5. Page | 5 5 • セーブポイント • データストア差分をデータ ボリュームに出力 • 少なくとも5分前の永続化 を保証 • 負荷視点 • 発生頻度：5分ごと(既定値) • 負荷内容：更新差分(ページ 単位）をディスクwrite • Tran量に左右される • セーブポイントの実行間隔を 変えることである程度制御可 能 データストアの永続化 04/14/2015 「SAP HANA運用管理の基礎知識(1) ～永続化、バックアップ、システムレプリ ケーションの基本動作を理解する～」より
- 6. Page | 6 6 • ロギング • トランザクション単位の 永続化 • 先書きログ方式 • メモリー上のログバッ ファにログエントリを 都度書き込む • Commitのタイミング でログバッファをディ スクにwrite • 負荷視点 • ログバッファサイズ • １MBと処理の相性？ トランザクションの永続化 04/14/2015 「SAP HANA運用管理の基礎知識(1) ～永続化、バックアップ、システムレプリ ケーションの基本動作を理解する～」より
- 8. Page | 8 8 • １つのカラム領域は、メインとデルタに分かれているようだ • 更新データは、デルタ領域に書き込まれるようだ • メインとデルタは読み書きの性能が違うようだ • デルタは、メインに移動・マージしてあげる必要がありそうだ このデモからわかること
- 9. Page | 9 9 カラムストアの高速化 インサート・オンリー、Read/Write最適化ストア UPDATE T1 SET PRICE=‘980’ WHERE ID=‘12345’ O_TOTAL..O_CUSTKEYO_CUSTKEY 18374 95625 42815 05639 12345 VALUE 1 2 3 4 5 IDカラム O_CUSTKEY : : 12345 : : VALUE : : 122 : : O_CUSTKEY T-Shirt Hat Socks Coat pants VALUE 1 2 3 4 5 Nameカラム O_CUSTKEY : : pants : : VALUE : : 122 : : O_CUSTKEY 1200 580 1980 480 980 VALUE 1 2 3 4 5 PRICEカラム O_CUSTKEY : : 880 : : VALUE : : 122 : : デルタストレージ メインストレージ Insert-Only 更新データは デルタストア の末尾に追記 Write最適化 • 更新差分 • ソートされない • 圧縮されない Read最適化 • 全件(マージ直後) • ソートされる • 圧縮される デルタマージ
- 10. Page | 10 10 カラムストアの高速化 デルタマージ マージ後 Read オペレーション New Main New Delta Write オペレー ション デルタ上のデータをメインに移動する作業 ディクショナリ、ValueID配列の再構成、再圧縮が生じる (メイン+デルタ)ｘ２、新デルタ（マージ中の変更分）のメモリーが同時に必要 マージ中 Read オペレーション Main New Delta Write オペレー ション Mergeオペレーション New Main Delta マージ前 Read オペレーション Main Delta Write オペレー ション
- 12. Page | 12 12 • Indexserver.ini[mergedoc]auto_merge_decision_func • (DRC*TMD > 3600*(MRC+0.0001)) • or • ((DMS>PAL/2000 or DMS > 1000 or DCC>100) and DRC > MRC/100) • or • (DMR>0.2*MRC and DMR > 0.001) • DRC:Delta Row Count • TMD:Time Merge Delay • MRC:Main Row Count • DMS:Delata Memory Siza • DCC:Delta Cells Count • DMR:Deleted Main Rows 制御パラメータの例 デフォルトでは自動実行。 Mergedog（内部スレッド）が60秒ごとに実施するかを判断。 • 相対的にデルタロー数がメインロー数に対して増加する • デルタメモリサイズが増加する • メイン削除ロー数が増加する といった傾向が強くなると実行されやすい。 マージの制御パラメータの変更はサポートissueです。
- 13. Page | 13 13 • コンシスタントビューマネージャ • 参照トランザクションにとって適切な データを抽出する • メインストアの更新削除されたデータ • デルタストアの最新以外のデータ • （正確には、MVCCも考慮して、参照トランに とって適切なデータを抽出する） • Visibilityフィルター • メインストア、デルタストアの各 ローがVisibleかどうかの情報 • 1ロー当たり1bitの配列 コンシスタントビューマネージャ 参照トラン デルタストア メインストア Where Nation=‘Italy’
- 14. Page | 14 14 • コンシスタントビューマネージャの作用は、 Visualize Planを通して垣間見ることができる コンシスタントビューマネージャ
- 15. Page | 15 15 OLTPとOLAPを同時に処理する仕組み Insert-Only 12347 VALUE 1 IDカラム 12344 12345 12346 VALUE 1 2 3 T-Shirts VALUE 1 NAMEカラム Socks Pants Pants VALUE 1 2 3 1000 VALUE 1 123452 Pants2 30002 PRICEカラム 980 2500 3500 VALUE 1 2 3 X X X 〇 〇 〇 Update T1 set PRICE = ‘3000’ where NAME = ‘Pants’ デルタストア メインストア アニメーション
- 16. Page | 16 16 OLTPとOLAPを同時に処理する仕組み コンシスタントビューマネージャ 12347 VALUE 1 IDカラム 12344 VALUE 1 T-Shirts VALUE 1 NAMEカラム Socks VALUE 1 1000 VALUE 1 123452 Pants2 30002 PRICEカラム 980 VALUE 1 123463 Pants3 35003 123452 Pants2 25002X X X 〇 〇 〇 Select * from TABLE where NAME = ‘Pants’ 12345 Pants 3000 12346 Pants 3500 デルタストア メインストア アニメーション
- 17. Page | 17 17 OLTPとOLAPを同時に処理する仕組み デルタマージ（Merge delta of テーブル名） VALUE 123471 IDカラム VALUE 123441 123452 123463 123452 X 〇 デルタストア メインストア 123452 IDカラム New Delta New Main VALUE 123441 123452 123463 123474 マージ中の更新は、 New Deltaへ VALUE 888881 99999２ アニメーション
- 18. Page | 18 18 • 重要なこと • HANAのカラムストアをオンラインでリアルタイムに更 新を行うのは非常に高コストな作業 • NEW DELTA＆MAINの領域 • ソート＆マージ • ディクショナリの再作成 • ValueID配列の再作成 • 再圧縮 • だから、そのコストをバッチ的に 遅延的に行うことにした • オンライン更新自身は軽くなった！ • 整合性を維持する仕組みとしてコンシスタン トビューマネジャ • 60秒ごとに遅延されたバッチ的な負荷がやってくるこ とは頭の隅に入れておくこと!! デルタマージ
- 19. Page | 19 19 • OLTP • メモリー上で処理（＋） • カラムストア上で処理（－） • Write最適化領域にInsert-only（＋） • 更新を遅延的バッチ的に実行してRead最適化領域を再構成（＋） • ローレベルロッキング • TSXー楽観的ロッキングシステム • OLAP • メモリー上で処理（＋） • カラムストア＋SIMDによるオンキャッシュ比率の向上（＋） • カラムストアー高速なスキャン（＋） • MVCCでブロックされることのない（＋） • Information view－OLAP専用の計算エンジンと開発環境というメタデータ収 集システム（＋） まとめ
- 20. Page | 20 20 • 以上が、HANAのトランザクション処理の仕組みと OLTP＆OLAPを1つのデータベースで処理する仕組み • だからといって、HANAの上にデータベースを構築し さえすればOLT&APができるというものではない • OLT&APは突き詰めると、１つのCPU・メモリ空間で 実行される2つの異質な処理（リクエスト）間の優先 度とリソース配分の問題 • だから、チューニングとワークロード管理は必須、場 合によってはアーキテクチャの“非正規化”による実現 も ？ OLTP OLAP OLTP/OLAP
- 21. Page | 21 21 HANAのワークロード管理概要 • CPUの使用を制御する • SQL文の同時実行、並列実行を制御する • SQL文が使用するメモリー量を制限する • アドミッション・コントロール • ワークロードクラスによる負荷管理
- 22. Page | 22 22 CPUの使用を制御する Socket(CPU) Core Core Core Core thread thread thread thread thread thread thread thread OS CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 Indexserver HDB Nameserver Indexserver CR1 CPU affinity設定 • nameserver, indexserver, compileserver, preprocessor, xsengine はプロセス単位で特定のCPU とバインドできる
- 23. Page | 23 23 SQL文の同時実行、並列実行を制御する Client SQL Listener SQL Executor Job Executor スレッド単位のSQL実行チャート • コネクション • セッションコンテキスト • ディスパッチ→SQL Executor • SQL解析 • 実行プラン作成、最適化 • シングル実行 • ディスパッチ→Job Scheduler • ディスパッチ→Job Worker • ジョブの分割 Job worker Job worker Job worker Job worker • ジョブの分割 • パラレル実行 • 同時実行の制御 • indexserver.ini[sql]sql_executor：SqlExecutorプール用の論理コア数のターゲット値（ソフトリミット） • indexserver.ini[sql]max_sql_executor ：SqlExecutorプール用の論理コア数の上限値（ハードリミット） • 並列実行の制御 • global.ini or indexserver.ini[execution]max_concurrency：JobExecutorが並列処理に使用するスレッドプールのサイズ • global.ini or indexserver.ini[execution]max_concurrency_hint：JobWorker用の論理コア数を制限する • global.ini or indexserver.ini[execution]default_statement_concurrency_limit：1ステートメントの1コネクション当たり並列度
- 24. Page | 24 24 • Statement memory limit • SQL文が実行する際に消費されるメモリーの総量に制限を設ける SQL文が使用するメモリー量を制限する Global Allocation Limit STATEMENT_MEMORY_ LIMIT_THRESHOULD STATEMENT_MEMORY_ LIMIT 100GB 60%(60GB) 2GB SQL1 SQL2Used Memory Used Memory SQL1は、LIMITを超 えているが、Used Memoryが60GB以内 →実行される SQL2は、LIMITを超 え、Used Memoryが 60GB超 →Out Of Mamory １SQL文あたりの メモリ使用制限 使用制限発動の閾値
- 25. Page | 25 25 アドミッションコントロール 統計情報 Enable=True Statistics_collection_interval(1000ms) 統計情報収集 Averaging Averaging_factor(70) Reject_cpu_threshould(0) queue_cpu_threshould(90) Reject_memory_threshould(0) queue_memory_threshould(90) 拒否 キューイング 実行 拒否 キューイング 実行 リクエスト リクエスト リクエスト Max_queue_size(10000) 拒否 実行 実行 実行 dequeue_interval(50) Queue Dequeue dequeue_size(50) リクエスト Indexserver.ini[admission_control]パラメータ 負荷(CPU)負荷(メモリー) High Low High Low High Low High Low アドミッションコントロール • システムのリソース使用状況が飽 和状態の時に、新しいリクエスト をどのように扱うか • 実行/拒否/キューイング • CPU、メモリーの使用状況で
- 26. Page | 26 26 • ワークロードクラス • 実行されるステートメントに対して処理の性格付けができる • 実行時の優先度は何か？ ：0-9 • メモリをどれだけ使えるか？ ： Statement Memory Limitの制限(GB) • 実行の並列度をどこまで高めらるか？：Job Workerスレッド数の制限 ワークロードクラスによる負荷管理 Client コネクション プロパティ • Application User Name • Client • Application Name • User Name • Application Component Name • Application Component Type マッピング ワークロードクラス マッピング ワークロードクラス マッピング ワークロードクラス デフォルトワークロードクラス
- 27. Page | 27 27 ワークロード管理概要 • CPUの使用を制御する • サービスプロセス⇔論理コアの結びつき • テナントデータベース視点の負荷管理はできそう • SQL文の同時実行、並列実行を制御する • インスタンス全体、テナントデータベース単位 • 同時実行・並列実行の多重度をコントロールできる • 但し、OLTP/OLAP awareなわけではない • SQL文が使用するメモリー量を制限する • アドミッション・コントロール • ワークロードクラスによる負荷管理
- 28. Page | 28 28 • システムレプリケーション Active/Active Read Enabled • ストリーミング・アナリティックス • AKA.スマートデータストリーミング システム・ランドスケープの話
- 29. Page | 29 29 • Active/Active(Read Enabled) • Active/Activeは、セカンダリーでRead onlyクエリーを実 行できる機能 • 新しいオペレーションモード • --operatioMode=logreplay_readaccess • プライマリーと同等の読み取り一貫性を提供するが、遅延 の可能性がある • フェールオーバー時の負荷集中に注意 • OLTP&OLAPの視点で言うと、 • 物理的DBは2つに分離 • レプリケーションで同期を維持 • 参照負荷をレプリカサイトにオフロードする システムレプリケーション Active/Active Read Enabled
- 30. Page | 30 30 スマートデータストリーミング SAP HANA システム HANA データベース ストリーミングサーバ 入力 ストリーム アダプタ アラート ダッシュボード アプリケーション Hadoop • ストリーミングソースからのイベン ト受信 • 毎秒数十万～数百万イベント • 入力データのフィルタ/リッチ化/標 準化 • すべてのデータをHANAに取り込むので はなく、最適化されたデータモデルによ る価値のあるデータのみを取り込むこと によってHANAのリソースを最適化 • データ量の削減 • 変更されたレコードだけ処理 • データのティアリング • IMDB、ダイナミックティアリングノー ドまたはHadoopに振り分け格納 • 複数パーティションに対する並列書き込 み→HANAデータベースへの高速ロー ディング スマートデータストリーミング OLTP&OLAPの視点から言うと、 • 超低レーテンシ、リアルタイムなレスポンスが必要な処 理をデータベースの手前で処理
- 31. Page | 31 31 • DBOnline HANA記事一覧 • https://enterprisezine.jp/dbonline/hana 参考記事
Editor's Notes
- 前回は、データベースがメモリー上に配置されること、One Fact, One Placeという考え方をカラムストアで実装しているという話、Information Viewの仕組みと性能、およびOLAPアプリケーションに与えた影響についてお話ししました。
- その中で、HANAが採用しているカラムストアは、内部的には辞書エンコーディングという構造を持ち、ユニークな値をもつディクショナリと、ディクショナリを参照するValueID配列という２つの配列構造から成ります。基本的には1カラムに対するインデックスも作成可能です。 この辞書エンコーディング構造の維持は、配列要素の追加・削除・更新が伴うことに加えて、圧縮・解凍を伴うためにコストが高いとされています。
- ここで、カラムストア更新の高速化の各機能やリソースを実感してもらうために簡単なデモをします。 ORDERSというテーブルを作成し、データをインポートします。 その間、Ordersテーブルの状態を見てみます。 Memory Consumption in Main Storageがメインストア、Memory Consumption in Delta Storageがデルタストアでそれぞれキロバイトでデータ量を表し、現在データは15万件で、その全てがデルタストアにあり約 33MB消費しています。 ここで、デルタマージを実行（右下）すると、データはメインに移動し、圧縮されて9MBをしめていることがわかります。 また、デルタマージの前後で全件読込の集計を行うと、メインの方がデルタより高億であることが分かります。 --デルタで実行 Statement 'select o.o_custkey, sum(o.o_totalprice) from ( select top 150000 * from orders order by o_custkey ) ...' successfully executed in 402 ms 643 µs (server processing time: 400 ms 227 µs) --メインで実行 Statement 'select o.o_custkey, sum(o.o_totalprice) from ( select top 150000 * from orders order by o_custkey ) ...' successfully executed in 136 ms 618 µs (server processing time: 134 ms 336 µs)
- DRC:Delta Row Count TMD:Time Merge Delay MRC:Main Row Count DMS:Delata Memory Siza DCC:Delta Cells Count DMR:Deleted Main Rows
- JECaptureIndexはプランには表示されないーVisibilityFilter、MVCCを反映したデータセットを抽出
- すでにID=12347,NAME=
- すでにID=12347,NAME=
- すでにID=12347,NAME=
- 同時実行・並列実行の多重度をコントロールできるが、OLTP/OLAP awareなわけではない
- 前提 global.ini[resource_tracking]enable_tracking = on global.ini[resource_tracking]mamory_tracking = on 設定 global.ini[memorymanager]statement_memory_limit １ステートメントに割り当てるメモリーの最大量 整数、GB単位(1GB～GAL) 既定値0(制限なし) 達すると’composite_oom’‘をファイル名に持つダンプファイル出力し、SQL文は異常終了 global.ini[memorymanager]statement_memory_limit_threshould statement_memory_limitを適用するかどうかの閾値をGALに対するパーセンテージで設定 既定値0（statement_memory_limit ） HANAのメモリー使用量が、statement_memory_limit_threshouldが示すメモリー量を超えたときのみstatement_memory_limitを適用する つまり、大してメモリーを使っていない場合、ステートメントメモリーの大きさは気にしない ユーザー単位の設定 ALTER USER <user_name> SET PARAMETER STATEMENT MEMORY LIMIT = <gb> グローバル設定とユーザー設定の両方がある場合、ユーザー設定を優先 解除 ALTER USER <user_name> CLEAR PARAMETER STATEMENT MEMORY LIMIT
- アドミッションコントロールは、ワークロードが高いとき、つまり、システムのリソース使用状況が飽和状態の時に、新しいリクエストをどのように扱うか、の仕組みです。 ワークロードは、CPU使用率とメモリー使用率で測ります。 デフォルトで1秒ごとに統計情報を取得し、Averagingという処理により重みづけされたCPU使用率とメモリー使用率が算出されます。 それぞれの使用率は、2レベルの閾値と比較されます。 １つめは、queueu_xxx_threshouldで、使用率がこれを超えるとキューイングされ実行が遅延されます。 2つ目は、reject_xxx_threshouldで、使用率がこれを超えるとリクエストは拒否され実行されません。 キューはサイズで管理されており、最大サイズに達した場合には、キューイングを停止します。 一定間隔でワークロードをチェックし、CPU、メモリーが実行可能なほど空けば、キューの中のリクエストはデキューされ実行されます。