JPWO2017163393A1 - データ処理システム - Google Patents

Abstract

本発明の一実施形態に係るデータ処理システムは、１以上のテーブルと、テーブルから抽出された１以上のレコードを含む複数のアーカイブファイルを管理する。データ処理システムは、テーブルに対する検索要求を受け付けると、検索要求で指定された項目を前記テーブルから検索するクエリ(部分クエリ１)を生成し、検索要求で検索対象とされているテーブルから移動されたレコードを含むアーカイブファイルを特定して、特定されたアーカイブファイルから前記検索要求で指定された項目を検索するクエリ(部分クエリ２)を生成する。そして、部分クエリ１と部分クエリ２の出力結果の和集合を求めるクエリを生成し、生成されたクエリに係る処理を並列実行する。

Description

本発明は、データ処理システムに関する。

従来のデータベース管理ツールやデータ処理アプリケーションで処理することが困難なほど巨大なデータセットの集積物をビッグデータという。近年、ビッグデータを分析して、ビジネスの傾向の発見等に活用することが行われるようになってきている。

ビッグデータはそのサイズの大きさのせいで、従来からあるデータベースシステムで管理できないことがある。そのため、データベースシステムでそのようなデータを扱う場合、ごく最近収集されたデータをデータベースのテーブルに格納し、それ以前のデータはアーカイブファイルへと移動して保管するという運用がなされることもある。アーカイブファイルは通常、データベースシステムが提供するアクセス方法でアクセス可能なデータではないため、このような運用を行うと、アーカイブファイルに記録されたデータを用いた分析等が困難になる。

このような問題を解決するために、アーカイブもデータベースの一部としてアクセス可能にする技術が考えられている。たとえば特許文献１には、所定の抽出条件にあてはまるデータをデータベースから抽出してアーカイブファイルに移動し、移動されたデータの日付情報をディクショナリに格納しておくシステムが開示されている。このシステムでは、日付を指定したデータ検索要求を受け付けると、データベースからデータ検索を行うことに加えて、ディクショナリを参照することで、指定された日付のデータが含まれているアーカイブファイルを読み出してデータ検索を行う。

特開２０００ー１３２４４２号公報

ビッグデータのような大規模なデータ群の中から所望のデータを検索する等の処理を現実的な時間で行うためには、システムのアクセス性能の向上が必要である。アクセス性能の向上施策の一つの例として、並列処理がある。しかしながら特許文献１に開示のシステムは、並列処理に対する考慮は無く、指定された日付のデータが含まれるアーカイブファイルを１つずつ特定し、逐次的にアーカイブファイル（またはテーブル）の検索を行う必要があり、処理性能の向上が難しい。

本発明の一実施形態に係るデータ処理システムは、１以上のテーブルと、テーブルから抽出された１以上のレコードを含む複数のアーカイブファイルを管理する。データ処理システムは、テーブルに対する検索要求を受け付けると、検索要求で指定された項目を前記テーブルから検索するクエリ(部分クエリ１)と、検索要求で検索対象とされているテーブルから抽出(移動)されたレコードを含むアーカイブファイルを特定して、特定されたアーカイブファイルから前記検索要求で指定された項目を検索するクエリ(部分クエリ２)とを生成する。さらに部分クエリ1と部分クエリ2を用いて、これらの出力結果の和集合を求めるクエリを生成し、生成されたクエリに係る処理を並列実行する。

本発明によれば、大規模データベースの処理性能を向上させることができる。

データ処理システムの構成図である。 検索対象データの格納されるテーブルの一例である。 テーブルとアーカイブファイルの格納される記憶領域の構成を説明する図である。 アーカイブファイルのフォーマットの一例である。 サーバの機能ブロック図である。 ディクショナリ（ＳＱＬ＿ＴＡＢＬＥＳ）の構成例である。 ディクショナリ（ＳＱＬ＿ＣＯＬＵＭＮＳ）の構成例である。 チャンク管理表の一例である。 ファイル管理表の一例である。 アーカイブ処理のフローチャートである。 検索処理のフローチャートである。 書き換え前のクエリの例である。 表関数を用いたクエリの例である。 部分クエリ２の例である。 書き換え後のクエリの例である。 クエリ書き換え処理のフローチャートである。 書き換え前のクエリの一般化例である。 書き換え後のクエリの一般化例である。

以下、本発明の実施例について、図面を用いて説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

（１） システム構成
図１は、本発明の実施例に係るデータ処理システムのハードウェア構成を示す図である。データ処理システムは、データベースサーバ１（以下、「サーバ１」あるいは「ＤＢサーバ１」と略記する）、クライアント２、記憶装置３，４を有する。サーバ１とクライアント２は、例えばイーサネット（Ｅｔｈｅｒｎｅｔ）を用いて構成されたローカルエリアネットワーク（ＬＡＮ）６を介して、相互通信可能に接続される。サーバ１は、たとえばファイバチャネル（ＦｉｂｒｅＣｈａｎｎｅｌ）を用いて構成されたネットワーク５（またはＳＡＮ５と呼ばれる）を介して、記憶装置３，４と接続される。

サーバ１は、データ処理システムの利用者（以下、「ユーザ」と呼ぶ）から受領した、データベースへのアクセスリクエストの処理を行うコンピュータで、ＣＰＵ１１、メモリ１２、ＬＡＮ６に接続するためのネットワークポート１３、入出力デバイス１４、ストレージポート１６を有する。メモリ１２はたとえばＤＲＡＭ等の記憶デバイスで、ＣＰＵ１１がプログラムを実行する時に、そのプログラムまたはプログラムの実行時に用いられる制御情報等を格納するために用いられる。ＣＰＵ１１はデータベースアクセス処理を実施するためのプログラムを実行するコンポーネントである。本実施例に係るデータ処理システムにおいて、サーバ１はいわゆるＳＭＰ（Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ Ｐｒｏｃｅｓｓｏｒｉｎｇ）サーバで、複数のＣＰＵ１１を有し、各ＣＰＵ１１が並列に処理を実行することができる。なお、サーバ１内に複数のＣＰＵ１１を設ける代わりに、サーバ１内にいわゆる複数のプロセッサコアを有するマルチコアプロセッサが１つ設けられる構成でも良い。

入出力デバイス１４はたとえば、キーボードやマウスなどの、ユーザが情報入力を行う際に用いるデバイスと、ディスプレイやプリンタ等の表示（出力）デバイスを含む。ストレージポート１６は、サーバ１と記憶装置３を接続するためのインタフェースである。

クライアント２は、ユーザがサーバ１に対してデータベースへの参照更新要求を発行したり、サーバ１から返送される、処理結果の出力を受領したりするために用いられるコンピュータである。クライアント２は、ＣＰＵ２１、メモリ２２、ＬＡＮ６に接続するためのネットワークポート２３、入出力デバイス２４を有する。ＣＰＵ２１、メモリ２２、ネットワークポート２３、入出力デバイス２４はそれぞれ、サーバ１のＣＰＵ１１、メモリ１２、ネットワークポート１３、入出力デバイス１４と同様のものである。またクライアント２は、メモリ２２の他に、磁気ディスクなどの補助記憶装置を備えていてもよい。

記憶装置３，４は、磁気ディスク等の不揮発性記憶デバイスを有する装置で、データベース３１やアーカイブファイル３２を格納するための装置である。記憶装置３，４は、いわゆるディスクアレイ（またはＲＡＩＤ）のように、複数の不揮発性記憶デバイスを有する装置であってもよい。記憶装置３は、ＳＡＮ５を介してサーバ１のストレージポート１６に接続される。

本実施例に係るデータ処理システムでは、データベース３１に格納されたデータは一定期間が経過すると、アーカイブファイル３２へと移される。アーカイブファイル３２は、データベース３１の格納される記憶装置３とは別の記憶装置４に格納される。本実施例では、アーカイブファイル３２の格納される記憶装置４のことを、「アーカイブ４」と呼ぶこともある。ただしデータベース３１とアーカイブファイル３２とが、同一の記憶装置３に格納される構成が採用されてもよい。

また、記憶装置３とアーカイブ４は、異なる種類の記憶装置であって良い。たとえばデータベース３１の格納される記憶装置３には、アーカイブ４よりもアクセス性能の高い記憶装置が用いられてもよい。また、アーカイブ４には、ＤＶＤや磁気テープ等の可搬型記憶媒体及び可搬型記憶媒体へのアクセスを行う記憶装置が用いられてもよい。

サーバ１のメモリ１２には、サーバ１で実行されるプログラムや、プログラムが使用する制御情報が格納される。サーバ１で実行されるプログラムとしては、たとえばデータベース管理プログラム１２０、ファイルシステムプログラム１２１、ＯＳ１２２がある。

ＯＳ１２２は、サーバ１上で実行される各種プログラムのスケジュール制御を行い、抽象化されたハードウェアリソースを各種プログラムに提供する処理を行うプログラムである。

