特許 6262505 分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6262505

(24)【登録日】2017年12月22日

(45)【発行日】2018年1月17日

(54)【発明の名称】分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20180104BHJP

   G06F 17/30 20060101ALI20180104BHJP

【ＦＩ】

   G06F12/00 513J

   G06F12/00 545A

   G06F17/30 110C

   G06F17/30 180D

【請求項の数】7

【全頁数】14

(21)【出願番号】特願2013-246938(P2013-246938)

(22)【出願日】2013年11月29日

(65)【公開番号】特開2015-106219(P2015-106219A)

(43)【公開日】2015年6月8日

【審査請求日】2016年7月29日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】斉藤 和広

【審査官】 甲斐 哲雄

(56)【参考文献】

【文献】 特開２００７−１９９８０４（ＪＰ，Ａ）

【文献】 特開２０１３−０２５４２５（ＪＰ，Ａ）

【文献】 特開２０１５−０４５９９６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

クエリ処理要求と結果受信を行うクライアントと、クエリ処理を行うデータ仮想化装置と、前記データ仮想化装置が利用する１つ以上のデータベースシステムと、前記データ仮想化装置のリソース量に関する情報、及び、前記データベースシステムが有するテーブル情報を管理する分散型データ仮想化システム管理装置と、を備えた分散型データ仮想化システムにおいて、
前記データ仮想化装置は、複数のデータ仮想化装置から構成し、
前記各データ仮想化装置は、
前記クエリ処理の手順を定義したクエリプランと前記リソース量及び前記テーブル情報を考慮し、クエリ処理を並列実施する複数のデータ仮想化装置の選定と当該複数のデータ仮想化装置でのクエリ処理内容とを含む分散処理計画を作成する分散処理計画部と、
分散処理するデータ仮想化装置群に前記分散処理計画を分配する処理計画配置部と、
前記分散処理計画に応じて、各データベースシステムから取得した処理対象データをレコード単位で他のデータ仮想化装置に分配又は当該データ仮想化装置で受信するデータ分散部と、
前記分散処理計画に従った処理を行うクエリ処理部と
前記分散処理計画に従った処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部と
を備えることを特徴とする分散型データ仮想化システム。

【請求項2】

クエリ処理要求と結果受信を行うクライアントと、クエリ処理を行う複数のデータ仮想化装置と、前記データ仮想化装置のリソース量に関する情報を管理する分散型データ仮想化システム管理装置と、前記データ仮想化装置が利用する１つ以上のデータベースシステムとを備えた分散型データ仮想化システムにおけるクエリ処理方法であって、
前記クライアントからクエリ処理要求があった場合に、
クエリ処理の手順を定義したクエリプランを作成するクエリプラン作成手順と、
前記クエリプランと前記リソース量及び前記データベースシステムが有するテーブル情報を考慮して、クエリ処理を並列実施する複数のデータ仮想化装置の選定と当該複数のデータ仮想化装置での分散クエリ処理内容とを含む分散処理計画を作成する分散処理計画手順と、
分散処理するデータ仮想化装置群に前記分散処理計画を分配する処理分配手順と、
前記分散処理計画に応じて、各データベースシステムから取得した処理対象データをレコード単位で分配又は受信するデータ分散手順と、
前記分散処理計画に従った処理を行うクエリ処理手順と
前記分散処理計画に従った処理の結果を受信し、集計した結果を前記クライアントに送信するデータ集計手順と
を含むことを特徴とするクエリ処理方法。

【請求項3】

前記分散処理計画手順は、
前記分散クエリ処理内容から各データベースシステムから得られる分散クエリ結果の容量を計算する手順と、
計算された容量から、実際の物理テーブルをユーザに提供する論理テーブルに変換する処理を定義した仮想スキーマで得られるテーブルや中間テーブル、最終的な結果の出力容量と、前記仮想スキーマの処理における最大処理容量を計算する手順と、
計算された容量を利用して、必要なデータ仮想化装置の数及び適用先のデータ仮想化装置を決定するデータ仮想化装置群選択手順と
を含む請求項２に記載のクエリ処理方法。

【請求項4】

