JP4777972B2 - 無共有型並列データベースシステム及びデータベース管理方法 - Google Patents

Description

本発明は、並列データベースシステム（ｐａｒａｌｌｅｌ ｄａｔａｂａｓｅ ｓｙｓｔｅｍ）に関するものであり、特に、無共有型（ｓｈａｒｅｄ−ｎｏｔｈｉｎｇ）並列データベースシステムに関する。

無共有型のアーキテクチャを用いて設計される並列データベースシステムは、プロセッサ、メモリ及びディスク資源を各々有する複数ノードから構成される。これらのシステムでは、データベースのテーブルは、システムの全ノードに亘って分散される。また、データベースに対する問合せ（Ｑｕｅｒｙ）は、同時に、複数ノードにおいて並列して実行される。無共有型並列データベースシステムは、システムにおけるノード数の増加によりパフォーマンスを向上させ、より大きなデータセットの処理を可能にするリニアスケーリング（ｌｉｎｅａｒ ｓｃａｌｉｎｇ）を提供することを目的とするものである。

しかしながら、従来の設計では、例えば問合せスキューのような問題により、リニアスケーリングが提供できていない。問合せスキューは、同じデータベースに対する複雑さのレベルが類似した２つの異なる問合せが、全く異なる実行時間を要したときに発生する。

従来の無共有型並列データベースシステムにおいて、問合せスキューは、他の問合せがほとんど又は全くデータ伝送をしていない間に、特定の問合せの処理をするノード間で大量のデータを伝送しなければならないことが原因で発生する。従来のシステムにおいて、このデータ転送は、問合せ処理を減速させ、障害（ボトルネック）を発生させる原因となっている。

例えば、４つのノードを有する従来のシステムにおいて、データベーステーブルは多くの場合、各々のノードに各テーブルの４分の１ずつが格納されるようにして等しく分散される。そして、典型的なデータベースの問合せは、１つのテーブルの主キーと他のテーブルの外部キーとの整合性（マッチング）を検索してそれぞれのデータベーステーブルをスキャンする一つ以上の「結合」を含む。

２つのデータベーステーブルの結合を処理するために、各々のノードは、他のノードにデータベーステーブルのうちの１つの一部を伝送しなければならない。
このデータ伝送は、どのデータベーステーブルが結合されているか、また、問合せにどれ位の数の結合が含まれているかにより、相当な時間を要する可能性があり、よって問合せ処理を遅延させることになる。

データセットが大きくなり、問合せセッションの数が増えるにつれて、問合せスキューはますますシステムパフォーマンスを悪化させる。
この問題の本質に鑑みると、更なる追加ノードをこれらの従来システムに組み込んでも、問合せ処理におけるこの障害を解消することにはならない。
従って、問合せスキューを低減することが可能な、改良された無共有型の並列データベースシステムが求められている。

さらに、改良されたシステムは、システムを運用するのに必要な管理費用を最小限にしつつ、安全確実なフェールオーバ保護（ｆａｉｌｏｖｅｒ ｐｒｏｔｅｃｔｉｏｎ）を提供しなければならない。

そこで、本発明は、超無共有型並列データベースシステム（ｕｌｔｒａ−ｓｈａｒｅｄ−ｎｏｔｈｉｎｇ ｐａｒａｌｌｅｌ ｄａｔａｂａｓｅ ｓｙｓｔｅｍ）を提供することで、前述した従来の無共有型のデータベースシステムにおける問題を解決することを目的とする。

本発明の超無共有型並列データベースシステムは、従来技術と同じ量のデータがノード間を伝送される必要なく、データベースの問合せが並列に処理されることを可能にする方法で、データベースのテーブルを、複数のスレーブノード（ｓｌａｖｅ ｎｏｄｅ）に分割し、分散する。データベースは、データベーススキーマの構造及びテーブルの相対的（ｒｅｌａｔｉｖｅ）な大きさに関連したルールセットに従って分散される。

本発明は、ノード間におけるデータ伝送の必要性を大幅に減らすことにより、ネットワークトラフィック及び結果として生じる問合せスキューを減らすことで、システムパフォーマンスを大きく改善する。

具体的には、ある特定のデータベースに関し、ファクトテーブル（ｆａｃｔ ｔａｂｌｅ）と、ディメンションテーブル（ｄｉｍｅｎｓｉｏｎ ｔａｂｌｅ）のうちの１つと、が共通キーで分割され、複数のスレーブノードに分散される。ここで、該データベースにおける小さなディメンションテーブルは、システムのスレーブノード全てに複製される。さらに、残りのディメンションテーブルは、複数スレーブノードの全般に亘って分割され、且つ、全スレーブノードに複製される。これにより、スレーブノード間又はマスターノードとスレーブノードとの間に大きなネットワークトラフィックを生じさせずに、データベースシステムにおいて多数の問合せが実行可能となる。

本発明の一形態によれば、マスターノードおよび複数のスレーブノードを含んだ並列データベースシステムが提供される。
ファクトテーブルと複数のディメンションテーブルとを含んだデータベースは、データベースシステムのスレーブノードに分散される。データベースのテーブルを分散するために、ファクトテーブル及び第１ディメンションテーブル（ｆｉｒｓｔ ｄｉｍｅｎｓｉｏｎ ｔａｂｌｅ）がスレーブノードに分割される。さらに、残ったディメンションテーブルが、各々のスレーブノードに複製され、それらが最小サイズである場合には、さらに全スレーブノードに亘って分割される。

好ましくは、ファクトテーブル及び第１ディメンションテーブルは、共通キーで分割されることが望ましい。
また、残りのディメンジョンテーブルは、必要に応じて行分割又は列分割され、システムの複数スレーブノードに亘って分散される。

さらに、データベースに対する問合せは、並列データベースシステムのスレーブノードによって該スレーブノード間のデータ伝送なしで実行可能な、少なくとも１つの副問合せ（ｓｕｂ−ｑｕｅｒｙ）に変換される。

本発明の別の態様では、並列データベースシステムは、データベースシステムにより生成された問合せ結果をキャッシュに格納する。
好ましくは、マスターノードは、該マスターノードにより生成された問合せ結果を格納するための問合せキャッシュを含み、スレーブノードはその各々が、夫々の該スレーブノードにより生成された副問合せ結果を格納するための問合せキャッシュを含むことが望ましい。

本発明の別の態様では、データベースシステムの各々のスレーブノードには少なくとも１つのフェールオーバパートナー（ｆａｉｌｏｖｅｒ ｐａｒｔｎｅｒ）が割り当てられる。また、各々のフェールオーバパートナーは、それ自身のテーブルに加え、そのフェールオーバパートナーのデータセットのうち、全て又は一部のデータセットを格納する。
さらに、スレーブノードに障害が発生した場合には、障害が発生したスレーブノードに向けられた副問合せが、障害が発生したスレーブノードの代わりにフェールオーバパートナーにより実行される。

以上に要約した本発明によれば、有用で信頼性の高い並列データベースシステムが提供される。
まず、問合せスキューがデータベースの問合せ処理から無くなることで、データベースシステムのリニアスケーリングに近い状態が可能になる。また、二層の問合せキャッシュにより、問合せにおける配下のテーブルに対する変更を介入させることなく、反復的な問合せ処理が低減される。さらに、スレーブノードにおけるフェールオーバパートナーの運用により、ノードに障害が発生したときにおいても継続した使用を可能とする、費用効率の良いソリューションを提供する。
前述した本発明の概要は、本発明の本質を迅速に理解可能にするべく提供されたものである。
本発明の好ましい実施態様に関しては、以下の発明の詳細な説明及び関連した図面を参照することにより、さらに詳細且つ完全に理解されるであろう。

本発明は、超無共有型並列データベースシステムと呼称される、改良された無共有型並列データベースシステムである。
超無共有型並列データベースシステムは、少なくとも１つのマスターノード及び複数のスレーブノードを用いた従来の無共有型並列データベースに準じた方法で構成される。