ファイルシステムプログラム１２１は、ファイル及びファイル管理情報を記憶装置４等に格納して管理するプログラムである。本実施例ではファイルシステムプログラム１２１は主に、データベース３１から移動されたデータが格納されたアーカイブファイル３２に対するアクセスを行い、データベース３１へのアクセスが行われる時には、ファイルシステムプログラム１２１は用いられない。ただし別の実施形態として、ファイルシステムプログラム１２１が作成したファイルシステム（ファイルを格納・管理するためのデータ構造）の上にデータベース３１を格納するように構成されてもよい。

データベース管理プログラム１２０は、関係データベース管理システム（ＲＤＢＭＳ）と呼ばれることもあるプログラムで、リレーショナルデータベース（データベース３１）の作成や管理を行う。また本実施例に係るデータベース管理プログラム１２０は、アーカイブファイル３２に対するアクセスも可能である。データベース管理プログラム１２０が具体的に提供する機能については後述する。

また、これらのプログラムが使用する管理情報として、ディクショナリ５００、チャンク管理表６００、ファイル管理表７００がある。これらの詳細は後述する。

なお、上で説明したプログラムや管理情報は、サーバ１が稼働していない時は記憶装置３（あるいはサーバ１に内蔵された、非図示の補助記憶装置）に格納されている。サーバ１が起動し、必要な時（検索処理等が行われる時）に、これらのプログラムや管理情報は記憶装置３からメモリ１２上に読み出され、ＣＰＵ１１によって使用される。なお、サーバ１は上で述べたプログラム以外のプログラム、そして上で述べた管理情報以外の情報を、メモリ１２に格納してもよい。

クライアント２のメモリ２２には、クライアントプログラム２２１が存在しており、ＣＰＵ２１がクライアントプログラム２２１を実行する。クライアントプログラム２２１は、ユーザが情報検索指示を発行するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）またはＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）を提供するプログラムである。

（２） データベースとアーカイブファイルの構成
続いて、本実施例に係るデータ処理システムで取り扱われるデータベース３１とアーカイブファイル３２の構成について説明する。記憶装置３内に、テーブル３００等を定義するためのデータベースエリア（データベース３１と呼ぶ）が定義され、データベース３１内には１または複数のテーブル３００が定義されている。

まず、サーバ１で作成されるテーブル３００の例を、図２に示す。テーブル３００は、ＳＥＱ＿ＮＯ（３１１）、ＵＳＥＲ＿ＤＡＴＡ（３１２）、ＲＥＣＯＲＤ＿ＤＡＹ（３１３）の３つのカラムを有するレコードを複数有する。ただし図２のテーブル３００は一例であり、各レコードは４以上のカラムを有していてもよい。

本実施例では、テーブル３００に格納されるデータ（レコード）は一例として、時系列データとする。時系列データとはたとえば、センシングデバイス等のデータソースから継続的に取得した計測データの集合である。計測データはテーブル３００内レコードのカラムＵＳＥＲ＿ＤＡＴＡ（３１２）に格納され、計測データが格納されたレコードのＲＥＣＯＲＤ＿ＤＡＹ（３１３）にはたとえば、計測データをデータソースから取得した日が格納される。

テーブルの定義される記憶装置３の記憶領域、そしてアーカイブファイルの格納されるアーカイブ４の記憶領域について、図３を参照しながら説明する。本実施例では、データソースから取得されたデータを用いて作成されたレコードをテーブルに格納する時、サーバ１はデータインポートツール等のプログラム（図１等では非図示）を用いて、一度に複数のレコードをテーブルに格納する。本実施例では、データインポートツールにより、テーブルに一度にロードされたレコードの集合のことを、「チャンク」と呼ぶ。テーブルは、このチャンクを複数持つ構成となっている。なお、チャンクは上に述べた定義以外のものでもよい。例えば、特定条件により分類されているレコードの集合がチャンクと定義されてもよい。あるいは、記憶装置３の領域を所定サイズの区画に区切ることにより形成された領域に格納されたレコードの集合が、チャンクと定義されてもよい。また、これらの複数の特性を備えたレコードの集合がチャンクと定義されてもよい。たとえば、記憶装置３内の所定サイズの区画（連続領域）内に、データインポートツールにより一度にロードされたレコードの集合を、チャンクと定義してもよい。

テーブル３００には、データソースから集められたデータが継続的に蓄積されるため、テーブル３００に格納されるデータは、時間の経過に伴い膨大なものになる。データ量が膨大になると、記憶装置３の空き領域がなくなりデータの蓄積ができなくなる。そのためサーバ１は、テーブル３００に格納されたデータのうち、古いデータ（ＲＥＣＯＲＤ＿ＤＡＹ（３１３）の日付が古いレコード）から順にアーカイブ４へ移動する。この処理をアーカイブ処理と呼ぶ。

アーカイブ４への移動の際、サーバ１はアーカイブ４内にファイルを作成し、移動対象のレコードをテーブル３００から読み出して、作成されたファイルに格納する。このファイルはアーカイブファイルと呼ばれる。レコードはアーカイブファイルに記録されるとテーブル３００からは削除される。

アーカイブ４の記憶領域には、ファイルシステムプログラム１２１によって、ディレクトリ等のファイル管理用のデータ構造が形成されている。アーカイブファイルを格納するディレクトリはあらかじめ定められており、そのディレクトリは「アーカイブディレクトリ」と呼ばれる。アーカイブディレクトリは、ユーザがテーブルを定義する際に指定される。

アーカイブファイル３２の例を図４に示す。本実施例ではアーカイブファイル３２のファイル形式には、いわゆるＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅ）形式が採用される。ただしＣＳＶ形式以外のファイル形式が用いられてもよい。またアーカイブファイル３２がアーカイブ４に格納される際には、圧縮された状態で格納されてもよい。図４に示されている例は、非圧縮状態のアーカイブファイル３２の内容である。

アーカイブファイル３２の各行は、テーブル３００のレコードに相当する。つまり、テーブル内レコードのカラム（ＳＥＱ＿ＮＯ（３１１）、ＵＳＥＲ＿ＤＡＴＡ（３１２）、ＲＥＣＯＲＤ＿ＤＡＹ（３１３））に格納されていたデータのそれぞれが、カンマで区切られた形で記述される。図４において、行３２０が、テーブルに格納されていた１つのレコードを表し、要素３２１，３２２，３２３はそれぞれ、テーブルのＳＥＱ＿ＮＯ（３１１）、ＵＳＥＲ＿ＤＡＴＡ（３１２）、ＲＥＣＯＲＤ＿ＤＡＹ（３１３）に格納されていた情報である。以下では特に断りのない限り、アーカイブファイル３２の行のことも、テーブル３００のレコードと同じく、「レコード」と呼ぶ。

アーカイブ４に格納されるアーカイブファイル３２は１つとは限らない。テーブルのデータをすべて１つのアーカイブファイル３２に格納すると、アーカイブファイル３２が大きくなりすぎて、アーカイブファイル３２を読み出す必要が出た際に、アーカイブファイル３２の読み出しに過剰に時間がかかることもあり得る。そのためサーバ１が、テーブルのデータをアーカイブ４に移す際には、データを複数のアーカイブファイル３２に分けて格納することもある。

（３） 機能ブロック構成
続いて図５を用いて、サーバ１の有する機能ブロックの説明を行う。本実施例に係るサーバ１は、上で説明したプログラム（主にデータベース管理プログラム１２０）がＣＰＵ１１で実行されることによって、ディクショナリ管理部２０１、チャンク管理部２０２、アーカイブ管理部２０３、クエリ受付部２０４、クエリ書換部２０５、クエリ最適化部２０６、クエリ実行部２０７、データベースアクセス部２０８、表関数処理部２０９という機能ブロックを備えた装置として動作する。以下、各機能ブロックの役割及び各機能ブロックが使用する管理情報を説明する。

ディクショナリ管理部２０１は、ユーザから受け付けたデータベーステーブル作成要求に従って、データベーステーブル（テーブル）の作成を行う。テーブル作成の際、ディクショナリ管理部２０１はテーブルの定義情報をディクショナリ５００に記録する。ディクショナリ５００の内容については後述する。

クエリ受付部２０４は、ユーザからのデータベースアクセス要求を受け付け、適切な機能ブロックにその要求に係る処理を行わせ、処理結果をユーザに返送する。本実施例に係るＤＢサーバ１は、クライアント２からＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）で記述されたデータベースアクセス要求（「クエリ」と呼ばれる）を受領し、クエリの処理を行う。クエリ書換部２０５は、受け付けたクエリの書き換えを行うための機能ブロックである。クエリ書換部２０５で行われる処理の詳細は、後述する。

クエリ最適化部２０６は、受け付けたクエリを解析し、クエリに係る処理の実行手順（実行プラン）を決定する機能ブロックである。クエリ実行部２０７はクエリ最適化部２０６で決定された処理実行手順に従って、データベーステーブルに格納されているレコードの検索等の処理を行う。