前記データ仮想化装置群選択手順は、
前記クエリプランから作成したプランツリーを根（クエリ結果）から順に前記クエリ処理を実行するノードを決める対象となるテーブルを降順探索する手順と、 前記テーブルが仮想スキーマにおける出力テーブルである場合に、当該仮想スキーマにおける最大出力容量と、データ仮想化装置群における利用状況及び利用可能メモリサイズからデータ仮想化装置群を選択する手順と
を含む請求項３に記載のクエリ処理方法。

【請求項5】

前記データ分散手順は、
前記各データベースシステムから前記処理対象データを取得する手順と、
前記処理対象データを処理するデータ仮想化装置をレコード単位で判定する手順と
を含む請求項２に記載のクエリ処理方法。

【請求項6】

前記クエリ処理手順は、
処理完了により次の処理を行う場合に、
単項演算であるか二項演算であるかを判定する手順と、
二項演算である場合は、二項演算の完了通知を待って次の処理を行うためのデータ移動とクエリ処理を行う手順と
を含む請求項２に記載のクエリ処理方法。

【請求項7】

請求項２の各手順をコンピュータに実行させるクエリ処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一つ以上のデータベースシステムに対する論理的なモデルを提供するデータ仮想化システムに関し、クエリ処理を複数のデータ仮想化装置に分散して並列処理する分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラムに関する。

【背景技術】

【0002】

データ仮想化システム（又はマルチデータベースシステム）は、複数のデータベースシステムを仮想的に一つのデータベースシステムに見せるために、各データベースシステムが持つテーブルを論理的に一つのシステムに集約して管理し、ユーザのクエリに対応するデータベースシステムにクエリを投稿する。
代表的なデータ仮想化システムは、例えば特許文献１に示されるように、複数の階層的なデータベースシステムを、データマッピングにより仮想スキーマ（実際の物理テーブルをユーザに提供する論理テーブルに変換する処理を定義したもの）に統合し、クエリ実行時において処理対象となるデータを保持するデータベースシステムにクエリを分配するよう構成されている。各データベースシステムで実行されたクエリの結果は中央に収集され、仮想スキーマに従って一つに統合して結果を出力するシステムとなっている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開平０７−１４１３９９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１のように、複数のデータベースシステムに跨がるクエリ処理の最終的な統合処理は、データ仮想化システム上で実行する必要がある。このとき、一つ以上のデータベースシステムから得られるデータが、データ仮想化システムの物理メモリサイズを超えるほど大規模であった場合、実行できずにエラー終了してしまう可能性がある。
OSのスワップ機構もしくはデータ仮想化システムのディスク退避の機能の実装によってある程度のサイズまでは対応可能であると考えられるが、それによる遅延は非常に大きく、その許容量を超えてしまった場合にも同様に終了してしまうという問題がある。

【0005】

ユーザにとってデータ仮想化システムを利用する最大のメリットは、個々のデータベースシステムを意識せず利用できる点にあり、データ仮想化システムがアクセスするデータベースシステムのクエリ処理の結果が大規模かどうかを意識させることはデータ仮想化システムの利益を損なうこととなる。

【0006】

本発明は上記実情に鑑みて提案されたものであり、データ仮想化システムにおいて、一台のデータ仮想化装置では処理しきれない大規模なデータを、複数のデータ仮想化装置に分散して並列処理を行う分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラムを提供することを目的としている。

【課題を解決するための手段】

【0007】

上記目的を達成するため本発明の請求項１は、クエリ処理要求と結果受信を行うクライアントと、クエリ処理を行うデータ仮想化装置と、前記データ仮想化装置が利用する１つ以上のデータベースシステムと、前記データ仮想化装置のリソース量に関する情報、及び、前記データベースシステムが有するテーブル情報を管理する分散型データ仮想化システム管理装置と、を備えた分散型データ仮想化システムにおいて、
前記データ仮想化装置は、複数のデータ仮想化装置から構成し、
前記各データ仮想化装置は、
前記クエリ処理の手順を定義したクエリプランと前記リソース量及び前記テーブル情報を考慮し、クエリ処理を並列実施する複数のデータ仮想化装置の選定と当該複数のデータ仮想化装置でのクエリ処理内容とを含む分散処理計画を作成する分散処理計画部と、
分散処理するデータ仮想化装置群に前記分散処理計画を分配する処理計画配置部と、
前記分散処理計画に応じて各データベースシステムから取得した処理対象データをレコード単位で他のデータ仮想化装置に分配又は当該データ仮想化装置で受信するデータ分散部と、
前記分散処理計画に従った処理を行うクエリ処理部と、
前記分散処理計画に従った処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部とを備えることを特徴としている。

