リスト・プロパティを含むエンティティの永続化

前回は、キー・バリュー・ストア、データ構造の柔軟性（プロパティ項目の可変性）と、それを利用したLow-Level APIを用いたアプリケーションの例を紹介しました。

今回は、キー・バリュー・ストアのもう1つの柔軟性といえるリスト・プロパティについて解説します。App Engineのデータ・ストアでは、Bigtable^*1と言われる分散キー・バリュー・ストアが複数組み合わせて使用されていますが、今回は、最初にこのBigtableについて簡単に触れます。

• [*1] BigTableの詳細な解説は『Bigtable: A Distributed Storage System for Structured Data』（http://labs.google.com/papers/bigtable.html）に掲載されており、ここでの説明も、この記事を参照した内容になっています。

1. Bigtableとデータ構造

Googleは、検索機能から成長していった会社です。Google検索では、クローラ^*2が集めた、想像を絶するほどの大量データを保存する必要があります。この大量のデータを安全に保存するための分散ファイル・システムとして、Google File System （GFS)が考案されました。しかし、GFSは、その特殊な用途から汎用的でないデータ構造になっており、App Engineなどで使用されるデータ・ストアとしては、あまりふさわしいものではありませんでした。

• [*2] サーチ・エンジンの検索データベースを作成するために、Web上の文書や画像などを周期的に取得して、自動的にデータベース化するプログラム。ボット（Bot）、スパイダーまたはロボットなどとも呼ばれます。

そこで、Googleは、提供するさまざまなアプリケーションで使用できるように、汎用化目的を主としたデザインで、新たなファイル・システムを作成しました。そのファイル・システムが、Bigtableです。Bigtableは、Google Earth、Google Financeなど60種類を超えるGoogleアプリケーションで使用されています。このBigtableが、App Engineのデータ・ストア用に、ほぼそのまま使用されています。

図1は、『Bigtable: A Distributed Storage System for Structured Data』に記載されているデータ構造のサンプルです。Googleは、上記のように、Googleのオンライン検索機能（Google Search）からスタートした会社なので、Bigtableのデータ構造にも、検索用に使用されるテーブル構造が色濃く反映されています。

[行キー、カラムキー、タイムスタンプ]

図1においては、"com.cnn.www"が行名です。RDBにおける主キーに相当し、行キーと呼ばれます。サンプルでは、CNN（アメリカのニュースサイト）のURLを反転したものになっています。次に、"contents"は、列名に相当します。図では、タイム・スタンプ「t3、t5、t6」を持つデータがあります。したがって、列データを検索するためには、行キーのほかに列名が必要となります。これを列キーと呼びます。結局、contentsデータは、行キー、列キー、タイム・スタンプにより、一意にデータ（文字列）を確定することができます（図2）。

[カラム・ファミリ]

次の"anchor"列には、このページを参照しているアンカー文字列が格納されています。例えば、この例のCNNニュースは、「Sports Illustrated」 と 「the MY-look home pages」のページから参照されており、それぞれのURLをanchor列ファミリのデータとして持っています。このように、同じ列に複数のデータを配置することもでき、列ファミリ（カラム・ファミリ）と呼ばれます。

[App Engineでのテーブル構造]

Bigtableは、App Engineで使用されています。Googleの技術解説に記載されているBigtableを全くそのままのかたちで使用しているかどうかは断言できませんが、ほぼ同様のファイル構造になっています。

（1）キー（図1のcom.cnn.www）

このサンプルで使っているプログラムは、こちらで実行できます。htmlファイルを除く部分を反転すると、com.appspot.swsgaejpm7.latest.8になります。App Engineの行キーは階層構造になっており、com.appspot.swsgaejpgm7までで、アクセスするデータ・ストアは確定し、行キーのサフィックスになっていると考えられます。従って、それ以下のlatest.8の部分が変わっても、kind名が同じであれば、同一データ・ストアが使用されます。これに対して、com.appspot.swsgaejpgm6としてjpgm7をjpgm6に変えてアクセスすれば、kind名が同じでも異なるデータ・ストアになります。つまり、Google技術文書のキー構造と同一構造になっていると考えられます。

（2）バージョン（図1のcontents）

Bigtableでは、タイム・スタンプにより、任意数のバージョンを管理できるようになっています。通常は、3世代のバージョンが保持されています。これに対してApp Engineでは、latestだけがアクセス可能であり、タイム・スタンプによるバージョンの世代管理はできません。しかし、タイム・スタンプとは関係なく、1つのアプリケーションIDで9種類のバージョンを保持することができます。

（3）カラム・ファミリ（図1のanchor:XXX）

Google技術文書のBigtableでは、カラム・ファミリにより、同一カラムに複数のプロパティを設定することができるようになっています。このカラム・ファミリが今回説明するリスト・プロパティと同一データ構造とは言えないかも知れませんが、考え方としては大変よく似ています。つまり、カラム・ファミリもリスト・プロパティも、同一プロパティ名で複数のデータ項目を保持することができるという点では共通しています。

2. リスト・プロパティ

それでは、ここから今回のテーマとなるリスト・プロパティを、サンプルを使用しながら具体的に解説します。

[前回のエンティティ・サンプル]

前回は、プロパティ項目の可変性について説明しました。プロパティ項目の可変性では、同一テーブル（kind）に属するエンティティ間でプロパティの数や属性を任意に変えることができました。例えば、前回のサンプルでは、コンピュータ製品におけるスペック項目を任意に変更できることを確認しました。

[今回のエンティティ・サンプル]

今回は、前回のサンプルにリスト・プロパティを追加します。リスト・プロパティは、図5のように、エンティティのプロパティ項目をリスト形式にしてデータを格納できる機能です。

App EngineのBigtableでは、インデックス以外の任意のプロパティ項目を、リスト形式のプロパティとして定義することができます。同じプロパティのリスト項目は同じデータ型にする必要がありますが、それぞれのプロパティごとに異なるデータ型にすることができます。

前回説明したように、2次元で表現できるデータは、ブロトコル・バッファによってシリアライズされてキー・バリュー・ストアに格納されます。これに加えて、リスト形式のプロパティ設定も、前回のプロパティ項目の可変性と同様に、スキーマレスであるキー・バリュー・ストアの柔軟なデータ構造によって可能になっています。