オルタナティブ・ブログ > 隠れた財産 >

Make Applications More Valuable

CAP定理で学ぶOracle RAC

»

CAP定理のジレンマをOracle RACで理解する

クラウドとともにCAP定理なるものを良く見聞きするようになりました。

早速、ウェブ検索すると、この記事にたどりつきました。

元ネタは、私のタイトルと意味が逆になっていますが、

これは、本来は、CAP定義を調べるつもりが今日は、Oracle RACを理解することができたことを意味しています。

Oracle RACに関しては、複数ノード間を高速のインターコネクトで使って同期を取る技術くらいのざっくりした理解しかしていませんでした。

なので、ノードが増えたら、ノード間の情報交換が指数級数的に増えて大変じゃないかと思っていましたが、さすがOracleさんもそんなタコな仕組みを作るはずがありませんでした。

要するにハッシュ関数を使って複数ノードにデータベースブロックを管理させるという仕組みのようです。

ただ、ハッシュは万能なハッシュ関数を作るのが難しく、ばらつきやシノニムの問題等があって、それに対処しようとすると、仕組みそのものが複雑になって、状況によっては、厳しい面もあるのではないかと思います。(おそらくいろいろな対策は講じられているかとも思いますが。)

しかし、このアーキテクチャーは、RDBMSの場合には、こうせざるを得ない面もあるかと思います。

RDBMSの場合、データベースサーバーの役割は、データベースへのI/Oだけでなくクエリーの構文解析だったり、アクセスパスの決定だったりCPUを良く使う処理も多く含むので、スケールさせるためには、データベースサーバを複数持つ構造にせざるを得ないということになります。

結果は、CとPを重視すると、Aを得ることが難しくなるということです。

これは、なかなか解がない所です。(だから定理なのでしょうが)

Comment(0)