【0008】

請求項２は、クエリ処理要求と結果受信を行うクライアントと、クエリ処理を行う複数のデータ仮想化装置と、前記データ仮想化装置のリソース量に関する情報を管理する分散型データ仮想化システム管理装置と、前記データ仮想化装置が利用する１つ以上のデータベースシステムとを備えた分散型データ仮想化システムにおけるクエリ処理方法であって、
前記クライアントからクエリ処理要求があった場合に、
クエリ処理の手順を定義したクエリプランを作成するクエリプラン作成手順と、
前記クエリプランと前記リソース量及び前記データベースシステムが有するテーブル情報を考慮して、クエリ処理を並列実施する複数のデータ仮想化装置の選定と当該複数のデータ仮想化装置での分散クエリ処理内容とを含む分散処理計画を作成する分散処理計画手順と、
分散処理するデータ仮想化装置群に前記分散処理計画を分配する処理分配手順と、
前記分散処理計画に応じて各データベースシステムから取得した処理対象データをレコード単位で分配又は受信するデータ分散手順と、
前記分散処理計画に従った処理を行うクエリ処理手順と、
前記分散処理計画に従った処理の結果を受信し、集計した結果を前記クライアントに送信するデータ集計手順と
を含むことを特徴としている。

【0009】

請求項３は、請求項２のクエリ処理方法において、
前記分散処理計画手順は、 前記分散クエリ処理内容から各データベースシステムから得られる分散クエリ結果の容量を計算する手順と、
計算された容量から、実際の物理テーブルをユーザに提供する論理テーブルに変換する処理を定義した仮想スキーマで得られるテーブルや中間テーブル、最終的な結果の出力容量と、前記仮想スキーマの処理における最大処理容量を計算する手順と、
計算された容量を利用して、必要なデータ仮想化装置の数及び適用先のデータ仮想化装置を決定するデータ仮想化装置群選択手順と
を含むことを特徴としている。

【0010】

請求項４は、請求項３のクエリ処理方法において、
前記データ仮想化装置群選択手順は、
前記クエリプランから作成したプランツリーを根（クエリ結果）から順に前記クエリ処理を実行するノードを決める対象となるテーブルを降順探索する手順と、
前記テーブルが仮想スキーマにおける出力テーブルである場合に、当該仮想スキーマにおける最大出力容量と、データ仮想化装置群における利用状況及び利用可能メモリサイズからデータ仮想化装置群を選択する手順と
を含むことを特徴としている。

【0011】

請求項５は、請求項２のクエリ処理方法において、
前記データ分散手順は、
前記各データベースシステムから前記処理対象データを取得する手順と、
前記処理対象データを処理するデータ仮想化装置をレコード単位で判定する手順と
を含むことを特徴としている。

【0012】

請求項６は、請求項２のクエリ処理方法において、
前記クエリ処理手順は、
処理完了により次の処理を行う場合に、
単項演算であるか二項演算であるかを判定する手順と、
二項演算である場合は、二項演算の完了通知を待って次の処理を行うためのデータ移動とクエリ処理を行う手順と
を含むことを特徴としている。

【0013】

請求項７は、請求項２の各手順をコンピュータに実行させるクエリ処理プログラム。
であることを特徴している。

【発明の効果】

【0014】

本発明（請求項１及び請求項２）によれば、分散処理計画と処理計画配置を行うことで、複数のデータ仮想化装置上の処理を分散化し並列処理を行うことができ、大規模データ処理に対応することが可能となる。
また、仮想スキーマを利用した分散による並列性の向上を実現することができる。
また、仮想スキーマの処理を独立化することにより、クエリ再実行の効率化及び仮想化対象のデータベースシステムの負荷軽減を実現することができる。

