JP2013186842A - 検索装置、検索方法、および検索プログラム - Google Patents

Abstract

【課題】移行処理の負荷の低減化を図ること。
【解決手段】初めに、検索装置１０１は、検索要求１２１を受け付ける。続けて、検索条件に合致したレコード１１２−１とレコード１１２−４について、検索装置１０１は、データストア依存識別子とデータストア非依存識別子のうちデータストア＃２へのアクセスに用いる識別子を決定する。レコード１１２−１について、検索頻度が高いため、検索装置１０１は、データストア依存識別子を用いてデータストア＃２が制御する記憶領域にアクセスする。レコード１１２−４について、検索頻度が低いため、検索装置１０１は、データストア非依存識別子と識別子生成ルールテーブル１１１内の情報を用いて、格納位置を示す識別子を生成する。続けて、検索装置１０１は、生成した識別子を用いて、データストア＃２が制御する記憶領域にアクセスする。
【選択図】図１

Description

本発明は、情報を検索する検索装置、検索方法、および検索プログラムに関する。

近年、システムの大規模化や業務の多様化に伴い、データを記憶するストレージを用いて、多種多様なデータを効率よく操作することが求められている。たとえば、複数のストレージに関する技術として、複数のストレージシステムのボリューム情報を統合して収集することにより、複数のストレージシステムの利用状況の監視を容易にするものがある（たとえば、下記特許文献１を参照。）。

特開２００５−２６７５０１号公報

しかしながら、上述した従来技術において、ストレージを割り当てるデータストアを複数用いてシステムを運用している状態において、特定のデータストアに格納されたデータを他のデータストアに移行する場合、移行負荷が大きくなる。たとえば、複数のデータストアのうちの一つのデータストアに、残余のデータストアに格納したデータへの格納位置を記憶し、移行処理を実行する装置が、残余のデータストアのうち特定のデータストアに格納されたデータを他のデータストアに移行するとする。このとき、移行処理の一部として、一つのデータストアに記憶されている、データへの格納位置を変更する処理があり、特定のデータストアに蓄積されたデータが多い場合、変更量が多くなるため、移行負荷が大きくなる。

本発明は、上述した従来技術による問題点を解消するため、移行負荷を低減できる検索装置、検索方法、および検索プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、特定の属性を有する情報群のうち検索条件に合致する情報の検索要求を受け付け、特定の属性によって指定される値の格納位置を示す第１の識別子または指定される値を識別する第２の識別子のうち少なくとも特定の属性を有する情報に基づいて特定された識別子を第１のデータストアの制御によって記憶する第１の記憶部を参照して、検索条件に合致する情報を検索し、検索された検索条件に合致する情報に基づいて、第１の識別子および第２の識別子のうち第１のデータストアとは異なる第２のデータストアの制御によって指定される値を記憶する第２の記憶部へのアクセスに用いる識別子を決定し、決定された識別子が第２の識別子である場合、第２の識別子および指定される値の格納位置の関係を示す情報と第２の識別子とに基づいて、指定される値の格納位置を示す識別子を生成し、生成された格納位置を示す識別子または第１の識別子を用いて、指定される値にアクセスする検索装置、検索方法、および検索プログラムが提案される。

本発明の一側面によれば、移行負荷の低減化を図ることができるという効果を奏する。

図１は、検索装置の動作例を示す説明図である。 図２は、データストア統合システムの接続例を示す説明図である。 図３は、検索装置のハードウェア構成例を示す説明図である。 図４は、検索装置の機能例を示すブロック図である。 図５は、データストア群の記憶内容の一例を示す説明図である。 図６は、格納方式定義ルールテーブルの記憶内容の一例を示す説明図である。 図７は、識別子生成ルールテーブルの記憶内容の一例を示す説明図である。 図８は、検索状況テーブルの記憶内容の一例を示す説明図である。 図９は、登録処理の動作例を示す説明図である。 図１０は、識別子削除処理の対象となるデータの一例を示す説明図である。 図１１は、検索処理の動作例を示す説明図である。 図１２は、移行処理の動作例を示す説明図である。 図１３は、識別子削除処理手順の一例を示すフローチャートである。 図１４は、検索処理手順の一例を示すフローチャート（その１）である。 図１５は、検索処理手順の一例を示すフローチャート（その２）である。 図１６は、移行処理手順の一例を示すフローチャート（その１）である。 図１７は、移行処理手順の一例を示すフローチャート（その２）である。

以下に添付図面を参照して、開示の検索装置、検索方法、および検索プログラムの実施の形態を詳細に説明する。

図１は、検索装置の動作例を示す説明図である。複数のデータストアを統合するデータストア統合システム１００は、ライフログデータを検索する検索装置１０１と、ライフログデータを記憶する記憶領域を制御するデータストアである、データストア＃０と、データストア＃１と、データストア＃２を有する。また、データストア統合システム１００は、識別子生成ルールテーブル１１１を有する。また、ライフログデータとは、人間の生活、行動、体験等を、映像・音声・位置情報などのデジタルデータとして記録したデータである。本実施の形態において、データストア統合システム１００は、ライフログデータの日付、歩数、ランチコメント、ランチ写真という４つの属性を蓄積する。

データストア＃０は、ライフログデータの検索インデクスを制御する。検索インデクスとは、ライフログデータを検索するための索引を示す。具体的に、データストア＃０の種別は、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ）である。データストア＃０が制御する記憶領域は、レコード１１２−１〜レコード１１２−７を記憶する。なお、レコード１１２−１〜レコード１１２−３は、検索頻度が高いレコードであるとする。検索頻度が高いレコードは、レコード数が少ないものとする。また、レコード１１２−４〜レコード１１２−７は、検索頻度が低いレコードであるとする。検索頻度が低いレコードは、レコード数が多いものとする。検索インデクスのレコードが、このような検索頻度、レコード数となる理由としては、図１０にて後述する。

また、データストア＃１の種別は、ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）である。データストア＃１が制御する記憶領域に記憶されているデータについては、図５にて後述する。さらに、データストア＃２の種別は、ファイルシステムである。データストア＃２が制御する記憶領域は、ｄａｔａディレクトリの中に、画像ファイルｆｉｌｅ＃９９と、画像ファイルｆｉｌｅ＃９８と、画像ファイルｆｉｌｅ＃８８を記憶する。データストアの種別の詳細については、図２にて後述する。

また、ライフログデータの４つの属性のうち、日付属性と歩数属性によって指定される値は、データストア＃０が制御する記憶領域に記憶される。ランチコメント属性によって指定される値は、データストア＃１が制御する記憶領域に記憶される。ランチ写真属性によって指定される値は、データストア＃２が制御する記憶領域に記憶される。なお、データストア＃０〜データストア＃２が制御する記憶領域の記憶内容の詳細については、図５にて後述する。

また、データストア＃０が制御する記憶領域には、ランチコメント属性によって指定される値とランチ写真属性によって指定される値の格納位置を示す識別子を記憶するフィールドを有する。以下、この識別子を、データストア依存識別子と呼称する。さらに、データストア＃０が制御する記憶領域には、ランチコメント属性によって指定される値とランチ写真属性によって指定される値を識別する識別子を記憶するフィールドを有する。以下、この識別子を、データストア非依存識別子と呼称する。本実施の形態で示すデータストア非依存識別子は、ランチコメント属性によって指定される値とランチ写真属性によって指定される値に同一の識別子を用いているが、異なる識別子を用意してもよい。

識別子生成ルールテーブル１１１は、データストア非依存識別子と属性によって指定される値の格納位置の関係を示す情報である。図１の例では、識別子生成ルールテーブル１１１は、データストア非依存識別子とデータストア＃２が制御する記憶領域に格納されたランチ写真属性によって指定される値の格納位置の関係を示す情報を記憶している。具体的に、識別子生成ルールテーブル１１１は、ランチ写真属性によって指定される値が、識別子フィールドを用いて“／ｄａｔａ／ｆｉｌｅ＃｛識別子｝”で示される位置に格納されていることを示している。

初めに、検索装置１０１は、検索要求１２１を受け付ける。検索要求１２１の検索条件は、歩数が５０００歩であり、かつ日付が２０１１／７／１から２０１１／８／３１である。次に、検索装置１０１は、検索要求１２１の検索条件に合致したレコードを検索する。図１の例では、検索要求１２１の検索条件に合致したレコードは、レコード１１２−１と、レコード１１２−４となる。

