既存の共有ディスク型アーキテクチャの弱点を克復したIBM DB2 pureScale
データベースの2つのクラスターアーキテクチャ 企業が扱うデータは、爆発的に増え続けている。莫大なデータを効率よく管理するには、大規模で高性能なデータベースが欠かせない。しかしながら、数年後のデータ増加を予測し、それを見越した巨大なシステムを一気に導入するとなると、初期投資が膨らんでしまう現実がある。 そこで登場したのが、クラスタリングだ。規模のそれほど大きくないサーバーを複数並べ、1台の大きなサーバーがあるように見せかける。そして、それぞれのサーバーに処理を分散させることで、巨大で高性能なサーバーと同様な処理を実現する。処理性能が足りなくなれば、ノードを追加し拡張性が得られるのだ。 拡張性に優れたデータベースのクラスタリングシステムには、現状では2つのアーキテクチャがある。1つは個々のメンバーに専用ディスクを割り当てられるもの、もう1つがディスクを複数ノードで共有するもので、それぞれに長所
流離ヒ見聞録: RACとpureScaleの違い
私は旅人です。 ふらっと現れて、ふらっと消えます。 気の赴くままに何かを見に行きます。 たまにあなたの前に帰ってきたら、 そのときは見知らぬうたをうたいましょう。 うたに耳を傾けていただけたなら、 きっと私は幸せです。 Oracle RACとDB2 pureScaleはどちらも shared disk型のcluster RDBなのですが、 違いが理解できていなかったので 今日のClubDB2でお勉強してきました。 結論から言うと、クラスタ内の各DBノードの 整合性を取る部分（OracleではCash Fusion、 DB2ではCaching Facility）の置き場所が 違うってことが、最大のポイントでした。 両製品ともに、あるインスタンスが落ちても、 クラスタ内の他のインスタンスが生きていれば 無停止でDBが稼動するというのがウリです。 ですが、そのためには、落ちたインスタンスが 掴ん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
