NoSQLデータベース（KVS）の起源

　NoSQLデータベースがリレーショナル型の構造を持たないとすると、一体どのような構造を持っているのだろうか。現時点でNoSQLデータベースに分類されている全てのデータベースが含まれるわけではないが、その主流は「KVS（キーバリューストア）」と呼ばれる。

　KVSの起源は、2003年に米Danga Interactiveが開発したオープンソースソフトウェア（OSS）の「memcached」にさかのぼる。当時、多くのWebアプリケーションではデータの格納先としてRDB（リレーショナル型データベース）が利用されていた。しかし、ブログのようなアクセス数が極めて多いWebアプリケーションでは、その性能の限界が問題となっていた。memcachedはRDBの検索結果をキャッシュとして保存することでRDBの負荷を低減し、多数のアクセスを処理できるようにする。つまり、RDBを補完する目的で開発された。

　memcachedは保存したいデータ（Value）にラベル（Key）を付けて、ValueとKeyのペアで保存する。保存したデータは、Keyを指定して対応するValueを取り出すという方法を取る。また、memcachedはKeyの値に応じてデータを格納するサーバを変えることで、複数のサーバにデータを分散配置できる。その結果、短時間で大量に増加するようなデータであっても、スケールアウトして対応できる。このmemcachedの成功の後、KVSはRDBを補完するという当初の目的を超えて、パブリッククラウドの基盤データベース技術としてRDBを置き換える存在になっていった。

NoSQLデータベース（KVS）の特徴

　RDBと比較した場合のKVSの特徴は、DWHの観点で大きく2つに集約される。一方は短所であり、もう一方は長所となる。

　1つ目の特徴は「SQLが使えない」という点で、DWHの観点では大きな制約となる。データの検索には、必ずRow Key（RDBの主キーに相当）の指定が必要となる。SQLのように、任意のカラムに対する条件指定での検索や複数のテーブルを結合する機能はない。なお、Row Keyの範囲を指定して、対応するデータを順次取り出すことは可能である。

　また、保存するデータ（Row）のデータ構造に基づいて、Row Keyで指定されたRow内部での検索条件を付加することも可能だ。このRowのデータ構造と追加の検索条件の違いが、さまざまなKVSを特徴付ける要素となっている。

　2つ目の特徴は「分散処理に優れる」という点で、DWHの観点では大きな優位性となる。KVSは複数サーバにデータを分散保存するために、大量のデータをスケールアウト型で扱える。このスケーラビリティの規模や耐障害性などが、さまざまなKVSを特徴付ける大きな要素となっている。

　ここでは、代表的な2つのNoSQLデータベース（KVS）について、そのデータ構造を紹介しておく。

HBaseのデータ構造

　「HBase」は、Googleの分散データベース基盤「BigTable」を基に、OSSプロジェクトとして開発されたものである。HBaseでは、KeyとValueの対をカラムと呼び、Keyの方を特にラベルと呼んでいる。カラムが集まったものがカラムファミリーと呼ばれ、さらに複数のカラムファミリーの集合がRowと呼ばれる。全てのRowにはRow Keyが付与されており、同じ構造を持つRowの集合がテーブルと呼ばれる。大ざっぱにいえば、HBaseのテーブルはRDBのテーブルに相当し、Row KeyはRDBの主キーに相当する。

HBaseのデータ構造の例

　上図は簡単な社員一覧表を基にHBaseのデータ構造を表している。例えば、社員「山田太郎」のメールアドレスを知りたい場合は、以下の順で検索を行い、

1. テーブル「社員」を指定
2. Row Key「002」を指定
3. カラムファミリー「連絡先」を指定
4. ラベル「メールID」を指定

結果、「t-yamada」という値を得ることになる。

Cassandraのデータ構造

　「Cassandra」は、米Facebookが自社のサービスの分散データベース基盤をOSSとして公開したものである。以下にCassandraのデータ構造の例を示す。

Cassandraのデータ構造の例

　CassandraとHBaseのデータ構造の大きな違いは、スーパーカラムの存在である。スーパーカラムは、複数のカラムの集合に対してキー（スーパーカラムのラベル）を付与したもので、カラムファミリーの中に定義することができる。そのため、HBaseでテーブルに相当するデータを1つのRowとして扱い、複数のRowの集合はキー・スペースと呼ばれる。

　このようにKVSでは、データの検索については制約条件が多い。例えば、KVSに販売データを格納して、製品を中心とした検索と顧客を中心とした検索の2つを実行するためには、原則として別のテーブルやカラムファミリーを作成する必要がある。このため、分析的なアプリケーションがKVSを直接使用することは、現時点ではまだ難しいといえる。

　しかし、ビッグデータの特性である莫大な明細データの格納という意味では、KVS（NoSQLデータベース）が有力な選択肢であることは間違いない。従って、NoSQLデータベースに明細データを保持した後に、RDBで分析用のデータベースを作成する、といった併用が現時点では現実的なアプローチといえる。