続けて、検索条件に合致したレコード１１２−１とレコード１１２−４について、検索装置１０１は、データストア依存識別子とデータストア非依存識別子のうちデータストア＃２へのアクセスに用いる識別子を決定する。レコード１１２−１について、検索頻度が高いため、検索装置１０１は、データストア依存識別子“／ｄａｔａ／ｆｉｌｅ＃９９”を用いてデータストア＃２が制御する記憶領域にアクセスし、画像ファイルｆｉｌｅ＃９９を取得する。

また、レコード１１２−４について、検索頻度が低いため、検索装置１０１は、識別子“８８”と識別子生成ルールテーブル１１１内の“／ｄａｔａ／ｆｉｌｅ＃｛識別子｝”を用いて、格納位置を示す識別子“／ｄａｔａ／ｆｉｌｅ＃８８”を生成する。続けて、検索装置１０１は、識別子“／ｄａｔａ／ｆｉｌｅ＃８８”を用いて、データストア＃２が制御する記憶領域にアクセスし、画像ファイルｆｉｌｅ＃８８を取得する。

このように、検索装置１０１は、検索頻度の高い情報にはデータストアでの属性の格納位置を示すデータストア依存識別子を付与し、検索頻度の低い情報には属性の識別子となるデータストア非依存識別子を付与して格納位置を生成する。これにより、検索装置１０１は、属性の移行処理には、検索頻度の高いレコードのデータストア依存識別子を変更すればよく、移行処理の負荷を低減できる。以下、検索装置１０１について、図２〜図１７を用いて詳細に説明する。

図２は、データストア統合システムの接続例を示す説明図である。データストア統合システム１００は、クライアント２０１と、クライアント２０２と、検索装置１０１と、データストア群２０３を含む。クライアント２０１と、クライアント２０２と、検索装置１０１は、ネットワーク２１０で接続されている。

クライアント２０１は、携帯電話機として、スマートフォンであってもよいし、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）であってもよいし、タブレット型端末であってもよい。クライアント２０２は、デスクトップ型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）である。検索装置１０１は、クライアント２０１またはクライアント２０２上で動作するアプリケーションソフトウェアからの検索要求に応じて、検索条件に対応する情報を取得して、アプリケーションソフトウェアに返却する。アプリケーションソフトウェアは、以下、“アプリ”と称する。

データストア群２０３は、データストア＃０〜データストア＃２を含む。データストアとは、データを決められた形式で記憶領域に記憶するソフトウェアである。図１で示したように、データストア＃０の種別は、ＲＤＢである。また、データストア＃１の種別がＫＶＳである。さらに、データストア＃２の種別は、ファイルシステムである。

ＲＤＢは、構造化した情報をテーブルに蓄積し、各カラムの値に関する条件を指定して、情報をテーブルから読み出す。ＲＤＢは、複雑な検索処理や、結果の集計処理を得意とする。ＫＶＳは、識別子となるキーに値を対応付け、キーを指定して対応する値を取得する。ＫＶＳは、ノードを追加することにより、容易にスケーラビリティを向上することが可能である。ファイルシステムは、識別子となるファイル名を指定して、コンテンツを読み書きする。ファイルシステムは、コンテンツのサイズが大きくてもよい。また、ファイルシステムは、ノードを追加することにより、容易にスケーラビリティを向上することができる。

また、ＲＤＢ、ＫＶＳ、ファイルシステム以外のデータストアとして、たとえば、全文検索エンジンがある。全文検索エンジンは、構造化されていない情報を蓄積し、フィールドの値やテキストに含まれる文字列を指定して検索する。なお、構造化されていない情報とは、たとえば、情報ごとに異なるフィールドを有していたり、１フィールドに複数の値を有していたり、または、テキスト情報である。

また、データストアはソフトウェアであるから、データストア＃０〜データストア＃２を実行する装置は、検索装置１０１であってもよいし、外部の装置であってもよい。外部の装置であれば、たとえば、外部の装置は、データストア＃０〜データストア＃２を実行して、データストア＃０〜データストア＃２それぞれが管理する記憶装置を制御する。データストア＃０〜データストア＃２を実行する装置は、同一であってもよいし、異なっていてもよい。

図２で示すように、データストア統合システム１００は、複数のデータストアを組合せて、クライアント２０１やクライアント２０２にライフログデータを利用するサービスを提供する。具体的なデータストアの組合せ方としては、ＲＤＢであるデータストア＃０が制御する記憶領域を検索インデクスとする。また、ＫＶＳであるデータストア＃１やファイルシステムであるデータストア＃２が制御する記憶領域は、ライフログデータの各属性のうち、それぞれのデータストアが最適な属性を記憶する。どのデータストアがどの属性を記憶するかについては、属性によって指定される値のサイズ、属性全体の蓄積量、値に対する更新頻度や検索条件の指定の有無等によって、データストア統合システム１００の開発者が決定する。

また、図２には示していないが、データストア統合システム１００に、データストア統合システム１００の管理者が操作する管理者端末があってもよい。または、管理者が、クライアント２０１またはクライアント２０２から管理者用のアカウントを用いてデータストア統合システム１００にログインしてもよい。

（検索装置１０１のハードウェア）
図３は、検索装置のハードウェア構成例を示す説明図である。図３において、検索装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、ＩＦ３０６と、を含む。また、各部はバス３０７によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、検索装置１０１の全体の制御を司る演算処理装置である。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される揮発性メモリである。磁気ディスクドライブ３０４は、ＣＰＵ３０１の制御に従って磁気ディスク３０５に対するデータのリード／ライトを制御する制御装置である。磁気ディスク３０５は、磁気ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発性メモリである。

ＩＦ３０６は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他の装置に接続される。そして、ＩＦ３０６は、ネットワーク２１０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。ＩＦ３０６には、たとえばモデムやＬＡＮアダプタなどを採用することができる。なお、検索装置１０１は、管理者が検索装置１０１を直接操作する場合、光ディスクドライブと、ディスプレイと、キーボードと、マウスと、を有していてもよい。

また、図３にて図示していないが、クライアント２０１は、たとえば、ＣＰＵと、ＲＡＭと、ＲＯＭと、フラッシュＲＯＭと、ディスプレイと、ＩＦを有する。フラッシュＲＯＭは、記憶内容を書き換え可能な不揮発性メモリである。また、クライアント２０１は、カメラデバイスと、センサを有してもよい。また、クライアント２０２は、たとえば、ＣＰＵと、ＲＡＭと、ＲＯＭと、磁気ディスクドライブと、磁気ディスクと、ＩＦと、光ディスクドライブと、ディスプレイと、キーボードと、マウスと、を有していてもよい。

（検索装置１０１の機能）
次に、検索装置１０１の機能について説明する。図４は、検索装置の機能例を示すブロック図である。検索装置１０１は、受付部４０１と、検索部４０２と、決定部４０３と、生成部４０４と、アクセス部４０５と、削除部４０６と、更新部４０７と、変更部４０８と、インデクスアダプタ４０９と、データストアアダプタ４１０を含む。制御部となる受付部４０１〜データストアアダプタ４１０は、記憶装置に記憶されたプログラムをＣＰＵ３０１が実行することにより、その機能を実現する。記憶装置とは、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、などである。または、ＩＦ３０６を経由して他のＣＰＵが実行することにより、その機能を実現してもよい。

また、検索装置１０１は、データストア群２０３と、格納方式定義ルールテーブル４１１と、識別子生成ルールテーブル１１１と、検索状況テーブル４１２にアクセス可能である。格納方式定義ルールテーブル４１１と、識別子生成ルールテーブル１１１と、検索状況テーブル４１２は、ＲＡＭ３０３、磁気ディスク３０５といった記憶装置に格納されている。

また、図４では、格納方式定義ルールテーブル４１１と、識別子生成ルールテーブル１１１と、検索状況テーブル４１２が、検索装置１０１の内部にあり、データストア群２０３が検索装置１０１の外部にある。格納方式定義ルールテーブル４１１と、識別子生成ルールテーブル１１１と、検索状況テーブル４１２が、検索装置１０１の外部にあってもよいし、データストア群２０３が検索装置１０１の内部にあってもよい。

受付部４０１は、特定の属性を有する情報群のうち検索条件に合致する情報の検索要求を受け付ける。たとえば、受付部４０１は、クライアント２０１上で動くアプリからの検索要求を受け付ける。

また、受付部４０１は、検索条件として属性によって指定される値が移行対象となる検索条件に合致する情報の検索要求を受け付けてもよい。移行対象となる検索条件としては、たとえば、移行対象となるランチ写真属性によって指定される値があるという検索条件であってもよいし、ランチ写真属性によって指定される値があり、かつ、管理者から指定された過去何年かまでの検索条件であってもよい。受付部４０１の機能により、検索装置１０１は、検索処理、移行処理の契機を検出することができる。なお、受け付けた検索要求は、ＲＡＭ３０３、磁気ディスク３０５といった記憶領域に記憶される。

