説明

解析処理用のデータベース装置、解析処理方法及び解析処理プログラム

【課題】データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮する。
【解決手段】ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データベースの解析処理に関する。
【背景技術】
【0002】
データベースに関する技術として、解析処理、或いはOLAP(Online Analytics Processing)処理と呼ばれる処理が存在する。これらの処理により、企業データのレポートや解析を行うことが可能となる。具体例としては、リテール業者が、POS(Point of sale system)の記録のレポートや解析を行うことで、事業の状況を把握したり、売り上げ向上のために製品配置を工夫したりすることが可能となる。
【0003】
これらの処理においては、クエリに指示されたアグリゲーションの計算に必要なアトリビュートを持つレコードが挿入され、その後にレコードが更新され、その直後にアグリゲーションを含むデータに対して解析クエリが実行される。もっとも、これらの一連の処理において遅延が生じることがあり問題となっている。この点について詳細に説明する。
【0004】
以下の(1−1)から(1−8)のステップで解析の準備処理と解析処理が行われる。
【0005】
(1−1)アグリゲーションの計算に必要なアトリビュートを持つレコードである、入力レコードが挿入あるいは更新される。
【0006】
(1−2)解析の準備処理を開始する。入力レコードを用いて他のテーブルとのジョイン処理を行って、セレクション項に要求されているアトリビュートを取得する。
【0007】
(1−3)セレクション処理を行う。
【0008】
(1−4)セレクションが真であった場合、テーブル間でのジョイン処理を行って、アグリゲーション処理に必要なアトリビュートを取得する。
【0009】
(1−5)アグリゲーション処理を行う。
【0010】
(1−6)アグリゲーションの結果をテーブルに保存する。この際に、他のクエリでもこのアグリゲーションの結果を再利用できるようにする。具体的には、他のクエリでセレクションやGROUP BYやHAVINGで用いられる可能性のあるアトリビュートに対するインデックスを作成する。更に、インデックスを辿って、結果を保存する場所を特定、または決定する。
【0011】
(1−7)解析処理を開始する。
【0012】
(1−8)アグリゲーション結果が格納されているテーブルからアグリゲーション結果を取得する。
【0013】
ここで、上記(1−6)の処理、特にインデックスを辿る処理に起因した遅延が問題であった。
【0014】
この点について、図4を参照して具体例を用いながら説明する。
【0015】
今回の説明では、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを例として取り上げる。
【0016】
ordersテーブルに、ある1セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図4を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【0017】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図4を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID(図示を省略する)を持つ。
【0018】
次に、customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図4を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【0019】
今回の説明では、まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。また、解析処理として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【0020】
<実行するクエリ>
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
【0021】
また、前提として、上述したようにc_custkeyが100、c_mktsegmentがautomotiveのレコードがcustomerテーブルに用意され、o_orderkeyが200、o_orderdateが2011-04-01のレコードがordersテーブルに用意されているとする。
【0022】
次に、l_orderkeyが200、l_cuskeyが100、のレコードが挿入され、その後にl_extendedpriceが$200に更新されるとする。
【0023】
更に、解析の準備処理で用いるaggregationテーブルを用意する。このaggregationテーブルでは、セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成しておくとする。
【0024】
ここで、次のステップで解析の準備処理と、解析処理が行われる。
【0025】
(2−1)lineitemへレコードを挿入し、次にそのレコードを更新する。このレコードを入力レコードと呼ぶ。
【0026】
(2−2)解析の準備処理を開始する。まず、入力レコードのl_custkeyの値を使って、customerテーブルとジョインする。すなわち、セレクションに必要なc_mktsegmentのアトリビュートを取得する。同様に、orderテーブルとジョインして、セレクションに必要なo_orderdateのアトリビュートを取得する。
【0027】
(2−3)セレクション処理を行う。すなわち、c_mktsegmentの値がautomotiveであり、o_orderdateが4/1であり3/3より後ろであるので、セレクションの結果は真となる。
【0028】
(2−4)セレクションの結果が真であったので、入力レコードのl_orderkeyの値を使って、ordersテーブルとジョインする。すなわち、アグリゲーション処理のうち、GROUP BYの処理に必要なアトリビュートo_orderdateを取得する。
【0029】
(2−5)アグリゲーション処理を行う。
【0030】
(2−6)アグリゲーションの結果をテーブルに保存する。つまり、c_mktsegmentと、o_orderdateを使ってインデックスを辿る。c_mktsegmentで辿るのは他のクエリで再利用できるようにするため、o_orderdateで辿るのは、GROUP BYの処理がアグリゲーション処理結果をいくつかの行に分けて格納することを要求しているためである。そして、見つけた場所に結果を保存する。
【0031】
(2−7)解析処理を開始する。
【0032】
(2−8)c_mktsegmentと、o_orderdateを使ってインデックスをたどり、アグリゲーション結果が格納されている場所を取得する。更に、この場所に保存されている情報を用いて、アグリゲーション結果を取得する。
【0033】
ここで、ステップ(2−6)、特にインデックスを辿る処理の遅延が課題であった。
【0034】
この点、上述したような解析クエリの遅延を短縮するための方法として、解析の準備処理段階で中間テーブルにジョイン結果やアグリゲーション結果を格納するという方法がある。この方法を以下の説明では「中間テーブル利用方法」と呼ぶ。
【0035】
この、中間テーブル利用方法では、中間テーブルにジョイン結果やアグリゲーション結果を格納した後に解析処理を開始して、その中間テーブルを参照して途中結果を再利用する。これにより、解析処理の遅延を削減することができる。この中間テーブルには、例えば、解析クエリを素早く計算できるようなデータ配置を行い、更にインデックスを持たせる。
【0036】
より詳細に説明すると、解析の準備処理では、複数の解析クエリに対して再利用できる中間テーブルを作成する。すなわち、セレクションやGROUP BYやHAVINGで用いられる可能性のあるアトリビュートに対して行を分割する。そして、更にそれらのアトリビュートに対するインデックスを作成して、クエリごとに、セレクションやGROUP BYやHAVINGの条件に応じて適切な途中結果を再利用できるようにする。
【0037】
このような中間テーブル利用方法を利用する技術としては、例えば特許文献1乃至3が挙げられる。特許文献1乃至3ではこれらの中間テーブル利用方法を用いた解析処理用データベースに関する技術が記載されている。以下、図5と図6を参照して、これらの解析処理用データベースについて説明する。
【0038】
図5のブロック図には、代表的な解析処理用データベース500が表されている。
【0039】
図5を参照すると、解析処理用データベース500は、入力格納部501、ジョイン部502、ジョイン結果格納部503、インデックス格納部504、テーブル格納部505、セレクション部506、アグリゲーション計算部507、インデックストラバーサル部508及びアグリゲーション結果格納部509を含む。
【0040】
そして、入力格納部501が入力レコードを格納し、解析準備処理が開始されると、ジョイン部502がクエリに指示されたセレクションとアグリゲーションに必要なアトリビュートを取得するためのジョイン処理を行う。その際に、インデックス格納部504とテーブル格納部505を参照する。そして、ジョインの結果をジョイン結果格納部503に格納する。
【0041】
また、セレクション部506がジョイン結果格納部503からセレクションに必要なアトリビュートを取得し、セレクション処理を行う。更に、セレクション結果が真の場合、ジョイン結果格納部503からアグリゲーションに必要なアトリビュートを取得し、アグリゲーション計算部507がアグリゲーション計算を行う。更に、インデックストラバーサル部508が、アグリゲーション結果格納部509の、アグリゲーション結果を格納するレコードの場所を、インデックス格納部504を参照して取得する。そして、アグリゲーション結果格納部509にアグリゲーション結果を格納する。解析処理が開始されると、アグリゲーション結果格納部509を参照して結果を取得する。
【0042】
続いて、図6に表される具体例を参照して解析処理用データベース500が行う処理について更に説明する。
【0043】
今回の説明では、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを例として取り上げる。
【0044】
ordersテーブルに、ある1セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図6を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【0045】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図6を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID(図示を省略する)を持つ。
【0046】
customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図6を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【0047】
今回の説明では、まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。また、解析処理として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【0048】
<実行するクエリ>
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
また、前提として、上述のようにc_custkeyが100、c_mktsegmentがautomotiveのレコードがcustomerテーブルに用意され、o_orderkeyが200、o_orderdateが2011-04-01のレコードがordersテーブルに用意されているとする。
【0049】
次に、l_orderkeyが200、l_cuskeyが100、のレコードが挿入され、その後にl_extendedpriceが$200に更新されるとする。
【0050】
更に、解析の準備処理で用いるaggregationテーブルを用意する。セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、aggregationテーブルでは、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成しておくとする。
【0051】
ここで、次のステップで解析の準備処理と、解析処理が行われる。
【0052】
(3−1)l_orderkeyが200、l_custkeyが100のlineitemのレコードをlineitemに挿入する。次にl_extendedpriceを$200に更新する。このレコードを入力レコードと呼ぶ。
【0053】
(3−2)解析の準備処理を開始する。入力レコードとcustomerテーブル、ordersテーブルとジョインして、セレクションとアグリゲーションに必要とされるアトリビュートを取得し、joinedテーブルに挿入する。あるいは、これらのアトリビュートをジョイン対象のテーブル上で特定できるIDを取得し、joinedテーブルに挿入する。
【0054】
(3−3)ジョイン結果を参照して、セレクションに合致していることを確認する。ひとつ前のステップで、アトリビュートの代わりにアトリビュートを指すIDを挿入した場合は、IDを用いてテーブルからアトリビュートを取り出して、その値を用いてセレクションに合致していることを確認する。
【0055】
(3−4)aggregationテーブルをインデックスによって辿る。つまり、c_mktsegmentと、o_orderdateを使ってインデックスを辿る。c_mktsegmentで辿るのは他のクエリで再利用できるようにするためである。また、o_orderdateで辿るのは、GROUP BYの処理がアグリゲーション処理をいくつかの行に分けて格納することを要求しているためである。
【0056】
(3−5)見つけた場所にl_extendedpriceの和を足しこむ。
【0057】
(3−6)解析処理を開始する。c_mktsegmentと、o_orderdateを使ってインデックスを辿り、アグリゲーション結果が格納されている場所を取得する。更に、この場所の情報を用いて、アグリゲーション結果を取得する。
【先行技術文献】
【特許文献】
【0058】
【特許文献1】特開2006−65846号公報
【特許文献2】特表2002−510088号公報
【特許文献3】特開2000−339390号公報
【発明の概要】
【発明が解決しようとする課題】
【0059】
上述したように、特許文献1乃至3等に記載されているような中間テーブル利用方法では、解析の準備処理において、クエリのセレクション処理やアグリゲーション処理に必要なアトリビュートについて、ジョイン結果を事前に実行して、その結果を中間テーブルに格納しておく。そして、解析処理の際に、クエリはジョインを行うことなく、その中間テーブルを参照する。こうすることで、解析処理の際に、セレクション処理やアグリゲーション処理に必要なジョイン処理を省略できて遅延が短縮される。
【0060】
しかし、アグリゲーション結果を格納する場所を探すステップ(上記のステップ(3−4))で依然インデックスを辿る処理が生じており、この点に起因する遅延については解消できていなかった。
【0061】
そこで、本発明は、データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮することが可能な解析処理用のデータベース装置、解析処理方法及び解析処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0062】
本発明の第1の観点によれば、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置が提供される。
【0063】
本発明の第2の観点によれば、データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法が提供される。
【0064】
本発明の第3の観点によれば、データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラムが提供される。
【発明の効果】
【0065】
本発明によれば、データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮することが可能となる。
【図面の簡単な説明】
【0066】
【図1】本発明の実施形態であるデータベース処理装置の基本的構成を表すブロック図である。
【図2】本発明の実施形態であるデータベース処理装置の基本的動作を表すフローチャートである。
【図3】本発明の実施形態であるデータベース処理装置におけるデータベースのテーブルの一具体例を表す図である。
【図4】背景技術を説明するためのデータベースのテーブルを表す図である。
【図5】一般的な技術におけるデータベース処理装置のブロック図である。
【図6】一般的な技術におけるデータベースのテーブルの一具体例を表す図である。
【発明を実施するための形態】
【0067】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【0068】
《実施の形態》
図1を参照すると、本発明の実施の形態にかかる解析処理用データベース装置100は、イベントフェーズ検知部101と、ジョイン部102と、アグリゲーション結果格納先決定部131と、ジョイン結果格納部111と、アグリゲーション結果格納先情報格納部112と、インデックス格納部113と、テーブル格納部114と、セレクション部121と、アグリゲーション結果格納先情報参照部123と、アグリゲーション計算部122と、アグリゲーション結果格納部124とを含む。
【0069】
イベントフェーズ検知部101は、入力レコードからイベントのフェーズを検知する機能を有する。
【0070】
ジョイン部102は、入力レコードを用いてクエリに必要なアトリビュートを揃える機能を有する。
【0071】
アグリゲーション結果格納先決定部131は、アグリゲーションの結果の格納先を決定する機能を有する。
【0072】
ジョイン結果格納部111は、ジョインの結果を格納する記憶装置である。また、アグリゲーション結果格納先情報格納部112は、アグリゲーション結果の格納先のアドレスを格納する記憶装置である。更に、インデックス格納部113は、テーブルのインデックスを格納する記憶装置である。加えて、テーブル格納部114は、入力レコードやジョイン対象のテーブルを格納する記憶装置である。
【0073】
セレクション部121は、クエリによって指示されたセレクションを行う機能を有する。
【0074】
アグリゲーション結果格納先情報参照部123は、アグリゲーション結果の格納先情報を取り出す機能を有する。
【0075】
アグリゲーション計算部122は、アグリゲーションを計算する機能を有する。
【0076】
アグリゲーション結果格納部124は、アグリゲーションの結果を格納する記憶装置である。
【0077】
解析処理用データベース装置100は、ハードウェアとして実現することもできるし、ハードウェアとソフトウェアの組合せにより実現できる。具体的には、汎用のサーバやパーソナルコンピュータ又は本実施形態専用の機器、といったコンピュータに、本実施形態特有のプログラムを組み込み、コンピュータが有する演算処理部がこのプログラムに応じた演算処理を行うことにより解析処理用データベース装置100を実現することができる。
【0078】
また、解析処理用データベース装置100が有する各格納部は、例えば、HDD(Hard disk drive)やFlash SSD(Solid State Drive)又はDRAM(Dynamic Random Access Memory)等により実現される。また、この記憶装置は汎用のサーバや、パーソナルコンピュータといったコンピュータ内にある必要はなく、外部の記憶装置を利用するようにしてもよい。この場合記憶装置を別のコンピュータとして実現し、バスやUSB(Universal Serial Bus)規格に準拠したケーブルや、インターネット等の手段を用いて接続するようにしてもよい。また、解析処理用データベース装置100が有する各格納部は、単一の記憶装置により実現することもできるが、複数の記憶装置により実現してもよい。
【0079】
また、解析処理用データベース装置100に含まれる各部は以下のように協働して動作を行う。
【0080】
つまり、イベントフェーズ検知部101が、レコードの挿入や更新のイベントについて、そのレコードを調べる。そして、イベントフェーズ検知部101は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃ったフェーズなのか、アグリゲーションに必要なアトリビュートが揃ったフェーズなのかを検知する。
【0081】
ジョイン部102は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃ったフェーズをイベントフェーズ検知部101が検知した場合に、クエリに必要なアトリビュートを揃えるためにジョイン処理を行う。そして、ジョイン部102は、このジョイン処理を行うために、インデックス格納部113とテーブル格納部114を参照する。ジョイント処理の結果はジョイン結果格納部111に格納する。
【0082】
アグリゲーション結果格納先決定部131は、クエリに指示されたアグリゲーション処理について、アグリゲーション結果の格納先を決定する。ここで格納先とは、アグリゲーション結果格納先情報格納部112のアドレスである。更に、アグリゲーション結果格納先決定部131は、決定したアドレスに基づいてアグリゲーション結果格納先情報格納部112にアグリゲーション結果を格納する。
【0083】
セレクション部121は、ジョイン結果格納部111からセレクションの実行に必要なアトリビュートを取得し、セレクションを実行する。
【0084】
アグリゲーション計算部122は、セレクションの結果が真の場合に、ジョイン結果格納部111からアグリゲーションに必要なアトリビュートを取得し、アグリゲーション計算を行う。更に、アグリゲーション計算部122は、アグリゲーション結果格納先情報参照部123を経由して、アグリゲーション結果格納先情報格納部112からアグリゲーション結果を格納するアドレスを取得する。そして、アグリゲーション計算部122は、アグリゲーション結果を、取得したアドレスに基づいてアグリゲーション結果格納部124に格納する。
【0085】
次に本実施の形態にかかる解析処理用のデータベース装置100の動作について、図2のフローチャートを参照して説明する。
【0086】
前提として、解析に必要とされるレコードは、まず挿入されて、その後更新されるものとする。また、挿入されるときに、アグリゲーションの結果を格納する場所が決定できる情報が揃うものとする。また、更新されるときに、アグリゲーションの結果を計算できるものとする。更に、解析のクエリの処理に関係するレコードのことを入力レコードと呼ぶ。
【0087】
まず、イベントフェーズ検知部101が、レコードの挿入や更新のイベントを調べる。続いて、イベントフェーズ検知部101が、インデックス格納部113に格納されているインデックスを参照し、このインデックスに基づいて、入力レコードをテーブル格納部114に格納する(ステップS1100)。
【0088】
ここで、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃った場合は(ステップS1101においてYes)、ステップS1102に進む。
【0089】
一方、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃わない場合は(ステップS1101においてNo)、ステップS1201に進む。
【0090】
なお、ステップS1101での判断条件を変更することも可能である。具体的には、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードにはないアグリゲーション計算に必要なアトリビュート及びHAVINGに必要なアトリビュートが揃ったという条件を同時に満たした場合にステップS1101においてYesと判断し、ステップS1102に進むようにしてもよい。
【0091】
ステップS1102では、ジョイン部102が、入力レコードのアトリビュートに加えて、インデックス格納部113及びテーブル格納部114を参照することにより、アグリゲーション結果を格納する場所を決めるのに必要なアトリビュートを集める。
【0092】
また、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート、HAVINGに必要なアトリビュートを取得して、ジョイン結果格納部111に格納する。
【0093】
ステップS1103では、アグリゲーション結果格納先決定部131が、アグリゲーション結果を格納する場所を決定し、その場所を指す情報を、アグリゲーション結果格納先情報格納部112に保存する。そして、ステップS1100に戻る。ここで、その場所を示す情報とは、アグリゲーション結果格納先情報格納部112上のアドレスであって間接参照を必要としないアドレスである。上述したように本実施形態は任意の記憶装置により実現できるため、場所を示す情報は、その記憶装置に応じて変化する。
例えば、RAMのアドレスでもよいし、フラッシュメモリの物理アドレスでもよいし、ハードディスクドライブの物理アドレスでもよい。
【0094】
ステップS1100で、イベントトフェーズ検知部101が、レコードの挿入や更新のイベントを調べた結果、アグリゲーションを計算するのに必要なアトリビュートが揃った場合は(ステップS1201においてYes)、ステップS1202に進む。そうでない場合は(ステップS1201においてNo)、ステップS1100に戻る。
【0095】
ステップS1202では、セレクション部121が、ジョイン結果格納部111から、セレクションに必要なアトリビュートを取得して、セレクションを実行する。このときに、入力レコードのIDを使ってインデックスを辿って取得してもよい。
【0096】
セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合は(ステップS1203においてYes)、ステップS1204に進む。それ以外の場合、すなわち、セレクション結果が偽であり、且つ、セレクション項のリテラルが変更された他のクエリのために結果を格納しない場合は(ステップS1203においてNo)、アルゴリズムを終了する。
【0097】
ステップS1204では、アグリゲーション結果格納先情報参照部123が、アグリゲーション結果格納先情報格納部112から、アグリゲーション結果の格納場所の情報を得る。このときに、ステップS1202でセレクションに必要なアトリビュートを取得する際のインデックスを辿る操作を、アグリゲーション結果の格納場所の情報を探す際のインデックスを辿る操作と兼用させることができる。このため、グリゲーション結果の格納場所の情報を探すための追加のコストなく、アグリゲーション結果を格納する場所につけられたインデックスを辿る必要もなく、アグリゲーション結果の格納場所の情報を得ることができる。
【0098】
続いて、アグリゲーション計算部122が、ジョイン結果格納部111から、必要なアトリビュートを取得し、アグリゲーションを計算し、結果をアグリゲーション結果格納部124に格納する(ステップS1205)。必要なアトリビュートがジョインを必要とする際には、ジョイン処理を行ってもよい。
【0099】
次に、本実施形態の効果について説明する。
【0100】
本実施形態は、データベースの解析処理の処理時間を短縮することができる、という効果を奏する。
【0101】
その理由は、アグリゲーションを計算し、その結果を格納する場所を探す際に、アグリゲーション結果格納先情報格納部より、間接参照が不要な、格納する場所の情報を得ることができ、更に、これを追加でインデックスを辿らずに得ることができるからである。すなわち、ジョイン結果格納部のインデックスをセレクションの実行のため、あるいはGROUP BYのため、あるいはアグリゲーションの計算自身のため辿る必要があり、この辿る操作をアグリゲーション結果格納場所の情報を探す際のインデックスを辿る操作に兼用できるため、追加で他のインデックスを辿る必要はないためである。
【0102】
《実施の形態の具体例》
図1、図2及び図3を参照して、本実施形態にかかるデータベース処理装置100の具体例を説明する。
【0103】
今回の説明では具体例として、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを取り上げる。
【0104】
ordersテーブルに、ある1セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図3を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【0105】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図3を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID(図示を省略する)を持つ。
【0106】
customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図3を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【0107】
まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。
【0108】
解析として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【0109】
<実行するクエリ>
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
【0110】
更に、解析の準備処理で用意するテーブルでは、セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成するとする。
【0111】
まず、l_orderkeyが200、l_custkeyが100のlineitemのレコードを挿入する。このレコードを入力レコードと呼ぶ。
【0112】
イベントフェーズ検知部101が、入力レコードの挿入のイベントを調べる(ステップS1100)。そして、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュート、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート、HAVINGに必要なアトリビュートが揃ったことを検知する(ステップS1101においてYes)。
【0113】
ここで、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートは、セレクション項のc_mktsegmentと、GROUP BYのo_orderdateである。c_mktsegmentについては、ジョインで取得できるため、l_custkeyがあればよい。o_orderdateについても同様に、l_orderkeyがあればよい。そのため、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートは、l_orderkeyと、l_custkeyと分かる。 セレクションに必要なアトリビュートは、同様にl_orderkeyと、l_custkeyである。また、入力レコードにない、アグリゲーション計算に必要なアトリビュートはない。更に、HAVINGに必要なアトリビュートもない。
【0114】
また、イベントフェーズ検知部101は、入力レコードを、インデックス格納部113を利用してテーブル格納部114に格納する(ステップS1100)。
【0115】
次に、ジョイン部102が、入力レコードのアトリビュートに加えて、インデックス格納部113及びテーブル格納部114を参照することにより、アグリゲーション結果を格納する場所を決めるのに必要なアトリビュートを集める。
【0116】
必要なアトリビュートはc_mktsegmentとo_orderdateであり、それぞれcustomerテーブル、orderテーブルとのジョインによって得られる。更に、クエリに必要なアトリビュートをジョインによって取得する。この場合、必要なアトリビュートは、セレクション項のo_orderdateとc_mktsegment、GROUP BYのo_orderdateであるので、追加でジョインで取得する必要はない。更に、これらの値を、ジョイン結果格納部111に格納する(ステップS1102)。
【0117】
更に、アグリゲーション結果格納先決定部131が、これらの値を用いて、アグリゲーション結果を格納する場所を決定し、その場所を指す情報を、アグリゲーション結果格納先情報格納部112に格納する(ステップ1103)。今回の説明では、場所を表す情報は、メモリのアドレスとする。アグリゲーションの結果に対しては、セレクションのc_mktsegmentの項のリテラルが変化したクエリにおいても再利用できるように、c_mktsegmentで分けて格納し、c_mktsegmentで辿れるインデックスを作成する。また、GROUP BYの処理がアグリゲーション結果をo_orderdateごとに分けて格納することを要求しているため、o_orderdateで分けて値を格納し、o_orderdateで辿れるインデックスを作成する。
【0118】
次に、入力レコードについて、l_extendedpriceが$200に更新される。イベントフェーズ検知部101が、入力レコードの更新のイベントを調べる(ステップS1100)。そして、アグリゲーションを計算するのに必要なアトリビュートが揃ったことを検知する(ステップS1201においてYes)。ここで、アグリゲーションを計算するのに必要なアトリビュートは、アグリゲーションにあらわれているl_extendedpriceと、GROUP BYのo_orderdateである。最初のものは入力レコードから、残りはジョイン結果格納部111から得られるため、アグリゲーションに必要なアトリビュートが揃ったと判定される。
【0119】
次に、セレクション部121が、ジョイン結果格納部111から、セレクションに必要なアトリビュートを取得し、セレクションを実行する。
【0120】
この場合は、入力レコードのIDであるl_linenumを使ってインデックスを辿って、o_orderdateと、c_mktsegmentを取り出す。また、クエリのセレクションの結果は真となる(ステップS1202)。
【0121】
セレクション結果が真であったので、ステップS1204へ進む(ステップS1203においてYes)。
【0122】
次に、アグリゲーション結果格納先情報参照部123が、アグリゲーション結果格納先情報格納部112から、アグリゲーション結果の格納場所の情報を得る(ステップS1204)。この例では、ステップS1202において、セレクションに必要なアトリビュートを取得する際のインデックスを辿る操作を、アグリゲーション結果の格納場所の情報を探す際のインデックスを辿る操作と兼用させることができる。このため、追加のコストなく、アグリゲーション結果の格納場所につけられたインデックスを辿る必要もなく、アグリゲーション結果の格納場所の情報を得ることができる。
【0123】
次に、アグリゲーション計算部122が、ジョイン結果格納部111から、必要なアトリビュートを取得し、アグリゲーションを計算し、結果をアグリゲーション結果格納部124に格納する(ステップS1205)。今回の説明では、$200を加算する。
【0124】
《その他の実施の形態》
以上、上述した実施形態は、本発明の好適な実施形態ではあるが、本発明は以上の実施の形態にのみ限定されず、本発明の要旨を逸脱しない範囲においてその他各種の付加変更が可能である。例えば、上述した実施形態において、イベントフェーズを、アグリゲーション結果の格納場所を決定するのに必要なアトリビュートが揃ったフェーズ、セレクションとHAVINGに必要なアトリビュートが揃ったフェーズ、アグリゲーションを計算するのに必要なアトリビュートが揃ったフェーズ、に分ける構成にすることも可能である。
【0125】
なお、上記のデータベース処理装置は、ハードウェア、ソフトウェア又はこれらの組合わせにより実現することができる。また、上記のデータベース処理装置により行なわれるデータベース処理方法も、ハードウェア、ソフトウェア又はこれらに組合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
【0126】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば、光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(random access memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0127】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【0128】
(付記1) ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置。
【0129】
(付記2) 付記1に記載のデータベース処理装置であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョイン部と、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定部と、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクション部と、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算部と、
を備えることを特徴とするデータベース処理装置。
【0130】
(付記3) 付記2に記載のデータベース処理装置であって、
データの解析処理を実行するクエリに対して影響を与えるレコードの、挿入や更新のイベントを調べることによりイベントの内容の検知を行う検知部を更に備え、
前記ジョイン部は、アグリゲーション結果の格納場所の決定ができるイベントを前記検知部が検知した場合に動作し、
前記セレクション部は、アグリゲーションを計算できるイベントを前記検知部が検知した場合に動作することを特徴とするデータベース処理装置。
【0131】
(付記4) 付記3に記載のデータベース処理装置であって、
前記検知部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョインができるイベントであることを検知し、
前期ジョイン部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョイン処理を行うことを特徴とするデータベース処理装置。
【0132】
(付記5) 付記2乃至4の何れか1に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報参照部及び前記アグリゲーション計算部は、前記セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合に動作することを特徴とするデータベース処理装置。
【0133】
(付記6) 付記2乃至5の何れか1に記載のデータベース処理装置であって、
前記ジョイン部は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート及びHAVINGに必要なアトリビュート、が揃ったという条件を同時に満たした場合に動作することを特徴とするデータベース処理装置。
【0134】
(付記7) 付記1乃至6の何れか1に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報とは、アグリゲーション結果を格納する記憶装置上のアドレスであって間接参照を必要としないアドレスであることを特徴とするデータベース処理装置。
【0135】
(付記8) データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法。
【0136】
(付記9) 付記8に記載のデータベース処理方法であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョインステップと、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定ステップと、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクションステップと、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算ステップと、
を備えることを特徴とするデータベース処理方法。
【0137】
(付記10) データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラム。
【符号の説明】
【0138】
100 データベース処理装置
101 イベントフェーズ検知部
102 ジョイン部
131 アグリゲーション結果格納先決定部
111 ジョイン結果格納部
112 アグリゲーション結果格納先情報格納部
113 インデックス格納部
114 テーブル格納部
121 セレクション部
122 アグリゲーション計算部
123 アグリゲーション結果格納先情報参照部
124 アグリゲーション結果格納部
500 データベース処理装置
501 入力格納部
502 ジョイン部
503 ジョイン結果格納部
504 インデックス格納部
505 テーブル格納部
506 セレクション部
507 アグリゲーション計算部
508 インデックストラバーサル部
509 アグリゲーション結果格納部

【特許請求の範囲】
【請求項1】
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置。
【請求項2】
請求項1に記載のデータベース処理装置であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョイン部と、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定部と、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクション部と、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算部と、
を備えることを特徴とするデータベース処理装置。
【請求項3】
請求項2に記載のデータベース処理装置であって、
データの解析処理を実行するクエリに対して影響を与えるレコードの、挿入や更新のイベントを調べることによりイベントの内容の検知を行う検知部を更に備え、
前記ジョイン部は、アグリゲーション結果の格納場所の決定ができるイベントを前記検知部が検知した場合に動作し、
前記セレクション部は、アグリゲーションを計算できるイベントを前記検知部が検知した場合に動作することを特徴とするデータベース処理装置。
【請求項4】
請求項3に記載のデータベース処理装置であって、
前記検知部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョインができるイベントであることを検知し、
前期ジョイン部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョイン処理を行うことを特徴とするデータベース処理装置。
【請求項5】
請求項2乃至4の何れか1項に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報参照部及び前記アグリゲーション計算部は、前記セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合に動作することを特徴とするデータベース処理装置。
【請求項6】
請求項2乃至5の何れか1項に記載のデータベース処理装置であって、
前記ジョイン部は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート及びHAVINGに必要なアトリビュート、が揃ったという条件を同時に満たした場合に動作することを特徴とするデータベース処理装置。
【請求項7】
請求項1乃至6の何れか1項に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報とは、アグリゲーション結果を格納する記憶装置上のアドレスであって間接参照を必要としないアドレスであることを特徴とするデータベース処理装置。
【請求項8】
データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法。
【請求項9】
請求項8に記載のデータベース処理方法であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョインステップと、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定ステップと、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクションステップと、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算ステップと、
を備えることを特徴とするデータベース処理方法。
【請求項10】
データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2013−92873(P2013−92873A)
【公開日】平成25年5月16日(2013.5.16)
【国際特許分類】
【出願番号】特願2011−233942(P2011−233942)
【出願日】平成23年10月25日(2011.10.25)
【出願人】(000004237)日本電気株式会社 (19,353)