JP6779855B2 - 情報処理装置、組込機器、情報処理方法、およびプログラム - Google Patents

情報処理装置、組込機器、情報処理方法、およびプログラム Download PDF

Info

Publication number
JP6779855B2
JP6779855B2 JP2017232795A JP2017232795A JP6779855B2 JP 6779855 B2 JP6779855 B2 JP 6779855B2 JP 2017232795 A JP2017232795 A JP 2017232795A JP 2017232795 A JP2017232795 A JP 2017232795A JP 6779855 B2 JP6779855 B2 JP 6779855B2
Authority
JP
Japan
Prior art keywords
language
unit
query
node
execution plan
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017232795A
Other languages
English (en)
Other versions
JP2019101813A (ja
Inventor
翔平 望月
翔平 望月
誠 嶋村
誠 嶋村
基孝 金松
基孝 金松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2017232795A priority Critical patent/JP6779855B2/ja
Publication of JP2019101813A publication Critical patent/JP2019101813A/ja
Application granted granted Critical
Publication of JP6779855B2 publication Critical patent/JP6779855B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明の実施形態は、情報処理装置、組込機器、情報処理方法、およびプログラムに関する。
一般に、DBMS(Database Management System)では、クエリの実行リクエストが入力されたときにクエリに基づく実行計画を作成し、実行計画を作成した後、クエリに応じた処理を実行している。ここでいうクエリとは、DBMSに保存されているデータに対する操作を表す命令である。クエリは、例えば、SQL(Structured Query Language)で記述されたコマンドである。実行計画とは、クエリを元に、データソースから高速かつ効率的に、クエリにより指定された条件を満たすデータを取得するための計画を規定する情報である。クエリの数が増加すると、実行計画のサイズが多くなり、実行計画を格納するファイルサイズが肥大化する傾向がある。クエリがSQLである場合、例えば、処理条件を示すWHERE句の式の解釈に、比較的大きな負荷がかかる場合がある。これらに対応し、利用頻度の低い実行計画を圧縮したり、複数の実行計画に共通する処理単位を共通化してサイズ削減を図る場合がある。
DBMSのうち、組込機器向けに構築されるDBMSは、使用できるメモリ容量が限られており、受信するクエリのパターンが予め想定可能であるという環境で構築される。このため、組込機器内で実行計画を作成することはせず、組込機器に搭載するシステムの開発環境において、予めクエリに基づく実行計画を作成しておき、組込機器に搭載するシステムと一緒に組込機器のROM(Read Only Memory)等に保存する場合がある。
実行計画は、例えば木構造で保存される。木構造で保存される実行計画をツリープランと称する場合がある。DBMSでクエリが実行される際は、まずその実行計画が解釈された後に、データソースからデータを取得するための処理が行われる。
また、実行計画は、CPU(Central Processing Unit)によって迅速に実行可能な機械語に変換される場合もある。機械語は、実行計画を構成する抽象的な記述に比べて、CPUでの解釈に要する時間が短い。そのため、機械語に変換された実行計画は、機械語に変換しない実行計画に比して、解釈に要する時間が削減される。しかしながら、実行計画を機械語に変換した場合、実行計画に比べて大きなメモリ容量を要する。機械語は、抽象化された言語に比べて、記述するためのデータ量が多いためである。
このように、従来の組込機器向けDBMSでは、実施の態様に合った実行計画を柔軟に取得することができない場合があった。
米国特許第8949222号明細書
Dmitry Melnik著、"Speeding up query execution in PostgreSQL using LLVM JIT compiler"、[online]、[平成29年10月31日検索]、インターネット〈URL:https://llvm.org/devmtg/2016-09/slides/Melnik-PostgreSQLLLVM.pdf) Surajit Chaudhuri著、"An overview of query optimization in relational systems"、[online]、[平成29年12月1日検索]、インターネット〈URL:https://dl.acm.org/citation.cfm?id=275492) A. Rosenthal著、他1名、"Anatomy of a Modular Multiple Query Optimizer"、(米国) Proceedings of the 14th International Conference on Very Large Databases (VLDB), IEEE, Long Beach, CA、1988年8月、p230-239 Dmitry Melnik著、他3名、"JIT-Compiling SQL Queries in PostgreSQL Using LLVM(PGCon 2017)"、[online]、[平成29年10月31日検索]、インターネット〈URL:https://www.pgcon.org/2017/schedule/attachments/467_PGCon%202017-05-26%2015-00%20ISPRAS%20Dynamic%20Compilation%20of%20SQL%20Queries%20in%20PostgreSQL%20Using%20LLVM%20JIT.pdf)
本発明が解決しようとする課題は、組込機器におけるデータベース処理を好適に行わせることができる情報処理装置、組込機器、情報処理方法、およびプログラムを提供することである。
実施形態の情報処理装置は、第1生成部と、評価部とを持つ。前記第1生成部は、一群のクエリに基づいて、データソースの検索処理の規則を、第1言語によって規定する、実行計画を生成する。前記評価部は、前記実行計画の少なくとも一部を、前記第1言語よりも解釈負荷が小さい第2言語に変換した場合の性能向上度合を評価する評価値を導出する。
第1の実施形態に係る情報処理装置100の構成を示す図。 第1の実施形態に係る情報処理装置100に入力されるクエリを例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を、共通化部120にて共通化処理することについて説明するための図。 第1の実施形態に係る情報処理装置100の共通化部120での共通化処理を示すフローチャート。 第1の実施形態に係る情報処理装置100に入力されるクエリを例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を、共通化部120にて共通化処理する過程を例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を、共通化部120にて共通化処理する過程を例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を、共通化部120にて共通化処理する過程を例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を、共通化部120にて共通化処理する過程を例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリを例示した図。 第1の実施形態に係る情報処理装置100に入力されるクエリに基づく実行計画を示した図。 第1の実施形態に係る情報処理装置100の評価部130での評価値導出例を示す図。 第1の実施形態に係る情報処理装置100の第2生成部140での処理の流れの一例を示すフローチャート。 第1の実施形態に係る情報処理装置100の第2生成部140での処理の流れの一例を示す図。 第1の実施形態に係る情報処理装置100の評価部130での評価値導出の一例を示す図。 第1の実施形態に係る情報処理装置100の評価部130での評価値導出の具体例を示す図。 第1の実施形態に係る情報処理装置100の評価部130での評価値導出の一例を示す図。 第1の実施形態に係る情報処理装置100の評価部130での評価値導出の一例を示す図。 第1の実施形態に係る情報処理装置100の第2生成部140での処理の流れの一例を示すフローチャート。 第1の実施形態に係る情報処理装置100の第2生成部140での処理の流れの一例を示す図。 第2の実施形態に係る組込機器200の構成を示す図。
以下、実施形態の情報処理装置、およびプログラムを、図面を参照して説明する。
(第1の実施形態)
[構成]
以下、第1の実施形態について説明する。図1は、第1の実施形態の情報処理装置100の構成図である。図1に示すように、情報処理装置100は、入力装置1に対して入力された指示を取得して動作する。情報処理装置100は、例えば、第1生成部110と、共通化部120と、評価部130と、第2生成部140とを備える。これらの構成要素は、例えば、CPUなどのハードウェアプロセッサがプログラム(ソフトウェア)を実行することにより実現される。また、これらの構成要素のうち一部または全部は、LSI(Large Scale Integration)やASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)、GPU(Graphics Processing Unit)などのハードウェア(回路部;circuitryを含む)によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。情報処理装置100は、組込システムを搭載する組込機器200の開発環境を提供する装置(開発装置)である。なお、第1の実施形態において共通化部120は省略されてもよい。
第1生成部110には、入力装置1からクエリ群が入力される。このクエリ群は、組込機器200で実行されることが予め想定されているデータ処理を規定するものである。第1生成部110は、入力されたクエリ群の解釈に必要であるデータベースのメタ情報を呼び出し、実行計画を作成する。データベースのメタ情報とは、組込機器200に搭載されたデータベースの構造に関する情報である。データベースの構造に関する情報とは、例えば、テーブルを構成するカラムや、データ型や、最大データレコード数等である。実行計画とは、入力されたクエリ群を解釈した処理結果を、第1言語で記述(規定)したものである。実行計画とは、例えば、“SQLクエリのWHERE句で指定した条件を満たすデータを、テーブルT1の索引を用いて検索した後、テーブルT1とテーブルT2の選択処理を行う”といった処理の内容や順序を表現する。実行計画は、実際には言語で記述されるものであるが、以下の説明では抽象化された木構造で表されるものとして説明する。
共通化部120には、第1生成部110から、実行計画が入力される。共通化部120は、実行計画を分解し、実行計画を構成するノードを解釈する。ノードとは、実行計画の処理単位のうち、情報処理装置100が一つの処理単位として扱う命令または式である。具体的に、ノードとは、例えば、テーブル結合命令や、“テーブルT1のカラムAと、テーブルT2のカラムBが一致するとき“といった条件式である。共通化部120は、実行計画を構成するすべてのノードを解釈し、内容が一致するノードがある場合、必要に応じて共通化する処理を行う。なお、ノードの内容が一致するとは、検索対象が同じテーブルであること、他のノードと内容が一致するノードがあること、結合条件が共通すること等が含まれる。
評価部130には、共通化部120から実行計画が入力される。評価部130は、入力装置1から取得した所定の条件に基づき、実行計画に含まれる各ノードを第2言語に変換した場合の性能向上度合を評価した、評価値を導出する。第2言語とは、第1言語に比べて、CPUが解釈する際の処理負荷が小さい記述である。第2言語は、例えば、機械語やバイトコードである。
第2生成部140には、共通化部120から実行計画が入力され、更に、評価部130から、評価値が入力される。第2生成部140は、入力装置1から取得した制約条件を満たす範囲で、評価値の高いノードを選択し、選択したノード(実行計画の一部)を第2言語に変換することで、ハイブリッドプランを生成する。なお、第2生成部140は自動化された処理によって第2言語に変換してもよいし、情報処理装置100を用いる開発者が、評価部130により導出された評価値を参照しながら実行計画の一部を第2言語に変換する操作を受け付けながら変換を行ってもよい。
[共通化]
以下、第1の実施形態の情報処理装置100の共通化部120によって行われる共通化処理について説明する。
図2は、情報処理装置100に入力されるクエリ群の一例を示す図である。図2に示すクエリ1は、テーブルT1およびテーブルT2から、テーブルT1とテーブルT2に共通するカラムAの示す値が一致するレコードのうち、テーブルT1におけるカラムCが0より大きい値であるレコードと、テーブルT2におけるカラムBの値が0であるレコードとを抽出し、値が一致するカラムAを共通化して、少なくともカラムA、カラムBおよびカラムCを含むレコードを構成して出力することを命令している。図2に示すクエリ2は、テーブルT2から、テーブルT2のカラムBの値が0であるレコードを構成して、少なくともカラムAを含むレコードを出力することを命令している。
図3(A)は、図2で示すクエリ1およびクエリ2の内容に基づく実行計画を示す図であり、図3(B)は、クエリ1およびクエリ2の内容に基づく実行計画の一部のノードが、共通化部120によって共通化された結果を表した図である。図3(A)に示すクエリ1は、ノードN11〜N15を含む。図3(A)に示すクエリ2は、ノードN21およびノードN22を含む。共通化部120は、ノードN11〜N15、およびノードN21〜N22から、2つの任意のノードを選択し、選択した2つのノードの内容が一致し、かつ、その子ノードがすべて共通する場合に、2つのノードを共通化する。子ノードとは、着目するノードに対応付き、着目するノードから木構造の基点とは逆の方向に一ステップ分離れたノードをいう。以下、着目するノードから木構造の基点の方向を「上位」、着目するノードから木構造の基点とは逆の方向を「下位」と称する。例えば、実行計画において、下位のノードほど、実際の処理としては先に行われるものである。なお、子ノードよりも下位のノードに関して、この実施形態では最下位から順に共通化するため、子ノードが共通する場合、それよりも下位のノードも共通化されていると考えられる。図3(A)では、ノードN14およびノードN15と、ノードN21およびノードN22は、共通化部120によって、共通化の対象であると判断される。そのため図3(B)では、これらはノードN14およびノードN15に統合されている。
図4は、第1の実施形態の情報処理装置100の共通化部120により実行される共通化処理の流れの一例を示すフローチャートである。
共通化部120は、実行計画全体に含まれる最下位の階層のノードから順に以下の処理を行う。まず、共通化部120は、着目する階層のノードについて、ノードの内容が一致し、かつすべての子ノードが共通する(既に共通化されている)ノードの組p1およびp2が存在するか否かを判定する。(ステップS100)。ノードの組p1およびp2が存在すると判定した場合、共通化部120は、p1とp2の共通化を行う。(ステップS110)。次に、共通化部120は、次の判定対象を1階層上のノードに移す(ステップS120)。次に、共通化部120は、次の判定対象がノードを構成する最上位の階層である第1階層であるか否かを判定する(ステップS130)。次の判定対象が第1階層でない場合、S100に処理を戻す。次の判定対象が第1階層である場合、本フローチャートの処理が終了する。
以下、第1の実施形態の情報処理装置100の共通化部120によって、図5に示すSQL文を含むクエリ1、クエリ2およびクエリ3に対して共通化処理が行われる例を示す。図5は、情報処理装置100に入力されるクエリ群の一例を示す図である。図5に示すクエリ1は、テーブルT1から、テーブルT1のカラムAの値が0であるレコードのうち、テーブルT1におけるカラムBが0より大きい値であるレコードを抽出し、少なくともカラムAおよびカラムBを含むレコードを構成して出力することを命令している。図5に示すクエリ2は、テーブルT1およびテーブルT2から、テーブルT1とテーブルT2に共通するカラムAの示す値が一致するレコードのうち、テーブルT2におけるカラムBが0より大きい値であるレコードとを抽出し、中身が一致するカラムAを共通化して、少なくともカラムAおよびカラムBを含むレコードを構成して出力することを命令している。図5に示すクエリ3は、テーブルT3とクエリ2の副問い合わせを行った結果から、テーブルT2とテーブルT3に共通するカラムAの示す値が一致するレコードを抽出し、少なくともカラムAを含むレコードを構成して出力することを命令している。
図図6〜9は、図5で示すクエリ1、クエリ2およびクエリ3に基づく実行計画のノードが、共通化部120によって、共通化される過程の一例を、段階を追って示す図である。図6は、クエリ1、クエリ2およびクエリ3に基づく実行計画を示す図である。図6に示すクエリ1は、ノードN11〜N14を含む。図6に示すクエリ2は、ノードN21〜N24を含む。図6に示すクエリ3は、ノードN31〜N36を含む。
図7は、共通化部120によって、図6の状態から、共通化処理が1段階行われた様子を示す図である。図7の状態では、図6のノードN14、ノードN23およびノードN34は、共通化部120によって、ノードN14に統合されている。また、図7の状態では、図6のノードN24およびノードN35は、共通化部120によって、ノードの内容が一致していると判定され、ノードN24に統合されている。これに伴って、ノードN14に統合された各ノード(ノードN14を含む)の上位ノードであったノードN13、ノードN22、およびノードN33がノードN14に対応付けられ、ノードN24に統合された各ノード(ノードN24を含む)の上位ノードであったノードN21およびノードN32がノードN24に対応付けられる。
図8は、共通化部120によって、図7の状態から、共通化処理が更に1段階行われた様子を示す図である。図8の状態では、図7のノードN13、ノードN22およびノードN33は、共通化部120によって、ノードN13に統合されている。これに伴って、ノードN13に統合された各ノード(ノード13を含む)の上位ノードであったノードN21およびノードN3図93がノードN13に対応付けられる。
図9は、共通化部120によって、図8の状態から、共通化処理が更に1段階行われた様子を示す図である。図9の状態では、図8のノードN21およびノードN32は、共通化部120によって、ノードN21に統合されている。これに伴って、ノードN32に統合された各ノード(ノード13を含む)の上位ノードであったノードN31がノードN21に対応付けられる。以上、図5に示すSQL文を含むクエリ1、クエリ2およびクエリ3に対して共通化処理が行われる過程の例の説明を終了する。
[評価手法とハイブリットプラン作成手法]
以下、評価部130による評価手法および第2生成部140によるハイブリッドプラン生成手法について第1例、第2例、および第3例を挙げて説明する。第1例は、所定の条件として重み付け係数が設定され、評価部130により評価値を導出し、第2生成部140により評価値を基にハイブリッドプランを作成する例である。第2例は、所定の条件として重み付け係数と評価回数が設定され、評価部130により評価値を導出し、第2生成部140により、制約条件としてハイブリッドプランの最大許容サイズが設定され、評価値と最大許容サイズを基にハイブリッドプランを作成する例である。第3例は、所定の条件としてそれぞれのクエリの最大実行時間が設定される例である。
[評価手法およびハイブリッドプラン生成手法の第1例]
評価部130は、あるノードの評価値を、そのノードを通過する実行計画のパスの基点となったクエリに付与された重み付け係数の和として求める。後述するように重み付け係数が一定であるとすると、あるノードの評価値は、そのノードを通過する実行計画のパスに基づく値となる。以下の説明では、情報処理装置100の利用者によって、クエリ毎に任意の重み付け係数が予め設定されているものとする。
図10は、入力されるクエリ群の他の一例を示す図である。図10に示すクエリ1は、テーブルT1から、テーブルT1におけるカラムAの値が0であるレコードを抽出し、更にテーブルT1のカラムBが0より大きい値であるレコードを抽出して、少なくともカラムAおよびカラムBを含むレコードを構成して出力することを命令している。図10に示すクエリ2は、テーブルT1から、テーブルT1におけるカラムBの値が0より大きい値であるレコードを抽出し、更にテーブルT1のカラムCの値が0であるレコードを抽出して、少なくともカラムBおよびカラムCを含むレコードを構成して出力することを命令している。
図11は、図10に示すクエリ1およびクエリ2に基づく実行計画を示す図である。なお実行計画のうちクエリ1に起因する部分と、クエリ2に起因する部分とは、共通化部120により一部のノードが共通化されている。ノードN13およびノードN14が共通化された部分に相当する。図12は、図10で示すクエリ1およびクエリ2に付与された重み付け係数と、ノード毎に導出される評価値と、を例示した図である。図12の上図に示す通り、クエリ1およびクエリ2にはそれぞれ所定の条件として、重み付け係数W1、W2が設定されている。ここで、重み付け係数W1=W2=1であっても構わない。この場合、重み付け係数を設定する手順自体が省略されてもよい。
図12の下図に示すように、評価部130は、ノードN11の評価値として、クエリ1に対して設定された重み付け係数のW1を導出する。また評価部130は、ノードN12の評価値として、クエリ1に対して設定された重み付け係数のW1を導出する。また評価部130は、ノードN21の評価値として、クエリ2に対して設定された重み付け係数であるW2を導出する。また評価部130は、ノードN22の評価値として、クエリ2に対して設定された重み付け係数であるW2を導出する。また評価部130は、ノードN13の評価値として、クエリ1およびクエリ2に対して設定された重み付け係数の和であるW1+W2を導出する。また評価部130は、ノードN14の評価値として、クエリ1およびクエリ2に対して設定された重み付け係数の和であるW1+W2を導出する。
この場合、第2生成部140は、評価部130の導出した評価値を基に、以下のような処理を行う。なお、第2生成部140は、ノードを第2言語に変換する規則である制約条件として、ハイブリッドプラン全体の最大許容サイズを基に判定を行うものとする。
まず、第2生成部140は、入力された実行計画の全体サイズを求める。第2生成部140は、実行計画の合計サイズを想定メモリとして一時的に記憶する。第2生成部140は、評価値の高いノードから、優先的に、第2言語に変換する対象として認識する。第2生成部140は、対象のノードを第2言語に変換した場合に増加するサイズを想定メモリに追加する。第2生成部140は、想定メモリが最大許容サイズを超過する直前まで、次に評価値の高いノードを第2言語に変換する対象として認識し、想定メモリを算出する上記の処理を繰り返す。
図13は、評価部130によって第1例の手法でノードの評価値の導出が行われ、所定の条件がハイブリッドプラン全体の最大許容サイズである場合に、評価部130および第2生成部140により行われる処理の流れを表すフローチャートである。
まず、評価部130は、ノードの評価値を導出する(ステップS200)。次に、第2生成部140は、実行計画全体の想定メモリを導出する(ステップS210)。次に、第2生成部140は、導出した想定メモリが、情報処理装置100の利用者が設定した最大許容サイズ以内か否かを判定する(ステップS220)。第2生成部140は、想定メモリが最大許容サイズ以内であると判定した場合、第2言語への変換が行われていないノードのうち、最も評価値の高いノードを第2言語への変換し、第2言語に変換した結果、増加するサイズを想定メモリに加算する(ステップS230)。第2生成部140は、想定メモリが最大許容サイズを超過するまで、S220からS230の処理を繰り返し実行する。想定メモリが最大許容サイズを超過すると判定した場合、第2生成部140は、一連の処理を終了する(ステップS240)。これにより本フローチャートの処理は終了する。
以下、このハイブリッドプランの生成例について具体例を用いて説明する。第2生成部140のハイブリッドプランの選択方法について、図14を用いて説明する。図14は、図2で示すクエリ1およびクエリ2に、制約条件として最大許容サイズと、ノードのサイズを例示した図である。図14の上図に示す通り、情報処理装置100の利用者があらかじめ設定したハイブリッドプランの最大許容サイズは200バイトであるとする。また、ノードの評価値は予め導出されており、ノードN11の評価値=100、ノードN12の評価値=50、ノードN13の評価値=50、ノードN14の評価値=10、ノードN15の評価値=10であるとする。また、ノードが第1言語で記述される場合のサイズは、ノードN11が8バイト、ノードN12が4バイト、ノードN13が4バイト、ノードN14が4バイト、ノードN15が5バイトであるとする。また、ノードが第2言語で記述される場合に増加するサイズは、ノードN11が50バイト、ノードN12が60バイト、ノードN13が60バイト、ノードN14が60バイト、ノードN15が60バイトであるとする。第2生成部140は、図14の下図に示す通り、まず、すべてのノードが第1言語である場合の想定メモリの演算を行う。第2生成部140は、想定メモリが25バイトであり、予め設定された最大許容サイズの200バイトより小さいため、次に、最も評価値の高いノードN11を第2言語に変換する場合の想定メモリの演算を行う。第2生成部140は、想定メモリが195バイトであり、予め設定された最大許容サイズの200バイトより小さいため、ノードN11を第2言語に変換する。第2生成部140は、更に、次に最も評価値の高いノードN14とノードN15を第2言語に変換する場合の想定メモリの演算を行う。第2生成部140は、想定メモリが315バイトであり、予め設定された最大許容サイズの200バイトを超過するため、ノードN14とノードN15を第2言語に変換しないと判定し、一連の処理を終了する。
このように、評価部130は、あるノードの評価値を、そのノードを通過する実行計画のパスの基点となったクエリに付与された重み付け係数の和として求める。評価部130は、重み付け係数が一定である場合、あるノードの評価値を、そのノードを通過する実行計画のパスの数に基づく値として求める。また、第2生成部140は、所定条件として設定されたハイブリッドプラン全体の最大許容サイズと、評価値とに基づいて、一部または全部のノードを第2言語に変換する。
[評価手法およびハイブリッドプラン生成手法の第2例]
第2例において、評価部130は、あるノードの評価値を、そのノードを通過する実行計画のパスの基点となったクエリに付与された重み付け係数の和と、実行計画内の評価回数との積として求める。ここでいう評価回数とは、実行計画のノードの判定が実行される回数のことをいう。評価回数は、事前に測定されてもよい。また、評価回数は、所定の演算方法を設けて推定してもよい。また、評価回数は、実行計画の最下位のノードで呼び出すテーブルレコードが全件呼び出された場合の数と同値とみなし、最下位のノードで呼び出すテーブルに格納できる最大レコード数としてもよい。以下の説明では、情報処理装置100の利用者によって、クエリ毎に任意の重み付け係数が予め設定されているものとする。
図15は、図2で示すクエリ1およびクエリ2に付与された重み付け係数と、図2で示すクエリ1およびクエリ2によって参照されるテーブルT1およびテーブルT2の最大レコード数と、ノード毎の導出される評価値を例示した図である。図15の上図に示す通り、図2に示すクエリ1およびクエリ2にはそれぞれ所定の条件として、重み付け係数W1、W2が設定されている。ここで、重み付け係数W1=W2=1であっても構わない。また、図15の上図に示す通り、図2で示すクエリ1およびクエリ2によって参照されるテーブルT1およびテーブルT2の最大レコード数R(T1)およびR(T2)は、予め測定されている。ここで、最大レコード数R(T1)=R(T2)であっても構わない。
図15の下図に示すように、評価部130は、ノードN11の評価値として、クエリ1に対して設定された重み付け係数のW1と、テーブルT1の最大レコード数R(T1)と、テーブルT2の最大レコード数R(T2)との積を導出する。また評価部130は、ノードN12の評価値として、クエリ1に対して設定された重み付け係数のW1と、テーブルT2の最大レコード数R(T2)と、係数Fとの積を導出する。係数Fは、テーブルT1に対してノードN14を実行した場合に、どの程度のレコードが抽出されるかの推定値が得られるような定数としてよい。また、評価部130は、ノードN14の評価値として、クエリ1とクエリ2に対して設定された重み付け係数の和であるW1+W2と、テーブルT1の最大レコード数R(T1)と、係数Fとの積を導出する。
図16に示すように、評価部130の評価処理内容を、更に具体的に説明する。図16は、図15の重み付け係数、評価回数に具体的な値を設定し、評価値を算出した例である。図16に示すように、クエリ1の重み付け係数W1=10、クエリ2の重み付け係数W2=1、テーブルT1の最大レコード数R(T1)=100、テーブルT2のR(T2)=200、係数F=1とした場合の、ノードN11〜N14の評価値を算出する。評価部130は、ノードN11の評価値を200,000、ノードN12の評価値を2,000、ノードN14の評価値を1,100と算出する。第2生成部140、または情報処理装置100を用いる開発者は、ノードN11、ノードN12、ノードN14の順に、第1言語から第2言語に変換する。このように、評価部130は、あるノードの評価値を、そのノードを通過する実行計画のパスの基点となったクエリに付与された重み付け係数の和と、評価回数との積として求める。また、第2生成部140は、評価値を基に、ノードを第2言語に変換する。
[評価手法およびハイブリッドプラン生成手法の第3例]
第3例において、評価部130は、あるノードを、それぞれのクエリの実行時間を基に評価する。この場合、評価部130は、評価値の代替として、クエリの実行時間を用いて評価を行う。以下の説明では、情報処理装置100の利用者によって、クエリ毎に最大実行時間が任意に設定されているものとする。
図17は、評価部130で、クエリの実行時間の推定を行う処理の一例を示す図である。図17は、上述の図2に示すクエリ1およびクエリ2に基づく実行計画のノードを示す図3(B)を用いて説明する。図17は、図2に示すクエリ1およびクエリ2に、所定の条件に含まれる最大実行時間を例示した図である。図17の上図に示す通り、図2に示すクエリ1およびクエリ2にはそれぞれ所定の条件として、最大実行時間tmax(1)およびtmax(2)が設定されている。ここで、tmax(1)=tmax(2)であっても構わない。また、図17の上図に示す通り、図2で示すクエリ1およびクエリ2によって参照されるテーブルT1およびテーブルT2の最大レコード数R(T1)およびR(T2)は、予め測定されている。ここで、最大レコード数R(T1)=R(T2)であっても構わない。
図17の下図に示すように、評価部130は、ノードN11の評価回数として、テーブルT1の最大レコード数R(T1)と、テーブルT2の最大レコード数R(T2)との積を導出する。また評価部130は、ノードN12の評価回数として、テーブルT2の最大レコード数R(T2)を導出する。また評価部130は、ノードN14の評価回数として、テーブルT1の最大レコード数R(T1)を導出する。
ここで、単一のノードが評価されるのに要する時間を単位実行時間tとする。ここでいうノードの評価とは、後述する組込機器200の選択部240が、ノードを解釈し、データソースがノードを満たすか否かを検証することを指す。図17の上図に示す通り、クエリ1の実行時間は、ノードN11、ノードN12およびノードN14の評価に要する時間の和である、{R(T1)×R(T2)}+R(T1)+R(T2)と、単位実行時間tとの積である。また図17の上図に示す通り、クエリ2の実行時間は、ノードN12の評価に要する時間である、R(T1)と単位実行時間tとの積である。
評価部130は、あるクエリの実行時間が、情報処理装置100の利用者により設定されたクエリの最大実行時間tmaxを上回る場合、評価回数が多いノードから優先的に第2言語に変換対象に指定する。第2生成部は、評価部130から変換対象に指定されたノードを第2言語に変換する。ここで、クエリを第2言語に変換した場合のクエリ高速化率をsとすると、第2言語に変換されたノードの1回あたりの実行時間は、元の実行時間を高速化率sで除した値となる。例えば、評価部130は、評価回数の最も多いノードN11を第2言語への変換対象と指定する。ノードN11の実行時間は、第2言語に変更された結果、{R(T1)+R(T2)}/sとなる。評価部130は、実行時間がクエリ1の最大実行時間tmax(1)を下回るまで、第2言語への変換対象とするノードの判定を繰り返す。
図18に示す通り、評価部130の評価処理内容を、更に具体的に説明する。図18は、図17の最大実行時間および最大レコード数に具体的な値を設定し、さらに単位実行時間tおよびクエリ高速化率sに具体的な値を設定して評価した例である。評価部130は、図18に示す通り、クエリ1の最大実行時間tmax(1)=50、クエリ2の最大実行時間tmax(2)=10、テーブルT1の最大レコード数R(T1)=100、テーブルT2のR(T2)=200、単位実行時間t=0.01、高速化率s=10とし、クエリ1およびクエリ2の実行時間を導出する。評価部130は、ノードN11の評価回数を20,000、ノードN12の評価回数を200、ノードN14の評価回数を100と導出する。また評価部130は、クエリ1の実行時間を203、クエリ2の実行時間は1と導出する。評価部130は、クエリ1の実行時間が、クエリ1の最大実行時間tmax(1)を超過しているため、クエリ1の、最も評価回数の多いノードN11を第2言語への変換対象と指定する。第2生成部140は、ノードN11を、第1言語から第2言語に変換する。クエリ1の実行時間は、第2言語に変更された結果、23となる。評価部130は、クエリ1の実行時間がクエリ1の最大実行時間tmax(1)を下回ったため、第2言語への変換対象とするノードの判定を終了する。
図19は、第1の実施形態の情報処理装置100の評価部130および第2生成部140により、所定の条件として実行時間で評価したクエリを第2言語に変換する処理の流れの一例を示すフローチャートである。
まず、評価部130は、実行計画のすべてのノードの評価回数を導出する(ステップS300)。次に、評価部130は、ノードの評価回数を用いてクエリの実行時間を導出する。(ステップS310)。次に、評価部130は、クエリの実行時間が、予め設定された最大実行時間を超過するか否かを判定する(ステップS320)。最大実行時間を超過すると判定した場合、第2生成部140は、クエリを構成するノードから最も評価回数の多いノードを、第2言語に変換する(ステップS330)。次に、評価部130は、S330で第2言語に変換されたノードの評価回数を高速化率sで除した値を用いて、実行時間を再計算する(ステップS340)。評価部130は、再計算した実行時間が最大実行時間を超過しなくなるまで、S320からS330の処理を繰り返し実行する。最大実行時間を超過しないと判定した場合、評価部130は、一連の処理を終了する。これにより本フローチャートの処理は終了する。
このように、評価部130は、それぞれのクエリの実行時間を基にノードを評価する。また、第2生成部140は、それぞれのクエリの実行時間を基に、ノードを第2言語に変換する。
[ハイブリッドプランの生成結果例]
図20は、第2生成部140が、評価値の導出の後に、実行計画をハイブリッドプランに変換した結果の一例を示す図である。第2生成部140は、図20の左図で示すように、ノードN14を第2言語に変換したものとする。ノードN14に対応する第2言語は、実行計画を格納するファイルとは別のファイルに保存される。別途保存するファイルを辞書ファイルと称する。ノードN14に対応する第2言語は、キー値K1と対応付けて辞書ファイルに保存される。ノードN14が実行される場合には、キー値K1を用いて、専用の関数で辞書ファイルから第2言語の呼び出しが行われる。
また、第2生成部140は、変換対象であるノードに関数を呼び出す記述がある場合、関数を呼び出す部分をインライン展開してもよい。インライン展開とは、呼び出し元のノードの関数を呼び出す部分に、関数と等価なソースコードを展開して置換するものである。第2生成部140は、インライン展開によって、関数を呼び出す際のオーバーヘッド・タイムを節約することができ、インライン展開しない場合よりも高速処理が可能な実行計画を生成できる。
このような構成によって、情報処理装置100は、評価値に応じて、実行計画を少なくとも部分的に第1言語から第2言語に変換した、ハイブリッドプランの生成ができる。
[まとめ]
以上説明した第1の実施形態の情報処理装置100によれば、一群のクエリに基づいて、処理の規則を第1言語によって規定する実行計画を生成する第1生成部110と、実行計画の少なくとも一部を、第1言語よりも解釈負荷が小さい第2言語に変換した場合の性能向上度合を評価する、評価値を導出する評価部130と、を備えることにより、組込機器200におけるデータベース処理を好適に行わせることができる。
また、第1の実施形態の情報処理装置100によれば、第2生成部140を更に備えることにより、評価値の高い実行計画の処理単位が優先的に第2言語に変換され、組込機器200におけるデータベース処理を好適に行わせる実行計画である、第1言語と第2言語の組合せであるハイブリッドプランが生成できる。
(第2の実施形態)
以下、第2の実施形態について説明する。第2の実施形態は、組込システムを搭載する組込機器200に、第1の実施形態における情報処理装置100の生成物(ハイブリッドプラン)を搭載したものである。図21は、第2の実施形態の組込機器200の構成図である。図21に示すように、組込機器200は、例えば、組込アプリケーション210と、選択部240と、ハイブリッドプラン解釈実行部250と、実行計画解釈実行部260と、組込データベース270と、記憶部280とを持つ。
組込機器200は、他の情報処理装置とは接続されていない、組込システムを搭載した機器である。組込機器200には予め、開発環境である情報処理装置100から、実行計画を構成するファイルと、ハイブリッドプランを構成するファイルが複写されている。
組込機器200の組込アプリケーション210は、例えば、クエリ送信部220と、クエリ受信部230とを備える。クエリ送信部220には、組込アプリケーション210から、組込機器200の利用者の操作に基づいた既知のクエリの実行が依頼される。選択部240には、クエリ送信部220から、既知のクエリの実行の依頼が入力される。
また、選択部240は、既知のクエリを識別し、実行計画の呼び出しがあるか、ハイブリッドプランの呼び出しがあるかを判定する。ハイブリッドプラン解釈実行部250には、選択部240から、既知のクエリに対応するハイブリッドプランの呼び出しの指示が入力される。また、実行計画解釈実行部260には、既知のクエリに対応する実行計画の呼び出しの指示が入力される。
ハイブリッドプラン解釈実行部250は、記憶部280から、ハイブリッドプランを呼び出し、辞書ファイルを呼び出す関数を含むか否かを判定する。ハイブリッドプラン解釈実行部250は、解釈対象のノードが辞書ファイルを呼び出す関数を含む場合、対応する第2言語を辞書ファイルから呼び出し、対応する第2言語をノードの解釈に利用する。ハイブリッドプラン解釈実行部250には、解釈したハイブリッドプランを基に、組込データベース270から条件を満たす処理結果が入力される。
また、実行計画解釈実行部260には、記憶部280から、第2言語を含まない実行計画を呼び出し、解釈する。実行計画解釈実行部260は、解釈した実行計画を基に、組込データベース270から条件を満たす処理結果が入力される。実行計画解釈実行部260については、当業者によく知られたものであるので詳細な説明は省略する。
このような構成によって、組込機器200は、ハイブリッドプラン解釈実行部250によりハイブリッドプランを読み取り実行できるため、組込機器における実行計画のファイルサイズ上限の制約がある中で実現可能な範囲で、高速なクエリ実行ができる。
以上説明した第2の実施形態の組込機器200によれば、ハイブリッドプラン解釈実行部250にて、実行計画の一部が第2言語に変換されたハイブリッドプランを解釈し、選択部240にて、ハイブリッドプランに基づいてデータソースから検索することで、クエリ実行処理時間を好適に高速化できる。
以上説明した少なくとも一つの実施形態によれば、一群のクエリに基づいて、処理の規則を第1言語によって規定する実行計画を生成する第1生成部110と、実行計画の少なくとも一部を、第1言語よりも解釈負荷が小さい第2言語に変換した場合の性能向上度合を示す評価値を導出する評価部130と、を備えることにより、組込機器200におけるデータベース処理を好適に行わせることができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
1…入力装置、100…情報処理装置(開発装置)、110…第1生成部、120…共通化部、130…評価部、140…第2生成部、200…組込機器、210…組込アプリケーション、220…クエリ送信部、230…クエリ受信部、240…選択部、250…ハイブリッドプラン解釈実行部、260…実行計画解釈実行部、270…組込データベース、280…記憶部