検索部４０２は、受付部４０１によって検索要求を受け付けた場合、第１の記憶部を参照して、検索条件に合致する情報を検索する。第１の記憶部とは、たとえば、データストア＃０によって制御される記憶領域である。たとえば、検索部４０２は、アプリから受け付けた検索要求の検索条件に合致する情報を検索する。検索部４０２の機能により、検索装置１０１は、検索条件に合致するレコードを取得できる。なお、検索結果は、ＲＡＭ３０３、磁気ディスク３０５といった記憶領域に記憶される。

第１の記憶部は、特定の属性によって指定される値の格納位置を示す第１の識別子または指定される値を識別する第２の識別子のうち少なくとも特定の属性を有する情報に基づいて特定された識別子を第１のデータストアの制御によって記憶する。第１の識別子は、たとえば、データストア依存識別子である。値の格納位置は、第１の記憶部を制御するデータストアが解釈可能な識別子となる。たとえば、第１のデータストアがＫＶＳであれば、第１の識別子は、キーである。また、ファイルシステムであれば、第１の識別子は、ファイルパスである。

なお、格納位置を示す第１の識別子は、値に応じて一意となるため、値ごとに異なる。値ごとに異なるような格納位置とするため、たとえば、格納位置は、値を識別する第２の識別子を含んでもよい。または、第１の識別子は、第２の識別子を変換して得られる情報を含んでいてもよい。

また、第１の記憶部は、第１の識別子が特定された場合、第１の識別子を記憶し、第２の識別子については記憶してもよいし、記憶しなくてもよい。また、第１の記憶部は、第２の識別子が特定された場合、第２の識別子を記憶し、第１の識別子については記憶してもよいし、記憶しなくてもよい。また、具体的な特定方法は、たとえば、特定の属性を有する情報が第１の記憶部に登録された日付や、特定の属性を有する情報の検索頻度に応じて特定する。

また、第１の記憶部は、第１の識別子または第２の識別子のうち少なくとも特定の属性を有する情報が第１の記憶部に登録された日付および現在の日付の比較結果に基づいて特定された識別子を第１のデータストアの制御によって記憶する。たとえば、登録された日付と現在の日付が１か月以内であれば、第１の記憶部は、少なくとも第１の識別子を記憶する。また、たとえば、登録された日付と現在の日付が１か月を超えていれば、第１の記憶部は、少なくとも第２の識別子を記憶する。具体的には、現在の日付が“２０１１／８／３１”であり、特定の属性を有する情報が第１の記憶部に登録された日付が“２０１１／８／１”であれば、第１の記憶部は、少なくとも第１の識別子を記憶する。

また、第１の記憶部は、第１の識別子または第２の識別子のうち少なくとも特定の属性を有する情報と更新部４０７によって更新された検索条件の履歴とに基づいて特定された識別子を記憶する。検索条件の履歴は、検索状況テーブル４１２に記憶されている。たとえば、検索条件の履歴として、過去１か月以内のレコードを取得する検索条件を受け付けた回数が管理者によって指定された閾値より大きいとする。このとき、特定の属性を有する情報が過去１か月以内のレコードである場合、第１の記憶部は、少なくとも第１の識別子を記憶する。また、過去１か月以内のレコードを取得する検索条件を受け付けた回数が指定された閾値以下であり、特定の属性を有する情報が過去１か月以内のレコードである場合、第１の記憶部は、少なくとも第２の識別子を記憶する。

決定部４０３は、検索部４０２によって検索された検索条件に合致する情報に基づいて、第１の識別子および第２の識別子のうち第１のデータストアとは異なる第２のデータストアの制御によって指定される値を記憶する第２の記憶部へのアクセスに用いる識別子を決定する。第２の記憶部は、たとえば、データストア＃１によって制御される記憶領域、またはデータストア＃２によって制御される記憶領域である。第１の識別子および第２の識別子のうちどちらの識別子を用いるかについての決定方法については、たとえば、検索条件に合致する情報の第１の記憶部に登録された日付や、検索条件に合致する情報への検索頻度、または第１の識別子の有無に応じて特定する。

また、決定部４０３は、検索部４０２によって検索された検索条件に合致する情報が第１の記憶部に登録された日付および現在の日付の比較結果に基づいて、第１の識別子および第２の識別子のうち第２の記憶部へのアクセスに用いる識別子を決定してもよい。たとえば、検索されたレコードの登録された日付と現在の日付が１か月以内であれば、決定部４０３は、第２の記憶部へのアクセスに用いる識別子を第１の識別子に決定する。また、たとえば、検索されたレコードの登録された日付と現在の日付が１か月を超えていれば、決定部４０３は、第２の記憶部へのアクセスに用いる識別子を第２の識別子に決定する。

また、決定部４０３は、検索部４０２によって検索された検索条件に合致する情報が第１の識別子を有する場合、第２の記憶部へのアクセスに用いる識別子を第１の識別子に決定してもよい。たとえば、検索されたレコードが第１の識別子を有していれば、決定部４０３は、第２の記憶部へのアクセスに用いる識別子を第１の識別子に決定する。

また、決定部４０３は、検索部４０２によって検索された検索条件に合致する情報と更新部４０７によって更新された検索条件の履歴とに基づいて、第１の識別子および第２の識別子のうち第２の記憶部へのアクセスに用いる識別子を決定してもよい。

たとえば、検索条件の履歴として、過去１か月以内のレコードを取得する検索条件を受け付けた回数が管理者によって指定された閾値より大きいとする。このとき、検索されたレコードが過去１か月以内のレコードであれば、決定部４０３は、第２の記憶部へのアクセスに用いる識別子を第１の識別子に決定する。また、過去１か月以内のレコードを取得する検索条件を受け付けた回数が閾値以下であり、検索されたレコードが過去１か月以内のレコードであれば、決定部４０３は、第２の記憶部へのアクセスに用いる識別子を第２の識別子に決定する。

決定部４０３の機能により、検索装置１０１は、検索頻度が高いレコードであれば、格納位置を示す識別子を生成せずに済む第１の識別子を用いることができ、検索頻度が低いレコードであれば、移行時に変更せずに済む第２の識別子を用いることができる。また、決定結果は、ＲＡＭ３０３、磁気ディスク３０５といった記憶領域に記憶される。

生成部４０４は、決定部４０３によって決定された識別子が第２の識別子である場合、第２の識別子および指定される値の格納位置の関係を示す情報と第２の識別子とに基づいて、指定される値の格納位置を示す識別子を生成する。第２の識別子および指定される値の格納位置の関係を示す情報は、識別子生成ルールテーブル１１１で記憶される情報である。

たとえば、指定される値の格納位置の関係を示す情報は、特定の文字情報であり、文字情報の一部を第２の識別子に置き換えることにより、指定される値の格納位置を示す識別子となる情報である。具体的に、指定される値の格納位置の関係を示す情報は、“／ｄａｔａ／ｆｉｌｅ＃｛識別子｝”である。｛識別子｝を第２の識別子に置き換えることにより、生成部４０４は、指定される値の格納位置を示す識別子を生成する。なお、指定される値の格納位置の関係を示す情報は、置き換えを行う以外に、たとえば、指定される値の格納位置の関係を示す情報と、第２の識別子を結合することにより、指定される値の格納位置を示す識別子を生成できるような情報であってもよい。この場合の指定される値の格納位置の関係を示す情報は、“／ｄａｔａ／ｆｉｌｅ＃”である。

また、生成部４０４は、第２のデータストアとは異なる第３のデータストアの制御によって指定される値の第３の記憶部への格納位置を示す識別子を生成してもよい。具体的に、生成部４０４は、第２の識別子および指定される値の第３の記憶部への格納位置の関係を示す情報と、第２の識別子とから、第３の記憶部への格納位置を示す識別子を生成してもよい。

たとえば、第３の記憶部への格納位置の関係を示す情報が、“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−｛識別子｝”であり、第２の識別子が“９９”であるとする。生成部４０４は、第３の記憶部への格納位置を示す識別子を“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−９９”のように生成する。

また、検索部４０２によって検索された検索条件に合致する情報に、第２の識別子がない場合もあり得る。しかし、この場合、検索条件に合致する情報は第１の識別子を有している。したがって、生成部４０４は、第１の識別子から第２の識別子を抽出し、抽出した値と、第２の識別子および指定される値の第３の記憶部への格納位置の関係を示す情報とから、第３の記憶部への格納位置を示す識別子を生成してもよい。生成部４０４の機能により、検索装置１０１は、指定された値にアクセスすることができる。

