JP3747525B2

JP3747525B2 - 並列データベースシステム検索方法

Info

Publication number: JP3747525B2
Application number: JP22640696A
Authority: JP
Inventors: 守弘岩田; 正士土田; 幸生中野; 憲宏原
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1996-08-28
Filing date: 1996-08-28
Publication date: 2006-02-22
Anticipated expiration: 2016-08-28
Also published as: US5940289A; US20070226179A1; US6564205B2; US7225179B2; US6959302B2; US20040002949A1; JPH1069488A; US20050283493A1; US20020038300A1

Description

【０００１】
【発明の属する技術分野】
本発明は、デ−タベ−ス管理システムに関し、特にリレ−ショナルデ−タベ−ス管理システムに適した問合せの並列処理に好適な問合せ処理方法に関する。
【０００２】
【従来の技術】
本発明に関連する従来技術として、ＳＱＬ３のAbstruct Data Typeと、並列データベースシステムの２点について記述する。
【０００３】
最初に、ＳＱＬ３のAbstruct Data Typeについて記述する。
事務データ処理を中心にしてリレーショナルデータベース、主にＳＱＬデータベースシステムの適用が進んでいる。また、従来のリレーショナルデータベースの枠組みでは効率的に扱うことが難しい、複雑な構造を持ったデータを扱うことを、１つの目的とするオブジェクトデータベースの実用も進められた。
【０００４】
一方で、リレーショナルデータベースを拡張して、複雑な構造を持ったデータを扱うことが研究されており、ＳＱＬ３で標準化が進められている。ＳＱＬ３では、Abstruct Data Type（抽象データ型、以下ADTと記す）という複雑な構造を持ったユーザ定義のデータ（型）を扱うことができる。ADTは、複数の、属性と呼ばれるデータ（以下では、サブデータと呼ぶことにする）を、関数インタフェースで隠蔽し、型間で継承関係を持つことができる、オブジェクト指向の考えを取り入れた複雑なデータを扱うことができる。CREATE TYPEで始まるADTの定義系SQL文により型を定義する。定義した型は、整数型、文字型などのシステム定義の型と同様に変数宣言や、表の列定義などに用いることができる。各型により複雑な構造を持ったデータを作成し使用することが可能になる。ＳＱＬ３、ADTについては、Andrew E. Wade, Ph.D. :"Object Query Standards",ACM SIGMOD Record, Vol.25, No.1, pp87-92, March 1996などに記載がある。また、ＳＱＬ３の標準化のDraftは、ISO/IEC JTC1/SC21/WG3 DBL-MCI-004, ISO Working Draft Database Language SQL, 1996である。
【０００５】
次に、並列データベースシステムについて記述する。
リレーショナルデータベースシステムにおいては、データを複数のデータベース処理サーバに分割して配置して、並列にアクセスすることで、性能の向上を図ることが容易である。このような並列データベースシステムに対する要求は、データ量の増大にともなって強まってきている。並列データベースシステムについては、DeWitt,D.,et.al.:"Parallel Database Systems: The Future of High Performance Database Systems", CACM, Vol.35, No.6, 1992.に記載されている。
【０００６】
並列データベースシステムの構成としては、ホスト計算機のユーザアプリケーションプログラム（以下UAPと呼ぶことにする）からのデータベースに対する問い合わせを解析しコンパイルするサーバ（フロントエンドサーバと呼ぶことにする）と、データが格納されるディスク装置にアクセスしデータの操作を行う複数のサーバ（データベース操作サーバと呼ぶことにする）を有する。以下では、簡単のため、１つのホスト、１つのフロントエンドサーバと複数のデータベース操作サーバの構成で説明を行う。しかし、１つ、または、複数のホストからの複数の問い合わせに対して、複数のフロントエンドサーバが取りあつかうことができる。この場合でも１つ１つの問い合わせに対しては、１つのホスト、１つのフロントエンドサーバと複数のデータベース操作サーバの構成であり、以下の説明、及び、本発明に問題無く適用される。
【０００７】
一般にデータベースに対する問い合わせ（以下、データベース問い合わせと呼ぶことにする）であるＳＱＬは、Ｃ言語などの計算機言語（以下親言語と呼ぶことにする）に埋めこんだ形で使われることが多い（以下、埋込型ＳＱＬと呼ぶことにする）。データベースへの検索、及びデータベースへのデータの更新、削除と挿入などのデータベース問い合わせを、ホストの親言語から発し、データベースシステムが問い合わせの解析、実行を行ない、結果をホストに返す。ホストの親言語は、結果を受け取り、条件判定などの制御処理や代入や計算などの加工処理に用いる。ストアドプロシジャのように、制御処理や加工処理を含めたデータベース問い合わせを発する場合でも本発明の適用は可能である。（この場合、検索、挿入、更新、削除処理などデータベース操作サーバ側で行なう処理を、制御処理や加工処理などフロントエンドサーバ側で行なう処理と分ける意味で、以下、データベース操作文と呼ぶことがある）。ストアドプロシジャについては、片山初子:ストアド・プロシージャとトリガーを使いこなす, NIKKEI OPEN SYSTEMS, No.2, pp.133-144,1993.などに記載されている。
【０００８】
親言語には、複数のデータベース問い合わせを埋め込むことができ、親言語の変数を介して、結果のやりとりを行なうことができる。変数による値の受け渡しは、親言語の解析結果の処理方法による。変数ごとに値を格納する領域を決めておき、変数の値を使用する場合は、その領域を見るように変数のバインドを決めておく方法などが挙げられる。
【０００９】
以下に、埋込型ＳＱＬによる、一般的な、並列データベースシステムの内部形式の処理手順の作成、転送と実行の例を記す。データベース操作の結果に対する加工や制御を、埋込型ＳＱＬで書かれたUAPの制御構文が行う。データベース問い合わせは１文ずつUAPとのフロントエンドサーバにネットワークを介して送られる。そして、コンパイラによって構文解析、意味解析、最適化、コンパイルを行うことによって、送られたデータベース問い合わせに基づいた実際のデータベース操作を行うための内部形式の処理手順を作成する。内部形式の処理手順は、インタプリタで解釈実行するコードや、実行形式のコードである。コンパイルに必要な定義情報などはフロントエンドサーバからアクセスできるディクショナリ情報として存在する。作成された処理手順は、実際にデータベース操作を行うデータベース操作サーバにネットワークを通じて転送し起動要求により実行する。実際にデータベース操作を行なうサーバは通常操作する表の分割に関する情報で決まる。表の分割に関する情報は表定義で指定し、ディクショナリに入る。データベース操作サーバはプロセサと１つ以上のディスク装置を有する。データベース操作サーバのキャッシュに内部形式の処理手順を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。並列データベースシステムにおいてはデータベース操作サーバは複数存在し、ＳＱＬの処理の並列化がなされる。ＳＱＬの処理の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にUAPとのフロントエンドサーバの結果受取り処理を通じて、実行結果がUAPに返され、実行結果の加工や制御を行う。以下ＳＱＬ文１文ずつについて同じ処理を繰り返す。
【００１０】
【発明が解決しようとする課題】
データベース問い合わせで扱えるデータが、複数のデータ（ADTでいう属性、以下サブデータと呼ぶ）の集まりであるとき、データに対する検索、更新、挿入、加工、制御などの処理は、サブデータ１つ１つを別個に処理する場合と、サブデータの集まりであるデータ全体を処理する場合の２通りが考えられる。ここで、データベースに対する問い合わせの使用方法として次のようなものが考えられる。まず、先に行なう問い合わせで、データ全体を検索する。そして、親言語の変数を介して、後の問い合わせに、検索したデータを渡す。後の問い合わせで渡されたデータのサブデータ１つ１つを別個に処理する。このような使用方法の場合、後の問い合わせが、検索したデータのサブデータ全てを使用するとは限らない。しかし、従来技術で述べた並列データベースシステムの技術をそのままADTに適用する場合、検索問い合わせでは、ホストに返す結果であるデータは、データのあるデータベース操作サーバから、後の問い合わせの解析や実行を行なうフロントエンドサーバに全て転送される。使用しないサブデータがLOBデータなど大規模なデータの場合、データベース操作サーバから、フロントエンドサーバに、使用しない大規模データを転送すると、転送時間が増大することになり、問い合わせにかかる時間が大きくなる。本発明は、データベース操作サーバから、フロントエンドサーバへ、後の処理で使用するデータのみを転送することを実現することで、問い合わせ時間を小さくするのが目的である。
【００１１】
【課題を解決するための手段】
上記目的を達成するために、先に行なう検索問い合わせのときには、複数のサブデータからなるデータに対しては、データベース操作サーバから、フロントエンドサーバに、データの位置情報のみを返す。位置情報は、データベース操作サーバ上でのデータのアドレスと、データベース操作サーバの識別子を含む。後の問い合わせには変数を介して、位置情報を渡す。後の問い合わせは、渡された位置情報と、データ内での各サブデータの位置のディクショナリ情報と、問い合わせで必要なサブデータの識別子により、データベース操作サーバにあるデータの各サブデータを取り出す。位置情報はデータのあるデータベース操作サーバの識別子を含むので、データのあるデータベース操作サーバにデータ取り出し要求を行なえる。また、位置情報はデータベース操作サーバ上でのデータのアドレスを含むので、データを取出せる。データ内での各サブデータの位置のディクショナリ情報と、必要なサブデータの識別子により、データから、必要なサブデータの位置を割り出し、個々のサブデータを取り出すことができる。取り出したサブデータはフロントエンドサーバに返され、そのサブデータを使用する処理を行なうことが可能になる。
【００１２】
データベース操作サーバから、フロントエンドサーバへ、後の処理で使用するデータのみを転送するため、使用しないデータが大きい場合、問い合わせ時間を小さくする目的が実現される。
【００１３】
サブデータを使用する後の処理が、先の検索処理のデータに対する更新処理である場合、更新処理の内部形式の処理手順が、データベース操作サーバ側で、必要とするサブデータを受け取り更新処理を行なうことができる。この場合、データベース操作サーバから、フロントエンドサーバへのサブデータの転送が無くなるため、さらに問い合わせの時間が小さくなる。
【００１４】
また、上記、先に行なう検索処理で、データの位置情報のみを取り出し、後の処理でサブデータを取り出す方法を第一の方法とし、
先に行なう検索処理で、サブデータを含むデータ全体をフロントエンドサーバ側に取り出し、後の処理に渡す方法を第二の方法とし、
サブデータのデータ長や通信にかかる時間などから計算した各方法のコスト比較や、LOBデータなどあらかじめシステムで与える基準値より長いサブデータの有無などにより、２つの方法から１つ選択することで、状況に応じて細かく、問い合わせ時間が小さい方法を選択することができ、問い合わせ時間を小さくする上記目的が達成される。
【００１５】
本発明はデータベースの主流であるリレーショナルデータベース、ＳＱＬにより説明を行う。また、本発明で扱う複雑な構造を持ったデータとして、ＳＱＬ３のADTにより説明を行なう。しかし、親言語に、データベース問い合わせが埋め込まれ、複数のデータベース問い合わせの間でデータのやりとりができ、かつ、複数のデータの集まりからなるデータを扱えるデータベース管理システムであれば本発明を適用可能である。
【００１６】
【発明の実施の形態】
以下において本発明の一実施例を図面を用いて説明する。
図１は本発明の実施例の構成図である。データベースへの問い合わせ１２２に対するフロントエンドの役割をするデータベースサーバ１２と、データベースに対する操作を行う役割をする複数のデータベース操作サーバ１３で構成される。フロントエンドデータベースサーバ１２とデータベース操作サーバ１３は、高速な相互結合ネットワークで繋がっているものとする。
【００１７】
ただし、ネットワークで繋がる複数プロセッサの並列データベースシステムで無く、単一プロセッサのシステムでも、各サーバの役割として並列なプロセスを割り当てていれば、本発明を適用可能である。
【００１８】
フロントエンドサーバ１２は、外部のホスト１１とネットワークで繋がっているものとする。ただし、本発明はフロントエンドサーバ１２とデータベース操作サーバ１３の間の転送量を削減するものなので、ホストの役割をデータベースシステム側に取り込み、内部の高速なネットワークで繋げる代案や、ホストの役割とフロントエンドのデータベースサーバを１つに統合する代案に対しても本発明を適用できる。また一連の問い合わせが、ホストのUAPで無く、ストアドプロシジャの場合でも、複数のサブデータに対する検索問い合わせ、変数による受け渡し、後の問い合わせでサブデータを使用するという形で対応を付けることができ、本発明を適用できる。
【００１９】
図１はデータベース問い合わせの解析、実行の例であり、表、型などの定義文の解析は後述の図１０を参照する。データベース問い合わせか、定義文かは、意味解析で判定できる。解析１０１にはその判定を含む。
【００２０】
まず、先に行なう検索問い合わせ１２２ａをフロントエンドサーバ１２で解析１０１することで、内部形式の処理手順１２５を作成する。内部形式の処理手順は、実行形式のコードであっても、インタプリタ用のコードであっても良い。
【００２１】
検索問い合わせ１２２ａの実行に対して、サブデータへの操作は無いものとし１３２、かつ、データベース操作文であるため１３３、内部形式の処理手順１２５をデータベース操作サーバ１３に転送する１０２。データベース操作サーバ１３は処理手順１２５を受け取り１１１、処理手順を実行し、複数のサブデータからなるデータの検索に対しては、データベース操作サーバの識別子IDとデータのアドレスを取得する１１２。検索の結果１２６はフロントエンドサーバ側に結果転送を行なう１１３。フロントエンドサーバ側は結果を受け取り１０３受け取った結果を、後の問い合わせ１２２ｂに変数を介して渡す情報１２７としてUAPに返す１０５。
【００２２】
次に、サブデータを使用する後の問い合わせ１２２ｂをフロントエンドサーバ１２で解析１０１する。入力となる変数が存在するので、変数にバインドした情報１２７がUAPから渡される。また、変数にバインドした情報１２７が、複数のサブデータからなるデータの位置情報１２６の場合、サブデータを取り出すためのオフセット情報１２４をディクショナリ１４から取得する。上記情報１２７、１２４により、サブデータを取得する内部形式の処理手順と、取得したサブデータを使用する問い合わせの処理手順を作成する。
【００２３】
問い合わせ１２２ｂの実行に対して、サブデータへの操作であるため１３１、サブデータ取得１０６を行なう。先の検索処理で取得した位置情報１２６のデータベース操作サーバの識別子から、データのあるデータベース操作サーバがわかるので、サブデータ取り出しに必要な情報１２８とともに、サブデータ取り出しの要求をそのデータベース操作サーバ１３に出す。サブデータ取り出しに必要な情報１２８とは、そのデータベース操作サーバ内でのデータのアドレスと、必要なサブデータを取り出すためのオフセット情報１２４である。どの、サブデータが必要かは、解析１０１時に抽出することができ、サブデータを取得する内部形式に情報を埋め込んで置く。データベース操作サーバ側は、サブデータ取り出しの要求があると、データのアドレスとサブデータのオフセット位置の情報からサブデータを取り出し、要求元のフロントエンドサーバ１２にサブデータ１２９を返す。実施例では、データベース操作サーバ１３側の処理を、データのアドレスとサブデータのオフセット情報を受け取り、サブデータを返す、システム括り付けの処理で表しているが、解析時に同様の処理を行なう内部形式の処理手順を作成し、実行時にデータベース操作サーバに処理手順を転送し、実行する代案でも本発明を適用できる。
【００２４】
フロントエンドサーバ側は、必要なサブデータ１２９を受け取る１０７。サブデータを受け取る場所は、解析１０１時に、問い合わせ１２２ｂの主となる処理であるサブデータを使用する処理の内部形式の処理手順中のサブデータ使用場所からポイントしておく。後の問い合わせがデータベース操作文である１３３無し１３４にかかわらず、続く内部形式の処理手順の実行１０４、１１２でサブデータを使用することができる。
【００２５】
先に行なう、複数のサブデータからなるデータの検索問い合わせ１２２ａで、位置情報１２６のみを取得し、後に行なう、サブデータを使用する問い合わせ１２２bで、必要とするサブデータ１２９のみを取得するため、使用しないデータがLOBのように大規模なデータの場合、問い合わせ時間を小さくすることが可能になる。
【００２６】
図２は、複数のサブデータからなるデータの例である。型の定義例２１、型から作成されるデータの例２２、データの検索問い合わせ例２３を記述する。
【００２７】
データ型の定義には、各サブデータ（ADTでいう属性）の名称と型の宣言２０１を含む。サブデータの型は、システム定義の型でも、ユーザ定義の型でも良い。型のデータに対する関数や手続きの定義２０２や、型同士の継承関係も指定することができるが、指定が無くても良い。
【００２８】
複数のサブデータからなるデータは、システム定義の型と同じく、表定義２２に使用する。表へ、データの挿入を行なうことで、住所データのように、郵便番号、住所、電話番号のサブデータ２０４からなるデータ２０３を作成することができる。
【００２９】
作成したデータは、検索などの問い合わせを行なうことができる２０５、２０６。２０５は住所データのサブデータ郵便番号を検索する問い合わせである。２０６は住所データのサブデータ住所がYokohamaである住所データを検索する問い合わせである。このように、サブデータの検索も、複数のサブデータからなるデータ自身の検索も行なうことができる。
【００３０】
図３は本発明の内、図１の位置情報１２６の例である。位置情報１２６は、データベース操作サーバ１３の識別子３０１と、サーバ１３内でのデータのアドレス３０２を含む。フロントエンドサーバ１２などでの制御処理に用いる情報として、型の識別子などの付加的な情報を含んでも良い。データベース操作サーバの識別子３０１は、データを格納するデータベース操作サーバを特定できる情報であればよい。データのアドレス３０２は、データ格納の実アドレスでも、メモリ上にデータを取り出し先頭アドレスからのオフセットによる論理的なアドレスで表してもよい。
【００３１】
図４は本発明の内、図１の変数にバインドする情報１２７の例である。図４は、複数のサブデータからなるデータの検索結果をバインドする場合である。複数のサブデータからなるデータ全体の検索で無い場合は、変数にバインドする情報は、検索するデータ自身である。変数にバインドする情報１２７は、データベース操作サーバ１３の識別子４０１と、サーバ１３内でのデータのアドレス４０２を含む。フロントエンドサーバ１２などでの制御処理に用いる情報として、型の識別子などの付加的な情報を含んでも良い。データベース操作サーバの識別子４０１は、データを格納するデータベース操作サーバを特定できる情報であればよい。データのアドレス４０２は、データ格納の実アドレスでも、メモリ上にデータを取り出しオフセットによる論理的なアドレスで表してもよい。図２１の実施例のように、コストによりデータをフロントエンド側に置くか、バックエンド側に置くか選択する方式を行なう場合には、データがフロントエンド側にあるか、バックエンド側にあるかを表す情報を変数にバインドする情報に含める。ホストのUAP側では、サブデータを含むデータの検索の場合、変数の領域として、変数にバインドする情報を受け取るだけの長さ分の領域を用意する必要がある。
【００３２】
図５は本発明の内、図１の内部形式の処理手順１２５の例である。内部形式の処理手順１２５は、インタプリタで解釈実行するコード及び各コードに付随する情報からなる。情報には、取り出すデータの型や長さの情報、サブデータのオフセット情報、取り出したデータを置く場所の情報など、処理に応じた各種の情報がある。情報には次に実行するコードの情報も含む。次に実行するコードが条件分岐の情報により分かれることも可能である。サブデータ取り出し用のコード５０１に付随する情報５０２はデータの位置情報１２６や使用するサブデータのオフセット情報を含む。内部形式の処理手順は、インタプリタで解釈実行するコードで無く、実行形式のコードであっても本発明を適用可能である。図５は位置情報１２６からサブデータ１２９を取り出す内部形式の処理手順５１と、サブデータを使用する内部形式の処理手順５２の関係を示すものである。処理手順５１により取り出すサブデータ１２９を置く場所５０５を共用メモリ上でのオフセット位置５０６で表し、処理手順５２でサブデータを使用するコードの情報５０４に入れて置く。上記の情報により、処理手順５１で取り出したサブデータ１２９を処理手順５２側で使用することができる。サブデータを取り出す内部形式の処理手順５１と、サブデータを使用する内部形式の処理手順５２は、１つの処理手順にまとめた形であっても良い。図５の例では、サブデータ１２９を取り出す処理は、取り出すサブデータの情報５０２を用いてコード５０１ａにより解釈実行する形であるが、取り出す手順を表す複数のコードからなっていても良い。図５の例では、サブデータ１２９を使用する場合の内部形式の処理手順であるが、サブデータを使用しない内部形式の処理手順の場合は、サブデータを取り出す処理手順５１や、サブデータ１２９を置く場所５０５のオフセット位置の情報は必要無い。位置情報１２６を取り出す内部形式の処理手順の場合、解釈実行に必要な情報として、取り出す位置情報の長さ分の領域へのオフセット位置を含む。
【００３３】
図６は本発明の内、図１のサブデータのオフセット情報１２４の例である。サブデータのオフセット情報１２４は、複数のサブデータからなるデータごとに作成する。サブデータのオフセット情報１２４は、サブデータの識別子６０１、データ型６０２、データ長６０３、オフセット位置６０４を含む。オフセット位置は、データの先頭などの基準となるアドレスからのオフセットである。各サブデータがクラスタリングしてあれば、各サブデータの、オフセット位置は、データ長６０３から計算できるため、データ型６０２やオフセット位置６０４は無くてもかまわない。また、可変長サブデータが存在する場合は、ディクショナリ１４にオフセット位置を置くことができない。この場合、オフセット位置をデータ１３０に組み入れる代案を適用できる。サブデータの識別子６０１とオフセットの対応が取れるようにデータ１３０に組みいれる。例えば、サブデータの識別子が、データの中の定義順に、１から順にふられている場合、データ１３０に同じ順にオフセットを置くようにする方法が考えられる。
【００３４】
図７は本発明の内、図１のサブデータ取り出し用情報１２８の例である。サブデータ取り出し用情報１２８は、データベース操作サーバ１３内でのデータのアドレス３０２と、使用するサブデータ１２９のオフセット情報７０１を含む。使用するサブデータのオフセット情報７０１は、サブデータの識別子６０１、データ型６０２、データ長６０３、オフセット位置６０４を含む。使用するサブデータ１２９のオフセット情報７０１は、解析１０１時に、サブデータのオフセット情報１２４から、使用するサブデータ１２９の識別子６０１のオフセット情報を取り出す。サブデータのオフセット情報１２４と、使用するサブデータ１２９の識別子を、サブデータ取り出し用情報１２８に含め、データベース操作サーバ１３側で、使用するサブデータ１２９のオフセット情報を選択する代案も適用できる。
【００３５】
図８は本発明の内、図１のサブデータ１２９の例である。サブデータ１２９は、システム定義型もしくは、ユーザ定義型の実際のデータ８０１である。取り出すサブデータがユーザ定義型で、使用するデータがサブデータのサブデータの場合、サブデータ取り出し用情報７０１に、サブデータのサブデータのオフセット情報を含めてデータベース操作サーバ１３側で、サブデータのサブデータを取り出す代案が適用できる。サブデータのサブデータのサブデータ以下続く場合でも同様にオフセット情報をサブデータ取り出し用情報７０１に含めることで適用可能である。
【００３６】
図９は本発明の内、図１のデータ操作サーバに格納してあるデータ１３０の例である。データ操作サーバに格納してあるデータ１３０は、各列ごとのデータ９０１の集まりである。各列の取り出しの高速化などの為に、各列のデータに対して、先頭からのオフセット情報などの付加情報があっても良い。各列のデータは、システム定義の型のデータ９０２と、ユーザ定義の型のデータ９０３を含む。各列のデータ型は、CREATE TABLEなどの表定義によるもので、システム定義の型のデータ９０２、ユーザ定義の型のデータ９０３ともに0回以上何回どの順番で出現してもかまわない。ただし、どちらか最低１つは必要である。図９の(a)は複数のサブデータからなる列データを、他の列データとクラスタリングし、全体のデータ１３０に埋め込んだ形式にしてある。サブデータに可変長のデータを含む場合、図９の(b)のように、サブデータを持つデータの列に対して、各サブデータのオフセット９０４を組み入れる代案を適用できる。サブデータを持つデータ９０３ｂの構造が、全体のデータ１３０の構造と同形になっている。図９の(b)では、オフセットはサブデータの先頭アドレスからのものを入れているが、サブデータの識別子から、サブデータの位置を確定できる情報が組み入れてあれば他の形でもよい。サブまた、可変長のサブデータに対して、オフセットの情報では無く、その可変長のサブデータにデータ長の情報を組み入れる代案もある。図６のディクショナリ情報のサブデータの識別子から、そのサブデータを取り出せる形になっていれば本発明を適用可能である。
【００３７】
複数のサブデータからなる列データ９０３を、全体のデータ１３０と別の領域に格納し、その領域へのポインタのみをデータ１３０に格納する代案も適用できる。
【００３８】
図１０はサブデータのオフセット情報１２４作成の実施例である。サブデータのオフセット情報１２４は、複数のサブデータからなるデータの型の定義のときに作成される。CREATE TYPEのような型の定義文１００１をフロントエンドサーバ１２で解析１０１を行なう。サブデータ１つ１つに対して型を調べ、型の種類により決められた長さ、もしくは、文字列などの場合は定義された長さによって、サブデータの識別子６０１、データ型６０２、データ長６０３、オフセット位置６０４を得る。サブデータ識別子６０１は、サブデータの名称と対応付けられるものであればかまわない。フロントエンドサーバと、ディクショナリのあるサーバを分けて、ディクショナリのあるサーバで解析を行なう代案も適用できる。
【００３９】
図１１は複数のサブデータからなるデータ１３０作成の実施例である。複数のサブデータからなるデータ１３０は、挿入問い合わせのときなどに作成される。CREATE TABLEのような表の定義文により作成される表定義情報を用いる。表定義情報は各列の列識別子、データ型を含む。従来と変わることとしては、データ型として、ユーザ定義の型を使用できる。図１１は挿入問い合わせの例である。挿入問い合わせ１１０１をフロントエンドサーバ１２で解析１０１を行なう。挿入問い合わせ１１０１は、各列に挿入する値データを含む。挿入する値データが、複数のサブデータからなるデータの場合、各サブデータの値を指定する方法や、データを作成する関数とその引数を指定する方法などがある。ADTの場合は、データを作成する関数とその引数（引数無しの指定もある）を指定する。関数によりデータを作成する場合は、図１０の型の定義時、定義の中に指定した関数などの解析した結果が、ディクショナリに格納される。
【００４０】
挿入問い合わせ１１０１の解析１０１により、挿入する値もしくは値を作成する関数と引数を、インタプリタで解釈実行する情報として含む内部形式の処理手順１１０２を作成する。情報には、表定義情報やサブデータのオフセット情報から得る各列やサブデータの型、長さを含む。内部形式の処理手順１１０２をその挿入する表の格納してあるデータ操作サーバ１３に転送する。データ操作サーバ１３側は、内部形式の処理手順１１０２を受け取り、実行する。インタプリタで実行するコードは、列やサブデータの型や長さの情報と挿入する値の情報から、挿入する値の作成１１０３、型変換１１０４を経て、データ１３０の形式に組み上げ格納１１０５する。サブデータのサブデータに対しては、再帰処理などを用いてデータ１３０を組み上げる。内部形式の処理手順１１０２は、インタプリタで解釈実行するコードで無く、実行形式のコードであっても本発明を適用可能である。
【００４１】
図１２は本発明の内、図１の内部形式の処理手順作成１０１の処理説明図である。まず、問い合わせ１２２と、変数による入力があればそのバインドの情報１２７を受け取る１２０１。問い合わせ１２２の構文解析１２０２、意味解析１２０３を行ない、その過程で変数のサブデータの使用があるかどうか、ある場合使用するサブデータの識別子の解析も行なう。また問い合わせ１２２の中に使用するサブデータは複数あってもよいので、使用する側のサブデータと、取り出す側のサブデータは同じ識別子で解析結果の情報に含めておく。変数のサブデータの使用があれば１２０４、変数のバインドの情報から、データの位置情報１２６を取り出し１２０５、そのデータの位置情報１２６と、ディクショナリにあるサブデータのオフセット情報１２４と、使用するサブデータの識別子から、サブデータを取り出す内部形式の処理手順５１を作成する１２０６。次に、サブデータを使用する問い合わせ１２２の内部形式の処理手順５２を作成する１２０７。同じ識別子のサブデータには同じ格納場所を表すオフセットを与えることで、サブデータを取り出す側５１と、使用する側５２で、サブデータのやり取りができる。変数のサブデータの使用が無ければ１２０４、サブデータを取り出す内部形式の処理手順は必要無く、問い合わせ１２２の内部形式の処理手順のみを作成する１２０７。問い合わせがデータベース操作サーバ側で行なうデータベース操作サーバの場合、内部形式の処理手順には、実行するデータベース操作サーバの情報を付随する。実行するデータベース操作サーバの情報は、操作を行なう表の分割に関する情報から得られる。表の分割情報は、表定義時に指定され、ディクショナリに入っている。
【００４２】
図１３は本発明の内、図１の内部形式の処理手順転送１０２と、処理手順受け取り１１１の実施例の処理説明図である。実行するデータベース操作サーバ１３の１つ１つに対して１３０１、内部形式の処理手順１２５を転送する１３０２。データベース操作サーバ１３側は、内部形式の処理手順１２５を受け取り１１１、実行を行なう１１２。データベース操作サーバが処理手順１２５の受け取り報告をフロントエンドサーバ１２に返し、全て受け取ったのを確認してから各データベース操作サーバ１３に起動要求をかけ実行１１２に移る代案も適用できる。データベース操作サーバのキャッシュに内部形式の処理手順１２５を置くことによって、２回目以降の実行は、実行要求を発しキャッシュにある処理手順１２５を用いる改良案も適用できる。
【００４３】
図１４は本発明の内、図１の内部形式の処理手順実行１０４の実施例の処理説明図である。インタプリタにより、コードを１つずつ１４０１、付随する情報とともに解釈実行を行なう１４０２。次に行なうコードを情報から取り出し１４０３、次々実行していく。
【００４４】
図１５は本発明の内、図１の処理手順実行１１２の実施例の処理説明図である。インタプリタによるコードの実行は図１４と同様である。インタプリタによって扱うコードの種類は、フロントエンドサーバ１２側と、バックエンドサーバ１３側で異なってもよい。インタプリタにより、コードを１つずつ１５０１、付随する情報とともに解釈実行を行なう１５０２。次に行なうコードを情報から取り出し１５０３、次々実行していく。実行するコードが、複数のサブデータからなるデータの検索の場合１５０４、データベース操作サーバ１３ａの識別子３０１とデータのアドレス３０２を取得し、解析時に結果用に用意しておく領域に、位置情報１２６を作成する。データベース操作サーバ１３の識別子は、内部形式の処理手順１２５にコードが用いる情報として用意しておいても良い。複数のサブデータからなるデータで無い場合のデータの検索の場合は、解析時に結果用に用意しておく領域に、データ自身を取り出す。
【００４５】
図１６は本発明の内、図１の結果受け取り１０３と、結果転送１１３の実施例の処理説明図である。内部形式の処理手順１２５を転送した１０２データベース操作サーバ１３から、実行結果が無くなる１６０２まで結果が転送される１６０１。結果は、複数個ごとに転送する代案も適用できる。各データベース操作サーバ１３からの結果はキューなどにより結果を送られてきた順などに取り出される１６０３。結果受取りの処理手順を解析時に作成しても良い。起動したデータベース操作サーバ１３から全て結果終了の報告が送られてくるまで１６０４、結果を受け取る１６０３。結果はホストのUAPに返す１０５。図１の場合、結果を全て受け取ってからUAPに返すようになっているが、結果を１つまたは複数個、受け取るごとにUAPに返す代案も適用できる。問い合わせが検索の場合は結果は検索結果である。複数のサブデータからなるデータの検索の場合は、検索結果に位置情報１２６を含む。問い合わせが検索結果以外の場合は、結果終了の報告のみである。
【００４６】
図１７は本発明の内、図１のサブデータ取得１０６と、サブデータ取り出し１１４と、データ転送１１５と、データ受け取り１０７の実施例の処理説明図である。データの位置情報１２７からデータのあるデータベース操作サーバ１３の識別子を取り出し１７０１、そのデータベース操作サーバ１３に、サブデータ取り出しに必要な情報１２８とともに、サブデータ取り出しの要求をそのデータベース操作サーバ１３に出す１７０２。データベース操作サーバ側はフロントエンドサーバ１２側から、サブデータ取り出し用情報１２８を受け取る１７０３。データベース操作サーバ１３内でのデータのアドレス３０２により、データを取得する１７０４。使用するサブデータのオフセット情報７０１により、オフセット位置６０４からデータ長６０３の分だけ、データ型６０２にしたがって、サブデータ１２９を取り出す１７０５。可変長のサブデータに対して、オフセットがデータ１３０の方に組み入れてある代案においては、サブデータの識別子から、データ１３０に組み込んだオフセットを取り出し、そのオフセットを用いてサブデータを取り出せばよい。取り出したサブデータ１２９はフロントエンドサーバ側に転送する１１５。データベース操作サーバ１３から受け取る１７０６結果である１つ以上のサブデータ１２９を、解析１０１時に用意した、結果を格納する領域５０５に置く１７０７。この領域は、サブデータを使用する内部形式の処理手順５２にオフセット５０６で指定され、サブデータの使用が実現する。
【００４７】
サブデータを使用する問い合わせ１２２ｂが、検索したデータに対する更新処理のように、データベース操作サーバ１３側でサブデータを受け渡すことが可能な場合は、サブデータを使用する側と共用している領域におく処理１０７と、図５のサブデータを置く場所５０５を、データベース操作サーバ１３側にする代案を適用できる。検索したデータに対する更新処理かどうかの判断は、先に行なう検索問い合わせ１２２ａの解析のときに、更新用検索の指定がある場合に可能である。この場合、フロントエンドサーバ１２とデータベース操作サーバ１３間のデータの転送が無いので、問い合わせ時間の削減が見込まれる。
【００４８】
また、サブデータを使用する問い合わせ１２２ｂが、検索したデータに対する更新処理であり、データのアドレス４０２がデータ格納の実アドレスである場合は、サブデータ取り出しを行なわず、更新処理の内部形式の処理手順に直接、位置情報１２７や使用するサブデータのオフセット情報１２４を組み込むことで、直接データベース上のデータを更新する代案も適用できる。この場合、データをメモリ上に取り出さず、直接データを更新するので、問い合わせ時間の削減が見込まれる。
【００４９】
図１８と図１９は本発明を具体的なＳＱＬに適用する例の概要図である。図１８は、複数のサブデータからなるデータの検索ＳＱＬの例であり、図１９は、図１８で検索したデータのサブデータを使用するＳＱＬの例である。図の例では、INTOにより、検索結果を１つ取り出し、後に使用する例であるが、複数の検索結果を取り出し、ループなどで結果１つずつを後の問い合わせで使用する場合にも、本発明を適用可能である。
【００５０】
図１８は、住所録から、住所データを検索するＳＱＬの解析、実行である。住所データは、郵便番号、住所、電話番号の３つのサブデータからなる。住所録表や、住所データの型の定義情報をディクショナリから取得し、解析を行ない、内部形式の処理手順１２５を作成する。住所録表がデータベース操作サーバ１とサーバ２の２つに分割格納されているものとする。WHERE条件に合うデータはサーバ２の方にあるものとする。サーバ１とサーバ２に内部形式の処理手順を転送し１０２、実行を行なう１１２。サーバ２では条件に合うデータが存在するので、データベース操作サーバ１３bの識別子であるサーバ２を取得し１５０５、データのアドレス１８０１を取得し１５０６、位置情報１２６を作成し１５０７、結果１２６を返す１１３。結果１２６は、ホスト１１のUAP側に変数にバインドする情報１２７として返す。図１８ではディスクを省略しているが、アドレスはデータ格納の実アドレスでも、メモリ上にデータを取り出しオフセットによる論理的なアドレスで表してもよい。
【００５１】
図１９は、住所データのサブデータである電話番号を判定条件に使用する問い合わせの例である。判定後の処理は、発明の主旨と関係無いので…で省略する。問い合わせを受け取り１２０１、構文解析、意味解析を行ない、変数:Xのサブデータ電話番号を使用する処理であるので、変数にバインドされた位置情報１２７と、使用するサブデータ電話番号のサブデータのオフセット情報１２４より、サブデータを取り出す内部形式の処理手順５１を作成する１２０６。次に、サブデータを使用するIF文の内部形式の処理手順５２を作成する１２０７。実行時には、位置情報１２７から取得したデータのベース操作サーバであるサーバ２に、サブデータ取り出し用情報１２８である、住所データのアドレスと使用するサブデータ電話番号のオフセット情報を転送する。電話番号のオフセットは26である。郵便番号のデータ長が6、住所のデータ長が20であり、住所データの先頭アドレスから26の位置に電話番号があり、サブデータ電話番号を取り出せる。ただし、サブデータはクラスタリングしてあるものとする。また、簡単のため、オフセットは、最初のサブデータの先頭を0で表している。住所データを図１８の検索問い合わせで、キャッシュ上に置き、余分なIOを起こさない代案を適用できる。取り出したサブデータ１２９は、データ受け取り１０７で、サブデータを使用するIF文側と共用する領域に置く１７０７ので、IF文の処理手順を実行する１０４ときに、サブデータ１２９を使用できる。
【００５２】
図２０は本発明の代案の実施例である。図２０は、先に行なう検索問い合わせ１２２ａの解析、実行の例である。図１と異なるのは、複数のサブデータからなるデータの検索１２２ａにおいて、検索結果２００１が、位置情報１２６で無く、データ自身２００１であることである。この場合変数にバインドする情報１２７は、フロントエンドサーバ上でのデータのアドレス、または、データ自身である。UAP側で、複数のサブデータからなるデータを受け取る機能が無い場合は、フロントエンドサーバ上でのアドレスになる。サブデータを使用する後の問い合わせ１２２bでは、フロントエンドサーバ側にデータがあるので、データベース操作サーバ側でサブデータ取り出しをする必要が無い。直接フロントエンドサーバ側のデータおよびサブデータを使用できる。
【００５３】
図２１は本発明の内、図１の変数にバインドする情報１２７の図４とは別の例である。図２２の例で使用する。変数にバインドする情報１２７は、データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを表すフラグ情報２１０１を含む。データをフロントエンドサーバに転送している場合0、位置情報をフロントエンドサーバに転送している場合1のフラグ情報でよい。データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを判別できれば、上記フラグ情報で無くてもかまわない。変数にバインドする情報１２７には、データをフロントエンドサーバに転送している場合の情報２１０２と、位置情報をフロントエンドサーバに転送している場合の情報２１０３を含む。データをフロントエンドサーバに転送している場合の情報２１０２は、フロントエンド上でのデータのアドレスもしくは、データ自身である。位置情報をフロントエンドサーバに転送している場合の情報２１０３は、位置情報１２６である。
【００５４】
図２２と図２３は、図１の方法（位置情報を転送する方法）と図２０の方法（データを転送する方法）を、コスト計算などの選択基準で選択する例の概要図である。選択基準としては、サブデータのデータ長などのディクショナリ情報から各方法のコストを計算し比較する方法や、検索するデータにLOBデータなどの大規模なサブデータがあれば図１の方法、無ければ図２０の方法というように分ける方法がある。
【００５５】
図２２は、複数のサブデータからなるデータの検索の概要図である。解析１０１時に、各方式のコスト計算など２２０１で図１の方法２２０２、図２０の方法２２０３の解析、実行を選択する。ただし、結果を返す１０５処理のときに、図２１の変数にバインドする情報１２７を作成する。ホストのUAP側では、サブデータを含むデータの検索の場合、変数の領域として、変数にバインドする情報を受け取るだけの長さ分の領域を用意する必要がある。
【００５６】
図２３は、サブデータを使用する問い合わせの概要図である。解析１０１時に、変数にバインドする情報１２７の、データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを表すフラグ情報２１０１により２３０１、図１の方法２３０２、図２０の方法２３０３の解析、実行を選択する。
【００５７】
【発明の効果】
以上のように、本発明によれば、複数のサブデータからなるデータの検索において、位置情報のみを転送し、後でそのデータのサブデータを使用する問い合わせにおいて、使用するサブデータを取り出すため、使用しないサブデータの転送による通信時間を削減し、問い合わせ時間を小さくすることができる。使用しないサブデータがLOBデータなど大規模なデータの場合特に有効である。
【図面の簡単な説明】
【図１】実施例の構成図である。
【図２】複数のサブデータからなるデータの例である。
【図３】位置情報の例である。
【図４】変数にバインドする情報の例である。
【図５】内部形式の処理手順の例である。
【図６】サブデータのオフセット情報の例である。
【図７】サブデータ取り出し用情報の例である。
【図８】サブデータの例である。
【図９】データ操作サーバに格納してあるデータの例である。
【図１０】サブデータのオフセット情報作成の実施例である。
【図１１】複数のサブデータからなるデータ作成の実施例である。
【図１２】内部形式の処理手順作成の処理説明である。
【図１３】内部形式の処理手順転送と処理手順受け取りの処理説明である。
【図１４】内部形式の処理手順実行の処理説明である。
【図１５】処理手順実行の処理説明である。
【図１６】結果受け取りと結果転送の処理説明である。
【図１７】サブデータ取得とサブデータ取り出しの処理説明である。
【図１８】具体例の概要図である。
【図１９】具体例の概要図である。
【図２０】代案の実施例である。
【図２１】変数にバインドする情報の例である。
【図２２】複数のサブデータからなるデータの検索の概要図である。
【図２３】サブデータを使用する問い合わせの概要図である。
【符号の説明】
１１…ホスト
１２…フロントエンドサーバ
１３…データベース操作サーバ
１４…ディクショナリ
１０１…解析、１０２…内部形式の処理手順転送、１０３…結果受け取り
１０４…内部形式の処理手順実行、１０６…サブデータ取得、１０７…データ受け取り
１１１…処理手順受け取り、１１２…処理手順実行、１１３…結果転送
１１４…サブデータ取り出し、１１５…データ転送
１２１…UAP、１２２…問い合わせ、１２４サブデータのオフセット情報
１２５…処理手順、１２６…位置情報、１２７…変数にバインドする情報
１２８…サブデータ取り出し用情報、１２９…サブデータ、１３０…データ

