(57)【特許請求の範囲】
【請求項１】
検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備えたデータ検索システムであって、
上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、
上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、データベースサーバに発行する処理と、
データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、
各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、
データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とするデータ検索システム。
【請求項２】
上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項１に記載のデータ検索システム。
【請求項３】
上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項１に記載のデータ検索システム。
【請求項４】
コンピュータを、
検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部として機能させるデータ検索プログラムであって、
上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、
上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、データベースサーバに発行する処理と、
データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、
各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、
データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とするデータ検索プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ検索システム及びプログラムに係り、特に、データベースから大量のデータを抽出して加工処理する際の効率化を図る技術に関する。
【背景技術】
【０００２】
これまで、コンピュータの処理能力の向上は、主としてCPUのクロック数の向上に依存してきたが、発熱や消費電力の問題が浮上したため、2003年〜2005年頃を境にCPUのクロック数は頭打ちと状態となっている。その代わりに、近年ではCPUのマルチコア化が進み、比較的低いクロック数のCPUコアであっても、一つのパッケージ内に４〜６個のCPUコアを格納させて処理の並列化を図ることにより、増え続けるデータ処理量に対応することが期待されている。
【非特許文献１】OpenCL入門 - マルチコアCPU・GPUのための並列プログラミング  インターネットURL：http://astore.amazon.co.jp/hiratacreate-22/detail/484432814X  検索日：２０１０年８月１２日
【非特許文献１】数値シミュレーションにおけるソフトウェア研究開発の動向  インターネットURL：http://www.nistep.go.jp/achiev/ftx/jpn/stfc/stt104j/0911_03_featurearticles/0911fa02/200911_fa02.html  検索日：２０１０年８月１２日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
DNA解析や気象解析のように、純粋な演算処理を主体とした科学技術計算の場合には、確かに多数のCPUコアを連携させることにより、処理能力を比較的容易に向上させることができる。
しかしながら、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、単純にアプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題がある。
現在、多数のアプリケーションサーバを並列化し、膨大な量のメモリ上にデータベース内のデータをキャッシュしておくことで、この問題を解決することも試みられているが、その分大きな設置スペースとコストを要することはもちろん、発熱や消費電力の問題が生じる結果となる。
【０００４】
この発明は、上記のような現状に鑑みて案出されたものであり、アプリケーションサーバの数を無闇に増加させることなく、マルチコアCPUの特性を活かすことにより、データベースに蓄積された大量のデータを効率よく抽出・加工することを可能とする技術の提供を目的としている。
【課題を解決するための手段】
【０００５】
上記の目的を達成するため、請求項１に記載したデータ検索システムは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備えたデータ検索システムであって、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、データベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。
【０００６】
請求項２に記載したデータ検索システムは、請求項１のシステムを前提とし、さらに上記検索条件分割処理部が、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。
【０００７】
請求項３に記載したデータ検索システムは、請求項１のシステムを前提とし、さらに上記検索条件分割処理部が、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。
【０００８】
請求項４に記載したデータ検索プログラムは、コンピュータを、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部として機能させるデータ検索プログラムであって、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件を上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、データベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。
【発明の効果】
【０００９】
この発明に係るデータ検索システム及びデータ検索プログラムにあっては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データも、一定量単位で複数のデータ加工処理部を介してデータの加工処理が並列処理される仕組みであるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いた効率的な処理が可能となる。
特に、データベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行するため、データベースサーバ側のDISK/IOによる影響を低減することができる。
【発明を実施するための最良の形態】
【００１０】
図１及び図２は、この発明に係るデータ検索システム10の全体構成を示すブロック図であり、Webサーバ12と、APサーバ14と、DBサーバ16とを備えている。
【００１１】
図１は、クライアント端末18から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。
【００１２】
また、図２はDBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。
【００１３】
APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実行される。
【００１４】
図３は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッドが順次処理していくイメージが描かれている。
この図におけるスレッド32が、図１及び図２に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。
【００１５】
各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。
【００１６】
つぎに、図４〜図６のフローチャートに従い、このシステム10における処理手順を説明する。
まず、図４に従い、検索条件分割処理部20による処理手順を説明する。
すなわち、クライアント端末18から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（Ｓ10）、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。
【００１７】
ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が示された場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。
【００１８】
これらの分割基準は、クライアント端末18から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。
【００１９】
ここでは、都道府県単位で４７分割されたものとして話を進める。
すなわち、検索条件分割処理部20は、４７個の検索処理部22に対して、上記都道府県単位の検索処理を割り当てる（Ｓ14）。
【００２０】
つぎに図５に従い、各検索処理部22における処理手順を説明する。
まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQL文を自動生成し、DBサーバ16に対して発行する（Ｓ20）。
【００２１】
ここで検索処理部22は、DBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量（例えばレコード1,000件分）のデータが送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部24に割り当てる（Ｓ24）。
この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。
受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。
【００２２】
検索処理部22は、データ加工処理部24から処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ24〜Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
そして、DBサーバ16からのデータ送信が完了し、Ｓ24〜Ｓ28の最後の処理が完了した時点で（Ｓ30／Ｙ）、検索処理部22はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部26に集計結果を出力する（Ｓ34）。
【００２３】
つぎに図６に従い、検索結果統合処理部26による処理手順を説明する。
まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックし（Ｓ40、Ｓ42）、全てが揃った段階で全検索処理部の集計結果を集計する（Ｓ44）。
そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末18に送信することになる。
【００２４】
つぎに、図７を参照しながら、このシステム10のより具体的な処理内容を説明する。
図７は、DBサーバ16に格納されたテーブル群を示しており、「顧客ID（主キー）」及び「地域」のデータ項目を備えた顧客管理テーブル40と、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えた予約管理テーブル42と、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えた売上管理テーブル44と、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えた予約取消管理テーブル46と、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えた請求管理テーブル48とによって、各店舗の売り上げが管理されている。
【００２５】
このようなテーブルがDBサーバ16において管理されている場合に、クライアント端末18から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。
【００２６】
つぎに検索処理部22は、これらの分割された検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）を３１個の検索処理部22に割り当てる。
【００２７】
これを受けた各検索処理部22は、まず自己に割り当てられた請求日を指定した、請求管理テーブルから請求データを取得するためのSQL文を生成し、DBサーバ16に発行する。
そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ（例えば1,000件のレコード相当分）単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。
(1)各請求データの「予約ID」を指定したSQL文を生成してDBサーバ16に発行し、「予約管理テーブル」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQL文を生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。
【００２８】
検索処理部22は、データ加工処理部24から上がってきた1,OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、１日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。
検索結果統合処理部26は、全検索処理部22から８月１日〜８月３１日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。
【００２９】
このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。
また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。
【００３０】
ここで、図８を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。
まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを２等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを２分割させる。
例えば、(a)のデータ列はキー項目の値が１〜６があるが、データ加工処理部24は「３」と「４」との間を境にこれを２分割させ、(b)及び(c)のデータ列を生成する。
【００３１】
つぎに、他のデータ加工処理部24は、(b)のデータ列を「２」と「３」との間で２分割させ、(d)及び(e)のデータ列を生成する。
この時点で、(e)のデータ列のキー項目の値は「３」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(e)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００３２】
これに対し、(d)のデータ列の場合には「１」と「２」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(h)及び(i)のデータ列を生成する。
この時点で、(h)のデータ列のキー項目の値は「１」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(h)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(i)のデータ列のキー項目の値は「２」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(i)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００３３】
一方、(c)のデータ列については、他のデータ加工処理部24が「５」と「６」との間で２分割させ、(f)及び(g)のデータ列を生成する。
この時点で、(g)のデータ列のキー項目の値は「６」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(g)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００３４】
これに対し、(f)のデータ列の場合には「４」と「５」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(j)及び(k)のデータ列を生成する。
この時点で、(j)のデータ列のキー項目の値は「４」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(j)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(k)のデータ列のキー項目の値は「５」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(k)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００３５】
図８の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量（例えばレコード1,000件分）のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。
この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。
このデータ加工処理部24による分割処理に際し、分割の回数（階層の深さ）に一定の限度を設けることもできる。
【００３６】
上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQL文を発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ち（I/O Wait）が発生することになる。
【００３７】
そこで図９に示すように、各スレッド32にI/O Waitを伴う処理用の第１のスレッドプール50と、I/O Waitを伴わない処理用の第２のスレッドプール52を設けることが望ましい。
この結果、第１のスレッドプール50に配置されたタスク36の実行によってI/O Waitが発生した場合、スレッド32は第２のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。
【図面の簡単な説明】
【００３８】
【図１】この発明に係るデータ検索システムの、検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。
【図２】この発明に係るデータ検索システムの、DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。
【図３】CPUコアとスレッドとの対応関係を示す模式図である。
【図４】検索条件分割処理部による処理手順を示すフローチャートである。
【図５】検索処理部による処理手順を示すフローチャートである。
【図６】検索結果統合処理部による処理手順を示すフローチャートである。
【図７】DBサーバに格納されたテーブル群を示す図である。
【図８】データ加工処理部によるデータ分割の手順を示す模式図である。
【図９】スレッド毎に複数のスレッドプールを設けた例を示す模式図である。
【符号の説明】
【００３９】
10    データ検索システム
12    Webサーバ
14    APサーバ
16    DBサーバ
18    クライアント端末
20    検索条件分割処理部
22    検索処理部
24    データ加工処理部
26    検索結果統合処理部
30    CPUコア
32    スレッド
34    スレッドプール
36    タスク
40    顧客管理テーブル
42    予約管理テーブル
44    売上管理テーブル
46    予約取消管理テーブル
48    請求管理テーブル
50    第１のスレッドプール
52    第２のスレッドプール
【図１】
0005425028.tif 000002
【図２】
0005425028.tif 000003
【図３】
0005425028.tif 000004
【図４】
0005425028.tif 000005
【図５】
0005425028.tif 000006
【図６】
0005425028.tif 000007
【図７】
0005425028.tif 000008
【図８】
0005425028.tif 000009
【図９】
0005425028.tif 000010