(57)【特許請求の範囲】
【請求項１】
データベース検索言語を処理するデータベース検索装置において、
データベース検索言語を解析するときに、先のソート処理の処理内容と、そのソート処理の処理結果を使う後のソート処理の処理内容とから、先のソート処理に使用するメモリ資源の分割数を決定する決定手段と、
上記決定手段の決定する分割数に従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行する実行手段とを備えることを、
特徴とするデータベース検索装置。
【請求項２】
請求項１記載のデータベース検索装置において、
決定手段は、２つのソート処理がＣＰＵを多く使用するのかＩ／Ｏを多く使用するのかに応じて、メモリ資源の分割数を決定することを、
特徴とするデータベース検索装置。
【請求項３】
請求項２記載のデータベース検索装置において、
決定手段は、先のソート処理がＣＰＵネックとなっていて、後のソート処理がＩ／Ｏネックとなっている場合には、先のソート処理のＣＰＵ使用量が減ることになるようにとメモリ資源の分割数を決定し、先のソート処理がＩ／Ｏネックとなっていて、後のソート処理がＣＰＵネックとなっている場合には、後のソート処理のＣＰＵ使用量が減ることになるようにとメモリ資源の分割数を決定することを、
特徴とするデータベース検索装置。
【請求項４】
請求項１記載のデータベース検索装置において、
先のソート処理の処理内容となる可能性のあるものと、後のソート処理の処理内容となる可能性のあるものとを検索キーとするマトリックス構造に従って、メモリ資源の分割数を管理するテーブル手段を備え、
決定手段は、上記テーブル手段を索引することでメモリ資源の分割数を決定することを、
特徴とするデータベース検索装置。
【請求項５】
データベース検索言語を処理するデータベース検索装置の実現に用いられるプログラムが格納されるプログラム記録媒体であって、
データベース検索言語を解析するときに、先のソート処理の処理内容と、そのソート処理の処理結果を使う後のソート処理の処理内容とから、先のソート処理に使用するメモリ資源の分割数を決定する決定処理と、
上記決定処理の決定する分割数に従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行する実行処理とをコンピュータに実行させるプログラムが格納されることを、
特徴とするプログラム記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データベース検索言語を処理するデータベース検索装置と、その装置の実現に用いられるプログラムが格納されるプログラム記録媒体とに関し、特に、高速処理を実現するデータベース検索装置と、その装置の実現に用いられるプログラムが格納されるプログラム記録媒体とに関する。
【０００２】
ＳＱＬ文の処理では、二次記憶からのデータの読み込み、メモリ上でのデータの加工、中間結果の二次記憶への退避を用いた複数の工程を経て、結果の抽出が行われることになる。データベースを利用するデータ処理の高速化を図るためにも、このＳＱＬ文の処理に要する時間の短縮を実現する技術を構築していく必要がある。
【０００３】
【従来の技術】
ＳＱＬ文の処理では、二次記憶からのデータ（レコード）の読み込み、メモリ上でのデータの加工、中間結果の二次記憶への退避を用いた複数の工程を経て、結果の抽出が行われることになる。
【０００４】
例えば、図２１（ａ）に示すＳＱＬ文は、表Ｔ１からカラムＣ１，Ｃ２のデータを読み込み、カラムＣ１のデータの順番に従って整列させて出力せよというものである。
【０００５】
このＳＱＬ文の処理手順は、図２１（ｂ）に示すように、先ず最初の工程で、データベースから表Ｔ１のデータを読み込んでソートにＰＵＴし、その次の工程で、ソートからデータをＧＥＴしてアプリケーションに返却するという２段階の工程を踏むことになる。
【０００６】
また、図２２（ａ）に示すＳＱＬ文は、表Ｔ１からカラムＣ１，Ｃ２のデータ（例えば名前と住所）を読み込むとともに、表Ｔ２からカラムＣ２のデータ（例えば電話番号）を読み込み、その読み込んだ表Ｔ１のカラムＣ１，Ｃ２のデータに、その読み込んだ表Ｔ２のカラムＣ２のデータを結合（Ｔ１．Ｃ１＝Ｔ２．Ｃ１（例えば名前の同じもの）というものを結合）させて、表Ｔ１のカラムＣ１のデータの順番に従って整列させて出力せよというものである。
【０００７】
このＳＱＬ文の処理手順は、図２２（ｂ）に示すように、先ず最初の工程で、データベースから表Ｔ１のデータを読み込んでソート１にＰＵＴし、その次の工程で、データベースから表Ｔ２のデータを読み込んでソート２にＰＵＴし、その次の工程で、ソート１,2からデータをＧＥＴしＪＯＩＮしてソート３にＰＵＴし、その次の工程で、ソート３からデータをＧＥＴしてアプリケーションに返却するという４段階の工程を踏むことになる。
【０００８】
また、図２３（ａ）に示すＳＱＬ文は、表Ｔ１からカラムＣ１，Ｃ２のデータ（例えば支店名と売上）を読み込むとともに、そのＣ２のデータ（例えば支店名）でグルービングしつつそのＣ１のデータ（例えば売上）の合計を求めて、それを表ＤＴ１として定義し、その表ＤＴ１からカラムＣ１，Ｃ２のデータ（例えば支店名と売上合計）を読み込むとともに、表Ｔ２からカラムＣ２のデータ（例えば住所）を読み込み、その読み込んだ表ＤＴ１のカラムＣ１，Ｃ２のデータに、その読み込んだ表Ｔ２のカラムＣ２のデータを結合（ＤＴ１．Ｃ２＝Ｔ２．Ｃ１（例えば支店名の同じもの）というものを結合）させて出力せよというものである。
【０００９】
このＳＱＬ文の処理手順は、図２３（ｂ）に示すように、先ず最初の工程で、データベースから表Ｔ１のデータを読み込んでワークにＰＵＴし、その次の工程で、ワークからデータをＧＥＴして集計処理を行ってソート１にＰＵＴし、その次の工程で、データベースから表Ｔ２のデータを読み込んでソート２にＰＵＴし、その次の工程で、ソート１,2からデータをＧＥＴしＪＯＩＮしてアプリケーションに返却するという４段階の工程を踏むことになる。
【００１０】
このように、ＳＱＬ文の処理では、二次記憶からのデータの読み込み、メモリ上でのデータの加工、中間結果の二次記憶への退避を用いた複数の工程を経て、結果の抽出が行われることになるが、これらの各工程では、先の工程で処理されたデータ（レコード）が次の工程に引き継がれていくことになる。従って、ＳＱＬ文の処理にソート処理が含まれる場合には、全件をソート処理に入力してからでないと、その結果を用いる次の工程に入れないという特性がある。
【００１１】
従来技術では、この特性を考慮して、ＳＱＬ文の処理にソート処理が含まれる場合には、図２４に示すように、ソート処理に使用するメモリの全領域にインデックスを張りつつ、データをソートしていく構成を採って、その後、そのインデックスを使ってソートされたデータを読み出しつつ、その結果を用いる次の工程に入るように処理していた。
【００１２】
【発明が解決しようとする課題】
しかしながら、このような従来技術に従っていると、最大限の処理性能を引き出せないという問題点がある。
【００１３】
すなわち、図２５（ａ）に示すように、先のソート処理の工程（ソート処理とそれと同時に走る処理の工程）が、ＣＰＵよりもＩ／Ｏをより多く使用し、後のソート処理の工程（ソート処理とそれと同時に走る処理の工程）が、逆にＩ／ＯよりもＣＰＵを多く使用するような場合、Ｉ／ＯとＣＰＵの使用バランスが悪いことで処理時間が長くかかってしまうという問題点がある。
【００１４】
そして、図２５（ｂ）に示すように、先のソート処理の工程（ソート処理とそれと同時に走る処理の工程）が、Ｉ／ＯよりもＣＰＵをより多く使用し、後のソート処理の工程（ソート処理とそれと同時に走る処理の工程）が、逆にＣＰＵよりもＩ／Ｏを多く使用するような場合、Ｉ／ＯとＣＰＵの使用バランスが悪いことで処理時間が長くかかってしまうという問題点がある。
【００１５】
本発明はかかる事情に鑑みてなされたものであって、高速処理を実現する新たなデータベース検索装置の提供と、その装置の実現に用いられるプログラムが格納される新たなプログラム記録媒体の提供とを目的とする。
【００１６】
【課題を解決するための手段】
図１に本発明の原理構成を図示する。
【００１７】
図中、１は本発明を具備するデータベース検索装置であって、データベース検索言語（ＳＱＬ文）を処理するもの、２はデータベース検索装置１の備える定義ファイルであって、処理手順の作成に必要となる定義情報（カラムの属性や表の格納構造やレコード件数やデータ分布など）を管理するもの、３はデータベースであって、データベース検索装置１の検索対象となるレコードを管理するものである。
【００１８】
本発明のデータベース検索装置１は、処理手順作成手段１０と、決定手段１１と、実行手段１２と、ＳＱＬ制御手段１３とを備え、そして、本発明のデータベース検索装置１の備える定義ファイル２は、本発明を実現するためにテーブル手段２０を備える。
【００１９】
この処理手順作成手段１０は、データベース検索言語を解析することで、どの表からアクセスするといったスケジュールを決定することで処理手順を作成する。
【００２０】
決定手段１１は、処理手順作成手段１０に展開されて、データベース検索言語を解析するときに、先のソート処理の処理内容と、そのソート処理の処理結果を使う後のソート処理の処理内容とから、先のソート処理に使用するメモリ資源の分割数を決定する。
【００２１】
実行手段１２は、処理手順作成手段１０の作成した処理手順に従ってデータベース検索言語を処理するものであり、このとき、決定手段１１の決定した分割数に従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行する。
【００２２】
ＳＱＬ制御手段１３は、アプリケーションの発行するデータベース検索言語を受け取ると、処理手順作成手段１０を呼び出すことで処理手順を作成し、それを指定して実行手段１２を呼び出すことでデータベース検索言語を処理する。
【００２３】
テーブル手段２０は、先のソート処理の処理内容となる可能性のあるものと、後のソート処理の処理内容となる可能性のあるものとを検索キーとするマトリックス構造に従って、メモリ資源の分割数を管理する。
【００２４】
ここで、本発明のデータベース検索装置１の持つ機能は具体的にはプログラムで実現されるものであり、このプログラムは、フロッピィディスクなどに格納されたり、サーバなどのディスクなどに格納され、それらからデータベース検索装置１にインストールされてメモリ上で動作することで、本発明を実現することになる。
【００２５】
このように構成される本発明のデータベース検索装置１では、決定手段１１は、データベース検索言語を解析するときに、先のソート処理がＣＰＵネックとなっていて、そのソート処理の処理結果を使う後のソート処理がＩ／Ｏネックとなっている場合には、先のソート処理のＣＰＵ使用量が減ることになるようにと、先のソート処理におけるメモリ資源の分割数を決定し、先のソート処理がＩ／Ｏネックとなっていて、そのソート処理の処理結果を使う後のソート処理がＣＰＵネックとなっている場合には、後のソート処理のＣＰＵ使用量が減ることになるようにと、先のソート処理におけるメモリ資源の分割数を決定する。
【００２６】
ここで、先のソート処理の処理内容となる可能性のあるものと、後のソート処理の処理内容となる可能性のあるものとを検索キーとするマトリックス構造に従って、そのような形態を示すメモリ資源の分割数を管理するテーブル手段２０が備えられるときには、決定手段１１は、このテーブル手段２０を索引することで、先のソート処理におけるメモリ資源の分割数を決定する。
【００２７】
この決定処理を受けて、実行手段１２は、決定手段１１により決定された分割数に従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行する。
【００２８】
図２に示すように、データベース検索言語に、処理Ａを施してデータ（レコード）をソートにＰＵＴし、それに続けて、ソートからデータ（レコード）をＧＥＴして処理Ｂを施すという処理を行うことが記述されているとする。
【００２９】
ここで、図中に示すように、メモリ資源の分割数が小さいときには、処理ＡのＣＰＵの使用量は大きくなり、メモリ資源の分割数が大きいときには、処理ＡのＣＰＵの使用量は小さくなるとする。一方、メモリ資源の分割数が小さいときには、処理ＢのＣＰＵの使用量は小さくなり、メモリ資源の分割数が大きいときには、処理ＢのＣＰＵの使用量は大きくなるとする。
【００３０】
例えば、処理Ａがデータベースからデータ（レコード）を読み込んでくる処理である場合には、メモリ資源の分割数が小さいときには、大きなインデックスを張らなくてはならず探索数が増えることでＣＰＵの使用量は大きくなる。逆に、メモリ資源の分割数が大きいときには、小さなインデックスを張れば足りるのでＣＰＵの使用量は小さくなる。
【００３１】
このとき、処理Ａによりソートされたデータに対して処理を施す処理Ｂは、メモリ資源の分割数が大きいときには、小さなインデックスでソートされたデータの集合をマージソートしなければならず、ＣＰＵの使用量は大きくなる。逆に、メモリ資源の分割数が小さいときには、大きなインデックスでソートされたデータの集合をマージソートすれば足りるので、ＣＰＵの使用量は小さくなる。
【００３２】
このメモリ資源の分割数と処理Ａ，ＢのＣＰＵ使用量との間に成立する関係を考慮して、図３の上段に示すように、先のソート処理の工程（ソート処理とそれと同時に走る処理Ａの工程）がＩ／Ｏネックとなっていて、後のソート処理の工程（ソート処理とそれと同時に走る処理Ｂの工程）がＣＰＵネックとなっている場合には、決定手段１１は、先のソート処理におけるメモリ資源の分割数として小さな値を決定することで、図３の下段に示すように、ＣＰＵネックとなっている後のソート処理の工程のＣＰＵ使用量を減らし、これにより、全体の処理時間の短縮を実現する。
【００３３】
一方、図４の上段に示すように、先のソート処理の工程（ソート処理とそれと同時に走る処理Ａの工程）がＣＰＵネックとなっていて、後のソート処理の工程（ソート処理とそれと同時に走る処理Ｂの工程）がＩ／Ｏネックとなっている場合には、決定手段１１は、先のソート処理におけるメモリ資源の分割数として大きな値を決定することで、図４の下段に示すように、ＣＰＵネックとなっている先のソート処理の工程のＣＰＵ使用量を減らし、これにより、全体の処理時間の短縮を実現する。
【００３４】
この処理時間の短縮について具体的に説明するならば、「Ａ ＩＯ」を処理Ａの使用するＩ／Ｏ量、「ＳＰ ＩＯ」をソートＰＵＴの使用するＩ／Ｏ量、「Ｂ ＩＯ」を処理Ｂの使用するＩ／Ｏ量、「ＳＧ ＩＯ」をソートＧＥＴの使用するＩ／Ｏ量、「Ａ ＣＰＵ」を処理Ａの使用するＣＰＵ量、「ＳＰ ＣＰＵ」をソートＰＵＴの使用するＣＰＵ量、「Ｂ ＣＰＵ」を処理Ｂの使用するＣＰＵ量、「ＳＧ ＣＰＵ」をソートＧＥＴの使用するＣＰＵ量、「ＭＡＸ ＩＯ」を単位時間当たりに処理できるＩ／Ｏ量、「ＭＡＸ ＣＰＵ」を単位時間当たりに処理できるＣＰＵ量とするならば、先のソート処理の工程の入力時間と後のソート処理の工程の出力時間とは、図５（ａ）／図６（ａ）に示すものとなる。
【００３５】
図３の上段に示すように、先のソート処理の工程がＩ／Ｏネックとなっていて、後のソート処理の工程がＣＰＵネックとなっている場合には、この入力時間と出力時間とは図５（ｂ）に示すようになり、全体の処理時間はこの合計となる。このとき、先のソート処理におけるメモリ資源の分割数を調整することで、図３の下段に示すように、ソートＧＥＴ時のＣＰＵ量の一部「Ｘ ＣＰＵ」をソートＰＵＴに移動させ、これにより、図５（ｃ）に示すように、出力時間が短縮され改善されることになる。
【００３６】
一方、図４の上段に示すように、先のソート処理の工程がＣＰＵネックとなっていて、後のソート処理の工程がＩ／Ｏネックとなっている場合には、この入力時間と出力時間とは図６（ｂ）に示すようになり、全体の処理時間はこの合計となる。このとき、先のソート処理におけるメモリ資源の分割数を調整することで、図４の下段に示すように、ソートＰＵＴ時のＣＰＵ量の一部「Ｙ ＣＰＵ」をソートＧＥＴに移動させ、これにより、図６（ｃ）に示すように、入力時間が短縮され改善されることになる。
【００３７】
このようにして、本発明のデータベース検索装置１では、データベース検索言語を処理する構成を採るときにあって、先のソート処理の処理内容と、そのソート処理の処理結果を使う後のソート処理の処理内容とから、先のソート処理に使用するメモリ資源の分割数を決定し、それに従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行することで、Ｉ／ＯとＣＰＵとの使用バランスを図って高速処理を実現するのである。
【００３８】
【発明の実施の形態】
以下、実施の形態に従って本発明を詳細に説明する。
【００３９】
図７に、本発明を具備するデータベース検索装置１の一実施例を図示する。図中、図１で説明したものと同じものについては同一の記号で示してある。
【００４０】
この実施例に従う本発明のデータベース検索装置１は、処理手順制御表作成プログラム１００と、実行プログラム１０１と、実行プログラム１０１から呼び出される複数の検索処理用部品１０２と、ＳＱＬ制御プログラム１０３とを備え、そして、定義ファイル２は、本発明を実現するために新たに分割数決定テーブル２００を備える。
【００４１】
ここで、本発明のデータベース検索装置１に展開されるプログラムは、フロッピィディスクや回線などを介してインストールされることになる。
【００４２】
図１で説明したように、本発明のデータベース検索装置１では、ＳＱＬ文で指定される先のソート処理がＣＰＵネックとなっていて、そのソート処理の処理結果を使う後のソート処理がＩ／Ｏネックとなっている場合には、先のソート処理のＣＰＵ使用量が減ることになるようにと、先のソート処理におけるメモリの分割数を決定し、逆に、先のソート処理がＩ／Ｏネックとなっていて、そのソート処理の処理結果を使う後のソート処理がＣＰＵネックとなっている場合には、後のソート処理のＣＰＵ使用量が減ることになるようにと、先のソート処理におけるメモリの分割数を決定して、その分割数に従ってメモリを分割しソート処理を実行することで、全体の処理時間を短縮する構成を採っている。
【００４３】
本発明を実現すべく新たに定義ファイル２に設ける分割数決定テーブル２００は、このメモリの分割数の決定に用いられるものである。
【００４４】
図８に、この分割数決定テーブル２００の一実施例を図示する。
【００４５】
この実施例に従う分割数決定テーブル２００は、先のソート処理と同時に走る処理（処理Ａ）となる可能性のあるものと、後のソート処理と同時に走る処理（処理Ｂ）となる可能性のあるものとを検索キーとするマトリックス構造に従って、先のソート処理におけるメモリの分割数を管理する構成を採っている。
【００４６】
例えば、先のソート処理と同時に走る処理ＡがＪＯＩＮ処理であり、そのソート処理の処理結果を使う後のソート処理と同時に走る処理ＢがＧＲＯＵＰ ＢＹの集計処理である場合には、先のソート処理におけるメモリの分割数が“５０”になるということを管理するのである。
【００４７】
次に、ソート処理に用いるメモリの分割数と、レコードの格納／取出に必要となる比較回数との関係について説明する。
【００４８】
ＰＵＴ時のソート処理は、メモリ上にインデックスを張ってソートしながら格納する。インデックスを持つことにより、レコードは二分木検索が可能になる。このとき、１件のレコードを格納するために必要となる比較回数は、
ｌｏｇ2 （既に格納されているレコード件数）
である。
【００４９】
従って、レコード件数をＮとするならば、メモリが分割されていない場合には、全てのレコードを格納するために必要となる比較回数は、
0003694193.tif 000002
という式に従って、
Ｎ×（ｌｏｇ2 Ｎ−１／ｌｏｇ２）
となる。
【００５０】
この式から分かるように、レコード格納域が大きくなれば大きくなる程、レコードの検索コストが大きくなり、ＰＵＴ時に必要とされるＣＰＵ量は大きくなる。
【００５１】
そこで、レコード格納域のサイズに上限を設けて、これを超えるときには、新たなレコード格納域を用いることで検索コストが大きくならないようにすることが考えられる。図９（ａ）に示すように、メモリをｋ個に分割することでｋ個のレコード格納域を用意したとする。１つのレコード格納域に格納されるレコード件数は“Ｎ／ｋ”である。
【００５２】
従って、１つのレコード格納域に、全てのレコードを格納するために必要となる比較回数は、上述の式から分かるように、
（Ｎ／ｋ）×〔ｌｏｇ2 （Ｎ／ｋ）−（１／ｌｏｇ２）〕
となるので、ｋ個の全レコード格納域に全てのレコードを格納するために必要となる比較回数は、これをｋ倍した
Ｎ×〔ｌｏｇ2 （Ｎ／ｋ）−（１／ｌｏｇ２）〕
となる。
【００５３】
一方、メモリが分割されていない場合には、ＧＥＴ時にマージソートする必要がないものの、メモリが分割されているときには、図９（ｂ）に示すように、ＧＥＴ時にマージソートする必要がある。
【００５４】
この場合、レコード格納域がｋ個あるときに、１件のレコードを取り出すために必要となる比較回数は“ｌｏｇ2 ｋ”であることから、全てのレコードを取り出すために必要となる比較回数は、
Ｎ×ｌｏｇ2 ｋ
となる。
【００５５】
このように、メモリをｋ個に分割する場合に、ＰＵＴ時に必要となるＣＰＵコストは、
Ｎ×〔ｌｏｇ2 （Ｎ／ｋ）−（１／ｌｏｇ２）〕×（キー比較のコスト）
となり、ＧＥＴ時に必要となるＣＰＵコストは、
Ｎ×ｌｏｇ2 ｋ×（キー比較のコスト）
となる。
【００５６】
この２つのＣＰＵコストの合計は、
Ｎ×〔ｌｏｇ2 Ｎ−（１／ｌｏｇ２）〕×（キー比較のコスト）
となることから分かるように、ｋに依存しない。従って、ソート処理に用いるメモリを分割しても、全体のＣＰＵコストは増加することはない。
【００５７】
しかしながら、ソート処理に用いるメモリを分割すると、図１０に示すように、その分割数ｋが大きいときには、ＰＵＴ時のＣＰＵコストが小さくなるともに、ＧＥＴ時のＣＰＵコストが大きくなる。一方、その分割数ｋが小さいときには、ＰＵＴ時のＣＰＵコストが大きくなるとともに、ＧＥＴ時のＣＰＵコストが小さくなる。
【００５８】
これから、ＰＵＴのソート処理がＩ／Ｏネックとなっていて、そのＰＵＴのソート処理の処理結果を使うＧＥＴのソート処理がＣＰＵネックとなっているときには、ＰＵＴのソート処理に用いるメモリの分割数ｋを小さくすることで、図３に示したように全体の処理時間の短縮が実現でき、一方、ＰＵＴのソート処理がＣＰＵネックとなっていて、そのＰＵＴのソート処理の処理結果を使うＧＥＴのソート処理がＩ／Ｏネックとなっているときには、ＰＵＴのソート処理に用いるメモリの分割数ｋを大きくすることで、図４に示したように全体の処理時間の短縮が実現できることになる。
【００５９】
本発明のデータベース検索装置１は、この点に着目して、ＳＱＬ文で指定される処理の高速化を実現するものである。
【００６０】
図１１に、本発明を実現するためにＳＱＬ制御プログラム１０３が実行する処理フローの一実施例、図１２に、本発明を実現するために処理手順制御表作成プログラム１００が実行する処理フローの一実施例、図１３に、本発明を実現するために実行プログラム１０１が実行する処理フローの一実施例を図示する。次に、これらの処理フローに従って、本発明について詳細に説明する。
【００６１】
ＳＱＬ制御プログラム１０３は、アプリケーションがＳＱＬ文を発行すると、図１１の処理フローに示すように、先ず最初に、ステップ１で、アプリケーションの発行するＳＱＬ文を受け取る。続いて、ステップ２で、そのＳＱＬ文を指定して、処理手順制御表作成プログラム１００を呼び出すことで、処理手順制御表を作成する。
【００６２】
続いて、ステップ３で、作成した処理手順制御表を指定して実行プログラム１０１を呼び出すことで、実行プログラム１０１からＳＱＬ文の処理結果を受け取る。続いて、ステップ４で、その処理結果をアプリケーションに返却して、処理を終了する。
【００６３】
このようにしてＳＱＬ制御プログラム１０３から呼び出されると、処理手順制御表作成プログラム１００は、図１２の処理フローに示すように、先ず最初に、ステップ１で、定義ファイル２０に格納される表の定義情報を参照しつつ、ＳＱＬ制御プログラム１０３から受け取るＳＱＬ文を構文解析し意味解析する。
【００６４】
続いて、ステップ２で、その解析結果を使い、定義ファイル２０に格納される表の最適化情報を参照しつつ、ＳＱＬ文の規定する処理手順を最適な形で決定する。すなわち、図２１（ｂ）や図２２（ｂ）や図２３（ｂ）に示したような処理手順を決定するのである。
【００６５】
続いて、ステップ３で、決定した処理手順にソート処理があるのか否かを判断して、ソート処理があることを判断するときには、ステップ４に進んで、先のソート処理と同時に走る処理（処理Ａ）と、その処理結果を使う後のソート処理と同時に走る処理（処理Ｂ）との組み合わせを抽出する。
【００６６】
続いて、ステップ５で、定義ファイル２０から分割数決定テーブル２００を読み込み、ステップ４で抽出した処理の組み合わせを検索キーにして、その分割数テーブル２００を索引することで、先のソート処理におけるメモリの分割数を決定する。
【００６７】
続いて、ステップ６で、ステップ２で決定した処理手順と、ステップ５で決定したメモリ分割数（ソート処理に対応付けて決定したもの）とを記述する処理手順制御表を作成する。一方、ステップ３で、ステップ２で決定した処理手順にソート処理がないことを判断するときには、その決定した処理手順のみを記述する処理手順制御表を作成する。
【００６８】
そして、続くステップ７で、その作成した処理手順制御表をＳＱＬ制御プログラム１０３に渡して、処理を終了する。
【００６９】
このようにして、処理手順制御表作成プログラム１００は、ＳＱＬ制御プログラム１０３から呼び出されると、ＳＱＬ文の規定する処理手順を決定するとともに、その処理手順に含まれるソート処理に対応付けてメモリ分割数を決定する。そして、それらを記述する処理手順制御表を作成して、それをＳＱＬ制御プログラム１０３に渡すように処理するのである。
【００７０】
従来技術では、ＳＱＬ文の規定する処理手順のみを決定して、それをＳＱＬ制御プログラム１０３に渡していたのに対して、本発明を実現する処理手順制御表作成プログラム１００では、その処理手順に含まれるソート処理に対応付けてメモリ分割数を決定して、それをＳＱＬ制御プログラム１０３に渡していくように処理している。
【００７１】
このメモリ分割数の決定処理は、上述したように、図８に示したようなテーブル構造を持つ分割数決定テーブル２００を索引することで行われる。
【００７２】
例えば、ＳＱＬ制御プログラム１０３から図２１（ａ）に示したＳＱＬ文を受け取るときには、先のソート処理（ＰＵＴ側）と同時に走る処理がデータベースからのレコード読込処理であり、その処理結果を使う後のソート処理（ＧＥＴ側）と同時に走る処理がアプリケーションへの返却であることから、先のソート処理（ＰＵＴ側）におけるメモリ分割数として“３０”を決定する。
【００７３】
これは、データベースからのレコードの読込処理では、Ｉ／Ｏを多く使いＣＰＵはほとんど使わないのに対して、アプリケーションへの返却処理では、Ｉ／ＯもＣＰＵもほとんど使用しない。これから、ＣＰＵはどちらも同じ程度空いてるので、どちらかと言えば、メモリの分割数を小さくしてＣＰＵの使用をＰＵＴ側に持っていくことで、Ｉ／Ｏと同時にＣＰＵを使用していくようにする点に、その理由がある。
【００７４】
また、ＳＱＬ制御プログラム１０３から図２２（ａ）に示したＳＱＬ文を受け取るときには、先のソート１，２処理（ＰＵＴ側）と同時に走る処理がデータベースからのレコード読込処理であり、その処理結果を使う後のソート３処理（ＧＥＴ側）と同時に走る処理がＪＯＩＮ処理であることから、先のソート１処理（ＰＵＴ側）におけるメモリ分割数として“１”を決定するとともに、先のソート２処理（ＰＵＴ側）におけるメモリ分割数として“１”を決定する。
【００７５】
これは、データベースからのレコード読込処理では、Ｉ／Ｏを多く使いＣＰＵはほとんど使わないのに対して、ＪＯＩＮ処理では、ＣＰＵを多く使いＩ／Ｏはほとんど使わない。これから、ＰＵＴ側ではＩ／Ｏネックになる可能性が高く、ＧＥＴ側ではＣＰＵネックになる可能性が高いので、メモリの分割数を小さくすることで、積極的にＣＰＵの使用をＰＵＴ側に持っていくことに、その理由がある。
【００７６】
そして、先のソート３処理（ＰＵＴ側）と同時に走る処理がＪＯＩＮ処理であり、その処理結果を使う後のソート処理（ＧＥＴ側）と同時に走る処理がアプリケーションへの返却であることから、先のソート３処理（ＰＵＴ側）におけるメモリ分割数として“７０”を決定する。
【００７７】
これは、ＪＯＩＮ処理では、ＣＰＵを多く使いＩ／Ｏはほとんど使わないのに対して、アプリケーションへの返却処理では、Ｉ／ＯもＣＰＵもほとんど使用しない。これから、ＰＵＴ側はＣＰＵネックになる可能性が高いのに対して、ＧＥＴ側はＩ／Ｏネックになるのかどうか分からないので、どちらかと言えば、メモリの分割数を大きくしてＣＰＵの使用をＧＥＴ側に持っていくことに、その理由がある。
【００７８】
また、ＳＱＬ制御プログラム１０３から図２３（ａ）に示したＳＱＬ文を受け取るときには、先のソート１処理（ＰＵＴ側）と同時に走る処理がＧＲＯＵＰ ＢＹの集計処理であり、その処理結果を使う後のソート処理（ＧＥＴ側）と同時に走る処理がＪＯＩＮ処理であることから、先のソート１処理（ＰＵＴ側）におけるメモリ分割数として“５０”を決定する。
【００７９】
これは、ＧＲＯＵＰ ＢＹの集計処理もＪＯＩＮ処理も、ＣＰＵを多く使いＩ／Ｏはほとんど使わない。これから、ＰＵＴ側もＧＥＴ側もＣＰＵネックになる可能性が高いので、メモリの分割数として平均的な値を用いることで、ＰＵＴ側とＧＥＴ側で平均的にＣＰＵを使用させるようにしていくことに、その理由がある。
【００８０】
そして、先のソート２処理（ＰＵＴ側）と同時に走る処理がデータベースからのレコードの読込処理であり、その処理結果を使う後のソート処理（ＧＥＴ側）と同時に走る処理がＪＯＩＮ処理であることから、先のソート２処理（ＰＵＴ側）におけるメモリ分割数として“１”を決定する。
【００８１】
これは、データベースからのレコード読込処理では、Ｉ／Ｏを多く使いＣＰＵはほとんど使わないのに対して、ＪＯＩＮ処理では、ＣＰＵを多く使いＩ／Ｏはほとんど使わない。これから、ＰＵＴ側ではＩ／Ｏネックになる可能性が高く、ＧＥＴ側ではＣＰＵネックになる可能性が高いので、メモリの分割数を小さくすることで、積極的にＣＰＵの使用をＰＵＴ側に持っていくことに、その理由がある。
【００８２】
図１２の処理フローに従って、処理手順制御表作成プログラム１００により処理手順制御表が作成され、図１１の処理フローに従って、ＳＱＬ制御プログラム１０３によりその処理手順制御表を指定して呼び出されると、実行プログラム１０１は、図１３の処理フローに示すように、先ず最初に、ステップ１で、ＳＱＬ制御プログラム１０３から処理手順制御表を受け取る。
【００８３】
続いて、ステップ２で、その受け取った処理手順制御表の指定する処理手順から、順番に従って処理手順を１つ選択し、続くステップ３で、全ての処理手順の選択を終了したのか否かを判断して、全ての処理手順の選択終了を判断するときには、ステップ４に進んで、これから説明する処理に得られた処理結果をＳＱＬ制御プログラム１０３に渡して、処理を終了する。
【００８４】
一方、ステップ３で、全ての処理手順の選択を終了していないことを判断するとき、すなわち、ステップ２で処理手順を選択できたことを判断するときには、ステップ５に進んで、その選択した処理手順がソート処理であるのか否かを判断する。
【００８５】
この判断処理により、ソート処理であることを判断するときには、ステップ６に進んで、処理手順制御表で指定するメモリ分割数を特定して、その特定したメモリ分割数に従ってソート処理に用いるメモリを分割しつつ、対応する検索処理用部品１０２を呼び出していくことでソート処理を実行してから、ステップ２に戻っていく。
【００８６】
一方、ステップ５で、選択した処理手順がソート処理でないことを判断するときには、ステップ７に進んで、対応する検索処理用部品１０２を呼び出していくことで指定される処理を実行してから、ステップ２に戻っていく。
【００８７】
このようにして、実行プログラム１０１は、処理手順制御表作成プログラム１００の作成した処理手順制御表で指定されるメモリ分割数に従って、ソート処理に用いるメモリを分割して、その分割されたメモリを使ってソート処理を実行していくことで、全体の処理時間の短縮を図っていくのである。
【００８８】
図１４ないし図１７に従って、この実行処理について具体的に説明するならば、レコードをソートすべくＰＵＴしていくときには、図１４（ａ）に示すように、分割したメモリのサイズに合わせてインデックスを作成しつつ、レコードをレコード格納域に格納（ソート順序はインデックスにより保証されている）していく。
【００８９】
この格納処理によりレコード格納域が満杯になるときには、図１４（ｂ）に示すように、レコード格納域に格納されたレコードをレコード退避域に退避する。このとき、レコードをソートの順番に入れ換えることでインデックスは不要になる。
【００９０】
この後、図１４（ｃ）に示すように、再び、レコード格納域のサイズに合わせてインデックスを作成しつつ、レコードをメモリに格納し、レコード格納域が満杯になるときには、図１５（ａ）に示すように、レコード格納域に格納されたレコードを新たなレコード退避域に退避していく。そして、この処理を繰り返していくことで、メモリが満杯になるときには、図１５（ｂ）に示すように、二次記憶にレコードを退避していく。
【００９１】
一方、ソートされたレコードをＧＥＴするときには、退避された単位で先頭から読み出してマージソートしていくことになるが、レコード格納域が満杯になっていないときには、図１６（ａ）に示すように、インデックスから読み出すだけでよい。
【００９２】
そして、メモリだけ使用していて二次記憶を使用していないときには、図１６（ｂ）に示すように、メモリ上に展開されるレコード格納域／レコード退避域に格納されるレコードをマージソートしていくことになる。更に、二次記憶を使用しているときには、図１７に示すように、それも含めた形でマージソートしていくことになる。なお、メモリに二次記憶から読み出していく領域が残されていない場合には、レコード格納域に格納されるレコードを二次記憶に退避させることで、その領域を確保することになる。
【００９３】
このようにして、実行プログラム１０１は、処理手順制御表作成プログラム１００の作成した処理手順制御表で指定されるメモリ分割数に従って、ソート処理に用いるメモリを分割して、その分割されたメモリを使ってソート処理を実行していくことで、全体の処理時間の短縮を図っていくのである。
【００９４】
図８に示した分割数決定テーブル２００では、マトリックス構造に従ってメモリ分割数を管理する構成を採ったが、各処理毎のＣＰＵ及びＩ／Ｏの使用量を定性的に管理する図１８（ａ）に示すような分割数決定テーブル２００を用意したり、各処理毎のＣＰＵ及びＩ／Ｏの使用量を定量的に管理する図１８（ｂ）に示すような分割数決定テーブル２００を用意して、処理手順制御表作成プログラム１００が、このテーブルデータを使ってプログラム処理的にメモリ分割数を決定するという方法を採ることも可能である。ここで、図１８（ｂ）に示すような分割数決定テーブル２００を用意する場合、レコード数やデータ分布などを変数とする関数を使って、ＣＰＵ及びＩ／Ｏの使用量を定量的に管理する構成を採ることも可能である。
【００９５】
このような分割数決定テーブル２００が用意されるときには、処理手順制御表作成プログラム１００は、先のソート処理と同時に走る処理と、その処理結果を使う後のソート処理と同時に走る処理との組み合わせを抽出すると、例えば図１９及び図２０に示す処理フローに従って、先のソート処理におけるメモリ分割数を決定することになる。
【００９６】
すなわち、処理手順制御表作成プログラム１００は、先のソート処理と同時に走る処理と、その処理結果を使う後のソート処理と同時に走る処理との組み合わせを抽出すると、図１９及び図２０の処理フローに示すように、先ず最初に、ステップ１で、分割数決定テーブル２００を索引することで、先のソート処理と同時に走る処理のテーブルデータを取得し、続くステップ２で、分割数決定テーブル２００を索引することで、後のソート処理と同時に走る処理のテーブルデータを取得する。
【００９７】
続いて、ステップ３で、その取得したテーブルデータに従って、先のソート処理がＩ／Ｏネックで、後のソート処理がＣＰＵネックとなる可能性が高いのか否かを判断して、その可能性が高いことを判断するときには、ステップ４に進んで、先のソート処理におけるメモリ分割数として小さな値を決定することで、先のソート処理のＣＰＵ量を増加させ、後のソート処理のＣＰＵ量を減少させるように設定する。
【００９８】
一方、ステップ３で、先のソート処理がＩ／Ｏネックで、後のソート処理がＣＰＵネックとなる可能性が高くないことを判断するときには、ステップ５に進んで、先のソート処理がＣＰＵネックで、後のソート処理がＩ／Ｏネックとなる可能性が高いのか否かを判断して、その可能性が高いことを判断するときには、ステップ６に進んで、先のソート処理におけるメモリ分割数として大きな値を決定することで、先のソート処理のＣＰＵ量を減少させ、後のソート処理のＣＰＵ量を増加させるように設定する。
【００９９】
一方、ステップ５で、先のソート処理がＣＰＵネックで、後のソート処理がＩ／Ｏネックとなる可能性が高くないことを判断するときには、ステップ７に進んで、先のソート処理がＩ／Ｏを多く使用するのか否かを判断して、多く使用することを判断するときには、ステップ８に進んで、先のソート処理におけるメモリ分割数として小さめの値を決定することで、先のソート処理のＣＰＵ量を増加させるように設定する。
【０１００】
一方、ステップ７で、先のソート処理がＩ／Ｏを多く使用しないことを判断するときには、ステップ９に進んで、先のソート処理がＣＰＵを多く使用するのか否かを判断して、多く使用することを判断するときには、ステップ１０に進んで、先のソート処理におけるメモリ分割数として大きめの値を設定することで、先のソート処理のＣＰＵ量を減少させるように設定する。
【０１０１】
一方、ステップ９で、先のソート処理がＣＰＵを多く使用しないことを判断するときには、ステップ１１に進んで、後のソート処理がＩ／Ｏを多く使用するのか否かを判断して、多く使用することを判断するときには、ステップ１２に進んで、先のソート処理におけるメモリ分割数として大きめの値を設定することで、後のソート処理のＣＰＵ量を増加させるように設定する。
【０１０２】
一方、ステップ１１で、後のソート処理がＩ／Ｏを多く使用しないことを判断するときには、ステップ１３に進んで、後のソート処理がＣＰＵを多く使用するのか否かを判断して、多く使用することを判断するときには、ステップ１４に進んで、先のソート処理におけるメモリ分割数として小さめの値を設定することで、後のソート処理のＣＰＵ量を減少させるように設定する。
【０１０３】
一方、ステップ１３で、後のソート処理がＣＰＵを多く使用しないことを判断するときには、ステップ１５に進んで、先のソート処理におけるメモリ分割数として中間の値を設定する。
【０１０４】
このようにして、各処理毎のＣＰＵ及びＩ／Ｏの使用量を定性的に管理する図１８（ａ）に示すような分割数決定テーブル２００を用意したり、各処理毎のＣＰＵ及びＩ／Ｏの使用量を定量的に管理する図１８（ｂ）に示すような分割数決定テーブル２００を用意して、処理手順制御表作成プログラム１００が、このテーブルデータを使ってメモリ分割数を決定するという方法を採ることもできるのである。
【０１０５】
これまで説明していなかったが、本発明は、並列化に適した方式となっている。
【０１０６】
それは、ＰＵＴのフェーズで、レコード全体を複数に分割してソートするという構成を採っていることから、それ自身が並列化に適する構成となっているからである。
【０１０７】
そして、満杯になったレコード格納域に対しては、ソートされた順にレコードを退避させてやれば、その退避させたレコードについてはインデックスが不要となるので、そのレコード格納域をソート処理に再利用できる構成となっているからである。
【０１０８】
これにより、インデックス領域を削減できることになるという他に、退避されたレコードがソートされた順番となっているので、二次記憶上や通信処理で、そのままの形式で処理できるという特徴がある。例えば、マージソート処理においては、先頭のレコードから順番に処理していけばよいことになり、通信処理や二次記憶からの読出処理を効率的に行うことができる。
【０１０９】
並列化する場合に、各プロセッサが本発明を実現すべく実行する処理は、上述した単一構成のプロセッサが本発明を実現すべく実行する処理と基本的に変わる所はない。ただ、各プロセッサのマージソートしたものを全プロセッサでマージソートする必要があるという点が加わるだけである。
【０１１０】
このマージソートにあたって、各プロセッサが他のプロセッサのメモリを参照できないという構成になっているときには、通信処理が加わることになるが、上述した理由から、退避されたレコードをそのまま通信していけばよいので、この通信処理も容易に達成できるものである。
【０１１１】
【発明の効果】
以上説明したように、本発明では、データベース検索言語を処理する構成を採るときにあって、先のソート処理の処理内容と、そのソート処理の処理結果を使う後のソート処理の処理内容とから、先のソート処理に使用するメモリ資源の分割数を決定し、それに従ってメモリ資源を分割して、その分割メモリ資源を単位にしてデータベース検索言語で指定されるソート処理を実行することで、Ｉ／ＯとＣＰＵとの使用バランスを図ることができるようになり、これにより、高速処理を実現できるようになる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明の説明図である。
【図３】本発明の説明図である。
【図４】本発明の説明図である。
【図５】本発明の説明図である。
【図６】本発明の説明図である。
【図７】本発明の一実施例である。
【図８】分割数決定テーブルの一実施例である。
【図９】レコードの格納／取出に必要となる比較回数の説明図である。
【図１０】メモリ分割数とＣＰＵコストとの間の関係の説明図である。
【図１１】ＳＱＬ制御プログラムの処理フローである。
【図１２】処理手順制御表作成プログラムの処理フローである。
【図１３】実行プログラムの処理フローである。
【図１４】本発明の説明図である。
【図１５】本発明の説明図である。
【図１６】本発明の説明図である。
【図１７】本発明の説明図である。
【図１８】分割数決定テーブルの他の実施例である。
【図１９】処理手順制御表作成プログラムの処理フローである。
【図２０】処理手順制御表作成プログラムの処理フローである。
【図２１】ＳＱＬ文の処理手順の説明図である。
【図２２】ＳＱＬ文の処理手順の説明図である。
【図２３】ＳＱＬ文の処理手順の説明図である。
【図２４】従来技術の説明図である。
【図２５】従来技術の説明図である。
【符号の説明】
１    データベース検索装置
２    定義ファイル
３    データベース
１０  処理手順作成手段
１１  決定手段
１２  実行手段
１３  ＳＱＬ制御手段
２０  テーブル手段
【図１】
0003694193.tif 000003
【図２】
0003694193.tif 000004
【図３】
0003694193.tif 000005
【図４】
0003694193.tif 000006
【図５】
0003694193.tif 000007
【図６】
0003694193.tif 000008
【図７】
0003694193.tif 000009
【図８】
0003694193.tif 000010
【図９】
0003694193.tif 000011
【図１０】
0003694193.tif 000012
【図１１】
0003694193.tif 000013
【図１２】
0003694193.tif 000014
【図１３】
0003694193.tif 000015
【図１４】
0003694193.tif 000016
【図１５】
0003694193.tif 000017
【図１６】
0003694193.tif 000018
【図１７】
0003694193.tif 000019
【図１８】
0003694193.tif 000020
【図１９】
0003694193.tif 000021
【図２０】
0003694193.tif 000022
【図２１】
0003694193.tif 000023
【図２２】
0003694193.tif 000024
【図２３】
0003694193.tif 000025
【図２４】
0003694193.tif 000026
【図２５】
0003694193.tif 000027