図１は、超無共有型データベースシステムの一実施形態のハードウェアアーキテクチャを表す概要図である。
図１はデータベースシステム１０の構成を表し、マスターノード１１、複数のスレーブノード１２ａから１２ｎまで（図示を簡略化するためこのように記述する）を示す。なお、図１では、マスターノードを１つだけ含む。しかしながら、詳細に後述するように、本発明の他の実施形態では、複数のマスターノード１１を、データベースシステム１０に組み込む。マスターノード１１及びスレーブノード１２ａから１２ｎは、ネットワーク１３を介して相互接続される。

好ましくは、ネットワーク１３はデータベースシステム１０の信頼性を改善するために用いられる冗長或は二重ネットワーク（ｒｅｄｕｎｄａｎｔ ｎｅｔｗｏｒｋ）であることが望ましい。あるいは、重要でないアプリケーションであれば、非冗長なネットワーク（ｎｏｎ−ｒｅｄｕｎｄａｎｔ ｎｅｔｗｏｒｋ）が用いられても良い。
ネットワーク１３は、当業者にとって周知の多数のネットワーク技術及びプロトコルのうちのいずれか用いて実装される。実施形態におけるネットワークは、イーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）で用いられるＴＣＰ／ＩＰ、及び、インフィニバンド（Ｉｎｆｉｎｉｂａｎｄ）で用いられるＭＰＩ（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ）を含むが、これに限定されるものではない。

データベースシステム１０の各ノードは、プロセッサ、メモリ及びディスク資源を含んで構成される。具体的には、マスターノード１１は、中央演算処理装置（ＣＰＵ）１４、メモリ（ＲＡＭ）１５及びディスク１６を含んで構成される。
スレーブノード１２ａからスレーブノード１２ｎは、各々、ＣＰＵ１２ａからＣＰＵ１７ｎ、ＲＡＭ１８ａからＲＡＭ１８ｎ、及び、ディスク１９ａからディスク１９ｎを含んで構成される。

各ＣＰＵは、各ディスクに格納されたソフトウェアモジュールのプログラム命令を実行する。各ＣＰＵは、命令シーケンスをロードし、また、データを格納して操作するためのワークスペースとしてＲＡＭを使用する。
各々のノードは単一のＣＰＵ及び単一のディスクを含んで構成されたものとして表されているが、当業者であれば、各々のノードが、処理能力を改善するべく複数のＣＰＵ及び複数のディスクを含んで構成され得ることが理解できるはずである。例えば、本発明の１つの実施形態として、デュアル・プロセッサ及び１２台のハードディスクを用いたノードを用いる。
基本ソフトウェアコンポーネント（例えばオペレーティングシステム及びデバイスドライバ）に加えて、データベースシステム１０の各ノードは、本発明を履行するためのソフトウェアモジュールを格納し、実行する。

図２は、データベースシステム１０のソフトウエア・アーキテクチャを表す概要図である。
マスターノード１１は、ストリーム管理ソフトウェア２０、問合せキャッシュソフトウェア２１、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）解析ソフトウェア２２、スレーブスキーマ生成ソフトウェア２３、更新／登録ソフトウェア２４、問合せ並列化／最適化ソフトウェア２５、マルチステップ問合せ実行ソフトウェア２６、結果セット解析ソフトウェア２８、日付分割メンテナンスソフトウェア２９、一括ローディングソフトウェア３０、ＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）３１及びシステム管理ソフトウェア３２を含んで構成される。

複数のマスターノードを用いる実施形態においては、各マスターノードが前述したソフトウェアモジュールを含んで構成される。
各スレーブノードは、ＤＢＭＳ３３ａ〜３３ｎ及びスレーブ管理ソフトウェア３４ａ〜３４ｎを含んで構成される。
最後に、管理コンソールソフトウェア３５は、少なくとも１つのマスターノードにインストールされ、マスターノードに接続された端末又はデータベースシステム１０から分離したコンピュータシステムで実行されるクライアントプログラムを介してアクセスすることができる。

前述のソフトウェアモジュールは、データベースシステムのノードの各ディスクに格納され、それらのノードの各ＣＰＵによって実行される。
好ましい実施例では、全てのノードが同一のハードウェア構成を備え、各ノードの適切なソフトウェアモジュールをロードし実行することで、マスターノード又はスレーブノードのいずれかとして機能することができる。

本発明の一実施例によれば、ソフトウェアモジュールはＪＡＶＡ（登録商標）プログラミング言語を用いて遂行される。しかしながら、当業者ならば１つ又は複数のソフトウェアモジュールを遂行するのに他のプログラミング言語を用いることが可能であることは、理解できるであろう。
これらのソフトウェアモジュールの処理については、以下の本発明の処理の説明において詳細に説明する。

従来の無共有型並列データベースに対する本発明の重要な改良点は、結合などのデータベース問い合せを実行するためにノード間でデータを伝送する必要性を大幅に低減することにある。この改良は、データベースシステム１０の全スレーブノードに、データベースのテーブルを自動的に分割及び分散するルールセットを用いることで達成される。データベースのテーブルの分割及び分散は、生成されたスレーブスキーマに従って実行される。
外部のホストシステムは、データベースシステム１０に対し、ホストスキーマを定義するメタデータを伝送する。

ストリーム管理ソフトウェア２０は、メタデータを含んだストリームを受信し、受信したメタデータをＤＢＭＳ３１に伝送する。伝送されたホストスキーマに対するスレーブスキーマを生成するべく、ＤＢＭＳ３１は、ホストスキーマのメタデータをスレーブスキーマ生成ソフト２３に伝送する。
ホストスキーマを受信すると、スレーブスキーマ生成ソフト２３は、スレーブスキーマを生成するルールセットを適用する。スレーブスキーマは、データベースのテーブルがスレーブノード１２ａから１２ｎにどのように分割及び分散されるかについて定義する。

図３は、本発明の一実施例に従って、スレーブスキーマを生成するスレーブスキーマ生成ソフトウェア２３によって実行される処理を表すフローチャートである。
図３に示すステップはスレーブスキーマを生成するのに用いられるルールセットを具体的に表す。

ステップ３００（図ではＳ３００と示す。以下同じ）では、スレーブスキーマ生成ソフトウェア２３が、データベース１０に接続された外部ホストシステムから出力されたホストスキーマを受信する。このホストスキーマは、正規化されたスキーマとして、スタースキーマやスノーフレークスキーマを含むことができるが、これに限定されるものではない。

図４は、トランザクション処理評議会（Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｃｏｕｎｃｉｌ）により作成された、データベースシステム用の標準的な指標（ｂｅｎｃｈｍａｒｋ）として用いられるスノーフレークスキーマの一例である。
このスキーマは、１つのファクトテーブル（「ＬＩＮＥＩＴＥＭ」）及び複数のディメンションテーブル（「ＯＲＤＥＲＳ」、「ＣＵＳＴＯＭＥＲ」、「ＰＡＲＴ」、「ＰＡＲＴＳＵＰＰ」、「ＳＵＰＰＬＩＥＲ」、「ＮＡＴＩＯＮ」及び「ＲＥＧＩＯＮ」）を含んで構成される。

ファクトテーブルは、それが親である場合に、他のテーブルと親子関係を持たないテーブルとして定義される。ディメンジョンテーブルは、それが親である場合に、他のテーブルと親子関係を持つテーブルとして定義される。
図４において示されるスキーマは１つのファクトテーブルのみを含むが、データベースのスキーマは複数のファクトテーブルを含み得ることが理解できるであろう。
ステップ３０１では、ホストスキーマのテーブルが、スレーブスキーマの生成に備えて並び替えられる（ｏｒｄｅｒｅｄ）。

図５は、ホストスキーマのテーブルを並び替えるための処理を表すフローチャートである。
ステップ５００では、ホストスキーマ内の全てのファクトテーブルが識別される。
ステップ５０１では、各々の識別されたファクトテーブルについて、ホストスキーマにおいて定義されたテーブルのリレーションシップが、ファクトテーブルから第１ディメンジョンテーブルへと、内から外へ順に識別される。
ステップ５０２では、他の関連ディメンジョンテーブルを並び替える。なお、ディメンジョンテーブルは、ファクトテーブルに対する位置及び関係に基づいて並び替えられる。

