PR

 分散型のキーバリューストア(分散KVS)には、オープンソースソフトや商用のもの、サービスとして提供されるものなど、さまざまな種類がある。これらをすべて同じだと思ってはいけない。その構造や特徴はバラバラであり、ある分散KVSのデータは別の分散KVSに移行するのは困難だ。

 既存のRDBMSの資産を分散KVSに移行するのが容易ではないことはよく知られている。同様に分散KVS間の移行もかなり難しい。安易に移行できると考えていると、苦労することになる。

大きく異なるテーブル構造

 現在、分散KVSと呼ばれるデータベースには、以下のようなものがある。

・Amazon SimpleDB(Amazon)
・Apache Cassandra(Apache)
・BigTable(Google)
・Flare(GREE)
・kumofs(えとらぼ)
・memcached(Danga Interactive)
・ROMA(楽天)
・Windows Azure テーブル・ストレージ(Microsoft)

*カッコ内は提供元

 ここではデータの永続化が可能なものだけをピックアップしたが、永続化を目的としないものも含めると、その数はもっと多くなる。

 このうち代表的な分散KVSは、memcached互換の分散KVS、Google BigTable、Windows Azureテーブル・ストレージの三つである。以下では、それぞれの特徴と、移行時のポイントについて見てみる(図1)。異なる分散KVS間の移行の難しさを理解できるはずだ。

図1●分散KVSのデータ構造
図1●分散KVSのデータ構造

(1)memcached互換の分散KVSの場合
 mixiやはてななどで使われているmemcached互換の分散KVSは、単純な構造になっているのが最大の特徴だ。キーからバリュー(値)を取得するだけのアクセスに対応したデータ構造であり、1次元のマップとなる。

 そのためバリューに対する柔軟な検索ができない。例えばキーに対して範囲選択をしたり、部分一致による検索をしたりすることはできない。RDBMSで一般的な結合操作も行えない。

(2)Google BigTableの場合
 BigTableは、その構造が多次元であること(行、列、タイムスタンプの3次元)と、行キーでソートされていることがポイントである。これにより、memcached互換の分散KVSよりも高機能なデータアクセスが可能である。

 BigTableのデータモデルは、多次元のソート済みマップという構造を持つ。「Row Key(行キー)」「Column Key(列キー)」「Timestamp(タイムスタンプ)」という三つのキーに索引(インデックス)を付けられる。Column Keyは、「column-family」と「qualifier」の組み合わせで作り、同一のcolumn-familyは同一の「SSTable(ノードに相当)」に配置される。

(3)Windows Azureテーブル・ストレージの場合
 Windows Azureテーブル・ストレージは、次のような特徴を持つ。

・255個以内のプロパティーから成るエンティティの集合
・Partition KeyとRow Keyが必須プロパティーであり、それ以外のプロパティーは任意
・Partition Keyは物理ノードの配置先決定に影響する(同一Partition Keyであれば同一ノードに配置される)

 ここでのポイントは、Partition Keyが物理ノードの配置先決定に影響することである。

1次元から3次元のテーブル変換に苦戦

 さて、三つの分散KVS間でデータベースを移行するとどうなるか。

 例えばmemcached互換の分散KVSからBigTableに移行する場合、キーの見直しが必要となる。つまり、1次元から3次元へ、キーの構造を変更しなければならない。column-familyを検討する必要もある。column-familyの設定を間違えると、性能に影響する恐れがある。

 memcached互換の分散KVSからWindows Azureテーブル・ストレージへの移行も、同様にキーの見直しが必要だ。Partition Keyによって物理的な配置先が決定されるので、その設定には十分に気を配らなければならない。

 BigTableからWindows Azureテーブル・ストレージへの移行はどうか。この場合、Column KeyとPartition Keyの変換が必要だ。このとき読み替えを間違えると、やはり性能の問題にぶつかる。性能低下を回避するには、テーブル設計を全面的に見直すことも必要だ。

 もっとも、移行時には、テーブル設計の見直しだけでなく、アプリケーション側の見直しも出てくる。RDBMSに比べて構造がシンプルな分散KVSでは、データの加工や操作をアプリケーション側で行うためだ。この変更作業も移行時にわずらわしさを感じるだろう。

 三つの分散KVS以外のものを利用する場合も、簡単に移行することはできない。データ移行する際には、それぞれの分散KVSの特徴をしっかりとつかんだ上で、テーブル変換、アプリケーション側の見直しを行う覚悟が必要だ。

大川 博(おおかわ ひろし)
日本ヒューレット・パッカード エンタープライズサービス事業統括アプリケーションサービス統括本部 アプリケーションデベロップメント本部 運輸アプリケーションデベロップメント部
2001年、コンパック(現日本ヒューレット・パッカード)に入社。通信・製造・金融などさまざまな業種のユーザー企業のJ2EEやWebのシステムを担当した後、2004年からは運輸のユーザー企業を担当する。以降、主に.NETでのシステムに携わっている。社内ではマイクロソフト関連技術についての技術展開にも積極的に実施している。