Claims

データベースへの問い合わせを解析し、検索結果の加工や制御を行なうフロントエンドサーバと、データベースに対する検索を行う複数のデータベース操作サーバを有し、前記フロントエンドサーバと、前記複数のデータベース操作サーバとがネットワークで接続された並列データベースシステムにおける並列データベースシステム検索方法であって、
前記フロントエンドサーバは、前記データベースへの問合せの解析に基づいて処理手順を生成し、
データベース操作サーバは、複数のサブデータからなる抽象データ型データの検索において、前記データベース操作サーバから、前記フロントエンドサーバからの前記処理手順に基づいて前記抽象データ型データの位置情報を前記フロントエンドサーバに返却し、
前記フロントエンドサーバは、サブデータへの操作がある場合には、前記返却された抽象型データの前記位置情報と、ディクショナリ情報から取り出した、前記操作対象のサブデータのオフセット情報と、前記操作対象のサブデータの識別子とにより、前記データベース操作サーバにある前記抽象データ型データのサブデータを取り出し、取り出した前記サブデータを使用する処理を行い、
前記ディクショナリ情報とは、複数のサブデータの名称と型の宣言から定義される抽象データ型データの、各サブデータの識別子と、前記抽象データ型データの格納場所から各サブデータの格納場所までのオフセット情報とを格納した情報である
ことを特徴とする並列データベースシステム検索方法。
前記抽象データ型データの位置情報とは、データベース操作サーバの識別子と、抽象データ型データのデータベース操作サーバ内でのアドレスであることを特徴とする請求項１記載の並列データベースシステム検索方法。
請求項１又は２に記載の並列データベースシステム検索方法であって、
前記取り出した前記サブデータを使用する処理は、取り出した前記サブデータが所定の条件を満たすかどうかを判定する処理であり、該条件を満たすサブデータを含む前記抽象データ型データを問い合わせに対する結果として返却することを特徴とする並列データベースシステム検索方法。
請求項３記載の並列データベースシステム検索方法であって、
前記問い合わせに対する結果として返却される前記抽象データ型データに対して更新処理を行うことを特徴とする並列データベースシステム検索方法。