データベースアクセス部２０８は、データベース３１内のテーブル３００に格納されているレコードへのアクセスを行う機能ブロックである。データベースアクセス部２０８はクエリ実行部２０７からの指示に従って、レコードのリードやライトを行い、結果をクエリ実行部２０７に返送する。たとえばクエリ実行部２０７からの指示がレコード検索の指示であれば、データベースアクセス部２０８はテーブル３００からレコードを読み出して、クエリ実行部２０７に返送する。

表関数処理部２０９は、アーカイブファイル３２の読み出しを行う機能ブロックである。表関数とは、ＳＱＬ２００３で規格化されている機能で、本実施例に係るデータベース管理プログラム１２０は表関数をサポートしている。表関数処理部２０９は、アーカイブファイル３２（ＣＳＶファイル）を読み出して、アーカイブファイル３２に記述されている各行をテーブル形式のデータとして、クエリ実行部２０７に返却する機能を有する。

チャンク管理部２０２は、テーブル３００へのデータロード処理を行う機能ブロックで、またチャンク管理表６００の管理を行う。またアーカイブ管理部２０３は、テーブル３００内データのアーカイブ処理を行う機能ブロックで、アーカイブファイル３２とテーブル３００との対応関係をファイル管理表７００に格納して管理する。

なお、本実施例では、プログラムまたはクエリ書換部２０５等の機能ブロックを主語として、サーバ１で実行される処理の内容が説明される箇所がある。先に述べたとおり、プログラム（主にデータベース管理プログラム１２０）がＣＰＵ１１で実行されることによって、サーバ１がこれら機能ブロックを備えた装置として動作するものであるから、実際の処理の主体は、正確にはサーバ１のＣＰＵ１１である。ただし説明が冗長になることを防ぐため、プログラムまたは機能ブロックを主語として、各種処理の流れを説明することがある。

（４） 管理情報
次に、ディクショナリ５００、チャンク管理表６００、ファイル管理表７００について説明する。サーバ１がテーブルを作成する時、定義されるテーブルの属性情報等をディクショナリ５００に記録する。図２に示されたテーブル３００が定義（作成）された時に、ディクショナリ５００に記録される情報の例を、図６、図７を参照しながら説明する。ディクショナリ５００は、テーブル３００の属性が格納されるＳＱＬ＿ＴＡＢＬＥＳ（５１０）、テーブルの各カラムの属性が格納されるＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）を有する。図６はＳＱＬ＿ＴＡＢＬＥＳ（５１０）の構成を示し、図７はＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）の構成を示している。

ＳＱＬ＿ＴＡＢＬＥＳ（５１０）は、スキーマ名（５１１）、表識別子（５１２）、表ＩＤ（５１３）、アーカイブ指定（５１４）、アーカイブディレクトリ（５１５）のカラムを有するレコードを１以上有する。テーブルが作成されるたびに、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）に１つのレコードが作成される。スキーマ名（５１１）、表識別子（５１２）、表ＩＤ（５１３）はそれぞれ、作成されたテーブルの属するスキーマの名称（一般には、テーブル作成を指示したユーザのユーザ名である）、作成されたテーブルの識別子（ユーザが指定した名称）、作成されたテーブルの識別番号である。これらは公知のＲＤＢＭＳでも管理される情報であるので、詳細説明は略す。なお、本実施例では、スキーマ名称とテーブルの識別子のセットのことを「テーブル名」と呼ぶことがある。

また、本実施例に係るデータベース管理プログラム１２０によって管理されるテーブルの属性には、アーカイブ指定（５１４）及びアーカイブディレクトリ（５１５）という情報も含まれる。先に述べたとおり、本実施例に係るＤＢサーバ１のアーカイブ管理部２０３は、テーブル３００内レコードをアーカイブファイル３２にアーカイブし、アーカイブファイル３２とテーブル３００との対応関係をファイル管理表７００に格納して管理する。アーカイブ指定（５１４）は、アーカイブ管理部２０３がアーカイブ処理を行う対象のテーブルであるか否かを示す情報である。アーカイブ管理部２０３がアーカイブ処理を行う対象のテーブルのことを、本実施例では「アーカイブ可能なテーブル（Ａｒｃｈｉｖａｂｌｅ ｔａｂｌｅ）」と呼ぶ。アーカイブ指定（５１４）はユーザが指定可能な情報である。ユーザがテーブル定義時に、そのテーブルをアーカイブ可能なテーブルにするよう指示した場合、そのテーブルのアーカイブ指定（５１４）には“Ｙ”が格納される。一方、アーカイブ可能なテーブルでないテーブルのアーカイブ指定（５１４）には“Ｎ”が格納される。

アーカイブディレクトリ（５１５）には、テーブルのレコードがアーカイブファイルに移される時にそのアーカイブファイルの格納されるディレクトリ名が記録される。アーカイブファイルの格納されるディレクトリ名も、ユーザがテーブル定義時に指定する。

ＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）は、スキーマ名（５２１）、表識別子（５２２）、列名（５２３）、列ＩＤ（５２４）、データ型（５２５）、データ定義長（５２６）、アーカイブレンジ列指定（５２７）のカラムを有するレコードを１以上有する。スキーマ名（５２１）、表識別子（５２２）はそれぞれ、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）の表識別子（５１２）、表ＩＤ（５１３）と同じ情報である。列名（５２３）は、テーブルに作成されたカラムの名称、列ＩＤ（５２４）は作成されたカラムの識別番号である。

データ型（５２５）は、作成されたカラムに格納されるデータのタイプが指定される。データのタイプとは図７に示されているように、たとえば整数型（ＩＮＴＥＧＥＲ）、文字列型（ＶＡＲＣＨＡＲ）等である。データ定義長（５２６）は、作成されたカラムに格納されるデータの長さ（最大長）が指定される。スキーマ名（５２１）〜データ定義長（５２６）は、公知のＲＤＢＭＳでも管理される情報である。一方アーカイブレンジ列指定（５２７）は、本実施例に係るデータベース管理プログラム１２０が管理する固有の情報であり、詳細は後述する。

続いて、本実施例に係るデータベース管理プログラム１２０が、テーブル（特にテーブルが有するチャンク）と各アーカイブファイルとの関連付けを管理するための方法について説明する。アーカイブ処理により、複数のアーカイブファイル３２が生成されることがある。そのためデータベース管理プログラム１２０は、各アーカイブファイル３２についての情報を、チャンク管理表６００及びファイル管理表７００を用いて管理する。

チャンク管理表６００の例を図８に示す。チャンク管理表６００は、テーブルを構成する各チャンクのデータの状態（アーカイブされたか否か）を管理するための情報である。１つのレコードが１つのチャンクについての情報を保持する。

６０１〜６０４のカラムのうち、チャンクＩＤ６０３はチャンクの識別番号である。本実施例では、各チャンクに付されているチャンクの識別番号のことを「チャンクＩＤ」と呼ぶ。そしてスキーマ名６０１と表識別子６０２は、チャンクＩＤ６０３で特定されるチャンクが用いられているテーブル３００のテーブル名である。

アーカイブ状態６０４は、このチャンクに格納されている（いた）レコードがアーカイブされたか否かを表す情報である。アーカイブ状態６０４に“Ｙ”が格納されている場合、このチャンクに格納されていたレコードがアーカイブされたことを表す。このチャンクに格納されているレコードがアーカイブされていない（まだテーブル３００に存在する）場合には、アーカイブ状態６０４にはＮＵＬＬが格納される。アーカイブ状態６０４の初期値はＮＵＬＬである。

データインポートツール等のプログラムが実行されることによって、テーブル３００に複数のレコードがロードされる時、テーブル３００に含まれるチャンク（及びそのチャンクのチャンクＩＤ）が新たに定義される。チャンクが定義されると、チャンク管理部２０２はチャンク管理表６００に、定義されたチャンクに対応するレコードを作成し、チャンク管理表６００に作成されたレコードに、スキーマ名６０１と表識別子６０２、そしてチャンクＩＤ６０３を登録する（スキーマ名６０１と表識別子６０２に登録される情報は、作成されたテーブル３００のテーブル名である）。またこの時点では、作成されたレコードのアーカイブ状態６０４は“ＮＵＬＬ”に設定される。

続いてファイル管理表７００の例を図９に示す。ファイル管理表７００は、各アーカイブファイルについての情報を格納するための表で、１つのレコードに１つのアーカイブファイルの情報が格納される。

ｐａｔｈ７０２は、アーカイブファイルのファイル名である。ｐａｔｈ７０２に格納されるファイル名には、相対パス名が用いられる。具体的には、ＳＱＬ＿ＴＡＢＬＥＳ（５１０）のアーカイブディレクトリ（５１５）に記録されているディレクトリからの相対パス名が、ｐａｔｈ７０２に記録される。たとえば図９の先頭行のｐａｔｈ７０２は“2012.tar.gz”、そしてＳＱＬ＿ＴＡＢＬＥＳ（５１０）のアーカイブディレクトリ（５１５）には“/home/archivedir”が記録されているので、図９の先頭行に記録されているアーカイブファイルの記録位置を絶対パス名で表記すると、“/home/archivedir/2012.tar.gz”である。

一方チャンクＩＤ７０１は、ｐａｔｈ７０２に格納されるファイル名称のファイル（アーカイブファイル）に格納されているレコードが、アーカイブ前に格納されていたチャンクを特定するための情報（チャンクＩＤ）である。図９の先頭行のｐａｔｈ７０２は“2012.tar.gz”、そしてチャンクＩＤ７０１は“０”であるから、アーカイブファイル“2012.tar.gz”に格納されているレコードは、元はチャンクＩＤが“０”のチャンクに格納されていたことを表す。

レンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４はそれぞれ、アーカイブファイルに記録されているレコードの特定のカラムの情報の最小値及び最大値を表す。これらの情報は、ＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）のアーカイブレンジ列指定（５２７）と関連する情報である。以下では、図２または図４に記載のレコード（あるいはアーカイブファイルに移動したレコード）、及び図６のディクショナリ５００を例にとって、アーカイブレンジ列指定（５２７）、レンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４について説明する。

本実施例に係るデータベース管理プログラム１２０は、アーカイブファイル３２内のデータ検索を行う際、テーブル内の特定カラムを参照して絞込みを行うことができる。本実施例ではこの特定カラムのことを、「アーカイブレンジ列」または「レンジ列」と呼ぶ。

レンジ列は、テーブル作成（定義）時にユーザから指定される。レンジ列に指定されたカラムの情報は、ディクショナリ５００に記録される。具体的にはＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）のアーカイブレンジ列指定（５２７）に記録される。たとえば図７では、列名（５２３）が“ＲＥＣＯＲＤ＿ＤＡＹ”のレコードのアーカイブレンジ列指定（５２７）に“Ｙ”が記録され、それ以外のレコードのアーカイブレンジ列指定（５２７）の値は“Ｎ”である。これは、定義されたテーブル（スキーマ名（５２１）及び表識別子（５２２）で特定されるテーブル）のカラムのうち、カラム“ＲＥＣＯＲＤ＿ＤＡＹ”（図２の例ではカラム３１３）がレンジ列として指定されたことを意味する。

データベース管理プログラム１２０はアーカイブ処理実行時に、作成したアーカイブファイル３２の情報を格納したレコードをファイル管理表７００に作成する。またテーブル定義時にレンジ列が指定されていた場合、データベース管理プログラム１２０はファイル管理表７００に作成されたレコードのレンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４に、それぞれ作成したアーカイブファイル３２に格納されたレコードのレンジ列の最小値及び最大値を格納する。

図９を参照しながら例を説明する。図９の先頭行には、ファイル“2012.tar.gz”の情報が記録されている。この行のレコードのレンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４はそれぞれ、“2012/01/01”、“2012/12/31”である。これは、アーカイブファイル“2012.tar.gz”に記録されているレコードは、カラム“ＲＥＣＯＲＤ＿ＤＡＹ”（レンジ列）の最小値（最も古い日付）が“2012/01/01”で、最大値（最も新しい日付）が“2012/12/31”であることを表す。

このような情報がファイル管理表７００に記録されているため、アーカイブファイル３２を読み出す数を削減することができる。たとえばデータベース管理プログラム１２０がユーザから、ＲＥＣＯＲＤ＿ＤＡＹが２０１３年以降のレコードを検索する要求を受け付けた時、データベース管理プログラム１２０はファイル管理表７００を参照することで、アーカイブファイル“2012.tar.gz”には２０１３年以降のレコードが格納されていないことを知ることができる。そのためデータベース管理プログラム１２０は、アーカイブファイル“2012.tar.gz”の内容を読み出す処理を省略することができる。

なお、本実施例では、チャンク管理表６００とファイル管理表７００もデータベース管理プログラム１２０が管理するテーブルである。そのためサーバ１がチャンク管理表６００とファイル管理表７００のレコードにアクセスする際、ＳＱＬクエリを発行することでアクセスできる。またチャンク管理表６００とファイル管理表７００の属性情報もディクショナリ５００に格納される。

（５） 処理の流れ
以下では、データ処理システムで実行される処理の流れを説明していく。

（５−１） アーカイブ処理
まずアーカイブ処理の流れを説明する。アーカイブ処理は定期的（１年に１回、或いは半年に１回等）に実行される。あるいは、データ処理システムの管理者がアーカイブ指示をサーバ１に行ったことを契機に、サーバ１はアーカイブ処理を実行してもよい。ただし以下では、定期的にアーカイブ処理が行われる例を説明する。

アーカイブ処理は、アーカイブ管理部２０３が実行する。アーカイブ管理部２０３はＳＱＬ＿ＣＯＬＵＭＮＳ（５２０）を参照することで、レンジ列を特定し、テーブル３００内各レコードのうち、レンジ列の値が所定範囲に属するレコードをアーカイブする。なお、アーカイブ処理は、アーカイブ可能なテーブルに対してのみ行われる。

なお、以下ではアーカイブ管理部２０３が、以下に述べる（１）〜（３）の前提に基づいてアーカイブ処理を行う例を説明する。
（１） アーカイブ対象のテーブル３００の形式は、図２に記載のもので、レンジ列はＲＥＣＯＲＤ＿ＤＡＹである。
（２） アーカイブ処理は定期的、たとえば１年に１回等の周期で行われる。アーカイブ処理実行時に、アーカイブ管理部２０３は、ＲＥＣＯＲＤ＿ＤＡＹ（３１３）に記録されている日付が最も古いレコードを特定し、そのレコードのＲＥＣＯＲＤ＿ＤＡＹ（３１３）と同じ年のレコードをアーカイブする。つまり、たとえば日付が最も古いレコードのＲＥＣＯＲＤ＿ＤＡＹ（３１３）の値が“2012/01/01”の場合、ＲＥＣＯＲＤ＿ＤＡＹ（３１３）に記録された年が２０１２年のレコードのレコード（ＲＥＣＯＲＤ＿ＤＡＹ（３１３）が2012/01/01〜2012/12/31の範囲にあるレコード）がアーカイブファイル３２に移動される。
（３） １つのアーカイブファイル３２に格納されるレコードは、いずれも同一チャンクに格納されていたチャンクとする。言い換えれば、レコードＡがチャンク＃０に格納されており、レコードＢがチャンク＃１に格納されていた場合、アーカイブ管理部２０３は、レコードＡとレコードＢを異なるアーカイブファイル３２に格納する。

但し、これは一例であり、１回のアーカイブ処理でアーカイブファイル３２に移動されるレコードの選択基準は、上で挙げた例に限定されない。たとえば別の例として、１回のアーカイブ処理で、所定個（ｎ個）のチャンクに格納されているレコードをアーカイブ対象とする、というルールに基づいて、アーカイブ処理が行われてもよい。あるいは、レンジ列の値がユーザから指定された範囲内に含まれるレコードがアーカイブされるようにしてもよい。以下、図１０を参照しながら、アーカイブ処理の流れを説明する。

ステップ１００１：アーカイブ管理部２０３は、テーブル３００の中から、今回のアーカイブ処理でアーカイブ対象となるデータを読み出す。この時アーカイブ管理部２０３はクエリ受付部２０４に、ＲＥＣＯＲＤ＿ＤＡＹ（３１３）が所定期間内のデータを読み出すための問い合わせ要求を発行することで、テーブル３００からレコードを取り出すとよい。

さらにアーカイブ管理部２０３は、読み出した全レコードをＣＳＶ形式のレコードに変換する（たとえば図４の行３２０のような形式のテキストを作成する）。そしてアーカイブ管理部２０３は、アーカイブ４にアーカイブファイル３２を作成し、作成されたアーカイブファイル３２に変換されたレコードを格納する。

本実施例では、アーカイブファイル３２のサイズに上限が設けられている。アーカイブファイル３２に変換されたレコードを全て格納するとファイルサイズが上限を超過する場合、アーカイブ管理部２０３は複数のアーカイブファイル３２を作成し、変換された複数のレコードを、複数のアーカイブファイル３２に分けて格納する。

分割の例は以下の通りである。アーカイブ管理部２０３は変換された複数のレコードを、順に１つのアーカイブファイル３２に格納していく。なお、アーカイブファイル３２に変換されたレコードを格納する際には、日付（ＲＥＣＯＲＤ＿ＤＡＹ（３１３））が古いレコードから順に格納されるとよい。その過程でアーカイブファイル３２のサイズが所定の閾値を超過する場合、別のアーカイブファイル３２を作成し、別のアーカイブファイル３２に変換されたレコードを格納する。このようにすることで、アーカイブ管理部２０３は作成されるアーカイブファイル３２のサイズが上限を超過しないようにする。

