［次世代DB編］異なる分散KVS間でデータ移行してはいけない

　分散型のキーバリューストア（分散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）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の特徴をしっかりとつかんだ上で、テーブル変換、アプリケーション側の見直しを行う覚悟が必要だ。