Technical Articles
HANA Cloud でデータの階層化を実現するNative Storage Extension（NSE)
お断り：このブログでご紹介するNative Storage Extension(NSE)は、オンプレミス版のSAP HANAにも同じ機能が提供されていますが、ここではHANA Cloudを前提としたご説明としますので、オンプレミス版のHANAを想定されている場合はご注意ください。
.
SAP HANA Native Storage Extension(NSE)とは？
.
これまでにHANA Cloudに関連して、Data Lakeに関するブログを書きましたが、今回ご紹介する Native Storage Extension (NSE) も、ストレージベースのデータ保持機構という点で共通点を持っている機能です。まずは、このNSEとData Lakeについての基本的な説明ですが、すでにわかりやすいブログの記事が公開されていますので、まずはこちらの「仮想データアクセス」、「データ階層化管理」の二つの章をご一読ください。
.
以下に簡単にまとめると、インメモリアーキテクチャを採用したSAP HANAは、基本的にすべてのデータがメモリ上に配置されていますが、超高速なパフォーマンスを発揮できる一方で、圧縮して保持しているとはいえ、データベースの規模が非常に大きくなった時にメモリサイズも大きくなるに伴い、コストに与えるインパクトも無視できないお客様も増えてまいりました。それに対応した機能がNSEとData Lakeによる「データ階層化管理」になります。
長期間のデータを保持する、という観点で考えてみると、データベースが処理するデータの利用頻度は直近のデータが高く（Hotデータ）、時間が経過したデータ（Warmデータ）ほど利用される頻度は低下するのが一般的です。このため一定の閾値を設けてそれより古いデータはコストの低いストレージ領域（HDD、あるいはSSD）に配置しておき、必要に応じて処理する事でシステムコストのバランスをとることが可能になります。
また、昨今のIoTデータや大量に生成されるログデータのようにテーブルの構造はもちながら（構造化されたデータ）件数の増加が著しいデータもメモリに配置するのではなく、ストレージベースに配置するほうが適したデータと言えます。
一方で両者に共通するのはストレージベースとはいえ処理速度はある程度維持したいというニーズです。これまでのブログでご紹介しましたData Lakeは後者のニーズに最適な機能であり、前者のニーズに適しているのが、NSEになります。
.
NSEのアーキテクチャ
.
前述の通り、NSEはストレージベースのデータ保持機構ですが、もう少し具体的なアーキテクチャについてご説明します。
上の図の左側に示すHANAがNSEを使用しない場合のデータの配置になります。すべてのデータはDROM領域に配置され、同時にRDBMSの要件である永続性（コミットされたトランザクション処理によるデータは、結果が失われないことを保証する）を維持するためのPersistence Layer（HDDもしくはSSD等で構成されるストレージ領域）にも記録されます。すべてのデータはメモリ上にあるので、必要なデータが要求された場合はメモリからデータを取得する事ができるので、高速な処理が可能です。
.
上の図の右側に示すのがHANAがNSEを使用する場合のデータの配置になります。ある一定の期間を過ぎた取引履歴のデータ（Warmデータ）などは利用頻度が低下するのが一般的である事は先に指摘しました。これらのデータをメモリに常駐させるのではなく、取引日などをキーとしたパーティション機能を使って一定の期日より古いデータに関してはメモリの常駐を解き、要求された時点でNSE用メモリ領域（Buffer Cache）にロードされ、処理されるようにするのがNSEの機能です。これにより、メモリに対するユーザデータの格納サイズを拡大する事が可能になります。
トレードオフとして、NSEの機能を有効にしたWarmデータの処理は、Hotデータよりも処理速度は低下する事にご留意ください。このバランスを考慮しないとコストとパフォーマンスのバランスを崩してしまうことになりますので、このWarmデータのサイズは不用意に大きくしない事は重要なポイントになります。デフォルトでBuffer Cacheはメモリ全体の10%となっています。
>
.>>>>
パーティションと「Column Loadable」「Page Loadable」属性 (LOAD UNIT)
.
このNSEを使ってHotデータとWarmデータという性格付けをするのがパーティション機能と、テーブル定義に与えられる「Column Loadable」「Page Loadable」という属性（LOAD UNITと呼びます）になります。
.
.
重要な事は、NSEはテーブルのパーティション機能を使用した仕組みであり、ユーザやアプリケーションから見た場合、NSEを有効にしてもしなくても同じテーブルとして利用できるということです。データベース管理者が最適な設計をすることで機能し、データを利用する側には何の変更も必要ありません。
.
NSEを導入するシナリオ例
.
NSEを導入するのは以下のようなシナリオが想定されます。
- テーブル作成当初は、HANA Cloudに十分なメモリ領域があるので、通常のテーブルを作成する。
- 業務の開始に伴いデータがテーブルに蓄積する。
- システムの稼働から時間が経過し、データの増加が見込まれる事と、一定期間よりも前のデータの利用頻度が下がる事を想定し、NSE設定を利用する事を決定する。
- 対象となるテーブルにNSEを有効化するための設定を行う。
サンプルテーブルによる設定例
.
以下の操作を行うために、HANA Cloudのトライアル環境を用意し、ブラウザによる操作を行うためのHANA Database Explorerが利用できるようにしておいてください。この準備には、こちらのブログをご参照下さい。
それでは実際のNSEの設定方法を確認してみましょう。上記のシナリオに即した操作の手順を以下に示します。
- テーブル（sample_tab）を作成する。
- データをテーブルに格納する（ここでは「sample_data.csv」をインポートします）。全てのデータがインメモリで動作する事を想定した設定「Column Loadable」である事を確認する。
- システムの稼働から時間が経過し、データの増加が見込まれる事と、一定期間よりも前のデータの利用頻度が下がる事を想定し、NSE設定を利用する事を決定する。
- 登録された日付のデータを持つカラムの値をキーに、テーブルにパーティションを設定し、古いデータを格納するパーティションを「Page Loadable」に変更する。作成されたパーティションの確認と、それぞれのパーティション「Column Loadable」と「Page Loadable」にマーク付けされていることを確認する。
１：テーブル「sample_tab」の作成と、LOAD UNITの確認
それではまずDatabase Explorerを使ってテーブルを作成します。Database Explolrerの左上ペインで、登録されたデータベース＞Catalog＞tableを選択します（下図の左側矢印）。さらに右側の矢印のボタンをクリックして、スキーマ名（通常ログインと同一）を選択しておくと、これから作成されるテーブルを探しやすくなります。この後、右側のSQLコンソールに以下のSQL文を張り付けてテーブルを作成してください。
CREATE TABLE SAMPLE_TAB(
RCD_NUM INT,
ORDER_CODE CHAR(12),
ORDER_DATE DATE,
OTHER_COST NUMERIC(10,0),
TOTAL_AMOUNT NUMERIC(10,0),
ITEM_COST NUMERIC(10,0),
TAX NUMERIC(10,0),
PAY_METHOD VARCHAR(25),
PROCESS_DIV NVARCHAR(10),
FLAG NVARCHAR(6),
CUSTNAME NVARCHAR(20),
MAIL_ADD VARCHAR(100),
PREFECTURES NVARCHAR(10),
ADDRESS1 NVARCHAR(20),
ADDRESS2 NVARCHAR(20),
ADDRESS3 NVARCHAR(20),
TEL VARCHAR(15),
TE2 VARCHAR(15),
GENDER CHAR(1)
)
SQLコンソールの左上にある緑色の「RUN」ボタンを押して実行します。左下のペインに「SAMPLE_TAB」が表示されることを確認してください。
.
２：テーブル「sample_tab」にCSVデータ「NSE_sample.csv」をインポート
続いて、サンプルのCSVデータをインポートします。サンプルのデータはこちらから 「NSE_sample.csv 」をダウンロードして任意のフォルダに配置してください。Database Explorerの左下ペインにあるテーブル「SAMPLE_TAB」を右クリックし、コンテキストメニューの中から「Import Data」を選択します。
Import Data ウィザードのステップ１では「local」を指定し、先ほどダウンロードした「NSE_sample.csv 」を指定します。ステップ２では上記の手順で作成したテーブルの名前が指定されていることを確認してください。
.
ステップ３では、CSVデータと、既存のテーブルのカラムをマッピングします。下図の赤枠のプルダウンからカラムに割り当てる列を選択してください。項目は上から順に並んでいます。
.
ステップ４ではエラーハンドリングを選びますがデフォルトのままで結構です。「Review」ボタンをクリックします。
.
Import Summary画面で、これまでの指定を確認し、右上にある「Import into database」をクリックします。進捗画面が表示され、「Saved all successful records」と表示されたらデータのインポートは完了です。
下の図の矢印部分のタブで、最初のSQLコンソールを表示させ、作成したテーブルを対象としたSQLを実行して、データが格納されていることを確認してください（図ではシンプルに、select * from SAMPLE_TAB を実行しました）。
.
ここで作成したテーブルは、HANA Cloudのデフォルトのテーブル、つまりメモリ上に常駐する属性である「Column Loadable」という属性（LOAD UNIT）を持っています。これを確認してみましょう。同じSQLコンソールから、以下のSQLコマンドを実行します。
.
SELECT SCHEMA_NAME,TABLE_NAME, PART_ID, COLUMN_NAME,LOAD_UNIT,LOADED
FROM M_CS_COLUMNS
WHERE TABLE_NAME='SAMPLE_TAB';selectリストにある「LOAD_UNIT」を見ると「COLUMN」が示されており、「Column Loadable」であることが確認できます。
.
なお、FROM 句で指定されている M_CS_COLUMNS というのはモニタリング・ビューと呼ばれるHANAであらかじめ提供されているシステムビューの一つです。ここではモニタリングビューについては詳しくは触れませんので、こちらのマニュアルを参考にモニタリング・ビューについて触れてみて下さい。
.
3.NSEの利用の判断
実際の運用ではこの過程でデータが増加し、メモリ容量の最適に維持する事を管理する必要が出てきます。パフォーマンスを維持するためにはメモリの増加も検討し、一方でアクセス頻度が低下したデータがあると判断できればNSEの設定を決定してください。
.
４．NSEの設定
.それではNSEの機能を利用してみましょう。
.
今回のサンプルでは、「ORDER＿DATE」カラムの日付が一定の期日より古いデータを「Page Loadable」とすることとします。今回のサンプルデータの「ORDER_DATE」には、2015年5月と6月のデータが含まれていますので、’2015/5/1’から’2015/5/31’までのデータを「Page Loadable」それ以外のデータを「Column Loadable」と設定します。NSEの機能を有効にするためにはALTER TABLE文を使い、パーティションを設定し、そのパーティションにLOAD UNITを指定する、という設定を行うだけです。以下のDDL文を実行してください。
ALTER TABLE SAMPLE_TAB PARTITION BY RANGE (ORDER_DATE)(
PARTITION '2015/5/1' <= VALUES < '2015/6/1' PAGE LOADABLE,
PARTITION OTHERS COLUMN LOADABLE);では、実際にテーブル「SAMPLE_TAB」のLOAD UNITがどのようになっているか、先ほどと同じSQL文で確認してみて下さい。
SELECT SCHEMA_NAME,TABLE_NAME, PART_ID, COLUMN_NAME,LOAD_UNIT,LOADED
FROM M_CS_COLUMNS
WHERE TABLE_NAME='SAMPLE_TAB';カラムのリストに合わせて パーティションID(PART_ID)と、LOAD UNITを確認してください。同じカラム名がパーティションIDが１と２に分かれてリストに登場し、それぞれがPAGE (Loadable）とCOLUMN (Lodable）のLOAD UNITを持っていることが確認できます。
これでColumn Loadableとマーク付けられたパーティションはメモリに常駐し、Page Loadableとマーク付けられたパーティションはNSEの機能が有効になり、Buffer Cacheを共有して使う事でメモリの占有領域を削減する事が可能になりました。
.
ご注意：今回のシナリオをテストするために用意したサンプルデータは、125KByte（858件）と少ないため、「Page Loadable」とマーク付けられたパーティションに比べてBuffer Cacheのサイズが大きいため、メモリに常駐することになります。データが増えてPage Loadableのパーティションに含まれるデータがBuffer Cacheのサイズよりも大きくなった場合にメモリからキャッシュアウトする点にご留意ください。なお、最後にデータが実際にメモリに常駐しているかどうかを確認するのは、上記のLOAD UNITを確認したモニタリングテーブルM_CS_COLUMNSを参照したSQLの最後の「LOADED」のカラムの値で判断することができます。
Very helpful. Thanks