図４で示されるホストスキーマを参照して説明すると、まず、「ＬＩＮＥＩＴＥＭ」テーブルは、ホストスキーマにおける唯一のファクトテーブルとして認識される。
次に、「ＬＩＮＥＩＴＥＭ」テーブルから順に外へ向かい、「ＯＲＤＥＲＳ」、「ＰＡＲＴ」、「ＰＡＲＴＳＵＰＰ」、「ＳＵＰＰＬＩＥＲ」テーブルが、「ＬＩＮＥＩＴＥＭ」テーブルと直接の関係を持つテーブルとして認識される。
このテーブルの第１階層は、例えばサイズなどの指定された基準に基づいて並び替えられる。この第１階層において並べ替えられた１番目のテーブル（例えば「ＯＲＤＥＲ」テーブル）は、第１ディメンションテーブルとして認識される。

テーブルのリレーションシップ及び指定された並べ替え基準を用いて、残りのディメンションテーブルが並び替えられる。
ここで、並列データベースシステムを用いた問合せを効率的に処理するために、サイズが大きく、また、頻繁にアクセスされるテーブルであるほど、全スレーブノードに出来る限り均等且つ効率的に割り当てられなければならない。
この点に関し、本発明は従来の無共有型データベースシステムにおいて用いられた方法に順ずる方法を採用する。

具体的には、本発明は、ファクトテーブル及び第１ディメンションテーブルを、共通キーでハッシュ分割する。これらのテーブルにおける共通キーを用いたハッシュ分割により、所定のキー値が各々のノードに割り振られ、２つのテーブルを結合する問合せは、スレーブノード間におけるデータ伝送なしで処理され得る。

図３のステップ３０２では、対になったファクトテーブル及び第１ディメンションテーブルごとに、ハッシュキーを記録する。
ここで再び図４に示すホストスキーマを再度、参照すると、ＯＲＤＥＲＫＥＹが、ＯＲＤＥＲＳテーブル（第１ディメンションテーブル）のプライマリキーであり且つＬＩＮＥＩＴＥＭテーブル（ファクトテーブル）の外部キーであるため、ハッシュキーとして記録される。

一旦データベーステーブルが並び替えられ（ＯＲＤＥＲＥＤ）、ハッシュキーが記録されると、スレーブスキーマ生成処理は、スレーブスキーマを生成可能な状態となる。そして、ホストスキーマの各テーブルが調査され（ＥＸＡＭＩＮＥＤ）、スレーブスキーマに、１つ又は複数の対応したテーブルが生成される。
図３のステップ３０３では、処理中のテーブルについて、それがファクトテーブルか、第１ディメンションテーブルかの判定が成される。
各々のファクトテーブル及びディメンションテーブルは、水平分割され（ｈｏｒｉｚｏｎｔａｌｌｙ ｐａｒｔｉｔｉｏｎｅｄ）、全スレーブノードに対して分散される。
このように、各々のスレーブノードは、ホストスキーマの各々のファクトテーブル及び各々の第１ディメンションテーブルの水平分割された一部分を割り当てられる。

ところで、通常のデータベースでは、テーブルは相当量のテキストを含む。このテキストは、通常はテーブルのコメントフィールドに存在する。
本発明の付加的な特徴は、これらの大きなコメントフィールドを削除してスレーブスキーマの分割テーブル内に移すために、テーブルを垂直分割することである。
２つのテーブルの行を正確に同じ順序に保つため、個々の行のコメントフィールドが、行識別子を用いることで識別される。
垂直分割機能は、デフォルトルールとして設定されるか、システム管理者からの入力によって設定される。

ステップ３０４では、テーブルを垂直分割するか否かが判定される。
ステップ３０５では、垂直分割しない場合に、スレーブスキーマに水平分割されたテーブルが生成される。
ステップ３０６では、垂直分割する場合に、スレーブスキーマに垂直分割されたテーブルのセットが生成される。なお、これらの垂直分割されたテーブルは、水平分割されたテーブルの垂直分割であり、ステップ３０５で生成された水平分割されたテーブルと同じセットとしてのものである。
本発明の好ましい実施例によれば、ファクトテーブル及び第１ディメンションテーブルの他の各々のテーブルが完全に複製され、各々のスレーブノードに格納される。

ステップ３０７では、調査されたテーブルがファクトテーブル又は第１ディメンションテーブルでない場合（以下、かかるテーブルを外部ディメンションテーブルという）に、完全な（ＦＵＬＬ）テーブルが、スレーブスキーマに生成される。
各々のスレーブノードに、各々の外部ディメンションテーブルを完全に複製することで、外部ディメンションテーブルと、ファクトテーブル又は第１ディメンションテーブルと、の間の結合を含む問合せなどが、スレーブノード間におけるテーブルデータの伝送を必要とせずに、並列に実行される。

各々の外部ディメンションテーブルの完全な複製に加え、本発明の好ましい実施例では、必要に応じて、全スレーブノードに亘って、外部ディメンションテーブルを分割及び分散する。
該スレーブノードに、外部ディメンションテーブルの完全な複製及び外部ディメンションテーブルの分割された一部を有することで、問合せを最適化し、最高のシステムパフォーマンスを生むようにスレーブノードのテーブル参照を行うようにすることができる。

しかしながら、一部の（ｃｅｒｔａｉｎ）データベーステーブルは、十分なパフォーマンスを産しないことから更なる処理や格納空間を必要することを正当化することもある。
例えば、比較的小さなデータベースを全スレーブノードに分割及び分散することは、に十分なパフォーマンスを供しない可能性もある。
従って、本発明の実施形態の１つは、例えばこのような所定のサイズより小さい一部の外部ディメンションテーブルについては、分割を行わないという分割オプションが、デフォルトルールとして又はシステム管理者による入力によって設定されるものである。

ステップ３０８では、処理中のテーブルを分割するか否かを判定する。
ステップ３０９では、分割オプションが設定されていない場合又はテーブルが分割基準を満たしていない場合に、テーブルを垂直分割するか否かを判定する。
ステップ３１０では、垂直分割しない場合に、水平分割されたテーブルが、スレーブスキーマに生成される。
ステップ３１１では、垂直分割する場合に、垂直分割されたテーブルが、スレーブスキーマに生成される。
なお、これらの垂直分割されたテーブルは、水平分割されたテーブルを垂直分割したものであり、セットとしては、ステップ３１０で生成された水平分割されたテーブルと同じものである。

ステップ３１２では、ひとたびホストスキーマの全てのテーブルが調査され、適切な関連テーブルがスレーブスキーマに生成されると、生成されたスレーブスキーマはＤＢＭＳ３１に格納され、各々のスレーブノードに伝送される。
スレーブスキーマは、マスターノード及びスレーブノードにより、データベーステーブルをデータベースシステムにロードし、分割するために用いられる。
個々のデータベースのデータは、マスターノードの中の１つ又は一括ローディング専用のノードのいずれかを介して、本発明のデータベースシステムに一括ローディングされる。

図６は、データベースシステムへのデータの一括ローディングの処理を表すフローチャートである。
ステップ６０１では、ロードされた各々のテーブルについて、関連するテーブルの適切なロックを設定することにより、スレーブノードがデータを受信する準備をする。

ステップ６０２では、全スレーブノードに対し、各々のテーブルのデータを伝送する。
好ましくは、データは、ノード間のネットワークによりマルチキャスティング機能を介してスレーブノードに伝送される。
ステップ６０３では、スレーブノードによって受信されたテーブルが、スレーブスキーマに基づいて分割される。

図７は、スレーブノードのテーブルをロード及び分割する処理を表すフローチャートである。
スレーブ管理ソフト３４は、個々のスレーブノードのテーブルをロード及び分割するべく、テーブルの各行を調査する。
ステップ７００では、テーブルが全てロードされるか否かが判定される。全てロードされる場合には、各行が適切なテーブルへロードされる。

ステップ７０２では、分割された構成（Ｆｏｒｍ）を保持するか否かが判定される。
ステップ７０３では、分割された構成が保持される場合に、個々のスレーブノードの分割されたテーブルに行が含まれているか否かを判定するべく、各行が調査される。
ここで、各々のスレーブノードは、分割されたテーブルの行の一意な一部が割り当てられることに留意する。

