Re 分散ストレージの収束する方向 (のうち Pacific 関連の話)

id:frsyuki さん & id:hirose31 さん、クラウドコン優勝おめでとうございます！ (参考: Interop Tokyo 2009のクラウドコンでグランプリいただきました！！ - （ひ）メモ)

Pacific はリゾルバがボトルネックになるが、Consistent Hashing + double-hash-space で分散できるのではないか。データの再配置を悲観的ロックではなく楽観的ロックでやるあたりが問題になりそうか…そこはまだ考えてない。

※2009-06-14追記：データの再分配が起こらなければ問題ないので、最初は小さく始めて動的に増やす（動的な運用）を考えなければ、台数固定で分割してやってもリゾルバは分散できそう。

分散ストレージの収束する方向 - sdyuki-devel

リゾルバ自体をある程度増やすのは簡単だったりします。リーダやライターは、リゾルバクラスタのうち１台にアクセスし、リロケータだけが、全リゾルバにロックを要求する、というモデルにすればいい。ただ、Pacific の場合、各クライアントと RDBMS ノードが直接通信するモデルなので、リゾルバを分散させる以前に RDBMS ノードの同時接続数制限がやばくなってくる（なのでプロキシが必要になってくる）でしょう。だからそっちが先かも。

再配置を楽観的ロックにするアイデアはある*1ので、いずれやるかもしれません。

トランザクションについては、Google App Engine の Data Store や Pacific の局所制に対する仮定は誤りだという話もあったりするようなので、パーティショニングのための情報はあくまでも最適化のためのパラメータだと考えて、単一ノードへのアトミックなトランザクション、複数ノードへの書き込みの場合は 2-phase commit、のように、自動的に切り替わる API をユーザーに提供できればいいんじゃないかな、と思うようになりつつあります (が、RDBMS sharding だとトランザクションから 2-phase commit へのアップグレードが難しいような気が...)。

*1:以前お話したように、書き込み権限を要求するクライアントが、必要なデータを移行後のノードにコピーしてしまえばいい