カラム型データベースの特徴

　カラム型データベースは、列単位でディスクへのデータ格納が行われるため、全てのレコードの特定のカラムを読み出す場合、隣接したディスク領域にアクセスすることで高速処理を可能にしている。

　また、カラム型データベースでは、1つの列に含まれるデータは連続した同一データの重複を排除した形で格納されている。例えば、1行目から50行目までが「A」、59行目から80行目までが「B」、81行目から100行目までが「C」というデータが存在する列を想定してみよう。標準的なデータベースでは100フィールド分（例えば100ワード）の領域が必要だが、カラム型データベースでは、「A」「50（回連続）」「B」「30（回連続）」「C」「20（回連続）」という形で格納されるので、必要な領域は6フィールド分（例えば6ワード）で済む。このため読み出しの際に必要なディスクI/Oが削減され、結果として処理が高速化される。

　さらにデータ圧縮の観点でいえば、列単位で格納されたデータは、文字列なら文字列、整数なら整数といった具合に同一の属性を持つため、標準的な圧縮アルゴリズムを適用した場合の効果が大きくなる。

　もちろん、カラム型データベースが一般的なRDBMSより全ての局面で有利というわけではない。一般の業務アプリケーションでは、行単位の書き込み、読み込みの方が頻繁に発生するため、カラム型データベースはこのようなアプリケーションでは不利となる。DWHにおいても、特定の行に対する訂正のような処理が頻繁に発生するような場合は、注意が必要となる。

カラム型データベースのスイートスポット

　本連載の第1回「読めば分かる！　ビッグデータのためのデータウェアハウス（DWH）とは？」で、DWHのデータ構造としてスタースキーマと大福帳スキーマについて説明した。カラム型データベースは、もともと列単位でのデータ格納と圧縮効率の良さを特徴とするため、必ずしもスタースキーマに見られる正規化、集約を必要としない。そういった意味で、カラム型データベースは大福帳スキーマに適しているといえる。さらに、同じ大福帳スキーマであっても、カラム型データベースがより有利となる局面が2つある。

　1つ目は、データのカーディナリティが低い場合である。カーディナリティはもともと集合理論の用語で「濃度」とも呼ばれる。データベース分野では、特定のカラムに含まれるデータの種類、もしくはレコードの数に対するデータの種類の比率を表す。いずれの場合でも、データの種類が少ない（比率が低い）ことを「カーディナリティが低い」という。例えば、「性別」というカラムに含まれるデータの種類は、「男性」「女性」の2種類しかないため、カーディナリティの低いデータの代表例といえる。連続した同一データの重複を排除した形で格納するカラム型データベースにおいては、カーディナリティが低い方が、同じ値が連続して現れる可能性がより高くなり、有利といえる。

　もう1つは、ファクトレスファクトテーブルとなる場合である。スタースキーマにおけるファクトテーブルが数値カラムを持たない場合、そのファクトテーブルをファクトレスファクトテーブルと呼ぶ。

ファクトレスファクトテーブルの例

　スタースキーマの場合、このような数値項目がないファクトテーブルには、疑似的な数値カラム（図では回線数）を作成し、値を常に1とする。

　ファクトレスファクトテーブルは、スタースキーマにおける概念であるが、大福帳スキーマにおいても同様のケースは発生する。このような場合、データの集計処理とは数値カラムの値を足すのではなく、検索条件に合うデータ（レコード）の数をカウントする処理を意味する。当然、このような処理を行う場合、特定のカラムに対して全件（全レコード）の読み込みが頻繁に行われので、カラム型データベースが有利となる。

ビッグデータとカラム型データベース

　カラム型データベースとして最初に登場したのはSybaseIQだと思われるが、その後、数々のカラム型データベースが登場し現在に至っている。特徴的なことは、2010年から2011年にかけて大手ベンダーに買収された製品が多いことである。

　また、ここにきて一般的なRDBMSにカラム型データベース的な機能を付加する動きも出始めている。「Oracle Exadata」のHybrid Columnar Compressionや「Microsoft SQL Server 2012」のカラムストアインデックスなどはその例といえる。このような傾向は、ビッグデータが注目されるようになったことと無関係ではなく、より大量のデータに対する分析アプリケーションのニーズが高まってきたことが背景にあると思われる。

　ただし、NoSQLデータベースが短時間に大量に発生するデータの処理を並列処理によるスケールアウトで解決しようとしてきたのに対し、カラム型データベースはもともとDWHのボトルネックであるディスクI/Oを、列単位でのデータ格納と効率的なデータ圧縮で解決するという全く別のアプローチだといえる。