テーブル分割は、テーブルの行を分割及び分散する周知のアルゴリズムのいずれかを用いて行われる。好ましくは、テーブルはスレーブノードに均等に分割されると良い。
テーブルの行を分割するのに用いるアルゴリズムに基づき、個々のスレーブノードに調査された列を割り当てるか否かが判定される。

本発明の付加的な特徴は、データを分割及び分散するのに、日付分割を用いることである。
日付分割では、データベーステーブルは、データに含まれる基準となる日付に基づいて分割され分散される。その日付は、予め設定されたルールを用いて設定されるか、又はシステム管理者による入力によってコントロールされる。例えば、個々の年、四半期又は月の間のデータが、異なるスレーブノードに格納されることができる。

これらの日付分割されたテーブルが格納され、日付に基づいたデータベース問合せに用いられる。日付分割されたテーブルは、基準となる日付の範囲に該当しないデータを除外するべく常に保持される。なお、好ましくは、日付分割されたテーブルは、日付分割専用のスレーブノードに格納されると良い。
しかしながら、日付分割されたテーブルは、他の分割された又は分割されていないテーブルとともに、通常のスレーブノードに格納されることも可能である。

ステップ７０４では、個々のスレーブノードが日付分割されたスレーブノードであるかを判定する。
ステップ７０５では、日付分割されたスレーブノードである場合に、調査された行がそのスレーブノードによって格納される日付範囲に該当するかどうかが判定される。
ステップ７０６では、スレーブノードが日付分割されたスレーブノードであり、且つ、行が基準となる日付の範囲に該当する場合、行がスレーブスキーマに基づいて垂直分割されるか否かが判定される。

ステップ７０７では、垂直分割された行について、行が垂直に分割されたテーブルの適切なセットに書き込まれる。
ステップ７０８では、行が垂直分割されない場合、行が適切な水平分割されたテーブルに書き込まれる。
本発明の付加的な特徴は、周知の分割アルゴリズムのいずれかを用いて、スレーブノードにおける更なるレベルのテーブル分割を行う方法である。
例えば、テーブルはハッシュ値または日付範囲によって分割されることができる。

本発明のデータベースシステムはまた、フェールオーバ保護を提供するように設計されている。
このプロテクトを実行するために、スレーブノードは、フェールオーバパートナーを割り当てられる。各々のスレーブノードは、それ自身が有する分割されたテーブルに加え、フェールオーバパートナーが有する分割されたテーブルをも格納し、関連したテーブルをアップデートするために、前述したような同じアルゴリズムを用いる。

このフェールオーバシステムを用いることにより、各々のノードにおいてミラーリング又はパリティに基づいたディスクアレイを運用しなくても、高い信頼性が提供される。
このことにより、ＲＡＩＤ０のディスクシステムが高いパフォーマンスを提供するべく用いられることが可能であり、高いレベルのＲＡＩＤシステムに伴う大きなコストを必要としないことから、実装コストを低減させることができる。

ステップ７０９では、調査された行が、スレーブノードの日付分割されたテーブルの日付の範囲に該当しない場合、又は、スレーブノードが日付分割されたテーブルを格納していない場合、行がスレーブノードに垂直分割されるか否かが判定される。
ステップ７１０では、行が垂直分割される場合、それが垂直分割されたテーブルの適切なセットに書き込まれる。
ステップ７１１では、行がスレーブノードの水平分割されたテーブルの一部であるか否かが判定される。

ステップ７１２では、行が水平分割されたテーブルの一部である場合、その行がそのテーブルに書き込まれる。
ステップ７１３では、一旦個々のテーブルの行の全てがデータベースに追加されると、影響を受けるさまざまな物理テーブルのインデックスがアップデートされる。

本発明の他のパフォーマンスを高める特徴は、問合せキャッシュ及び一時テーブルキャッシュを用いることである。
問合せキャッシュは、各々のマスターノードのＤＢＭＳ３１及び各々のスレーブノードのＤＢＭＳ３３に格納され、保持される。問合せキャッシュは、個々のノードにおいて実行される問合せに対する問合せ結果を格納する。

一時テーブルキャッシュは、多重処理（ｍｕｌｔｉ−ｓｔｅｐ）の問合せを実行するときにマスターノードによって生成される一時テーブルを格納するために、各々のマスターノードのＤＢＭＳ３１に格納され、保持される。
テーブルがデータベースシステムにロードされるときに、問合せキャッシュ、及び、テーブルの前のバージョン（版）に基づいて生成された結果を含む一時テーブルキャッシュは、初期化されなければならない。
ステップ６０４では、これに従い、関連した問合せキャッシュ及び一時テーブルキャッシュは存在しない。
これらのキャッシュの処理に関するより詳細な説明は、後述する。

以上、テーブルのソート及び分割により、データベースシステムにテーブルを一括ローディングするのに用いられる、様々な処理について詳述した。
データをデータベースシステムへロードするための付加的な処理は、生成されたスレーブスキーマ及びデータ分散に影響するシステム設定へアクセスする外部ホストシステムを用いて、データを、予めソートすることである。予めソートされたデータは、マスターノードを迂回し、直接スレーブノードにロードされることが可能である。

図８は、予めソートされたデータを一括ローディングする処理を表すフローチャートである。
図８に示すように、各々のテーブル及び各々の予めソートされたデータの分割データは、調査され、適切なスレーブノードにロードされる。
ステップ８００では、スレーブノードに全て格納された各々のテーブルについて、全てのスレーブノードが、テーブルを一括ローディングできる状態にされる。
ステップ８０１では、全てのテーブル内容が、全てのスレーブノードに伝送される。

ステップ８０２では、ソートされたデータの各々の分割データについて、スレーブノードの割り当てられたフェールオーバセットは、分割データをロードできる状態にされる。
ステップ８０３では、分割データはフェールオーバセットに伝送される。
ステップ８０４では、最後に、適切な問合せキャッシュ及び一時テーブルキャッシュが初期化される。

本発明の一実施例によれば、外部のホストシステムは、ＳＱＬステートメントを用いてデータベースシステムと通信する。
ＳＱＬステートメントは一般的に、ホストシステムによって各々のストリームに分けられ、各々のストリームは個々のユーザ又はアプリケーションに対応する。ＳＱＬステートメントを編成するためにストリームを用いることにより、ステートメントが、データベースシステムによって正しい順序で実行されることが確実となる。
データベースシステムによって受信されるＳＱＬステートメントのストリームは、各々のマスターノードのストリーム管理ソフトウェア２０によって管理される。

図９は、外部のホストシステムから新規のステートメントを受信したときに、ストリーム管理ソフトウェア２０によって実行される処理を表すフローチャートである。
前述のように、本発明のデータベースシステムは、１つ以上の個数のマスターノードを有する。
外部のホストシステムによって送信されるＳＱＬステートメントは、各々のマスターノードによって受信され、図９に記載されている方法で処理される。

ステップ９０１では、各々のマスターノードのストリーム管理ソフトウェア２０において、受信したステートメントが、新規のストリームの開始又は既にデータベースシステムによって処理されている既存のストリームの一部であるか否かを判定する。
ステップ９０２では、ステートメントが新規のストリームの開始である場合、ストリーム管理ソフトウェア２０は、ストリームを当該マスターノードにおいて制御するべきか否かを判定する。

各々のストリームは、データベースシステムの１つのマスターノードによって制御される。各々のマスターノードのストリーム管理ソフトウェア２０は、どのマスターノードが生成されたストリームを制御するかについて決定するべく、他のマスターノードと通信する。ストリーム制御は、多数ある周知のロード・バランシング・アルゴリズムのいずれかを用いて決定される。
ステップ９０３では、ステップ９０２において当該マスターノードがストリームを制御すると判定された場合、ストリーム管理ソフトウェア２０は、当該マスターノードがストリームを制御することを、他のマスターノードに通知する。