Claims (13)

  1. 一群のクエリに基づいて、処理の規則を第1言語によって規定する実行計画を生成する第1生成部と、
    前記実行計画の少なくとも一部を、前記第1言語よりも解釈負荷が小さい第2言語に変換した際の性能向上度合を示す評価値を導出する評価部と、
    を備える情報処理装置。
  2. 前記実行計画に含まれる前記評価値の高い処理単位を優先的に前記第2言語に変換することで、前記第1言語と前記第2言語の組合せであるハイブリッドプランを生成する第2生成部を更に備える
    請求項1記載の情報処理装置。
  3. 前記ハイブリッドプランは、
    前記第2言語で記述された辞書ファイルと、
    前記第1言語で記述され、前記辞書ファイルの呼び出し情報を含む前記実行計画と
    を含む、
    請求項2記載の情報処理装置。
  4. 前記第2生成部は、前記第2言語に変換する際に、前記実行計画に含まれる少なくとも一つの処理単位が関数の呼び出しを行う場合に、前記関数と等価なソースコードで呼び出し元の処理単位を置換する
    請求項2または3記載の情報処理装置。
  5. 前記第2言語は、記述するのに前記第1言語よりも多くのメモリ領域を消費する言語であり、
    前記第2生成部は、使用可能なメモリ領域の上限を超えないように、前記実行計画に含まれる処理単位を前記第2言語に変換する、
    請求項2から4のうちいずれか1項記載の情報処理装置。
  6. 前記実行計画は、木構造で生成され、
    前記評価部は、前記一群のクエリに含まれるクエリに対して設定された重み付け係数と、前記第2言語に変換される前記実行計画の一部を通過するパス数とに基づいて、前記評価値を導出する、
    請求項1から5のうちいずれか1項に記載の情報処理装置。
  7. 前記評価部は、
    前記実行計画内の処理単位が判定に利用される回数である評価回数と、前記クエリに対して設定された重み付け係数との積に基づいて、前記評価値を導出する
    請求項1から5のうちいずれか1項記載の情報処理装置。
  8. 前記評価部は、前記一群のクエリを構成する個々のクエリの処理時間を前記評価値として導出する、
    請求項1から5のうちいずれか1項記載の情報処理装置。
  9. 前記実行計画に含まれる前記評価値の高い処理単位を優先的に前記第2言語に変換することで、前記第1言語と前記第2言語の組合せであるハイブリッドプランを生成する第2生成部を更に備え、
    前記第2生成部は、前記個々のクエリに対して予め設定された最大実行時間よりも、前記評価値として導出される処理時間が短くなるように前記第2言語に変換する
    請求項8記載の情報処理装置。
  10. 前記実行計画は、木構造で生成され、
    前記実行計画における異なるパスにおける内容が一致する処理単位を抽出し、前記内容が一致する処理単位を統合する共通化部を更に備え、
    前記評価部は、前記共通化部により前記内容が一致する処理単位が統合された前記実行計画に対して、前記評価値を導出する、
    請求項1から9のうちいずれか1項に記載の情報処理装置。
  11. 入力されたクエリに基づいて、記憶部に記憶され、第1言語によって規定された実行計画と前記第1言語よりも解釈負荷が小さい第2言語で記述された処理単位とを含む一以上のハイブリッドプランの中から、一以上のハイブリッドプランを選択する選択部と、
    前記選択部により選択されたハイブリッドプランを解釈してデータベースを検索する解釈実行部と、
    を備える組込機器。
  12. コンピュータが、
    一群のクエリに基づいて、処理の規則を第1言語によって規定する実行計画を生成し、
    前記実行計画の少なくとも一部を、前記第1言語よりも解釈負荷が小さい第2言語に変換した際の性能向上度合を示す評価値を導出する、
    情報処理方法。
  13. コンピュータに、
    一群のクエリに基づいて、処理の規則を第1言語によって規定する実行計画を生成させ、
    前記実行計画の少なくとも一部を、前記第1言語よりも解釈負荷が小さい第2言語に変換した際の性能向上度合を示す評価値を導出させる、
    プログラム。
JP2017232795A 2017-12-04 2017-12-04 情報処理装置、組込機器、情報処理方法、およびプログラム Active JP6779855B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017232795A JP6779855B2 (ja) 2017-12-04 2017-12-04 情報処理装置、組込機器、情報処理方法、およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017232795A JP6779855B2 (ja) 2017-12-04 2017-12-04 情報処理装置、組込機器、情報処理方法、およびプログラム

Publications (2)

Publication Number Publication Date
JP2019101813A JP2019101813A (ja) 2019-06-24
JP6779855B2 true JP6779855B2 (ja) 2020-11-04

Family

ID=66973815

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017232795A Active JP6779855B2 (ja) 2017-12-04 2017-12-04 情報処理装置、組込機器、情報処理方法、およびプログラム

Country Status (1)

Country Link
JP (1) JP6779855B2 (ja)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000330792A (ja) * 1999-05-18 2000-11-30 Matsushita Electric Ind Co Ltd バイトコードプログラム実行制御システム
JP4109305B1 (ja) * 2006-12-28 2008-07-02 透 降矢 マルチオペレーション・プロセッシングを用いたデータベースのクエリー処理システム

Also Published As

Publication number Publication date
JP2019101813A (ja) 2019-06-24

Similar Documents

Publication Publication Date Title
Fan et al. Answering graph pattern queries using views
Weir et al. Dbpal: A fully pluggable nl2sql training pipeline
Mishra et al. Generating targeted queries for database testing
US11288266B2 (en) Candidate projection enumeration based query response generation
JP6260294B2 (ja) 情報検索装置、情報検索方法および情報検索プログラム
KR102411778B1 (ko) 다중 지식의 비교 우위를 추론하는 서버, 방법 및 컴퓨터 프로그램
Paganelli et al. Tuner: Fine tuning of rule-based entity matchers
US20130060753A1 (en) Optimization Method And Apparatus
Akin et al. Searching for efficient neural architectures for on-device ML on edge TPUs
EP1341101A2 (en) System and method for document retrieval
JP6779855B2 (ja) 情報処理装置、組込機器、情報処理方法、およびプログラム
Benslimane et al. Deriving Conceptual Schema from Domain Ontology: A Web Application Reverse Engineering Approach.
JP2004310561A (ja) 情報検索方法、情報検索システム及び検索サーバ
Song et al. Extended query pattern graph and heuristics-based sparql query planning
US20210349429A1 (en) Similarity search of industrial components models
US20230153491A1 (en) System for estimating feature value of material
JP6971929B2 (ja) 問合せ文出力装置及び問合せ文出力方法
Eddy et al. Using structured queries for source code search
JP2004192374A (ja) 文書検索装置、プログラムおよび記録媒体
JP6034240B2 (ja) 分析方法、分析装置および分析プログラム
Ribeiro et al. Efficient algorithms for processing preference queries
CN117150994B (zh) 一种信号赋值延时的分析方法、电子设备及存储介质
JP7462498B2 (ja) データ処理装置、データ処理プログラム及びデータ処理方法
Sakr Towards a comprehensive assessment for selectivity estimation approaches of XML queries
Jabeen et al. Tuned schema merging (tusme)

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190822

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200728

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200915

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201014

R151 Written notification of patent or utility model registration

Ref document number: 6779855

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151