アクセス部４０５は、生成部４０４によって生成された格納位置を示す識別子または第１の識別子を用いて、指定される値にアクセスする。たとえば、生成部４０４によって、格納位置を示す識別子である“／ｄａｔａ／ｆｉｌｅ＃８８”が生成された場合、アクセス部４０５は、“／ｄａｔａ／ｆｉｌｅ＃８８”に格納された値にアクセスする。

また、アクセス部４０５は、生成部４０４によって生成された第２の記憶部への格納位置を示す識別子または第１の識別子を用いて第２の記憶部から指定された値を読み込む。続けて、アクセス部４０５は、読み込んだ値を生成部４０４によって生成された第３の記憶部への格納位置を示す識別子を用いて第３の記憶部へ書き込む。たとえば、アクセス部４０５は、識別子“／ｄａｔａ／ｆｉｌｅ＃９９”を用いて指定された値を第２の記憶部から読み込む。続けて、アクセス部４０５は、識別子“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−９９”を用いて指定された値を第３の記憶部に書き込む。アクセス部４０５の機能により、検索装置１０１は、検索処理または移行処理の対象となった値にアクセスできる。

削除部４０６は、第１の記憶部に記憶された特定の属性を有する情報に基づいて、特定の属性を有する情報が有する第１の識別子を削除する。削除部４０６は、たとえば、特定の属性を有する情報の第１の記憶部に登録された日付や、特定の属性を有する情報への検索頻度に応じて、第１の識別子を削除する。具体的には、特定の属性を有する情報の登録された日付と現在の日付が１か月より離れていれば、削除部４０６は、特定の属性を有する情報の第１の識別子を削除する。

なお、特定の属性を有する情報に第２の識別子がない状態で第１の識別子を削除する場合、削除部４０６は、第１の識別子に含まれる第２の識別子を抽出し、抽出した値を第１の記憶部に書き込んでから、第１の識別子を削除する。削除部４０６の機能により、検索装置１０１は、第１の記憶部の記憶量を削減することができる。

更新部４０７は、受付部４０１によって検索要求を受け付けた場合、検索条件の履歴を更新する。検索条件の履歴は、第１の識別子を削除する。たとえば、受付部４０１が過去１か月以内という検索条件を有する検索要求を受け付けた場合、更新部４０７は、１か月以内の検索条件を受け付けた回数をインクリメントする。更新部４０７の機能により、検索装置１０１は、実際に検索された検索状況を用いることができる。

変更部４０８は、決定部４０３によって決定された識別子が第１の識別子である場合、第１の記憶部に記憶された第１の識別子を、生成部４０４によって生成された第３の記憶部への格納位置を示す識別子に変更する。たとえば、変更部４０８は、第１の記憶部に記憶された第１の識別子“／ｄａｔａ／ｆｉｌｅ＃９９”を生成部４０４によって生成された識別子“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−９９”に変更する。変更部４０８の機能により、検索装置１０１は、移行先のデータストアに書き込んだ値にアクセスできる。

インデクスアダプタ４０９は、検索インデクスごとのプロトコルやデータ形式の違いを吸収して、同一のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）で検索インデクスとなるデータストア＃０にアクセスできるようにするソフトウェアである。また、データストアアダプタ４１０は、データストアごとのプロトコルやデータ形式の違いを吸収して、同一のＡＰＩでデータストア＃１やデータストア＃２にアクセスできるようにするソフトウェアである。

図５は、データストア群の記憶内容の一例を示す説明図である。本実施の形態で示すデータストア統合システム１００は、ライフログデータを蓄積する。図５に示すデータストア＃０が制御する記憶領域は、レコード１１２−１〜レコード１１２−７を記憶する。また、図５に示すデータストア＃１が制御する記憶領域は、レコード５０１−１〜レコード５０１−３を記憶する。さらに、図５に示すデータストア＃２が制御する記憶領域は、画像ファイルｆｉｌｅ＃９９、画像ファイルｆｉｌｅ＃９８を記憶する。さらに、レコード１１２−１〜レコード１１２−３は、検索頻度が高いレコードであるとする。また、レコード１１２−４〜レコード１１２−７は、検索頻度が低いレコードであるとする。

データストア＃０が制御する記憶領域は、日付、歩数、識別子、ランチコメント、ランチ写真という５つのフィールドを有する。日付フィールドは、対象となるレコードが、ユーザの操作によるアプリによって登録された日、またはセンサが情報を登録した日を格納する。なお、日付フィールドは、時刻を含んでいてもよい。歩数フィールドは、日付フィールドで指定された日におけるユーザの歩数を格納する。識別子フィールドは、ランチコメントフィールドとランチ写真フィールドによって指定される値を識別するデータストア非依存識別子である。具体的に、識別子フィールドは、ランチコメントフィールドに格納される識別子およびランチ写真フィールドに格納される識別子のシリアル番号である。具体的には、識別子フィールドは、１から採番される数値である。

ランチコメントフィールドは、日付フィールドで指定された日におけるランチに対するユーザのコメントとなる文字情報の格納位置を示す識別子である。具体的には、文字情報は、データストア＃１が制御する記憶領域内に格納されている。ランチ写真フィールドは、日付フィールドで指定された日におけるランチを写した画像情報の格納情報を示す識別子である。具体的には、画像情報は、データストア＃２に格納されている。

データストア＃１が制御する記憶領域は、識別子となるキーと、キーに対応するランチコメントと、いう２つのフィールドを有する。ＫＶＳの仕様上、キーフィールドには任意の文字列が設定可能である。本実施の形態の例では、キーフィールドには、データストア＃０が制御する記憶領域内の対応するレコード内のランチコメントフィールドと同一の文字列が設定されるとする。ランチコメントフィールドには、ランチに対するユーザのコメントとなる文字情報が設定される。たとえば、レコード５０１−１は、キーが“ｋｅｙ＃９９”であり、ランチコメントが“美味”であることを示す。

データストア＃２が制御する記憶領域は、ディレクトリ構造を有する。図５で示すデータストア＃２が制御する記憶領域は、“ｄａｔａ”ディレクトリ内にユーザのランチを写した画像情報が格納されている。画像情報は、たとえば、画像ファイルｆｉｌｅ＃９９、画像ファイルｆｉｌｅ＃９８である。画像ファイルｆｉｌｅ＃９９の識別子はファイルパスとなる“／ｄａｔａ／ｆｉｌｅ＃９９”である。画像ファイルｆｉｌｅ＃９８の識別子はファイルパスとなる“／ｄａｔａ／ｆｉｌｅ＃９８”である。

たとえば、レコード１１２−１は、“２０１１／８／３１”におけるライフログデータの歩数属性が５０００歩であることを示す。また、レコード１１２−１は、ランチコメント属性によって指定される値となる文字情報が、データストア依存識別子であるランチコメントフィールド“ｋｅｙ＃９９”が示すレコード５０１−１より“美味”であることを示す。また、レコード１１２−１は、ランチ写真属性によって指定される値となる画像情報が、ランチ写真フィールド“／ｄａｔａ／ｆｉｌｅ＃９９”が示すファイルパスを有する画像ファイルｆｉｌｅ＃９９であることを示す。

図６は、格納方式定義ルールテーブルの記憶内容の一例を示す説明図である。図６に示す格納方式定義ルールテーブル４１１は、レコード４１１−１〜レコード４１１−３を記憶している。なお、格納方式定義ルールテーブル４１１の１レコード分の情報を、格納方式定義ルール情報と呼称する。格納方式定義ルールテーブル４１１は、属性名、格納先という２つのフィールドを含む。属性名フィールドには、ライフログデータの属性名が格納される。格納先フィールドには、属性によって指定される値が格納されている記憶領域を制御するデータストアの識別情報が格納される。

たとえば、レコード４１１−１は、ライフログデータの属性のうち、日付属性と歩数属性によって指定される値が、データストア＃０が制御する記憶領域に格納されていることを示す。また、レコード４１１−２は、ライフログデータの属性のうち、ランチコメント属性によって指定される値が、データストア＃１が制御する記憶領域に格納されていることを示す。同様に、レコード４１１−３は、ランチ写真属性によって指定される値が、データストア＃２が制御する記憶領域に格納されていることを示す。