ステップ１００２：アーカイブ管理部２０３はファイル管理表７００に、作成されたアーカイブファイル３２についてのレコードを作成する。レコードのチャンク７０１には、アーカイブファイル３２に格納されたレコードが存在していたチャンクのチャンクＩＤが格納され、ｐａｔｈ７０２には、アーカイブファイル３２のファイル名が格納される。レンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４にはそれぞれ、アーカイブファイル３２に格納されたレコードのレンジ列（ＲＥＣＯＲＤ＿ＤＡＹ）の最小値と最大値が格納される。

ステップ１００３：アーカイブ管理部２０３はチャンク管理表６００のレコードのうち、今回のアーカイブ処理でレコードがアーカイブされたチャンクに関する情報を管理しているレコードのアーカイブ状態６０４を“Ｙ”に変更する。なお、今回のアーカイブ処理で、アーカイブファイル３２に移動されなかったレコードがチャンクに残ることもある。その場合にもアーカイブ状態６０４は“Ｙ”に変更される。

ステップ１００４：アーカイブ管理部２０３は、今回のアーカイブ処理でレコードがアーカイブされたチャンクから、アーカイブファイル３２に移動されたレコードを削除し、処理を終了する。

（５−２） 検索処理
続いて検索処理の流れを説明する。図１１は、検索処理のフローチャートである。検索処理は、ＤＢサーバ１がユーザからレコード検索を要求する問い合わせ（ＳＱＬクエリ）を受領した時に実行される。

ステップ１１０１：クエリ受付部２０４は、ユーザが使用するクライアント２からＳＱＬクエリを受け付けると、そのクエリをクエリ書換部２０５に渡す。クエリを渡されたクエリ書換部２０５では、受領したクエリの書き換えを行う。

ステップ１１０２：クエリ書換部２０５は、書き換えられたクエリをクエリ最適化部２０６に渡す。クエリ最適化部２０６では、クエリの実行プランの生成が行われる。この処理は、公知のＲＤＢＭＳで行われるものと同様である。

ステップ１１０３：クエリ最適化部２０６は、生成したクエリの実行プランをクエリ実行部２０７に渡す。クエリ実行部２０７は、実行プランに従って処理を行う。クエリ実行部２０７は、データベースアクセス部２０８や表関数処理部２０９を用いて、テーブル３００やアーカイブファイル３２からレコードの読み出しを行い、読み出されたレコードから、クエリで指定された条件に該当するレコードを抽出する。そしてクエリ実行部２０７は、抽出したレコードをクエリ受付部２０４に返送する。クエリ受付部２０４は返送されてきた結果を、ユーザ（クライアント２）へと出力する。

これが検索処理の全体の流れである。以下では各ステップの詳細について説明していく。

（５−３） クエリ書き換え処理
ここでは、ステップ１１０１で行われるクエリの書き換え処理について説明する。ただしその前に、ユーザから渡されるクエリ（書き換え前クエリと呼ぶ）、そしてステップ１１０１において書き換えられた後のクエリ（書き換え後クエリと呼ぶ）の記述例を説明する。

図１２に記載のクエリは、ユーザがサーバ１に対して発行するＳＱＬクエリ（書き換え前クエリ）の例である。ＳＱＬは公知であるため、ここではクエリの概要のみ説明する。なお、図１２等に示されているクエリの各行の先頭に付されている番号は、説明のために付されている行番号である。

図１２の書き換え前クエリの記述内容を簡単に説明する。図１２の書き換え前クエリは、２行目のＦＲＯＭ句で指定されている、テーブル“USER.TBL_01”を検索対象とするクエリである。以下、クエリのＦＲＯＭ句で指定されているテーブルのことを、「検索対象テーブル」と呼ぶ。

またこのクエリは、検索対象のテーブル“USER.TBL_01”の中から、３行目及び４行目のＷＨＥＲＥ句で指定された条件に該当するレコードだけを抽出し、１行目に記載のカラム“ＳＥＱ＿ＮＯ”と“ＵＳＥＲ＿ＤＡＴＡ”を出力することを指示するクエリである。ＷＨＥＲＥ句で指定された条件は具体的には、抽出すべきレコードのカラム“ＳＥＱ＿ＮＯ”がｘより大きく、“ＲＥＣＯＲＤ＿ＤＡＹ”の範囲がｙ〜ｚの間にあることである。なお、実際にはｘには具体的な数値が指定され、ｙ及びｚには具体的な日付が指定される。

また、説明が複雑化することを避けるため、図１２では検索対象テーブルは１つしか指定されていない例を示している。ただし実際には、ＦＲＯＭ句に検索対象テーブルが複数指定されることもある。そのような例については後述する。

ユーザがサーバ１にクエリを発行する際、テーブル３００の一部のレコードがアーカイブされているか否か（アーカイブファイル３２に移動されているか否か）は認識していないし、認識している必要もない。そのためユーザは単純に、図１２に示されているような、テーブル３００からレコードを検索するクエリを発行するが、アーカイブファイル３２からデータを読み出すような要求を発行することはない。

しかし検索対象テーブルがアーカイブ可能なテーブルの場合、クエリで指定されている条件（ＷＨＥＲＥ句で指定される条件等）に該当するデータは、アーカイブファイル３２に格納されていることもあるため、サーバ１はアーカイブファイル３２内のレコード（ＣＳＶ形式に変換されたレコード）も検索対象にする必要がある。そのため、検索対象テーブルがアーカイブ可能なテーブルの場合、サーバ１はクエリの書き換えを行うことで、テーブル３００に加えてアーカイブファイル３２の検索も行うクエリを作成する。

本実施例に係るデータベース管理プログラム１２０は、アーカイブファイル３２の読み出しに表関数を用いる。表関数を用いて記述された、アーカイブファイル３２を読み出すためのクエリの例を図１３に示す。

図１３に示されたクエリは、図１２の書き換え前クエリと同様の検索をアーカイブファイル３２（ファイル2014.tar.gzとaaa.tar.gz）に対して行うクエリである。図１３のクエリと図１２のクエリの違いは、ＦＲＯＭ句に指定された情報だけで、それ以外には違いはない。

ここで用いられている表関数の機能について説明する。表関数ＴＡＢＬＥ（）の引数部分に記述されている関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）は、引数に指定されたファイル（ＣＳＶファイル）から読み出した各行を出力する関数である。ＴＡＢＬＥ（）は、テキスト行をテーブル形式のデータとして出力する関数である。なお、ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数には、複数のファイル名を指定することができる。たとえばＡＤＢ＿ＣＳＶＲＥＡＤ（ＭＵＬＴＩＳＥＴ［2014.tar.gz，aaa.tar.gz］）と記述されている場合、ファイル2014.tar.gzとaaa.tar.gzの読み出しが行われる。また、５行目に記述されている“ＣＯＭＰＲＥＳＳＩＯＮ＿ＦＯＲＭＡＴ＝ＧＺＩＰ”は、引数で指定されるファイルが圧縮形式の場合に指定される引数で、リード対象のアーカイブファイル３２が圧縮形式でない場合には、この引数は不要である。

読み出すべきアーカイブファイル３２のファイル名が既知の場合には、データベース管理プログラム１２０（つまりサーバ１のＣＰＵ１１）は図１３に示されたクエリを実行することで、図１２の書き換え前クエリと同様の検索をアーカイブファイル３２に対して行うことができる。しかし実際には、クライアント２からクエリを受領した時点では、読み出すべきアーカイブファイル３２のファイル名は判明していない。そのため、読み出すべきアーカイブファイル３２のファイル名を特定するための処理を行う必要がある。

チャンク管理表６００には、チャンクが用いられているテーブルのテーブル名（スキーマ名６０１及び表識別子６０２）と、チャンクのアーカイブ状態６０４が含まれている。ファイル管理表７００には、チャンク内レコードがアーカイブされたアーカイブファイルの名称（ｐａｔｈ７０２）が含まれている。そのため、たとえばデータベース管理プログラム１２０が、検索対象テーブルに格納されていたレコードがアーカイブされているアーカイブファイル３２を見つけ出すためには、以下の（ａ）及び（ｂ）の処理を行うとよい。
（ａ）チャンク管理表６００から、スキーマ名６０１及び表識別子６０２が検索対象テーブルの名称と一致し、アーカイブ状態６０４が“Ｙ”のチャンクのチャンクＩＤ６０３を特定する。
（ｂ）さらにファイル管理表７００のレコードの中から、チャンクＩＤ７０１の値が、特定されたチャンクＩＤ６０３と等しいレコードのｐａｔｈ７０２を特定する。

関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数には、ファイル名を直接指定する代わりに、ファイル名を出力する関数やクエリが指定されることも許されている。そのためデータベース管理プログラム１２０（クエリ書換部２０５）は、上の（ａ）、（ｂ）を行う部分クエリ（これを「部分クエリ３」と呼ぶ）を作成し、ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数に部分クエリ３を記述したクエリ（これを「部分クエリ２」と呼ぶ）を作成する。そしてデータベース管理プログラム１２０は、この部分クエリ２を実行することにより、読み出すべきアーカイブファイル３２のファイル名の特定と、特定されたアーカイブファイル３２内のレコード検索を行う。

