×この技術を簡単クリック査定この機能をご利用いただくには、会員登録(無料)が必要です。出願した特許の牽制数、引用された数などを知る事ができます。気になる技術や特許をブックマークしておけば、いつでも後から読むことができます。後で印刷するために、公報をPDFでダウンロードできます。会員登録してastamuseを使えば、もっと簡単に便利にお使いいただけます。会員登録(無料)「astamuse」は世界中の挑戦したい社会課題に挑戦し、未来を創る人のプラットフォームです。分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラムこの技術は特許登録された実績があります。※この項目の情報は公開日時点(2015年6月8日)のものです。大規模なデータを複数のデータ仮想化装置に分散して並列処理を行う分散型データ仮想化システムを得る。従った処理を行うクエリ処理部38と、前記処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部39とを備える。概要この情報を共有FacebookTwitterGoogle+LinkedIn背景データ仮想化システム(又はマルチデータベースシステム)は、複数のデータベースシステムを仮想的に一つのデータベースシステムに見せるために、各データベースシステムが持つテーブルを論理的に一つのシステムに集約して管理し、ユーザのクエリに対応するデータベースシステムにクエリを投稿する。代表的なデータ仮想化システムは、例えば特許文献1に示されるように、複数の階層的なデータベースシステムを、データマッピングにより仮想スキーマ(実際の物理テーブルをユーザに提供する論理テーブルに変換する処理を定義したもの)に統合し、クエリ実行時において処理対象となるデータを保持するデータベースシステムにクエリを分配するよう構成されている。各データベースシステムで実行されたクエリの結果は中央に収集され、仮想スキーマに従って一つに統合して結果を出力するシステムとなっている。大規模なデータを複数のデータ仮想化装置に分散して並列処理を行う分散型データ仮想化システムを得る。従った処理を行うクエリ処理部38と、前記処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部39とを備える。従った処理を行うクエリ処理部と前記分散処理計画に従った処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部とを備えることを特徴とする分散型データ仮想化システム。従った処理を行うクエリ処理手順と前記分散処理計画に従った処理の結果を受信し、集計した結果を前記クライアントに送信するデータ集計手順とを含むことを特徴とするクエリ処理方法。含む請求項2に記載のクエリ処理方法。前記クエリプランから作成したプランツリーを根(クエリ結果)から順に前記クエリ処理を実行するノードを決める対象となるテーブルを降順探索する手順と、前記テーブルが仮想スキーマにおける出力テーブルである場合に、当該仮想スキーマにおける最大出力容量と、データ仮想化装置群における利用状況及び利用可能メモリサイズからデータ仮想化装置群を選択する手順とを含む請求項3に記載のクエリ処理方法。請求項5前記データ分散手順は、前記各データベースシステムから前記処理対象データを取得する手順と、各テーブルの1レコードずつ指定するデータ仮想化装置を判定する手順とを含む請求項2に記載のクエリ処理方法。請求項6前記クエリ処理手順は、処理完了により次の処理を行う場合に、単項演算であるか二項演算であるかを判定する手順と、二項演算である場合は、二項演算の完了通知を待って次の処理を行うためのデータ移動とクエリ処理を行う手順とを含む請求項2に記載のクエリ処理方法。0001本発明は、一つ以上のデータベースシステムに対する論理的なモデルを提供するデータ仮想化システムに関し、クエリ処理を複数のデータ仮想化装置に分散して並列処理する分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラムに関する。背景技術0002データ仮想化システム(又はマルチデータベースシステム)は、複数のデータベースシステムを仮想的に一つのデータベースシステムに見せるために、各データベースシステムが持つテーブルを論理的に一つのシステムに集約して管理し、ユーザのクエリに対応するデータベースシステムにクエリを投稿する。代表的なデータ仮想化システムは、例えば特許文献1に示されるように、複数の階層的なデータベースシステムを、データマッピングにより仮想スキーマ(実際の物理テーブルをユーザに提供する論理テーブルに変換する処理を定義したもの)に統合し、クエリ実行時において処理対象となるデータを保持するデータベースシステムにクエリを分配するよう構成されている。各データベースシステムで実行されたクエリの結果は中央に収集され、仮想スキーマに従って一つに統合して結果を出力するシステムとなっている。発明が解決しようとする課題0004特許文献1のように、複数のデータベースシステムに跨がるクエリ処理の最終的な統合処理は、データ仮想化システム上で実行する必要がある。このとき、一つ以上のデータベースシステムから得られるデータが、データ仮想化システムの物理メモリサイズを超えるほど大規模であった場合、実行できずにエラー終了してしまう可能性がある。OSのスワップ機構もしくはデータ仮想化システムのディスク退避の機能の実装によってある程度のサイズまでは対応可能であると考えられるが、それによる遅延は非常に大きく、その許容量を超えてしまった場合にも同様に終了してしまうという問題がある。0005ユーザにとってデータ仮想化システムを利用する最大のメリットは、個々のデータベースシステムを意識せず利用できる点にあり、データ仮想化システムがアクセスするデータベースシステムのクエリ処理の結果が大規模かどうかを意識させることはデータ仮想化システムの利益を損なうこととなる。0006本発明は上記実情に鑑みて提案されたものであり、データ仮想化システムにおいて、一台のデータ仮想化装置では処理しきれない大規模なデータを、複数のデータ仮想化装置に分散して並列処理を行う分散型データ仮想化システム、クエリ処理方法及びクエリ処理プログラムを提供することを目的としている。従った処理の結果を各クエリ処理部から受信し、集計した結果を前記クライアントに送信するデータ集計部とを備えることを特徴としている。従った処理の結果を受信し、集計した結果を前記クライアントに送信するデータ集計手順とを含むことを特徴としている。含むことを特徴としている。前記テーブルが仮想スキーマにおける出力テーブルである場合に、当該仮想スキーマにおける最大出力容量と、データ仮想化装置群における利用状況及び利用可能メモリサイズからデータ仮想化装置群を選択する手順とを含むことを特徴としている。各テーブルの1レコードずつ指定するデータ仮想化装置を判定する手順とを含むことを特徴としている。二項演算である場合は、二項演算の完了通知を待って次の処理を行うためのデータ移動とクエリ処理を行う手順とを含むことを特徴としている。0013請求項7は、請求項2の各手順をコンピュータに実行させるクエリ処理プログラム。あることを特徴している。発明の効果0014本発明(請求項1及び請求項2)によれば、分散処理計画と処理計画配置を行うことで、複数のデータ仮想化装置上の処理を分散化し並列処理を行うことができ、大規模データ処理に対応することが可能となる。仮想スキーマを利用した分散による並列性の向上を実現することができる。仮想スキーマの処理を独立化することにより、クエリ再実行の効率化及び仮想化対象のデータベースシステムの負荷軽減を実現することができる。0015請求項3及び請求項4によれば、分散クエリ結果の容量と、仮想スキーマの処理における最大処理容量を考慮することで、適切なデータ仮想化装置群の選択が可能となる。0016請求項5によれば、データ仮想化装置を判定するに際して、各テーブルの1レコードずつ指定するので、処理に適したデータ仮想化装置を選択することができる。0017請求項6によれば、クエリ処理を行うに際し、二項演算の完了通知を待って次の処理を行うようにしたので、計画に沿ったクエリ処理を確実に行うことが可能となる。0018請求項7によれば、複数のデータ仮想化装置上の処理を分散化し並列処理を行うことができるクエリ処理方法をコンピュータ上に構築することができる。図面の簡単な説明0019本発明の分散型データ仮想化システムの全体構成図を示すモデル図である。一般的なデータ仮想化システムにおける仮想スキーマの例を示す分散型データ仮想化システムにおけるデータ仮想化装置の構成を説明するためのブロック図である。分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理において、データ仮想化装置が各データベースシステムの処理結果を受け取るまでのデータの流れを示すブロック図である。分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理において、データ仮想化装置が各データベースシステムの処理結果を分散処理するときのデータの流れを示すブロック図である。データ仮想化装置の分散処理計画部における処理手順を示すフローチャート図である。a」のクエリプランをプランツリーへの変換例を示すモデル図である。ついての処理手順を示すフローチャート図である。作成した分散処理計画を利用するデータ仮想化装置群に配布し、データベースシステムにおけるクエリ処理が完了した直後のデータ分散処理について、図9に示す。フローチャート図である。データ仮想化装置のクエリ処理部において、クエリツリー上のそれぞれの処理が完了した後の処理の流れを図10に示す。フローチャート図である。図10図5図6図9実施例0020本発明の分散型データ仮想化システムの実施形態について、図1を参照して説明する。本発明の分散型データ仮想化システムは、データ仮想化システムにおいて、一台のデータ仮想化装置では処理しきれない大規模なデータを、複数のデータ仮想化装置に分散して並列処理を行うシステムであり、図1に示すように、システムを利用するクライアント1と、分散型データ仮想化システム管理装置2と、1つ以上のデータ仮想化装置3と、分散型データ仮想化システムが利用する1つ以上のデータベースシステム4から構成されている。各データ仮想化装置3と、クライアント1及び分散型データ仮想化システム管理装置2とはネットワークXを介して接続されている。各データ仮想化装置3と各データベースシステム4とはネットワークYを介して接続されている。図10021クライアント1、分散型データ仮想化システム管理装置2、各データ仮想化装置3及び各データベースシステム4は、それぞれ、オペレーティングシステム(OS)を含む基本プログラムや各種の基本デバイスが記憶されたROMと、各種のプログラムションやデータが記憶されるハードディスクドライブ装置(HDD)と、CR-ROMやDVD等の記憶媒体からプログラムやデータを読み出すメディアドライブ装置と、プログラムを実行するCPUと、このCPUにワークエリアを提供するRAMと、外部装置と通信するパラレル/シリアルI/Fとを主要部分とする一般的な構成を備えたコンピュータ上に構築されている。上述した構成を有する各コンピュータにおいて、メディアドライブ装置で読み取られたクエリ処理プログラムがHDDにインストールされることで分散型データ仮想化システムが構築される。0022クライアント1は、データ仮想化装置3の利用状況や稼働状況から適切な一つのデータ仮想化装置3に接続し、クエリの投稿と結果の受信を行う分散コネクタ11を備えている。0023分散型データ仮想化システム管理装置2は、それぞれのデータ仮想化装置3が持つリソース容量及び現在の利用状況(リソース情報)を保持するリソース管理データ21と、各データベースシステム4上にあるテーブル情報(物理モデルやサイズ、クエリによるサイズ変更差分)を持つデータソース管理データ22と、その物理モデルに対する仮想スキーマの構成、変換手順(論理モデル情報)及び消費リソース量に関する情報(消費情報)を持つモデルデータ23を備えている。0024モデルデータ23が有する仮想スキーマは、ユーザがクエリで指定する論理テーブルを、どのデータベースシステム4上のテーブルに対して、どのように処理を行うかに関する仮想スキーマ情報を管理している。データ仮想化装置3にクエリが投稿された場合の仮想スキーマによる一般的な処理例について、図2に示す。ここでは、クライアント1からテーブルaへのSQLクエリが投稿されたとする。データ仮想化装置3上では、テーブルaに対して、テーブルsとテーブルtのUNION処理の結果が仮想スキーマaと定義されている。テーブルsは、実際にはデータベースシステムS上にあるテーブルであり、テーブルtは、データベースシステムTにあるテーブルである。図20025このとき、クライアント1が投稿したSQLクエリに対して、テーブルaを仮想スキーマaの処理に変換する。このクエリは、データ仮想化装置3上で実行されるクエリ(UNION)、データベースシステムS上で実行されるクエリ(テーブルsへのSQLクエリ)、データベースシステムT上で実行されるクエリ(テーブルtへのSQLクエリ)に分解され、各データベースシステム4にクエリが投稿される。それぞれのデータベースシステム4の処理結果は、クエリを投稿したデータ仮想化装置3に収集され、予め作られたクエリ(UNION)処理を実行してクライアント1に送信される。0026データ仮想化装置3は、図3〜図5に示すように、クエリ評価部31と、分散クエリ生成部32と、分散クエリ投稿部33と、分散処理計画部34と、処理計画配置部35と、クエリ結果受信部36、データ分散部37と、クエリ処理部38と、データ集計部39とを備えて構成されている。図3図4図50027クエリ評価部31は、クライアント1からクエリ処理要求を受け取り、モデルデータ23から仮想スキーマ情報を取得Aして、この情報に従ってクエリ処理の手順を定義したクエリプランを生成する(図4)。分散クエリ生成部32は、データソース管理データ22からテーブル情報を取得Bし、この情報を基にクエリプランに従って適切なデータベースシステム4向けのクエリを生成(再構成)する(図4)。分散クエリ投稿部33は、分散クエリ生成部32で生成したクエリを各データベースシステム4に投稿Cする(図3)。図3図40028分散処理計画部34は、リソース管理データ21からリソース情報を取得Dし、モデルデータ23から論理モデル情報及び消費情報を取得Eし、データソース管理データ22からテーブル情報を取得Fし、クエリ評価部31で生成されたクエリプランに対してこれらの情報を利用して、処理内容と処理を実施するデータ仮想化装置3を選択する分散処理計画を生成する。処理計画配置部35は、分散処理するデータ仮想化装置群に分散処理計画部34で生成した分散処理計画を分配Gする(図3)。図30029クエリ結果受信部36は、各データベースシステム4からのクエリ実行結果の受信Hし、データ分散部37への出力Iを行う(図4)。データ分散部37は、リソース管理データ21からリソース情報を受信Jするとともに、処理計画配置部35から分散処理計画を受け取り、この計画に基いて各データベースシステム4から受信したクエリ実行結果をレコード単位で各データ仮想化装置3のデータ分散部37に分配K又は受信する(図5)。クエリ処理部38は、データ分散部37との間で分散処理計画に基いた処理Lを行う(図5)。データ集計部39は、処理Lの結果を各クエリ処理部38から受信Mして集計し、その結果をクライアント1の分散コネクタ11に転送Oする(図5)。データ仮想化装置を構成する各データ仮想化装置3は、それぞれ同様の機能を備えて構成されている。図4図50030データベースシステム4は、クエリを処理するクエリエンジン41と、実データを保管するデータソース42から構成されている。0031次に、分散型データ仮想化システムにおけるデータ仮想化処理及び分散クエリ処理の一連の流れについて説明する。ユーザは、クライアント1の分散コネクタ11を経由してクエリを投稿する。クエリ評価部31はクエリを受け取り、クエリの処理対象となるテーブルに対応する仮想スキーマをモデルデータ23から呼び出し、ユーザが投稿したクエリに仮想スキーマの処理を適用した形でクエリプランを生成する。このクエリプランには、データ仮想化装置(以下、ノードと称する)3群に接続されたデータベースシステム4群の実際のテーブルが含まれる。0032分散クエリ生成部32は、このテーブルとデータソース管理データ22を突合し、対象のデータベースシステム4を明確にする。クエリプランを基に実際のデータベースシステム4で実行可能なクエリを生成する。分散クエリ投稿部33は、この実行可能なクエリを、対象となるデータベースシステム4にそれぞれ投稿する。0033分散処理計画部34は、クエリ評価部31がクエリプランを生成した段階で、このクエリプランを利用してノード3群の分散処理計画を作成する。分散処理計画部34における処理手順について、図6及び図7を参照して説明する。図6図70034クエリプラン(文字データ)を基に、処理対象テーブルと処理内容の流れを、処理毎の中間テーブルも含めて表すプランツリーを生成する(ステップ61)。プランツリーは、図7に示すように、テーブルに対する処理が連なるように構成されている。次に、モデルデータ23及びデータソース管理データ22を取得し(ステップ62)、プランツリー上の処理内容から各データベースシステム4から得られる分散クエリ結果の容量を計算する(ステップ63)。図70035この結果から、仮想スキーマで得られるテーブルや中間テーブル、最終的な結果の出力容量と、仮想スキーマの処理における最大処理容量を計算する(ステップ64)。最大処理容量は、必要なノードの数を決める際に有用なデータとなる。計算した容量を利用して、必要なノードの数及び適用先のノード(自身なのか別なのか)を決定する(ステップ65)。このとき、最終的にデータを収集するノード3が、現在分散処理を作成しているノード3と異なる場合には(ステップ66)、クライアント1の分散コネクタ11に接続先変更を依頼し(ステップ67)、分散処理計画を完了する(ステップ68)。このような処理を行うことで、分散クエリ結果の容量と、仮想スキーマの処理における最大処理容量が考慮されるので、適切なノードの選択が可能となる。a」のクエリプランをプランツリーに変換した例を示す。ユーザが投稿したSQLクエリは、図7の例のように、3つのSQLクエリに分解される。これらのうち物理モデルであるテーブルsとテーブルtへのクエリの結果は、中間テーブルとしてノード3上に収集され、仮想スキーマaで定義されたUNION処理の対象として処理される。図2図70037このような流れについて、処理の前後のテーブルを明確に表したものが図7のプランツリーである。各データベースシステムから得られるテーブル容量としてデータソース管理データ22から取得したテーブルsのサイズ(30GB)とテーブルtのサイズ(10GB)が示される。中間テーブルの出力容量として、Projection処理後のテーブルsのサイズ(6GB)とテーブルtのサイズ(2GB)、及び、モデルデータ23にある仮想スキーマ処理のサイズ計算メソッドを適用した処理後のサイズ(8GB)が示されている。図70038次に、図6における「各テーブルの処理ノード群選択」(ステップ65)についての詳細の処理フローを図8に示す。処理ノード群の選択が開始された場合(ステップ81)、作成したプランツリーを根(クエリ結果)から順に、クエリ処理を実行するノードを決める対象となるテーブルを降順探索する(ステップ82)。図6図80039探索で対象のテーブルが発見された場合(ステップ83)、対象テーブルが、論理テーブル(仮想スキーマにおける出力テーブル)、仮想スキーマ内のテーブル(仮想スキーマにおける物理テーブル又は中間テーブル)、仮想スキーマ外のテーブル(論理テーブルに対する処理における中間テーブル又はクエリ結果)のいずれであるかのテーブル種別を行う(ステップ84)。ステップ84のテーブル種別で、論理テーブルを発見した場合、当該仮想スキーマにおける最大出力容量と、ノード群における利用状況及び利用可能メモリサイズからノード群を選択する(ステップ85)。仮想スキーマ内のテーブルである場合は、仮想スキーマ全体で処理容量を計算しているため、ここでは無視して再度探索を続ける。0040ステップ84のテーブル種別で、仮想スキーマ外のテーブル(中間テーブル又はクエリ結果)を発見した場合は、当該テーブルの出力容量とノード群の利用可能メモリサイズを基に、ツリーにおける下位(葉側)のテーブルに対する処理を行ったノードの中から処理するノード群を選択する(ステップ86)。このとき、できる限りデータ通信が少なくなるよう、テーブルデータが多く含まれているノードを優先する。併せて、利用するノードのリソース管理データを更新する。ここで空いているノードがない場合、すでに実行されている処理が最も早く終わると考えられるノードを選択し、対象ノードのリソース管理データの処理待ちキューの対象として記録される。0041ノード群を選択後、当該ノード群へのデータ転送を行うために、ハッシュ化対象属性を選択する(ステップ87)。この属性は、直前の処理内容に依存し、例えばJOINのように、特定の属性毎の処理が必要な場合には選択されるが、UNION処理のようなハッシュ化が必要のない場合には選択されない。0042以上の処理をプランツリー全体に対して行った後(ステップ88)、処理ノード群選択の処理が完了する(ステップ89)。このように、仮想スキーマをベースとしたノード群の選択を行うことで、依存性のあるテーブル間の処理を特定のノードに集めることができ、クエリ処理に対して高い並列性を出すことが可能となる。0043更には、仮にある特定のノードが実行中に異常終了し、ノード単位で再実行が不可能になったとしても、異常終了したノードで実行された仮想スキーマの処理のみを再実行すればよく、ノード群におけるクエリ処理と、対象となるデータベースシステムへのクエリ処理要求を最低限に抑えることが可能となる。0044次に、作成した分散処理計画を利用するノード群に配布し、データベースシステムにおけるクエリ処理が完了した直後のデータ分散処理の詳細フローについて、図9に示す。各データベースシステム4にクエリを投稿したノード3において、データベースシステム4の実行結果が受信されると(ステップ91)、クエリ結果受信部36は、この結果データをストリーム的にデータ分散部37に1レコードずつ渡す(ステップ92)。図90045このときデータ分散部37は、処理計画配置部35から取得した分散処理計画を基に、対象となるノード3のデータ分散部37へ結果データを転送する。転送先が複数あり、ハッシュ化対象属性がある場合は、これを利用して複数の対象ノードから一つを選択する。ハッシュ化対象属性がない場合は、複数の対象ノード3から空いているノード3を選択する。したがって、ノード3を判定するに際して、各テーブルの1レコードずつ指定するので、処理に適したノードが選択可能となる。ここで、事前に計算した最大処理容量の誤差等でノード3のメモリに空きがなくなった場合、リソース管理データから代替のノード3を決定し、分散処理計画を修正後に全利用ノード3に再配布し、レコードを対象のノード3に転送する(ステップ93)。転送の可否が判断され(ステップ94)、データソース管理データ22上も空きノード3がなく転送できない場合には、分散処理計画部34と同様に、すでに実行されている処理が最も早く終わると考えられるノード3を代替ノードとして選択する(ステップ95)。0046データ転送時に、対象のノード3の処理待ちキューに当該クエリ処理が登録されている場合、対象のノード3のディスク上等の、現在実行されている処理を阻害しない場所にデータを格納する。実行中の処理が終了後、対象のテーブルに対する分散クエリ処理の実行が開始される。これにより、実行中クエリを阻害することなく、またクエリ処理のメモリ過剰で強制終了することなくクエリを実行することが可能となる。0047ステップ94において転送可である場合、データベースシステム単位でデータ転送が完了した時点で(ステップ96)、対象のノードにテーブルの受信完了通知を配布する(ステップ97)。続いて、処理続行の可否を判断する(ステップ98)。演算が二項処理(2つの演算結果が必要)であって、もう片方のテーブルの受信が完了してない場合や、処理待ちキューに登録されている場合は、それぞれの完了通知が配布されるまで実行は開始されない。全ての完了通知が配布されて初めて、対象ノードのクエリ処理部38におけるクエリ処理が開始される(ステップ99)。0048次に、クエリ処理部38にて、クエリツリー上のそれぞれの処理が完了した後における詳細な処理フローを図10に示す。クエリ処理部38では、処理終了後(ステップ101)、残処理の有無を判断し(ステップ102)、他の処理が残っている場合は、分散処理計画に従って次の処理内容を続行する(ステップ103)。他の処理が残っていない場合は、分散処理計画に従ってデータ集計部39に転送する(ステップ104)。図100049ステップ103で次の処理内容を続行する場合、完了した処理の結果のテーブルに対して、次に利用する処理が二項演算の場合、対象処理ノード全体でデータの移動を行い(ステップ105)、もう一方の完了を待つ必要がある。そのため、処理対象の両テーブルともに完了していることを完了通知の有(ステップ106)や完了通知待ち(ステップ107)で確認してから、次の処理が開始される。したがって、クエリ処理を行うに際し、二項演算の完了通知を待って次の処理を行うようにしたので、計画に沿ったクエリ処理を確実に行うことが可能となる。0050単項演算の場合は、他の処理に影響されることはないため、処理終了後、そのまますぐ開始される。仮にデータのサイズが処理前に比べて大きくなり、他ノードへの転送が必要となっていて、そのノードが処理待ちキューに登録されている場合は、その完了を待つ必要がある。0051次の処理に伴うデータ移動において(ステップ108)、メモリサイズを超えてしまった場合は(ステップ109)、クエリツリー上のこれまで利用してきたノードのうち、メモリが空いているノードに結果を転送する(ステップ110)。空きがない場合は、前述の代替ノード選択のロジック(ステップ95)で転送先ノードを決定する。完了した処理がクエリツリー上の最も根に近い最終処理の場合は、クエリ処理全体が完了となることから、最終処理の結果をデータ集計部39に転送する。0052その後、クエリ集計部39にて、必要に応じた最終的な処理を行って、クライアント1に結果を転送し、クエリ処理が完了する。0053上述した分散型データ仮想化システムによれば、分散処理計画部34と処理計画配置部35を備えることで、複数のデータ仮想化装置(ノード)3上の処理を分散化し並列処理を行うことにより、大規模データ処理に対応することが可能となる。仮想スキーマ単位でテーブルを処理することで、複数仮想スキーマに対して仮想スキーマ毎にデータ仮想化装置(ノード)3へ分散することにより、並列性の向上を実現することができる。仮想スキーマの処理を仮想スキーマ単位に独立化することにより、クエリ再実行の効率化及び仮想化対象のデータベースシステムの負荷軽減を実現することができる。39...データ集計部。ページトップへこの技術を出願した法人この情報を共有FacebookTwitterGoogle+LinkedInこの技術を発明した人物この情報を共有FacebookTwitterGoogle+LinkedInページトップへ関連する挑戦したい社会課題この情報を共有FacebookTwitterGoogle+LinkedIn癌(5大疾病)のない社会を実現する癌のない社会を実現すると、全世界の患者約1,750万人を助け、年間約760万人の亡くなる命を救うことができます。厚労省が定めた五大疾病に含まれる癌は、周囲の組織を破壊し、治療が遅れると全身に転...最終更新日:2018/06/11高い食料自給率を実現する高い食料自給率を実現すると、国内での食料の安定供給や、他国の問題による食料不足などの問題を防止する可能性が高まります。イノベーションを導く多くの企業が膨大な労力と費用をかけて新たな市場や事業を生み出そうとしている中「イノベーション」にかかわるデータのニーズはかつてないほどの高まりを見せいます。