図７は、識別子生成ルールテーブルの記憶内容の一例を示す説明図である。図７に示す識別子生成ルールテーブル１１１は、レコード１１１−１、レコード１１１−２を記憶している。なお、識別子生成ルールテーブル１１１の１レコード分の情報を、識別子生成ルールと呼称する。識別子生成ルールテーブル１１１は、格納先、識別子生成ルールという２つのフィールドを含む。格納先フィールドには、ライフログデータの属性によって指定値の格納先となる記憶領域を制御するデータストア名が格納される。識別子生成ルールフィールドには、データストア非依存識別子および指定される値の格納位置の関係を示す情報が格納される。

たとえば、レコード１１１−１は、データストア＃１の識別子生成ルールが、“ｋｅｙ＃｛識別子｝”であることを示す。具体的に、データストア非依存識別子が１であれば、検索装置１０１は、データストア依存識別子を、“ｋｅｙ＃１”のように生成する。

図８は、検索状況テーブルの記憶内容の一例を示す説明図である。図８に示す検索状況テーブル４１２は、レコード４１２−１〜レコード４１２−３を記憶している。なお、検索状況テーブル４１２の１レコード分の情報を、検索状況情報と呼称する。検索状況テーブル４１２は、期間、検索回数という２つのフィールドを含む。期間フィールドには、検索条件の中の期間が格納される。検索回数フィールドには、該当の期間に対して検索された回数が格納される。

たとえば、レコード４１２−１は、アプリからの検索条件が１か月以内であった回数が、１００回であることを示す。また、レコード４１２−２は、アプリからの検索条件が半年以内であった回数が、５０回であることを示す。続けて、図５〜図８で示した記憶内容を用いて、検索装置１０１が行う、登録処理、検索処理、識別子削除処理、移行処理の動作例を、図９〜図１２に示す。

図９は、登録処理の動作例を示す説明図である。図９では、データストア群２０３へのライフログデータの登録処理について説明する。ライフログデータ９０１は、たとえば、ユーザによって操作されたクライアント２０１上で動作するアプリ、またはクライアント２０１内のセンサによって生成される。具体的に、データストア＃０が制御する記憶領域の日付フィールドに格納される値は、ユーザによるアプリの操作日となる。また、歩数フィールドに格納される値は、センサによってカウントされた値となる。データストア＃１が制御する記憶領域のランチコメントに格納される情報は、ユーザによるアプリの操作によって生成された情報である。データストア＃２が制御する記憶領域の画像ファイルは、ユーザによる操作によって検索装置１０１のカメラデバイスが生成したファイルである。

たとえば、図９では、ライフログデータ９０１は、日付が“２０１１／８／３１”であり、歩数が５０００歩であり、ランチコメントが“美味”であり、ランチ写真が画像ファイル９０２であるとしている。

アプリは、ライフログデータ９０１を検索装置１０１に送信する。ライフログデータ９０１を受け付けた検索装置１０１は、データストア＃０が制御する記憶領域に新規レコードとなるレコード１１２−１を追加する。次に、検索装置１０１は、レコード１１２−１の日付フィールドに“２０１１／８／３１”を格納する。また、検索装置１０１は、レコード１１２−１の歩数フィールドに、“５０００”を格納する。さらに、検索装置１０１は、レコード１１２−１の識別子フィールドに検索装置１０１が採番した“９９”を格納する。

続けて、検索装置１０１は、識別子“９９”を用いて、データストア依存識別子である“ｋｅｙ＃９９”を生成して、レコード１１２−１のランチコメントフィールドに、生成したデータストア依存識別子を格納する。同様に、検索装置１０１は、識別子“９９”を用いて、データストア依存識別子である“／ｄａｔａ／ｆｉｌｅ＃９９”を生成して、レコード１１２−１のランチ写真フィールドに、生成したデータストア依存識別子を格納する。

さらに、検索装置１０１は、データストア＃１に、キーフィールドが“ｋｅｙ＃９９”であり、ランチコメントフィールドが“美味”であるレコード５０１−１を追加する。続けて、検索装置１０１は、データストア＃２の、“／ｄａｔａ／ｆｉｌｅ＃９９”となるファイルパスに、画像ファイル９０２を格納する。格納された画像ファイルは、図５で示した画像ファイルｆｉｌｅ＃９９と同一である。

図１０は、識別子削除処理の対象となるデータの一例を示す説明図である。図１０では、データストア群２０３にて、データストア依存識別子を削除する対象について説明する。グラフ１００１は、データストア群２０３への検索回数を示している。グラフ１００１の横軸は、日付を示す。グラフ１００１の縦軸は、検索回数を示す。

グラフ１００１が示すように、データストア群２０３に格納されているライフログデータのうち、最新のライフログデータから、図１０で示す最頻検索期間に含まれるライフログデータが、検索回数が多くなる傾向にある。最頻検索期間とは、現日付から一定期間前の日付とする。一定期間は、たとえば、１週間、１か月等である。このように、検索回数がライフログデータで偏る理由として、クライアント２０１上のアプリが表示する情報、または検索する情報は、最新のライフログデータから一定期間までのライフログデータとなることが多いためである。なお、最頻検索期間に含まれるライフログデータの数は少なく、最頻検索期間以降のライフログデータの数は多い。

したがって、データストア＃０が制御する記憶領域のレコード群のうち、最頻検索期間に含まれるレコードに関して、検索装置１０１は、データストア依存識別子とデータストア非依存識別子を保存する。また、最頻検索期間以降のレコードに関して、検索装置１０１は、データストア非依存識別子を保存して、データストア依存識別子を削除する。

これにより、検索対象になる可能性の高い、最頻検索期間に含まれるレコードはデータストア依存識別子を有しており、データストア依存識別子を生成しなくてよいため、検索装置１０１は、検索性能を向上できる。また、移行時において、検索装置１０１は、最頻検索期間に含まれるレコードのデータストア依存識別子を変更することになるが、最頻検索期間に含まれるレコードは数が少ないため、移行負荷を小さくすることができる。

また、最頻検索期間以降のレコードはデータストア非依存識別子を有しており、移行時に変更を要するデータストア依存識別子を有していない。最頻検索期間以降のレコードは数が多いため、移行時において、検索装置１０１は、移行負荷を低減することができる。また、検索時において、検索装置１０１は、最頻検索期間以降のレコードのデータストア依存識別子を生成することになるが、最頻検索期間以降のレコードは検索対象となる機会が少ないため、検索性能への影響を小さくすることができる。

図１１は、検索処理の動作例を示す説明図である。図１１では、データストア群２０３への検索処理について説明する。検索装置１０１は、検索要求を受け付けると、データストア＃０に検索要求を通知する。データストア＃０は、自身が制御する記憶領域に格納しているレコード群のうち、検索要求の検索条件に合致するレコードを抽出する。図１１では、レコード１１２−１〜レコード１１２−７が検索条件に合致するレコードであるとする。

レコード１１２−１〜レコード１１２−７を取得した検索装置１０１は、ランチコメントフィールドとランチ写真フィールド、または識別子フィールドのいずれかを用いてランチコメント属性によって指定される値とランチ写真属性によって指定される値を取得する。なお、図１１と図１２では、説明の簡略化のため、ランチ写真によって指定される値を取得する場合について説明する。ランチコメント属性によって指定される値の取得方法も、ランチ写真属性によって指定される値の取得方法と同一であるため、図１１での表記を省略する。

図１１では、レコード１１２−１〜レコード１１２−３に関して、検索装置１０１は、検索頻度が高いと判断したとする。また、レコード１１２−４〜レコード１１２−７に関して、検索装置１０１は、検索頻度が低いと判断したとする。ここで、具体的な判断基準としては、たとえば、検索装置１０１は、日付フィールドが最頻検索期間内に含まれるレコードを、検索頻度が高いレコードであると判断してもよい。図１１で示す例は、最頻検索期間を１か月に設定した例となる。または、検索状況テーブル４１２を参照して、検索回数が特定の閾値以上となる期間に含まれるレコードを、検索頻度が高いレコードであると判断してもよい。

また、検索頻度が高いか否かの他の判断方法として、検索装置１０１は、データストア依存識別子の値の有無に応じて判断してもよい。この判断方法を用いた場合、検索装置１０１は、レコード１１２−１〜レコード１１２−４を検索頻度が高いと判断する。また、検索装置１０１は、データストア依存識別子となるランチコメントフィールドとランチ写真フィールドに“（削除済）”という値が格納されているレコード１１２−５〜レコード１１２−７を検索頻度が低いと判断する。

レコード１１２−１〜レコード１１２−３に関して、検索頻度が高いため、検索装置１０１は、ランチコメントフィールドとランチ写真フィールドを用いてランチコメント属性によって指定される値とランチ写真属性によって指定される値を取得する。たとえば、ランチ写真に関して、検索装置１０１は、ランチ写真フィールドに格納されているファイルパスを用いて、ランチ写真属性によって指定される値となる画像ファイルを取得する。

レコード１１２−４〜レコード１１２−７に関して、検索頻度が低いため、検索装置１０１は、識別子フィールドを用いてランチコメント属性によって指定される値とランチ写真属性によって指定される値を取得する。たとえば、ランチ写真に関して、検索装置１０１は、識別子フィールドと、ランチ写真が格納されているデータストア＃２の識別子生成ルールを用いて、ランチ写真属性によって指定される値となる画像ファイルを取得する。具体的には、レコード１１２−４に関して、検索装置１０１は、識別子生成ルール“／ｄａｔａ／ｆｉｌｅ＃｛識別子｝”の｛識別子｝を“８８”に置き換えて、画像ファイルの格納位置を示す識別子“／ｄａｔａ／ｆｉｌｅ＃８８”を生成する。次に、検索装置１０１は、生成した識別子“／ｄａｔａ／ｆｉｌｅ＃８８”を用いて、ランチ写真属性によって指定される値となる画像ファイルを取得する。

図１２は、移行処理の動作例を示す説明図である。図１２では、データストア群２０３の移行処理について説明する。図１２で行う移行処理は、ランチ写真属性によって指定される値となる画像ファイルを格納するデータストアを、データストア＃２からデータストア＃３に移行するとする。なお、データストア＃３は、データストアの種別がファイルシステムであるとする。

また、移行処理を行う機会として、たとえば、データストア統合システム１００の運用開始時には、ファイルシステムとして、開発コストや運用コストの低いローカルファイルシステムにライフログデータの特定の属性によって指定される値を格納していたとする。しかし、運用を続けていくうちに、指定される値の記憶量が増加したため、スケーラビリティが高い分散ファイルシステムに特定の属性によって指定される値を移行するといった場合である。また、移行処理を行う他の機会としては、データストア統合システム１００を利用するユーザが増大したため、ファイルシステムの階層を追加し、ユーザグループ単位でディレクトリを分けるように変更する場合である。

図１２では、移行元の情報が記載された格納方式定義ルールテーブル４１１を、格納方式定義ルールテーブル４１１＿Ｓとして示す。また、移行先の情報が記載された格納方式定義ルールテーブル４１１を、格納方式定義ルールテーブル４１１＿Ｄとして示す。また、移行元の情報が記載された識別子生成ルールテーブル１１１を、識別子生成ルールテーブル１１１＿Ｓとして示す。また、移行先の情報が記載された識別子生成ルールテーブル１１１を、識別子生成ルールテーブル１１１＿Ｄとして示す。

具体的に、格納方式定義ルールテーブル４１１＿Ｓのレコード４１１−３＿Ｓは、ランチ写真属性によって指定される値が移行元となるデータストア＃２に格納されていることを示す。また、格納方式定義ルールテーブル４１１＿Ｄのレコード４１１−３＿Ｄは、ランチ写真属性によって指定される値が移行先となるデータストア＃３に格納することを示す。さらに、識別子生成ルールテーブル１１１＿Ｓのレコード１１１−２＿Ｓは、データストア＃２での識別子生成ルールが、“／ｄａｔａ／ｆｉｌｅ＃｛識別子｝”であることを示す。また、識別子生成ルールテーブル１１１＿Ｄのレコード１１１−２＿Ｄは、データストア＃３での識別子生成ルールが、“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−｛識別子｝”であることを示す。

図１２では、レコード１１２−１〜レコード１１２−３に関して、検索装置１０１は、検索頻度が高いと判断したとする。また、レコード１１２−４〜レコード１１２−７に関して、検索装置１０１は、検索頻度が低いと判断したとする。検索頻度の判断基準は、図１１で示した判断基準と同一であるため、説明を省略する。

レコード１１２−１〜レコード１１２−３に関して、検索頻度が高いため、検索装置１０１は、ランチ写真フィールドの値をデータストア＃２での格納位置を示す値から、データストア＃３での格納位置を示す値に変更する。具体的に、レコード１１２−１に関して、検索装置１０１は、ランチ写真フィールドの値を“／ｄａｔａ／ｆｉｌｅ＃９９”から“／ｄａｔａ／ｕｓｒ１／ｆｉｌｅ−９９”に変更する。また、検索装置１０１は、ランチ写真属性によって指定される値となる画像ファイルをデータストア＃２からデータストア＃３に移動する。次に、図１０〜図１２で示した動作を行うフローチャートについて、図１３〜図１７を用いて説明する。

図１３は、識別子削除処理手順の一例を示すフローチャートである。図１３では、データストア＃０に対する識別子削除処理の一例について説明する。識別子削除処理は、検索装置１０１が有するタイマの満了によって定期的に実行されてもよい。または、識別子削除処理は、管理者による指示によって実行されてもよい。また、検索装置１０１は、識別子削除処理を実行した際の対象データの最新日付を記録している。

検索装置１０１は、検索状況テーブル４１２から検索状況情報を取得する（ステップＳ１３０１）。次に、検索装置１０１は、前回の識別子削除処理の対象データの最新日付を読み出す（ステップＳ１３０２）。なお、前回の識別子削除処理の対象データの最新日付が記憶されていない場合もありうる。この場合、検索装置１０１は、データストア＃０が記憶する記憶領域のレコード群の日付フィールドのうち、最も古い日付を前回の識別子削除処理の対象データの最新日付とする。

続けて、検索装置１０１は、格納方式定義ルールテーブル４１１から、格納方式定義ルール情報を取得する（ステップＳ１３０３）。次に、検索装置１０１は、データストア＃０が制御する記憶領域の日付フィールドが前回の識別子削除処理の対象データの最新日付より新しいレコード群から、最頻検索期間に含まれないレコードを検索する（ステップＳ１３０４）。

続けて、検索装置１０１は、検索結果が空か否かを判断する（ステップＳ１３０５）。検索結果が空でない場合（ステップＳ１３０５：Ｎｏ）、検索装置１０１は、検索結果の各レコードのデータストア依存識別子を削除する（ステップＳ１３０６）。次に、検索装置１０１は、識別子削除処理の対象データの最新日付を記憶する（ステップＳ１３０７）。ステップＳ１３０７の実行終了後、または検索結果が空である場合（ステップＳ１３０５：Ｙｅｓ）、検索装置１０１は、識別子削除処理を終了する。このように、図１３で示した識別子削除処理は、読み出されることがないデータストア依存識別子を削除することになり、データストア＃０が制御する記憶領域の記憶量を減らすことができる。

図１４は、検索処理手順の一例を示すフローチャート（その１）である。図１４と図１５では、データストア群２０３への検索処理の一例について説明する。検索装置１０１は、アプリから検索要求を受け付ける（ステップＳ１４０１）。次に、検索装置１０１は、格納方式定義ルールテーブル４１１から、格納方式定義ルール情報を取得する（ステップＳ１４０２）。続けて、検索装置１０１は、格納方式定義ルール情報を取得できたか否かを判断する（ステップＳ１４０３）。取得できなかった場合（ステップＳ１４０３：Ｎｏ）、検索装置１０１は、エラーをアプリに返却する（ステップＳ１４０４）。ステップＳ１４０４の処理を終了後、検索装置１０１は、検索処理を終了する。

取得できた場合（ステップＳ１４０３：Ｙｅｓ）、検索装置１０１は、検索条件に応じて、検索状況テーブル４１２を更新する（ステップＳ１４０５）。ステップＳ１４０５の処理について、たとえば、検索条件が１か月以内である場合、検索装置１０１は、レコード４１２−１の検索回数フィールドの値をインクリメントする。また、検索条件が半年以内である場合、検索装置１０１は、レコード４１２−２の検索回数フィールドの値をインクリメントする。

続けて、検索装置１０１は、検索インデクスから検索条件に合致するレコードを検索する（ステップＳ１４０６）。次に、検索装置１０１は、検索結果が空か否かを判断する（ステップＳ１４０７）。検索結果が空である場合（ステップＳ１４０７：Ｙｅｓ）、検索装置１０１は、空の検索結果をアプリに返却する（ステップＳ１４０８）。ステップＳ１４０８の処理を終了後、検索装置１０１は、検索処理を終了する。

検索結果が空でない場合（ステップＳ１４０７：Ｎｏ）、検索装置１０１は、検索結果のレコード群のうち、先頭のレコードを選択する（ステップＳ１４０９）。ステップＳ１４０９の処理を終了後、検索装置１０１は、図１５で示すステップＳ１５０１の処理に移行する。