部分クエリ２の例を図１４に示す。図１３と図１４の違いは、図１４に記載のクエリには、関数ＡＤＢ＿ＣＳＶＲＥＡＤ（）の引数部分に、具体的なファイル名ではなく部分クエリ３が記述されている点である（図１４の５行目〜１２行目）。部分クエリ３のうち５行目〜１１行目が、上で説明した（ａ），（ｂ）の処理を行うためのクエリである。

なお、部分クエリ３の最終行（図１４の１２行目）に記述されている条件について説明する。この条件は、書き換え前クエリのＷＨＥＲＥ句に、レンジ列についての条件が記述されている場合に追加される。以下、検索条件に含まれているレンジ列についての条件を「レンジ列条件」と呼ぶ。

図１２を参照すると、４行目にレンジ列条件（"RECORD_DAY" BETWEEN y AND z）が存在する。この場合、レンジ列（ＲＥＣＯＲＤ＿ＤＡＹ）がｙ〜ｚの範囲にあるレコードを明らかに含まないアーカイブファイル３２を読み出すことは非効率である。そのためデータベース管理プログラム１２０（クエリ書換部２０５）は、書き換え前クエリのＷＨＥＲＥ句に、レンジ列についての条件が記述されている場合、この条件に該当するレコードが含まれている可能性があるアーカイブファイル３２のみを読み出すよう、部分クエリ３にレンジ列に関する条件を追加する。これにより、不必要なアーカイブファイル３２の読み込みが行われることがなくなる。

データベース管理プログラム１２０（クエリ書換部２０５）は、書き換え前のクエリに含まれているレンジ列条件を解析し、部分クエリ３のＷＨＥＲＥ句に条件を付加する。付加される条件は以下のルールに従って決定される。

（ルール１）“レンジ列＜Ａ”の条件がレンジ列条件に含まれている場合、クエリ書換部２０５は“レンジ（Ｍｉｎ．）７０３＜Ａ”の条件を部分クエリ３に付加する。この条件が付加されることにより、レンジ（Ｍｉｎ．）７０３の値がＡ以上のアーカイブファイル３２は、部分クエリ３による検索対象外になる。この条件が付加される理由は、“レンジ（Ｍｉｎ．）７０３≧Ａ”の条件を満たすアーカイブファイル３２には、レンジ列の値がＡ未満のレコードは含まれていないことが明らかだからである。同様に、“レンジ列≦Ａ”の条件がレンジ列条件に含まれている場合、“レンジ（Ｍｉｎ．）７０３≦Ａ”の条件が部分クエリ３に付加される。

（ルール２）“レンジ列＞Ａ”の条件がレンジ列条件に含まれている場合、クエリ書換部２０５は“レンジ（Ｍａｘ．）７０４＞Ａ”の条件を部分クエリ３に付加する。この条件が付加されることにより、レンジ（Ｍａｘ．）７０４の値がＡ以下のアーカイブファイル３２は、部分クエリ３による検索対象外になる。この条件が付加される理由は、“レンジ（Ｍａｘ．）７０４≦Ａ”の条件を満たすアーカイブファイル３２には、レンジ列の値がＡより大きいレコードは含まれていないことが明らかだからである。同様に、“レンジ列≧Ａ”の条件がレンジ列条件に含まれている場合、“レンジ（Ｍａｘ．）７０４≧Ａ”の条件が部分クエリ３に付加される。

クエリ書換部２０５は、上で述べた部分クエリ２を作成し（部分クエリ３の作成も行われる）、さらに部分クエリ２と、テーブル３００内のレコード検索を行うためのクエリ（これを「部分クエリ１」と呼ぶ）の出力結果の和集合を求めるクエリを作成する。本実施例では、これを書き換え後クエリと呼ぶ。図１５は、図１２の書き換え前クエリを書き換えた後のクエリの例である。図中の「部分クエリ１」と記述された部分が、テーブル３００内のレコード検索を行うためのクエリで、この例では、部分クエリ１の内容は書き換え前クエリと同じである。図１５の８行目以降（部分クエリ２）がアーカイブファイル３２からレコードを検索するクエリで、図１４と同じ内容である。書き換え後クエリは、部分クエリ１と部分クエリ２を、６行目に記述されている“ＵＮＩＯＮ ＡＬＬ”演算子で連結したものである。

ただし上で説明した部分クエリ１〜３は一例であり、図１５等に記載されたクエリと同じものが生成されなければいけないわけではない。書き換え前クエリで指定された条件のレコードを、テーブル３００とアーカイブファイル３２の両方から検索でき、かつ読み出すべきアーカイブファイル３２を適切に特定できるクエリが生成されればよい。また、本実施例に係るクエリ書換部２０５が実際に行う処理も、上で説明したものとは若干異なり、書き換え後クエリの記述内容も図１５に記載されたものと異なる点がある。クエリ書換部２０５が実際に行う処理については、以下で説明する。

次に図１６を用いて、クエリの書き換え処理の流れを説明する。以下の説明では、書き換え前クエリとして、図１７に記載のクエリが与えられた場合の例について説明する。図１７は図１２に記述されたクエリの例をより一般化したものである。ＳＥＬＥＣＴ句、ＦＲＯＭ句、ＷＨＥＲＥ句には、実際にはユーザから指定される具体的なカラム名やテーブル名、或いは条件が入るが、以下ではクエリ書き換えの方法を一般化した例を説明するため、クエリ中で指定される情報を、（＄Ａ），（＄Ｂｎ），（＄Ｃ）等の変数に置き換えたクエリを用いて説明を行う。

ＳＥＬＥＣＴ句に含まれる変数（＄Ａ）は、カラム名を表す。なお（＄Ａ）には複数のカラム名が指定されてよい（たとえば図１２のクエリの例では、（＄Ａ）に該当する箇所には"SEQ_NO"と"USER_DATA"の２つのカラムが指定されている）。

また、ＦＲＯＭ句に含まれている変数（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）はそれぞれ、検索対象のテーブル名を表す。（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）のそれぞれが、１つのテーブル名に相当する。つまり図１７のクエリは、検索対象テーブルが複数ある場合の例である。なお、以下では（＄Ｂｘ）のことを「テーブル（＄Ｂｘ）」と呼ぶこともある（ｘは１以上ｎ以下の整数である）。

ＷＨＥＲＥ句に含まれる変数（＄Ｃ）は、クエリで指定される条件を表す。（＄Ｃ）には複数の条件が指定されることがある。たとえば図１２の例では、[SEQ_NO> x]という条件と、["RECORD_DAY" BETWEEN y AND z]という条件が指定されている。

ここでは、ＦＲＯＭ句で指定されたテーブル（＄Ｂ１），（＄Ｂ２），．．．，（＄Ｂｎ）のうち、テーブル（＄Ｂ１）がアーカイブ可能なテーブルだった場合に、クエリ書換部２０５によりどのようにクエリ書き換えが行われるかを説明する。図１８が、図１７の書き換え前クエリが書き換えられた後の例で、３行目〜５行目が部分クエリ１、１０行目〜２６行目が部分クエリ２である。そして部分クエリ２のうち、１４行目〜２１行目が部分クエリ３である。

ステップ１２０１：クエリ書換部２０５は、クエリ受付部２０４から受領したＳＱＬクエリを解析し、検索対象のテーブル（ＦＲＯＭ句に記載されたテーブル）の中で、アーカイブ可能なテーブルを１つ特定する。アーカイブ可能なテーブルの特定のために、クエリ書換部２０５はＳＱＬ＿ＴＡＢＬＥＳ（５１０）を参照し、検索対象のテーブルのうち、アーカイブ指定（５１４）が“Ｙ”のテーブルがあるか判定する。

ステップ１２０２：クエリ書換部２０５は、ステップ１２０１の結果、まだステップ１２０３以降の処理が行われていないアーカイブ可能なテーブルがあれば（ステップ１２０２：Ｙ）、次にステップ１２０３を行う。アーカイブ可能なテーブルがない場合、あるいはすべてのアーカイブ可能なテーブルについてステップ１２０３以降の処理が行われた場合には（ステップ１２０２：Ｎ）、処理を終了する。

そのため、受け付けたクエリによる検索対象テーブルの中にアーカイブ可能なテーブルがない場合には、クエリの書き換えは行われない。また、クエリ書換部２０５に図１２に記載のクエリが渡された場合には、図１２のクエリのＦＲＯＭ句には検索対象のテーブル名が１つ（“USER.TBL_01”のみ）しか記述されていないため、ステップ１２０３以降の処理が１回行われるだけで、処理は終了する。

