＞＞前回
システム担当者に向けたビッグデータの連載である。前回、セマンティック技術を利用して情報の意味を理解するところまで説明した。今回は、それらのデータを格納するデータベース技術を説明する。
リレーショナルデータベースが直面する問題
ビッグデータにおけるデータベース技術は、データ容量の拡張性や性能向上対策が議論されることが多い。しかし、直面する最も大きい問題は、従来のリレーショナルデータベース（以下RDB）が前提とするデータ構造にある。問題をイメージしやすくするために、消費者行動分析のためのデータ構造を例に説明しよう。従来は、POS情報などの購買実績データを中心に分析されてきたが、「なぜ売れたのか・なぜ売れなかったのかの理由を知りたい」という分析ニーズが高まっている。
このような分析を実現するには、ユーザーが購入に至るまでのさまざまな情報を記録する必要がある。店舗であれば、ユーザーが店頭にいた時点での商品の陳列状況、価格設定、店員との会話、天候、気温などが該当する。ECサイトであれば、図1のような情報になるだろう。
これらを見てみると、個々の情報の構造はそれほど複雑ではない。ECサイトに表示する情報の多くがRDBに格納されており、そこから取り出されていることを考えれば当然である。しかし、RDBのデータモデルを構成する上では、大きく3つの点を考慮する必要がある。
（1）データの組み合わせの履歴保存
ここに出ている情報の組み合わせは、時間ごとのスナップショットとして記録する必要がある。RDBで実装する場合には、すべての情報に詳細な変更履歴を持つ必要がある。
（2）多様なデータの組み合わせパターン
キャンペーン表示画面、商品一覧画面、商品決定画面、商品比較画面など、ECサイトの画面種別ごとに保持するデータ構造が異なるため、画面種別ごとにデータモデルを作成する必要がある。また、口コミ情報の分析には、前回取り上げたセマンティック技術を活用することになる。口コミ情報には、商品の機能、色、価格、デザイン、クレームなどさまざまな情報が含まれ、それら情報の種類や組み合わせをあらかじめ予測し、データモデルを作成するのは難しい。
（3）データ構成の柔軟な変更
各画面の内容やその組み合わせはサイト企画者の意図で柔軟に変更される。そのため、頻繁なデータモデルの変更が発生する。
上記の課題をRDBで解決しようとすると、データモデルは過度に複雑化し、頻繁な構成変更が必要になる。しかし、RDBでは構成が一定レベルを超えて複雑になると、性能が極端に劣化するという問題がある。データ要素を追加するたびに性能チューニングを行うことが必要で、データ要素を追加するためにデータベースの再構成が必要となる。
ここで問題となるのは、分析にかけてもいい時間と、データベースの構成変更にかかる時間のギャップだ。例えば、マーケティング担当者は１週間のサイクルで企画を変更するケースは珍しくないが、データベースの構成変更には数カ月を要する場合がある、といった時間のギャップである。
ビッグデータ処理においては、データベースへのデータ格納時間や検索時間よりも、データ構造の変更に対する対応時間の方が重要なのだ。そこで注目したいのが、XMLを基盤とした非構造化データベース（以下、XML型データベース）である。
