高速化を実現した５つの技術革新
2. 高速化を実現した５つの技術革新
2. 高速化を実現した５つの技術革新
高速化を実現した５つの技術革新
①インメモリデータベース
②Row Store →Column Store
③辞書圧縮
④集計テーブルのView化
⑤OLAP高速化 HANA View
インメモリデータベース
※SAPが自動で行う処理の為、ABAP作成の際に開発者が意識する必要はありません。
元の課題
SAPでデータ更新を行うと、CPU → メモリ → ハードディスクの一連の流れがセットとなり、都度更新されていました。
また、それぞれの更新の処理速度には大きな差がある事がわかっていました。
CPU → メモリ が50ナノ秒に対して、
CPU → ハードディスクは5,000,000ナノ秒
つまり、10万倍の処理速度差がありました。
上記のような時間がデータが更新される度発生しており、特にメモリ→ハードディスクでの処理がリアルタイムでの分析の障害となっておりました。
この障害、課題は、HANAに限らず、IT業界では、共通の課題となっており、色々試行錯誤し、I/O(読み込み/書き込み)速度の短縮を図っていました。
SAP HANAでは、その課題をそもそもの処理速度が要件に対して遅いディスク(SSD,HDD)を使わずに、格納していたデータをすべてメモリ上に載せてデータを扱うインメモリデータベースを採用して解消を図っています。
インメモリデータベースにすることにより、メモリ → ハードディスクの処理で5,000,000ナノ秒かかっていた処理が、全て「CPU → メモリ」50ナノ秒になり、およそ10万倍の処理速度の高速化が可能になります。
ただし、メモリ上にすべてのデータを保管した場合、電源などが落ちたりなど障害が発生するとメモリ上のデータは消失してしまう可能性があるため、一定の間隔でHDD、SDDなどの補助記憶装置にはデータが保管されています。
そのため、インメモリデータベースでは、HANA化においてHDD、SSDは無くなりません。
技術革新により
インメモリデータベースでは、非常に時間が掛かるデーターベース(HDD,SDD)への更新を完了(COMMIT)するまでの処理について、方法が変わりました。
インメモリデータベースのS/4HANAにおいて、更新は一旦メモリ上迄とし、データベース(HDD,SDD)への更新は一定時間毎に纏めて行うこととし、これにより高速化を図っています。
補足
メモリ上でも更新履歴を保持しているため、データベースへの更新が未完了のデータに対しても修正や抽出が可能です。（メモリのデータが利用可）
Row Store → Column Store
Row Store
これまでは、データの登録も集計もすべて行(row・ロウ)単位で行っていました。
Column Store
HANAでは、データを列(column・カラム)単位で扱います。
元の課題
ローストア(横)の持ち方は、小さいデータを更新するようなOLTPに向いているが
大量データを分析するOLAPには不向き (遅い)というのが挙げられます。
例えば、伝票データには多くの情報※が含まれており、それはレコード単位（横）で管理されていました。
※項目＝カラム：伝票番号、取引先、日付、金額、支払日等
一方、分析する際は、取引先ごとにいくらとなる？など、登録されているデータをカラム単位（縦）で利用する必要がありました。
技術革新により
カラムストアを採用する事で、処理に時間が掛かっていたOLAPの高速化が可能となりました。
補足
-
新規テーブルを定義する際、カラムストアかローストアを選択する事ができます。
ただ、今後ローストアは殆ど使われず、あっても殆ど更新が発生しないマスタ等となります。 -
以前のSAPでのテーブル定義は全てローストアであったが、HANAへのマイグレーションの際に
自動的にカラムストアに変更されます。
辞書圧縮
※SAPが自動で行う処理の為、ABAP作成の際に開発者が意識する必要はありません。
元の課題
ローストア(横)の持ち方は、大量データを分析するOLAPには不向きでした。(遅い)
そのため、分析をなるべく速くする為に、よく検索するカラム（項目）を指定し手動で索引（INDEX）を登録し、それを利用する事でOLAPの高速化を図っていました。
ただし、全ての項目また組み合わせに対してではない為、検索条件を変えると索引の効果は得られず遅いという問題がありました。
技術革新により
辞書圧縮が利用でき、全てのカラム（項目）において自動的に索引(INDEX)が作成されました。
これにより処理に時間が掛かっていたOLAPの高速化が可能となりました。
補足
既存のSAPにて作成した索引(INDEX)はHANAにすると不要になります。
また、新規で索引を作成することも基本的にはなくなります。
HANAへのマイグレーションの際に自動的に無効状態となります。
集計テーブルのView化
※SAPが自動で行う処理の為、ABAP作成の際に開発者が意識する必要はありません。
元の課題
ひとつの取引データでも、複数テーブルに実データを登録していました。
例えば、会計伝票の登録でみると。全ての会計伝票のデータは、総勘定元帳テーブル（BKPF/BSEG)に登録されます。また、その会計伝票が仕入に関するものであれば、補助元帳での管理も必要となり、別テーブルにもデータが登録されます。
管理会計での管理要件もあるなら、更に別テーブルにも登録していました。
なお、追加で登録されていたテーブルを2次インデックスの集計テーブルと呼びます。
技術革新により
集計テーブルは実テーブルではなくビューに置き換わりました。 つまり、データを複数持つのではなく、データはあくまで一つであるが、集計テーブル側では、目的別にフィルターが掛かった結果を表示する事で、今までどおりの出力結果を表示するようにしました。
これにより、実データの登録先は最小におさえられる事となりました。
補足
- 2次インデックス等の集計テーブルは、ビューとして引き続き利用可能です。
- 今まであったクラスタテーブル（BSEGのように一つのテーブルにみえるが、中身は複数のテーブルの集合）は廃止され、すべて透過テーブル(実データが存在)となりました。
OLTP高速化
※SAPが自動で行う処理の為、ABAP作成の際に開発者が意識する必要はありません。
元の課題
ローストアの持ち方は、小さいデータを更新するようなOLTPに向いていたが、大量データを分析するOLAPには不向きでした。(遅い)
逆にHANAにてカラムストアに変えると、OLTPに不向きとなるのでそれを解消する必要がありました。
例えば、辞書圧縮などは、データが追加で登録されると全ての項目に対して項目毎に辞書を再作成する必要があり、データ更新時に今まで以上に時間が掛かる事となりました。
技術革新により
OLAPを高速化する一方、更新処理はこれ迄に比べ遅くなる傾向。少しでも緩和する機能として実装されています。
特に緩和をさせている機能として、SAP HANAは、カラムストアのOLTPに弱い デメリットを克服するため
OLTP、OLAPに最適化された2つのメモリー領域を使用して緩和しています。
2つの領域のうち、
OLAPに最適化されたメモリー領域を、メインストレージと呼びます。
OLTPに最適化されたメモリー領域は、デルタストレージと呼びます。
このデルタストレージのメモリ領域にてSAP HANAは更新処理を行うように設計しています。