ステップ９０４では、各々のステートメントがマスターノードによって受信されたとき、各々のマスターノードの問合せキャッシュソフトウェア２１は、ステートメントとマスターノードの問合せキャッシュとを比較する。前述したように、各々のマスターノードは、問合せキャッシュに、以前の問合せの結果を格納している。
ステップ９０４において、同一のステートメントが、マスターノードにより配下のテーブルに対する更新において以前に処理されたかどうかを判定するべく、ステートメントが問合せキャッシュと比較される。

ステップ９０５では、同一のステートメントがすでに処理された場合、そのステートメントに対応する結果セットが問合せキャッシュから検索されて、問合せストリームを制御する外部のホストシステム又はマスターノードに送信される。そして、マスターノードによるステートメントの処理は終了する。
ステップ９０６では、ステートメントが問合せキャッシュで見つからない場合、受信したステートメントが当該マスターノードによって制御されるストリームの一部であるか否かが判定される。

ステップ９０７では、マスターノードがそのストリームを制御する場合、ステートメントがＳＱＬ解析ソフトウェア２２よって処理される。
ステートメントが当該マスターノードによって制御されるストリームの一部でない場合、当該マスターノードによるステートメント処理は終了し、ストリーム管理ソフトウェア２０は、次のステートメントが受信されるのを待機する。

図１０は、新たな処理におけるステートメントを生成するＳＱＬ処理ソフトウェア２２によって実行される処理を表すフローチャートである。
ステップ１００１では、新たな処理における各々のステートメントを生成するべく、ステートメントがトークン化される。
ステップ１００２では、トークンが解析される。
ステップ１００３では、最後に、解析されたステートメントを処理する関連したサブルーチンがコールされる。
サブルーチンは、テーブルの改変（ａｌｔｅｒ）、データの更新／登録、及び問合せ並列化（ｑｕｅｒｙ ｐａｒａｌｌｅｌｉｚａｔｉｏｎ）を含むことができるが、これに限られるものではない。

図１１は、データベースを改変するために、ＳＱＬ解析ソフトウェア２２によってコールされるテーブル改変サブルーチンによって実行される処理を表すフローチャートである。
データベーステーブルの改変は、主にスレーブスキーマ生成ソフトウェア２３によって実行される。

ステップ１１００では、改変されるテーブルがファクトテーブ又は第１ディメンションテーブルであるか否かが判定される。
ステップ１１０１では、テーブルがファクトテーブル又は第１ディメンションテーブルである場合、改変するテーブルが垂直分割されているか否かが判定される。
ステップ１１０２では、テーブルが垂直分割されていない場合、テーブルの改変は、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードの、水平分割されたテーブルにおいて行われる。

ステップ１１０３では、改変されたテーブルが垂直分割されている場合、垂直分割されたテーブルのセットは、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードにおいて改変される。
ステップ１１０４では、改変されるテーブルがファクトテーブル又はディメンションテーブルでない場合、テーブルは、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードにおいて改変される。
ステップ１１０５では、改変されるテーブルが複数スレーブノードに対して分割されているか否かが判定される。

ステップ１１０６では、テーブルが分割されている場合、そのテーブルが垂直分割されているか否かが判定される。
ステップ１１０７では、テーブルが垂直分割されていない場合、当該水平分割されたテーブルのセットのメタデータ及び実テーブルの内容が改変される。
ステップ１１０８では、テーブルが垂直分割されている場合、当該垂直分割されたテーブルのセットのメタデータ及び実テーブルの内容が改変される。
ステップ１１０９では、最後に、改変されたテーブルに依存する問合せキャッシュエントリおよび一時テーブルキャッシュエントリが初期化される。

図１２は、データベースに対しデータを更新又は登録するためにＳＱＬ解析ソフトウェア２２によりコールされる更新／登録サブルーチンにより実行される処理を表すフローチャートである。
ステップ１２００では、更新又は登録された各々の行について、行がスレーブノードに分割された形態でのみ保持される例えばファクトテーブルや第１ディメンションテーブルと言ったテーブルの一部であるか否かが判定される。
ステップ１２０１では、行がスレーブノードに分割された形態でのみ保持されるテーブルの一部ではない場合、その行はシステムの各々のスレーブノードに書き込まれる。

ステップ１２０２では、行が分割された形態でのみ保持されるテーブルの一部である場合には、その行は、適切なハッシュキー及び場合によっては基準となる日付に基づいて、分割される。
ステップ１２０３では、行が、関連するスレーブノードの分割されたテーブルに書き込まれる。
ステップ１２０４では、変更された全てのデータベースのインデックスが更新される。
ステップ１２０５では、データが更新／登録されたテーブルに依存する全ての問合せキャッシュおよび一時テーブルキャッシュエントリが初期化される。
問合せステートメントは、問合せ並列化ソフトウェア２５によって処理され、最適化される。

図１３は、問合せ並列化処理を表すフローチャートである。
ステップ１３０１では、問合せがデータベースシステムの日付分割設定に含まれる特定の日付範囲を調査するか否かを判定する。
ステップ１３０２では、問合せが日付分割に含まれる日付範囲を調査する場合、特定の日付範囲に用いられるスレーブノードのグループが指定される。
ステップ１３０３では、問合せが特定の日付範囲を調査しない場合、又は日付範囲がどの日付分割設定にも相当しない場合、全てのスレーブノードは問合せを実行するのに用いられるべく指定される。

ステップ１３０４、１３０５及び１３０６は、問合せの構造に基づいて、また、当業者なら周知の技術を用いて、スレーブノードの問合せをどのように処理するかを決定する。
ステップ１３０４では、夫々独立して実行する必要がある副問合せが、２つの別々の問合せに分割される。
副問合せは、マスターノードにおいて集められる中間結果を伴ってまず実行され、更なる処理のために、残りの問合せとともに、スレーブノードに返される。

ステップ１３０５では、外部結合が含まれる場合、問合せを成し遂げるべく、スレーブノード及びマスターノードにより提携して実行される複数の問合せに分割される。
ステップ１３０６では、問合せ最適化プログラムは、再び当業者に周知の技術を用いて、多重処理及び単一処理のストラテジー（ｓｔｒａｔｅｇｉｅｓ）のコストを評価し、最も低いコストの機能を選択する。多重処理が最適である場合は多重処理を、単一処理が最適である場合は単一処理を行なう。
ステップ１３０９では、問合せが、単一処理の問合せを行うステップ１３０７又は多重処理の問合せを行うステップ１３０８のいずれかを経て処理され、結果セットがホストに返される。

図１４は、単一処理の問合せを実行するための処理を表すフローチャートである。
問合せは、ホストスキーマからテーブル名を運用しているテーブルを参照する外部のホストシステムから受け取られる。スレーブノードを用いて問合せを並列に処理するために、テーブル名は、スレーブスキーマに準ずるテーブル名に置き換えられなければならない。別の実施例においては、単一処理の問合せは直線的にスレーブノードを経由することができるため、ホストスキーマで用いられるテーブル名は、生成されたスレーブスキーマで用いることが可能であった。
ステップ１４０１では、問合せにおいて参照されるテーブル名が、スレーブスキーマに準ずるテーブル名に置き換えられる。

図１５は、問合せにおいて用いられるテーブル名を置き換えるために用いられる処理を表すフローチャートである。
ステップ１５００では、問合せからの結合及び／又はテーブルは、ファクトテーブルの外部における処理を再要求される。
ステップ１５０１では、要求された問合せが、その問合せにおいて実行されるべき結合を含むか否かを判定するべく調査される。

ステップ１５０２では、問合せが結合を含んでいない場合、問合せで用いられたテーブルが、スレーブノードに分割された形態でのみ保持されるものであるか否かが判定される。
テーブルがスレーブノードにおいて完全に保持される場合、テーブル名を置き換えることなく、処理を終了する。
ステップ１５０３では、テーブルが分割された形態でのみ保持される場合、スレーブスキーマにおいて、テーブルが垂直分割されているか否かが判定される。

ステップ１５０４では、テーブルが垂直分割されていない場合、テーブル名が、関連する水平分割されたテーブルの名称で置き換えられる。
ステップ１５０５では、テーブルがスレーブスキーマにおいて垂直分割されている場合、問合せにおいて、垂直分割によって削除された列（例えば大きいコメントフィールドなど）が用いられるか否かが判定される。
ステップ１５０６では、削除された列が問合せで用いられない場合、テーブル名が、関連した垂直分割されたテーブルの名称で置き換えられる。

