RDBの機能をNoSQLで実現する（2）：RDB開発者におくるNoSQLの常識（4）（1/3 ページ）

テーブル結合やデータ集計に挑戦

　前回は「リレーショナルデータベース管理システム（RDBMS）が提供しているさまざまな読み取り処理の機能を、NoSQLデータベースで実現するには？」をテーマに、KVS型のNoSQLデータベースで検索処理や並べ替えを実現する方法を紹介しました。

　分散環境で性能を発揮できるようシンプルさを追求したNoSQLデータベースには、RDBMSのように便利なデータ加工処理機能はありません。RDBMSが相手なら、SQL文を書くだけで簡単に使えた検索処理や並べ替えも、「データベースにお任せ」というわけにはいかず、アプリケーション側での工夫が必要になります。今回も引き続き、RDBMSのデータ読み取り処理をNoSQLで実現する方法について説明します。特に、SQLによるデータ読み取りでよく使う「テーブル結合（JOIN）」や「データ集計」の例を挙げて解説します。

オンライン書店のレビューページを作ってみる

　本連載の第1回でも少し説明しましたが、NoSQLデータベースについて皆さんが最も耳にする意見は「NoSQLデータベースはテーブルの結合ができない」というものではないでしょうか。今回はまず、RDBMSを使ったデータ取得の基本ともいえる「複数のテーブルを結合してデータを取得する」というシナリオを、NoSQLデータベースでどのように実現するか、ということから考えていきます。

　具体的な例として「オンライン書店の商品レビューページを作る」というシナリオを考えてみましょう。インターネットで雑誌や書籍を販売するオンライン書店では、書籍そのものの情報のほか、評判を参考にする顧客のためのカスタマーレビューを掲載しているサイトをよく見かけますね。この機能を実現するためのデータ構造を考えてみます。

　カスタマーレビューのページに表示する項目としては、まずレビューのタイトル、本文、点数、投稿日を格納するデータ構造が必要になりそうです。次に、レビューの対象となる本のタイトルや著者名、出版社、価格、表紙の画像データなど、書籍のデータも必要です。この他、レビューを投稿する会員（レビュアー）のデータも必要でしょう。

　これらのデータを格納するためのテーブル構造を、ひとまず「RDB設計の考え方」でまとめていきます。「レビュー」「書籍」「会員」の各データ構造を図で表すと、図1のような形になるはずです。「レビュー」テーブルには「書籍」テーブルと「会員」テーブルのID（書籍IDと会員ID）を外部キーとして持たせます。

図1　レビュー機能付きのオンライン書店に必要なデータベースを、RDB設計の考え方で設計したもの

　図1の3つのテーブルから、画面表示に必要な項目を考えます。画面に表示する項目は「書名」「レビュアー名」「投稿日」「レビューのタイトル」「レビュー本文」「レビューの点数」の6項目あれば用が足りそうですね。RDBMSの場合はSQLを使って図の3つのテーブルを結合し、図2のような結果セットを生成します。

図2　図1のテーブルにあるデータから、画面表示に必要なものを選び出したもの

　RDBMSの場合は、データ構造に対応する結果セットを、問い合わせが来たタイミングで動的に生成するので、事前にこの形でテーブルを作っておく必要はありませんでした。しかしNoSQLデータベースにはテーブル結合機能はありません。

　今回はこれをKVS型のデータベースに格納するために、物理的なデータ構造を作成します。KVSのテーブルにデータを追加するには、上記のデータ項目以外に、データを引き出すためのキー情報を追加する必要があります。ほとんどのKVSではRDBMSにあった「複合キー」のような機能はないので、既存の列を組み合わせて主キーとすることはできません。必ず、単一の値で一意となるようなキー情報が必要です。

　キー情報として使う値は、論理的には一意の値でありさえすれば何でもよいのですが、単なるランダムな文字列をキーにしてしまうと、KVSの実装によっては関連の深い（まとめて取得したい）データの保存場所も拡散してしまいます。処理性能を考えると、できるだけ用途に合わせたキー値の生成方法を考えるべきでしょう。

　今回は「書籍紹介ページのレビュー一覧」という利用シナリオを想定しているので、ある1つの書籍のレビューを、最新のものから順に表示させていくと考え、[書籍ID＋投稿日（降順）]を文字列化した値をキー情報として使用することにします。