この記事をご覧いただきありがとうございます。
今回、テーブルのストレージタイプについて疑問を持ったため、
HANAにおけるデータベースの構造と合わせて調べてみました。
既にご存じの方も多いかもしれませんが、復習の意味も込めてお付き合いくだされば幸いです。
※この記事は暫定記事であり、以下のブログ承認後非公開となります。
https://blogs.sap.com/2019/12/06/how-to-define-row-and-column-store/
この記事のまとめ
- HANAはカラム型データベース
- テーブルのほとんどがカラム型
- ロー型のテーブルの特徴は下記である
- 計算対象となる値がない
- 情報に対してIDが一意である
- 変更しない情報
- 行数が比較的少ない
- 列数が比較的少ない
この記事の目標
カラムストアとローストアを具体的にイメージし、正しく使い分けできるようになる。
私が抱いた疑問
- HANA DBは「インメモリデータベース」かつ「カラム型データベース」という構成をとっている。
- テーブルのストレージタイプはローストアとカラムストアの2種類を選択できる。
保存されている情報を用いて頻繁に計算する場合はカラムストア、
そうでない場合はローストアとするのが基本ですが、
具体的にどう活用されているのか、私は疑問に思いました。
まず、その疑問を解決するための前提知識として、HANAのデータベース構造をそのほかの一般的なデータベースと対比します。その次に、ローストア、カラムストアの違いを説明し、具体的な使用方法を実際のテーブルを上げて解説していきます。
データベースについて
CPUに近い場所にあるメモリ:高速にデータ通信が可能/容量小さい/揮発性
CPUと離れた場所にあるメモリ:アクセス速度は相対的に遅い/容量大きい/不揮発性
➡データを置く位置によってアクセスの速度が異なる(データヒエラルキーがある。)
データベースの構造 オンディスクデータベースとインメモリデータベース
オンディスクデータベース
オンディスクデータベース:HDDなどのディスクストレージにデータを格納するデータベース ディスクに保存されたデータをデータベースエンジンによって取り出し、すぐに使う情報はメモリにキャッシュとして保存する等データヒエラルキーに基づいてチューニングを行う。
メインデータ:ディスクに保存 スナップショット:なし キャッシュ:メモリに保存 |
インメモリデータベース
インメモリデータベース:データを全てメインメモリ上に格納するデータベース データが大量かつ急速に増える→データヒエラルキーのチューニングが追い付かない。 →データヒエラルキーを考える必要がない「インメモリデータベース」が登場
メインデータ:メモリに保存 スナップショット:SSDに更新毎&定期的に保存 キャッシュ:なし |
データの管理方法 RDB(リレーショナルデータベース)
RDB:データを複数の表として管理し、表と表の関係を定義することで、複雑なデータの関連性を扱えるデータベースの管理方式
・RDBのデータモデル
RDBのデータモデルにはローストアとカラムストアがあり、HANAはカラムストアが初期設定となっています。
ローストア(行型ストレージ):1つのレコードを1行のデータとみなして格納する
カラムストア(列型ストレージ):データを列ごとにまとまった形で格納する
※カラムストアはNoSQL(Not only SQLの略)の一種として定義されることもある
以上のような区切りでデータを保存すると、データベース上には下記のような状態でデータが保持される。
ローストア | カラムストア | |
追加・更新・削除処理 | はやい | おそい |
集計処理 | おそい | はやい |
HANAはカラム型データベースであり、データは列方向に圧縮され保持されています。
追加・更新・削除といった処理を速くするためにHANAは「デルタバッファ」というコンセプトを打ち出しています。
参考 デルタバッファ
デルタバッファはL1デルタ、L2デルタ、カラム型データベースであるメインストアの3つで構成される。
L1:データベースに対する追加、更新、削除の情報がローストアで圧縮されずに保存される。
L2:バックグラウンドでローストアであるL1がカラムストアであるL2に変換され、インデックスにより圧縮される。
参考:「Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth」
本題 ローストアとカラムストアの用途とは
以上のように、HANAにおいて情報は基本的にカラムストアで保存されています。
しかし、テーブルを定義する際には、ローストアとカラムストアの2種類の方法のどちらかを選択することができます。
両ストアの特徴を踏まえると、扱う情報としては下記のようなものが向いています。
・扱う情報の性質
ローストアに適したテーブルの性質 | カラムストアに適したテーブルの性質 |
• 主に固有な値が含まれる→低圧縮率
• 最大/すべての列が関連している • インデックスのないカラムに対する検索、あるいは、集計の対象ではないテーブル • 完全にバッファ • レコード数が少ない |
• 多数の行に対する列操作の対象
• 多数の列があり、使用不使用が多いテーブル • テーブルが検索操作に集約している
|
参考:OpenSAP
ローストアとカラムストアの実際の使用例
調査の方法:SE16N(一般テーブル照会)からDD09Lテーブルの技術設定を参照し、Storage Typeを絞って検索する
結果
SAP標準テーブル205個のうち、203個がカラムストアで定義されており、1つがローストア、1つが未定義となっていました。
ローストアについて
ちなみに、SAP標準テーブルのうち、ローストアで定義されていたのは、TBTCO(ジョブステータス概要テーブル)だけでした。このテーブルには下記のようにジョブが登録された日付や実行された日付等のログが保存されていました。
BKPF:会計伝票ヘッダデータ:集計対象ではないが、GUIDは存在せず、レコード数が多い
VBAP:販売伝票: 明細データ:集計対象となっている。GUIDは存在せず、レコード数が多い、
SAP標準テーブルの以外のテーブルも参照した結果、ローテーブルが使われているテーブルとして下記のような情報がありました。
- アクセスのための情報
- アクセス履歴・送受信ログ
- 辞書・定義
- 一意の連番(GUID)のみ
- GUIDに紐づく情報
- 順序
- バリアント
- マッピング )/SAPAPO/ORDMAP(Order Mapping Table)
- 説明文・テキスト)DDTYPET
- 構成情報・設定情報
これらのテーブルの特徴をまとめると、下記が挙げられると思います。
- 計算対象となる値がない
- 情報に対してIDが一意である
- 変更しない情報
- 行数が比較的少ない
- 列数が比較的少ない
先に挙げた扱う情報の性質にも当てはまっていましたが、実際にテーブルを見ると、より具体的にイメージできました。
カラムストアについて
SAP標準テーブルからいくつかのテーブルを具体例として挙げます。
バリアント情報(VARI):GUIDは存在せず、レコード数が多い(4000)
BKPF:会計伝票ヘッダデータ:集計対象ではないが、GUIDは存在せず、レコード数が多い
VBAP:販売伝票: 明細データ:集計対象となっている。GUIDは存在せず、レコード数が多い、
まとめ
テーブルを作成するときは、基本的にカラムストアを使う。
ローストアに設定するべきテーブルの性質を理解して、適切に使うことでアクセス速度が上がる。
ローストアに適したテーブルの性質 | カラムストアに適したテーブルの性質 |
• 主に固有な値が含まれる
• 最大/すべての列が関連している • インデックスのないカラムに対する検索、あるいは、集計の対象ではないテーブル • 完全にバッファ • レコード数が少ない •あまり変更されない情報 |
• 多数の行に対する列操作の対象になっている
• 多数の列があり、使用不使用が多い • テーブルが検索操作に集約している •レコード数が多い |
ここまでお読みくださりありがとうございます。