2009-05-20 - 未来のいつか/hyoshiokの日記
http://d.hatena.ne.jp/hyoshiok/20090520#p1
ところが、昨今のWebアプリケーションの世界では、BASEというACIDではない原理原則が支配している。ACIDの代替としてのBASEである。BASEとは
- Basically Available
- Soft State
- Eventually Consistent
まあ、大体動いていて、状態を持ち、厳密な一貫性ではなくゆるい一貫性を持つ*4。ま、一貫性はいつの日か達成できればいいんじゃね。くらいののりである。例えば、銀行のトランザクションはACIDの世界が絶対必要だ、そりゃそうだ、自分のお金が大体あっていればいいなんて話は受け入れられない。だけど、日記を書いて、それのトラックバックのアップデートが若干遅れて反映されるようなシステムでも、まあ、困らない。BASEでいいんじゃね。という感じである。
こういう仕組みの中で一番手軽に使えるのが Git じゃなかろうかと思っている。
あ、でも Hadoop HDFS とか試してみよう。
twitterでコメントもらった気がする？ありがとうございます。
http://twitter.com/hyoshiok/status/2104982008
BASEのEventually ConsistentはCが厳密には達成できないAPの場合ということかと思います。
http://twitter.com/hyoshiok/status/2105000024
ACID学校の生徒はCは絶対というパラダイムで生きてきたので、ま、そのうちCになればいいんでない、という割り切りには堪えられない。という感じでしょうか。
Git を定期的に動かして、複数台のWeb+DBサーバのファイルを遅延同期するシステムを妄想しています。書き込みがそれほど多くなく、数秒程度の同期遅延が許されるのであれば、git pull を使ってファイルを更新し、git push で数秒ごとに同期するようにしておけば、シンプルにマルチマスタの分散ファイルシステムが作れるかなと。
ポイントは耐障害性です。Gitの部分はノード間が断線しても、FS+Webの単体セットが残っていればとりあえずサービスが継続できます。通信が復活ししだい同期すればよさげ。(どういうパターンでコンフリクトが起こりうるのはあんましわかっていません。)
ファイルの流通量が大きいと同期負荷が大きくなってお得でないので、書き込み頻度も量もそんなに大きくないけど、なくしたくないデータにつかえるのではないかと。Flickrのように、画像ファイルを置いておくWebサーバとか。ブログシステムとか。
きっと、分散ファイルシステムはいくらもあるだろうと思いますので、これがいいよ、というのがあればぜひ。
