シェアード・ナッシング・クラスタ
各DBサーバーは自身の担当するストレージのデータにのみアクセス可能なアーキテクチャをシェアード・ナッシング・クラスタと言います。データベースの全データを何らかのルールにより分割し、各サーバーに担当させます。このデータの分割とサーバーへの割り当ては第3回で解説したパーティショニングの概念そのものです。
ストレージは各DBサーバーに内蔵されるフラッシュ・メモリーやハードディスクの場合もありますし、ネットワーク・ストレージの場合もあります。DBサーバー内蔵ストレージ構成の場合、デバイスとの帯域を大きくとることができますが、DBサーバーの障害でアクセス不能なデータが発生します。また、DBサーバーの増減に対応しやすくするためにも、パブリック・クラウドで提供されるシェアード・ナッシング・クラスタはネットワーク・ストレージで構成される場合が多くなっています。
各サーバーにデータを分割するパーティション・キーはDBMSによっては分散キーと呼ばれる場合もあります。パーティション・キーをどのようなアルゴリズムで分割するかには、値の範囲を指定するレンジ、文字列などの離散的な値の集合を指定するリスト、そして値をハッシュしたハッシュ・バケットで分割するハッシュがあります。どのアルゴリズムが適しているかは、どのような処理を実行させるのかに依存します。
そのため、ある処理に最適化したパーティショニングが別の処理に対しては並列実行プロセス間の処理量の偏りが大きくなって並列化の効果が適切に出ないということもあり得ます。また、分析処理というのは「購買者の属性と商品」や「地域と商品」のように複数のデータ要素間の関係を調べることが多いため、大量データのジョイン処理が高速に実行できることが求められます。ですから、複数の表をフル・ジョインできるようにパーティショニングしてパーティションごとのジョインが1つのノード内で完結できるかも設計のポイントになります。
シェアード・ナッシング・クラスタはデータのパーティショニングが処理にうまく適合したときに高い性能を発揮します。しかし、並列度を上げるためにDBサーバー・ノードを増設するとデータの再配置が必要になります。
また、並列化する処理のアルゴリズムつまりSQL実行計画の途中の段階で各サーバー間でのデータ交換能力があるかも重要です。データ交換能力がない場合、単一ノード内で完結しない処理のデータはSQL実行計画の最終段階であるコーディネーター・ノードまで対象データを運び、そこで初めて他のノードが持っていたデータと結合されます。この場合、SQL実行計画の途中でデータを間引くことができません。そのため、このようなアーキテクチャではデータのパーティショニングがフル・パーティション・ワイズ・ジョインできるように配置できるかが処理時間に大きな影響をおよぼします。
例えばOracle Databaseではシェアード・ナッシング・クラスタ構成のOracle Database Shardingとシェアード・エブリシング・クラスタ構成のOracle Real Application Clustersがありますが、Oracle Database Shardingの各シャード・データベース・ノード間はデータの交換能力を持っていません。各シャード・ノード内の並列実行と、コーディネーター・ノードを介した全シャード・ノードの並列実行は可能です。そのため各シャードに配分するデータのパーティショニングがフル・パーティション・ワイズできることを前提としています。シャード・ノード間のデータ交換能力がないため用途をオンライン・トランザクション処理に割り切っています。
シェアード・ナッシング・クラスタはサーバー・ノードの台数を増やしやすいアーキテクチャではありますが、シェアード・ナッシング・クラスタに移行したらそれだけでアプリケーションの性能を上げられるかは判断できません。サーバー・ノード間のデータ交換能力の有無や、アプリケーションが発行する処理と適合するパーティショニングが可能であるのかといったことも検討する必要があります。