ステップ１２０３：クエリ書換部２０５は、受け付けたクエリから部分クエリ１を生成する。先に説明したとおり、部分クエリ１は、受け付けた書き換え前クエリで指定されているテーブルからレコードを検索するクエリで、書き換え前クエリと実質的に近い内容のクエリである。

図１８に示されているように、ここで生成される部分クエリ１では、ＳＥＬＥＣＴ句（３行目）に、テーブル（＄Ｂ１）内のカラムのうち、変数（＄Ａ）と（＄Ｃ）に記述されているカラムが指定され、またＷＨＥＲＥ句（５行目）には、変数（＄Ｃ）に含まれる条件のうち、テーブル（＄Ｂ１）に関する条件が指定される。またＦＲＯＭ句にはテーブル（＄Ｂ１）が指定される。

ステップ１２０４：ステップ１２０４〜ステップ１２０６において、クエリ書換部２０５は部分クエリ３の生成を行う。ステップ１２０４では、クエリ書換部２０５は部分クエリ３のうち、レンジ列条件以外の部分を生成する。具体的には、図１８に示された例における、１４行目〜２０行目に記述された部分が生成される。

１４行目〜２０行目に記述された部分は、先に述べた（ａ）及び（ｂ）の処理を行うクエリである。つまり１４行目〜２０行目に記述されたクエリが実行されると、チャンク管理表６００から、スキーマ名６０１及び表識別子６０２がテーブル（＄Ｂ１）の名称と一致し、アーカイブ状態６０４が“Ｙ”のチャンクのチャンクＩＤ６０３が特定される。さらにファイル管理表７００のレコードの中から、チャンクＩＤ７０１の値が、特定されたチャンクＩＤ６０３と等しいレコードのｐａｔｈ７０２が特定される。

ステップ１２０５：クエリ書換部２０５はさらに、書き換え前のクエリにレンジ列条件が含まれているか（レンジ列が検索条件に含まれているか）判定する。レンジ列が検索条件に含まれている場合（ステップ１２０５：Ｙ）、ステップ１２０６が実行され、レンジ列が検索条件に含まれていない場合は（ステップ１２０５：Ｎ）、ステップ１２０６はスキップされる。

ステップ１２０６：この処理は、図１４の部分クエリ３の例を用いて説明した処理で、レンジ列条件に該当するレコードが含まれないアーカイブファイル３２の読み出しを行わないようにするために、部分クエリ３のＷＨＥＲＥ句に条件を付加する処理である。クエリ書換部２０５は、上で説明したルール１、ルール２に従って、レンジ（Ｍｉｎ．）７０３及びレンジ（Ｍａｘ．）７０４を用いた条件を生成し、ここで生成した条件を、ステップ１２０４で作成した部分クエリ３のＷＨＥＲＥ句（図１８の２１行目）に付加する。ここで生成される条件の具体例は、先に説明したとおりであるので、ここでの説明は略す。

ステップ１２０７：クエリ書換部２０５は、ステップ１２０６までで作成された部分クエリ３を含む部分クエリ２を生成する。部分クエリ２のＳＥＬＥＣＴ句（図１８の１０行目）、ＷＨＥＲＥ句（図１８の２６行目）に指定される情報は、部分クエリ１のものと同じである。そして部分クエリ２のＦＲＯＭ句には、ステップ１２０６までで作成された部分クエリ３を引数に含む表関数が指定される。

ステップ１２０８：クエリ書換部２０５は、ここまでで作成された部分クエリ１及び部分クエリ２の出力結果の和集合を出力するクエリを生成する。具体的には、図１８（３行目〜２６行目）に示されているように、クエリ書換部２０５は、部分クエリ１と部分クエリ２を“ＵＮＩＯＮ ＡＬＬ”演算子で連結したクエリを生成する。そして書き換え前クエリのＦＲＯＭ句に指定されているテーブルを、ここで生成したクエリに書き換える。たとえばステップ１２０１でテーブル（＄Ｂ１）が選択された場合、書き換え前クエリのＦＲＯＭ句のうち、（＄Ｂ１）部分を、ここで生成したクエリに書き換える。図１８では（＄Ｂ１）が書き換えられた例が示されている。この後クエリ書換部２０５は、再びステップ１２０１からの処理を実行する。

（５−４） 実行プラン生成と最適化
最後に、ステップ１１０２、ステップ１１０３で行われる、実行プランの生成、実行処理について説明する。本実施例における実行プランの生成処理は、公知のＲＤＢＭＳで行われるものと大きく変わるところはないため、本実施例における実行プランの生成及び実行処理の概要を述べる。

本実施例に係るデータ処理システムでは、サーバ１が複数のＣＰＵ１１を有するので、幾つかの処理を並列に実行することができる。そこでクエリ最適化部２０６は、実行プランを生成する際、並列化可能な複数の処理がある場合、それらの処理が並列実行されるような実行プランを生成する。

並列化可能な処理とは、たとえば互いに依存関係のない処理である。逆に依存関係のある処理同士は並列実行できない。たとえば図１５等に記載の書き換え後クエリの中で、部分クエリ２と部分クエリ３は、互いに依存関係がある。つまり部分クエリ３が実行されて、読み出すべきアーカイブファイル３２のファイル名が特定されるまでは、部分クエリ２は実行できないため、この２つのクエリについての処理は並列化されない。そのためクエリ最適化部２０６は、部分クエリ３の実行が完了してから部分クエリ２に関する処理を実行するような実行プランを生成する。

一方、部分クエリ１と部分クエリ２の間には依存関係がない。部分クエリ１の実行のためには、記憶装置３内のテーブル３００を読み出す必要があり、また部分クエリ２の実行のためにはアーカイブ４内のアーカイブファイル３２を読み出す必要があるが、テーブル３００の読み出しとアーカイブファイル３２の読み出しには互いに依存関係がない（テーブル３００を読み出すまでアーカイブファイル３２を読み出すことができない等の制約がない）。そのためクエリ最適化部２０６は、テーブル３００の読み出しとアーカイブファイル３２の読み出しを並列に実行する実行プランを生成し、クエリ実行部２０７に実行させる。クエリ実行部２０７ではそのような実行プランを受領すると、たとえばテーブル３００の読み出しを行うタスク（スレッド）とアーカイブファイル３２の読み出しを行うタスクとを生成し、両者を並列実行する。なお、並列実行可能なタスクの数は、サーバ１の構成（ＣＰＵまたはプロセッサコアの数、あるいは同時にサーバ１で実行されているタスクの状況等）によって異なり得るため、クエリ最適化部２０６はサーバ１の構成にあわせてタスクを並列実行するか否かを決定してもよい。本実施例のように、クエリを解析することで実行プランを生成する方法の場合、サーバ１の構成などの状態に応じて、並列実行させるタスクの数を動的に変更することも可能になる。そのため、クエリに係る処理を効率的に実行することができる。

また、部分クエリ３の実行の結果、リード対象のアーカイブファイル３２が複数（たとえばｍ個）特定された場合、ｍ個のアーカイブファイル３２の読み出し処理を並列実行可能である。そのためクエリ最適化部２０６は、アーカイブファイル３２の読み出しを並列実行する実行プランを生成し、クエリ実行部２０７に実行させる。

先に述べたとおり、アーカイブ管理部２０３がアーカイブファイル３２を作成するとき、ファイルサイズに上限を設け、各アーカイブファイル３２のサイズが所定の閾値以内に収まるようにしている。その結果、生成されるアーカイブファイル３２のサイズはおおむね等しくなる（閾値に近いサイズになっている）。

そのため、クエリ実行部２０７が各アーカイブファイル３２の読み出しを並列実行すると、それぞれのアーカイブファイル３２の読み出しの所要時間はおおむね等しくなる。これは各アーカイブファイル３２のサイズがおおむね等しいからである。もし各アーカイブファイル３２のサイズに偏りがあり、特定のアーカイブファイル３２のサイズが極端に大きい場合、そのアーカイブファイル３２の読み出しに時間がかかり、並列処理の効果がなくなる。結果として部分クエリ２の実行に要する時間が長時間化することになる。本実施例に係るデータ処理システムでは、アーカイブ時にアーカイブファイル３２のサイズを所定の閾値以内に収め、各アーカイブファイル３２のサイズが等しくなるようにしている為、クエリ実行時の並列処理の効果が得られやすい。

また、テーブル３０は複数のチャンクを有している。記憶装置３内に所定サイズの区画（連続領域）が複数形成され、各チャンクがこの各区画に格納されている場合、各チャンクを並列に読み出すことで、チャンクのリードに要する時間を短くできることがある。そのためこの場合、クエリ最適化部２０６は部分クエリ１の実行プランを生成する際、チャンクからのデータリードを並列実行する実行プランを生成してもよい。これによりテーブル３０のリード処理の速度をより向上させることができる。

以上、本発明の実施例を説明したが、これは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。