ステップ１５０７では、問合せにおいて削除された列が用いられる場合、テーブル名が、関連した垂直分割されたテーブルで置き換えられる。また、削除された列を含むテーブルから対応する列を取得するように問合せが修正される。これは、当業者なら周知の技術を用い、行識別子を介して達成される。
ステップ１５０１において、問合せが結合を含むと判定された場合、各々の結合は順次に調査される。
ステップ１５０８では、処理中の問合せにおける各々のテーブルについて、テーブルがファクトテーブルか第１ディメンションテーブルかが判定される。

ステップ１５０９では、テーブルがファクトテーブル又は第１ディメンションテーブルである場合、テーブルがスレーブスキーマにおいて垂直分割されているか否かが判定される。
ステップ１５１０では、テーブルが垂直分割されていない場合、テーブル名が、対応する水平分割されたテーブルの名称で置き換えられる。
ステップ１５１１では、テーブルが垂直分割されている場合、問合せが垂直分割において削除された列を用いているか否かが判定される。

ステップ１５１２では、問合せが削除された列を用いない場合、テーブル名が、対応する垂直分割されたテーブルの名称で置き換えられる。
ステップ１５１３では、問合せが削除された列を用いる場合、テーブル名は、対応する垂直分割されたテーブルの名称で置き換えられる。また、削除された列を含むテーブルから対応する列を取得するように問合せが修正される。
これは、当業者なら周知の技術を用い、行識別子を介して成し遂げられる。
ステップ１５０８においてテーブルがファクトテーブル又は第１ディメンションテーブルでないと判定された場合、ステップ１５１４では、調査された問合せで用いたテーブル名が、対応する水平分割されたテーブル名で置き換えられる。

ステップ１５０９では、水平分割されたテーブル名が問合せに含まれていない場合、ステップ１５０９へ進む。
そのとき、ステップ１５０９からステップ１５１３が、既述した方法で繰り返される。
ステップ１５１５では、テーブル名が水平分割されたテーブル名で置き換えられなかった場合、テーブルが、既に用いられている水平分割されたテーブルと同じ分割キーを有するか否かが判定される。
テーブルが、同じ分割キーを有する場合、結合がテーブルにおける同じ位置の分割の間で実行され、処理がステップ１５０９から１５１３へと進み、前述したように実行される。
テーブルが同一の分割キーを有しない場合、テーブル名は置き換えられず、処理が終了する。

図１４に戻り、ステップ１４０１で一旦テーブル名が置き換えられていると、ステップ１４０２において、問合せは、当業者なら周知の技術を用いて、スレーブノードで用いられたデータベースに対して最適化される。
例えば、問合せがより効率的に実行されるために、Ｉ／Ｏサイクルと関連するＣＰＵサイクルのコスト設定が変更可能である。
ステップ１４０３では、最適化された問合せがスレーブノードに伝送される。

スレーブノードに障害が発生した場合は、詳しく後述するように、システムの他のスレーブノードに加え、障害が発生したスレーブノードに対応するフェールオーバパートナーに問合せが送信される。各々のスレーブノードのスレーブ管理ソフトウェア３４は、依存するマスターノードから問合せを受信し、処理する。

図１６は、新規の問合せが受信されたときに、スレーブ管理ソフトウェアによって実行される処理を表すフローチャートである。
ここで、場合によっては、スレーブ管理ソフトウェアの介入なしで、スレーブノードのＤＢＭＳによって直接問合せが実行可能であることに留意する。
ステップ１６００では、マスターノードから新規の問合せを受信すると、スレーブ管理ソフトウェア３４は、問合せがスレーブノードで用いられるＤＢＭＳにおいて解釈可能になるように変換される必要があるか否かが判定される。

本発明のシステム設計は、システムのスレーブレベルで専用のＤＢＭＳが用いられることを必要としない。この特徴は、既に使用しているＤＢＭＳをスレーブノードで用いることが可能であるため、システムコストを低減し、実装までの期間を短縮することができる。
ステップ１６０１では、変換が必要な場合、問合せは当該ＤＢＭＳにおいて解釈可能になるように変換される。

ステップ１６０２では、当該ＤＢＭＳで問合せを実行するのに最適化が必要であるか否かが判定される。
ステップ１６０３では、最適化が必要である場合、問合せが最適化される。
マスターレベルで処理が実行されるのと同様に、新規の問合せがその問合せにおいて参照されたテーブルに対する変更を介在させることなく、以前にデータベースに対して行われたか否かを調べるために、問合せキャッシュと照合される。

スレーブ管理ソフトウェア３４は、スレーブノードに記録された、ファイルオーバテーブル及びローカルのテーブルの両方の問合せキャッシュを保持する。
ここで、一部のＤＢＭＳ製品は、自分自身の問合せキャッシュを保持する。スレーブノードで実行されているＤＢＭＳが問合せキャッシュを保持している場合、スレーブ管理ソフトウェア３４は、それ自身の問合せキャッシュをチェック及び保持する必要がない。

本発明は、マスターレベルで保持される問合せキャッシュと共に、問合せ処理の不必要な反復を防ぐことによってシステムパフォーマンスを改善する二層の問合せキャッシュを提供する。
ステップ１６０４では、受信された問合せが、問合せキャッシュと比較される。
ステップ１６０５では、問合せが問合せキャッシュに存在する場合、結果セットが問合せキャッシュから検索される。

ステップ１６０６では、問合せが問合せキャッシュに存在しない場合、問合せは実行されるＤＢＭＳに送信される。
ステップ１６０７では、一旦結果セットが取得されると、スレーブ管理ソフトウェア３４は、結果セットがマスターノードに返される前に、後処理が必要であるか否かが判定される。
ステップ１６０８では、後処理が必要とされる場合、それが実行される。
ステップ１６０９では、結果セットが、問合せを発行したマスターノードへ返される。

再び図１４に戻り、マスターノードの結果セット解析ソフトウェア２８は、問合せ処理に用いられた各々のスレーブノードからの結果セットを受信する。
ステップ１４０４では、結果セット解析ソフトウェア２８は、受信した結果セットの後処理を実行する。
後処理は、複数の結果セットを１つの結果セットに結合させ、結果セットのなかで結果を編成し、問合せを生成する外部ホストシステムと互換性のあるフォーマットに結果セットを変換することを含むが、この限りではない。

図１７は、本発明の一実施例に基づく、問合せの多重処理を表すフローチャートである。
ステップ１７０１では、問合せは２つ以上のスレーブ問合せに分割される。
これらの問合せを、一連のスレーブノードにおいて実行される複数のスレーブ問合せに分割することは、元々の（分割前の）問合せを処理するためにスレーブノード間でデータを伝送する必要をなくし、また、これらの問合せを実行するシステムパフォーマンスを改善する。

問合せの多重処理は、問合せを実行するマスターノードの一時テーブル（テンポラリテーブル）を使用して遂行される。これらの一時テーブルは、個々のスレーブ問合せを実行することにより生成される中間結果セットを格納する。また、一時テーブルは、各々のスレーブ問合せによる結果セットを蓄積するために用いられる。なお、これに代えて、一時テーブルは、スレーブノードに送信されて、一時テーブルの或るものとスレーブノードのローカルテーブルとを結合させる次のスレーブ問合せを実行するようにしても良い。

各々のマスターノードは、データベースシステムのマスターノード及びスレーブノードで用いられる問合せキャッシュと同様に、マスターノードのＤＢＭＳ３１においてマスターノードにより実行されるスレーブ問合せに対して生成された一時テーブルの複製を格納している一時テーブルキャッシュを保持する。
ステップ１７０２では、スレーブ問合せを実行するときに、スレーブ問合せが、一時テーブルが依存する配下のテーブルに対する変更を介在させることなく既に実行されたか否かを判定するべく、スレーブ問合せが一時テーブルキャッシュと照合される。
ステップ１７０３では、一時テーブルキャッシュと一致しない場合、スレーブ問合せに対する一時テーブルが生成される。