【0015】

請求項３及び請求項４によれば、分散クエリ結果の容量と、仮想スキーマの処理における最大処理容量を考慮することで、適切なデータ仮想化装置群の選択が可能となる。

【0016】

請求項５によれば、データ仮想化装置を判定するに際して、各テーブルの１レコードずつ指定するので、処理に適したデータ仮想化装置を選択することができる。

【0017】

請求項６によれば、クエリ処理を行うに際し、二項演算の完了通知を待って次の処理を行うようにしたので、計画に沿ったクエリ処理を確実に行うことが可能となる。

【0018】

請求項７によれば、複数のデータ仮想化装置上の処理を分散化し並列処理を行うことができるクエリ処理方法をコンピュータ上に構築することができる。

【図面の簡単な説明】

【0019】

【図1】本発明の分散型データ仮想化システムの全体構成図を示すモデル図である。

【図2】一般的なデータ仮想化システムにおける仮想スキーマの例を示す

【図3】分散型データ仮想化システムにおけるデータ仮想化装置の構成を説明するためのブロック図である。

【図4】分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理において、データ仮想化装置が各データベースシステムの処理結果を受け取るまでのデータの流れを示すブロック図である。

【図5】分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理において、データ仮想化装置が各データベースシステムの処理結果を分散処理するときのデータの流れを示すブロック図である。

【図6】データ仮想化装置の分散処理計画部における処理手順を示すフローチャート図である。

【図7】図５の仮想スキーマaを例に、ユーザが投稿したSQLクエリ「SELECT aid FROM a」のクエリプランをプランツリーへの変換例を示すモデル図である。

【図8】図６における「各テーブルの処理データ仮想化装置群選択」についての処理手順を示すフローチャート図である。

【図9】作成した分散処理計画を利用するデータ仮想化装置群に配布し、データベースシステムにおけるクエリ処理が完了した直後のデータ分散処理について、図９に示す。フローチャート図である。

【図10】データ仮想化装置のクエリ処理部において、クエリツリー上のそれぞれの処理が完了した後の処理の流れを図１０に示す。フローチャート図である。

【発明を実施するための形態】

【0020】

本発明の分散型データ仮想化システムの実施形態について、図１を参照して説明する。
本発明の分散型データ仮想化システムは、データ仮想化システムにおいて、一台のデータ仮想化装置では処理しきれない大規模なデータを、複数のデータ仮想化装置に分散して並列処理を行うシステムであり、図１に示すように、システムを利用するクライアント１と、分散型データ仮想化システム管理装置２と、１つ以上のデータ仮想化装置３と、分散型データ仮想化システムが利用する１つ以上のデータベースシステム４から構成されている。
各データ仮想化装置３と、クライアント１及び分散型データ仮想化システム管理装置２とはネットワークXを介して接続されている。また、各データ仮想化装置３と各データベースシステム４とはネットワークYを介して接続されている。

【0021】

クライアント１、分散型データ仮想化システム管理装置２、各データ仮想化装置３及び各データベースシステム４は、それぞれ、オペレーティングシステム（ＯＳ）を含む基本プログラムや各種の基本デバイスが記憶されたＲＯＭと、各種のプログラムションやデータが記憶されるハードディスクドライブ装置(HDD)と、CR-ROMやDVD等の記憶媒体からプログラムやデータを読み出すメディアドライブ装置と、プログラムを実行するCPUと、このCPUにワークエリアを提供するRAMと、外部装置と通信するパラレル／シリアルI/Fとを主要部分とする一般的な構成を備えたコンピュータ上に構築されている。
例えば、上述した構成を有する各コンピュータにおいて、メディアドライブ装置で読み取られたクエリ処理プログラムがHDDにインストールされることで分散型データ仮想化システムが構築される。

【0022】

クライアント１は、データ仮想化装置３の利用状況や稼働状況から適切な一つのデータ仮想化装置３に接続し、クエリの投稿と結果の受信を行う分散コネクタ１１を備えている。

【0023】

