Kazuho@Cybozu Labs

　大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。

　分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例: 最新５件の日記を表示)、トランザクションがないためアプリケーションプログラムが複雑になったりするという問題を抱えています。

　では、どうすればいいのか？　MySQL や PostgreSQL を使った RDBMS sharding でも、動的なノード追加（と無停止での負荷の再分散）を実現したい。というのが、今回コードを書き始めた動機でした。それが Pacific です。

　技術的には、大して複雑ではありません。Pacific は、パーティショニング情報とロックを管理する中央サーバ（リゾルバと呼んでいます）と、実際のデータを保存する RDBMS のノード群によって構成されます。

　Pacific では、レンジクエリを実行するために、ユニークキーを利用したレンジパーティショニングを行います。レンジパーティショニングは、ハッシュベースのパーティショニングよりもデータの局所性が向上するので、パフォーマンスや障害の局所性が高まるという効果も期待できます。

　また、トランザクションを可能にするためには、関連するデータが常に同一のノード上に配置される必要があるため注2、全てのデータがパーティショニング用のキーに関連づけられるようなテーブル設計を強制することになります。このデータモデルは、(Pacific が RDBMS 上の分散ストレージであるという点を除けば) Google App Engine の Data Store注3 と同様です。Pacific では、パーティショニング用のキーを含むテーブルをプライマリテーブル、プライマリテーブルと 1:1 または 1:n のリレーションをもつテーブルをセカンダリテーブルと呼んでいます。

　データの再配置は、単一の (あるいは数個の) ユニークキー単位で、1) そのキーに属する全データに排他的書き込みロックをかけ、2) データを別ノードにコピ