ステップ１７０４から１７０７では、スレーブ問合せが実行され、結果が生成される。
これらのステップにおける処理は、図１４のステップ１４０１から１４０４における処理と同様であることから、詳細な説明を省略する。

ステップ１７０８では、一旦スレーブ問合せが実行されるか、又はスレーブ問合せが一時テーブルキャッシュに存在している場合、マスターノードは、スレーブ問合せが残っているか否かを判定する。
ステップ１７０９では、更なるスレーブ問合せが実行される場合、次のスレーブ問合せが処理のために一時テーブルを必要とするか否かを判定する。
ステップ１７１０では、一時テーブルがスレーブにおいて必要とされる場合、一時テーブルがスレーブノードに送信され、ステップ１７０２の処理へ戻る。
なお、一時テーブルが必要とされない場合、次のスレーブ問合せのために、そのままステップ１７０２の処理へ戻る。

図１３に示すように、一旦外部ホストシステムから受信した問い合わせが単一処理又は多重処理のいずれかで実行され処理されると、最終的な結果セットが外部ホストシステムに返される。

本発明のデータベースシステムの各々のマスターノードは、データベースシステムの他のノードの状態を監視するべく、システム管理ソフトウェア３２と接続される。
適切なシステム管理ソフトウェアの一例は、ＩＰＭＩ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｐｌａｔｆｏｒｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｆａｃｅ）及びＩｎｔｅｌのシステムマネージャを含んで構成される。

マスターノードに障害が発生した通知を受信すると、ストリーム管理ソフトウェア２０は、管理コンソール３５に対してマスターノードの障害を知らせるシステムステータスメッセージを送信する。管理コンソール３５は、データベースシステムの状態を調査し、また、システム能力を維持するために修復を必要とする障害が発生したノードを特定するべく、システム管理者によって運用される。一旦管理コンソール３５がマスターノードの障害の通知を受けると、ストリーム管理ソフトウェア２０は、マスターノードのフェールオーバ処理を実行する。

図１８は、データベースシステムのマスターノードで障害が発生したときに、ストリーム管理ソフトウェア２０において実行されるフェールオーバ処理を表すフローチャートである。
図１８で示される処理は、障害が発生したマスターノードによって制御されている各々のストリームに対して実行される。

ステップ１８００では、マスターノードは、当該ストリームが、障害の発生しているマスターノードで制御すべきものか否かを判定する。
本発明の一実施例によれば、この判定は、データベースシステムにより受信された新規のストリームを操作するのに用いられるのと同様の負荷分散方法を用いたデータベースシステムの使用可能なマスターノードの間で行われる。
しかしながら、当業者なら周知の他の方法を、この判定をするのに用いることができる。

ステップ１８０１では、障害が発生したマスターノードで制御すべきものであると判定されたとき、マスターノードは自身がストリームを制御していることを他のマスターノードに通知する。
一旦マスターノードがストリームの制御を引き受けると、当該ストリームからの各々の不完全なステートメントが、マスターノードによって占有される。ステップ１８０２では、不完全なステートメントが、周知のトランザクション管理技術によってロールバックされる。
ステップ１８０３では、ステートメントが再実行される。

このように、障害が発生したマスターノードによって制御される各々のストリームは、データベースシステムの動作を維持するべく、使用可能なマスターノードによって引き継がれる。一旦障害が発生したマスターノードが復旧されるか又は交換されると、データベースシステムからの新規のストリームを処理可能となる。また、データベースシステムの他のマスターノードを監視することに加え、システム管理ソフトウェア３２は、システムの各々のスレーブノードもまた監視する。

図１９は、データベースシステムのスレーブノードに障害が発生したときの処理を表すフローチャートである。
ステップ１９００では、スレーブノードに障害が発生した場合、ストリーム管理ソフトウェア２０に障害が通知される。ストリーム管理ソフトウェアは、さらに、管理コンソール３５を介して、ノード障害についてシステム管理者に通知する。
ステップ１９０１では、障害が発生したスレーブノードに関連する各々の不完全トランザクションについて、ストリーム管理ソフトウェア２０は、不完全トランザクションをロールバックする。

ステップ１９０２では、障害が発生したスレーブノードの代わりに対応するフェールオーバパートナーを用いて、トランザクションを再実行する。
障害が発生したスレーブノードが復旧されているか又は交換されている間、マスターノードは、正規に使用されるスレーブノード及び対応するフェールオーバパートナーの両方において問合せを実行する。従って、データベースシステムの動作は、スレーブノードにおける障害発生にも関わらず、維持される。一旦スレーブノードが復旧又は交換されると、マスターノードは通常の問合せ実行に戻る。

本発明の別の実施例は、多数のスレーブノードを制御するための階層的なマスターノード構成を有するものである。
この構成では、マスターノードによって実行される処理が、パフォーマンスを向上するべく、複数のレイヤに分解される。さらに、スレーブノードレベルにおいて実行される一部の処理は、マスターノードレベルに移されることができる。

他の実施例では、前述したような直接取り付けられた記憶装置の変わりに、データベースのスレーブノードにおける共有の記憶システムを用いる。フェールオーバデータは、共有された記憶装置に格納されることができ、これにより、使用可能なスレーブノードが、障害が発生したノードに対するフェールオーバ動作責務を実現することができるようになる。

前述した超無共有型並列データベースシステムは、従来の無共有型並列データベースシステムに対し、有意義な利点を提供する。
まず、本発明のデータベースシステムは、データベースシステムのパフォーマンスにおける問合せスキュー及び不利益な影響を防ぐことができる。
次に、データベースシステムのスレーブノード全体におけるデータベースの分割及び分散が、自動的に行われる。
これは、システム管理を煩雑にすることなく、システムパフォーマンスを向上する。
また、二層のキャッシュが問合せキャッシュに用いられることにより、同じ問合せを複数回不必要に繰り返すことを防ぐことができる。さらに、ノードに障害が発生した場合であっても、データベースシステムのフェールオーバ処理により、システム動作を維持することができる。

前述の説明は、本発明の好ましい実施例を具体的に説明することを目的とする。しかしながら、記載される実施例は本発明の範囲を制限することを目的とせず、それは、特許請求の範囲からも明らかである。本発明の目的及び範囲から逸脱することなく、実施例に対し様々な変更をなし得ることは当然のことである。

無共有型並列データベースシステムのハードウェアアーキテクチャを表す概要図である。 本発明の一実施形態における超無共有型並列データベースシステムのソフトウエア・アーキテクチャを表す概要図である。 スレーブスキーマを生成するために用いる処理を表すフローチャートである。 ホストスキーマの一例を表す図である。 ホストスキーマのテーブルを順序付ける（ｏｒｄｅｒｉｎｇ）ための処理を表すフローチャートである。 本発明の一実施形態において、データベースのテーブルをデータベースシステムに一括ローディング（ｂｕｌｋ ｌｏａｄｉｎｇ）する処理を表すフローチャートである。 データベーステーブルをデータベースシステムのスレーブノードへロードする処理を表すフローチャートである。 予めソートされたデータを直接スレーブノードへ一括ローディングする処理を表すフローチャートである。 外部のホストシステムから新規のステートメントを受信すると実行される処理を表すフローチャートである。 ＳＱＬステートメントを解析し実行する処理を表すフローチャートである。 データベーステーブルを改変するための処理を表すフローチャートである。 データベーステーブルにデータを更新／登録する処理を表すフローチャートである。 問合せ並列化処理を表すフローチャートである。 単一処理（ｓｉｎｇｌｅ ｓｔｅｐ）の問合せを実行するための処理を表すフローチャートである。 問合せのテーブル名を、スレーブスキーマにおいて用いられるテーブル名に置き換えるための処理を表すフローチャートである。 問合せを実行するスレーブノードで実行される処理を表すフローチャートである。 多重処理の問合せの処理を表すフローチャートである。 マスターノードに障害が発生した場合に実行されるフェールオーバ処理を表すフローチャートである。 スレーブノードに障害が発生した場合は実行されるフェールオーバ処理を表すフローチャートである。

符号の説明

１０ データベースシステム
１１ マスターノード
１２ スレーブノード
１３ ネットワーク
１４ マスターノードの中央演算処理装置（ＣＰＵ）
１５ マスターノードのメモリ（ＲＡＭ）
１６ マスターノードのディスク
１７ スレーブノードの中央演算処理装置（ＣＰＵ）
１８ スレーブノードのメモリ（ＲＡＭ）
１９ スレーブノードのディスク
２０ ストリーム管理ソフトウェア
２１ 問合せキャッシュソフトウェア
２２ ＳＱＬ解析ソフトウェア
２３ スレーブスキーマ生成ソフトウェア
２４ 更新／登録ソフトウェア
２５ 問合せ並列化ソフトウェア
２６ マルチステップ問合せ実行ソフトウェア
２８ 結果セット解析ソフトウェア
２９ 日付分割メンテナンスソフトウェア
３０ 一括ローディングソフトウェア
３１ マスターノードのＤＢＭＳ
３２ システム管理ソフトウェア
３３ スレーブノードのＤＢＭＳ
３４ スレーブ管理ソフトウェア
３５ 管理コンソールソフトウェア

Claims (28)

1. マスターノードと、
   複数のスレーブノードと、
   ファクトテーブル及び複数のディメンションテーブルを含むデータベースを、前記複数のスレーブノードに分散させるための分散手段と
   を備えた並列データベースシステムであって、
   前記分散手段は、
   前記ファクトテーブルと、前記複数のディメンションテーブルのうちの第１ディメンションテーブルとを、前記ファクトテーブル及び前記第１ディメンションテーブルが共通に有する共通キーを使用して分割し、該分割されたファクトテーブルの一部と該分割された第１ディメンションテーブルの一部とを前記複数のスレーブノードに格納し、
   前記複数のディメンションテーブルのうち前記第１のディメンションテーブル以外の全てのディメンションテーブルをそれぞれ複製して、該複製されたディメンションテーブルの各々を前記複数のスレーブノードの各々に格納し、
   前記複数のディメンションテーブルのうち、前記第１のディメンションテーブルおよび最小サイズを有するディメンションテーブル以外の他のディメンションテーブルを分割して、前記他のディメンションテーブルの分割された一部を前記複数のスレーブノードに格納することを特徴とする並列データベースシステム。
2. 前記他のディメンションテーブルは、行分割されることを特徴とする請求項１記載の並列データベースシステム。
3. 前記他のディメンションテーブルは、列分割されることを特徴とする請求項１記載の並列データベースシステム。
4. 前記他のディメンションテーブルは、行分割及び列分割の両方で分割されることを特徴とする請求項１記載の並列データベースシステム。
5. 前記ファクトテーブル及び前記第１ディメンションテーブルは、行分割されることを特徴とする請求項１記載の並列データベースシステム。
6. 前記ファクトテーブル及び前記第１ディメンションテーブルは、前記共通キーでハッシュ分割されることを特徴とする請求項５記載の並列データベースシステム。
7. 前記ファクトテーブル及び前記第１ディメンションテーブルは、さらに列分割されることを特徴とする請求項５記載の並列データベースシステム。
8. 前記ファクトテーブル及び前記複数のディメンションテーブルは、各テーブル内のデータの日付に応じて分割され、前記複数のスレーブノードに格納されることを特徴とする請求項１記載の並列データベースシステム。
9. 前記データベースに対する問合せを、前記複数のスレーブノード間のデータの伝送を必要とせずに前記並列データベースシステムによって実行可能な少なくとも１つの副問合せに変換するための変換手段をさらに備えたことを特徴とする請求項１記載の並列データベースシステム。
10. 前記データベースシステムによって生成された問合せの結果をキャッシュするための手段をさらに備えたことを特徴とする請求項９記載の並列データベースシステム。
11. 前記マスターノードは、該マスターノードにより生成された問合せの結果をキャッシュするための手段を含むことを特徴とする請求項１０記載の並列データベースシステム。
12. 前記複数のスレーブノードはそれぞれ、該スレーブノードによって生成された副問合せの結果をキャッシュするための手段を含むことを特徴とする請求項１１記載の並列データベースシステム。
13. 各スレーブノードに格納された各テーブルの複製は、前記複数のスレーブノードのうち、該スレーブノードのフェールオーバパートナーとして指定された他のスレーブノードに格納されることを特徴とする請求項１記載の並列データベースシステム。
14. 前記複数のスレーブノードのうち障害が発生したスレーブノードによって実行されるべき副問合せは、前記障害が発生したスレーブノードの前記フェールオーバパートナーとして指定された前記他のスレーブノードで実行されることを特徴とする請求項１３記載の並列データベースシステム。
15. マスターノードと複数のスレーブノードとを含む並列データベースシステムにおいて、ファクトテーブル及び複数のディメンションテーブルを備えるデータベースを管理するための方法であって、
    前記マスターノードが、前記データベースの前記ファクトテーブルと前記複数のディメンションテーブルのうちの第１ディメンションテーブルとを識別するステップと、
    前記マスターノードが、前記ファクトテーブルと前記第１ディメンションテーブルとを、前記ファクトテーブル及び前記第１ディメンションテーブルが共通に有する共通キーを使用して分割し、該分割されたファクトテーブルの一部と該分割された第１ディメンションテーブルの一部とを前記複数のスレーブノードに格納させるステップと、
    前記マスターノードが、前記複数のディメンションテーブルのうち前記第１ディメンションテーブル以外の全てのディメンションテーブルをそれぞれ複製して、該複製されたディメンションテーブルの各々を、前記複数のスレーブノードの各々に格納させるステップと、
    前記マスターノードが、前記複数のディメンションテーブルのうち前記第１のディメンションテーブルおよび最小サイズを有するディメンションテーブル以外の他のディメンションテーブルを分割して、前記他のディメンションテーブルの分割された一部を前記複数のスレーブノードに格納させるステップと、
    を含むことを特徴とする方法。
16. 前記他のディメンションテーブルは、行分割されることを特徴とする請求項１５記載の方法。
17. 前記他のディメンションテーブルは、列分割されることを特徴とする請求項１５記載の方法。
18. 前記他のディメンションテーブルは、行分割及び列分割の両方で分割されることを特徴とする請求項１５記載の方法。
19. 前記ファクトテーブル及び前記第１ディメンションテーブルは、行分割されることを特徴とする請求項１５記載の方法。
20. 前記ファクトテーブル及び前記第１ディメンションテーブルは、前記共通キーでハッシュ分割されることを特徴とする請求項１９記載の方法。
21. 前記ファクトテーブル及び前記第１ディメンションテーブルは、さらに列分割されることを特徴とする請求項１９記載の方法。
22. 前記ファクトテーブル及び前記第１ディメンションテーブルを各テーブル内のデータの日付に従って分割して、前記複数のスレーブノードに格納させるステップをさらに含むことを特徴とする請求項１５記載の方法。
23. 前記マスターノードが、前記データベースに対する問合せを、前記複数のスレーブノード間のデータの伝送を必要とせずに前記並行データベースシステムによって実行可能な少なくとも１つの副問合せに変換するステップをさらに含むことを特徴とする請求項１５記載の方法。
24. 前記マスターノードが生成した問合せの結果を該マスターノード内にキャッシュするステップをさらに含むことを特徴とする請求項２３記載の方法。
25. 前記複数のスレーブノードの各々が、前記少なくとも１つの副問合せの結果をキャッシュするステップをさらに含むことを特徴とする請求項２３記載の方法。
26. 各スレーブノードに格納された各テーブルの複製を、前記複数のスレーブノードのうち、該スレーブノードのフェールオーバパートナーとして指定された他のスレーブノードに格納させるステップをさらに含むことを特徴とする請求項１５記載の方法。
27. 前記複数のスレーブノードのうち障害が発生したスレーブノードによって実行される副問合せを、該障害が発生したスレーブノードの前記フェールオーバパートナーとして指定された前記他のスレーブノードが実行するステップをさらに含むことを特徴とする請求項２６記載の方法。
28. 請求項１５乃至２７のいずれかに記載の方法を実行するためのプログラムを記録したことを特徴とするコンピュータ読取可能な記録媒体。

Images