本連載の第2回で、Oracle技術者になじみの深いSCOTTスキーマのEMP表を例にカラムストアのイメージを考えてみました。図１はローストアのイメージを示したものです。ローストアは物理的にも１行がそのままの形で格納されているので、ROWIDにより行を特定し、さらに必要なカラムデータを取得します。
ローストアの場合、「SELECT * FROM TBL 〜」のような「全列ワイルド・カード(アスタリスク)記述」とSELECTの後にカラムを明示的に指定した場合の性能的な違いはあまりありません。
全列ワイルド・カード記述はむしろSQLコードの読み難さの観点からコーディング規約等で避けられるケースが多いように思われます。
SAP HANAの場合も全列ワイルド・カード記述が可能なのですが、SAP社のあるセッションに参加した際「性能上の理由からHANAにおいて全列ワイルド・カード記述はお勧めしません。SELECTの後に必要なカラムを明示的に記述して下さい。」という説明があり、印象深かった記憶があります。
また、そもそもHANAカラムストアにおいてはROWIDに相当する概念はあるのかという疑問も持ちました。
今回は私が一人のOracleエンジニアとして感じた疑問を起点に、HANAカラムストアの謎に迫っていきたいと思います。
HANAカラムストア イメージのおさらい
図２はローストアのイメージのまま各カラムにデータを格納したイメージです。
各カラムの添字は同じ行を示すので、添字が同じデータを横串に連結すればリレーショナルデータベースのタプルを簡単に表現できることがわかります。
ところが、この方法の欠点は重複データを含むため、容量が無駄になるだけでなく例えばJOBカラムの「MANAGER」を「DIRECTOR」に一斉変更したい場合、複数のデータを更新しなければならなくなることです。
一方、図３は重複排除かつソートした状態でデータを格納したイメージです。
図２の欠点を解決していますが、各カラムの添字が異なるのでタプルの表現が困難になります。
SAP HANAではメモリ上に展開された配列構造を応用してカラムストアを実現しているのですが、実際にどのような仕組みになっているのでしょうか。今回はその概要を説明します。
