(57)【要約】  テーブル検索サーバ及びファイル検索サーバを検索クエリの送信先候補とする検索システムにおいて、テーブルデータとして検索するよりもファイルデータとして検索した方が検索速度が速いと思われるテーブルデータを特定し、前記特定したテーブルデータをファイルデータに変換し、ファイル検索サーバに格納することを課題とする。  検索システムにおいて、検索クエリ履歴を蓄積保管する検索クエリ履歴管理表、及びテーブルデータとして検索するよりもファイルデータとして検索した方が検索速度が速いと判定するルールを管理する特性判定ルール管理表を作成する。検索システムが、前記検索クエリ履歴に特性判定ルールを適用し、当該テーブルデータを特定する。検索システムは、前記特定されたテーブルデータをテーブル検索サーバから取得し、ファイルデータに変換し、ファイル検索サーバに格納する。
2015049734.tif 000002
【特許請求の範囲】
【請求項１】
テーブル形式のデータを検索するテーブル検索部と複数のファイル形式のデータを並列に検索するファイル検索部を備える検索システムであって、
前記テーブル検索部は検索対象のテーブル形式のデータを格納するテーブルデータ記憶領域と、
前記ファイル検索部は検索対象のファイル形式データを格納するファイルデータ記憶領域と、
前記テーブル検索部がテーブル形式のデータを検索したときに、ファイル形式のデータとして検索した方が検索速度が速いと思われる前記テーブル形式のデータの一部分を行単位で特定する性能判定部と、
前記特定したテーブル形式のデータの一部分を行単位でファイルへ格納し、前記ファイルデータ記憶領域へ移動するデータ移動部と、
受け取った検索クエリを前記テーブル検索部とファイル検索部に振り分ける統合検索部を備えることを特徴とする検索システム。
【請求項２】
請求項１に記載の検索システムにおいて、
検索対象のデータと前記データの記憶領域を対応付けて格納するデータ格納先管理表を備え、
前記統合検索部は前記データ格納先管理表に基づいて前記検索クエリを検索対象のデータを検索対象とする前記検索部のいずれかに検索クエリを送付することを特徴とする検索システム。
【請求項３】
請求項２に記載の検索システムにおいて検索対象のデータを検索対象とする前記検索部が特定できない場合は、前記統合検索部は検索対象となる可能性のある複数の前記検索部へ検索クエリを送付することを特徴とする検索システム。
【請求項４】
請求項２に記載の検索システムであって、
検索クエリの実行履歴を格納する検索クエリ履歴管理表を備え、
前記検索クエリ履歴管理表を基に、前記検索クエリの検索対象データのデータ量が予め定められた容量よりも大きいか、前記検索クエリの検索実行時間が予め定められた検索実行時間よりも長い場合、前記テーブルデータ形式のデータを前記ファイルデータ記憶領域へ格納することを特徴とする検索システム。
【請求項５】
請求項４に記載の検索システムであって、
検索実行時間による判定結果と他の条件による判定結果が相反する場合は検索実行時間による判定結果に基づき格納先を決定することを特徴とする検索システム。
【請求項６】
請求項２に記載の検索システムであって、
検索クエリの実行履歴を格納する検索クエリ履歴管理表を備え、
前記検索クエリ履歴管理表を基に、前記検索クエリ履歴管理表が管理する過去の検索クエリ実行結果において、検索クエリの検索対象データに対する集約処理の処理回数が予め定められた回数よりも多い場合、前記テーブルデータ形式のデータを前記ファイルデータ記憶領域へ格納することを特徴とする検索システム。
【請求項７】
テーブル形式のデータを検索するテーブル検索部と複数のファイル形式のデータを検索するファイル検索部を備える検索システムの検索方法であって、
テーブルデータ記憶領域に前記テーブル検索部が検索対象のテーブル形式のデータを格納し、
ファイルデータ記憶領域に前記ファイル検索部が検索対象のファイル形式データを格納し、
性能判定部は前記テーブル検索部がテーブル形式のデータを検索したときに、ファイル形式のデータとして検索した方が検索速度が速いと思われる前記テーブル形式のデータの一部分を行単位で特定し、
データ移動部が前記特定したテーブル形式のデータの一部分を行単位でファイルへ格納し、前記ファイルデータ記憶領域へ移動し、
統合検索部が受け取った検索クエリを前記テーブル検索部とファイル検索部に振り分けるを備えることを特徴とする検索方法。
【請求項８】
請求項７に記載の検索方法において、
検索対象のデータと前記データの記憶領域を対応付けて格納するデータ格納先管理表を備え、
前記統合検索部は前記データ格納先管理表に基づいて前記検索クエリを検索対象のデータを検索対象とする前記検索部のいずれかに検索クエリを送付することを特徴とする検索方法。
【請求項９】
請求項８に記載の検索方法において検索対象のデータを検索対象とする前記検索部が特定できない場合は、前記統合検索部は検索対象となる可能性のある複数の前記検索部へ検索クエリを送付することを特徴とする検索方法。
【請求項１０】
請求項８に記載の検索方法であって、
検索クエリの実行履歴を格納する検索クエリ履歴管理表を備え、
前記検索クエリ履歴管理表を基に、前記検索クエリの検索対象データのデータ量が予め定められた容量よりも大きいか、前記検索クエリの検索実行時間が予め定められた検索実行時間よりも長い場合、前記テーブルデータ形式のデータを前記ファイルデータ記憶領域へ格納することを特徴とする検索方法。
【請求項１１】
請求項１０に記載の検索方法であって、
検索実行時間による判定結果と他の条件による判定結果が相反する場合は検索実行時間による判定結果に基づき格納先を決定することを特徴とする検索方法。
【請求項１２】
請求項８に記載の検索方法であって、
検索クエリの実行履歴を格納する検索クエリ履歴管理表を備え、
前記検索クエリ履歴管理表を基に、前記検索クエリ履歴管理表が管理する過去の検索クエリ実行結果において、検索クエリの検索対象データに対する集約処理の処理回数が予め定められた回数よりも多い場合、前記テーブルデータ形式のデータを前記ファイルデータ記憶領域へ格納することを特徴とする検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索システム及び検索方法に関する。
【背景技術】
【０００２】
インターネットの普及により、テキスト、画像、音声などのファイルデータの数が膨大になっている。膨大な数のファイルデータに対する処理を実時間で完了させるため、複数の計算機で分散処理をすることがある。例えば分散処理フレームワークであるHadoopは、ファイルデータを複数の計算機に分散して格納し、処理命令を各計算機に送信し、各計算機がそれぞれに格納するファイルデータに対して処理を実行する。特許文献1には、RDB（Relational Database）に格納されるテーブルデータ及びXML DB（eXtensible Markup Language Database）に格納されるXMLファイルを統合して、一つのテーブルデータを作成することが開示されている。【０００３】
また、特許文献2には、テキストファイルデータに自然言語解析手法を適用した結果をテーブルデータとして作成し、前記テーブルデータと別のテーブルデータを統合して、一つのテーブルデータを作成することが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】US 8,195,647
【特許文献２】特開2010-205077
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来、データの種別と、データの処理プログラムは1対1で固定されており、各々の処理プログラムが管理するストレージに格納されていた。例えば、テーブルデータのような構造データであればRDBで処理されデータベースとして格納され、テキストデータや時系列データのような非構造データであればHadoopで処理され、Hadoopが管理するファイルに格納され、それらの格納先で当該データの処理が行われてきた。しかし、コスト・性能面で、データの格納先が適切ではない場合がある。例えば、テーブルデータの内容でもHadoopが管理するファイル格納しHadoopで処理することが適切であったり、時系列データであってもRDBが管理するデータベースへ格納してＲＤＢが処理することが適切であったりする場合がある。具体的には、巨大なテーブルデータを集約する処理では、テーブルデータを分割してHadoopのファイルに格納し、Hadoopで処理した方が、処理時間が短くなる場合がある。このように、テーブルデータやファイルデータといったデータの種別ではなく、集約や検索といった、当該データに対する処理の特性を考慮して、データの格納先を決定する必要がある。【０００６】
データ処理特性は、処理の履歴から決定することができる。【０００７】
履歴からデータ処理特性を決定することにより情報システムの管理者が一つ一つのデータについて、処理特性を決定する必要が無い。【０００８】
また、データに対する処理特性は、時間と共に変化する可能性があるため、処理特性の変化に応じた適切なデータ処理特性の決定がおこなうことが望まれる。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、テーブル検索サーバ及びファイル検索サーバを検索クエリの送信先候補とする検索システムにおいて、テーブルデータとして検索するよりもファイルデータとして検索した方が、検索速度が速いと思われるテーブルデータを特定し、前記特定したテーブルデータをファイルデータに変換し、ファイル検索サーバに格納するためには、検索クエリ履歴を蓄積保管する検索クエリ履歴管理表、テーブルデータとして検索するよりもファイルデータとして検索した方が検索速度が速いと判定するルールを管理する特性判定ルール管理表、及び判定結果に基づきテーブルデータをファイルデータに変換し、ファイル検索サーバに格納するデータ移動技術が必要になる。【００１０】
本願は、テーブル形式のデータを検索するテーブル検索部と複数のファイル形式のデータを並列に検索するファイル検索部を備える検索システムであって、前記テーブル検索部は検索対象のテーブル形式のデータを格納するテーブルデータ記憶領域と、前記ファイル検索部は検索対象のファイル形式データを格納するファイルデータ記憶領域と、前記テーブル検索部がテーブル形式のデータを検索したときに、ファイル形式のデータとして検索した方が検索速度が速いと思われる前記テーブル形式のデータの一部分を行単位で特定する性能判定部と、前記特定したテーブル形式のデータの一部分を行単位でファイルへ格納し、前記ファイルデータ記憶領域へ格納することを特徴とする。
【発明の効果】
【００１１】
データ移動の自動化による検索時間の短縮、及びデータ管理コストの低減
【図面の簡単な説明】
【００１２】
【図１】システム構成図の一例である。
【図２】検索システム構成図の一例である。
【図３】ファイル検索サーバ構成図の一例である。
【図４】検索サーバ特性管理表の例を示す図である。
【図５】データ格納先管理表の例を示す図である。
【図６】検索クエリ履歴管理表の例を示す図である。
【図７】移動データ候補特性管理表の例を示す図である。
【図８】特性判定ルール管理表の例を示す図である。
【図９】集約関数管理表の例を示す図である。
【図１０】データ移動管理表の例を示す図である。
【図１１】データ移動後のデータ格納先管理表の例を示す図である。
【図１２】検索システムによる検索クエリの処理の例である。
【図１３】テーブル検索サーバによる検索クエリの処理の例である。
【図１４】ファイル検索サーバによる検索クエリの処理の例である。
【図１５】性能判定部の処理の例である。
【図１６】データ移動部の処理の一例である。
【図１７】管理画面の例である。
【図１８】SQLクエリをファイル検索サーバが処理可能な形式に変換した例である。
【図１９】テーブルデータを分割して、ファイルに変換した例である。
【図２０】XMLファイルの変換例
【図２１】テキストファイルの変換例
【発明を実施するための形態】
【実施例１】
【００１３】
本実施例では、検索クエリの履歴集計方法、移動データの決定方法、及びデータ移動方法などについて説明する。本実施例では、テーブル検索サーバに格納されているテーブルデータを分割し、分割したテーブルデータをファイルに変換し、変換後のファイルをファイル検索サーバに格納し、当該テーブルデータをテーブル検索サーバより削除するケースで説明する。【００１４】
図1は、本発明の実施例におけるシステムの構成を例示する図である。ネットワーク5000を介して、検索システム1000、テーブル検索サーバ2000、ファイル検索サーバ3000、及びクライアントマシン4000が接続されている。なお、テーブル検索サーバ2000、ファイル検索サーバ3000、クライアントマシン4000は、それぞれ複数台存在してもよい。テーブル検索サーバ2000は、テーブル検索部2100及びテーブルデータ記憶領域2200から構成される。ファイル検索サーバ3000は、ファイル検索部3100及びファイルデータ記憶領域3200から構成される。後述のように、ファイル検索サーバは代表ノード3010及び複数のメンバノード3020から構成されている。クライアントマシン4000は、検索システム管理部4100及び又はデータ分析部4200で構成される。【００１５】
図2は、検索システム1000の構成を例示する説明図である。検索システム1000は、統合検索部1100、性能判定部1200、データ移動部1300、管理画面生成部1400、及びタイマー1500から構成される。また、検索システム1000は、データ格納先管理表6100、検索クエリ履歴管理表6200、移動データ候補特性管理表6300、データ移動管理表6400、特性判定ルール管理表6500、検索サーバ特性管理表6600、集約関数管理表6700を所持する。【００１６】
図3は、ファイル検索サーバ3000の構成を例示する説明図である。ファイル検索サーバ3000は、検索サーバID、代表IPアドレス、及びノード数で識別される。また、ファイル検索サーバ3000は、代表ノード3010及とメンバノード3020で構成される。これらの代表ノード3010及び各メンバノード3020はネットワーク5000を介して接続され、それぞれIPアドレスによって特定できる。また、代表ノード3010は、ファイル検索部3110及びファイルデータ記憶領域3210から構成され、各メンバノード3020は、それぞれファイル検索部3120及びファイルデータ記憶領域3220から構成される。【００１７】
図4は、検索サーバ特性管理表6600の構成を例示する図である。検索サーバ特性管理表6600は、各検索サーバの情報を格納する。具体的には、検索サーバID6610、サーバ種別6620、代表IPアドレス6630、ノード数6640、及びサーバ特性6650から構成される。サーバ種別6620は、”TSS”または”FSS”の値をとり、サーバの種別がそれぞれテーブル検索サーバ2000（ＴＳＳ），ファイル検索サーバ3000（ＦＳＳ）であることを意味する。サーバ特性6650は、”検索”または”集約”を示す値をとり、当該検索サーバが検索処理又は集約処理のどちらに適しているかを表す。適しているとは、例えば、処理速度が高いことや、消費記憶領域の量が少ないことを基準に判断されてもよい。【００１８】
図5は、データ格納先管理表6100の構成を例示する図である。データ格納先管理表6100は、テーブル名及び移動データ検索式で特定されるデータ群が格納されている検索サーバに関する情報を格納する。具体的には、テーブル名6110、移動データ検索式6120、格納先検索サーバID6130、及び格納先ディレクトリ名6140などから構成される。【００１９】
移動データ検索式6120は、SQLクエリにおけるwhere文に記述される条件式などを意味する。テーブル名6110と移動データ検索式6120を組み合わせることで、一意にデータを指定することができる。この例では、テーブル名6110＝”TBL3”及び移動データ検索式6120＝”Age<30”は、TBL3のAgeが30未満のデータ群を指定する。また、移動データ検索式6120＝”*”は、当該テーブル内の全データ群を指定することを意味する。【００２０】
格納先ディレクトリ名6140=”N/A”とは、格納先検索サーバID6130に対応する検索サーバのサーバ種別6620が”TSS”（テーブル検索サーバ2000）であることを意味する。テーブル検索サーバ2000では、ディレクトリ名ではなく、テーブル名6110によりデータを管理しているためである。【００２１】
図6は、検索クエリ履歴管理表6200の構成を例示する図である。検索クエリ履歴管理表6200は、検索クエリの履歴を格納する。具体的には、検索クエリ6210、テーブル名6220、検索式6230、レコード数6240、集約関数6250、UPDATE処理6260、検索実行時間6270から構成される。【００２２】
検索クエリ6210は、統合検索部1100が、データ分析部4200から受信した検索クエリを格納する。テーブル名6220及び検索式6230は、当該検索クエリから抽出したテーブル名及び検索式を登録する。レコード数6240は、前記テーブル名6220及び検索式6230で特定されるデータ群のデータ数を登録する。集約関数6250は、前記検索クエリ6210が、後述の集約関数管理表6700に登録されている関数6710のいずれかを含む場合には”Yes”、含まない場合には”No”が格納される。UPDATE処理6260は、前記検索クエリ6210がUPDATE処理の場合には”Yes”、そうでない場合には”No”が格納される。検索実行時間6270は、統合検索部1100がデータ分析部4200から検索クエリを受信してから、統合検索部1100がデータ分析部4200に検索結果を返信するまでに要した時間が格納される。【００２３】
検索実行時間6270として、例えば処理時間（Process time）や経過時間（Elapsed time）を用いてもよい。前記処理時間は、検索システム1000の中央演算処理装置が前記検索クエリ処理のために稼働していた時間を意味する。このため、前記中央演算処理装置が前記検索クエリ処理と同時に何らかの処理を行なっている場合であっても、前記処理時間は前記検索クエリの正確な処理時間を表す。しかし、前記処理時間は、検索システム1000からテーブル検索サーバ2000又はファイル検索サーバ3000への前記検索クエリの送信に要する時間などを含んでおらず、ユーザの体感する検索実行時間と乖離してしまうことがある。ユーザの体感できる検索実行時間を表現するためには、前記経過時間を採用するとよい。【００２４】
検索実行時間6270は実際に検索を実行した結果に基づく指標であるため、データを移動するときに用いる図７で説明するようなレコード数、検索回数、集約回数、Update回数等の指標よりも優先的に用いることにより、より検索時間を短縮できる。【００２５】
図7は、移動データ候補特性管理表6300を例示する図である。移動データ候補特性管理表6300は、移動データ候補6310、移動データ候補の特性判定要素6320、及び移動データ候補の特性6330を格納する。具体的には、テーブル名6311、検索式6312、レコード数6321、検索回数6322、集約回数6323、UPDATE回数6324、及び特性6330で構成される。なお、テーブル名6311及び検索式6312を総称して移動データ候補6310とよび、レコード数6321、検索回数6322、集約回数6323、及びUPDATE回数6324を総称して特性判定要素6320とよぶ。【００２６】
移動データ候補特性管理表6300の移動データ候補6310及び特性判定要素6320は、検索クエリ履歴管理表6200を集計して求める。集計方法の詳細は、後述する。【００２７】
図8は、特性判定ルール管理表6500の構成を例示する図である。特性判定ルール管理表6500は、検索クエリの特性を判定するルールを格納する。具体的には、判定ルール6510及び特性6520で構成される。判定ルール6510は、前記特性判定要素6320から構成される論理式である。例えば、図8に示す特性判定ルール管理表6500の1行目の判定ルール6510は、「検索実行時間の平均値が5（秒）以上」となっている。もちろん、「検索実行時間の最大値が5（秒）以上」としてもよい。判定ルール6510が真の場合、当該判定ルール6510に対応する特性6520を当該検索クエリの特性とする。【００２８】
図9は、集約関数管理表6700の構成を例示する図である。集約関数管理表6700は、処理対象のデータ群を集約する関数を格納する。具体的には、関数6710で構成される。集約関数の例として、処理対象のデータ群の平均値を算出するavg等が挙げられる。【００２９】
図10は、データ移動管理表6400の構成を例示する図である。データ移動管理表6400は、移動データ、移動元、移動先、及びステータスを格納する。具体的には、テーブル名6411、移動データ検索式6412、移動元検索サーバID6421、移動元ディレクトリ名6422、移動先検索サーバID6431、移動先ディレクトリ名6432、及びステータス6440から構成される。なお、テーブル名6411及び移動データ検索式6412を総称して移動データ6410、移動元検索サーバID6421及び移動元ディレクトリ名6422を総称して移動元検索サーバ6420、移動先検索サーバID6431及び移動先ディレクトリ名6432を総称して移動先検索サーバ6430、とそれぞれよぶ。【００３０】
性能判定部1200が、移動データ候補特性管理表6300及び検索サーバ特性管理表6600を比較し、移動データ候補6310の特性6330と当該移動データ候補6310の格納先検索サーバのサーバ特性6650が一致していない場合、移動データ候補6310の特性6330をもつ検索サーバを移動先とし、データ移動管理表6400に移動データ候補、移動元、移動先をデータ移動管理表6400に登録する。データ移動管理表6400の作成方法の詳細は、後述する。【００３１】
図11は、データ移動管理表6400に従ってデータを移動した後の、データ格納先管理表6100の一例である。例えば、データ移動管理表6400の1行目のデータ移動により、テーブル”TBL1”の一部データ群が検索サーバ”TSS_01”から検索サーバ”FSS_01”に移動したため、図11の1行目には、テーブル”TBL1”のうち、図5の1行目の移動データ（テーブル名6110「TBL1」及び移動データ検索式6120「*」）及び前記移動データ6410（テーブル名6411「TBL1」及び移動データ検索式6412「sex=M」）の差集合の情報（テーブル名6110「TBL1」及び移動データ検索式6120「sex=F」）が格納され、図11の2行目には、前記移動データ6410の情報（テーブル名6411「TBL1」及び移動データ検索式6412「sex=M」）が、それぞれ格納してある。【００３２】
図12は、検索システム1000が、データ分析部4200から受信した検索クエリを処理する流れを示す。本処理では、統合検索部1100がテーブル検索サーバ2000及び又はファイル検索サーバ3000に検索クエリを送信し、結果をデータ分析部4200に返信する。【００３３】
はじめにステップS101を説明する。ステップS101では、統合検索部1100が、検索クエリをデータ分析部4200から受信する。ここで、検索クエリに含まれるテーブル名及び検索式で特定されるデータ群を処理データとよぶこことする。【００３４】
次にステップS102を説明する。ステップS102では、統合検索部1100が、処理データを格納する検索サーバを特定する。具体的には、統合検索部1100が、データ格納先管理表6100を参照し、前記検索クエリに含まれるテーブル名がテーブル名6110に登録されており、かつ、前記検索クエリに含まれる検索式を包含する移動データ検索式6120が登録された行を特定し、前記特定した行に対応する格納先検索サーバを特定する。【００３５】
まず、統合検索部1100が、データ格納先管理表6100を参照し、前記検索クエリに含まれるテーブル名がテーブル名6110に登録されている行を全て特定する。【００３６】
次に、統合検索部1100が、前記特定した行それぞれについて、移動データ検索式6120と前記検索クエリに含まれる検索式の包含関係を判定する。【００３７】
前記検索クエリに含まれる検索式を包含する移動データ検索式6120を有する前記特定した行が存在する場合、統合検索部1100が、当該行の格納先検索サーバID6130及び格納先ディレクトリ名6140を取得する。統合検索部1100が、検索サーバ特性管理表6600を参照し、前記取得した格納先検索サーバID6130に対応する、代表IPアドレス6630を取得する。
一方、前記検索クエリに含まれる検索式を包含する移動データ検索式6120を有する前記特定した行が存在しない場合、前記特定した行それぞれについて、格納先検索サーバID6130及び格納先ディレクトリ名6140を取得する。統合検索部1100が、検索サーバ特性管理表6600を参照し、前記取得した格納先検索サーバID6130それぞれに対応する、代表IPアドレス6630を取得する。【００３８】
前記検索クエリに含まれる検索式を包含する移動データ検索式6120を有する前記特定した行が存在しない場合は、処理データの格納先が不明、又は処理データの格納先が複数の検索サーバに分散していることを意味する。例えば、検索クエリ「select * where age < 30 from TBL1」に含まれるテーブル名「TBL1」及び検索式「age < 30」で識別される処理データを格納する検索サーバの特定を考える。図11に示すようなデータ格納先管理表6100の例では、テーブル名「TBL1」がテーブル名6110に登録されている行は1行目と2行目であることが特定できる。しかし、図11に示すデータ格納先管理表6100の1行名及び2行目のうち、検索式「age<30」を包含する移動データ検索式6130を有する行は存在しない。以上が、ステップS102の説明である。【００３９】
ステップS103では、統合検索部1100が、前記検索クエリ及び前記取得した格納先ディレクトリ名6140を、前記取得した代表IPアドレス6630、即ち前記格納先検索サーバID6610に対応する格納先検索サーバに送信する。各格納先検索サーバが受信した検索クエリを処理し、結果を統合検索部1100に返信する。ここで統合検索部1100は、格納先検索サーバが処理可能な形式に検索クエリを変換した後、変換後の検索クエリを各格納先検索サーバに送信する。【００４０】
統合検索部1100が、データ移動管理表6400を参照し、移動データ6410の、移動元検索サーバ6420、移動先検索サーバ6430、及びステータス6440を取得する。【００４１】
検索クエリはSELECT要求、UPDATE要求、INSERT要求、及びDELETE要求のいずれかであり、SELECT要求を除く他の3つの要求は、処理データの内容を変更する。このため、前記検索クエリがSELECT要求以外であった場合、且つ前記取得したステータス6440が“移動中”であった場合、検索クエリによる処理データの内容変更は、データ分析部4200からの検索クエリを処理しているタイミングで、移動先検索サーバ6430においても反映される必要がある。なぜならば、移動元検索サーバ6420に格納されるデータにのみ前記内容変更が反映された状態で、当該データが誤って消去されたとき、移動先検索サーバ6430に格納されるデータに反映されないまま、前記内容変更が失われてしまうためである。【００４２】
従って、前記検索クエリがSELECT要求以外であり、且つ前記取得したステータス6440が“移動中”であるか判定する。前記検索クエリがSELECT要求以外であった場合、且つ前記取得したステータス6440が“移動中”であった場合、統合検索部1100が、検索クエリを移動先検索サーバ6430に送信し、移動先検索サーバ6430が検索クエリを処理し、結果を統合検索部1100に返信する。この際、統合検索部1100は、移動先検索サーバ6430が処理可能な形式に検索クエリを変換した後、変換後の検索クエリを移動先検索サーバ6430に送信する。【００４３】
処理データを格納する検索サーバを特定することができない場合や、困難な場合には処理データを格納する可能性のある検索サーバの全てにクエリを送付し、クエリを送付した検索サーバから検索結果を受け取っても良い。【００４４】
処理データを格納する可能性のある検索サーバを予め登録しておくことにより処理データを格納する検索サーバを特定する負荷を低減できる。【００４５】
以上が、ステップS103である。【００４６】
最後に、統合検索部1100は、結果をデータ分析部4200に返信し（ステップS104）、検索クエリを検索クエリ履歴管理表6200に追記し（ステップS105）、処理を終了する。【００４７】
図13は、テーブル検索サーバ2000のテーブル検索部2100が、統合検索部1100から検索クエリを受信し（ステップS201）、受信した検索クエリを処理し、結果を統合検索部1100に返信する（ステップS202）流れを示す。【００４８】
図14は、ファイル検索サーバ3000が、統合検索部1100から受信した検索クエリを処理し、結果を統合検索部1100に返信する流れを示す。【００４９】
はじめに、ファイル検索サーバ3000の代表ノード3010のファイル検索部3110が、ファイル検索サーバ3000が処理可能な形式に変換した検索クエリを、統合検索部1100から受信する（ステップS301）。【００５０】
次に、代表ノード3010のファイル検索部3110が、前記変換後の検索クエリを各メンバノード3020のファイル検索部3120に送信する（ステップS302）。【００５１】
前記変換後の検索クエリを受信した各メンバノード3020のファイル検索部3120が、当該検索クエリを処理し、結果を代表ノード3010のファイル検索部3110に返信する（ステップS303）。【００５２】
最後に、代表ノード3010のファイル検索部3110が、各結果を統合し、統合検索部1100に返信する（ステップS304）。【００５３】
図15は、性能判定部1200が、タイマー1500によって一定時間毎に、まず検索クエリを集計し、次に移動データ候補を決定し、最後にデータ移動を判定する処理を示す。【００５４】
はじめに、検索クエリ履歴管理表6200の検索クエリ6210を集計し、移動データ候補特性管理表6200を作成する（ステップS401）。【００５５】
まず、検索クエリ履歴管理表6200の各行について、テーブル名6220及び検索式6230のユニークなセットを、移動データ候補6310として、移動データ候補特性管理表6300に格納する。このとき、レコード数6321をコピーする。【００５６】
次に、検索クエリ履歴管理表6200より、移動データ候補特性管理表6300の処理対象行に含まれるテーブル名と同じテーブル名6220及び検索式6230を持つ行を抽出し、検索回数6322、集約回数6323、及びUPDATE回数6324を集計し、それぞれ移動データ候補特性管理表6300に格納する。【００５７】
なお、集計回数6323とは、集約関数管理表6700に登録されている各関数6710が検索クエリ6210に含まれている回数を、検索回数6322とはSELECT要求の回数から前記集約回数6323を差し引いた回数を、UPDATE回数6324とは、UPDATE要求の回数を、それぞれ意味する。【００５８】
最後に、移動データ候補6310に対応する特性判定要素6320が、特性判定ルール管理表6500の判定ルール6510を満たす判定ルールがあるかどうか調べ、満たす判定ルールが見つかった場合に当該判定ルールの特性6520を移動データ候補特性管理表6300の特性6330に格納する。【００５９】
次に、移動データ候補特性管理表6300の全ての行につき、移動データ候補の特性6330と移動データの格納先検索サーバのサーバ特性6650の一致判定が終了したか判定する（ステップS402）。【００６０】
移動データ候補特性管理表6300の全てにつき、前記一致判定が終了した場合、ステップS405に進む。前記一致判定が終了していない場合、ステップS403に進む。【００６１】
移動データ候補特性管理表6300の各行につき、移動データ候補の特性6330と移動データの格納先検索サーバのサーバ特性6650の一致を判定する（ステップS403）。【００６２】
データ格納先管理表6100を参照し、移動データ候補特性管理表6300のテーブル名6311及び検索式6312に対応する、格納先検索サーバID6130及び格納先ディレクトリ名6140を取得する。【００６３】
さらに、検索サーバ特性管理表6600を参照し、前記取得した格納先検索サーバID6610に対応する検索サーバのサーバ特性6650を取得する。移動データ候補特性管理表6300の特性6330が、前記取得した格納先検索サーバのサーバ特性6650と同一であるか判定する。【００６４】
移動データ候補特性管理表6300の特性6330が、前記取得した格納先検索サーバのサーバ特性6650と同一である場合、ステップS402に戻る。一方、移動データ候補特性管理表6300の特性6330が、前記取得した格納先検索サーバのサーバ特性6650と異なる場合、移動データ候補6310を移動データ6410とし、ステップS404に進む。【００６５】
ステップS404では、移動データ6410の移動元検索サーバ6420及び移動先検索サーバ6430を決定する。【００６６】
まず、移動先検索サーバID6431を決定する。特性6330が集約の場合、ファイル検索サーバ3000を移動先検索サーバ6430とする。特性6330が検索の場合、テーブル検索サーバ2000を移動先検索サーバ6430とする。検索サーバ特性管理表6600を参照し、特性6330を有する検索サーバ群を抽出する。前記抽出した検索サーバ群から検索サーバを選択する。前記選択した検索サーバに対応する検索サーバID6610を、移動先検索サーバID6431とする。【００６７】
次に、移動先ディレクトリ名6432を決定する。前記移動先検索サーバ6430がファイル検索サーバ3000の場合、移動先ディレクトリ名6432として”/fss/テーブル名の小文字表記”を登録する。具体的には、テーブル名6311が”TBL3”であった場合、移動先ディレクトリは”/fss/tbl3”となる。【００６８】
一方、前記移動先検索サーバ6430がテーブル検索サーバ2000であった場合、移動先ディレクトリ名6432としてN/Aを登録する。【００６９】
これまでの処理により、移動先検索サーバID6431及び移動先ディレクトリ名6432が決定されている。【００７０】
移動元検索サーバID6421として前記格納先検索サーバID6130を、移動元ディレクトリ名6422として前記格納先ディレクトリ名6140を、それぞれ登録する。データ移動管理表に新たに行を追加し、移動元検索サーバID6421、移動元ディレクトリ名6422、移動先検索サーバID6431、及び移動先ディレクトリ名6432を登録する。ステータス6440として”未移動”を登録し、ステップS402に戻る。【００７１】
ステップS405では、データの移動命令を、データ移動部1300に送信する。【００７２】
図16は、データ移動部1300が、データを移動する流れを示す。本処理では、データ移動部1300が、テーブル検索サーバ2000からファイル検索サーバ3000にデータを移動、又はファイル検索サーバ3000からテーブル検索サーバ2000にデータを移動する。ただし簡単のため、本実施例では、ファイル検索サーバ3000に格納される全てのデータは、CSVファイルであることを前提とする。【００７３】
まず、移動元検索サーバ6420から移動先検索サーバ6430へデータのコピーを行う。コピー完了後、データ格納先管理表6100における当該移動データの格納先を、移動元検索サーバ6420から移動先検索サーバ6430に変更する。最後に、移動元検索サーバ6420から移動データを削除する。【００７４】
以上が、データ移動の簡単な流れの説明である。これ以降、データ移動の詳細な流れを説明する。【００７５】
はじめに、データ移動部1300が、データ移動命令を性能判定部1200から受信する。データ移動部1300が、データ移動管理表6400の各行について、ステータス6440を「移動中」に変更し、以下の処理を実行する。【００７６】
まず、データ移動部1300が、データ移動管理表6400を参照し、移動データ6410、移動元検索サーバ6420、及び移動先検索サーバ6430を取得する。次に、データ移動部1300が、検索サーバ特性管理表6600を参照し、前記取得した移動元検索サーバID6421に対応する代表IPアドレス6630及びサーバ種別6620を取得する。【００７７】
前記取得した移動元検索サーバ6420のサーバ種別6620を判定する。【００７８】
前記取得した移動元検索サーバ6420のサーバ種別6620が”FSS”の場合、ファイル検索サーバ3000から移動データ6410を読み出し（ステップS501）、テーブル形式に変換し（ステップS502）、テーブル検索サーバ2000に格納する（ステップS503）。より具体的には次の通りである。【００７９】
データ移動部1300が、前記取得した移動元ディレクトリ名6422を、前記取得した移動元検索サーバ6420の代表IPアドレス6630、即ち代表ノード3010に送信する。代表ノード3010は、受信した移動元ディレクトリ名6422を、各メンバノード3020に送信する。各メンバノード3020が、移動元ディレクトリに格納されるCSVファイルを、代表ノード3010に返信する（ステップS501）。代表ノード3010が、受信したCSVファイルをテーブルデータに統合し、データ移動部1300に返信する（ステップS502）。【００８０】
前述のように、本実施例では、ファイル検索サーバ3000に格納される全てのデータは、CSVファイルであることを前提としている。例えば、MySQLのLOAD DATA INFILE構文により、CSVファイルはテーブルデータへ変換可能である。同様に、MySQLのLOAD XML INFILE構文により、XMLファイルはテーブルデータへ変換可能である。例えば、図２０のようにXMLファイルをテーブルデータに変換できる。【００８１】
いくつかのメールクライアントは、電子メールをファイルに格納することが可能である。例えば、Microsoft Outlook ExpressやMozilla Thunderbirdは、eml形式で電子メールをファイルに格納する。Eml形式のように構造が決まっているテキストファイルであれば、図２１のようなマッピング情報を定義することにより、テーブルデータに変換することができる。【００８２】
データ移動部1300が、検索サーバ特性管理表6600を参照し、移動先検索サーバID6431に対応する代表IPアドレス6630を取得する。データ移動部1300が、前記テーブルデータ及びテーブル名6411を、移動先検索サーバ6430の前記取得した代表IPアドレス6630に送信する。移動先検索サーバ6430が、前記テーブルデータを、テーブルデータ記憶領域2200に格納する（ステップS503）。【００８３】
一方、移動元検索サーバ6420のサーバ種別6620が”TSS”の場合、テーブル検索サーバ2000から移動データ6410を読み出し（ステップS501）、テーブルデータを分割し、ファイル形式に変換し（ステップS502）、ファイル検索サーバ3000に格納する（ステップS503）。より具体的には次の通りである。【００８４】
データ移動部1300が、移動元検索サーバ6420のテーブル検索部2100に、テーブル名6411及び移動データ検索式6412を送信する。テーブル検索部2100が、受信したテーブル名6411及び移動データ検索式6412で特定されるデータ群を、テーブルデータ記憶領域2200より読み出し、データ移動部1300に返信する（ステップS501）。【００８５】
データ移動部1300が、検索サーバ特性管理表6600を参照し、移動先検索サーバID6431に対応する代表IPアドレス6630及びノード数6640を取得する。データ移動部1300が、受信したデータ群をノード数6640で分割し、それぞれテーブルデータからCSVファイルに変換する（ステップS502）。CSVファイルへの変換方法の一例は、図21を参照されたい。データ移動部1300が、当該CSVファイルを移動先ディレクトリ名6432と共に、移動先検索サーバ6430の代表ノード3010のファイル検索部3110に送信する。【００８６】
代表ノード3010のファイル検索部3110が、受信したCSVファイルを各メンバノード3020のファイル検索部3120に送信する。CSVファイルを受信した各メンバノード3020のファイル検索部3120は、当該CSVファイルをファイルデータ記憶領域3200に格納する（ステップS503）。【００８７】
ここまでの手順で、移動元検索サーバ6420から移動先検索サーバ6430へのデータコピーが完了する。次に、データ格納先管理表6100を更新し（ステップS504）、移動元検索サーバ6420から当該データを削除する（ステップS505）。より具体的には次の通りである。【００８８】
データ移動部1300が、データ格納先管理表6100に移動したデータに対応する行を追加し、移動データのテーブル名6110、移動データ検索式6120、格納先検索サーバID6130へ移動先検索サーバID6431、及び格納先ディレクトリ名6140として移動先ディレクトリ名6432を、それぞれ登録する。【００８９】
データ移動部1300が、移動データ検索式6120を包含する移動データ検索式6120を持つデータを、データ格納先管理表6100から特定する。【００９０】
次に、移動データ検索式6120で特定されるデータ群から移動元の移動データ検索式6120で特定されるデータ群を差し引いた残りの集合を決定する。当該集合を特定する移動データ検索式6120を決定し、データ格納先管理表6100で特定された移動データ検索式6120として登録する（本登録により、図5の1行目は図11の1行目となる）（ステップS504）。【００９１】
データ移動部1300が、データ移動管理表6400の移動データのステータス6440を「移動完了」に変更する。【００９２】
移動元検索サーバ6420のサーバ種別6620が”FSS”か”TSS”か判定する。移動元検索サーバ6420のサーバ種別6620が”FSS”の場合は、各メンバノード3020が前記CSVファイルをファイルデータ記憶領域3200から削除し、一方、移動元検索サーバ6420のサーバ種別6620が”TSS”の場合は、テーブル検索部2100が、前記データ群をテーブルデータ領域から削除する（ステップS505）。【００９３】
以上のステップをデータ移動管理表6400の移動データについて実行する。【００９４】
図17は、管理画面生成部1400が生成する、検索システム1000の管理画面の構成を例示する図である。この画面の例では入力された特性判定ルール601, 検索サーバの特性が「検索」か「集約」か指定する検索サーバの特性情報602, 集約の特性を持つSQL関数603を入力することができる。本管理画面を通じ、検索システム管理部4100は、検索サーバ特性管理表6600、特性判定ルール管理表6500、及び集約関数管理表6700を管理する。【００９５】
図18は、SQLクエリ651をファイル検索サーバ3000が処理可能な形式652に変換した一例の説明図である。【００９６】
図19は、テーブルデータ671からsex=Mの条件で行単位にデータを抽出したテーブルデータ672を作成し、CVS化することによりファイル673に変換した一例の説明図である。【００９７】
以上、本発明の実施例1について説明したが、本発明はこの実施例1に限定されることなくその趣旨を逸脱しない範囲内で種々の構成をとることができることは言うまでもない。【００９８】
例えば図4に示すように、本実施例では、検索に適したテーブル検索サーバ2000及び集約に適したファイル検索サーバ3000のいずれかにデータを格納することを前提としてきた。しかし、本発明は、これら2種類の検索サーバに加え、第3の特性を有する検索サーバをデータ格納先候補とすることも可能である。この際、検索クエリの処理、データ特性判定、及びデータ移動は、前述と同様の方法で実施可能である。
【符号の説明】
【００９９】
１０００・・・検索システム
１１００・・・統合検索部
１２００・・・性能判定部
１３００・・・データ移動部
１４００・・・管理画面生成部
１５００・・・タイマー
２０００・・・テーブル検索サーバ
２１００・・・テーブル検索部
２２００・・・テーブルデータ記憶領域
３０００・・・ファイル検索サーバ
３０１０・・・代表ノード
３０２０・・・メンバノード
３１００、３１１０、３１２０・・・ファイル検索部
３２００、３２１０、３２２０・・・ファイルデータ記憶領域
４０００・・・クライアントマシン
４１００・・・検索システム管理部
４２００・・・データ分析部
５０００・・・ネットワーク
６１００・・・データ格納先管理表
６１１０・・・テーブル名
６１２０・・・移動データ検索式
６１３０・・・格納先検索サーバID
６１４０・・・格納先ディレクトリ名
６２００・・・検索クエリ履歴管理表
６３００・・・移動データ候補特性管理表
６４００・・・データ移動管理表
６５００・・・特性判定ルール管理表
６６００・・・検索サーバ特性管理表
６７００・・・集約関数管理表
【図１】
2015049734.tif 000003
【図２】
2015049734.tif 000004
【図３】
2015049734.tif 000005
【図４】
2015049734.tif 000006
【図５】
2015049734.tif 000007
【図６】
2015049734.tif 000008
【図７】
2015049734.tif 000009
【図８】
2015049734.tif 000010
【図９】
2015049734.tif 000011
【図１０】
2015049734.tif 000012
【図１１】
2015049734.tif 000013
【図１２】
2015049734.tif 000014
【図１３】
2015049734.tif 000015
【図１４】
2015049734.tif 000016
【図１５】
2015049734.tif 000017
【図１６】
2015049734.tif 000018
【図１７】
2015049734.tif 000019
【図１８】
2015049734.tif 000020
【図１９】
2015049734.tif 000021
【図２０】
2015049734.tif 000022
【図２１】
2015049734.tif 000023
【国際調査報告】
2015049734.tif 000024
2015049734.tif 000025
2015049734.tif 000026
2015049734.tif 000027