CodeZine(コードジン)

特集ページ一覧

分析・集計処理の並列実行を複数の物理サーバーに拡張するには? アーキテクチャ2つのパターンを紹介

オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド 第5回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

シェアード・エブリシング・クラスタ

 クラスタの各DBサーバーがストレージ上のすべてのデータにアクセスできるアーキテクチャをシェアード・エブリシング・クラスタと言います。ストレージは全ノードからアクセスできる必要があるためネットワーク・ストレージになります。このアーキテクチャを持っているのはOracle Real Application Clusters(RAC)とIBM Db2 pureScaleです。しかし、IBM Db2 pureScaleはノード内並列実行が可能ですが複数ノードにまたがった並列実行ができないので、データ・ウェアハウスなどの分析・集計処理にも使われるシェアード・エブリシング・クラスタは実質的にOracle RACしかありません。

 シェアード・ナッシング・クラスタではデータのパーティショニングが必須でしたが、シェアード・エブリシング・クラスタは必須ではありません。Oracle RACは全ノードが全データにアクセスできるため、クラスタの構成とデータのパーティショニングが結びついていないのが特徴です。データのパーティショニングはあくまでパーティション・プルーニングやパーティション・ワイズ・ジョインのように演算量を減らすためのチューニング要素として、ハードウェア構成とデータ構造を切り離して考えることができます。Oracle RACはSQL実行計画の途中のステップでもノード間のデータ交換能力があり、フル・パーティション・ワイズ・ジョインにならないパターンでも効果的にデータを間引いて次のステップにデータを送ります。

 また、物理DBサーバーの台数を増やすと、それに比例してストレージにもデータ供給性能の増加が求められます。Oracle RACの共有ストレージは物理的に1つである必要はなく、複数の筐体を並べたスケール・アウト型を取ることが可能です。物理DBサーバー・ノードをクラスタに増設してもストレージのデータの再配置は不要です。

 Oracle Databaseはスケール・アウト型ストレージ筐体の増減にも対応できるようなクラスタ・ボリューム・マネージャ兼ファイルシステムを自前で実装しておりOracle Automatic Storage Management(ASM)と言います。

Oracle Automatic Storage Management
Oracle Automatic Storage Management

 ASMは1つのファイルをエクステントというある程度連続した領域に分割し、エクステントをすべてのストレージ・デバイス上に分散するように配置します。そのため、どのファイルへのアクセスでもストレージ・サブシステムの性能を全力で出せるようになっています。そして、ストレージ筐体が増減するとエクステントを動的に再配置し、エクステントがすべてのストレージ・デバイスに分散された状態を維持しようとします。

 また、エクステントを異なるストレージ筐体上にミラーすることで冗長性を持たせています。ストレージ・デバイス単体の障害だけでなく、あるストレージ筐体がアクセス不能になったとしても、そのストレージ筐体が格納しているエクステントのミラーが別のストレージ筐体に格納されているため、全データへのアクセスが維持されます。

 Oracle RACの「データのパーティショニングとノードが結びついていない」という性質とASMの「どのファイルへのアクセスもストレージ・サブシステムの全性能を引き出す」という性質が組み合わさることで、データへのアクセス・パターンが変わったとしてもクラスタの全ノードと全ストレージを使った並列実行が可能であり、アプリケーションの変化に強いアーキテクチャになっています。

Oracle RACとASMによる並列実行
Oracle RACとASMによる並列実行

 また、全DBサーバー・ノードが全データにアクセスできるため、必ずしも全サーバー・ノードが並列実行に参加する必要はなく、一部のノードだけでも並列実行が可能です。この性質を利用して、Oracle RACとASMがベースとなっているOracle Autonomous Databaseはパブリック・クラウドで1CPU単位の動的なリソース調整および課金が可能な分析・集計処理を得意とするデータベース・サービスを提供しています。

まとめ

 今回は、大量のデータにアクセスする場合に複数のCPUに処理を分担させて処理時間を短縮する並列実行を複数の物理サーバーに拡張するクラスタ構成について解説しました。

 クラスタのアーキテクチャは大別するとシェアード・ナッシング・クラスタとシェアード・エブリシング・クラスタに分けることができます。シェアード・ナッシング・クラスタは各DBサーバー・ノードにデータを分割して配置しますが、これはパーティショニングの概念そのものです。パーティショニングと物理サーバーおよび物理ストレージの対応関係が固定であるため、処理とパーティショニングがうまく適合している場合は高速ですが、適合していない場合は並列実行の利点が活かせない場合があります。

 シェアード・エブリシング・クラスタは全DBサーバー・ノードが全ストレージ上のデータにアクセス可能です。データのどの部分集合(パーティション)にアクセスする場合でも全DBサーバー・ノードと全ストレージ・サブシステムの性能を引き出すことができるため、アプリケーションからのクエリーの変化に強いアーキテクチャとなっています。

 次回は分析・集計処理のような大量のデータにアクセスする処理の高速化を別の観点から扱います。データの格納フォーマットの違いである行指向と列指向、およびストレージとメモリーの関係についてキャッシュ・ベースのアーキテクチャとインメモリー・データベースを扱う予定です。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド

著者プロフィール

  • 日下部 明(日本オラクル株式会社)(クサカベ アキラ)

     日本オラクル株式会社でOracle Databaseを担当するエンジニア。主にOracle Real Application Clustersを中心とする高可用性構成や性能チューニングの問題解決およびコンサルティングに従事。著書に「これは使えるOracle新機能活用術」(翔泳社)。

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5