分散型データ仮想化システム管理装置２は、それぞれのデータ仮想化装置３が持つリソース容量及び現在の利用状況（リソース情報）を保持するリソース管理データ２１と、各データベースシステム４上にあるテーブル情報（物理モデルやサイズ、クエリによるサイズ変更差分）を持つデータソース管理データ２２と、その物理モデルに対する仮想スキーマの構成、変換手順（論理モデル情報）及び消費リソース量に関する情報（消費情報）を持つモデルデータ２３を備えている。

【0024】

モデルデータ２３が有する仮想スキーマは、ユーザがクエリで指定する論理テーブルを、どのデータベースシステム４上のテーブルに対して、どのように処理を行うかに関する仮想スキーマ情報を管理している。例えば、データ仮想化装置３にクエリが投稿された場合の仮想スキーマによる一般的な処理例について、図２に示す。
ここでは、クライアント１からテーブルaへのSQLクエリが投稿されたとする。データ仮想化装置３上では、テーブルaに対して、テーブルsとテーブルtのUNION処理の結果が仮想スキーマaと定義されている。テーブルsは、実際にはデータベースシステムS上にあるテーブルであり、テーブルtは、データベースシステムTにあるテーブルである。

【0025】

このとき、クライアント１が投稿したSQLクエリに対して、テーブルaを仮想スキーマaの処理に変換する。そして、このクエリは、データ仮想化装置３上で実行されるクエリ（UNION）、データベースシステムS上で実行されるクエリ（テーブルsへのSQLクエリ）、データベースシステムT上で実行されるクエリ（テーブルtへのSQLクエリ）に分解され、各データベースシステム４にクエリが投稿される。
それぞれのデータベースシステム４の処理結果は、クエリを投稿したデータ仮想化装置３に収集され、予め作られたクエリ（UNION）処理を実行してクライアント１に送信される。

【0026】

データ仮想化装置３は、図３〜図５に示すように、クエリ評価部３１と、分散クエリ生成部３２と、分散クエリ投稿部３３と、分散処理計画部３４と、処理計画配置部３５と、クエリ結果受信部３６、データ分散部３７と、クエリ処理部３８と、データ集計部３９とを備えて構成されている。

【0027】

クエリ評価部３１は、クライアント１からクエリ処理要求を受け取り、モデルデータ２３から仮想スキーマ情報を取得Ａして、この情報に従ってクエリ処理の手順を定義したクエリプランを生成する（図４）。
分散クエリ生成部３２は、データソース管理データ２２からテーブル情報を取得Ｂし、この情報を基にクエリプランに従って適切なデータベースシステム４向けのクエリを生成（再構成）する（図４）。
分散クエリ投稿部３３は、分散クエリ生成部３２で生成したクエリを各データベースシステム４に投稿Ｃする（図３）。

【0028】

分散処理計画部３４は、リソース管理データ２１からリソース情報を取得Ｄし、モデルデータ２３から論理モデル情報及び消費情報を取得Ｅし、データソース管理データ２２からテーブル情報を取得Ｆし、クエリ評価部３１で生成されたクエリプランに対してこれらの情報を利用して、処理内容と処理を実施するデータ仮想化装置３を選択する分散処理計画を生成する。
処理計画配置部３５は、分散処理するデータ仮想化装置群に分散処理計画部３４で生成した分散処理計画を分配Ｇする（図３）。

【0029】

クエリ結果受信部３６は、各データベースシステム４からのクエリ実行結果の受信Ｈし、データ分散部３７への出力Ｉを行う（図４）。
データ分散部３７は、リソース管理データ２１からリソース情報を受信Ｊするとともに、処理計画配置部３５から分散処理計画を受け取り、この計画に基いて各データベースシステム４から受信したクエリ実行結果をレコード単位で各データ仮想化装置３のデータ分散部３７に分配Ｋ又は受信する（図５）。
クエリ処理部３８は、データ分散部３７との間で分散処理計画に基いた処理Ｌを行う（図５）。
データ集計部３９は、処理Lの結果を各クエリ処理部３８から受信Ｍして集計し、その結果をクライアント１の分散コネクタ１１に転送Ｏする（図５）。
なお、データ仮想化装置を構成する各データ仮想化装置３は、それぞれ同様の機能を備えて構成されている。