図１５は、検索処理手順の一例を示すフローチャート（その２）である。ステップＳ１４０９の処理を終了後、検索装置１０１は、選択されたレコード内の属性によって指定される値について、検索インデクス内のデータストア依存識別子を用いるか否かを判断する（ステップＳ１５０１）。なお、ステップＳ１５０１の処理である検索インデクス内のデータストア依存識別子を用いるか否かの判断方法は、たとえば、図１０で示した選択されたレコードの日付フィールドを参照する方法である。

検索インデクス内のデータストア依存識別子を用いない場合（ステップＳ１５０１：Ｎｏ）、検索装置１０１は、識別子生成ルールテーブル１１１から、識別子生成ルール情報を取得する（ステップＳ１５０２）。次に、検索装置１０１は、取得した識別子生成ルール情報を用いて、データストア依存識別子を生成する（ステップＳ１５０３）。

次に、検索装置１０１は、ステップＳ１５０３の処理で生成したデータストア依存識別子、または検索インデクス内のデータストア依存識別子を用いて（ステップＳ１５０１：Ｙｅｓ）、データストア群２０３から属性によって指定される値を取得する（ステップＳ１５０４）。続けて、検索装置１０１は、検索結果のレコード群全てについて属性によって指定される値を取得したか否かを判断する（ステップＳ１５０５）。属性によって指定される値を取得していないレコードがある場合（ステップＳ１５０５：Ｎｏ）、検索装置１０１は、検索結果のレコード群のうち次のレコードを選択する（ステップＳ１５０６）。ステップＳ１５０６の終了後、検索装置１０１は、ステップＳ１５０１の処理に移行する。

検索結果のレコード群全てについて属性によって指定される値を取得した場合（ステップＳ１５０５：Ｙｅｓ）、検索装置１０１は、取得した値を集約する（ステップＳ１５０７）。次に、検索装置１０１は、集約した値をアプリに返却する（ステップＳ１５０８）。ステップＳ１５０８の処理を終了後、検索装置１０１は、検索処理を終了する。このように、図１４と図１５で示した検索処理は、アプリが要求した検索要求に対応する検索結果を返却することができる。

図１６は、移行処理手順の一例を示すフローチャート（その１）である。図１６と図１７では、データストア群２０３の移行処理の一例について説明する。検索装置１０１は、管理者端末から移行要求を受け付ける（ステップＳ１６０１）。次に、検索装置１０１は、格納方式定義ルールテーブル４１１から、移行元および移行先の格納方式定義ルール情報を取得する（ステップＳ１６０２）。続けて、検索装置１０１は、移行元および移行先の格納方式定義ルール情報を取得できたか否かを判断する（ステップＳ１６０３）。

取得できなかった場合（ステップＳ１６０３：Ｎｏ）、検索装置１０１は、エラーを管理者端末に返却する（ステップＳ１６０４）。ステップＳ１６０４の処理終了後、検索装置１０１は、移行処理を終了する。取得できた場合（ステップＳ１６０３：Ｙｅｓ）、検索装置１０１は、検索インデクスから検索条件に合致したレコードを検索する（ステップＳ１６０５）。なお、ステップＳ１６０５の検索条件は、たとえば、検索インデクスのレコード群のうち、移行対象となる属性によって指定される値を有するという検索条件であってもよいし、検索インデクスのレコード群全てという検索条件であってもよい。

次に、検索装置１０１は、検索結果のレコード群のうち、先頭のレコードを選択する（ステップＳ１６０６）。ステップＳ１６０６の処理を実行後、検索装置１０１は、図１７に示すステップＳ１７０１の処理に移行する。

図１７は、移行処理手順の一例を示すフローチャート（その２）である。検索装置１０１は、選択されたレコード内の属性によって指定される値について、検索インデクス内のデータストア依存識別子を用いるか否かを判断する（ステップＳ１７０１）。なお、ステップＳ１７０１の処理である検索インデクス内のデータストア依存識別子を用いるか否かの判断方法は、たとえば、図１０で示した選択されたレコードの日付フィールドを参照する方法である。

検索インデクス内のデータストア依存識別子を用いない場合（ステップＳ１７０１：Ｎｏ）、検索装置１０１は、移行元のデータストア依存識別子を生成する（ステップＳ１７０２）。続けて、検索装置１０１は、移行先のデータストア依存識別子を生成する（ステップＳ１７０３）。次に、検索装置１０１は、移行元および移行先のデータストア依存識別子を用いて、移行元データストアから移行先データストアへ属性によって指定される値を移行する（ステップＳ１７０４）。ステップＳ１７０４の具体的な処理として、検索装置１０１は、移行元のデータストア依存識別子を用いて、移行元データストアが制御する記憶領域から指定された値を読み込む。続けて、検索装置１０１は、移行先のデータストア依存識別子を用いて、移行先データストアが制御する記憶領域に読み込んだ値を書き込む。

検索インデクス内のデータストア依存識別子を用いる場合（ステップＳ１７０１：Ｙｅｓ）、検索装置１０１は、移行先のデータストア依存識別子を生成する（ステップＳ１７０５）。次に、検索装置１０１は、検索インデクス内のデータストア依存識別子および移行先のデータストア依存識別子を用いて、移行元データストアから移行先データストアへ属性によって指定される値を移行する（ステップＳ１７０６）。ステップＳ１７０６の具体的な処理として、検索装置１０１は、検索インデクス内のデータストア依存識別子を用いて、移行元データストアが制御する記憶領域から指定された値を読み込む。続けて、検索装置１０１は、移行先のデータストア依存識別子を用いて、移行先データストアが制御する記憶領域に読み込んだ値を書き込む。続けて、検索装置１０１は、検索インデクス内のデータストア依存識別子を、生成した移行先のデータストア依存識別子に変更する（ステップＳ１７０７）。

ステップＳ１７０４、またはステップＳ１７０７の処理を実行後、検索装置１０１は、検索結果のレコード群全てについて属性によって指定される値を移行したか否かを判断する（ステップＳ１７０８）。属性によって指定される値を移行していないレコードがある場合（ステップＳ１７０８：Ｎｏ）、検索装置１０１は、次のレコードを選択する（ステップＳ１７０９）。ステップＳ１７０９の実行終了後、検索装置１０１は、ステップＳ１７０１の処理に移行する。

検索結果のレコード群全てについて属性によって指定される値を移行した場合（ステップＳ１７０８：Ｙｅｓ）、検索装置１０１は、移行結果を管理者端末に返却する（ステップＳ１７１０）。ステップＳ１７１０の処理終了後、検索装置１０１は、移行処理を終了する。このように、図１６と図１７で示した移行処理は、管理者端末が要求した移行要求に対応する属性によって指定される値の移行処理を行うことができる。

以上説明したように、検索装置、検索方法、および検索プログラムによれば、検索頻度の高い情報にはデータストアでの属性によって指定される値の格納位置を付与し、低い情報には属性によって指定される値の識別子を付与して格納位置を求める。

これにより、検索装置は、特定のデータストアに格納されたデータを他のデータストアに移行する場合、検索インデクス内のデータストア依存識別子を変更するレコード数が検索インデクス全てのレコード数より少なくなるため、移行負荷を低減できる。移行負荷が低減できることにより、たとえば、検索装置は、移行処理中の登録処理、または検索処理の性能低下を抑制することができる。また、検索装置は、検索頻度の高いレコードに関して、データストア依存識別子を有しているため、データストア依存識別子を生成しなくてよく、検索性能を向上できる。このように、検索装置は、検索インデクスの移行負荷の低減と検索性能の向上という両立を達成することができる。

また、検索装置は、検索条件に合致する情報が登録された日付と現在の日付の比較結果に基づいて、データストア依存識別子とデータストア非依存識別子のうちどちらの識別子を用いてデータストアが制御する記憶領域にアクセスするかを決定してもよい。これにより、検索装置は、実際の検索状況を取得せず日付の比較という単純な処理によって、検索頻度が高いレコードを特定できる。

また、検索装置は、検索条件に合致する情報にデータストア依存識別子があれば、データストア依存識別子を用いてデータストアが制御する記憶領域にアクセスするかを決定してもよい。この場合、検索頻度が低い情報については、データストア非依存識別子を付与しておかないこととする。これにより、検索装置は、比較処理も行わずに検索頻度が高いレコードを特定できる。

また、検索装置は、検索条件の履歴を更新し、検索条件の履歴を用いてデータストア依存識別子とデータストア非依存識別子のうちどちらの識別子を用いてデータストアが制御する記憶領域にアクセスするかを決定してもよい。これにより、検索装置は、実際の検索状況に応じて、検索頻度が高いレコードを特定できる。

