(57)【要約】【課題】ノード間におけるデータ伝送の必要性を大幅に減らし、システムパフォーマンスを向上できる超無共有型並列データベースを提供する。【解決手段】超無共有型並列データベースシステム１０は、少なくとも１つのマスターノード１１及び複数のスレーブノード１２を含んで構成される。また、マスターノード１１は、外部ホストから受信した問合せを並列に実行するべく、データベース１６を、少なくとも１つのファクトテーブルと複数のディメンションテーブルに分割し、スレーブノード１２全体に分散する。また、データベース１６の他のディメンションテーブルは、各々のスレーブノード１２に複製し、さらに、これらのディメンションテーブルのうち少なくとも１つをスレーブノード１２に分割する。【選択図】図１
2007531087.tif 000002
【特許請求の範囲】
【請求項１】
マスターノードと、
複数のスレーブノードと、
ファクトテーブル及び複数のディメンションテーブルを含んで構成されたデータベースを前記複数のスレーブノードに分割及び分散させる分割・分散手段と、
を含んで構成され、
前記分割・分散手段は、
前記ファクトテーブル及び前記複数のディメンションテーブルにおける第１ディメンションテーブルが前記複数のスレーブノードに分割及び分散され、
前記複数のディメンションテーブルにおける他の全てのディメンションテーブルが、前記複数のスレーブノードに複製され、かつ、
前記他のディメンションテーブルにおける最小サイズを有した複数個数のディメンションテーブルまでは、前記複数のスレーブノードに分割及び分散されることを特徴とする並列データベースシステム。
【請求項２】
前記複数個数の他のディメンションテーブルは、行分割されることを特徴とする請求項１記載の並列データベースシステム。
【請求項３】
前記複数個数の他のディメンションテーブルは、列分割されることを特徴とする請求項１記載の並列データベースシステム。
【請求項４】
前記複数個数の他のディメンションテーブルは、行分割及び列分割の両方で分割されることを特徴とする請求項１記載の並列データベースシステム。
【請求項５】
前記ファクトテーブル及び前記第１ディメンションテーブルは、行分割されることを特徴とする請求項１記載の並列データベースシステム。
【請求項６】
前記ファクトテーブル及び前記第１ディメンションテーブルは、共通キーでハッシュ分割されることを特徴とする請求項５記載の並列データベースシステム。
【請求項７】
前記ファクトテーブル及び前記第１ディメンションテーブルは、さらに列分割されることを特徴とする請求項５記載の並列データベースシステム。
【請求項８】
前記データベースのテーブルが、前記複数のスレーブノードに日付分割されることを特徴とする請求項１記載の並列データベースシステム。
【請求項９】
前記分割・分散手段が、前記データベースのテーブルを自動的に前記複数のスレーブノードに分割及び分散させることを特徴とする請求項１記載の並列データベースシステム。
【請求項１０】
前記データベースに対する問合せを、前記スレーブノード間のデータ伝送なしで実行可能な少なくとも１つの副問合せに変換する変換手段をさらに含んで構成されることを特徴とする請求項１記載の並列データベースシステム。
【請求項１１】
生成された問合せ結果をキャッシュとして保存するキャッシュ手段をさらに含んで構成されることを特徴とする請求項１０記載の並列データベースシステム。
【請求項１２】
前記マスターノードは、そのマスターノードにより生成された問合せ結果を保存するキャッシュ手段を包含することを特徴とする請求項１１記載の並列データベースシステム。
【請求項１３】
各々の前記複数のスレーブノードが、そのスレーブノードで生成された副問合せ結果を保存するキャッシュ手段を包含することを特徴とする請求項１２記載の並列データベースシステム。
【請求項１４】
各々の前記複数のスレーブノードについて、各々のスレーブノードに格納されたデータセットの複製が、前記複数のスレーブノードのうち各々のスレーブノードのフェイルオーバパートナーとして指定された他のスレーブノードに格納される構成を具備することを特徴とする請求項１記載の並列データベースシステム。
【請求項１５】
障害が発生した前記スレーブノードにおいて実行される副問合せが、そのスレーブノードの代わりに、そのスレーブノードに対応する前記フェイルオーバパートナーのスレーブノードで実行される構成を具備することを特徴とする請求項１４記載の並列データベースシステム。
【請求項１６】
並列データベースシステムにおけるデータベース管理方法であって、
前記データベースは、ファクトテーブル及び複数のディメンションテーブルを含んで構成され、
前記データベースにおける前記ファクトテーブルと前記複数のディメンションテーブルのうち１つの第１ディメンションテーブルとを識別するステップと、
前記ファクトテーブル及び前記第１ディメンションテーブルを複数のスレーブノードに分割及び分散するステップと、
前記複数のディメンションテーブルのうち前記第１ディメンションテーブル以外の他のディメンションテーブルの各々を、前記複数のスレーブノードに複製するステップと、
前記他のディメンションテーブルのうち最小サイズを有する複数個数のディメンションテーブルまでは、前記複数のスレーブノードに分割及び分散されるステップと、
を含むことを特徴とするデータベース管理方法。
【請求項１７】
前記複数個数の他のディメンションテーブルが、行分割されることを特徴とする請求項１６記載のデータベース管理方法。
【請求項１８】
前記複数個数の他のディメンションテーブルが、列分割されることを特徴とする請求項１６記載のデータベース管理方法。
【請求項１９】
前記複数個数の他のディメンションテーブルが、行分割及び列分割の両方で分割されることを特徴とする請求項１６記載のデータベース管理方法。
【請求項２０】
前記ファクトテーブル及び前記第１ディメンションテーブルが、行分割されることを特徴とする請求項１６記載のデータベース管理方法。
【請求項２１】
前記ファクトテーブル及び前記第１ディメンションテーブルが、共通キーでハッシュ分割されることを特徴とする請求項２０記載のデータベース管理方法。
【請求項２２】
前記ファクトテーブル及び前記第１ディメンションテーブルが、さらに列分割されることを特徴とする請求項２０記載のデータベース管理方法。
【請求項２３】
前記データベースのテーブルが、前記複数のスレーブノードに日付分割されることを特徴とする請求項１６記載のデータベース管理方法。
【請求項２４】
前記データベースに対する問合せを、前記スレーブノード間のデータ伝送なしで実行可能な少なくとも１つの副問合せに変換するステップをさらに含むことを特徴とする請求項１６記載のデータベース管理方法。
【請求項２５】
前記マスターノードにおいて、生成された問合せ結果をキャッシュとして保存するステップをさらに含むことを特徴とする請求項２４記載のデータベース管理方法。
【請求項２６】
各々の前記スレーブノードにおいて、少なくとも１つの副問合せの結果をキャッシュに保存するステップをさらに含むことを特徴とする請求項２４記載のデータベース管理方法。
【請求項２７】
各々の前記スレーブノードのデータセットの複製が、前記複数のスレーブノードのうち各々のスレーブノードのフェイルオーバパートナーとして指定された他のスレーブノードに格納されるステップをさらに含むことを特徴とする請求項１６記載のデータベース管理方法。
【請求項２８】
障害が発生した前記スレーブノードにおいて実行される副問合せが、そのスレーブノードの代わりに、そのスレーブノードに対応する前記フェイルオーバパートナーのスレーブノードで実行されるステップをさらに含むことを特徴とする請求項２７記載のデータベース管理方法。
【請求項２９】
並列データベースシステムにおけるデータベース制御プログラムが格納されたコンピュータ読取可能な記録媒体であって、
前記データベースは、ファクトテーブル及び複数のディメンションテーブルを含んで構成され、
前記データベース制御プログラムは、
データベースにおいて前記ファクトテーブルおよび前記複数のディメンションテーブルのうち１つの第１ディメンションテーブルを識別するステップと、
前記ファクトテーブル及び前記第１ディメンションテーブルを複数のスレーブノードに分割及び分散するステップと、
前記複数のディメンションテーブルのうち前記第１ディメンションテーブル以外の他のディメンションテーブルの各々を、前記複数のスレーブノードに複製するステップと、
前記他のディメンションテーブルのうち最小サイズを有する複数個数のディメンションテーブルまでは、前記複数のスレーブノードに分割及び分散するステップと、
をコンピュータに実現させることを特徴とするコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、並列データベースシステム（ｐａｒａｌｌｅｌ  ｄａｔａｂａｓｅ  ｓｙｓｔｅｍ）に関するものであり、特に、無共有型（ｓｈａｒｅｄ−ｎｏｔｈｉｎｇ）並列データベースシステムに関する。
【背景技術】
【０００２】  無共有型のアーキテクチャを用いて設計される並列データベースシステムは、プロセッサ、メモリ及びディスク資源を各々有する複数ノードから構成される。これらのシステムでは、データベースのテーブルは、システムの全ノードに亘って分散される。また、データベースに対する問合せ（Ｑｕｅｒｙ）は、同時に、複数ノードにおいて並列して実行される。無共有型並列データベースシステムは、システムにおけるノード数の増加によりパフォーマンスを向上させ、より大きなデータセットの処理を可能にするリニアスケーリング（ｌｉｎｅａｒ  ｓｃａｌｉｎｇ）を提供することを目的とするものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】  しかしながら、従来の設計では、例えば問合せスキューのような問題により、リニアスケーリングが提供できていない。問合せスキューは、同じデータベースに対する複雑さのレベルが類似した２つの異なる問合せが、全く異なる実行時間を要したときに発生する。【０００４】  従来の無共有型並列データベースシステムにおいて、問合せスキューは、他の問合せがほとんど又は全くデータ伝送をしていない間に、特定の問合せの処理をするノード間で大量のデータを伝送しなければならないことが原因で発生する。従来のシステムにおいて、このデータ転送は、問合せ処理を減速させ、障害（ボトルネック）を発生させる原因となっている。【０００５】  例えば、４つのノードを有する従来のシステムにおいて、データベーステーブルは多くの場合、各々のノードに各テーブルの４分の１ずつが格納されるようにして等しく分散される。そして、典型的なデータベースの問合せは、１つのテーブルの主キーと他のテーブルの外部キーとの整合性（マッチング）を検索してそれぞれのデータベーステーブルをスキャンする一つ以上の「結合」を含む。【０００６】  ２つのデータベーステーブルの結合を処理するために、各々のノードは、他のノードにデータベーステーブルのうちの１つの一部を伝送しなければならない。
このデータ伝送は、どのデータベーステーブルが結合されているか、また、問合せにどれ位の数の結合が含まれているかにより、相当な時間を要する可能性があり、よって問合せ処理を遅延させることになる。【０００７】  データセットが大きくなり、問合せセッションの数が増えるにつれて、問合せスキューはますますシステムパフォーマンスを悪化させる。
この問題の本質に鑑みると、更なる追加ノードをこれらの従来システムに組み込んでも、問合せ処理におけるこの障害を解消することにはならない。
従って、問合せスキューを低減することが可能な、改良された無共有型の並列データベースシステムが求められている。【０００８】  さらに、改良されたシステムは、システムを運用するのに必要な管理費用を最小限にしつつ、安全確実なフェールオーバ保護（ｆａｉｌｏｖｅｒ  ｐｒｏｔｅｃｔｉｏｎ）を提供しなければならない。【０００９】  そこで、本発明は、超無共有型並列データベースシステム（ｕｌｔｒａ−ｓｈａｒｅｄ−ｎｏｔｈｉｎｇ  ｐａｒａｌｌｅｌ  ｄａｔａｂａｓｅ  ｓｙｓｔｅｍ）を提供することで、前述した従来の無共有型のデータベースシステムにおける問題を解決することを目的とする。
【課題を解決するための手段】
【００１０】  本発明の超無共有型並列データベースシステムは、従来技術と同じ量のデータがノード間を伝送される必要なく、データベースの問合せが並列に処理されることを可能にする方法で、データベースのテーブルを、複数のスレーブノード（ｓｌａｖｅ  ｎｏｄｅ）に分割し、分散する。データベースは、データベーススキーマの構造及びテーブルの相対的（ｒｅｌａｔｉｖｅ）な大きさに関連したルールセットに従って分散される。【００１１】  本発明は、ノード間におけるデータ伝送の必要性を大幅に減らすことにより、ネットワークトラフィック及び結果として生じる問合せスキューを減らすことで、システムパフォーマンスを大きく改善する。【００１２】  具体的には、ある特定のデータベースに関し、ファクトテーブル（ｆａｃｔ  ｔａｂｌｅ）と、ディメンションテーブル（ｄｉｍｅｎｓｉｏｎ  ｔａｂｌｅ）のうちの１つと、が共通キーで分割され、複数のスレーブノードに分散される。ここで、該データベースにおける小さなディメンションテーブルは、システムのスレーブノード全てに複製される。さらに、残りのディメンションテーブルは、複数スレーブノードの全般に亘って分割され、且つ、全スレーブノードに複製される。これにより、スレーブノード間又はマスターノードとスレーブノードとの間に大きなネットワークトラフィックを生じさせずに、データベースシステムにおいて多数の問合せが実行可能となる。【００１３】  本発明の一形態によれば、マスターノードおよび複数のスレーブノードを含んだ並列データベースシステムが提供される。
ファクトテーブルと複数のディメンションテーブルとを含んだデータベースは、データベースシステムのスレーブノードに分散される。データベースのテーブルを分散するために、ファクトテーブル及び第１ディメンションテーブル（ｆｉｒｓｔ  ｄｉｍｅｎｓｉｏｎ  ｔａｂｌｅ）がスレーブノードに分割される。さらに、残ったディメンションテーブルが、各々のスレーブノードに複製され、それらが最小サイズである場合には、さらに全スレーブノードに亘って分割される。【００１４】  好ましくは、ファクトテーブル及び第１ディメンションテーブルは、共通キーで分割されることが望ましい。
また、残りのディメンジョンテーブルは、必要に応じて行分割又は列分割され、システムの複数スレーブノードに亘って分散される。【００１５】  さらに、データベースに対する問合せは、並列データベースシステムのスレーブノードによって該スレーブノード間のデータ伝送なしで実行可能な、少なくとも１つの副問合せ（ｓｕｂ−ｑｕｅｒｙ）に変換される。【００１６】  本発明の別の態様では、並列データベースシステムは、データベースシステムにより生成された問合せ結果をキャッシュに格納する。
好ましくは、マスターノードは、該マスターノードにより生成された問合せ結果を格納するための問合せキャッシュを含み、スレーブノードはその各々が、夫々の該スレーブノードにより生成された副問合せ結果を格納するための問合せキャッシュを含むことが望ましい。【００１７】  本発明の別の態様では、データベースシステムの各々のスレーブノードには少なくとも１つのフェールオーバパートナー（ｆａｉｌｏｖｅｒ  ｐａｒｔｎｅｒ）が割り当てられる。また、各々のフェールオーバパートナーは、それ自身のテーブルに加え、そのフェールオーバパートナーのデータセットのうち、全て又は一部のデータセットを格納する。
さらに、スレーブノードに障害が発生した場合には、障害が発生したスレーブノードに向けられた副問合せが、障害が発生したスレーブノードの代わりにフェールオーバパートナーにより実行される。
【発明の効果】
【００１８】  以上に要約した本発明によれば、有用で信頼性の高い並列データベースシステムが提供される。
まず、問合せスキューがデータベースの問合せ処理から無くなることで、データベースシステムのリニアスケーリングに近い状態が可能になる。また、二層の問合せキャッシュにより、問合せにおける配下のテーブルに対する変更を介入させることなく、反復的な問合せ処理が低減される。さらに、スレーブノードにおけるフェールオーバパートナーの運用により、ノードに障害が発生したときにおいても継続した使用を可能とする、費用効率の良いソリューションを提供する。
前述した本発明の概要は、本発明の本質を迅速に理解可能にするべく提供されたものである。
本発明の好ましい実施態様に関しては、以下の発明の詳細な説明及び関連した図面を参照することにより、さらに詳細且つ完全に理解されるであろう。
【発明を実施するための最良の形態】
【００１９】  本発明は、超無共有型並列データベースシステムと呼称される、改良された無共有型並列データベースシステムである。
超無共有型並列データベースシステムは、少なくとも１つのマスターノード及び複数のスレーブノードを用いた従来の無共有型並列データベースに準じた方法で構成される。【００２０】  図１は、超無共有型データベースシステムの一実施形態のハードウェアアーキテクチャを表す概要図である。
図１はデータベースシステム１０の構成を表し、マスターノード１１、複数のスレーブノード１２ａから１２ｎまで（図示を簡略化するためこのように記述する）を示す。なお、図１では、マスターノードを１つだけ含む。しかしながら、詳細に後述するように、本発明の他の実施形態では、複数のマスターノード１１を、データベースシステム１０に組み込む。マスターノード１１及びスレーブノード１２ａから１２ｎは、ネットワーク１３を介して相互接続される。【００２１】  好ましくは、ネットワーク１３はデータベースシステム１０の信頼性を改善するために用いられる冗長或は二重ネットワーク（ｒｅｄｕｎｄａｎｔ  ｎｅｔｗｏｒｋ）であることが望ましい。あるいは、重要でないアプリケーションであれば、非冗長なネットワーク（ｎｏｎ−ｒｅｄｕｎｄａｎｔ  ｎｅｔｗｏｒｋ）が用いられても良い。
ネットワーク１３は、当業者にとって周知の多数のネットワーク技術及びプロトコルのうちのいずれか用いて実装される。実施形態におけるネットワークは、イーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）で用いられるＴＣＰ／ＩＰ、及び、インフィニバンド（Ｉｎｆｉｎｉｂａｎｄ）で用いられるＭＰＩ（Ｍｅｓｓａｇｅ  Ｐａｓｓｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を含むが、これに限定されるものではない。【００２２】  データベースシステム１０の各ノードは、プロセッサ、メモリ及びディスク資源を含んで構成される。具体的には、マスターノード１１は、中央演算処理装置（ＣＰＵ）１４、メモリ（ＲＡＭ）１５及びディスク１６を含んで構成される。
スレーブノード１２ａからスレーブノード１２ｎは、各々、ＣＰＵ１２ａからＣＰＵ１７ｎ、ＲＡＭ１８ａからＲＡＭ１８ｎ、及び、ディスク１９ａからディスク１９ｎを含んで構成される。【００２３】  各ＣＰＵは、各ディスクに格納されたソフトウェアモジュールのプログラム命令を実行する。各ＣＰＵは、命令シーケンスをロードし、また、データを格納して操作するためのワークスペースとしてＲＡＭを使用する。
各々のノードは単一のＣＰＵ及び単一のディスクを含んで構成されたものとして表されているが、当業者であれば、各々のノードが、処理能力を改善するべく複数のＣＰＵ及び複数のディスクを含んで構成され得ることが理解できるはずである。例えば、本発明の１つの実施形態として、デュアル・プロセッサ及び１２台のハードディスクを用いたノードを用いる。
基本ソフトウェアコンポーネント（例えばオペレーティングシステム及びデバイスドライバ）に加えて、データベースシステム１０の各ノードは、本発明を履行するためのソフトウェアモジュールを格納し、実行する。【００２４】  図２は、データベースシステム１０のソフトウエア・アーキテクチャを表す概要図である。
マスターノード１１は、ストリーム管理ソフトウェア２０、問合せキャッシュソフトウェア２１、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）解析ソフトウェア２２、スレーブスキーマ生成ソフトウェア２３、更新／登録ソフトウェア２４、問合せ並列化／最適化ソフトウェア２５、マルチステップ問合せ実行ソフトウェア２６、結果セット解析ソフトウェア２８、日付分割メンテナンスソフトウェア２９、一括ローディングソフトウェア３０、ＤＢＭＳ（Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）３１及びシステム管理ソフトウェア３２を含んで構成される。【００２５】  複数のマスターノードを用いる実施形態においては、各マスターノードが前述したソフトウェアモジュールを含んで構成される。
各スレーブノードは、ＤＢＭＳ３３ａ〜３３ｎ及びスレーブ管理ソフトウェア３４ａ〜３４ｎを含んで構成される。
最後に、管理コンソールソフトウェア３５は、少なくとも１つのマスターノードにインストールされ、マスターノードに接続された端末又はデータベースシステム１０から分離したコンピュータシステムで実行されるクライアントプログラムを介してアクセスすることができる。【００２６】  前述のソフトウェアモジュールは、データベースシステムのノードの各ディスクに格納され、それらのノードの各ＣＰＵによって実行される。
好ましい実施例では、全てのノードが同一のハードウェア構成を備え、各ノードの適切なソフトウェアモジュールをロードし実行することで、マスターノード又はスレーブノードのいずれかとして機能することができる。【００２７】  本発明の一実施例によれば、ソフトウェアモジュールはＪＡＶＡ（登録商標）プログラミング言語を用いて遂行される。しかしながら、当業者ならば１つ又は複数のソフトウェアモジュールを遂行するのに他のプログラミング言語を用いることが可能であることは、理解できるであろう。
これらのソフトウェアモジュールの処理については、以下の本発明の処理の説明において詳細に説明する。【００２８】  従来の無共有型並列データベースに対する本発明の重要な改良点は、結合などのデータベース問い合せを実行するためにノード間でデータを伝送する必要性を大幅に低減することにある。この改良は、データベースシステム１０の全スレーブノードに、データベースのテーブルを自動的に分割及び分散するルールセットを用いることで達成される。データベースのテーブルの分割及び分散は、生成されたスレーブスキーマに従って実行される。
外部のホストシステムは、データベースシステム１０に対し、ホストスキーマを定義するメタデータを伝送する。【００２９】  ストリーム管理ソフトウェア２０は、メタデータを含んだストリームを受信し、受信したメタデータをＤＢＭＳ３１に伝送する。伝送されたホストスキーマに対するスレーブスキーマを生成するべく、ＤＢＭＳ３１は、ホストスキーマのメタデータをスレーブスキーマ生成ソフト２３に伝送する。
ホストスキーマを受信すると、スレーブスキーマ生成ソフト２３は、スレーブスキーマを生成するルールセットを適用する。スレーブスキーマは、データベースのテーブルがスレーブノード１２ａから１２ｎにどのように分割及び分散されるかについて定義する。【００３０】  図３は、本発明の一実施例に従って、スレーブスキーマを生成するスレーブスキーマ生成ソフトウェア２３によって実行される処理を表すフローチャートである。
図３に示すステップはスレーブスキーマを生成するのに用いられるルールセットを具体的に表す。【００３１】  ステップ３００（図ではＳ３００と示す。以下同じ）では、スレーブスキーマ生成ソフトウェア２３が、データベース１０に接続された外部ホストシステムから出力されたホストスキーマを受信する。このホストスキーマは、正規化されたスキーマとして、スタースキーマやスノーフレークスキーマを含むことができるが、これに限定されるものではない。【００３２】  図４は、トランザクション処理評議会（Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｃｏｕｎｃｉｌ）により作成された、データベースシステム用の標準的な指標（ｂｅｎｃｈｍａｒｋ）として用いられるスノーフレークスキーマの一例である。
このスキーマは、１つのファクトテーブル（「ＬＩＮＥＩＴＥＭ」）及び複数のディメンションテーブル（「ＯＲＤＥＲＳ」、「ＣＵＳＴＯＭＥＲ」、「ＰＡＲＴ」、「ＰＡＲＴＳＵＰＰ」、「ＳＵＰＰＬＩＥＲ」、「ＮＡＴＩＯＮ」及び「ＲＥＧＩＯＮ」）を含んで構成される。【００３３】  ファクトテーブルは、それが親である場合に、他のテーブルと親子関係を持たないテーブルとして定義される。ディメンジョンテーブルは、それが親である場合に、他のテーブルと親子関係を持つテーブルとして定義される。
図４において示されるスキーマは１つのファクトテーブルのみを含むが、データベースのスキーマは複数のファクトテーブルを含み得ることが理解できるであろう。
ステップ３０１では、ホストスキーマのテーブルが、スレーブスキーマの生成に備えて並び替えられる（ｏｒｄｅｒｅｄ）。【００３４】  図５は、ホストスキーマのテーブルを並び替えるための処理を表すフローチャートである。
ステップ５００では、ホストスキーマ内の全てのファクトテーブルが識別される。
ステップ５０１では、各々の識別されたファクトテーブルについて、ホストスキーマにおいて定義されたテーブルのリレーションシップが、ファクトテーブルから第１ディメンジョンテーブルへと、内から外へ順に識別される。
ステップ５０２では、他の関連ディメンジョンテーブルを並び替える。なお、ディメンジョンテーブルは、ファクトテーブルに対する位置及び関係に基づいて並び替えられる。【００３５】  図４で示されるホストスキーマを参照して説明すると、まず、「ＬＩＮＥＩＴＥＭ」テーブルは、ホストスキーマにおける唯一のファクトテーブルとして認識される。
次に、「ＬＩＮＥＩＴＥＭ」テーブルから順に外へ向かい、「ＯＲＤＥＲＳ」、「ＰＡＲＴ」、「ＰＡＲＴＳＵＰＰ」、「ＳＵＰＰＬＩＥＲ」テーブルが、「ＬＩＮＥＩＴＥＭ」テーブルと直接の関係を持つテーブルとして認識される。
このテーブルの第１階層は、例えばサイズなどの指定された基準に基づいて並び替えられる。この第１階層において並べ替えられた１番目のテーブル（例えば「ＯＲＤＥＲ」テーブル）は、第１ディメンションテーブルとして認識される。【００３６】  テーブルのリレーションシップ及び指定された並べ替え基準を用いて、残りのディメンションテーブルが並び替えられる。
ここで、並列データベースシステムを用いた問合せを効率的に処理するために、サイズが大きく、また、頻繁にアクセスされるテーブルであるほど、全スレーブノードに出来る限り均等且つ効率的に割り当てられなければならない。
この点に関し、本発明は従来の無共有型データベースシステムにおいて用いられた方法に順ずる方法を採用する。【００３７】  具体的には、本発明は、ファクトテーブル及び第１ディメンションテーブルを、共通キーでハッシュ分割する。これらのテーブルにおける共通キーを用いたハッシュ分割により、所定のキー値が各々のノードに割り振られ、２つのテーブルを結合する問合せは、スレーブノード間におけるデータ伝送なしで処理され得る。【００３８】  図３のステップ３０２では、対になったファクトテーブル及び第１ディメンションテーブルごとに、ハッシュキーを記録する。
ここで再び図４に示すホストスキーマを再度、参照すると、ＯＲＤＥＲＫＥＹが、ＯＲＤＥＲＳテーブル（第１ディメンションテーブル）のプライマリキーであり且つＬＩＮＥＩＴＥＭテーブル（ファクトテーブル）の外部キーであるため、ハッシュキーとして記録される。【００３９】  一旦データベーステーブルが並び替えられ（ＯＲＤＥＲＥＤ）、ハッシュキーが記録されると、スレーブスキーマ生成処理は、スレーブスキーマを生成可能な状態となる。そして、ホストスキーマの各テーブルが調査され（ＥＸＡＭＩＮＥＤ）、スレーブスキーマに、１つ又は複数の対応したテーブルが生成される。
図３のステップ３０３では、処理中のテーブルについて、それがファクトテーブルか、第１ディメンションテーブルかの判定が成される。
各々のファクトテーブル及びディメンションテーブルは、水平分割され（ｈｏｒｉｚｏｎｔａｌｌｙ  ｐａｒｔｉｔｉｏｎｅｄ）、全スレーブノードに対して分散される。
このように、各々のスレーブノードは、ホストスキーマの各々のファクトテーブル及び各々の第１ディメンションテーブルの水平分割された一部分を割り当てられる。【００４０】  ところで、通常のデータベースでは、テーブルは相当量のテキストを含む。このテキストは、通常はテーブルのコメントフィールドに存在する。
本発明の付加的な特徴は、これらの大きなコメントフィールドを削除してスレーブスキーマの分割テーブル内に移すために、テーブルを垂直分割することである。
２つのテーブルの行を正確に同じ順序に保つため、個々の行のコメントフィールドが、行識別子を用いることで識別される。
垂直分割機能は、デフォルトルールとして設定されるか、システム管理者からの入力によって設定される。【００４１】  ステップ３０４では、テーブルを垂直分割するか否かが判定される。
ステップ３０５では、垂直分割しない場合に、スレーブスキーマに水平分割されたテーブルが生成される。
ステップ３０６では、垂直分割する場合に、スレーブスキーマに垂直分割されたテーブルのセットが生成される。なお、これらの垂直分割されたテーブルは、水平分割されたテーブルの垂直分割であり、ステップ３０５で生成された水平分割されたテーブルと同じセットとしてのものである。
本発明の好ましい実施例によれば、ファクトテーブル及び第１ディメンションテーブルの他の各々のテーブルが完全に複製され、各々のスレーブノードに格納される。【００４２】  ステップ３０７では、調査されたテーブルがファクトテーブル又は第１ディメンションテーブルでない場合（以下、かかるテーブルを外部ディメンションテーブルという）に、完全な（ＦＵＬＬ）テーブルが、スレーブスキーマに生成される。
各々のスレーブノードに、各々の外部ディメンションテーブルを完全に複製することで、外部ディメンションテーブルと、ファクトテーブル又は第１ディメンションテーブルと、の間の結合を含む問合せなどが、スレーブノード間におけるテーブルデータの伝送を必要とせずに、並列に実行される。【００４３】  各々の外部ディメンションテーブルの完全な複製に加え、本発明の好ましい実施例では、必要に応じて、全スレーブノードに亘って、外部ディメンションテーブルを分割及び分散する。
該スレーブノードに、外部ディメンションテーブルの完全な複製及び外部ディメンションテーブルの分割された一部を有することで、問合せを最適化し、最高のシステムパフォーマンスを生むようにスレーブノードのテーブル参照を行うようにすることができる。【００４４】  しかしながら、一部の（ｃｅｒｔａｉｎ）データベーステーブルは、十分なパフォーマンスを産しないことから更なる処理や格納空間を必要することを正当化することもある。
例えば、比較的小さなデータベースを全スレーブノードに分割及び分散することは、に十分なパフォーマンスを供しない可能性もある。
従って、本発明の実施形態の１つは、例えばこのような所定のサイズより小さい一部の外部ディメンションテーブルについては、分割を行わないという分割オプションが、デフォルトルールとして又はシステム管理者による入力によって設定されるものである。【００４５】  ステップ３０８では、処理中のテーブルを分割するか否かを判定する。
ステップ３０９では、分割オプションが設定されていない場合又はテーブルが分割基準を満たしていない場合に、テーブルを垂直分割するか否かを判定する。
ステップ３１０では、垂直分割しない場合に、水平分割されたテーブルが、スレーブスキーマに生成される。
ステップ３１１では、垂直分割する場合に、垂直分割されたテーブルが、スレーブスキーマに生成される。
なお、これらの垂直分割されたテーブルは、水平分割されたテーブルを垂直分割したものであり、セットとしては、ステップ３１０で生成された水平分割されたテーブルと同じものである。【００４６】  ステップ３１２では、ひとたびホストスキーマの全てのテーブルが調査され、適切な関連テーブルがスレーブスキーマに生成されると、生成されたスレーブスキーマはＤＢＭＳ３１に格納され、各々のスレーブノードに伝送される。
スレーブスキーマは、マスターノード及びスレーブノードにより、データベーステーブルをデータベースシステムにロードし、分割するために用いられる。
個々のデータベースのデータは、マスターノードの中の１つ又は一括ローディング専用のノードのいずれかを介して、本発明のデータベースシステムに一括ローディングされる。【００４７】  図６は、データベースシステムへのデータの一括ローディングの処理を表すフローチャートである。
ステップ６０１では、ロードされた各々のテーブルについて、関連するテーブルの適切なロックを設定することにより、スレーブノードがデータを受信する準備をする。【００４８】  ステップ６０２では、全スレーブノードに対し、各々のテーブルのデータを伝送する。
好ましくは、データは、ノード間のネットワークによりマルチキャスティング機能を介してスレーブノードに伝送される。
ステップ６０３では、スレーブノードによって受信されたテーブルが、スレーブスキーマに基づいて分割される。【００４９】  図７は、スレーブノードのテーブルをロード及び分割する処理を表すフローチャートである。
スレーブ管理ソフト３４は、個々のスレーブノードのテーブルをロード及び分割するべく、テーブルの各行を調査する。
ステップ７００では、テーブルが全てロードされるか否かが判定される。全てロードされる場合には、各行が適切なテーブルへロードされる。【００５０】  ステップ７０２では、分割された構成（Ｆｏｒｍ）を保持するか否かが判定される。
ステップ７０３では、分割された構成が保持される場合に、個々のスレーブノードの分割されたテーブルに行が含まれているか否かを判定するべく、各行が調査される。
ここで、各々のスレーブノードは、分割されたテーブルの行の一意な一部が割り当てられることに留意する。【００５１】  テーブル分割は、テーブルの行を分割及び分散する周知のアルゴリズムのいずれかを用いて行われる。好ましくは、テーブルはスレーブノードに均等に分割されると良い。
テーブルの行を分割するのに用いるアルゴリズムに基づき、個々のスレーブノードに調査された列を割り当てるか否かが判定される。【００５２】  本発明の付加的な特徴は、データを分割及び分散するのに、日付分割を用いることである。
日付分割では、データベーステーブルは、データに含まれる基準となる日付に基づいて分割され分散される。その日付は、予め設定されたルールを用いて設定されるか、又はシステム管理者による入力によってコントロールされる。例えば、個々の年、四半期又は月の間のデータが、異なるスレーブノードに格納されることができる。【００５３】  これらの日付分割されたテーブルが格納され、日付に基づいたデータベース問合せに用いられる。日付分割されたテーブルは、基準となる日付の範囲に該当しないデータを除外するべく常に保持される。なお、好ましくは、日付分割されたテーブルは、日付分割専用のスレーブノードに格納されると良い。
しかしながら、日付分割されたテーブルは、他の分割された又は分割されていないテーブルとともに、通常のスレーブノードに格納されることも可能である。【００５４】  ステップ７０４では、個々のスレーブノードが日付分割されたスレーブノードであるかを判定する。
ステップ７０５では、日付分割されたスレーブノードである場合に、調査された行がそのスレーブノードによって格納される日付範囲に該当するかどうかが判定される。
ステップ７０６では、スレーブノードが日付分割されたスレーブノードであり、且つ、行が基準となる日付の範囲に該当する場合、行がスレーブスキーマに基づいて垂直分割されるか否かが判定される。【００５５】  ステップ７０７では、垂直分割された行について、行が垂直に分割されたテーブルの適切なセットに書き込まれる。
ステップ７０８では、行が垂直分割されない場合、行が適切な水平分割されたテーブルに書き込まれる。
本発明の付加的な特徴は、周知の分割アルゴリズムのいずれかを用いて、スレーブノードにおける更なるレベルのテーブル分割を行う方法である。
例えば、テーブルはハッシュ値または日付範囲によって分割されることができる。【００５６】  本発明のデータベースシステムはまた、フェールオーバ保護を提供するように設計されている。
このプロテクトを実行するために、スレーブノードは、フェールオーバパートナーを割り当てられる。各々のスレーブノードは、それ自身が有する分割されたテーブルに加え、フェールオーバパートナーが有する分割されたテーブルをも格納し、関連したテーブルをアップデートするために、前述したような同じアルゴリズムを用いる。【００５７】  このフェールオーバシステムを用いることにより、各々のノードにおいてミラーリング又はパリティに基づいたディスクアレイを運用しなくても、高い信頼性が提供される。
このことにより、ＲＡＩＤ０のディスクシステムが高いパフォーマンスを提供するべく用いられることが可能であり、高いレベルのＲＡＩＤシステムに伴う大きなコストを必要としないことから、実装コストを低減させることができる。【００５８】  ステップ７０９では、調査された行が、スレーブノードの日付分割されたテーブルの日付の範囲に該当しない場合、又は、スレーブノードが日付分割されたテーブルを格納していない場合、行がスレーブノードに垂直分割されるか否かが判定される。
ステップ７１０では、行が垂直分割される場合、それが垂直分割されたテーブルの適切なセットに書き込まれる。
ステップ７１１では、行がスレーブノードの水平分割されたテーブルの一部であるか否かが判定される。【００５９】  ステップ７１２では、行が水平分割されたテーブルの一部である場合、その行がそのテーブルに書き込まれる。
ステップ７１３では、一旦個々のテーブルの行の全てがデータベースに追加されると、影響を受けるさまざまな物理テーブルのインデックスがアップデートされる。【００６０】  本発明の他のパフォーマンスを高める特徴は、問合せキャッシュ及び一時テーブルキャッシュを用いることである。
問合せキャッシュは、各々のマスターノードのＤＢＭＳ３１及び各々のスレーブノードのＤＢＭＳ３３に格納され、保持される。問合せキャッシュは、個々のノードにおいて実行される問合せに対する問合せ結果を格納する。【００６１】  一時テーブルキャッシュは、多重処理（ｍｕｌｔｉ−ｓｔｅｐ）の問合せを実行するときにマスターノードによって生成される一時テーブルを格納するために、各々のマスターノードのＤＢＭＳ３１に格納され、保持される。
テーブルがデータベースシステムにロードされるときに、問合せキャッシュ、及び、テーブルの前のバージョン（版）に基づいて生成された結果を含む一時テーブルキャッシュは、初期化されなければならない。
ステップ６０４では、これに従い、関連した問合せキャッシュ及び一時テーブルキャッシュは存在しない。
これらのキャッシュの処理に関するより詳細な説明は、後述する。【００６２】  以上、テーブルのソート及び分割により、データベースシステムにテーブルを一括ローディングするのに用いられる、様々な処理について詳述した。
データをデータベースシステムへロードするための付加的な処理は、生成されたスレーブスキーマ及びデータ分散に影響するシステム設定へアクセスする外部ホストシステムを用いて、データを、予めソートすることである。予めソートされたデータは、マスターノードを迂回し、直接スレーブノードにロードされることが可能である。【００６３】  図８は、予めソートされたデータを一括ローディングする処理を表すフローチャートである。
図８に示すように、各々のテーブル及び各々の予めソートされたデータの分割データは、調査され、適切なスレーブノードにロードされる。
ステップ８００では、スレーブノードに全て格納された各々のテーブルについて、全てのスレーブノードが、テーブルを一括ローディングできる状態にされる。
ステップ８０１では、全てのテーブル内容が、全てのスレーブノードに伝送される。【００６４】  ステップ８０２では、ソートされたデータの各々の分割データについて、スレーブノードの割り当てられたフェールオーバセットは、分割データをロードできる状態にされる。
ステップ８０３では、分割データはフェールオーバセットに伝送される。
ステップ８０４では、最後に、適切な問合せキャッシュ及び一時テーブルキャッシュが初期化される。【００６５】  本発明の一実施例によれば、外部のホストシステムは、ＳＱＬステートメントを用いてデータベースシステムと通信する。
ＳＱＬステートメントは一般的に、ホストシステムによって各々のストリームに分けられ、各々のストリームは個々のユーザ又はアプリケーションに対応する。ＳＱＬステートメントを編成するためにストリームを用いることにより、ステートメントが、データベースシステムによって正しい順序で実行されることが確実となる。
データベースシステムによって受信されるＳＱＬステートメントのストリームは、各々のマスターノードのストリーム管理ソフトウェア２０によって管理される。【００６６】  図９は、外部のホストシステムから新規のステートメントを受信したときに、ストリーム管理ソフトウェア２０によって実行される処理を表すフローチャートである。
前述のように、本発明のデータベースシステムは、１つ以上の個数のマスターノードを有する。
外部のホストシステムによって送信されるＳＱＬステートメントは、各々のマスターノードによって受信され、図９に記載されている方法で処理される。【００６７】  ステップ９０１では、各々のマスターノードのストリーム管理ソフトウェア２０において、受信したステートメントが、新規のストリームの開始又は既にデータベースシステムによって処理されている既存のストリームの一部であるか否かを判定する。
ステップ９０２では、ステートメントが新規のストリームの開始である場合、ストリーム管理ソフトウェア２０は、ストリームを当該マスターノードにおいて制御するべきか否かを判定する。【００６８】  各々のストリームは、データベースシステムの１つのマスターノードによって制御される。各々のマスターノードのストリーム管理ソフトウェア２０は、どのマスターノードが生成されたストリームを制御するかについて決定するべく、他のマスターノードと通信する。ストリーム制御は、多数ある周知のロード・バランシング・アルゴリズムのいずれかを用いて決定される。
ステップ９０３では、ステップ９０２において当該マスターノードがストリームを制御すると判定された場合、ストリーム管理ソフトウェア２０は、当該マスターノードがストリームを制御することを、他のマスターノードに通知する。【００６９】  ステップ９０４では、各々のステートメントがマスターノードによって受信されたとき、各々のマスターノードの問合せキャッシュソフトウェア２１は、ステートメントとマスターノードの問合せキャッシュとを比較する。前述したように、各々のマスターノードは、問合せキャッシュに、以前の問合せの結果を格納している。
ステップ９０４において、同一のステートメントが、マスターノードにより配下のテーブルに対する更新において以前に処理されたかどうかを判定するべく、ステートメントが問合せキャッシュと比較される。【００７０】  ステップ９０５では、同一のステートメントがすでに処理された場合、そのステートメントに対応する結果セットが問合せキャッシュから検索されて、問合せストリームを制御する外部のホストシステム又はマスターノードに送信される。そして、マスターノードによるステートメントの処理は終了する。
ステップ９０６では、ステートメントが問合せキャッシュで見つからない場合、受信したステートメントが当該マスターノードによって制御されるストリームの一部であるか否かが判定される。【００７１】  ステップ９０７では、マスターノードがそのストリームを制御する場合、ステートメントがＳＱＬ解析ソフトウェア２２よって処理される。
ステートメントが当該マスターノードによって制御されるストリームの一部でない場合、当該マスターノードによるステートメント処理は終了し、ストリーム管理ソフトウェア２０は、次のステートメントが受信されるのを待機する。【００７２】  図１０は、新たな処理におけるステートメントを生成するＳＱＬ処理ソフトウェア２２によって実行される処理を表すフローチャートである。
ステップ１００１では、新たな処理における各々のステートメントを生成するべく、ステートメントがトークン化される。
ステップ１００２では、トークンが解析される。
ステップ１００３では、最後に、解析されたステートメントを処理する関連したサブルーチンがコールされる。
サブルーチンは、テーブルの改変（ａｌｔｅｒ）、データの更新／登録、及び問合せ並列化（ｑｕｅｒｙ  ｐａｒａｌｌｅｌｉｚａｔｉｏｎ）を含むことができるが、これに限られるものではない。【００７３】  図１１は、データベースを改変するために、ＳＱＬ解析ソフトウェア２２によってコールされるテーブル改変サブルーチンによって実行される処理を表すフローチャートである。
データベーステーブルの改変は、主にスレーブスキーマ生成ソフトウェア２３によって実行される。【００７４】  ステップ１１００では、改変されるテーブルがファクトテーブ又は第１ディメンションテーブルであるか否かが判定される。
ステップ１１０１では、テーブルがファクトテーブル又は第１ディメンションテーブルである場合、改変するテーブルが垂直分割されているか否かが判定される。
ステップ１１０２では、テーブルが垂直分割されていない場合、テーブルの改変は、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードの、水平分割されたテーブルにおいて行われる。【００７５】  ステップ１１０３では、改変されたテーブルが垂直分割されている場合、垂直分割されたテーブルのセットは、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードにおいて改変される。
ステップ１１０４では、改変されるテーブルがファクトテーブル又はディメンションテーブルでない場合、テーブルは、マスターノードのＤＢＭＳ３１に格納されたメタデータ及び各々のスレーブノードにおいて改変される。
ステップ１１０５では、改変されるテーブルが複数スレーブノードに対して分割されているか否かが判定される。【００７６】  ステップ１１０６では、テーブルが分割されている場合、そのテーブルが垂直分割されているか否かが判定される。
ステップ１１０７では、テーブルが垂直分割されていない場合、当該水平分割されたテーブルのセットのメタデータ及び実テーブルの内容が改変される。
ステップ１１０８では、テーブルが垂直分割されている場合、当該垂直分割されたテーブルのセットのメタデータ及び実テーブルの内容が改変される。
ステップ１１０９では、最後に、改変されたテーブルに依存する問合せキャッシュエントリおよび一時テーブルキャッシュエントリが初期化される。【００７７】  図１２は、データベースに対しデータを更新又は登録するためにＳＱＬ解析ソフトウェア２２によりコールされる更新／登録サブルーチンにより実行される処理を表すフローチャートである。
ステップ１２００では、更新又は登録された各々の行について、行がスレーブノードに分割された形態でのみ保持される例えばファクトテーブルや第１ディメンションテーブルと言ったテーブルの一部であるか否かが判定される。
ステップ１２０１では、行がスレーブノードに分割された形態でのみ保持されるテーブルの一部ではない場合、その行はシステムの各々のスレーブノードに書き込まれる。【００７８】  ステップ１２０２では、行が分割された形態でのみ保持されるテーブルの一部である場合には、その行は、適切なハッシュキー及び場合によっては基準となる日付に基づいて、分割される。
ステップ１２０３では、行が、関連するスレーブノードの分割されたテーブルに書き込まれる。
ステップ１２０４では、変更された全てのデータベースのインデックスが更新される。
ステップ１２０５では、データが更新／登録されたテーブルに依存する全ての問合せキャッシュおよび一時テーブルキャッシュエントリが初期化される。
問合せステートメントは、問合せ並列化ソフトウェア２５によって処理され、最適化される。【００７９】  図１３は、問合せ並列化処理を表すフローチャートである。
ステップ１３０１では、問合せがデータベースシステムの日付分割設定に含まれる特定の日付範囲を調査するか否かを判定する。
ステップ１３０２では、問合せが日付分割に含まれる日付範囲を調査する場合、特定の日付範囲に用いられるスレーブノードのグループが指定される。
ステップ１３０３では、問合せが特定の日付範囲を調査しない場合、又は日付範囲がどの日付分割設定にも相当しない場合、全てのスレーブノードは問合せを実行するのに用いられるべく指定される。【００８０】  ステップ１３０４、１３０５及び１３０６は、問合せの構造に基づいて、また、当業者なら周知の技術を用いて、スレーブノードの問合せをどのように処理するかを決定する。
ステップ１３０４では、夫々独立して実行する必要がある副問合せが、２つの別々の問合せに分割される。
副問合せは、マスターノードにおいて集められる中間結果を伴ってまず実行され、更なる処理のために、残りの問合せとともに、スレーブノードに返される。【００８１】  ステップ１３０５では、外部結合が含まれる場合、問合せを成し遂げるべく、スレーブノード及びマスターノードにより提携して実行される複数の問合せに分割される。
ステップ１３０６では、問合せ最適化プログラムは、再び当業者に周知の技術を用いて、多重処理及び単一処理のストラテジー（ｓｔｒａｔｅｇｉｅｓ）のコストを評価し、最も低いコストの機能を選択する。多重処理が最適である場合は多重処理を、単一処理が最適である場合は単一処理を行なう。
ステップ１３０９では、問合せが、単一処理の問合せを行うステップ１３０７又は多重処理の問合せを行うステップ１３０８のいずれかを経て処理され、結果セットがホストに返される。【００８２】  図１４は、単一処理の問合せを実行するための処理を表すフローチャートである。
問合せは、ホストスキーマからテーブル名を運用しているテーブルを参照する外部のホストシステムから受け取られる。スレーブノードを用いて問合せを並列に処理するために、テーブル名は、スレーブスキーマに準ずるテーブル名に置き換えられなければならない。別の実施例においては、単一処理の問合せは直線的にスレーブノードを経由することができるため、ホストスキーマで用いられるテーブル名は、生成されたスレーブスキーマで用いることが可能であった。
ステップ１４０１では、問合せにおいて参照されるテーブル名が、スレーブスキーマに準ずるテーブル名に置き換えられる。【００８３】  図１５は、問合せにおいて用いられるテーブル名を置き換えるために用いられる処理を表すフローチャートである。
ステップ１５００では、問合せからの結合及び／又はテーブルは、ファクトテーブルの外部における処理を再要求される。
ステップ１５０１では、要求された問合せが、その問合せにおいて実行されるべき結合を含むか否かを判定するべく調査される。【００８４】  ステップ１５０２では、問合せが結合を含んでいない場合、問合せで用いられたテーブルが、スレーブノードに分割された形態でのみ保持されるものであるか否かが判定される。
テーブルがスレーブノードにおいて完全に保持される場合、テーブル名を置き換えることなく、処理を終了する。
ステップ１５０３では、テーブルが分割された形態でのみ保持される場合、スレーブスキーマにおいて、テーブルが垂直分割されているか否かが判定される。【００８５】  ステップ１５０４では、テーブルが垂直分割されていない場合、テーブル名が、関連する水平分割されたテーブルの名称で置き換えられる。
ステップ１５０５では、テーブルがスレーブスキーマにおいて垂直分割されている場合、問合せにおいて、垂直分割によって削除された列（例えば大きいコメントフィールドなど）が用いられるか否かが判定される。
ステップ１５０６では、削除された列が問合せで用いられない場合、テーブル名が、関連した垂直分割されたテーブルの名称で置き換えられる。【００８６】  ステップ１５０７では、問合せにおいて削除された列が用いられる場合、テーブル名が、関連した垂直分割されたテーブルで置き換えられる。また、削除された列を含むテーブルから対応する列を取得するように問合せが修正される。これは、当業者なら周知の技術を用い、行識別子を介して達成される。
ステップ１５０１において、問合せが結合を含むと判定された場合、各々の結合は順次に調査される。
ステップ１５０８では、処理中の問合せにおける各々のテーブルについて、テーブルがファクトテーブルか第１ディメンションテーブルかが判定される。【００８７】  ステップ１５０９では、テーブルがファクトテーブル又は第１ディメンションテーブルである場合、テーブルがスレーブスキーマにおいて垂直分割されているか否かが判定される。
ステップ１５１０では、テーブルが垂直分割されていない場合、テーブル名が、対応する水平分割されたテーブルの名称で置き換えられる。
ステップ１５１１では、テーブルが垂直分割されている場合、問合せが垂直分割において削除された列を用いているか否かが判定される。【００８８】  ステップ１５１２では、問合せが削除された列を用いない場合、テーブル名が、対応する垂直分割されたテーブルの名称で置き換えられる。
ステップ１５１３では、問合せが削除された列を用いる場合、テーブル名は、対応する垂直分割されたテーブルの名称で置き換えられる。また、削除された列を含むテーブルから対応する列を取得するように問合せが修正される。
これは、当業者なら周知の技術を用い、行識別子を介して成し遂げられる。
ステップ１５０８においてテーブルがファクトテーブル又は第１ディメンションテーブルでないと判定された場合、ステップ１５１４では、調査された問合せで用いたテーブル名が、対応する水平分割されたテーブル名で置き換えられる。【００８９】  ステップ１５０９では、水平分割されたテーブル名が問合せに含まれていない場合、ステップ１５０９へ進む。
そのとき、ステップ１５０９からステップ１５１３が、既述した方法で繰り返される。
ステップ１５１５では、テーブル名が水平分割されたテーブル名で置き換えられなかった場合、テーブルが、既に用いられている水平分割されたテーブルと同じ分割キーを有するか否かが判定される。
テーブルが、同じ分割キーを有する場合、結合がテーブルにおける同じ位置の分割の間で実行され、処理がステップ１５０９から１５１３へと進み、前述したように実行される。
テーブルが同一の分割キーを有しない場合、テーブル名は置き換えられず、処理が終了する。【００９０】  図１４に戻り、ステップ１４０１で一旦テーブル名が置き換えられていると、ステップ１４０２において、問合せは、当業者なら周知の技術を用いて、スレーブノードで用いられたデータベースに対して最適化される。
例えば、問合せがより効率的に実行されるために、Ｉ／Ｏサイクルと関連するＣＰＵサイクルのコスト設定が変更可能である。
ステップ１４０３では、最適化された問合せがスレーブノードに伝送される。【００９１】  スレーブノードに障害が発生した場合は、詳しく後述するように、システムの他のスレーブノードに加え、障害が発生したスレーブノードに対応するフェールオーバパートナーに問合せが送信される。各々のスレーブノードのスレーブ管理ソフトウェア３４は、依存するマスターノードから問合せを受信し、処理する。【００９２】  図１６は、新規の問合せが受信されたときに、スレーブ管理ソフトウェアによって実行される処理を表すフローチャートである。
ここで、場合によっては、スレーブ管理ソフトウェアの介入なしで、スレーブノードのＤＢＭＳによって直接問合せが実行可能であることに留意する。
ステップ１６００では、マスターノードから新規の問合せを受信すると、スレーブ管理ソフトウェア３４は、問合せがスレーブノードで用いられるＤＢＭＳにおいて解釈可能になるように変換される必要があるか否かが判定される。【００９３】  本発明のシステム設計は、システムのスレーブレベルで専用のＤＢＭＳが用いられることを必要としない。この特徴は、既に使用しているＤＢＭＳをスレーブノードで用いることが可能であるため、システムコストを低減し、実装までの期間を短縮することができる。
ステップ１６０１では、変換が必要な場合、問合せは当該ＤＢＭＳにおいて解釈可能になるように変換される。【００９４】  ステップ１６０２では、当該ＤＢＭＳで問合せを実行するのに最適化が必要であるか否かが判定される。
ステップ１６０３では、最適化が必要である場合、問合せが最適化される。
マスターレベルで処理が実行されるのと同様に、新規の問合せがその問合せにおいて参照されたテーブルに対する変更を介在させることなく、以前にデータベースに対して行われたか否かを調べるために、問合せキャッシュと照合される。【００９５】  スレーブ管理ソフトウェア３４は、スレーブノードに記録された、ファイルオーバテーブル及びローカルのテーブルの両方の問合せキャッシュを保持する。
ここで、一部のＤＢＭＳ製品は、自分自身の問合せキャッシュを保持する。スレーブノードで実行されているＤＢＭＳが問合せキャッシュを保持している場合、スレーブ管理ソフトウェア３４は、それ自身の問合せキャッシュをチェック及び保持する必要がない。【００９６】  本発明は、マスターレベルで保持される問合せキャッシュと共に、問合せ処理の不必要な反復を防ぐことによってシステムパフォーマンスを改善する二層の問合せキャッシュを提供する。
ステップ１６０４では、受信された問合せが、問合せキャッシュと比較される。
ステップ１６０５では、問合せが問合せキャッシュに存在する場合、結果セットが問合せキャッシュから検索される。【００９７】  ステップ１６０６では、問合せが問合せキャッシュに存在しない場合、問合せは実行されるＤＢＭＳに送信される。
ステップ１６０７では、一旦結果セットが取得されると、スレーブ管理ソフトウェア３４は、結果セットがマスターノードに返される前に、後処理が必要であるか否かが判定される。
ステップ１６０８では、後処理が必要とされる場合、それが実行される。
ステップ１６０９では、結果セットが、問合せを発行したマスターノードへ返される。【００９８】  再び図１４に戻り、マスターノードの結果セット解析ソフトウェア２８は、問合せ処理に用いられた各々のスレーブノードからの結果セットを受信する。
ステップ１４０４では、結果セット解析ソフトウェア２８は、受信した結果セットの後処理を実行する。
後処理は、複数の結果セットを１つの結果セットに結合させ、結果セットのなかで結果を編成し、問合せを生成する外部ホストシステムと互換性のあるフォーマットに結果セットを変換することを含むが、この限りではない。【００９９】  図１７は、本発明の一実施例に基づく、問合せの多重処理を表すフローチャートである。
ステップ１７０１では、問合せは２つ以上のスレーブ問合せに分割される。
これらの問合せを、一連のスレーブノードにおいて実行される複数のスレーブ問合せに分割することは、元々の（分割前の）問合せを処理するためにスレーブノード間でデータを伝送する必要をなくし、また、これらの問合せを実行するシステムパフォーマンスを改善する。【０１００】  問合せの多重処理は、問合せを実行するマスターノードの一時テーブル（テンポラリテーブル）を使用して遂行される。これらの一時テーブルは、個々のスレーブ問合せを実行することにより生成される中間結果セットを格納する。また、一時テーブルは、各々のスレーブ問合せによる結果セットを蓄積するために用いられる。なお、これに代えて、一時テーブルは、スレーブノードに送信されて、一時テーブルの或るものとスレーブノードのローカルテーブルとを結合させる次のスレーブ問合せを実行するようにしても良い。【０１０１】  各々のマスターノードは、データベースシステムのマスターノード及びスレーブノードで用いられる問合せキャッシュと同様に、マスターノードのＤＢＭＳ３１においてマスターノードにより実行されるスレーブ問合せに対して生成された一時テーブルの複製を格納している一時テーブルキャッシュを保持する。
ステップ１７０２では、スレーブ問合せを実行するときに、スレーブ問合せが、一時テーブルが依存する配下のテーブルに対する変更を介在させることなく既に実行されたか否かを判定するべく、スレーブ問合せが一時テーブルキャッシュと照合される。
ステップ１７０３では、一時テーブルキャッシュと一致しない場合、スレーブ問合せに対する一時テーブルが生成される。【０１０２】  ステップ１７０４から１７０７では、スレーブ問合せが実行され、結果が生成される。
これらのステップにおける処理は、図１４のステップ１４０１から１４０４における処理と同様であることから、詳細な説明を省略する。【０１０３】  ステップ１７０８では、一旦スレーブ問合せが実行されるか、又はスレーブ問合せが一時テーブルキャッシュに存在している場合、マスターノードは、スレーブ問合せが残っているか否かを判定する。
ステップ１７０９では、更なるスレーブ問合せが実行される場合、次のスレーブ問合せが処理のために一時テーブルを必要とするか否かを判定する。
ステップ１７１０では、一時テーブルがスレーブにおいて必要とされる場合、一時テーブルがスレーブノードに送信され、ステップ１７０２の処理へ戻る。
なお、一時テーブルが必要とされない場合、次のスレーブ問合せのために、そのままステップ１７０２の処理へ戻る。【０１０４】  図１３に示すように、一旦外部ホストシステムから受信した問い合わせが単一処理又は多重処理のいずれかで実行され処理されると、最終的な結果セットが外部ホストシステムに返される。【０１０５】  本発明のデータベースシステムの各々のマスターノードは、データベースシステムの他のノードの状態を監視するべく、システム管理ソフトウェア３２と接続される。
適切なシステム管理ソフトウェアの一例は、ＩＰＭＩ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｐｌａｔｆｏｒｍ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｔｅｒｆａｃｅ）及びＩｎｔｅｌのシステムマネージャを含んで構成される。【０１０６】  マスターノードに障害が発生した通知を受信すると、ストリーム管理ソフトウェア２０は、管理コンソール３５に対してマスターノードの障害を知らせるシステムステータスメッセージを送信する。管理コンソール３５は、データベースシステムの状態を調査し、また、システム能力を維持するために修復を必要とする障害が発生したノードを特定するべく、システム管理者によって運用される。一旦管理コンソール３５がマスターノードの障害の通知を受けると、ストリーム管理ソフトウェア２０は、マスターノードのフェールオーバ処理を実行する。【０１０７】  図１８は、データベースシステムのマスターノードで障害が発生したときに、ストリーム管理ソフトウェア２０において実行されるフェールオーバ処理を表すフローチャートである。
図１８で示される処理は、障害が発生したマスターノードによって制御されている各々のストリームに対して実行される。【０１０８】  ステップ１８００では、マスターノードは、当該ストリームが、障害の発生しているマスターノードで制御すべきものか否かを判定する。
本発明の一実施例によれば、この判定は、データベースシステムにより受信された新規のストリームを操作するのに用いられるのと同様の負荷分散方法を用いたデータベースシステムの使用可能なマスターノードの間で行われる。
しかしながら、当業者なら周知の他の方法を、この判定をするのに用いることができる。【０１０９】  ステップ１８０１では、障害が発生したマスターノードで制御すべきものであると判定されたとき、マスターノードは自身がストリームを制御していることを他のマスターノードに通知する。
一旦マスターノードがストリームの制御を引き受けると、当該ストリームからの各々の不完全なステートメントが、マスターノードによって占有される。ステップ１８０２では、不完全なステートメントが、周知のトランザクション管理技術によってロールバックされる。
ステップ１８０３では、ステートメントが再実行される。【０１１０】  このように、障害が発生したマスターノードによって制御される各々のストリームは、データベースシステムの動作を維持するべく、使用可能なマスターノードによって引き継がれる。一旦障害が発生したマスターノードが復旧されるか又は交換されると、データベースシステムからの新規のストリームを処理可能となる。また、データベースシステムの他のマスターノードを監視することに加え、システム管理ソフトウェア３２は、システムの各々のスレーブノードもまた監視する。【０１１１】  図１９は、データベースシステムのスレーブノードに障害が発生したときの処理を表すフローチャートである。
ステップ１９００では、スレーブノードに障害が発生した場合、ストリーム管理ソフトウェア２０に障害が通知される。ストリーム管理ソフトウェアは、さらに、管理コンソール３５を介して、ノード障害についてシステム管理者に通知する。
ステップ１９０１では、障害が発生したスレーブノードに関連する各々の不完全トランザクションについて、ストリーム管理ソフトウェア２０は、不完全トランザクションをロールバックする。【０１１２】  ステップ１９０２では、障害が発生したスレーブノードの代わりに対応するフェールオーバパートナーを用いて、トランザクションを再実行する。
障害が発生したスレーブノードが復旧されているか又は交換されている間、マスターノードは、正規に使用されるスレーブノード及び対応するフェールオーバパートナーの両方において問合せを実行する。従って、データベースシステムの動作は、スレーブノードにおける障害発生にも関わらず、維持される。一旦スレーブノードが復旧又は交換されると、マスターノードは通常の問合せ実行に戻る。【０１１３】  本発明の別の実施例は、多数のスレーブノードを制御するための階層的なマスターノード構成を有するものである。
この構成では、マスターノードによって実行される処理が、パフォーマンスを向上するべく、複数のレイヤに分解される。さらに、スレーブノードレベルにおいて実行される一部の処理は、マスターノードレベルに移されることができる。【０１１４】  他の実施例では、前述したような直接取り付けられた記憶装置の変わりに、データベースのスレーブノードにおける共有の記憶システムを用いる。フェールオーバデータは、共有された記憶装置に格納されることができ、これにより、使用可能なスレーブノードが、障害が発生したノードに対するフェールオーバ動作責務を実現することができるようになる。【０１１５】  前述した超無共有型並列データベースシステムは、従来の無共有型並列データベースシステムに対し、有意義な利点を提供する。
まず、本発明のデータベースシステムは、データベースシステムのパフォーマンスにおける問合せスキュー及び不利益な影響を防ぐことができる。
次に、データベースシステムのスレーブノード全体におけるデータベースの分割及び分散が、自動的に行われる。
これは、システム管理を煩雑にすることなく、システムパフォーマンスを向上する。
また、二層のキャッシュが問合せキャッシュに用いられることにより、同じ問合せを複数回不必要に繰り返すことを防ぐことができる。さらに、ノードに障害が発生した場合であっても、データベースシステムのフェールオーバ処理により、システム動作を維持することができる。【０１１６】  前述の説明は、本発明の好ましい実施例を具体的に説明することを目的とする。しかしながら、記載される実施例は本発明の範囲を制限することを目的とせず、それは、特許請求の範囲からも明らかである。本発明の目的及び範囲から逸脱することなく、実施例に対し様々な変更をなし得ることは当然のことである。
【図面の簡単な説明】
【０１１７】
【図１】  無共有型並列データベースシステムのハードウェアアーキテクチャを表す概要図である。
【図２】  本発明の一実施形態における超無共有型並列データベースシステムのソフトウエア・アーキテクチャを表す概要図である。
【図３】  スレーブスキーマを生成するために用いる処理を表すフローチャートである。
【図４】  ホストスキーマの一例を表す図である。
【図５】  ホストスキーマのテーブルを順序付ける（ｏｒｄｅｒｉｎｇ）ための処理を表すフローチャートである。
【図６】  本発明の一実施形態において、データベースのテーブルをデータベースシステムに一括ローディング（ｂｕｌｋ  ｌｏａｄｉｎｇ）する処理を表すフローチャートである。
【図７】  データベーステーブルをデータベースシステムのスレーブノードへロードする処理を表すフローチャートである。
【図８】  予めソートされたデータを直接スレーブノードへ一括ローディングする処理を表すフローチャートである。
【図９】  外部のホストシステムから新規のステートメントを受信すると実行される処理を表すフローチャートである。
【図１０】  ＳＱＬステートメントを解析し実行する処理を表すフローチャートである。
【図１１】  データベーステーブルを改変するための処理を表すフローチャートである。
【図１２】  データベーステーブルにデータを更新／登録する処理を表すフローチャートである。
【図１３】  問合せ並列化処理を表すフローチャートである。
【図１４】  単一処理（ｓｉｎｇｌｅ  ｓｔｅｐ）の問合せを実行するための処理を表すフローチャートである。
【図１５】  問合せのテーブル名を、スレーブスキーマにおいて用いられるテーブル名に置き換えるための処理を表すフローチャートである。
【図１６】  問合せを実行するスレーブノードで実行される処理を表すフローチャートである。
【図１７】  多重処理の問合せの処理を表すフローチャートである。
【図１８】  マスターノードに障害が発生した場合に実行されるフェールオーバ処理を表すフローチャートである。
【図１９】  スレーブノードに障害が発生した場合は実行されるフェールオーバ処理を表すフローチャートである。
【符号の説明】
【０１１８】１０    データベースシステム
１１    マスターノード
１２    スレーブノード
１３    ネットワーク
１４    マスターノードの中央演算処理装置（ＣＰＵ）
１５    マスターノードのメモリ（ＲＡＭ）
１６    マスターノードのディスク
１７    スレーブノードの中央演算処理装置（ＣＰＵ）
１８    スレーブノードのメモリ（ＲＡＭ）
１９    スレーブノードのディスク
２０    ストリーム管理ソフトウェア
２１    問合せキャッシュソフトウェア
２２    ＳＱＬ解析ソフトウェア
２３    スレーブスキーマ生成ソフトウェア
２４    更新／登録ソフトウェア
２５    問合せ並列化ソフトウェア
２６    マルチステップ問合せ実行ソフトウェア
２８    結果セット解析ソフトウェア
２９    日付分割メンテナンスソフトウェア
３０    一括ローディングソフトウェア
３１    マスターノードのＤＢＭＳ
３２    システム管理ソフトウェア
３３    スレーブノードのＤＢＭＳ
３４    スレーブ管理ソフトウェア
３５    管理コンソールソフトウェア
【図１】
2007531087.tif 000003
【図２】
2007531087.tif 000004
【図３】
2007531087.tif 000005
【図４】
2007531087.tif 000006
【図５】
2007531087.tif 000007
【図６】
2007531087.tif 000008
【図７】
2007531087.tif 000009
【図８】
2007531087.tif 000010
【図９】
2007531087.tif 000011
【図１０】
2007531087.tif 000012
【図１１】
2007531087.tif 000013
【図１２】
2007531087.tif 000014
【図１３】
2007531087.tif 000015
【図１４】
2007531087.tif 000016
【図１５】
2007531087.tif 000017
【図１６】
2007531087.tif 000018
【図１７】
2007531087.tif 000019
【図１８】
2007531087.tif 000020
【図１９】
2007531087.tif 000021