はじめに
第4回は分析・集計処理のような1つの処理が大量のデータにアクセスする場合によく使用される並列実行について扱いました。今回も分析・集計処理を高速化する技法を扱います。並列実行を、複数台の物理サーバーのCPUコアを使用する場合に拡張します。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説していきます。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
並列実行を複数サーバーに拡張する
複数台の物理サーバーで1つの階層を構成することを、一般的にクラスタ構成と呼びます。1つの処理を複数の物理サーバーで並列化するには、処理対象の全体のデータを何らかの方法で分割して各物理サーバーに分担させる必要があります。全体のデータを分割して各物理サーバーに割り当てるのは第3回でも説明したパーティショニングの概念そのものです。
![複数台の物理サーバーにデータを分割して並列実行](http://cz-cdn.shoeisha.jp/static/images/article/15217/15217_001_s.png)
そしてパーティショニングされたデータの部分集合の処理量に大きなばらつきがあると、並列実行プロセス間の処理時間のばらつきも大きくなり、最も処理時間の長い並列実行プロセスの完了を待たないと全体としては処理が完了しないため、並列度を上げても全体の処理時間が短縮されないという問題があります。そのため、並列実行させる処理のデータへのアクセス・パターンを事前に把握し、それに適したパーティショニングを適用する必要があります。ある処理には適合したデータのパーティショニングであっても、別の処理に対してはあまり適切ではないということもあります。パーティショニングしたデータへのアクセスが硬直的なDBMSアーキテクチャであると、データへのアクセス・パターンの変化に適応するのが難しくなります。ストレージに格納されたデータのパーティショニングのやり直しは膨大な量のデータの移動が発生するので現実的ではない場合があります。
各物理サーバーからデータ全体がどうアクセスされるかでクラスタのアーキテクチャを大別することができ、シェアード・ナッシング・クラスタ構成とシェアード・エブリシング・クラスタ構成があります。
![シェアード・ナッシング・クラスタとシェアード・エブリシング・クラスタ](http://cz-cdn.shoeisha.jp/static/images/article/15217/15217_002_s.png)