また、検索装置は、データストア依存識別子とデータストア非依存識別子のうち少なくとも特定の属性を有する情報が登録された日付と現在の日付の比較結果に基づいて特定された識別子を記憶してもよい。これにより、検索装置は、実際の検索状況を取得せず日付の比較という単純な処理によって、検索頻度が高い情報についてはデータストア依存識別子を用いてアクセスするように設定することができる。

また、検索装置は、検索条件の履歴を更新し、検索条件の履歴を用いてデータストア依存識別子とデータストア非依存識別子のうち少なくとも特定の属性を有する情報が登録された日付と現在の日付の比較結果に基づいて特定された識別子を記憶してもよい。これにより、検索装置は、実際の検索状況に応じて、検索頻度が高い情報についてはデータストア依存識別子を用いてアクセスするように設定することができる。

また、検索装置は、特定の属性を有する情報に基づいて、データストア依存識別子を削除してもよい。これにより、検索装置は、データストア依存識別子を記憶する検索インデクスの記憶量を低減できる。

また、検索装置は、移行対象となる検索条件に合致する情報を検索し、データストア依存識別子を用いてアクセスする情報について、データストア依存識別子を移行元から移行先に変更する。データストア非依存識別子を用いてアクセスする情報については変更しなくてよいため、検索装置は、移行処理の負荷を従来の検索装置より低減することができる。

なお、本実施の形態で説明した検索方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本検索プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本検索プログラムは、インターネット等のネットワークを介して配布してもよい。

＃０，＃１，＃２ データストア
１０１ 検索装置
１１１ 識別子生成ルールテーブル
４０１ 受付部
４０２ 検索部
４０３ 決定部
４０４ 生成部
４０５ アクセス部
４０６ 削除部
４０７ 更新部
４０８ 変更部
４１１ 格納方式定義ルールテーブル
４１２ 検索状況テーブル

Claims (11)

1. 特定の属性を有する情報群のうち検索条件に合致する情報の検索要求を受け付ける受付部と、
   前記受付部によって前記検索要求を受け付けた場合、前記特定の属性によって指定される値の格納位置を示す第１の識別子または前記指定される値を識別する第２の識別子のうち少なくとも前記特定の属性を有する情報に基づいて特定された識別子を第１のデータストアの制御によって記憶する第１の記憶部を参照して、前記検索条件に合致する情報を検索する検索部と、
   前記検索部によって検索された前記検索条件に合致する情報に基づいて、前記第１の識別子および前記第２の識別子のうち前記第１のデータストアとは異なる第２のデータストアの制御によって前記指定される値を記憶する第２の記憶部へのアクセスに用いる識別子を決定する決定部と、
   前記決定部によって決定された識別子が前記第２の識別子である場合、前記第２の識別子および前記指定される値の格納位置の関係を示す情報と前記第２の識別子とに基づいて、前記指定される値の格納位置を示す識別子を生成する生成部と、
   前記生成部によって生成された格納位置を示す識別子または前記第１の識別子を用いて、前記指定される値にアクセスするアクセス部と、
   を有することを特徴とする検索装置。
2. 前記決定部は、
   前記検索部によって検索された前記検索条件に合致する情報が前記第１の記憶部に登録された日付および現在の日付の比較結果に基づいて、前記第１の識別子および前記第２の識別子のうち前記第２の記憶部へのアクセスに用いる識別子を決定することを特徴とする請求項１に記載の検索装置。
3. 前記決定部は、
   前記検索部によって検索された前記検索条件に合致する情報が前記第１の識別子を有する場合、前記第２の記憶部へのアクセスに用いる識別子を前記第１の識別子に決定することを特徴とする請求項１に記載の検索装置。
4. 前記受付部によって前記検索要求を受け付けた場合、前記検索条件の履歴を更新する更新部を有し、
   前記決定部は、
   前記検索部によって検索された前記検索条件に合致する情報と前記更新部によって更新された前記検索条件の履歴とに基づいて、前記第１の識別子および前記第２の識別子のうち前記第２の記憶部へのアクセスに用いる識別子を決定することを特徴とする請求項１に記載の検索装置。
5. 前記第１の記憶部は、
   前記第１の識別子または前記第２の識別子のうち少なくとも前記特定の属性を有する情報が前記第１の記憶部に登録された日付および現在の日付の比較結果に基づいて特定された識別子を第１のデータストアの制御によって記憶することを特徴とする請求項１〜４のいずれか一つに記載の検索装置。
6. 前記受付部によって前記検索要求を受け付けた場合、前記検索条件の履歴を更新する更新部を有し、
   前記第１の記憶部は、
   前記第１の識別子または前記第２の識別子のうち少なくとも前記特定の属性を有する情報と前記更新部によって更新された前記検索条件の履歴とに基づいて特定された識別子を第１のデータストアの制御によって記憶することを特徴とする請求項１〜３のいずれか一つに記載の検索装置。
7. 前記第１の記憶部は、
   前記第１の識別子または前記第２の識別子のうち少なくとも前記特定の属性を有する情報と前記更新部によって更新された前記検索条件の履歴とに基づいて特定された識別子を第１のデータストアの制御によって記憶することを特徴とする請求項４に記載の検索装置。
8. 前記第１の記憶部に記憶された前記特定の属性を有する情報に基づいて、前記特定の属性を有する情報が有する前記第１の識別子を削除する削除部を有することを特徴とする請求項１〜７のいずれか一つに記載の検索装置。
9. 前記受付部は、
   前記検索条件として前記指定される値が移行対象となる検索条件に合致する情報の検索要求を受け付け、
   前記生成部は、
   さらに、前記第２のデータストアとは異なる第３のデータストアの制御によって前記指定される値の移行先となる第３の記憶部への格納位置を示す識別子を生成し、
   前記アクセス部は、
   前記生成部によって生成された前記第２の記憶部への格納位置を示す識別子または前記第１の識別子を用いて前記第２の記憶部から前記指定された値を読み込んで、読み込んだ値を前記生成部によって生成された前記第３の記憶部への格納位置を示す識別子を用いて前記第３の記憶部へ書き込み、
   前記決定部によって決定された識別子が前記第１の識別子である場合、前記第１の記憶部に記憶された前記第１の識別子を、前記第３の記憶部への格納位置を示す識別子に変更する変更部を有することを特徴とする請求項１〜８のいずれか一つに記載の検索装置。
10. コンピュータが、
    特定の属性を有する情報群のうち検索条件に合致する情報の検索要求を受け付け、
    前記検索要求を受け付けた場合、前記特定の属性によって指定される値の格納位置を示す第１の識別子または前記指定される値を識別する第２の識別子のうち少なくとも前記特定の属性を有する情報に基づいて特定された識別子を第１のデータストアの制御によって記憶する第１の記憶部を参照して、前記検索条件に合致する情報を検索し、
    検索した前記検索条件に合致する情報に基づいて、前記第１の識別子および前記第２の識別子のうち前記第１のデータストアとは異なる第２のデータストアの制御によって前記指定される値を記憶する第２の記憶部へのアクセスに用いる識別子を決定し、
    決定した識別子が前記第２の識別子である場合、前記第２の識別子および前記指定される値の格納位置の関係を示す情報と前記第２の識別子とに基づいて、前記指定される値の格納位置を示す識別子を生成し、
    生成した格納位置を示す識別子または前記第１の識別子を用いて、前記指定される値にアクセスする、
    処理を実行することを特徴とする検索方法。
11. コンピュータに、
    特定の属性を有する情報群のうち検索条件に合致する情報の検索要求を受け付け、
    前記検索要求を受け付けた場合、前記特定の属性によって指定される値の格納位置を示す第１の識別子または前記指定される値を識別する第２の識別子のうち少なくとも前記特定の属性を有する情報に基づいて特定された識別子を第１のデータストアの制御によって記憶する第１の記憶部を参照して、前記検索条件に合致する情報を検索し、
    検索した前記検索条件に合致する情報に基づいて、前記第１の識別子および前記第２の識別子のうち前記第１のデータストアとは異なる第２のデータストアの制御によって前記指定される値を記憶する第２の記憶部へのアクセスに用いる識別子を決定し、
    決定した識別子が前記第２の識別子である場合、前記第２の識別子および前記指定される値の格納位置の関係を示す情報と前記第２の識別子とに基づいて、前記指定される値の格納位置を示す識別子を生成し、
    生成した格納位置を示す識別子または前記第１の識別子を用いて、前記指定される値にアクセスする、
    処理を実行させることを特徴とする検索プログラム。

Images