たとえば上で説明した実施例に係るデータ処理システムでは、ＤＢサーバとは別にクライアントが設けられ、ユーザはクライアントの入力装置及び出力装置を用いる例が説明された。ただし、クライアントを設けることは必須ではなく、ＤＢサーバでクライアントプログラムが実行される構成にしてもよい。その場合ユーザは、ＤＢサーバの入出力デバイスを用いて、情報検索のリクエストを発行するとよい。

また、ＤＢサーバの台数は１台に限定されない。データ処理システムに複数のＤＢサーバを設けて、検索処理等を複数のＤＢサーバで並列実行させるようにしてもよい。

また、上で説明した実施例では、ＤＢサーバはテーブルとアーカイブファイルの関係を管理するために、２つの表（チャンク管理表とファイル管理表）を保持しているが、２つの表を保持する代わりに、チャンク管理表が保持する属性とファイル管理表の保持する属性とを有する１つの表（仮に「アーカイブ管理表」と呼ぶ）を保持するようにしてもよい。その場合、ＤＢサーバが生成する部分クエリ３は、アーカイブ管理表の中から、検索条件に該当するアーカイブファイル名を検索するクエリになる。

上で説明された各種プログラムは、プログラム配布サーバや計算機が読み取り可能な記憶メディアによって提供され、プログラムを実行する各装置にインストールされてもよい。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、例えばＩＣカード、ＳＤカード、ＤＶＤ等の不揮発性記憶媒体である。

また、上の実施例で説明されたプログラムの一部または全ての処理は、専用ハードウェアによって実現されてもよい。

１：サーバ、２：クライアント、３，４：記憶装置、５：ＳＡＮ、６：ＬＡＮ

Claims (15)

1. サーバと第１の記憶装置と第２の記憶装置を備え、
   前記サーバは、複数の列を含む１以上のテーブルを前記第１の記憶装置に格納し、前記テーブルから抽出された１以上のレコードを含む複数のアーカイブファイルを前記第２の記憶装置に格納するよう、構成されており、
   前記サーバは検索要求を受け付けると、
   前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成し、
   前記検索要求で検索対象とされている前記テーブルから抽出されたレコードを含む前記アーカイブファイルを特定して、特定された前記アーカイブファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成し、
   前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成し、
   前記生成されたクエリを解析し、前記クエリに係る処理を並列実行する、
   データ処理システム。
2. 前記第２の部分クエリは、前記アーカイブファイルから前記テーブルの形式のデータを出力するための表関数を含む、
   請求項１に記載のデータ処理システム。
3. 前記サーバは、前記生成されたクエリを解析して、少なくとも前記第１の部分クエリに係るタスクと前記第２の部分クエリに係るタスクを生成し、前記生成されたタスクを並列実行する、
   請求項１に記載のデータ処理システム。
4. 前記テーブルは、複数のレコードの集合であるチャンクを複数有し、
   前記サーバは、前記第１の部分クエリを解析し、前記テーブルに含まれる前記チャンクにアクセスするタスクを前記チャンクごとに生成し、前記チャンクにアクセスするタスクを並列実行する、
   請求項１に記載のデータ処理システム。
5. 前記サーバは、前記テーブルから所定の条件に該当する１以上のレコードを抽出してアーカイブファイルに移動するアーカイブ処理を定期的に実行し、
   前記アーカイブ処理の実行時に、前記サーバは、抽出された前記レコードの量が所定の上限値を超過する場合、前記抽出されたレコードを複数のアーカイブファイルに分けて格納する、
   請求項１に記載のデータ処理システム。
6. 前記サーバは、前記第２の部分クエリを実行することにより、複数の前記アーカイブファイルが特定された場合、
   特定された複数の前記アーカイブファイルに並列にアクセスする、
   請求項５に記載のデータ処理システム。
7. 前記サーバは前記テーブルの定義時に、前記複数の列のうち、データ絞込みに使われる列であるレンジ列の指定を受け付け、
   前記サーバは前記アーカイブ処理の実行時に、作成されたアーカイブファイルに含まれる前記レコードのレンジ列の最小値及び最大値を記録したファイル管理表を作成し、
   前記サーバは、受け付けた前記検索要求でレンジ列の条件が指定されている場合、
   前記ファイル管理表を用いて前記レンジ列の条件に該当するレコードを有する前記アーカイブファイルを特定する、第３の部分クエリを生成し、
   前記第２の部分クエリとして、前記第３の部分クエリを含む部分クエリを生成する、
   請求項５に記載のデータ処理システム。
8. 複数の列を含む１以上のテーブルと、前記テーブルから抽出された１以上のレコードを含む複数のアーカイブファイルと、を管理するデータ処理システムにおいて、
   前記データ処理システムが、
   ａ） 検索要求を受け付ける工程と、
   ｂ） 前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成する工程と、
   ｃ） 前記検索要求で検索対象とされている前記テーブルから抽出されたレコードを含む前記アーカイブファイルを特定して、特定された前記アーカイブファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成する工程と、
   ｄ） 前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成する工程と、
   ｅ） 前記生成されたクエリを解析し、前記クエリに係る処理を並列実行する工程と、
   を実行する、データ処理システムのデータ検索方法。
9. 前記ｅ）において、少なくとも前記第１の部分クエリに係るタスクと前記第２の部分クエリに係るタスクを生成し、前記生成されたタスクを並列実行する、
   請求項８に記載のデータ処理システムのデータ検索方法。
10. 前記テーブルから所定の条件に該当する１以上のレコードを抽出してアーカイブファイルに移動するアーカイブ処理工程を実行し、
    前記アーカイブ処理工程では、抽出された前記レコードの量が所定の上限値を超過する場合、前記抽出されたレコードは複数のアーカイブファイルに分けて格納される、
    請求項８に記載のデータ処理システムのデータ検索方法。
11. 前記ｅ）において、前記第２の部分クエリを実行することにより、複数の前記アーカイブファイルが特定された場合、
    特定された複数の前記アーカイブファイルに並列にアクセスする工程を実行する、
    請求項１０に記載のデータ処理システムのデータ検索方法。
12. 前記データ処理システムがさらに、前記テーブルの定義時に、前記複数の列のうちデータ絞込みに使われる列であるレンジ列の指定を受け付ける工程を実行し、
    前記アーカイブ処理工程は、作成されたアーカイブファイルに含まれる前記レコードのレンジ列の最小値及び最大値を記録したファイル管理表を作成する工程を含み、
    前記ａ）において受け付けた前記検索要求にレンジ列の条件が指定されている場合、
    前記ｃ）では、前記ファイル管理表を用いて前記レンジ列の条件に該当するレコードを有する前記アーカイブファイルを特定する、第３の部分クエリを生成し、前記第２の部分クエリとして前記第３の部分クエリを含む部分クエリを生成する、
    請求項１０に記載のデータ処理システムのデータ検索方法。
13. 複数の列を含む１以上のテーブルと、前記テーブルから抽出された１以上のレコードを含む複数のアーカイブファイルと、を管理するコンピュータのプロセッサに、
    ａ） 検索要求を受け付ける工程と、
    ｂ） 前記検索要求で指定された条件に該当するレコードを前記テーブルから検索する、第１の部分クエリを生成する工程と、
    ｃ） 前記検索要求で検索対象とされている前記テーブルから抽出されたレコードを含む前記アーカイブファイルを特定して、特定された前記アーカイブファイルから前記検索要求で指定された条件に該当するレコードを検索するクエリである、第２の部分クエリを生成する工程と、
    ｄ） 前記第１及び第２の部分クエリの出力結果の和集合を求めるクエリを生成する工程と、
    ｅ） 前記生成されたクエリを解析し、前記クエリに係る処理を並列実行する工程と、
    を実行させるプログラムを記録した、コンピュータ読み取り可能な記憶媒体。
14. 前記プロセッサに、
    前記テーブルから所定の条件に該当する１以上のレコードを抽出してアーカイブファイルに移動するアーカイブ処理工程を実行させ、
    前記アーカイブ処理工程では、抽出された前記レコードの量が所定の上限値を超過する場合、前記抽出されたレコードを複数のアーカイブファイルに分けて格納させる、
    プログラムを記録した、請求項１３に記載のコンピュータ読み取り可能な記憶媒体。
15. 前記テーブルの定義時に前記プロセッサに、前記複数の列のうちデータ絞込みに使われる列であるレンジ列の指定を受け付ける工程を実行させ、
    前記アーカイブ処理工程は、前記プロセッサに、作成されたアーカイブファイルに含まれる前記レコードのレンジ列の最小値及び最大値を記録したファイル管理表を作成させる工程を含み、
    前記ａ）において、受け付けた前記検索要求にレンジ列の条件が指定されている場合、
    前記ｃ）において、前記プロセッサに、前記ファイル管理表を用いて前記レンジ列の条件に該当するレコードを有する前記アーカイブファイルを特定する、第３の部分クエリを生成させ、前記第２の部分クエリとして前記第３の部分クエリを含む部分クエリを生成させる、
    プログラムを記録した、請求項１４に記載のコンピュータ読み取り可能な記憶媒体。

Images