Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

HANAはどうやって行を識別しているのか

2017/12/22 06:00

今回は前回予告したように、SAP HANAのカラムストアでどのように行(ロー:Row)が識別されるのかということを解説します。

 本連載の第2回で、Oracle技術者になじみの深いSCOTTスキーマのEMP表を例にカラムストアのイメージを考えてみました。図1はローストアのイメージを示したものです。ローストアは物理的にも1行がそのままの形で格納されているので、ROWIDにより行を特定し、さらに必要なカラムデータを取得します。
 ローストアの場合、「SELECT * FROM TBL 〜」のような「全列ワイルド・カード(アスタリスク)記述」とSELECTの後にカラムを明示的に指定した場合の性能的な違いはあまりありません。
 全列ワイルド・カード記述はむしろSQLコードの読み難さの観点からコーディング規約等で避けられるケースが多いように思われます。
 SAP HANAの場合も全列ワイルド・カード記述が可能なのですが、SAP社のあるセッションに参加した際「性能上の理由からHANAにおいて全列ワイルド・カード記述はお勧めしません。SELECTの後に必要なカラムを明示的に記述して下さい。」という説明があり、印象深かった記憶があります。
 また、そもそもHANAカラムストアにおいてはROWIDに相当する概念はあるのかという疑問も持ちました。
 今回は私が一人のOracleエンジニアとして感じた疑問を起点に、HANAカラムストアの謎に迫っていきたいと思います。

HANAカラムストア イメージのおさらい

 図2はローストアのイメージのまま各カラムにデータを格納したイメージです。
 各カラムの添字は同じ行を示すので、添字が同じデータを横串に連結すればリレーショナルデータベースのタプルを簡単に表現できることがわかります。
 ところが、この方法の欠点は重複データを含むため、容量が無駄になるだけでなく例えばJOBカラムの「MANAGER」を「DIRECTOR」に一斉変更したい場合、複数のデータを更新しなければならなくなることです。

 一方、図3は重複排除かつソートした状態でデータを格納したイメージです。
 図2の欠点を解決していますが、各カラムの添字が異なるのでタプルの表現が困難になります。
 SAP HANAではメモリ上に展開された配列構造を応用してカラムストアを実現しているのですが、実際にどのような仕組みになっているのでしょうか。今回はその概要を説明します。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 三原健一(ミハラケンイチ)

     ベンチュリーコンサルティング株式会社 技術顧問  現在、大手SIerの性能問題対応チームに従事。主にOracleデータベースの性能問題解決や負荷テストの計画・実施・分析・評価等を担当。前職のインサイトテクノロジーではメルマガやブログの執筆に関わる。  ・ブログ「サイクル&オラクル」

バックナンバー

連載:Oracle技術者から見た、SAP HANA
All contents copyright © 2007-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5