JPWO2015029208A1 - データベース管理装置、データベース管理方法及び記憶媒体 - Google Patents
データベース管理装置、データベース管理方法及び記憶媒体 Download PDFInfo
- Publication number
- JPWO2015029208A1 JPWO2015029208A1 JP2015533885A JP2015533885A JPWO2015029208A1 JP WO2015029208 A1 JPWO2015029208 A1 JP WO2015029208A1 JP 2015533885 A JP2015533885 A JP 2015533885A JP 2015533885 A JP2015533885 A JP 2015533885A JP WO2015029208 A1 JPWO2015029208 A1 JP WO2015029208A1
- Authority
- JP
- Japan
- Prior art keywords
- task
- resource
- query
- database
- query execution
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
- G06F16/24545—Selectivity estimation or determination
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Operations Research (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
プロセッサとメモリとストレージ装置を備えて、ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、データベースへのクエリを受け付けるクエリ受付部と、受け付けたクエリを実行するために必要なデータベースオペレーションを含むクエリ実行プランを生成するクエリ実行プラン生成部と、生成したクエリ実行プランに基づいて受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部と、を有し、クエリ実行部は、リソースの利用状況を取得して、次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、当該新たなタスクを前記タスクと並列して実行する。
Description
本発明は、データ管理技術に関する。
企業活動において、大量に生じる業務データの活用は不可欠になっている。そのため、大量の業務データを蓄積したデータベース(以下、「DB」)を解析処理するシステムが既に考案されている。
この解析処理において、データベース管理システム(以下、「DBMS」)は、クエリを受け付け、DBを格納する記憶デバイスにデータ読出し要求を発行する。
1つのクエリの処理におけるデータ読出しの待ち時間の短縮化を図る技術として、特許文献1に開示される技術が知られている。特許文献1によれば、DBMSは、クエリを実行するために必要な複数のデータベースオペレーション(DBオペレーション、または、処理ステップと呼ぶ)を組合せたプラン(以下、クエリ実行プラン)を生成し、前記処理ステップを実行するタスクを動的に生成し、前記タスクを並行実行することでデータ読出し要求を多重化する。特許文献1によれば、DBMSは、所定数まではタスクを増加させ、その後所定数を維持するようタスクを生成する。
近年、計算機の高性能化が進んでいる。例えば、演算を行うコア(これをプロセッサコアと呼ぶ)を複数搭載したプロセッサが一般化しており、計算機はこのようなプロセッサを複数搭載することで複数のプロセッサコアを持つ。ストレージ装置では、従来は直接ハードディスクドライブ(HDD)を接続していたが、HDDを複数搭載したストレージ装置を高速ネットワークで接続した形態も一般化している。
タスクを動的に生成するDBMSは、複数のタスクを実行することで、計算機のCPUリソースやI/Oリソース、メモリリソースなどのクエリの実行に利用されるリソースを活用し、クエリの処理時間を短縮している。I/O(Input/Output)とは、計算機がネットワークによって接続している外部の装置(例えば、ストレージ装置や別の計算機)からデータを入力する、または計算機が外部の装置へデータを出力する動作のことである。I/O要求とは外部装置からの入力要求又は外部装置への出力要求のことであり、例えば、DBMSを実行する計算機から外部装置へ発行される。ストレージ装置へ発行されるI/O要求は、ストレージ装置からの入力要求又はストレージ装置への出力要求となる。別計算機へ発行されるI/O要求は、別計算機からの入力要求又は別計算機への出力要求となる。
しかし、前記従来の技術において、タスクを動的に生成するDBMSでは、タスクの数を指定する必要があり、前記従来のDBMSでは、タスク数の指定を誤るとCPUリソース、メモリリソース、又はI/Oリソースなどのリソースを有効に活用できず、クエリの処理時間を短縮できないといった問題があった。
また、前記従来のDBMSは、クエリごとに処理が変わりCPUリソース、メモリリソース、又はI/Oリソースなどの使い方が異なる。このため、単にタスクの数を適切に設定しても、CPUリソース、メモリリソース、又はI/Oリソースを十分に使えない場合もあった。
そこで、本発明の目的は、タスクを動的に生成するDBMSが、CPUリソース、メモリリソース、又はI/Oリソースなどのリソースを有効に活用できるようタスクの生成を制御することである。
ここでCPUリソースとは、CPU(プロセッサコア)またはCPUの処理能力のことをいい、DBMSによるDBオペレーションが割り当てられたタスクの実行処理によって消費される。
また、メモリリソースとは、計算機に搭載されたメモリ(空き記憶領域)のことをいい、タスクがメモリにデータを記憶することで消費される。
I/Oリソースとは、DBMSにおけるタスクの実行により発行されるI/O要求の性能(データ読出しの待ち時間など)に影響を与えるリソースのことをいい、例えば、計算機、ストレージ装置、若しくは計算機とストレージとを接続するネットワークなど、又は、計算機、ストレージ装置、若しくはネットワークなどの性能がI/Oリソースにあたる。具体的には、計算機がネットワークに接続するためのネットワークアダプタの性能であったり、I/O要求やそのI/O要求に対するデータを転送するネットワークのケーブルの性能(帯域幅など)である。他には、計算機から発行されたI/O要求をストレージ装置で処理するためにストレージ装置がネットワークに接続するためのネットワークアダプタの性能であったり、ストレージ装置でI/O要求を処理するためのプロセッサの処理能力、データを記録するためのHDDの容量などがI/Oリソースにあたる。これらのI/Oリソースにおいて、ネットワークアダプタが同時に発行できるI/O要求の数であったり、ネットワークケーブルのデータ転送速度の上限であったり、I/O要求を処理するHDDの数などがI/O性能に影響を与える。これらのI/Oリソースは、DBMSにおけるタスクの実行によりI/O要求を処理する際に消費される。
本発明は、ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、データベースへのクエリを受け付けるクエリ受付部と、受け付けたクエリを実行するために必要な1以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成するクエリ実行プラン生成部と、生成したクエリ実行プランに基づいて受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行するクエリ実行部と、を有し、クエリ実行部は、受け付けたクエリの実行に利用されるリソースの利用状況を取得し、生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、新たなタスクを他のタスクと並列して実行するものである。
本発明によれば、タスクを動的に生成するデータベース管理装置において、CPUリソース、メモリリソース、又はI/Oリソースなどのクエリの実行に利用されるリソースの利用が十分になるようタスクを生成することが可能となる。また、データベース管理装置がタスクを生成する際には、利用が不十分なリソースを活用するタスクを生成することにより、CPUリソース、メモリリソース、又はI/Oリソースなどのクエリの実行に利用されるリソースの利用率を向上させることが可能となる。
以下、図面を用いて実施例1を説明する。
図1Aは、本発明の実施例1に係る計算機システムの一例を示すブロック図である。また、図1Bは、計算機100で実行されるDBMSの一例を示すブロック図である。
計算機システムは、計算機100と、外部ストレージ装置200とを有する。計算機100と、外部ストレージ装置200とは、通信ネットワーク300を介して接続されている。通信ネットワーク300を介した通信のプロトコルとしては、例えば、FC(Fibre Channel)、SCSI(Small Computer System Interface)、IB(Infini Band)、又は、TCP/IP(Transmission Control Protocol/Internet Protocol)等を採用することができる。
計算機100は、例えば、パーソナルコンピュータや、ワークステーション又はメインフレームである。計算機100は、ネットワークアダプタ110と、プロセッサ(典型的にはマイクロプロセッサ(例えばCPU(Central Processing Unit)))120と、ローカル記憶デバイス130と、メモリ140を有する。
プロセッサ120は、コンピュータプログラム、例えば、図示しないOS(Operating System)や、DBMS(Data Base Management System)141を実行する。1又は複数のプロセッサ120は、1又は複数のプロセッサコアを有する。各プロセッサコアがそれぞれ独立して、または並列的に処理を実行することができる。
メモリ140は、プロセッサ120によって実行されるプログラムと、プログラムが使用するデータとを一時的に記憶する。本実施例では、メモリ140は、DB(DataBase)の管理や関連する一連の処理を行うプログラムであるDBMS141及びデータを記憶する。メモリ141は、DBMS141にクエリを発行するためのAP(Application Program)148を記憶するようにしても良い。
ローカル記憶デバイス130は、計算機100のプログラム、及びプログラムが使用するデータを格納する。ローカル記憶デバイス130は、不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他の不揮発性半導体メモリである。
ネットワークアダプタ110は、通信ネットワーク300と計算機100とを接続する。また、プロセッサ120は、ネットワークアダプタ110及びメモリ140等に接続された制御デバイスに含まれている要素であっても良い。制御デバイスは、プロセッサ120の他に、専用ハードウェア回路(例えば、データの暗号化及び/又は復号化を行う回路や、データの圧縮及び/又は伸張を行う回路)を含むことができる。
なお、計算機100は、性能面や冗長性の観点から、ネットワークアダプタ110、プロセッサ120、ローカル記憶デバイス130、及びメモリ140のうちの少なくとも1つの要素を複数備えていても良い。また、計算機100は、図示しない入力デバイス(例えば、キーボード及びポインティングデバイス)と表示デバイス(例えば液晶ディスプレイ)とを有しても良い。入力デバイスと表示デバイスは一体になっていても良い。
計算機100は、データベース206に対して発行されたクエリをDBMS141が実行するデータベース管理装置である。このクエリは、計算機100で実行されるAP148又は、通信ネットワーク300に接続された図示しない計算機(クライアント)で実行されるAPによって発行される。
DBMS141は、AP148により発行されたクエリを実行し、前記クエリの実行に伴い、外部ストレージ装置200に格納されたDB206に対するI/O要求を、OSを介して外部ストレージ装置200に送信する。
なお、本実施例において、計算機100で実行されるDBMS141は一つだけであるが、DBMS141が複数実行されてもよい。なお、図示しないOSは、仮想化プログラムが生成した仮想マシン上で実行されるゲストOSであっても良い。そして、仮想化マシン上のOSがDBMS141を実行してもよい。そして計算機100が実行する仮想マシンは複数であってもよい。
外部ストレージ装置200は、計算機100が使用するデータを記憶する。外部ストレージ装置200は、計算機100からI/O要求を受信し、I/O要求に対応した処理を実行し、処理結果を計算機100に送信する。
外部ストレージ装置200は、ネットワークアダプタ201と、記憶デバイス群203及びそれらに接続されたコントローラ202を有する。
ネットワークアダプタ201は、外部ストレージ装置200を通信ネットワーク300に接続する。
記憶デバイス群203は、1つ以上の記憶デバイスを含む。記憶デバイスは、不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他の不揮発性半導体メモリである。記憶デバイス群203は、RAID(Redundant ARRAY of Independent Disks)に従い所定のRAIDレベルでデータを記憶するグループであっても良い。
記憶デバイス群203の記憶空間に基づく論理的な記憶デバイス(論理ボリューム)が計算機100に提供されても良い。記憶デバイス群203は、DB206を記憶する。DB206は、1つ以上の表205や索引204を含む。
表205は1つ以上のレコードの集合であり、レコードは1つ以上のカラムから構成される。索引204は、表205の中の1つ以上のカラムを対象に生成されるデータ構造であり、当該索引が対象とするカラムを含む選択条件による表205へのアクセスを高速化する。例えば、索引は、対象とするカラムの値毎に前記値を含む表の中のレコードを特定する情報(RowID)を保持するデータ構造であり、B木構造などが用いられる。DBの表205の構成例や表205同士の関連性の一例は、後述する。
コントローラ202は、例えば、図示しないメモリ及びプロセッサを含んでおり、計算機100からのI/O要求に従って、DB206を記憶した記憶デバイス群203に対してデータの入出力を実行する。例えば、コントローラ202は、計算機100からの書込み要求に従う書込み対象のデータを、記憶デバイス群203に格納したり、計算機100からの読出し要求に従う読出し対象のデータを記憶デバイス群203から読み出し、前記データを計算機100に送信する。
なお、外部ストレージ装置200は、性能面や冗長性確保の観点から、コントローラ202などの要素を複数備えても良い。また、外部ストレージ装置200を複数備えても良い。
DBMS141は、業務データを含んだDB206を管理する。図1Bで示すようにDBMS141は、クライアント通信制御部142、クエリ実行プラン生成部143、クエリ実行部144、実行タスク管理部145、DBバッファ管理部146、DBバッファ1460、コストテーブル1431及びDB領域管理表147を含む。
クライアント通信制御部142は、通信ネットワーク300に接続されたクライアントまたは計算機100で実行されるAP148との間の通信を制御する。具体的には、クライアント通信制御部(クエリ受付部)142は、図示しないクライアントまたはAP148から発行されたクエリを受け付け、クエリの処理結果をクライアントまたはAP148に応答する処理を実行する。クエリは、例えばSQL(Structured Query Language)で記述されている。
クエリ実行プラン生成部143は、クライアント通信制御部142が受け付けたクエリを実行するために必要な1つ以上の処理ステップを有するクエリ実行プランを生成する。クエリ実行プランは、例えば、クエリの実行の際に行うべき処理ステップの実行順序を木構造で定義した情報であり、メモリ140に格納される。クエリ実行プランの一例については、後述する。
DBバッファ管理部146は、DB206内のデータを一時的に格納するための記憶領域としてのDBバッファ1460(またはDBキャッシュ)を管理する。DBバッファ1460は、メモリ140上に構築される。あるいは、DBバッファを、ローカル記憶デバイス130上に構築しても良い。
クエリ実行部144は、クエリ実行プラン生成部143が生成したクエリ実行プランに従って処理を行うタスクを動的に生成し、前述タスクを実行することでDB206へアクセスし、クエリの結果を生成する。クエリ実行部144は、タスクが生成したDB206へのアクセス結果をクエリの発行元に応答する。クエリ実行部144は、タスク生成制御部152と、コンテキスト管理部153と、システム性能閾値表154と、性能データ表155とを有する。
タスク生成制御部152は、タスク生成の要求を受け付けた時にリソースの利用状況に基づいて新たなタスクを生成する。リソースとは、クエリの実行で利用する計算機のCPUリソース(プロセッサ120)やI/Oリソース(ネットワークアダプタ110や記憶デバイス群203等)、メモリリソース(メモリ140)などである。CPUリソースの利用状況はCPU利用率により示される。I/Oリソースの利用状況は、外部ストレージ装置200などの外部装置から計算機100へのデータ転送量や、計算機100から外部ストレージ装置200などの外部装置へのデータ転送量、又は、計算機100から外部ストレージ200などの外部装置に発行されるI/O要求数により示される。データ転送量は、単位時間当たりのデータ転送量であるデータ転送速度でもよく、累積したデータ転送量である累積データ転送量でもよい。I/O要求数は、単位時間あたりの処理したI/O要求数であるIOPS(Input/Output Per Second)でもよく、累積されたI/O要求数である累積I/O要求数でもよく、I/Oが完了していない発行済みI/O要求数であるアウトスタンディングI/O数でもよい。メモリリソースの利用状況は、メモリ使用量により示される。例えば、タスク生成制御部152は、CPUリソースやI/Oリソースの利用が不十分な場合にタスクを生成する。具体的には、現時点でのCPU利用率や、外部ストレージ装置200やローカル記憶デバイス130のディスク転送速度(またはデータ転送速度)やIOPS等のリソースの利用状況をタスク生成制御部152が取得して、予め設定したCPU利用率の閾値やディスク転送速度の閾値やIOPSの閾値と比較する。そして、タスク生成制御部152は利用量が閾値未満であれば、CPUリソースやI/Oリソース等のリソースが十分利用できていない(あるいは所定の条件を満足していない)と判定する。
そして、タスク生成制御部152は、リソースの使用状況が不十分であればタスクを生成する。リソースの使用状況が十分であるか否かを判定するため、タスク生成制御部152はシステム性能閾値表154から値を参照し、現時点でのCPU利用率やディスク転送速度やIOPSは性能データ表155を参照する。
コンテキスト管理部153は、新たに生成するタスクの実行に必要な情報を含むコンテキストを管理する。ここで、コンテキストは、タスクにおいて実行を開始する処理ステップが、クエリ実行プランが表す1以上の処理ステップのうちのいずれであるかを示す第1の情報と、第1の情報が示す処理ステップに要するデータのアクセス先に関する第2の情報と、タスクにより結果を生成するために必要なデータに関する第3の情報とを含む情報である。コンテキストを管理するための情報であるコンテキスト管理情報の構造については後述する。
システム性能閾値表154は、CPUリソースおよびI/Oリソースの利用が十分か否かを判定するための閾値を予め保持しており、タスク生成制御部152が参照する。
性能データ表155は、CPUリソースおよびI/Oリソースの現在の利用状況を判定するための値を保持しており、タスク生成制御部152が参照する。
実行タスク管理部145は、クエリを実行するためのタスクを管理する。ここで、タスクとしては、任意のモジュールを採用することができる。例えば、タスクは、OS415が管理するプロセス又はスレッドでも良いし、DBMS412で実装される疑似プロセス又は疑似スレッドでも良い。また、タスクは、各処理を関数としてまとめた関数へのポインタ(関数ポインタ)の集合であってもよい。タスクを管理するための情報であるタスク管理情報の構造については、後述する。
クライアント通信制御部142、クエリ実行プラン生成部143、クエリ実行部144、及びDBバッファ管理部146の少なくとも1つの処理部が行う処理の少なくとも一部が、ハードウェアで行われても良い。また、本実施例の説明において、処理部が主語になる場合は、実際には前記処理部を実行するプロセッサ120によって処理が行われるが、処理部の少なくとも一部がハードウェアで実現されている場合は、プロセッサ120に代えて又は加えて、前記ハードウェアも、主語とされ得る。DBMS141を実現するコンピュータプログラムは、プログラムソースから計算機100にインストールされて良い。プログラムソースは、例えば、計算機100が読み取り可能な記憶メディアで良いし、他の計算機でも良い。
また、図1に示したDBMS141の構成は、一例である。例えば、或る処理部が複数の処理部に分割されたり、複数の処理部の機能を統合した1つの処理部が構築されたりしても良い。
DBMS141を構成するクライアント通信制御部142と、クエリ実行プラン生成部143と、クエリ実行部144と、実行タスク管理部145及びDBバッファ管理部146の各機能部はプログラムとしてメモリ140にロードされ、プロセッサ120によって実行される。
プロセッサ120は、各機能部のプログラムに従って処理を実行することによって、所定の機能を実現する機能部として動作する。例えば、プロセッサ120は、クエリ実行プログラムに従って処理を実行することでクエリ実行部144として機能する。他のプログラムについても同様である。さらに、プロセッサ120は、各プログラムが実行する複数の処理のそれぞれを実現する機能部としても動作する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
DBMS141の各機能を実現するプログラム、テーブル等の情報は、ローカル記憶デバイス130や外部ストレージ装置200や不揮発性半導体メモリ、ハードディスクドライブ、SSD(Solid State Drive)等の記憶デバイス、または、ICカード、SDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
図2は、実施例1に係るDB206の表205及び索引204の定義を説明する図である。
DB206は、表205として、例えば、カラムc1(2052)及びカラムc2(2053)を含むPart表2051(図3参照)と、カラムc3(2055)及びカラムc4(2056)を含むLineitem表2054(図4参照)とを有する。
また、DB206は、索引204として、カラムc1(2052)の値に基づいたPart表2051に関する索引(Part索引)と、カラムc3(2055)の値に基づいたLineitem表に関する索引(Lineitem索引)とを有する。
図3は、実施例1に係るDB206のPart表2051の一例を示す図である。DB206のPart表2051は、論理的には、例えば、カラムc1(2052)の値と、対応するカラムc2(2053)の値とを対応付けた表である。
図4は、実施例1に係るDB206のLineitem表2054の一例を示す図である。DB206のLineitem表(2054)は、例えば、カラムc3(2055)の値と、対応するカラムc4(2056)の値とを対応付けた表である。
図5は、実施例1に係るDBの第一のクエリの一例を示す図である。図5に示すクエリは、図2〜図4、図6〜図8に示す構造のDB206に対するクエリの一例である。図5に示すクエリは、Part表2051及びLineitem表2054から、カラムc1(2052)の値が"130"であり、且つカラムc2(2053)の値とカラムc3(2055)の値とが同じであるものについて、カラムc1(2052)の値とカラムc4(2056)の値とを抽出することを意味している。
図6は、実施例1に係るDB206におけるpart索引2041のデータ構造の一例を説明する図である。
Part索引2041は、例えば、カラムc1(2052)の値に基づいて、対応するレコードを格納するpart表のページ(P、P1〜P9)及びページ内のスロットを検索するためのB木構造である。なお、索引のデータ構造には、R木やハッシュ、ビットマップなどのデータ構造を用いても良い。同様に、Lineitem索引2042は、例えば、カラムc3(2055)の値に基づいて、対応するレコードを格納するLineitem表2054のページ及びページ内のスロットを検索するためのB木構造である。
ここで、ページとは、DB206に対する入出力における最小のデータ単位である。本実施例では、Part索引2041は、ページPを入出力単位としたB木構造としている。Part索引2041においては、最下位のページであるリーフページ(P4〜P9)と、リーフページの上位のページである上位ページP1〜P3とがある。ここで、上位ページP1〜P3の中の最上位のページ(P1)をルートページという。
Part索引2041のルートページ(ページP1)には、一つ下の階層のページに対するポインタPtと、当該一つ下の階層のページが管理対象とするカラムc1(2052)の値の最大値とを対応付けたエントリが1以上設けられる。
例えば、ページP1には、"100"以下のカラムc1(2052)の値に対する対応関係を管理するページP2へのポインタPt12と、"100"より大きく"200"以下のカラムc1の値に対する対応関係を管理するページP3へのポインタPt13が格納される。同様に、上位ページにおいては、それぞれのページの一つ下の階層のページに対するポインタと、当該1つ下の階層のページに管理されているカラムc1(2052)の値の最大値とを対応付けたエントリPtが1以上設けられる。
一方、リーフページには、カラムc1(2052)の値と、当該値に対応するPart表のレコードの格納位置であるRowID(例えば、Part表2051のページ番号及び当該ページ中のスロット番号)とを対応付けたエントリEを1以上格納する。例えば、リーフページであるページP7には、カラムc1(2052)の値"110"に対応するカラムc2(2053)の値が格納されているページ及びスロットの番号を含むエントリE71と、カラムc1(2052)の値"130"に対応するカラムc2(2053)の値が格納されているページ及びスロットの番号を含むエントリ(E72)とが格納される。なお、その他のリーフページも同様であり、図中エントリEで表す。
図7は、実施例1に係るDB206におけるPart索引2041のキー値が130におけるRowIDを保持するデータ構造の一例を説明する図である。
例えば、図3に示したPart表2051のカラムc1(2052)の値"130"に対応するレコードのRowID(20411)には、ページP21のスロット2、ページP22のスロット1、ページP23のスロット4など、合計10個のRowIDが格納される。
図8は、実施例1に係るPart表(2051)のデータ構造の一例を説明する図である。
ページP21のスロット2にあるレコードは、カラムc1が130でカラムc2がid131である。ページP22のスロット1にあるレコードは、カラムc1が130でカラムc2がid132である。ページP23のスロット4にあるレコードは、カラムc1が130でカラムc2がid133である。以上のように、図7で示したカラムc1の値"130"に対応するレコードのRowIDは、カラムc1が130である10個のレコード20411を指し示している。
図9は、実施例1に係るDB206を外部ストレージ装置200の複数の記憶領域へ配置した一例を説明するブロック図である。外部ストレージ装置200は、複数の論理的な記憶領域(論理ボリュームまたは論理ユニット:LU)#1〜#4で構成され、これらの記憶領域#1〜#4に、DB206の索引204と表205を分散して配置した例を示す。
図9において、索引204はPart索引2041とLineitem索引2042に2分割される。Lineitem表2054は、LINEITEM(1)2054−1〜LINEITEM(4)2054−4に4分割される。
Part索引IDX_PART2041は記憶領域#1に格納されており、Lineitem索引IDX_LINEITEM2041は記憶領域#2に格納されている。
Part表2051は4つの領域(PART(1)2051−1とPART(2)2051−2とPART(3)2051−3とPART(4)2051−4)から構成される。Part表のPART(1)2051−1は記憶領域#1に、PART(2)2051−2は記憶領域#2に、PART(3)2051−3は記憶領域#3に、PART(4)2051−4は記憶領域#4に格納されている。
Lineitem表2054も、Part表2051と同様に、4つの領域2054−1〜2054−4から構成されており、それぞれの領域2054−1〜2054−4が記憶領域#1〜4に格納される。
図10は、実施例1に係るDB領域管理表147の一例を示す図である。
図10のDB領域管理表147は、DBオブジェクト(本実施例では、Part索引、Part表、Lineitem索引、Lineitem表)1471と、DBオブジェクトを構成するページ番号1472と、当該ページ番号がいずれの記憶領域#1〜#4に格納されているかを示す記憶領域名1473からひとつのエントリが構成される。例えば、DBオブジェクト1471がPart索引IDX_PARTの場合、ページ番号1472がP1〜P20であり、ページ番号P1〜P20は記憶領域#1に格納されていることを示す。また、Part表2051を構成するPART(2)のページ番号はP121〜P150であり、ページP121〜P150は記憶領域#2に格納されている事を示す。
なお、本実施例では、DB領域管理表147をDBMS141が保持する例を示したが、外部ストレージ装置200の記憶デバイス群203に保持されていても良い。
図11は、実施例1に係るクエリ実行プランの一例を示す図である。
図11に示すクエリ実行プランは、DBMS141が図5に示すクエリを受け付けた場合に、クエリ実行プラン生成部143により生成されるクエリ実行プランの一例を示している。
図5に示すクエリに対応するクエリ実行プランは、図11に示すように、Part索引2041による索引検索を行う処理ステップ#1と、Part表2051からレコードを取得する処理ステップ#2と、Lineitem索引2042による索引検索を行う処理ステップ#3と、Lineitem表2054からレコードを取得する処理ステップ#4と、これらの結果をネストループ結合する処理ステップ#5と、ネストループ結合した結果に対して演算を実行する処理ステップ#6と、を含む。図中外側は、ネストの外側のループを示し、本実施例では、Part表2051に対する処理となる。また、図中内側は、ネストの内側のループを示し、本実施例では、Lineitem表2054に対する処理となる。
図12は、図11に示した各処理ステップ#1〜#6におけるCPUコストを設定したコストテーブル1431の一例を示す図である。
コストテーブル1431は、クエリ実行プラン生成部143によってメモリ140上で管理される。コストテーブル1431は、処理ステップの番号を格納する処理ステップ1432と、プロセッサ120のコストを格納するCPUコスト1433からひとつのエントリが構成される。
各処理ステップ#1〜#6におけるCPUコスト1433とは、対応する処理ステップを実行する際にプロセッサ120が必要とする処理量を数値で表したものである。処理量としては、例えば、各処理ステップの命令数であったり、各処理ステップを実行するのにプロセッサ120が必要とするクロック数、処理ステップの処理に要する処理時間などを採用することができる。本実施形態では、計算機100で各処理ステップ1432を実行したときの処理時間(μsec)でCPUコスト1433を表す例を示す。
クエリ実行プラン生成部143では、例えば、各処理ステップのCPUコストやI/Oコストを元にクエリ実行プランを決定しているため、CPUコストはクエリ実行プラン生成部143のコスト見積りで使うCPUコストを用いてもよい。
また、クエリ実行プラン生成部が、143事前に処理ステップ毎の処理時間や処理に要するクロック数を計測した結果をコストテーブル1431に設定しておいてもよい。また、クエリを実行中にCPUコストを検出して、この値をコストテーブル1431に設定するようにしてもよい。さらには、検出したCPUコストをクエリ実行中の処理ステップの処理時間を用いて補正してもよい。
図13は、実施例1に係るタスク実行状態情報73の一例を示す図である。タスク実行状態情報73は、実行タスク管理部145がメモリ14上で保持する。
タスク実行状態情報73には、メモリ140上に設定されたワーク領域73aと、実行する処理ステップの番号を格納する処理ステップ73bと、処理ステップ実行状態73cが含まれる。
ワーク領域73aには、対応するタスクがクエリ実行プランを処理する際にカラムの値を格納するワーク領域73dを示すポインタが格納される。処理ステップ73bには、対応するタスクで実行する処理ステップを識別する情報、例えば、処理ステップ番号が格納される。処理ステップ実行状態73cには、対応する処理ステップの実行状態情報(処理ステップ実行状態情報)74が格納される。処理ステップの実行状態情報74の具体例については、後述する。
図14は、実施例1に係る処理ステップの実行状態情報74の第1の例を示す図である。図14は、索引検索における上位ページを使用するタスクについての処理ステップ実行状態情報を示す。
処理ステップ実行状態情報74Aは、検索条件74aと、ページ番号74bと、スロット番号74cとを含む。検索条件74aには、検索条件が格納される。図示の例では、検索条件74aには、図5に示したクエリに含まれる検索条件である"c1=130"を格納される。ページ番号74bには、タスクの処理で使用する上位ページの番号(ページ番号)を格納される。スロット番号74cには、図8で示したように、タスクの処理で使用するページにおけるスロットの番号(スロット番号)を格納される。
図15は、実施例1に係る処理ステップの実行状態情報74の第2の例を示す図である。図15は、索引検索におけるリーフページP4〜P9(図6参照)を使用するタスクについての処理ステップ実行状態情報を示す。
処理ステップ実行状態情報74Bは、検索条件74dと、ページ番号74eと、スロット番号74fと、処理RowID番号74gとを含む。検索条件74dには、検索条件が格納される。図示の例では、検索条件74dには、検索条件である"c1=130"が格納される。ページ番号74eには、タスクの処理で使用するリーフページのページ番号"7"が格納される。
スロット番号74fには、タスクの処理で使用するページにおけるスロットのスロット番号"2"が格納される。処理RowID番号74gには、対応するタスクで処理するスロット内のRowのID番号(処理RowID番号)"1"が格納される。
図16は、実施例1に係る処理ステップの実行状態情報74の第3の例を示す図である。図16は、レコード取得を行うタスクについての処理ステップ実行状態情報74Cを示す。
処理ステップ実行状態情報74Cは、ページ番号74hと、スロット番号74iとを含む。ページ番号74hには、タスクの処理で使用するページのページ番号"2"が格納される。スロット番号74iには、タスクの処理で使用するページにおけるスロットのスロット番号"2"が格納される。
図17は、実施例1に係るタスク管理情報1450のデータ構造の一例を示す図である。タスク管理情報1450は、実行タスク管理部145によって管理されるデータ構造で、メモリ140上に保持される。
タスク管理情報1450のデータ構造は、実行可能なタスクを管理するための実行可能リスト1451と、I/O要求の完了を待っているタスクなど、実行待ち状態であるタスクを管理するための待ちリスト1452が含まれる。
実行可能リスト1451は、実行可能なタスクに関する実行状態情報であるタスク実行状態情報73(図13参照)へのポインタ1453を有する。待ちリスト1452も同様に、待機中のタスクに関する実行状態情報であるタスク実行状態情報73(図13参照)へのポインタ1454を有する。また、タスク実行状態情報73は、実行可能な他のタスクに関するタスク実行状態情報73へのポインタを有する。
図18は、初期のコンテキスト1530の一例を示す図である。上述のように、コンテキスト1530は、新たに生成するタスクの実行に必要な情報であり、コンテキスト管理部153が管理する。
初期のコンテキスト1530には、図18で示すように、開始ステップ1531と、中間結果1532と、生成可能数1533と、実行状態1534と、を含む。開始ステップ1531には、実行する処理ステップの番号または識別子が格納される。
中間結果1532には、処理ステップを実行するタスクに必要な中間結果を格納するワーク領域1539の所在を示すポインタが格納される。ここで、中間結果とは、クエリの結果を生成するために必要な取得済みのデータである。また、ワーク領域1539はメモリ140上に設定された領域である。
実行状態1534には、次に実行するタスクの処理の内容を特定する情報を格納される。例えば、図示の例では、処理対象のページ番号1561と、まだ処理されていないデータのリストで構成された未処理データリスト1562である。未処理データリスト1562は、例えば、処理されていないページ番号とスロット番号の組で構成することができる。
生成可能数1533には、タスクの実行状態において、タスク生成制御部152がさらに生成することのできるタスクの数(タスク生成可能数)が格納される。このタスク生成可能数は、開始ステップ1531の実行状態のページ番号において、論理的に分岐する処理の数の内で、タスクとして生成されていない処理の数である。図18の例では、図6に示したPart索引2041において、"c1=130"という検索条件で検索している際に、"c1=130"のエントリをページP7で取得した際のコンテキストを示している。
図18の例では、開始ステップ1531には、"処理ステップ#1"が格納される。中間結果1532には、コンテキストを生成する時点のタスクが保持するワーク領域73dの内容をコピーした領域であるワーク領域1539のポインタが格納される。
ページ番号1561には、図6で示したように、コンテキストから生成されるタスクの処理で使用するリーフページのページ番号である"P7"が格納される。ここで、図7に示した最初のRowID20411="P21,2"は、コンテキストを生成するタスクが処理するため、未処理データリスト1562には、残りの9個のRowID20411のデータを格納する。この初期のコンテキスト1530から生成可能なタスクは9個のため、タスク生成可能数1533には"9"が格納される。
図19は、実施例1に係る第1のコンテキスト1530−1の一例を示す図である。
本発明において、I/OリソースやCPUリソースの利用状況によって生成するタスクを選択できるようにするために、生成されるタスクの特徴(または種類)ごとにコンテキスト1530−1〜1530−nを生成することができる。本実施例では、タスクの特徴として、I/O要求を出す記憶領域#1〜#4と、I/O要求の大きさであるI/Oサイズ、I/Oパターン、そしてCPUコストを特徴とする。I/Oパターンとは、複数のI/O要求に記されたアドレスの特徴である。例えば、前に行われたI/O要求のアドレスに隣接したアドレスへのI/O要求が連続して処理される場合、そのI/Oパターンはシーケンシャルと呼ばれる。一方、前に行われたI/O要求のアドレスとは無関係なアドレスへのI/O要求が連続して処理される場合、そのI/Oパターンをランダムと呼ぶ。タスクの特徴としてのI/Oパターンとは、当該タスクを実行した場合にそれらのI/O要求のアドレスがどのような特徴となるかを示すものである。そして、DBMS141では、初期のコンテキスト1530から分類された特徴毎にコンテキスト1530−1〜1530−nを生成する。
このため、図19に示す第1のコンテキスト1530−1には、図18に示した開始ステップ1531と中間結果1532と生成可能数1533と実行状態1534に加え、記憶領域名1535と、I/Oサイズ1536と、I/Oパターン1537と、CPUコスト1538とを含む。
図19は、上記図18に示した初期のコンテキスト1530に含まれるRowID20411(図7参照)を分類した場合に、記憶領域#1にアクセスするRowIDを集めた第1のコンテキスト1530−1の一例である。特徴に基づいて生成すべきコンテキストを分類する処理の詳細に関しては後述する。
上記コンテキスト1530−1から生成されるタスクは、記憶領域#1にアクセスし、I/Oサイズ1536は4KBで、I/Oパターン1537はランダムで、そのCPUコスト1538は125のタスクである。
図20は、実施例1に係る第2のコンテキストの一例を示す図である。
図20は、上記図18に示した初期のコンテキスト1530に含まれるRowID20411(図7参照)を分類した場合に、記憶領域#2にアクセスするRowIDを集めたコンテキスト1530−2の一例である。このコンテキスト1530−2から生成されるタスクは、記憶領域#2にアクセスし、I/Oサイズ1536は4KBで、I/Oパターン1537はランダムで、そのCPUコスト1538は125のタスクとなる。
なお、本実施例ではI/OリソースやCPUリソースの利用が区別できるようなコンテキストの分類をしているが、メモリリソースの利用に関する分類ができてもよい。例えば、本コンテキストで処理を開始するタスクのメモリ消費量を特徴にしても良い。
図21は、実施例1を示し、DBMS141がクエリを受け付けてから、結果を応答するまでの処理全体のフローチャートである。
クエリ受付時の処理においては、クライアント通信制御部142が、AP148からクエリを受け付けると(ステップS1)、受け付けたクエリをクエリ実行プラン生成部143に渡し、クエリ実行プラン生成部143がクエリ実行プランを生成する(ステップS2)。
続いて、クエリ実行部144が、初期タスク数と上限タスク数と下限タスク数を設定する(ステップS3)。本実施例では、初期タスク数と上限タスク数と下限タスク数を設定しているが、いずれか1つでもよく、または初期タスク数と上限タスク数と下限タスク数を任意に組み合わせても良い。
ここで、初期タスク数とは、クエリ実行処理の開始後にCPUリソースやI/Oリソースの利用状況とは関係なく、クエリ実行部144が生成するタスクの数である。初期タスク数は、ユーザが指定しても良く、あるいは、DBMS141がハードウェア構成から自動的に計算しても良い。例えば、通信ネットワーク300と計算機100をFibre Channelで接続している場合、Fibre Channelのポートで同時に発行できるI/O要求数であるタグ数が1024であるとすると、"Fibre Channelポート数×1024"を初期タスク数に設定する。
あるいは、外部ストレージ装置200の同時コマンド受付数が2048であれば、初期タスク数に"2048"を設定する。外部ストレージ装置200がn台のハードディスクドライブ(HDD)を使って計算機100に論理ボリュームを提供している場合、"n×32"を初期タスク数に設定する。
上限タスク数とはDBMS141上で同時に存在するタスクの上限であり、CPUリソースやI/Oリソースが十分利用されていない場合でも、上限タスク数を超えるタスクがDBMS141上で同時に存在しないことを保証する。上限タスク数は、ユーザが指定してもよく、DBMS141がハードウェア構成から自動的に計算しても良い。例えば、通信ネットワーク300と計算機100をFibre Channelで接続している場合、Fibre Channelポートで同時に発行できるI/O要求数であるタグ数が1024であるとすると、"Fibre Channelポート数×1024"を上限タスク数に設定する。外部ストレージ装置200の同時コマンド受付数が2048であれば、上限タスク数に"2048"を設定する。外部ストレージ装置200がn台のハードディスクドライブ(HDD)を使って計算機100に論理ボリュームを提供している場合、"n×32"を上限タスク数に設定する。
下限タスク数とは、CPUリソースやI/Oリソースの利用状況とは関係なく生成するタスクの数である。下限タスク数は、ユーザが指定してもよく、DBMS141がハードウェア構成から自動的に計算しても良い。例えば、プロセッサコアを活用できるようにプロセッサコアの数を下限タスク数に設定する。下限タスク数は外部ストレージ装置200のHDDを活用できるようHDDの数を下限タスク数に設定する。
次に、クエリ実行部144が、初期のコンテキスト1530を生成する(ステップS4)。初期のコンテキスト1530とは、図18で示したように、クエリ実行プランを最初に実行するタスクを生成するコンテキスト1530である。例えば、図11に示したクエリ実行プランの場合、Part索引のルートページから"c1=130"という検索条件で処理ステップ#1を開始させるコンテキスト1530である。生成した初期のコンテキスト1530は、コンテキスト管理部153に登録される。
クエリ実行部144がクエリ実行処理を行う(ステップS5)。クエリ実行部144が新たなタスクを生成し、タスクを実行することでクエリの処理を行い、外部ストレージ装置200のDB203に対するクエリの結果を生成する。クエリ実行処理の具体的な内容は、図22にて説明する。
クエリ実行部144が生成した結果を、クライアント通信制御部142がクエリを送付してきたAP148に応答する(ステップS6)。クエリ実行部144が生成する結果がなくなった時に、全体の処理が終了する。
以上の処理が、DBMS141がAP148からクエリを受け付けて、クエリに対応するタスクを生成し、タスクを実行して外部ストレージ装置200のDB203にアクセスを実行し、アクセス結果をクエリの処理結果として生成する。
図22は、実施例1に係るクエリ実行処理の一例を示すフローチャートである。この処理は、図21のステップS5で行われる処理である。
クエリ実行部144は、コンテキスト1530の有無とタスクの有無を判定する(ステップS11)。コンテキスト1530の有無は、コンテキスト管理部153に登録されているコンテキスト1530の有無を判定する。タスクの有無は、実行タスク管理部145にタスクが存在しているか否かを判定する。コンテキスト1530が無く、かつ、タスクもない場合には、クエリ実行処理が終了する。一方、コンテキスト1530が有る、または、タスクがある場合は、ステップS12の処理に進む。
クエリ実行部144は、実行可能なタスクの有無を判定する(ステップS12)。実行可能なタスクの有無は、実行タスク管理部145にて判定する。実行可能なタスクがなければステップS13へ進み、実行可能なタスクがあればステップS16へ進む。
実行可能なタスクがない場合、クエリ実行部144は、タスク生成処理を行う(ステップS13)。タスク生成処理は、コンテキスト1530を読み込んで新たなタスクを生成する処理である。具体的な処理については後述する。
タスク生成処理の後に、クエリ実行部144は、再度実行可能なタスクの有無を判定する(ステップS14)。実行可能なタスクがない場合は、コンテキストもなく、存在するタスクは全て待ちリスト1452のポインタ1454(図17参照)に保持された状態なので、一定時間スリープする(ステップS15)。
一方、ステップS12またはステップS14で実行可能なタスクがある場合には、クエリ実行部144は、タスクを1つ選択し(ステップS16)、選択したタスクを実行する(ステップS17)。タスクの実行とは、新規のタスクであれば、図23に示すタスク実行処理を開始することである。一方、待ちリスト1452のポインタ1454から実行可能リストに移ったタスクであれば、待ちリスト1452のポインタ1454へ入ったときの処理から再開する。
クエリ実行部144は、新規または再開したタスクの実行が終了すると、ステップS11に戻り、コンテキスト1530とタスクがなくなるまで上記処理を繰り返す。
図23は、実施例1に係るタスク実行処理の一例を示すフローチャートである。この処理は、図22のステップS17で新たなタスクに対して行われる処理である。
このタスク実行処理は、クエリ実行部144が、処理の決まっていない新規のタスクを実行する際に適用される。クエリ実行部144は、新たなタスクの処理の内容を決めるために、コンテキスト管理部153でコンテキスト取得処理を行う(ステップS21)。コンテキスト取得処理の具体的な内容は、図31にて説明する。
クエリ実行部144は、取得したコンテキスト1530を使ってタスクの実行状態情報73(図13参照)を設定する(ステップS22)。ここでは、図19に示した第1のコンテキスト1530−1を例に説明する。クエリ実行部144は、コンテキスト1530−1の開始ステップ1531の値(処理ステップ#1)を、タスク実行状態情報73の処理ステップ73bにコピーする。
クエリ実行部144は、コンテキスト1530の中間結果1532のポインタが示すワーク領域1539のデータを、タスク実行状態情報73のワーク領域73aのポインタが示すワーク領域にコピーする。
クエリ実行部144は、取得したコンテキスト1530の未処理データリスト1562からデータを一つ取り出し、処理ステップ実行状態情報74Cを設定する。クエリ実行部144は、未処理データリスト1562からデータを一つ取り出したので、コンテキスト1530の生成可能数1533を1減らす。
処理ステップ実行状態情報74Cの設定について、具体的な例を説明する。例えば、クエリ実行部144が、図7に示したRowID(P22,1)を未処理データリスト1562から取得したとする。図18で示したようにコンテキスト1530の実行状態のページ番号が"P7"であることから、未処理データリスト1562のデータは、レコードの取得を行うRowIDである。
そこで、クエリ実行部144は、レコードの取得を行うステップ実行状態である図16の処理ステップ実行状態情報74Cを準備する。すなわち、クエリ実行部144は、処理ステップ実行状態情報74Cのページ番号74hには"P22"を設定し、スロット番号74iには"1"を設定する。
クエリ実行部144は、タスクを開始する際、レコードの取得から処理を実行するため、タスク実行状態情報73内の処理ステップ73bを一つ進め、図11で示すように処理ステップ#2を設定する。以上で、クエリ実行部144は、タスクの実行状態情報73を設定する処理が完了する。
クエリ実行部144は、ステップS22で設定された状態に従い、処理ステップ実行処理を実行する(ステップS23)。処理ステップ実行処理に関しては図24で説明する。処理ステップ実行処理が終了すると、タスク実行処理は終了する。
図24は、実施例1に係る処理ステップ実行処理のフローチャートである。この処理は、図23のステップS23で実行される処理である。
クエリ実行部144は、DBバッファ管理部146にDBページ取得処理(図26参照)を実行させる(ステップS30)ことにより、DB206からクエリの対象となるページ(DBページ)を取得する。
次いで、クエリ実行部144は、取得したページにおけるデータについて、検索条件と合致するものがあるか否かを判定する(ステップS31)。例えば、索引の上位ページであれば、上位ページ内の検索処理であり、リーフページであればリーフページの検索処理である。この判定の結果、ページにおけるデータに、検索条件と合致するデータがない場合(ステップS31で"偽")には、処理ステップ実行処理が終了する。
一方、検索条件に合致するデータがある場合(ステップS31で"真")には、クエリ実行部144は、検索条件に合致するデータが1つであるか、2つ以上であるか否かを判定する(ステップS32)。
この判定の結果、検索条件に合致するデータが1つである場合(ステップS32で"1つ")には、クエリ実行部144は、処理をステップS35に進める。一方、検索条件に合致するデータが2つ以上である場合(ステップS32で"2つ以上")には、クエリ実行部144がコンテキスト生成処理(図25)を行い(ステップS33)、クエリ実行部144のタスク生成制御部152はタスク生成処理(図29)を実行し(ステップS34)、処理をステップS35に進める。
ステップS35では、クエリ実行部144は、当該タスクによる処理ステップにおけるDB206のページに対する処理を実行する。ここで、DB206のページに対する処理とは、例えば、索引の上位ページであれば、検索条件に合致するページ番号を読み出す処理であり、リーフページであれば検索条件に合致するRowIDを読み出す処理であり、表204のページであればレコードのカラムを読み出す処理である。
次いで、クエリ実行部144は、次のDB206のページと、当該ページに対する処理を決定し(ステップS36)、ステップS37に処理を進める。
ステップS37では、クエリ実行部144は、処理が終了したので、取得しているDB206のページを解放する。次いで、ステップS38では、クエリ実行部144は、次の処理があるか否かを判定する。具体的には、現在行っている処理ステップ73bが完了しており、当該処理ステップを含む処理ブロックにおいて次の処理ステップがない場合にクエリ実行部144は処理が"無"と判定する。
この判定の結果、次の処理がある場合(ステップS38で"有")には、クエリ実行部144は、処理をステップS30に戻す一方、次の処理がない場合(ステップS38で"無")には、処理結果をクエリ実行部144に渡し(ステップS39)、処理ステップ実行処理を終了する。
ここで、次のDB206から取得したページと、当該ページに対する処理の決定について、図2〜図4と図6〜図8に示すDB206に対して、"c1=130"を検索条件として、Part索引2041を索引検索する場合を例にして、以下に説明する。
最初に索引検索を開始している場合においては、クエリ実行部144は、索引のルートページ(図6に示したページ番号"P1"のページ)を次のDB206のページと決定し、当該ページに対して"130"というキーを検索する上位ページ内の検索処理をDB206のページに対する処理として決定し、処理を開始する。
ステップS30で、クエリ実行部144はページP1を読み込み、ステップS31で当該ページP1の中でカラムc1(2052)に"130"を含むエントリを検索する。図6において、クエリ実行部144は、カラムc1(2052)に"200"を含むエントリ(Pt13)を1つ取得するので、ステップS35とステップS36で、次の処理としてページP3に対して上位ページ内の検索処理をDB206のページに対する処理と決定する。
また、ステップS30からステップS35で、索引の下位ページP3に対する処理を行う。クエリ実行部144は、DB206からページP3を読み込み、当該ページP3でカラムc1(2052)に"130"を含むエントリを検索し、カラムc1(2052)に"130"を含むエントリにおいてページP7へのポインタPtを取得する。この結果、クエリ実行部144は、ページP7を次のDB206の処理対象ページと決定し、当該ページP7に対してリーフページ内の検索処理をDB206のページに対する処理と決定する。
クエリ実行部144は、ステップS30からステップS33で、ページP7を読み込み、図6で示したように、当該ページP7でカラムc1(2052)に"130"を含むエントリ(E72)を取得する。ここで図7に示したように、検索条件に合致するデータが10個あるので、当該タスクで処理するデータ以外の9個のデータの処理を行うために、クエリ実行部144は、コンテキスト生成処理(ステップS33)を行い、タスク生成処理(ステップS34)を行う。
本実施例では、当該タスクで処理するデータを最初のデータとし、ステップS36でPart表2051のページP21を次のDB206の対象ページと決定し、図8で示したように、当該ページP21に対してスロット番号2にあるレコードを取得する処理をDB206のページに対する処理と決定する。
以上の処理により、DBMS141では、処理対象の先頭のDB206のページから、検索条件に合致するデータを処理するコンテキスト1530を図18で示したように生成し、このコンテキスト1530からタスクを生成することで、複数のタスクとして実行することができる。
図25は、実施例1に係るコンテキスト生成処理のフローチャートである。この処理は図24のステップS33で行われる処理である。
クエリ実行部144は、まず、図18に示した初期のコンテキスト1530から生成されるタスクを、I/O要求を出す記憶領域#1〜#4と、I/Oパターンと、I/Oサイズと、CPUコストで分類する(ステップS41)。
例えば、リーフページ(P4〜)の処理で作られたコンテキスト1530から生成されるタスクは、コンテキスト1530の未処理データリスト1562に格納されるRowIDを元に生成される。クエリ実行部144は、コンテキストに保持するRowIDを、I/O要求を出す記憶領域名、I/O要求の大きさであるI/Oサイズ、I/Oパターン、CPUコストにより分類し、分類された未処理データリスト1562ごとにコンテキスト1530−1〜1530−nを生成する。
例えば、図18における未処理データリスト1562に含まれるRowID(P21,2)は、クエリ実行部144が図10のDB領域管理表147を参照して、記憶領域#1にI/O要求を発行する。
また、クエリ実行部144はDB領域管理表147から処理ステップ#1の前記I/O要求がリーフページからの処理となるため、I/Oサイズ1536はDB206のページサイズ(ここでは4KBを仮定)であり、I/Oパターン1537はランダムとする。
また、クエリ実行部144は、図12のコストテーブル1431を参照してCPUコストを取得する。クエリ実行部144は、初期のコンテキスト1530から生成されるタスクは、処理ステップ#1から処理ステップ#6まで行う可能性があるため、初期のコンテキスト1530のCPUコスト1538はコストテーブル1431のCPUコスト1433を合計した125となる。クエリ実行部144は、上記処理を図7に示した残りのRowID20411についても実行し、記憶領域#、I/Oサイズ、I/Oパターン、CPUコストから生成するタスクを、利用するリソースの種類に応じて分類する。
そして、クエリ実行部144は、上述の分類ごとにコンテキスト1530−1〜1530−nを生成して(ステップ42)、コンテキスト管理部153に登録する。
図18に示すコンテキスト1530の場合、本実施例では記憶領域#1にアクセスする第1のコンテキスト1530−1(図19)と記憶領域#2にアクセスする第2のコンテキスト1530−1(図20)、記憶領域#3にアクセスする第3のコンテキスト(図示省略)と記憶領域#4にアクセスする第4のコンテキスト(図示省略)を生成する。
図26は、実施例1に係るDBページ取得処理のフローチャートである。この処理は、図24のステップS30で行われる処理の一例を示すフローチャートである。
DBバッファ管理部146は、取得対象のDB206のページに対応するバッファページ(DBバッファ1460に保持されたページ)を検索し(ステップS51)、取得対象のDB206のページに対応するDBバッファページの有無を判定する(ステップS52)。
この判定の結果、DBバッファ管理部146は、DBバッファページがDBバッファ1460にある場合(ステップS52で"有")には、DBバッファ管理部146は、DB206から当該ページの読込みが完了しているか否かを判定する(ステップS53)。外部ストレージ装置200からの読み込みが完了している場合(ステップS53で"完了")には、DBバッファ管理部146は、DBページ取得処理を終了する。一方、DB206からの読み込みが完了していない場合(ステップS53で"未完")には、ステップS56に処理を進める。
一方、ステップ52の判定で、取得対象のDB206のページに対応するDBバッファページがない場合(ステップS52で"無")には、DBバッファ管理部146は、DBバッファ1460から空きDBバッファページを取得する(ステップS54)。そして、DBバッファ管理部146は、DB206に対して取得対象のページを空きDBバッファページに読込むためにページ読込み要求を発行し(ステップS55)、処理をステップS56に進める。これにより、DBバッファ1460から取得した空きDBバッファページに、取得対象のページがDB206から読み込まれる。
ステップS56では、DBバッファ管理部146が、DB206からのページの読込みが完了するのを待つ。ここで、DBバッファ管理部146は、ページの読込みが完了するまで待つ同期I/O、または、ページの読込みが完了していなくて他の処理を実行する非同期I/Oの何れかを採用することができる。
例えば、DBバッファ管理部146は、実行中のタスクの処理を中断して待ち状態とし、タスク実行状態情報73を待ちリスト1452に移動する。そして、DBバッファ管理部146は、別のタスクにより取得対象のページの読込みの完了を判定する。DBバッファ管理部146は、当該別のタスクでページの読込みの完了を判定した場合には、当該タスクのタスク実行状態情報73を実行可能リスト1451に移動し、当該タスクの処理を再開させるようにしてもよい。
このように、非同期I/Oを採用すると、DBバッファ管理部146は、ページの読込み完了を待たずに、他のタスクの実行を行うことができるようになり、DBMS141の処理能力を向上することができる。なお、DB206からのページの読み込みが完了した場合には、DBバッファ管理部146は、DBページ取得処理を終了する。
図27は、実施例1に係るシステム性能閾値表の一例を示す図である。
システム性能閾値表154は、CPUリソースおよびI/Oリソースの利用が十分であるか否かを判定するための閾値を保持する。CPUリソースの閾値は計算機100に搭載された全てのプロセッサの利用率であるCPU利用率1541とする。I/Oリソースの閾値は、外部ストレージ装置200からの単位時間あたりのデータ転送量であるディスク転送速度1542(単位:MB/s)と、外部ストレージ装置200の単位時間あたりのI/O要求処理数であるIOPS1543(単位:IOPS)とする。また、計算機が複数存在するシステムでは、他の計算機との単位時間あたりのパケットの送受信数であるパケット転送レート1544(単位:pps(Packet Per Second))もI/Oリソースの閾値に加えることもできる。本実施例では他の計算機との通信のI/Oリソースにパケット転送レートを用いているが、他の計算機とのデータ転送量であるネットワーク転送速度(単位:MB/s)をパケット転送レートの代わりに用いてもよい。
システム性能閾値表154の閾値は、ユーザが値を指定しても良いし、計算機システムの構成からDBMS141が自動計算しても良い。また、性能を測定するためのテストクエリを実行させたり、単純なCPU処理や単純なランダムREADやシーケンシャルREADを行うことで閾値の値を求めてもよい。
図27の例では、CPU利用率1541が閾値の90%以上であれば、CPUリソースの活用が十分であると判断する。一方、ディスク転送速度1542が閾値の2000MB/s以上か、またはIOPS1543が閾値の60000IOPS以上であればI/Oリソースの活用が十分と判断する。なお、実施例1では、計算機100が1台でありパケット転送レート1544は考慮しない。このため、パケット転送レート1544には"−1"を設定する。
図28は、実施例1に係る性能データ表155の一例を示す図である。
性能データ表155は、システム性能閾値表154に登録された閾値に対応する性能データについて現在の値を保持する。性能データ表155は、CPUリソースの性能データとして計算機100に搭載された全てのプロセッサの利用率であるCPU利用率1551を含む。また、性能データ表155は、I/Oリソースの性能データとして、外部ストレージ装置200からの単位時間あたりのデータ転送量であるディスク転送速度1552と、外部ストレージ装置200の単位時間あたりのI/O要求処理数であるIOPS1553を含む。
また、計算機100が複数存在する計算機システムでは、性能データ表155に、他の計算機とのデータ転送量であるパケット転送レート1554も含める。これらの値は、DBMS141がCPU利用時間やI/Oコマンドの履歴を保持し、性能データ表155を参照するたびに計算してもよい。また、DBMS141がCPU利用時間やI/Oコマンドの履歴を保持し、一定間隔で性能データ表155の値を更新する方法でもよい。また、計算機100で稼働するOSのコマンド(mpstatコマンドやiostatコマンド)から一定間隔で出力される値から算出した値を、性能データ表155に設定してもよい。
なお、性能データ表155の各値は、DBMS141や計算機100のOS(図示省略)が所定の周期で取得した値を用いることができる。
図29は、実施例1に係るタスク生成処理のフローチャートである。この処理は、図24のステップS34で、クエリ実行部144のタスク生成制御部152が実行する。
タスク生成処理では、タスク生成制御部152がCPUリソースやI/Oリソースの利用状況によりタスクの生成を調整する。また、タスク生成制御部152は、クエリ実行部144が図21のステップS3で設定した初期タスク数と上限タスク数または下限タスク数によってもタスク数の調整を行う。タスク数は、実行タスク管理部145においてその時点で存在しているタスクの数である。
タスク生成制御部152は、初期タスク数が1以上か否かを判定し(ステップS59)、1以上であれば初期状態のタスクを生成する(ステップS67)。その際、タスク生成制御部152は、タスク数と初期タスク数を比較して(ステップS68)、タスク数が初期タスク数と同じであれば初期タスク数に0を設定する(ステップS69)。一方、タスク数が初期タスク数と異なれば、タスク生成処理は終了する。これにより、タスク生成制御部152は、CPUリソースやI/Oリソースの利用状況に関係なく、初期タスク数まではタスク数を増加させることができる。
初期タスク数が1以上でない場合(ステップS59で偽の場合)、タスク生成制御部152は、下限タスク数とタスク数の比較を行う(ステップS60)。下限タスク数よりタスク数以下の場合は、タスク生成制御部152が初期状態のタスクを生成する(ステップS66)。
下限タスク数よりタスク数が多い場合(ステップS60で真の場合)、タスク生成制御部152はCPUリソースやI/Oリソースの利用状況により初期タスクの生成の可否を判定する。具体的には、性能データ表155のCPU利用率1551がシステム性能閾値表154のCPU利用率1541より小さいか否かを判定する(ステップS61)。性能データ表155のCPU利用率1551が、閾値のCPU利用率1541以上であれば、タスク生成制御部152は、タスク生成処理を終了する。
次に、タスク生成制御部152は、性能データ表155のディスク転送速度1552がシステム性能閾値表154のディスク(またはデータ)転送速度1542より小さいか否かを判定する(ステップS62)。性能データ表155のディスク転送速度1552が、閾値のディスク転送速度1542以上であれば、タスク生成制御部152は、タスク生成処理を終了する。
次に、タスク生成制御部152は、性能データ表155のIOPS1553がシステム性能閾値表154のIOPS1543より小さいか否かを判定する(ステップS63)。性能データ表155のIOPS1553が、閾値のIOPS1543以上であれば、タスク生成制御部152は、タスク生成処理を終了する。
次に、タスク生成制御部152は、性能データ表155のパケット転送レート1554がシステム性能閾値表154のパケット転送レート1544より小さいか否かを判定する(ステップS64)。性能データ表155のパケット転送レート1554が、閾値のパケット転送レート1544以上であれば、タスク生成制御部152は、タスク生成処理を終了する。
これにより、CPUリソースやI/Oリソースの利用が十分であると判断されれば新たなタスクは生成されず、計算機100の利用が不十分であると判定された場合にタスク生成が行われる。
最後に、タスク生成制御部152は、上限タスク数と現在のタスク数を比較し(ステップS65)、タスク数が上限タスク数以上の場合は、タスク生成処理を終了する。一方、タスク数が上限タスク数よりも小さい場合に、タスク生成制御部152は、初期状態のタスクを生成する(ステップS66)。
以上の処理により、上限タスク数以上のタスクが生成されるのを防いでいる。なお、図29では、CPUリソースの利用とI/Oリソースの利用の双方をチェックしているが、I/Oリソースの利用状況のチェックだけでもよい。または、CPUリソースの利用状況のチェックだけでもよい。また、I/Oリソースの利用状況のチェックには、IOPSだけを対象にしてもよく、あるいは、ディスク転送速度だけを対象にしてもよく、パケット転送レートだけを指標にしてもよい。また、これらの性能データを組合せたものと、閾値を比較するようにしてもよい。
図30は、実施例1に係る記憶領域性能データ表157の一例を示す図である。
記憶領域性能データ表157は、記憶領域#1〜#4間のI/Oリソースの利用状況の偏りの有無を判定するために、記憶領域ごとのI/Oリソースの利用状況の指標を保持する。記憶領域性能データ表157は、記憶領域名1571と、指標1572と、値1573からエントリが構成される。指標1572としては、例えば、発行中のI/O要求数であるアウトスタンディングI/O数1574と、ディスク転送速度1575と、IOPS1576とを保持する。これらの値は、図28に示した性能データ表155と同じ方法によって設定される。
図31は、実施例1に係るコンテキスト取得処理のフローチャートである。この処理は、図23のステップS21で行われる処理である。
実施例1のコンテキスト取得処理では、I/Oリソースの利用に記憶領域#1〜#4間で偏りがある場合に、クエリ実行部144のコンテキスト管理部153は空いている記憶領域を優先的に利用するようにコンテキストを選択する。これにより、空いている記憶領域#1〜#4を活用するタスクを生成させることができる。図31の例では、I/Oリソースの利用状況を示す指標に、図30に示したアウトスタンディングI/O数1574を用いる。しかし、図30に示したディスク転送速度1575やIOPS1576を指標にしてI/Oリソースの利用状況を判定しても良い。
まず、コンテキスト管理部153は記憶領域性能データ表157を参照し、アウトスタンディングI/O数1574が最も小さい記憶領域名1571を選択する(ステップS71)。
コンテキスト管理部153は、ステップS71で選択した記憶領域名1571がI/O要求を発行する記憶領域となっているコンテキスト1530を、処理ステップの番号の大きい順に検索する(ステップS72)。コンテキスト管理部153は、自身が管理するコンテキスト1530の中から検索し、該当するコンテキスト1530が存在する場合は、コンテキスト取得処理を終了する(ステップS73)。
一方、コンテキスト管理部153は、該当するコンテキスト1530が存在しない場合は、その他の記憶領域にI/O要求を発行するコンテキスト1530を、処理ステップ番号の大きいものから順に検索する(ステップS74)。
これにより、クエリ実行部144のコンテキスト管理部153は、I/Oリソースの利用が少ない記憶領域名1571にI/O要求を発行するコンテキストが優先的に選択される。この結果、クエリ実行部144は、I/Oリソースの利用が少ない記憶領域にI/O要求を発行するタスクを生成することができる。
本発明を用いない従来例の場合は、図18に示したコンテキスト1530が生成される。そして、コンテキスト1530の未処理データリスト1562の順にタスクを生成するため、RowID(P22,1)、RowID(P23,4)、RowID(P24,2)と記憶領域#1にI/O要求を行うタスクを生成する。
これに対して、本実施例1では、図30に示した記憶領域性能データ表157からアウトスタンディングI/O数1574が小さい記憶領域名1571を選択し、選択した記憶領域名1571にI/O要求を発行するコンテキスト1530を選択してタスクを生成する。このため、クエリ実行部144は、全ての記憶領域#1〜#4に均等にI/O要求を発行するタスクを生成することが可能となる。
具体的には、既に既存のタスクが、図7で示したRowID(P21,2)にI/O要求を発行しているため,新規タスクが追加された際にはRowID(P120,1)、RowID(P220,2)、RowID(P321、4)という順にタスクを生成する。つまり、従来技術では記憶領域#1に偏ってI/O要求が発行されていたのに対し、本実施例では4つの記憶領域#1〜#4へ均等にI/O要求を発行することが可能となるのである。
以上の処理により、タスクを動的に生成するDBMS140では、CPUリソースやI/Oリソースの利用状況がシステム性能閾値表154の閾値以内でタスクを生成することが可能となる。また、DBMS140がタスクを生成する際には、利用が不十分なリソースを優先して利用するタスクを生成することにより、CPUリソースやI/Oリソースの利用率を向上させることが可能となる。これにより、特定のリソースに処理が偏るのを防いで、DBMS141の処理能力を向上させることが可能となるのである。
以下、実施例2を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
図32は、実施例2に係る記憶領域性能閾値表154Aの一例を示す図である。
記憶領域性能閾値表154Aは、記憶領域ごとに性能が十分であると判定するために性能の閾値を保持している。これら閾値の設定は、前記実施例1の図27に示したシステム性能閾値表154の閾値の設定と同様の手法にて設定するのでも良い。
記憶領域性能閾値表154Aは、記憶領域名1541Aと、項目1542Aと、値1543Aからエントリが構成される。そして、項目1542Aとしては、例えば、ディスク転送速度1544Aの閾値と、IOPS1545Aの閾値とを保持する。
図33は、実施例2に係るコンテキスト取得処理のフローチャートである。この処理は、実施例1の図23のステップS21で行われる処理である。
クエリ実行部144のコンテキスト管理部153は、図33Aの記憶領域性能閾値表154Aのディスク転送速度(閾値)1544AとIOPS1545A(閾値)を指標とする。コンテキスト管理部153は、ディスク転送速度を指標としたI/Oリソースの利用率であるディスク転送利用率と、IOPSを指標にしたI/Oリソースの利用率であるIOPS利用率を計算する(ステップS81)。ここで、ディスク転送利用率は、前記実施例1の図28に示した性能データ表155のディスク転送速度1552を、図32に示した記憶領域性能閾値表154Aの記憶領域名1541A毎のディスク転送速度(閾値)1542で割った値である。また、IOPS利用率は、前記実施例1の図28に示した性能データ表155のIOPS1553を、システム性能閾値表154のIOPS1543で割った値である。
コンテキスト管理部153は、ディスク転送利用率とIOPS利用率を比較する(ステップS82)。ディスク転送利用率の方が大きければ、ディスク転送速度がI/O性能の決定要因であるためステップS83に進み、コンテキスト管理部153は、記憶領域#1〜#4ごとにディスク転送利用率を計算する(ステップS83)。
そして、コンテキスト管理部153は、ディスク転送利用率が最も小さい記憶領域を選択する(ステップS84)。
一方、ステップS82の判定で、IOPS利用率の方が大きければ、IOPSがI/O性能を決定する要因であるため、コンテキスト管理部153は、記憶領域#1〜#4ごとにIOPS利用率を計算し(ステップS85)、IOPS利用率が最も小さい記憶領域を選択する(ステップS86)。
コンテキスト管理部153は、ステップS84またはステップS86で選択した記憶領域にI/O要求を出すコンテキストを処理ステップの大きい順に検索し(ステップS87)、該当するコンテキストが存在すれば、そのコンテキストを選択する(ステップS88)。
一方、ステップS88でコンテキストが見つからない場合、コンテキスト管理部153は、ステップS84またはステップS86で選択された記憶領域以外で処理ステップの大きい順にコンテキストを選択する(ステップS89)。
これにより、実施例2では、記憶領域#1〜#4ごとに設定された閾値によりI/Oリソースの利用率を計算し、前記I/Oリソースの利用率の低い記憶領域#1〜#4にI/O要求を発行するタスクを生成することができる。
以下、実施例3を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
図34は、実施例3に係るDB206の第二のクエリの一例を示す図である。
図34に示すクエリは、Part表2051(カラムc1、c2)及びLineitem表2054(カラムc3、c4)から、カラムc1の値が"130"であり、且つカラムc4の値が"z"であり、且つカラムc2の値とカラムc3の値とが同じであるものについて、カラムc1の値とカラムc4の値とを抽出することを意味している。
図35は、実施例3に係るクエリ実行プランの一例を説明する図である。
図35に示すクエリ実行プランは、DBMS141が、図34に示したクエリを受け付けた場合に、クエリ実行プラン生成部143により生成されるクエリ実行プランの一例を示している。
図34に示したクエリに対応するクエリ実行プランは、図35に示すように、DBMS141がLineitem表2054の全てのDB206のページを読込んで、条件に合致したレコードを取得するテーブルスキャンを行う処理ステップ#1と、Part索引2041による索引検索を行う処理ステップ#2と、Part表2051からレコードを取得する処理ステップ#3と、Lineitem表2054から読み込んだデータと、Part表2051から読み込んだデータをハッシュ結合する処理ステップ#4と、これらの結果をネストループ結合する処理ステップ#5とを含む。なお、図35のクエリ実行プランでは、Lineitem表2054のデータをBuild側とし、Part表2051のデータをProbe側とする。
図36は、実施例3に係る処理ステップ毎にCPUコストを設定したコストテーブル1431の一例を示す図である。
処理ステップにおけるCPUコストは、図12で説明したCPUコストと同様の方法にて取得するのでもよい。図示のコストテーブル1431では、前記実施例1の図12と同様にCPUコストが設定され、処理ステップ#4については、上述のBuild側と、Probe側のCPUコストがそれぞれ設定される。
実施例3では、図35に示したクエリ実行プランで生成される3種類のコンテキストを想定する。なお本実施例のテーブルスキャン(処理ステップ#1)では、64個のDBページを一つの管理領域として管理し、16個のDBページで1個のI/O要求とすることを想定する。なお、管理するページ数は他の管理単位であってもよく、I/O要求する際のページ数は他の値でも良い。
図37は、実施例3に係る第5コンテキスト1530−5の一例を示す図である。
第5のコンテキストは、処理ステップ#1のテーブルスキャンでI/O要求を発行するタスクを生成するためのコンテキストである。I/O要求は16個のページ(4KB/ページ)を連続して読むため、I/Oサイズ1536は64KBとなる。また、上述のように、64個のDBページで一つの管理領域となるため、コンテキスト1530−5では4個のタスクが生成可能となる。このため、生成可能数1533には"4"が設定される。
I/Oパターン1537は、DBMS141が連続してDB206のページを読み込むため、シーケンシャルとする。CPUコスト1538は、処理ステップ#1の後に処理ステップ#4のBuild処理を行うため、図36のコストテーブル1431より10+10=20を設定する。なお、中間結果1532や実行状態1534に関しては、実施例1と同様に設定すればよいので、ここでは説明を省略する。
図38は、実施例3に係る第6のコンテキスト1530−6の一例を示す図である。
第6のコンテキスト1530−6は、処理ステップ#1のテーブルスキャンでI/O要求を伴わないタスクを生成するためのコンテキストである。これらのタスクは第5のコンテキスト1530−5から生成されたタスクがI/O要求を完了した後に生成するコンテキスト1530−6で、このコンテキスト1530−6がある限りはDBMS141が読み込んだDB206のページはメモリ140に保持しておく。
例えば、16個のDBページに161レコード格納されている場合は、生成可能数1533に160を設定する。本タスクはI/O要求を伴わないので、記憶領域名1535は"なし"、I/Oサイズ1536は"0"、I/Oパターン1537は"なし"を設定する。CPUコスト1538は、第5のコンテキスト1530−5と同様に"20"を設定する。
図39は、実施例3に係る第7のコンテキスト1530−7の一例を示す図である。
第7のコンテキスト1530−7は、処理ステップ#2で生成されるランダムなI/O要求を行うタスクを生成するコンテキストである。これは、実施例1のコンテキスト1530−1と同様のため、説明は省略する。
図40は、実施例3に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例1の図23のステップS21で行われる処理である。
クエリ実行部144のコンテキスト管理部153は、前記実施例2と同様にして、ディスク転送利用率とIOPS利用率を計算し、利用率が大きい方をI/Oリソース利用率とする(ステップS91)。ディスク転送利用率と、IOPS利用率は、実施例2のステップS81の方法と同じでよい。また、コンテキスト管理部153は、CPU利用率を算出する。ここで、CPU利用率は、前記実施例1の図28に示した性能データ表155のCPU利用率1551を、図27に示したシステム性能閾値表154のCPU利用率1541で割った値である。
コンテキスト管理部153は、I/Oリソース利用率とディスク転送利用率を比較し(ステップS92)、I/Oリソース利用率が低ければ、I/Oリソース利用率を高める必要があると判断し、処理ステップ番号の大きい順にI/Oを行うコンテキストから優先的に検索する(ステップS93)。例えば、第5のコンテキスト1530−5と第6のコンテキスト1530−6と第7のコンテキスト1530−7が存在している状況では、第5のコンテキスト1530−5が選択される。
一方、コンテキスト管理部153は、I/Oリソース利用率が高ければ、I/Oリソース利用率を高める必要がないと判定し、処理ステップ番号の大きい順に、I/Oを行わないコンテキストを優先的に選択する(ステップS94)。例えば、第5のコンテキスト1530−5と第6のコンテキスト1530−6と第7のコンテキスト1530−7が存在している状況では、第6のコンテキスト1530−6が選ばれる。
なお、実施例3ではI/Oリソースの利用率が低いことを、CPU利用率とI/Oリソース利用率を比較することで判断したが、これ以外の方法で判断してもよい。例えば、外部からI/Oリソース利用率が高いと判断できる値を設定してもよい。
これにより、実施例3では、I/Oリソースの利用が低い場合には、I/Oリソースの利用率の高いコンテキストを選択することで、I/Oリソースの利用率の高いタスクを生成することができる。一方、I/Oリソースの利用が高い場合には、I/Oリソースの利用率が低いコンテキストを選択することで、I/Oリソースの利用率の低いタスクを生成することができる。
以下、実施例4を説明する。その際、実施例3との相違点を主に説明し、実施例3との共通点については説明を省略或いは簡略する。
図41は、実施例4に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例1の図23のステップS21で行われる処理である。
クエリ実行部144のコンテキスト管理部153は、前記実施例2と同様にして、ディスク転送利用率とIOPS利用率を計算し、利用率が大きい方をI/Oリソース利用率とする(ステップS101)。ディスク転送利用率とIOPS利用率は、ステップS81の方法と同じでよい。また、コンテキスト管理部153は、前記実施例3と同様にしてCPU利用率を演算する。
コンテキスト管理部153は、I/Oリソース利用率とCPU利用率を比較し(ステップS102)、CPU利用率が高ければ、CPU利用率を高める必要がないと判定し、処理ステップ番号の大きい順にCPUコストが小さいコンテキストから優先的に選択する(ステップS103)。例えば、第5のコンテキスト1530−5と第6のコンテキスト1530−6と第7のコンテキスト1530−7が存在している状況では、第5のコンテキスト1530−5または第6のコンテキスト1530−6が選ばれる。
一方、コンテキスト管理部153は、CPU利用率が低ければ、CPU利用率を高める必要があると判断し、処理ステップ番号の大きい順に、CPUコストが大きいコンテキストから優先的に選択する(ステップS104)。例えば、第5のコンテキスト1530−5と第6のコンテキスト1530−6と第7のコンテキスト1530−7が存在している状況では、第7のコンテキスト1530−7が選択される。
なお、実施例4ではCPUリソースの利用率(CPU利用率)が低いことを、CPU利用率とI/Oリソース利用率を比較することで判定したが、これ以外の方法で判定してもよい。例えば、外部からCPU利用率が高いと判定できる値を設定してもよい。あるいは、予め設定したCPU利用率の閾値と、CPU利用率を比較しても良い。
これにより、実施例4では、CPUリソースの利用率が低い場合には、CPUコストの高いコンテキストを選択することで、CPUリソースをより利用するタスクを生成することができる。なお、DBMS141は、CPU利用率が低いときには、コストテーブル1431を参照して最もCPUコスト1433が大きい処理ステップ1432のタスクを生成し、CPUコスト1433が高いときには、コストテーブル1431を参照して最もCPUコスト1433が小さい処理ステップ1432のタスクを生成するようにしても良い。
なお、実施例3および実施例4においては、I/OリソースとCPUリソースのどちらかで空いているリソースを利用するコンテキストを選択したが、メモリリソースと比較してもよい。具体的には、I/Oリソースの利用率とメモリリソースの利用率を比較して、メモリリソースが空いているかどうかを判定し、メモリリソースが空いていればメモリリソースをより多く利用するコンテキストを選択してもよい。また、CPUリソースの利用率とメモリリソースの利用率を比較して、メモリリソースが空いているかどうかを判定し、メモリリソースが空いていればメモリリソースをより多く利用するコンテキストを選択してもよい。
以下、実施例5を説明する。その際、実施例3との相違点を主に説明し、実施例3との共通点については説明を省略或いは簡略する。
図42は、実施例5に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例1の図23のステップS21で行われる処理である。
クエリ実行部144のコンテキスト管理部153は、前記実施例2と同様にして、ディスク転送利用率とIOPS利用率を計算する(ステップS111)。ディスク転送利用率とIOPS利用率は、ステップS81の方法と同じでよい。
コンテキスト管理部153は、ディスク転送利用利率とIOPS利用率を比較し(ステップS112)、ディスク転送利用率が高い場合は、I/Oパターンがシーケンシャルのコンテキストを、処理ステップ番号の大きい順に検索する(ステップS113)。例えば、第5のコンテキスト1530−5と第7のコンテキスト1530−7がある状況では、第5のコンテキスト1530−5が選択される。コンテキスト管理部153は、コンテキストが取得できれば終了する(ステップS114)。
コンテキストが取得できない場合、コンテキスト管理部153は、I/Oパターン1537がランダムのコンテキストを、処理ステップ番号の大きい順に検索する(ステップS115)。例えば、第5のコンテキスト1530−5と第7のコンテキスト1530−7がある状況では、第7のコンテキスト1530−7が選択される。
一方、コンテキスト管理部153は、ディスク転送利用利率とIOPS利用率を比較し(ステップS112)、IOPS利用率が高い場合は、I/Oパターン1537がランダムのコンテキストを、処理ステップ番号の大きい順に検索する(ステップS116)。コンテキスト管理部153はコンテキストを取得すれば処理を終了する(ステップS117)。
コンテキストを取得できない場合、コンテキスト管理部153は、I/Oパターン1537がシーケンシャルのコンテキストを、処理ステップ番号の大きい順に検索する(ステップS118)。
なお、実施例5では、現在のI/Oパターンを判定するのにディスク転送利用率とIOPS利用率を比較することで判断している。つまり、ディスク転送利用率が高い場合はシーケンシャルであり、IOPS利用率が高い場合はランダムである。この他の方法を用いてI/Oパターンを判断してもよい。例えば、一定数のI/Oパターンの履歴をDBMSが保持しておき、I/Oパターンを判断するのでもよい。OSがI/Oパターンを判定し、DBMS141が前記結果を参照するのでもよい。
これにより、実施例5では、I/Oパターンに応じて同じI/Oパターンを行うコンテキストを選択し、同じI/Oパターンを行うタスクを生成することができる。
以下、実施例6を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
図43は、実施例6に係る計算機システムの構成を示すブロック図である。
実施例6は複数の計算機100−1〜100−4で動作するDBMS141−1〜141−4が協調して処理を行うデータベース管理システムの一例を示す。
図43では、4台の計算機(計算機1、計算機2、計算機3、計算機4)100−1〜100−4でデータベース管理システムが構成される例を示す。4台の計算機100−1〜100−4はネットワーク300で接続されている。
各計算機100−1〜100−4は外部ストレージ装置200−1〜200−4をそれぞれ有しており、計算機100−1〜100−4と外部ストレージ装置200−1〜200−4はネットワークによって接続されている。計算機1(100−1)が接続している外部ストレージ装置200−1は記憶領域#1を含み、計算機2(100−2)と接続している外部ストレージ装置200−2は記憶領域#2を含み、計算機3(100−3)と接続している外部ストレージ装置200−3は記憶領域#3を含み、計算機4(100−4)と接続している外部ストレージ装置200−3は記憶領域#4を含む。なお、図43では独立した外部ストレージ装置200−1〜200−4で構成された例を示すが、複数の計算機100−1〜100−4でひとつの外部ストレージ装置200を共有しても良い。この場合、共有される外部ストレージ装置200内には、独立した記憶領域#1〜#4があれば良い。なお、計算機100−1〜100−4、DBMS141−1〜141−4、外部ストレージ装置200−1〜200−4は、それぞれ前記実施例1の計算機100、DBMS141及び外部ストレージ装置200と同様の構成である。
図44は、実施例6に係るDB領域管理表147Aの一例を示す図である。実施例6のDB領域管理表147Aは、前記実施例1の図10に示したDB領域管理表147にDBMS識別子1474を加えた点が、前記実施例1のDB領域管理表147と相違し、その他は、同様の構成である。
複数の計算機100−1〜100−4が協調して処理を行うDBMS140−1〜140−4では、記憶領域#1〜#4ごとにアクセスするDBMS140−1〜140−4が決定される。このため、DB領域管理表147Aは、DBオブジェクト1471、ページ番号1472、記憶領域名1473に、DBMS識別子1474を追加したものである。DBMS識別子1474はDBMS140−1〜140−4を識別するための情報で、本識別子により、いずれの計算機100−1〜100−4上で動作しているのかも特定可能である。
図45は、実施例6に係る第8のコンテキスト1530−8の一例を示す図である。
独立した外部ストレージ装置200−1〜200−4を有する複数の計算機100−1〜100−4が、協調して処理を行うデータベース管理システムでは、タスクを処理可能なDBMS140−1〜140−4が限られるため、コンテキスト1530−8に処理を実行するDBMSを設定するDBMS識別子1563を加える。
図45は前記実施例1の第8のコンテキスト1530−8を、複数の計算機100−1〜100−4が協調して処理を行うデータベース管理システムで処理する場合の例である。記憶領域#1にI/O要求を発行するタスクは、計算機100−1のDBMS1でのみ処理可能なため、DBMS識別子1563には"DBMS1"を設定する。
図46は、実施例6に係る第9のコンテキスト1530−9の一例を示す図である。
図46は前記実施例1に示した第9のコンテキスト1530−9を複数の計算機100−1〜100−4が協調して処理を行うデータベース管理システムで処理する場合の例である。
独立した外部ストレージ装置200−1〜200−4を有する複数の計算機100−1〜100−4が、協調して処理を行うデータベース管理システムでは、タスクを処理可能なDBMS140−1〜140−4が限られる。
このため、第9のコンテキスト1530−9には、処理を実行するDBMS140−1〜140−4を設定するDBMS識別子1563を加える。図示の例では、記憶領域#2にI/O要求を発行するタスクは、計算機100−2で実行されるDBMS2でのみ処理可能なため、DBMS識別子1563には"DBMS2"を設定する。
図47は、実施例6に係るタスク実行処理の一例を示すフローチャートである。この処理は、前記実施例1の図22のステップS17において、新たなタスクに対して行われる処理で、複数の計算機100−1〜100−4が協調して処理を行うデータベース管理システムに適用される。
タスク実行処理は、クエリ実行部144が、処理の決まっていない新規のタスクを実行する際に適用される。処理が決まっていない新規タスクを生成して処理を開始する。新規タスクの処理を決めるために、コンテキスト取得処理を行う(ステップS121)。コンテキスト取得処理の内容は、後述する図48で説明する。
クエリ実行部144は、取得したコンテキストのDBMS識別子1563を判定し、現在処理しているDBMS140−1〜140−4の識別子と比較する(ステップS122)。例えば、このタスク実行処理をDBMS1(140−1)で処理しており、図45に示した第8のコンテキスト1530−8を取得した場合は、コンテキスト1530−8のDBMS識別子1563と自DBMSのDBMS識別子が同じとなる。この場合、ステップS122の判定結果は"真"となって、ステップS123の処理へ進む。一方、図46の第9のコンテキスト1530−9を取得した場合は、コンテキストのDBMS識別子1563と自DBMSのDBMS識別子が異なる。この場合、ステップS122の判定結果は"偽"となって、ステップS125の処理へ進む。
コンテキスト1530のDBMS識別子1563と自DBMSのDBMS識別子が同じ場合、クエリ実行部144は、タスクの実行状態情報を設定する(ステップS123)。この処理は、図23のステップS22と同様に、クエリ実行部144が、取得したコンテキストを使ってタスクの実行状態情報73(図13参照)を設定する。
そして、クエリ実行部144は、処理ステップ実行処理を行う(ステップS124)。この処理は、前記実施例1に示した図23のステップS22と同様であり、クエリ実行部144は、ステップS123で設定された状態に従い、処理ステップ実行処理を実行する。
コンテキストのDBMS識別子1563と自DBMSのDBMS識別子が異なる場合は、タスクを実行させるために入手したコンテキストを、コンテキストのDBMS識別子1563のDBMS140−1〜140−4へネットワーク300を介して送信する(ステップS125)。このコンテキストは、送信されたDBMS140−1〜140−4上で再びコンテキスト管理部153に登録され、送信されたDBMS140−1〜140−4上でコンテキストからタスクを生成し、タスクを実行する。
図48は、実施例6に係るコンテキスト取得処理の一例を示すフローチャートである。
複数の計算機100−1〜100−4が協調して処理を行うデータベース管理システムでは、システム性能閾値表154(図27参照)のパケット転送レート1544と性能データ表155(図28参照)のパケット転送レート1554に値が設定される。
クエリ実行部144は、システム性能閾値表154のパケット転送レート1544と、性能データ表155のパケット転送レート1554を比較し(ステップS131)、性能データ表155のパケット転送レート1554が小さい場合は、処理ステップ番号の大きい順に、自DBMS識別子と異なるDBMS識別子1563のコンテキストを優先的に選択する(ステップS132)。
一方、性能データ表155のパケット転送レート1554が小さい場合は、処理ステップ番号の大きい順に、自DBMS識別子と同じDBMS識別子1563のコンテキストから優先的に選択する(ステップS133)。
これにより、実施例6では、計算機100−1〜100−4間のデータ転送に関するI/Oリソースであるネットワークリソースの利用が低い場合に、ネットワークリソースをより多く使うタスクを生成することができる。
以上、実施例1から実施例6を説明したが、各実施例では1つの指標においてタスクを選択してきた。実際は1つの指標だけでなく複数の指標を混ぜてタスクを選択することで、CPUリソースやI/Oリソース、メモリリソースを活用することも可能である。例えば、メモリの使用率が指定された閾値より小さい場合に、新たなタスクを生成するといったことも可能である。さらに、タスクを生成する際には、メモリの使用率に応じてタスクを生成する。指定されたメモリ使用率より小さい場合はメモリリソースの利用が大きいタスクを生成し、指定されたメモリ使用率より大きい場合はメモリリソースの利用が小さいタスクを生成したりする。
上記実施例1から実施例6では、一つのAP148が一つのDBMS141で一つのクエリを実行する場合について説明したが、AP148が複数であってもよく、DBMS141が複数であってもよく、クエリが複数であってもよい。
また、DBMS141がクエリを複数実行する場合は、トランザクションIDやユーザID,スキーマIDなどでコンテキストを識別でき、クエリの優先度に応じてタスクを生成する順番を変更してもよい。DBMS141が複数稼働する場合は、DBMS141の識別子でコンテキストを識別し、DBMS141の優先度に応じてタスクを生成する順序を変えてもよい。また、仮想マシンにより複数のDBMS141を実行する場合は、仮想マシンの識別子でコンテキストを識別し、仮想マシンの優先度に応じてタスクを生成する順番を変えてもよい。
以下、実施例7を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
図49は、実施例7に係る計算機システムの構成を示すブロック図である。
アプリケーションサーバ(以下、APサーバ)4902は、DBMS141が稼働する計算機(以下、DBサーバ)100に、通信ネットワーク4912を介して通信できるように接続されている。また、DBサーバ100は、外部ストレージ装置200に、通信ネットワーク300を介して通信できるように接続されている。
ユーザ端末(クライアント端末)4901は、APサーバ4902に、通信ネットワーク4911を介して通信できるように接続されている。DBサーバ100は、前記実施例1に示したDB206を管理するDBMS141を実行する。外部ストレージ装置200は、DB206を格納する。APサーバ4902は、DBサーバ100で実行されるDBMS141に対してクエリを発行するAPを実行する。ユーザ端末4901は、APサーバ4902で実行されるAPに要求を出す。なお、ユーザ端末4901、又は、APサーバ4902は、複数存在しても良い。
APサーバ管理端末4903は、通信ネットワーク4914を介してAPサーバ4902に接続されている。DBサーバ管理端末4904は、通信ネットワーク4915を介してDBサーバ100に接続されている。ストレージ管理端末4905は、通信ネットワーク4916を介して外部ストレージ装置200に接続されている。APサーバ管理端末4903は、APサーバ4902を管理する端末である。DBサーバ管理端末4904は、DBサーバ100を管理する端末である。ストレージ管理端末4905は、外部ストレージ装置200を管理する端末である。DBサーバ管理者又はユーザは、DBサーバ管理端末4904から、DBMS141に関する設定を行っても良い。なお、管理端末4903〜4905のうちの少なくとも二つが共通(一体)であっても良い。また、通信ネットワーク4911、4912、4914、4915、4916、及び300のうちの少なくとも二つが共通(一体)であっても良い。
実施例7では、例えば、下記の通り処理が実行される。
ステップS141では、ユーザ端末4901は、APサーバ4902に要求(以下、ユーザ要求)を発行する。
ステップS142では、APサーバ4902が、ステップS141で受信したユーザ要求に従いクエリを生成する。そして、生成したクエリをDBサーバ100に発行する。
ステップS143では、DBサーバ100は、APサーバ4902からのクエリを受け付け、受け付けたクエリを実行する。DBサーバ100は、受け付けたクエリの実行において必要なデータの入出力要求(例えば、データの読出し要求)を外部ストレージ装置200に発行する。DBサーバ100は、一つのクエリの実行において、複数のデータ入出力要求を並行して発行することがある。そのため、DBサーバ100は、一つのクエリの実行において、ステップS143の要求を複数回並行して行うことがある。
ステップS144では、外部ストレージ装置200は、S143で発行されたデータ入出力要求について、DBサーバ100に応答する。外部ストレージ装置200は、S144の応答を複数回並行して行うことがある。
ステップS145では、DBサーバ100は、クエリの実行結果を生成し、APサーバ4902に送信する。
ステップS146では、APサーバ4902は、クエリの実行結果を受信する。そして、該実行結果に従う、S141で受信したユーザ要求に対する回答を、ユーザ端末4901に送信する。
なお、APサーバ4902に発行されるユーザ要求、又は、DBサーバ100へ発行されるクエリは、同時に複数あっても良い。
以上のように、実施例7では、APサーバ4902をDBサーバ100から分離した構成であっても、本発明を適用することができる。
なお、本発明において説明した計算機等の構成、処理部及び処理手段等は、それらの一部又は全部を、専用のハードウェアによって実現してもよい。
また、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体(例えば、非一時的な記憶媒体)に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。
また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
Claims (15)
- ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、
前記データベースへのクエリを受け付けるクエリ受付部と、
前記受け付けたクエリを実行するために必要な1以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成するクエリ実行プラン生成部と、
前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部と、
を有し、
前記クエリ実行部は、
受け付けたクエリの実行に利用されるリソースの利用状況を取得し、
前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、前記リソースの利用状況に基づいて新たなタスクを生成し、
当該新たなタスクを前記生成されたタスクと並列して実行する、ことを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況としてI/Oリソースの利用状況を用い、
前記I/Oリソースの利用状況として、前記ストレージ装置からの、若しくは前記ストレージ装置へのデータ転送量、又は、前記ストレージ装置へのI/O要求数を取得し、前記データ転送量、又は、前記I/O要求数に基づいて新たなタスクを生成する、ことを特徴とするデータベース管理装置。 - 請求項2に記載のデータベース管理装置であって、
前記I/O要求数は、前記ストレージ装置に発行される前記ストレージ装置からの入力要求数であることを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況としてCPUリソースの利用状況を用い、
前記CPUリソースの利用状況としてCPU利用率を取得し、前記CPU利用率に基づいて新たなタスクを生成する、ことを特徴とするデータベース管理装置。 - 請求項2に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記データ転送量が予め設定されたデータ転送量閾値よりも小さく、かつ、前記I/O要求数が予め設定されたI/O要求数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。 - 請求項5に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況として前記I/Oリソースに加えてCPUリソースの利用状況を用い、
前記CPUリソースの利用状況としてCPU利用率を取得し、
前記CPU利用率が予め設定されたCPU利用率閾値よりも小さく、かつ、前記データ転送量が前記データ転送量閾値よりも小さく、かつ、前記I/O要求数が前記I/O要求数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記新たなタスクを生成する際には、前記リソースの利用状況が所定の閾値未満となる空きリソースを利用するタスクを、分類されたタスクから選択し、生成することを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況としてI/Oリソースの利用状況を用い、
前記I/Oリソースの利用状況として、前記ストレージ装置における前記データベースが分割して配置された記憶領域ごとのI/O要求数を取得し、前記I/O要求数が最小の記憶領域に分割して配置された前記データベースのデータに対するI/O要求を発行するタスクを生成することを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況としてI/Oリソースの利用率と、CPU利用率を取得し、前記I/Oリソースの利用率が前記CPU利用率よりも低い場合には、前記I/Oリソースを利用するタスクを生成し、前記I/Oリソースの利用率が前記CPU利用率よりも高い場合には、前記データベース管理装置のプロセッサを利用するタスクを生成することを特徴とするデータベース管理装置。 - 請求項4記載のデータベース管理装置であって、
前記クエリ実行プラン生成部は、
処理ステップごとのCPUコストを予め設定したコスト情報を保持し、
前記クエリ実行部は、
当該CPU利用率と予め設定した閾値とを比較して、前記CPU利用率が前記閾値未満の場合には、前記コスト情報を参照してCPUコストが大きい処理ステップを実行するためのタスクを生成し、前記CPU利用率が前記閾値以上の場合には、前記コスト情報を参照してCPUコストが小さい処理ステップを実行するためのタスクを生成することを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記クエリ実行部は、
前記リソースの利用状況としてI/Oリソースの利用状況を用い、
前記I/Oリソースの利用状況として、I/Oパターンを識別し、前記新たなタスクは、前記取得したI/Oパターンと同一のI/Oパターンであることを特徴とするデータベース管理装置。 - 請求項1に記載のデータベース管理装置であって、
前記データベース管理装置は、ネットワークを介して他の計算機に接続され、
前記クエリ実行部は、
前記リソースの利用状況としてI/Oリソースの利用状況を用い、
前記I/Oリソースの利用状況として、前記他の計算機と送受信するパケット数である転送パケット数を取得し、
前記転送パケット数が予め設定された転送パケット数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。 - 計算機がストレージ装置に格納されたデータベースを管理するデータベース管理方法であって、
前記計算機が、前記データベースへのクエリを受け付ける第1のステップと、
前記計算機が、前記受け付けたクエリを実行するために必要な1以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成する第2のステップと、
前記計算機が、前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成する第3のステップと、
前記計算機が、前記動的に生成されたタスクを実行する第4のステップと、
を含み、
前記第3のステップは、
受け付けたクエリの実行に利用されるリソースの利用状況を取得し、
前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、前記リソースの利用状況に基づいて新たなタスクを生成し、
前記第4のステップは、
前記新たなタスクを前記生成されたタスクと並列して実行することを特徴とするデータベース管理方法。 - 請求項13に記載のデータベース管理方法であって、
前記第3のステップは、
前記リソースの利用状況としてI/Oリソースの利用状況を用い、
前記I/Oリソースの利用状況として、前記ストレージ装置からの、若しくは前記ストレージ装置へのデータ転送量と、前記ストレージ装置へのI/O要求数と、を取得するステップと、
前記データ転送量が予め設定されたデータ転送量閾値よりも小さく、かつ、前記I/O要求数が予め設定されたI/O要求数閾値よりも小さい場合に前記新たなタスクを生成するステップと、
を含むことを特徴とするデータベース管理方法。 - 計算機でストレージ装置に格納されたデータベースを管理するプログラムを格納した記憶媒体であって、
前記データベースへのクエリを受け付ける第1のステップと、
前記受け付けたクエリを実行するために必要な1以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成する第2のステップと、
前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成する第3のステップと、
前記動的に生成されたタスクを実行する第4のステップと、
を前記計算機に実行させるプログラムを格納した非一時的な計算機読み取り可能な記憶媒体であって、
前記第3のステップは、
受け付けたクエリの実行に利用されるリソースの利用状況を取得して、前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、
前記第4のステップは、
前記新たなタスクを前記生成されたタスクと並列して実行することを特徴とする記憶媒体。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2013/073271 WO2015029208A1 (ja) | 2013-08-30 | 2013-08-30 | データベース管理装置、データベース管理方法及び記憶媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5950267B2 JP5950267B2 (ja) | 2016-07-13 |
JPWO2015029208A1 true JPWO2015029208A1 (ja) | 2017-03-02 |
Family
ID=52585824
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015533885A Active JP5950267B2 (ja) | 2013-08-30 | 2013-08-30 | データベース管理装置、データベース管理方法及び記憶媒体 |
Country Status (3)
Country | Link |
---|---|
US (1) | US10515078B2 (ja) |
JP (1) | JP5950267B2 (ja) |
WO (1) | WO2015029208A1 (ja) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6245700B2 (ja) * | 2014-04-11 | 2017-12-13 | 国立大学法人 東京大学 | 計算機システム、データの検査方法及び計算機 |
US20160259825A1 (en) * | 2015-03-06 | 2016-09-08 | Dell Products L.P. | Discovery of potential problematic execution plans in a bind-sensitive query statement |
JP6690829B2 (ja) * | 2015-08-28 | 2020-04-28 | 国立大学法人 東京大学 | 計算機システム、省電力化方法及び計算機 |
JP6531587B2 (ja) * | 2015-09-16 | 2019-06-19 | 富士通株式会社 | データベースシステム、データベースアクセス方法、データベースアクセスプログラム、及び、情報処理装置 |
US10956294B2 (en) * | 2017-09-15 | 2021-03-23 | Samsung Electronics Co., Ltd. | Methods and systems for testing storage devices via a representative I/O generator |
JP7485934B2 (ja) | 2020-06-30 | 2024-05-17 | 富士通株式会社 | 情報処理プログラム、情報処理装置及び情報処理方法 |
US12045235B2 (en) * | 2020-12-14 | 2024-07-23 | International Business Machines Corporation | Access path for database optimizer |
JP2022107451A (ja) * | 2021-01-08 | 2022-07-21 | 富士通株式会社 | 情報処理装置、情報処理システム及び帯域制御方法 |
CN113282571A (zh) * | 2021-05-26 | 2021-08-20 | 北京金山云网络技术有限公司 | 数据转移方法、装置、电子设备和存储介质 |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6108653A (en) * | 1998-08-31 | 2000-08-22 | Platinum Technology Ip, Inc. | Method and apparatus for fast and comprehensive DBMS analysis |
US20050131893A1 (en) * | 2003-12-15 | 2005-06-16 | Sap Aktiengesellschaft | Database early parallelism method and system |
JP4611830B2 (ja) | 2005-07-22 | 2011-01-12 | 優 喜連川 | データベース管理システム及び方法 |
US20090043728A1 (en) * | 2007-08-07 | 2009-02-12 | Barsness Eric L | Query Optimization in a Parallel Computer System to Reduce Network Traffic |
US20090043745A1 (en) * | 2007-08-07 | 2009-02-12 | Eric L Barsness | Query Execution and Optimization with Autonomic Error Recovery from Network Failures in a Parallel Computer System with Multiple Networks |
US7885969B2 (en) * | 2007-09-17 | 2011-02-08 | International Business Machines Corporation | System and method for executing compute-intensive database user-defined programs on an attached high-performance parallel computer |
US20090327216A1 (en) * | 2008-06-30 | 2009-12-31 | Teradata Us, Inc. | Dynamic run-time optimization using automated system regulation for a parallel query optimizer |
US8775413B2 (en) * | 2008-06-30 | 2014-07-08 | Teradata Us, Inc. | Parallel, in-line, query capture database for real-time logging, monitoring and optimizer feedback |
US8447754B2 (en) * | 2010-04-19 | 2013-05-21 | Salesforce.Com, Inc. | Methods and systems for optimizing queries in a multi-tenant store |
US9613092B2 (en) * | 2010-12-31 | 2017-04-04 | Microsoft Technology Licensing, Llc | Allocation of tenants to database services |
JP5098120B2 (ja) * | 2011-10-12 | 2012-12-12 | 株式会社日立製作所 | 計算機システム及びデータベース管理システムプログラム |
US9317552B2 (en) * | 2012-01-30 | 2016-04-19 | Memsql, Inc. | Reusing existing query plans in a database system |
US9280583B2 (en) * | 2012-11-30 | 2016-03-08 | International Business Machines Corporation | Scalable multi-query optimization for SPARQL |
US9639573B2 (en) * | 2013-07-22 | 2017-05-02 | Mastercard International Incorporated | Systems and methods for query queue optimization |
-
2013
- 2013-08-30 JP JP2015533885A patent/JP5950267B2/ja active Active
- 2013-08-30 WO PCT/JP2013/073271 patent/WO2015029208A1/ja active Application Filing
- 2013-08-30 US US14/905,017 patent/US10515078B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
WO2015029208A1 (ja) | 2015-03-05 |
JP5950267B2 (ja) | 2016-07-13 |
US20160154848A1 (en) | 2016-06-02 |
US10515078B2 (en) | 2019-12-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5950267B2 (ja) | データベース管理装置、データベース管理方法及び記憶媒体 | |
US11860874B2 (en) | Multi-partitioning data for combination operations | |
US11151137B2 (en) | Multi-partition operation in combination operations | |
WO2020220216A1 (en) | Search time estimate in data intake and query system | |
US9990265B2 (en) | Diagnosing causes of performance issues of virtual machines | |
JP4659888B2 (ja) | データベース処理システム、計算機及びデータベース処理方法 | |
US8856079B1 (en) | Application programming interface for efficient object information gathering and listing | |
US20190392047A1 (en) | Multi-table partitions in a key-value database | |
US11636107B2 (en) | Database management system, computer, and database management method | |
US11630695B1 (en) | Dynamic reassignment in a search and indexing system | |
US11693710B1 (en) | Workload pool hierarchy for a search and indexing system | |
WO2015118865A1 (ja) | 情報処理装置、情報処理システム及びデータアクセス方法 | |
CN113474764A (zh) | 共享数据库对象上的流 | |
US9646048B2 (en) | Declarative partitioning for data collection queries | |
US12007997B2 (en) | Metadata search via N-gram index | |
US11188228B1 (en) | Graphing transaction operations for transaction compliance analysis | |
JP6108418B2 (ja) | データベース管理システム、計算機、データベース管理方法 | |
US9870152B2 (en) | Management system and management method for managing data units constituting schemas of a database | |
US11947537B1 (en) | Automatic index management for a non-relational database | |
JP7068210B2 (ja) | データベース管理システム、端末装置及び方法 | |
CN113297226A (zh) | 数据存储方法、数据读取方法、装置、电子设备及介质 | |
US11586608B1 (en) | Handling requests to access separately stored items in a non-relational database | |
Dory | Study and Comparison of Elastic Cloud Databases: Myth or Reality? |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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: 20160510 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160530 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5950267 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |