日々の破片

_ ACIDからBASE

ちょっと勉強。

BASE：ACIDの代わりをどうぞ

要約(のつもりだったがのりで)抄訳：（誤読は十分あり得る）

これまでは垂直拡散（うまい訳はなんだろう？ vertical scaling）ってのがひとつの方法だった。よりパワフルなマシンへ移行するという道筋だ。何より簡単だってのがいいところ。でも、問題がある。どこまででもでかくできるわけでもないし、何より金食い虫だ。

それに対して水平拡散（horizontal scaling）ってのもある。いや、でもこれは複雑になる。この場合は、2次元で考えるといいね。横方向は機能分割。縦方向は断片化だ。Oracleのパーティショニングあたりとかかな。

機能分割はいいんだけど、そうなると1つのトランザクションが複数のデータベースサーバーをまたがる必要が出てくる。

エリック?ブルーワっていうバークレーの先生で、インクトミの首席サイエンティストがいるんだけど、CAP予想というのを唱えたんだ。Consistency（一貫性）、Availability（可用性）、Partition tolerance（個々のコンポーネントが使えなくても操作が完了できること）の3つの要素を同時に満たすことは不可能、っていう予想だ。

特に水平分割したデータベースでスケールさせるWebアプリケーションの場合は、どううまいことデータベースを設計しても一貫性と可用性のどちらかを犠牲にしなければならないことになる。

ACIDはもちろん知っているよね？ Atomicity、Consistency、Isolation、Durabilityだ。2フェーズコミットとか取り入れて、こいつを満たそうってわけだけど、分散させたら、ほら、一貫性のために可用性が失われてしまったわけじゃないか。

というわけでBASEですよ。

ACIDは悲観主義に徹して操作の最後に一貫性を強制するよね。BASE（Basically available、Soft State、Eventually consitent）（基本的にいつでも使えることにしておいて、状態はなあなあで、最後には一貫性が保てればいいじゃん）は違う。全然違う。データベース、不安定でいいじゃん。楽観主義で行こうよ。なんで、こんなのがACIDの代わりになるのかって？

部分的な失敗をサポートするからだ。簡単な例を出そう。もしユーザーが5つのデータベースサーバーをまたがって使うことにするとしよう。BASE設計では1つのでデータベースがいかれたら、その特定のホストにつながっている20%のユーザーにだけ、あきらめてもらうということだ。でも、これがシステムの可用性を高める秘訣なんだ。

というわけで、機能別にデータベースを分割して、その中でも特に忙しいやつを縦に分割しようじゃないか。こいつにどうBASEを適用するかって？ BASEでは論理トランザクションについての深い分析が要求されるんだよ。では、そいつを説明しようじゃないか。

さあ、続きのページを読んでくれ。

というところまで読んだ。

（続きも読んだが、これBASEと名前付けただけじゃん……とか言い出すのは老化の兆候かもしれないので自重）

_ イベントドリブンはまだ続くのかなぁ

GUIの秘訣はイベントドリブン。というわけで、複数のスレッドをがんがん使えるようになっても、Windows3.0レベルのアーキテクチャが一番、というような当面の結論があって。

そしてスケーラビリティの肝となる（とeBayの人が言っている）のも、またもやイベントドリブン（というよりも、キューを利用した遅延処理）だ。

でも、まあ、それが自然なのかな、とも思わないでもない。