以下、図面を用いて本発明の実施例を説明する。なお、本発明が本実施例に限定されるものではない。
図1は、本発明を実現する計算機システムの全体構成を示すブロック図である。計算機システムは大きく、データベースに処理を要求するクライアント100と、データの管理を行うデータベースサーバ200と、データベース処理を高速化する高速化装置1000およびこれらを接続するネットワーク300で構成される。
クライアント100は、プロセッサ101とメモリ102と通信処理部120を含む計算機で、メモリ02にはデータベースへの処理を依頼するアプリケーション110がロードされてプロセッサ101によって実行される。アプリケーション110は、データベースサーバ200のベンダが提供する独自のインタフェースや、アプリケーションの実装言語に用意されたデータベースアクセスインタフェースを利用して、データベースサーバ200に対してデータ処理を依頼する。本実施例1では、アプリケーション110が要求した処理は通信処理部120からネットワーク300及び高速化装置1000を介して、データベースサーバ200に通知される。
データベースサーバ200は、プロセッサ201と、メモリ202とデータ蓄積部210と通信処理部230を含む計算機である。メモリ202には、処理制御部220がロードされてプロセッサ201によって実行される。
データベースサーバ200は、クライアント100からの処理要求を受け取り、処理制御部220がHDDやSSDなどで構成されるデータ蓄積部210に格納されたデータ(テーブル240)の読み込み、書き込み、演算を実行してその処理結果を応答する。
データベースサーバ200の処理制御部220は、具体的にはOracle(登録商標) DatabaseやPostgreSQLなどのDBMS(DataBase Management System)に相当する。
本実施例1は、クライアント100とデータベースサーバ200の通信を、高速化装置1000を介して行うことで実現する。高速化装置1000は、クライアント100からの処理要求を解析してデータベースサーバ200で実行していた処理を高速に実行し、クライアント100が要求した処理の応答時間の削減を実現する。
高速化装置1000は、プロセッサ1001と、メモリ1002と、クライアント100およびデータベースサーバ200と通信するための通信処理部1100を有し、クライアント100からの処理要求の内容を解析してその処理方法を判断して変更する変換処理部1200と、特定した処理をGPU(Graphics Processing Unit)やFPGA(field-programmable gate array)等のハードウェアアクセラレータで高速に処理する機能を含む処理高速化部1500を有する。
変換処理部1200の各機能部はプログラムとしてメモリ1002にロードされる。プロセッサ1001は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ1001は、変換処理プログラムに従って処理することで変換処理部1200として機能する。他のプログラムについても同様である。さらに、プロセッサ1001は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
変換処理部1200の各機能を実現するプログラム、テーブル等の情報は、ストレージサブシステムや不揮発性半導体メモリ、ハードディスクドライブ、SSD(Solid State Drive)等の記憶デバイス、または、ICカード、SDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
クライアント100と、データベースサーバ200と、高速化装置1000は、それぞれネットワーク300を介して通信する。ネットワーク300は、ひとつの機器内のシステムバスなどの内部ネットワークであってもよいし、インターネットなどの広域ネットワークであってもよい。
以下、具体例として、クライアント100からデータベースサーバ200への処理要求としてSQLを含む場合の処理高速化方法について以下に説明する。これは本発明の実施例が、データベースサーバ200がSQLを処理するリレーショナルデータベースであることを限定するものではない。
図2は本実施例における高速化装置1000の機能の詳細を示すブロック図である。変換処理部1200はクライアント100との通信を処理するクライアント通信処理部1210と、データベースサーバ200との通信を処理するデータベース通信部1220と、クライアント100からの処理要求の内容を解析し、高速化処理の要否を判断して実行する高速処理制御部1230と、処理高速化部1500に処理を依頼してその処理結果を受け取る高速化処理管理部1240を有し、高速処理制御部1230が高速化処理の要否判断時に参照する適用条件1250と変換定義1260を保持する。
高速処理制御部1230は、クライアント100から受け取った処理要求から式や関数を検出し、それらが高速化可能かどうか判断する。ここで、式とは例えばSQLであればjoinやorder byなどのデータベースに対するデータ操作要求、またはテーブル、カラム、値そのものなどの処理実行時に参照する情報全般のことである。
処理高速化部1500は、指定された処理を実行する処理実行部1510と変換処理部1200から指示される高速化処理を管理する登録処理管理部1520を有する。
図3は、適用条件1250の一実施例を示す。図4は、変換定義1260の一実施例を示す。
適用条件1250には、高速処理変換対象 となる式や関数と、その対象が通知された際に高速化可否を判断するための条件を高速化装置1000のユーザ(または管理者)が登録する。図3の例では、適用条件1250は変換対象処理1251と、適用条件の項目1252と、適用条件の値1253がひとつのエントリに含まれる。
図4の変換定義1260は、変換対象処理1261と、クライアント100から通知された処理要求(本実施例1ではSQL文)のSQL変換方法1262と、処理高速化部1500で実際に実行する処理の名称を格納する高速化処理1263と、この処理高速化部1500に通知するデータフォーマットを設定するデータ構造1264と、処理高速化部1500から受け取るデータフォーマットを設定するデータ構造1265とを、高速化装置1000のユーザ(または管理者)が予め登録しておく。
変換定義1260は、処理高速化部1500へのデータの入出力フォーマットの変換定義(データ構造など)を含み、変換処理部1200は、変換定義1260に従って、データベースサーバ200からデータを変換して処理高速化部1500へ入力する。また、変換処理部1200は、処理高速化部1500の出力を変換定義1260に従って処理結果に変換する。
これらの情報を使って、高速化装置1000はデータベースサーバ200で実行される処理の高速化可否を判断し、高速化が可能であれば、実際に処理高速化部1500で処理を実行して処理結果をクライアント100に応答する。この具体的な処理の一例をアクティビティ図で表現したものが図5である。以下、例としてクライアント100が適用条件1250を満たした「select funcA(c1,c2,c3) from tableD」という「funcA」が含まれるSQL文を通知した際に実行する変換定義について述べる。
クライアント100はデータベースサーバ200で処理したい内容、本実施例1では「select funcA(c1,c2,c3) from tableD」を高速化装置1000に通知する。この処理要求を受け取った高速化装置1000のクライアント通信処理部11210は、変換処理部1200に受け取った処理要求を通知し、変換処理部1200の高速処理制御部1230は処理要求に含まれるSQL文を解析する(ステップS1000)。
クライアント通信処理部1210から処理要求に含まれるSQL文字列を受け取った高速処理制御部1230は、SQL文から式および関数を検出して、funcAが利用されていること、tableDのc1、c2、c3のカラムをfuncAの引数として利用することなどを検出する。
高速処理制御部1230は、検出した処理要求の内容を元に、適用条件1250を検索する(ステップS1100)。高速処理制御部1230は、適用条件1250の変換対象処理1251のうち、処理要求の内容が一致するエントリを判定する。高速処理制御部1230は、適用条件1250には処理要求の内容「funcA」に関する条件として「tableD」を利用しているエントリが登録されており、本実施例1のSQL文はこの適用条件1250を満たし、処理高速化部1500で処理を実行することが有効と判定する。
なお、実装上は登録される変換対象処理1251の数は変換定義1260の方が適用条件1250よりも少なくなることが予想されるため、変換定義1260を検索して対象処理の有無を判定してもよい。
上記判定の結果、高速処理制御部1230は、処理高速化部1500を使用して処理を高速化できると判定し、変換定義1260を参照して受け付けたSQL文を処理高速化部1500へ入力可能なデータ構造に変換する(ステップS1200〜ステップS1600)。
まず、高速処理制御部1230は、変換定義1260を参照して、検出した内容が変換対象処理1261に存在するか否かを判定する。本実施例1ではSQL文中の「funcA」が変換対象処理1261に含まれるため、該当するSQL変換方法1262を参照する。具体的な変換定義は、図5では「SQL変換方法」(1262)の欄に定義されており、SQL変換方法1262には各カラムを取得すると定義されている。この場合、高速処理制御部1230は、変換定義1260に基づいて処理対象のデータを特定するが、これに限定されるものではなく、処理要求に含まれるSQL文などから処理対象のデータを特定してもよい。
高速処理制御部1230は、変換定義1260に基づいて処理要求を、データが格納されているテーブル「tableD」の「c1」、「c2」、「c3」の各カラムのみをデータベースサーバ200から取得する処理(データ取得要求)に変換する。つまり、高速処理制御部1230は、クライアント100から受け付けた処理要求を、c1カラムをデータベースサーバ200から取得するために「select c1 from tableD」というデータ取得要求に変換して(ステップS1200)、データベースサーバ200から処理対象のカラムのみを取得する(ステップS1300)。
高速処理制御部1230は、カラムc2、c3についても同様に処理要求を、データ取得要求に変換してデータベースサーバ200に処理対象のデータを要求し、データベースサーバ200からの処理結果を保持する。このように、変換処理部1200は、データベースサーバ200のテーブル240から処理に必要なデータのみを取得する内容に変換することで、高速化装置1000の利用時に発生するテーブル240のデータ取得処理のオーバーヘッドを削減する。すなわち、変換処理部1200は、処理対象のテーブル240を全て読み込むのではなく、処理対象のカラムのみをテーブル240から読み込むことでデータ取得処理に要する時間を低減する。
高速処理制御部1230は、上記のようにデータベースサーバ200から取得したデータを、「処理高速化部に通知するデータ構造」(1264)に定義されているデータ構造に変換して図示しない入力領域(例えば、キュー)に格納する。
本実施例1の場合、高速処理制御部1230は、カラムc1の1行目の情報を8bit幅で入力領域に格納し、その直後にカラムc2の1行目の情報を2bit幅で格納し、その後にカラムc3の1行目の情報を2bit幅で入力領域に格納する。その後、高速処理制御部1230は、4bitの空白領域を設けた上で、同様にカラムc1、c2、c3の2行目の情報、次に3行目の情報と、順次の読み込んだデータを指定された形式で入力領域に格納する。
こうして変換定義1260に基づいて所定の入力フォーマットに変換したデータを入力として、高速化処理管理部1240は処理高速化部1500に「funcA.img」の実行を指令する(ステップS1400)。「funcA.img」が実際に利用可能かは登録処理管理部1520が判定する。なお、高速化処理管理部1240は、処理高速化部1500の「funcA.img」が利用不可の場合はエラーを返すなどして処理を中断する。
処理高速化部1500に依頼した処理の結果は、「処理高速化部からの応答」(1265)に定義されているデータ構造(出力フォーマット)で出力される。高速化処理管理部1240は、通知された出力を高速処理制御部1230に渡す。
高速処理制御部1230は処理高速化部1500の処理結果を、「処理高速化部からの応答」(1265)のデータ構造から、アプリケーション110への応答として適した形式のデータに変換して(ステップS1600)、データベースサーバ200からの処理結果としてクライアント100に返す(ステップS1800)。
高速化処理を具体的に実行するGPUやFPGAなどの処理高速化部1500を実現するハードウェアのアクセラレータは、データ操作の読み書きは数バイト単位でしか実行できないという制約が存在する。さらに、そのハードウェアで処理する高速化処理の実装に応じたデータの送受信を行う必要がある。このデータ送受信時のデータ構造を変換定義1260のように用意しておくことで、処理高速化部1500の性能を引き出せるデータ送受信方法を明確にでき、高速処理制御部1230が処理高速化部1500を最適に扱えるようになる。
また、変換定義1260として送受信(または入出力)用のデータ定義(1264、1265)を用意することで、高速処理制御部1230と処理高速化部1500間のデータ送受信処理をフレームワーク化した汎用的な仕組みを構築できる。
なお、処理高速化部1500の入出力に利用するデータ構造を本実施例1のように定義するのではなく、「SQL変換方法」(1262)欄の具体的な変換処理方法内容に含めてしまってもよい。また、実際の実装ではテーブル240から取得するカラムのデータ型(Integer、Long、Stringなど)によっても、利用する処理高速化部1500の高速化処理1263や、高速化処理1263と変換処理部1200の間で入出力するデータ構造が異なる場合がある。
変換対象処理1261で利用される引数の種類に応じた高速化処理1263および入出力のデータ構造(1264、1265)がある場合は、それに応じた内容を変換定義1260Bに定義してもよい。実際のデータ構造(1264、1265)の定義は、例えばC言語の構造体定義のように定義し、プログラムとして参照または利用できる形式で格納することができる。
なお、適用条件1250でクライアント100を判定した際に条件を満たさない場合はクライアント100から要求されたSQL文をそのままデータベースサーバ200に通知し、その処理結果を取得する(ステップS1700)。そしてその結果をアプリケーション110に返す(ステップS1800)。
このように、クライアント100から通知された処理要求のうち、適用条件1250を満たす処理要求を変換処理部1200でデータを取得する要求に変換して、処理に必要な情報だけをデータベースサーバ200から取得し、高速化装置1000で特定の処理を高速実行できる処理高速化部1500にてデータベースサーバ200に代わって処理を実行する。
本実施例1の高速化装置1000により、データベースサーバ200で実行していた処理を高速化でき、処理高速化部1500で実行する処理数が増えれば増えるほど、データベースサーバ200で処理をするよりもより高速に結果を応答することができる。
図6は、第2の実施例を示し、計算機システムの機能の一例を示すブロック図である。実施例2は、前記図2に示した高速化装置1000の変換処理部1200に、ハードウェアコンフィグレーション1268や処理時間などの情報が加わった変換定義1260Bとし、補足情報1270を加えたもので、その他の構成は前記実施例1と同様である。
補足情報1270は、計算機システムに固定的な情報や、計算機システムを実環境にデプロイした際に明確になる情報を記録する。例えば、クライアント100、データベースサーバ200、高速化装置1000が利用できるネットワーク300の通信帯域や通信速度、データベースサーバ200内に格納されたテーブル240のサイズやデータ量のようなほぼ更新が不要な情報などの、静的あるいはほぼ静的な情報などを保持する。これらの情報は動的に取得することも可能であるが、このように別途情報を保持することで問い合わせ処理を削減することができる。
図7は変換定義1260Bの一例を示す図である。変換定義1260Bは、前記実施例1の図4に示した変換定義1260に、登録時間1266と処理時間算出式1267を追加したものであり、その他の構成は前記実施例1と同様である。
変換定義1260Bには、高速化処理を実際に処理高速化部1500で利用できるよう準備するための時間(登録時間1266)、実際に処理高速化部1500で実行する処理に要する時間を算出するための処理時間算出式1267の情報を保持する。なお、他のデータ入出力のデータ構造(1264、1265)などの情報は前記実施例1の変換定義1260と同様であり、図7では図示を省略している。
また、前記実施例1の変換定義1260では変換処理部1200から通知された高速化処理の存在を判定するのみであったが、本実施例2では、変換処理部1200から処理高速化部1500に処理を依頼した高速化処理1263が処理高速化部1500に存在しない場合は、変換処理部1200はハードウェアコンフィグレーション1268から高速化処理1263のイメージ(または設定)を読み込んで新規に処理高速化部1500に登録する。
処理高速化部1500に高速化処理1263を登録処理に要する処理時間が、変換定義1260Bの「登録時間」(1266)に相当する。処理高速化部1500側では登録処理管理部1520が、変換処理部1200の高速化処理管理部1240から通知される高速化処理1263の情報を管理し、必要に応じて登録済み処理(1263)の更新を実施する。
また登録処理管理部1520は、変換処理部1200からの要求に応じて処理実行部1510で実行する内容も制御する。この機能により、変換処理部1200から複数の処理が依頼されても、処理高速化部1500では登録した高速化処理を切り替えて稼働させることができる。なお、処理高速化部1500に登録する高速化処理は高速化装置1000内部で管理しているものだけでなく、ネットワーク300を介して取得できるものでもよい。
本実施例2では、クライアント100からの処理要求で適用条件1250の条件を満たすものについて、データベースサーバ200で実行する場合と高速化装置1000で実行する場合の処理時間を予測し、予測処理時間が短い方で処理を実行する。
このため、基本的な処理のアクティビティ図は前記実施例1の図5の通りであるが、図5に示したステップS1100の「変換条件判定」において、予測処理時間に応じた分岐が生じる点で異なる。図8は、予測処理時間を活用する本実施例2の高速化装置1000で行われる処理の一例を示すアクティビティ図である。
以下の例では、高速化装置1000がクライアント100から「select funcA(t1, t2, t3) from t」というSQL文を含む処理要求を受け取った場合について、前記実施例1と異なる部分の処理について説明する。
クライアント100から要求された処理を解析して適用条件1250を検索した結果、変換処理部1200は変換対象処理1261に登録されている「funcA」を検出する(ステップS1110)。
図3に示した適用条件1250には2つの条件があり、このSQLは「処理コストが5000以上」という条件に一致する可能性がある。このため、変換処理部1200は処理コストを算出する。
ここで、「処理コスト」はデータベースサーバ200が事前に見積もる処理量(または処理量相当値)である。データベースサーバ200の処理制御部220として機能する各種DBMSには、通知されたSQL文に対して実際にDBMS内部で実行する処理計画とその予測処理量を予測した値を返す機能がある。「処理コスト」とは、この予測処理量のことである。
変換処理部1200は、データベースサーバ200に処理コストを問い合わせるため、クライアント100から受け取ったSQL文字列をデータベース通信部1220からデータベースサーバ200に通知する。本実施例2では、SQLの処理コストが5000を越えているものとする。各DBMS(処理制御部220)から取得できる処理コストは予測処理時間とは異なるものであるが、その数値は処理時間とある程度の相関関係がある。この処理コストから予測処理時間を算出するためのパラメータを補足情報1270に記憶しておき、変換処理部1200はこの情報を使ってデータベースサーバ200で処理要求を実行した場合の予測処理時間を算出する。
一方、変換処理部1200は、データベースサーバ200との予測処理時間を比較するために、高速化装置1000の処理高速化部1500を利用した時の予測処理時間も算出する必要がある。
高速化装置1000で処理を実行した場合、図8のステップS1200からS1600の実行時間がかかるため、これらの処理時間を予測する。本実施例2のSQLでは、まずテーブルt(240)からt1、t2、t3の各カラムを取得する。この処理に要する時間は各カラムのデータ量およびデータベースサーバ200と高速化装置1000間でのデータ転送速度から算出できる。取得対象カラムのデータ量は、変換処理部1200がデータベースサーバ200に問い合わせる、あるいは事前に補足情報1270に登録しておいたものを利用する。
データベースサーバ200と高速化装置1000間でのデータ転送速度についても同様である。これらの値を使い、変換処理部1200ではステップS1300の予測処理時間が算出できる。ステップS1400およびステップS1600の処理に必要な予測処理時間は、高速処理制御部1230から高速化処理管理部1240を介して処理高速化部1500にデータを転送する、あるいはその逆方向の通信時間とほぼ等しい。
このため、変換処理部1200は、ステップS1300で取得した処理対象のデータ量と、変換定義1260Bで定義される処理結果を格納するデータ構造と、変換処理部1200と処理高速化部1500の間のデータ転送速度から算出できる。なお、データ転送速度は動的に判定、または補足情報1270に事前に登録したものを参照して取得することができる。ステップS1500の処理時間は、変換処理部1200が処理回数の情報と変換定義1260Bの処理時間算出式を使って取得できる(ステップS1150)。
こうして、変換処理部1200はデータベースサーバ200での予測処理時間と、高速化装置1000での予測処理時間が得られるため、これらを比較し、より短い時間で処理を実行できる方を選択する。
変換処理部1200では、データベースサーバ200での処理が速い場合(予測処理時間が高速化装置1000より小)は、データベースサーバ200で処理要求を実行させ(ステップS1700)、高速化装置1000での処理が速い場合(予測処理時間がデータベースサーバ200より小)は実施例1の場合と同様に高速化装置1000で処理要求を実行して(ステップS1200〜ステップS1600)、最後にアプリケーションに結果を返す(ステップS1800)。
上記処理により、クライアント100から要求された処理の内容に応じて、高速化装置1000では処理時間の短い装置(処理高速化部1500またはデータベースサーバ200)を選択して処理要求を実行することで処理を高速化することができる。
なお、本実施例2では、クライアント100から受け付けた処理要求が、適用条件1250を満たし、かつ、予測処理時間が高速化装置1000の短いときに処理高速化部1500で処理要求を実行するので、処理時間を最小にすることが可能となる。
図9は、第3の実施例を示し、計算機システムの機能の一例を示すブロック図である。本実施例3の構成は前記実施例2の高速化装置1000に統計情報1280が追加されており、統計情報を使って高速化処理の利用判断をより的確に行う。その他の構成については前記実施例2と同様である。
図10は統計情報1280の一例を示す図である。統計情報1280は、変換対象処理1281と、処理高速化1282と、変換対象処理が参照する情報1283と、予測コスト1284と、予測処理時間1285と、処理回数1286と、実処理時間1287とをひとつのエントリに含む。
変換対象処理1281は、処理高速化部1500で実行する処理(関数や命令)を格納する。処理高速化1282は、当該エントリの処理で処理高速化部1500を使用したか否かが格納される。変換対象処理が参照する情報(処理対象情報)1283には、変換対象処理1281で使用するテーブル240とカラムなどが格納される。
予測コスト1284には、処理対象情報1283で変換対象処理1281の処理をデータベースサーバ200で実行した場合の処理コストが格納される。この予測コスト1284には、変換処理部1200がデータベースサーバ200に問い合わせた処理コストが格納される。
予測処理時間1285には、前記実施例2と同様に、処理対象情報1283について変換対象処理1281の処理を処理高速化部1500で実行する場合の時間を変換処理部1200で見積もった値が格納される。
処理回数1286には、処理高速化部1500が処理対象情報1283を処理するのに必要な処理回数が格納される。この処理回数1286は、変換処理部1200が処理高速化部1500に処理を実行させた回数を格納することができる。実処理時間1287には、処理高速化部1500が処理対象情報1283を処理した時間が格納される。
なお、処理高速化1282で「未使用」の場合には、高速化装置1000の外部となるデータベースサーバ200で処理要求を実行させたことを示す。一方、処理高速化1282が「使用」の場合には、処理高速化部1500で処理要求を実行させたことを示す。
図10の例では、変換対象処理1281を実際に高速化装置1000で実行したか(1282)、その変換対象処理が参照していた情報(1283)は何か、予測コスト1284および予測処理時間1285、変換対象処理の処理回数1286、実際にかかった処理時間1287を記録している。その他、実際に処理したカラム数やデータ転送に要した時間など、変換対象処理1281に直接関与しない情報も蓄積してもよい。
図11に本実施例3における高速化装置1000で行われる処理の一例を示すアクティビティ図を示す。図11の処理は前記実施例2に示した図8にステップS1900の処理を加え、ステップS1150の処理で統計情報1280を用いる点が前記実施例2と相違する。その他の構成は前記実施例2と同様である。
ステップS1150では、変換処理部1200が前記実施例2と同様に予測処理時間を算出するのに加え、予測処理時間の算出時に統計情報1280の実処理時間1287を参照して、より的確な予測処理時間を算出する(ステップS1150)。そして、処理結果をアプリケーションに返した後(ステップS1800)、実際に実施した際に得られた情報(処理回数1286や実処理時間1287)を統計情報1280に追加する(ステップS1900)。なお、変換処理部1200は、統計情報1280の実処理時間1287の平均値などから予測処理時間を算出してもよい。この場合、処理要求に含まれる変換対象処理1281について平均値を算出して、予測処理時間とすればよい。あるいは、前記実施例2と同様に算出した予測処理時間を、実処理時間1287の平均値などで補正してもよい。
なお、統計情報1280は処理を実行する度に増加していく情報であるため、予測処理時間の算出時(ステップS1150)において、その情報全てを参照して利用すると処理時間がかかることが予想される。この問題を回避するため、予測処理時間の算出時に利用する統計情報を、統計情報更新時(ステップS1900)に補足情報1270に記録しておいてもよい。
さらに、変換処理部1200は、得られた統計情報1280を元に、適用条件1250を更新してもよい。この更新処理により、ユーザが適用条件1250としてかなり幅を有する設定をしている場合や、誤った設定をしている場合でも、適切に高速な処理を選択できるようになる。また、統計情報の収集は、クライアント100からの処理要求に応じて実行するだけでなく、高速化装置1000が独自に処理を実行して収集してもよい。
また、高速化装置1000は統計情報1280を保持しているため、計算機システム全体として稼働率が低い時間帯を特定することができる。稼働率が低い時間帯に統計情報1280を取得する処理を実行することで、計算機システム全体に与える影響を抑えながら情報取得することができる。
図12は、第4の実施例を示し、計算機システムの機能の一例を示すブロック図である。本実施例4は、高速化装置1000がデータベースサーバ200に論理的に内包されている例を示す。本実施例4では、前記実施例3の構成に加えて、データベースサーバ200と高速化装置1000がインターコネクト350を介して接続され、さらに、データベースサーバ200の処理制御部220には、実行計画構築部221と、処理実行部222と、データ操作部223が含まれる。その他の構成については前記実施例3と同様である。インターコネクト350は、例えば、PCIexpressで構成され、変換処理部1200は、インターコネクト350を介してテーブル240のデータを読み込む。
本実施例4では、クライアント100からの処理要求は直接データベースサーバ200に通知され、データベースサーバ200の処理制御部220が必要に応じて高速化装置1000を利用する。このため、データベースサーバ200内部の処理制御部220が高速化装置1000と直接通信を行う。この通信は、ネットワーク300を経由してもよいし、インターコネクト350を経由してもよい。
通常のデータベース処理では、クライアント100から処理要求を受け取ったデータベースサーバ200は、処理制御部220内の実行計画構築部221が処理要求の内容を解析して実行計画を生成する。そして、処理実行部222が実行計画を実施してデータ操作部223にデータアクセスを指示して処理を実現する。
本実施例4で行われる処理の一例を示すアクティビティ図を図13に示す。処理の内容は、前記実施例1〜3と同様であるがデータベースサーバ200から高速化装置1000を呼び出す部分が前記実施例1と異なる。
まず、クライアント100から処理要求を受け取ったデータベースサーバ200は、処理制御部220の実行計画構築部221で、処理要求の実行計画を生成し、処理コストを算出する(ステップS2000)。
実行計画結果と処理コストの演算結果を入力として、処理実行部222が高速化装置1000に処理高速化の可否判定を依頼する(ステップS1100)。高速化装置1000では前記実施例2、3と同様にして、データベースサーバ200での予測処理時間と、高速化装置1000での予測処理時間を算出し、予測処理時間が短い装置を選択する。
データベースサーバ200の予測処理時間が短い(高速化できないまたはオリジナル処理の方が速い)場合には、処理実行部222で処理を行う(ステップS2700)。
一方、高速化装置1000の予測処理時間が短い場合には、実行計画構築部221で生成した実行計画を処理実行部222で変更し(ステップS1200)、処理高速化部1500に提供するデータの取得をデータ操作部223に依頼する(ステップS2300)。高速化装置1000の変換処理部1200は、インターコネクト350を介してデータを取得し、処理高速化部1500で対象の処理を実行する(ステップS1500)。変換処理部1200は、処理高速化部1500からの処理結果からアプリケーションに返すデータを生成し(ステップS1600)、データベースサーバ200の処理実行部222に転送し、処理要求の発行元のクライアント100へ処理の結果を応答する(ステップS1800)。
本実施例4のように高速化装置1000をデータベースサーバ200から利用する構成の場合、データベースサーバ200への依存性は高まる。しかし、処理実行部222を入れ替え可能なモジュール構成にすれば、実施例1から3と同等の可搬性を確保することができる。また、データベースサーバ200と高速化装置1000を同一機器内に構築する場合、本構成にすることでデータベースサーバ200から高速化装置1000間でのデータ送受信の時間を大幅に削減できるため、処理性能を大きく向上させることができる。
図14は、第5の実施例を示し、暗号データ検索システムの機能の一例を示すブロック図である。本実施例5は、前記実施例1から実施例4で説明したデータベースを高速化する計算機システムを具体的に利用した例として、検索可能暗号を利用した暗号データ検索システムについて説明する。
検索可能暗号とは、暗号化されたデータを復号せずに検索を可能にする技術である。この技術を利用してデータを暗号化することで、クラウドやデータセンタなどのユーザが直接管理していない外部のデータ蓄積場所を利用しても、データを漏洩させずに検索できる。
なお、本実施例5の暗号データに対する検索処理は、複合はできないが検索可能な鍵を使用する。例えば、トラップドアと呼ばれる特殊な演算を実行するなど、利用する検索可能暗号アルゴリズムに応じた演算を実施することで実現される。本実施例5では、暗号データの検索処理に検索鍵を使用する例について説明する。これらの検索鍵やトラップドアを用いた検索処理では複雑な演算が実行される。また、検索対象が大量になればなるほど、この独自演算の回数が増加するため、より高速に処理することが求められる。
図14は、前記実施例1から実施例4の構成に加え、具体的に暗号処理を実行するためにクライアント100に暗号処理部130と、処理高速化部1500内部に検索可能暗号で暗号化されたデータを検索するための暗号データ検索処理1530が追加されている。 暗号処理部130で平文と暗号文の変換を実施するため、図14の暗号データ検索システムでは、この暗号処理部130より上部は平文が利用できるセキュアな領域であり、これより下部は暗号データしか利用しない非セキュアな領域となる。暗号化や複合化に必要な暗号鍵400は暗号処理部130内に保管されており、データベースサーバ200及び暗号データ検索処理1530には検索時に利用する検索鍵410が格納される。暗号鍵400及び検索鍵410は、クライアント100が指定する暗号化対象に応じて複数存在してもよい。例えば、カラム毎に異なる検索鍵410を使用するように設定することもできる。
本暗号データ検索システムにおける、初期化、データ追加、データ検索の処理の一例を示すシーケンス図を図15に示す。
初期化は、クライアント100がユーザから指示を受け付けて、高速化装置1000を介してデータベースサーバ200にデータ格納場所の準備を実施させる。SQLの場合であれば、CREATE TABLEを使ってカラム及び格納するデータ型の指示をする等の処理を実行する(ステップS200〜S220)。
次に、クライアント100は、暗号データを検索するための処理と、暗号データの検索処理で利用する検索鍵410と、暗号データの検索処理を利用する対象カラムや検索鍵410とデータベースサーバ200のテーブル240及びカラムを対応付ける情報と、暗号データ検索処理の実行に必要な予測処理時間などの情報の登録を高速化装置1000に指示する(ステップS230)。
高速化装置1000はクライアント100から受け取った情報のうち、検索要処理と、検索処理で利用する検索鍵410をデータベースサーバ200に登録する指示を送出し、登録の指示を受け付けたデータベースサーバ200は、受け付けた情報を登録する(ステップS240、S250)。
次に、高速化装置1000は検索要処理と、利用する検索鍵410と、検索鍵410に対応付けられた情報とを、適用条件1250と、変換定義1260及び1260B、補足情報1270及び統計情報1280に登録し、検索処理の構成を変換処理部1200のハードウェアコンフィグレーション1268または処理高速化部1500に登録する(ステップS230)。データベースサーバ200は、データ格納場所(テーブル240)の初期化後に、クライアント100から受け付けた暗号データ及び検索鍵410を登録する(ステップS250)。
クライアント100は、まず、データベースサーバ200へ格納するデータを検索可能暗号で暗号化し、このデータをデータベースサーバ200に登録あるいは更新する(ステップS300〜S330)。初期化及びデータ登録の処理において、テーブル初期化(ステップS200)と検索用処理と検索鍵410の登録(ステップS250)、暗号データ登録(ステップS310)の処理は、高速化装置1000を介さず、クライアント100が直接データベースサーバ200に処理を依頼してもよい。あるいは、必ず高速化装置1000を利用する場合には、検索用処理と検索鍵410の登録処理(ステップS250)は実行しなくてもよい。
また、本実施例5では初期化処理の一部として変換対象処理の登録を実施したが(ステップS230〜S260)、これらの処理は高速化装置1000として最初に受け付ける検索処理を実行する前までに実行すればよい。
暗号データを検索する一連の手順がステップS400台の処理である。ここでは、高速化装置1000の処理高速化部1500を呼び出す場合の手順を例として説明する。まず、クライアント100はユーザからの指示を受けて、暗号処理部130でデータベースサーバ200のテーブル240に格納された暗号データを検索するための検索クエリを生成する(ステップS400)。クライアント100は、生成した検索クエリを使って、初期化時に登録した検索処理を呼び出すSQLを生成して高速化装置1000に処理を依頼する(ステップS410)。
処理要求を受けた高速化装置1000は、依頼された内容を解析して処理高速化を進める(ステップS420)。まず、高速化装置1000は、データベースサーバ200から処理対象の暗号データを取得する指示を送出し(ステップS430)、処理対象のデータを取得する(S440)。
処理高速化部1500や変換処理部1200に、処理高速化部1500で高速実行する処理が未登録であれば、この処理対象データの取得時にデータベースサーバ200から検索処理に必要なデータを取得してもよい。
取得した暗号データに対して、処理高速化部1500に登録した検索可能暗号の検索処理を適切な検索鍵410を用いて実行し、処理対象データの検索を処理高速化部1500のハードウェアで高速に実行する(ステップS450)。なお、変換処理部1200は、データベースサーバ200から取得した暗号データと、当該暗号データに対応する検索鍵410を処理高速化部1500へ入力して検索要求を実行させる。
高速化装置1000は暗号データの検索結果を処理高速化部1500から受け付けて、この検索結果をクライアント100に応答する。検索要求の結果を受信したクライアントは暗号データを復号し、アプリケーション110で処理を実行してユーザに応答を返す(ステップS460)。
本実施例5では検索可能暗号のデータ検索処理に適用した例を説明した。検索以外にも、暗号データを復号することなく処理する(演算する、分析するなど)様々な暗号技術が提案されている。これらの暗号技術に対しても、各実施例の計算機システムを適用することができる。
同様に、機械学習などの大量データに対して複雑な演算を実施するシステムに適応可能である。具体的には暗号データ検索(ステップS450)の処理を、実際に適用する計算機システムに応じた処理に変更することで、本実施例5の構成で処理高速化を実現することができる。
<まとめ>
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上記実施例1〜5は、以下のような構成とすることもできる。
16.
15に記載のデータ処理方法であって、
前記第3のステップは、
前記処理高速化部で実行する場合の予測処理時間を、前記処理要求の内容に応じて予め設定した算出式に基づいて算出するステップと、
前記処理要求を外部で実行する場合の予測処理時間を、前記処理要求の実行にかかる処理時間相当値を問い合わせ、前記処理時間相当値から前記予測処理時間を算出するステップと、
を含むことを特徴とするデータ処理方法。
17.
15に記載のデータ処理方法であって、
前記第3のステップは、
前記処理要求毎に、前記処理高速化部で実行した処理時間と、前記処理要求を外部に実行させた処理時間を、統計情報に格納し、前記処理高速化部または外部で実行する処理要求の予測処理時間を前記統計情報に基づいて算出することを特徴とすることを特徴とするデータ処理方法。
18.
14に記載のデータ処理方法であって、
前記データは、検索可能な暗号データで構成され、
前記第3のステップは、
前記データ取得要求に対するデータと、予め設定された検索鍵とを前記処理高速化部へ入力して処理要求を実行させることを特徴とすることを特徴とするデータ処理方法。