【0030】

データベースシステム４は、クエリを処理するクエリエンジン４１と、実データを保管するデータソース４２から構成されている。

【0031】

次に、分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理の一連の流れについて説明する。
ユーザは、クライアント１の分散コネクタ１１を経由してクエリを投稿する。
クエリ評価部３１はクエリを受け取り、クエリの処理対象となるテーブルに対応する仮想スキーマをモデルデータ２３から呼び出し、ユーザが投稿したクエリに仮想スキーマの処理を適用した形でクエリプランを生成する。
このクエリプランには、データ仮想化装置（以下、ノードと称する）３群に接続されたデータベースシステム４群の実際のテーブルが含まれる。

【0032】

分散クエリ生成部３２は、このテーブルとデータソース管理データ２２を突合し、対象のデータベースシステム４を明確にする。そして、クエリプランを基に実際のデータベースシステム４で実行可能なクエリを生成する。
分散クエリ投稿部３３は、この実行可能なクエリを、対象となるデータベースシステム４にそれぞれ投稿する。

【0033】

分散処理計画部３４は、クエリ評価部３１がクエリプランを生成した段階で、このクエリプランを利用してノード３群の分散処理計画を作成する。
分散処理計画部３４における処理手順について、図６及び図７を参照して説明する。

【0034】

クエリプラン（文字データ）を基に、処理対象テーブルと処理内容の流れを、処理毎の中間テーブルも含めて表すプランツリーを生成する（ステップ６１）。プランツリーは、図７に示すように、テーブルに対する処理が連なるように構成されている。
次に、モデルデータ２３及びデータソース管理データ２２を取得し（ステップ６２）、プランツリー上の処理内容から各データベースシステム４から得られる分散クエリ結果の容量を計算する（ステップ６３）。

【0035】

この結果から、仮想スキーマで得られるテーブルや中間テーブル、最終的な結果の出力容量と、仮想スキーマの処理における最大処理容量を計算する（ステップ６４）。最大処理容量は、必要なノードの数を決める際に有用なデータとなる。
計算した容量を利用して、必要なノードの数及び適用先のノード（自身なのか別なのか）を決定する（ステップ６５）。このとき、最終的にデータを収集するノード３が、現在分散処理を作成しているノード３と異なる場合には（ステップ６６）、クライアント１の分散コネクタ１１に接続先変更を依頼し（ステップ６７）、分散処理計画を完了する（ステップ６８）。
このような処理を行うことで、分散クエリ結果の容量と、仮想スキーマの処理における最大処理容量が考慮されるので、適切なノードの選択が可能となる。

【0036】

図７は、図２の仮想スキーマaを例に、ユーザが投稿したSQLクエリ「SELECT aid FROM a」のクエリプランをプランツリーに変換した例を示す。
ユーザが投稿したSQLクエリは、図７の例のように、３つのSQLクエリに分解される。これらのうち物理モデルであるテーブルsとテーブルtへのクエリの結果は、中間テーブルとしてノード３上に収集され、仮想スキーマaで定義されたUNION処理の対象として処理される。

【0037】

このような流れについて、処理の前後のテーブルを明確に表したものが図７のプランツリーである。すなわち、各データベースシステムから得られるテーブル容量としてデータソース管理データ２２から取得したテーブルsのサイズ（30GB）とテーブルtのサイズ（10GB）が示される。また、中間テーブルの出力容量として、Projection処理後のテーブルsのサイズ（6GB）とテーブルtのサイズ（2GB）、及び、モデルデータ２３にある仮想スキーマ処理のサイズ計算メソッドを適用した処理後のサイズ（8GB）が示されている。

【0038】

次に、図６における「各テーブルの処理ノード群選択」（ステップ６５）についての詳細の処理フローを図８に示す。
処理ノード群の選択が開始された場合（ステップ８１）、作成したプランツリーを根（クエリ結果）から順に、クエリ処理を実行するノードを決める対象となるテーブルを降順探索する（ステップ８２）。

【0039】

探索で対象のテーブルが発見された場合（ステップ８３）、対象テーブルが、論理テーブル（仮想スキーマにおける出力テーブル）、仮想スキーマ内のテーブル（仮想スキーマにおける物理テーブル又は中間テーブル）、仮想スキーマ外のテーブル（論理テーブルに対する処理における中間テーブル又はクエリ結果）のいずれであるかのテーブル種別を行う（ステップ８４）。
ステップ８４のテーブル種別で、論理テーブルを発見した場合、当該仮想スキーマにおける最大出力容量と、ノード群における利用状況及び利用可能メモリサイズからノード群を選択する（ステップ８５）。
なお、仮想スキーマ内のテーブルである場合は、仮想スキーマ全体で処理容量を計算しているため、ここでは無視して再度探索を続ける。

【0040】

ステップ８４のテーブル種別で、仮想スキーマ外のテーブル（中間テーブル又はクエリ結果）を発見した場合は、当該テーブルの出力容量とノード群の利用可能メモリサイズを基に、ツリーにおける下位（葉側）のテーブルに対する処理を行ったノードの中から処理するノード群を選択する（ステップ８６）。このとき、できる限りデータ通信が少なくなるよう、テーブルデータが多く含まれているノードを優先する。また併せて、利用するノードのリソース管理データを更新する。
ここで空いているノードがない場合、すでに実行されている処理が最も早く終わると考えられるノードを選択し、対象ノードのリソース管理データの処理待ちキューの対象として記録される。

【0041】

ノード群を選択後、当該ノード群へのデータ転送を行うために、ハッシュ化対象属性を選択する（ステップ８７）。この属性は、直前の処理内容に依存し、例えばJOINのように、特定の属性毎の処理が必要な場合には選択されるが、UNION処理のようなハッシュ化が必要のない場合には選択されない。

【0042】

以上の処理をプランツリー全体に対して行った後（ステップ８８）、処理ノード群選択の処理が完了する（ステップ８９）。
このように、仮想スキーマをベースとしたノード群の選択を行うことで、依存性のあるテーブル間の処理を特定のノードに集めることができ、クエリ処理に対して高い並列性を出すことが可能となる。

【0043】

更には、仮にある特定のノードが実行中に異常終了し、ノード単位で再実行が不可能になったとしても、異常終了したノードで実行された仮想スキーマの処理のみを再実行すればよく、ノード群におけるクエリ処理と、対象となるデータベースシステムへのクエリ処理要求を最低限に抑えることが可能となる。

【0044】

次に、作成した分散処理計画を利用するノード群に配布し、データベースシステムにおけるクエリ処理が完了した直後のデータ分散処理の詳細フローについて、図９に示す。
各データベースシステム４にクエリを投稿したノード３において、データベースシステム４の実行結果が受信されると（ステップ９１）、クエリ結果受信部３６は、この結果データをストリーム的にデータ分散部３７に１レコードずつ渡す（ステップ９２）。

【0045】

このときデータ分散部３７は、処理計画配置部３５から取得した分散処理計画を基に、対象となるノード３のデータ分散部３７へ結果データを転送する。転送先が複数あり、ハッシュ化対象属性がある場合は、これを利用して複数の対象ノードから一つを選択する。ハッシュ化対象属性がない場合は、複数の対象ノード３から空いているノード３を選択する。
したがって、ノード３を判定するに際して、前記処理対象データを処理するデータ仮想化装置をレコード単位で判定するので、処理に適したノードが選択可能となる。
ここで、事前に計算した最大処理容量の誤差等でノード３のメモリに空きがなくなった場合、リソース管理データから代替のノード３を決定し、分散処理計画を修正後に全利用ノード３に再配布し、レコードを対象のノード３に転送する（ステップ９３）。
転送の可否が判断され（ステップ９４）、データソース管理データ２２上も空きノード３がなく転送できない場合には、分散処理計画部３４と同様に、すでに実行されている処理が最も早く終わると考えられるノード３を代替ノードとして選択する（ステップ９５）。

【0046】

データ転送時に、対象のノード３の処理待ちキューに当該クエリ処理が登録されている場合、対象のノード３のディスク上等の、現在実行されている処理を阻害しない場所にデータを格納する。実行中の処理が終了後、対象のテーブルに対する分散クエリ処理の実行が開始される。これにより、実行中クエリを阻害することなく、またクエリ処理のメモリ過剰で強制終了することなくクエリを実行することが可能となる。

【0047】

ステップ９４において転送可である場合、データベースシステム単位でデータ転送が完了した時点で（ステップ９６）、対象のノードにテーブルの受信完了通知を配布する（ステップ９７）。
続いて、処理続行の可否を判断する（ステップ９８）。例えば、演算が二項処理（２つの演算結果が必要）であって、もう片方のテーブルの受信が完了してない場合や、処理待ちキューに登録されている場合は、それぞれの完了通知が配布されるまで実行は開始されない。全ての完了通知が配布されて初めて、対象ノードのクエリ処理部３８におけるクエリ処理が開始される（ステップ９９）。

【0048】

次に、クエリ処理部３８にて、クエリツリー上のそれぞれの処理が完了した後における詳細な処理フローを図１０に示す。
クエリ処理部３８では、処理終了後（ステップ１０１）、残処理の有無を判断し（ステップ１０２）、他の処理が残っている場合は、分散処理計画に従って次の処理内容を続行する（ステップ１０３）。
他の処理が残っていない場合は、分散処理計画に従ってデータ集計部３９に転送する（ステップ１０４）。

【0049】

ステップ１０３で次の処理内容を続行する場合、完了した処理の結果のテーブルに対して、次に利用する処理が二項演算の場合、対象処理ノード全体でデータの移動を行い（ステップ１０５）、もう一方の完了を待つ必要がある。そのため、処理対象の両テーブルともに完了していることを完了通知の有（ステップ１０６）や完了通知待ち（ステップ１０７）で確認してから、次の処理が開始される。
したがって、クエリ処理を行うに際し、二項演算の完了通知を待って次の処理を行うようにしたので、計画に沿ったクエリ処理を確実に行うことが可能となる。

【0050】

単項演算の場合は、他の処理に影響されることはないため、処理終了後、そのまますぐ開始される。ただし、仮にデータのサイズが処理前に比べて大きくなり、他ノードへの転送が必要となっていて、そのノードが処理待ちキューに登録されている場合は、その完了を待つ必要がある。

【0051】

次の処理に伴うデータ移動において（ステップ１０８）、メモリサイズを超えてしまった場合は（ステップ１０９）、クエリツリー上のこれまで利用してきたノードのうち、メモリが空いているノードに結果を転送する（ステップ１１０）。もし空きがない場合は、前述の代替ノード選択のロジック（ステップ９５）で転送先ノードを決定する。
完了した処理がクエリツリー上の最も根に近い最終処理の場合は、クエリ処理全体が完了となることから、最終処理の結果をデータ集計部３９に転送する。

【0052】

その後、クエリ集計部３９にて、必要に応じた最終的な処理を行って、クライアント１に結果を転送し、クエリ処理が完了する。

【0053】

上述した分散型データ仮想化システムによれば、分散処理計画部３４と処理計画配置部３５を備えることで、複数のデータ仮想化装置（ノード）３上の処理を分散化し並列処理を行うことにより、大規模データ処理に対応することが可能となる。
また、仮想スキーマ単位でテーブルを処理することで、複数仮想スキーマに対して仮想スキーマ毎にデータ仮想化装置（ノード）３へ分散することにより、並列性の向上を実現することができる。
また、仮想スキーマの処理を仮想スキーマ単位に独立化することにより、クエリ再実行の効率化及び仮想化対象のデータベースシステムの負荷軽減を実現することができる。

【符号の説明】

【0054】

１…クライアント、 ２…分散型データ仮想化システム管理装置、 ３…データ仮想化装置（ノード）、 ４…データベースシステム、 １１…分散コネクタ、 ２１…リソース管理データ、 ２２…データソース管理データ、 ２３…モデルデータ、 ３１…クエリ評価部、 ３２…分散クエリ生成部、 ３３…分散クエリ投稿部、 ３４…分散処理計画部、 ３５…処理計画配置部、 ３６…クエリ結果受信部、 ３７…データ分散部、 ３８…クエリ処理部、 ３９…データ集計部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】