(57)【要約】【課題】充分なメモリ容量が確保できず且つ計算能力が少ない省資源機器においても、インデックスを用いた検索を低メモリ容量で実施可能にする為の技術を提供すること。【解決手段】データベースから検索して得た検索データを第２のデータ形式で第２のキャッシュメモリに格納するとともに、該検索データと同じ検索結果を示すデータがすでに第１のキャッシュメモリに格納されているか否かを判断する。検索データと同じ検索結果を示すデータが第１のキャッシュメモリには格納されていない場合、該検索データへの参照を示す参照データを第１のキャッシュメモリに登録する。検索データを第１のデータ形式に変換してから出力する。【選択図】図１
2013235397.tif 000002
【特許請求の範囲】
【請求項１】
データを第１のデータ形式で格納するための第１のキャッシュメモリと、データベースから検索して得たデータを該第１のデータ形式とは異なる第２のデータ形式で格納するための第２のキャッシュメモリと、を有するデータ検索装置であって、
前記データベースから検索して得た検索データを前記第２のデータ形式で前記第２のキャッシュメモリに格納するとともに、該検索データと同じ検索結果を示すデータがすでに前記第１のキャッシュメモリに格納されているか否かを判断する手段と、
前記検索データと同じ検索結果を示すデータが前記第１のキャッシュメモリには格納されていない場合、該検索データへの参照を示す参照データを前記第１のキャッシュメモリに登録する手段と、
前記検索データを前記第１のデータ形式に変換してから出力する出力手段と
を備えることを特徴とするデータ検索装置。
【請求項２】
前記出力手段は、
前記検索データと同じ検索結果を示すデータが前記第１のキャッシュメモリにすでに格納されており、且つ該データが、前記第２のキャッシュメモリにすでに格納されている前記検索データと同データを参照するために用いる参照データである場合、該同データを前記第１のデータ形式に変換してから出力する
ことを特徴とする請求項１に記載のデータ検索装置。
【請求項３】
前記第１のデータ形式は、前記データベースへの検索を指示するアプリケーションが取り扱うデータ形式であることを特徴とする請求項１又は２に記載のデータ検索装置。
【請求項４】
前記第２のデータ形式は、前記アプリケーションからのデータ検索指示に従って前記データベースに対するデータ検索を行うデータベースエンジンが取り扱うデータ形式であることを特徴とする請求項３に記載のデータ検索装置。
【請求項５】
更に、
前記第１のキャッシュメモリに格納されている各参照データと、該参照データが参照する前記第２のキャッシュメモリないのデータと、のセットのうち削除対象を、該データへの参照を示す参照データの数もしくは参照頻度に応じて決定し、決定したセットを削除する手段を備えることを特徴とする請求項１乃至４の何れか１項に記載のデータ検索装置。
【請求項６】
データを第１のデータ形式で格納するための第１のキャッシュメモリと、データベースから検索して得たデータを該第１のデータ形式とは異なる第２のデータ形式で格納するための第２のキャッシュメモリと、を有するデータ検索装置が行うデータ検索方法であって、
前記データ検索装置の判断手段が、前記データベースから検索して得た検索データを前記第２のデータ形式で前記第２のキャッシュメモリに格納するとともに、該検索データと同じ検索結果を示すデータがすでに前記第１のキャッシュメモリに格納されているか否かを判断する工程と、
前記データ検索装置の登録手段が、前記検索データと同じ検索結果を示すデータが前記第１のキャッシュメモリには格納されていない場合、該検索データへの参照を示す参照データを前記第１のキャッシュメモリに登録する工程と、
前記データ検索装置の出力手段が、前記検索データを前記第１のデータ形式に変換してから出力する出力工程と
を備えることを特徴とするデータ検索方法。
【請求項７】
コンピュータを、請求項１乃至５の何れか１項に記載のデータ検索装置の各手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ検索技術に関するものである。
【背景技術】
【０００２】
近年のフラッシュメモリの容量の増加に伴い、デジタルスチルカメラやフォトフレーム、インクジェット複合機等、計算資源に制約がある省資源機器においても、数万件から数十万件のデータを保存できる記憶容量を持つようになっている。また、認識技術等の向上によって、人名や地名をはじめとした多様な属性値が付与可能となっており、これらの属性値を用いて、多種多量のデータ検索を高速に行う必要性が、省資源機器においても高まっている。写真データの場合、日付や撮影パラメータ、位置情報であるＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）座標などの属性値が撮影時に付与されるほか、お気に入り度合いや印刷指定等の属性値が再生時に付与される。これらの属性値を格納する枠組みとしては、Ｅｘｉｆ（Ｅｘｃｈａｎｇｅａｂｌｅ  ｉｍａｇｅ  ｆｉｌｅ  ｆｏｒｍａｔ）が代表的である。ユーザ所望のデータを検索する場合には、これらの属性値を用いることが有益である。しかしながら、データ、及び属性値が多種多量である場合に、各データに対して全走査を行って検索を行うことは計算量が膨大となり、応答時間の遅延を招いてしまう。
【０００３】
そこで、検索を高速に行えるようにするためにインデックスをあらかじめ構築しておき、検索時にインデックスを利用することで応答時間を短縮する手法が一般的である。さらに、頻繁なインデックスへのＩ／Ｏ要求を抑制するために、メモリ上にキャッシュ機構を設ける手法とも組み合わされる。検索対象となるデータは、写真や文章など多岐に渡るため、一般にそのインデックスはデータ特性に応じて特化して設計される。様々なデータに対し、インデックスの汎用的な管理・運用を行うためにデータベースエンジンが用いられる。ところで、利用者から検索要求を受け取って処理を行うアプリケーションと、アプリケーションからの指示によってインデックスの検索処理を行うデータベースエンジンでは、それぞれ内部のデータ形式が異なる。そのため、アプリケーションとデータベースエンジンではそれぞれ異なるキャッシュ機構を持つ。そのため、本質的に同じデータを指す情報を多重にキャッシュする結果を招き、メモリ消費が増大する。デジタルスチルカメラ等の計算資源が限られた組み込み機器においては、このようなメモリ消費が肥大化すると、本来の撮影機能等に必要なメモリの容量不足を招く。そのため、同時に実行可能な機能が減る上に、性能が劣化してしまう。そのため、多重にキャッシュ機構を持つ場合には、様々な検索用途に応じて適切にメモリ消費量を管理し、利用する必要のないメモリを削減する必要がある。
【０００４】
従来、多重のキャッシュ機構を持つデータ処理装置としては、例えば特許文献１のように、データベースファイルへの読み出し回数を減らすために、中央キャッシュを設置して、多重アクセスする各プロセスがそれを維持・管理する手法がある。また、特許文献２のように、高い計算能力を持ち、かつ圧縮メモリを用いる環境において、キャッシュ上に圧縮を展開したデータを配置する際に、キャッシュミスによる圧縮展開コストを減らす手法も存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１０−２２２４０７号公報
【特許文献２】特開２０００−３４７９３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、これらの先行技術は、計算資源が限定される省資源機器において実施することが困難である。なぜなら、特許文献１ではインデックスのデータを貯めこむための潤沢なメモリを、特許文献２では圧縮メモリに対してデータを圧縮、展開する計算能力を要求するためである。
【０００７】
本発明は上記の問題に鑑みてなされたものであり、充分なメモリ容量が確保できず且つ計算能力が少ない省資源機器においても、インデックスを用いた検索を低メモリ容量で実施可能にする為の技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の目的を達成するために、例えば、本発明のデータ検索装置は、データを第１のデータ形式で格納するための第１のキャッシュメモリと、データベースから検索して得たデータを該第１のデータ形式とは異なる第２のデータ形式で格納するための第２のキャッシュメモリと、を有するデータ検索装置であって、前記データベースから検索して得た検索データを前記第２のデータ形式で前記第２のキャッシュメモリに格納するとともに、該検索データと同じ検索結果を示すデータがすでに前記第１のキャッシュメモリに格納されているか否かを判断する手段と、前記検索データと同じ検索結果を示すデータが前記第１のキャッシュメモリには格納されていない場合、該検索データへの参照を示す参照データを前記第１のキャッシュメモリに登録する手段と、前記検索データを前記第１のデータ形式に変換してから出力する出力手段とを備えることを特徴とする。
【発明の効果】
【０００９】
本発明の構成によれば、充分なメモリ容量が確保できず且つ計算能力が少ない省資源機器においても、インデックスを用いた検索を低メモリ容量で実施可能にすることができる。
【図面の簡単な説明】
【００１０】
【図１】データ検索装置のハードウェア構成例を示すブロック図。
【図２】ＲＯＭ１００２、ＲＡＭ１００３、外部記憶部１００４の構成例を示す図。
【図３】データ群２００７、インデックス群２００８、データベースキャッシュ２００５、アプリケーションキャッシュ２００６の構成例を示す図。
【図４】ＧＵＩ、ＳＱＬ文を示す図。
【図５】キャッシュ間参照を説明する図。
【図６】検索処理のフローチャート。
【図７】アプリケーションキャッシュ２００６内の更新に応じた処理のフローチャート。
【図８】データベースキャッシュ２００５内の１ページ確保処理のフローチャート。
【発明を実施するための形態】
【００１１】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載の構成の具体的な実施例の１つである。
【００１２】
［第１の実施形態］
先ず、本実施形態に係るデータ検索装置のハードウェア構成例について、図１のブロック図を用いて説明する。なお、図１に示した構成は、以下に説明する各処理を実行可能な構成の一例であり、以下に説明する各処理を実行可能な構成であれば、図１に示した構成以外の構成を採用しても良い。
【００１３】
なお、本実施形態に係るデータ検索装置は、携帯電話等、メモリ資源が一般のＰＣ（パーソナルコンピュータ）などに対して比較的小さい装置であることを前提にしており、それが故に、下記の通り、使用メモリ量を出来るだけ軽減させることを目的としている。しかし、使用メモリ量を軽減させることは、メモリ資源の大小にかかわらず、必要に応じて求められることであるため、どのような装置に適用してもかまわない。
【００１４】
ＣＰＵ１００１は、ＲＯＭ１００２やＲＡＭ１００３に格納されているコンピュータプログラムやデータを用いてデータ検索装置１０００全体の動作制御を行うと共に、データ検索装置１０００が行うものとして後述する各処理を実行する。
【００１５】
ＲＯＭ１００２には図２（ａ）に示す如く、アプリケーション２００３、データベースエンジン２００２、基本システム２００１が格納されている。もちろん、ＲＯＭ１００２に格納されている情報はこれらの情報に限るものではない。
【００１６】
アプリケーション２００３は、ユーザからのデータ検索指示を受けると、該データ検索指示に基づいてＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）を生成する。そしてアプリケーション２００３は、この生成したＳＱＬ文をデータベースエンジン２００２に対して送出することで、データベースエンジン２００２にデータ検索を指示する。また、アプリケーション２００３は、データベースエンジン２００２によるデータ検索結果をユーザに提示する。
【００１７】
データベースエンジン２００２は、アプリケーション２００３からＳＱＬ文を受けると、このＳＱＬ文を解釈し、その解釈結果に応じてデータベースに対するデータ検索を行い、データ検索の結果を管理する。
【００１８】
アプリケーション２００３及びデータベースエンジン２００２は何れも、コンピュータプログラムとしてＲＯＭ１００２に格納されている。基本システム２００１は、データ検索装置１０００の基本動作用のシステムソフトウェア（データを含む）である。
【００１９】
ＲＯＭ１００２に格納されているコンピュータプログラムやデータは、ＣＰＵ１００１による制御に従って適宜ＲＡＭ１００３にロードされ、ＣＰＵ１００１による処理対象となる。
【００２０】
ＲＡＭ１００３は、図２（ｂ）に示す如く、アプリケーションキャッシュ２００６、データベースキャッシュ２００５、基本システム作業領域２００４、を有する。もちろん、ＲＡＭ１００３内に設けられるエリアは、これらのエリアに限るものではない。
【００２１】
アプリケーションキャッシュ２００６は、アプリケーション２００３が取り扱うデータ形式（第１のデータ形式）でデータを格納（キャッシュ）する為のエリア（第１のキャッシュメモリ）である。
【００２２】
データベースキャッシュ２００５は、データベースエンジン２００２（データベース）が取り扱うデータ形式（第２のデータ形式）のデータを格納（キャッシュ）する為のエリア（第２のキャッシュメモリ）である。
【００２３】
なお、アプリケーション２００３が取り扱うデータ形と、データベースエンジン２００２（データベース）が取り扱うデータ形式と、は異なる。基本システム作業領域２００４は、外部記憶部１００４やＲＯＭ１００２からロードされたコンピュータプログラムやデータ、通信部１００６が受信したコンピュータプログラムやデータ、を一時的に記憶するためのエリアを有する。また、基本システム作業領域２００４は、ＣＰＵ１００１が各種の処理を実行する際に用いるワークエリアも有する。即ち、基本システム作業領域２００４は、各種のエリアを適宜提供することができる。
【００２４】
外部記憶部１００４は、上記のデータベースの他、様々なコンピュータプログラムやデータを格納することが出来る。外部記憶部１００４には、フラッシュメモリカード、ＨＤＤ、光学ディスクなどを用いることができる。外部記憶部１００４内のデータベースには、図２（ｃ）に示す如く、データ群２００７と、データベースエンジン２００２がデータ群２００７を高速に検索するための索引情報として予め作成されたインデックス群２００８と、が格納されている。なお、データ群２００７は、画像のファイルや文書のファイルなど、様々な属性のファイルを含みうる。データ群２００７、インデックス群２００８の詳細については後述する。
【００２５】
入力部１００５は、ボタン、キーボード、マウスなどにより構成されており、ユーザが操作することで各種の指示、例えばデータ検索条件や、データ検索指示を、ＣＰＵ１００１に対して入力することが出来る。
【００２６】
通信部１００６は、有線及び／又は無線のネットワークを介して外部装置とのデータ通信を行うものであり、通信部１００６が外部装置から受信したコンピュータプログラムやデータは、外部記憶部１００４やＲＡＭ１００３に格納される。
【００２７】
表示部１００７は、ＣＰＵ１００１による処理結果を画像や文字などでもって表示することが出来る。なお、表示部１００７と入力部１００５とを一体化させて、タッチパネル式の液晶画面を構成しても良い。
【００２８】
電源部１００８は、データ検索装置１０００に必要な電源を供給するためのもので、必要に応じて外部からの給電および充電に対応する。上記の各部はバス１００９に接続されている。
【００２９】
次に、外部記憶部１００４内のデータベースに登録されているデータ群２００７、インデックス群２００８について説明する。データ群２００７に含まれているある１つの写真ファイルの構成例を図３（ａ）に示す。写真ファイルには、写真そのもののデータである画像データのほか、該写真の撮影日時や人名など、画像データの属性情報を表すメタデータが格納されている。
【００３０】
それぞれのファイルのメタデータをテーブル形式で表したものを図３（ｂ）に示す。それぞれのメタデータにはＩＤ（ＲｏｗＩＤ）が割り当てられており、ＲｏｗＩＤごとに対応するメータデータ（図３（ｂ）では、ファイル名、日付、地名、人名、イベント、ＧＰＳ座標（緯度、経度）から成るメタデータ）が存在する。
【００３１】
インデックス群２００８は、検索処理を高速化するためにそれぞれのファイルから、ファイル名、日付、地名、人名、イベント、ＧＰＳ座標（緯度、経度）等の属性（インデックス）ごとに事前に収集したデータ（インデックスデータ）から成る。図３（ｃ）に、各ファイルから事前に収集した地名のインデックスのデータ（地名インデックスデータ）の構成例を示す。図３（ｃ）に示す地名インデックスデータでは、地名とファイル名とを対応付けてツリー構造で管理している。インデックスは、Ｂ−ＴｒｅｅやＡＶＬ  Ｔｒｅｅ、ハッシュ等の論理構造を持ち、検索値と元データとを紐付けておくことで高速な検索が可能になる。
【００３２】
次に、上記のアプリケーションキャッシュ２００６、データベースキャッシュ２００５、について説明する。
【００３３】
データベースキャッシュ２００５は、図３（ｄ）に示す如く、ページと呼ばれる一定単位のブロックごとにデータを管理し、各ブロックにはヘッダ、データへのポインタ、データ本体が含まれる。
【００３４】
アプリケーションキャッシュ２００６は、図３（ｅ）に示す如く、データに固有のＩＤ、該データに対するキャッシュフラグ値、該データ本体、から成る構造体ごとに管理する。図３（ｅ）では、アプリケーションキャッシュ２００６の構造をＣ言語の構造体定義記述でもって表している。
【００３５】
上記でも述べたように、データベースキャッシュ２００５とアプリケーションキャッシュ２００６とは図３（ｄ）、（ｅ）に示すごとく、データの管理形態、即ち、同じデータを管理する場合でも、管理するデータの形式が異なる。データベースキャッシュ２００５は、ブロック管理された領域から、ヘッダ情報やレコードポインタ情報を用いて切り出したデータで構成される。一方、アプリケーションキャッシュ２００６は、アプリケーション２００３が用いるデータ構造体に基づいて構成される。それぞれに格納される属性値はデータベース、アプリケーションそれぞれの都合によって精度や文字コード、バイナリ配列順等が異なる場合もある。
【００３６】
次に、ＣＰＵ１００１がアプリケーション２００３を実行することで表示部１００７の表示画面に表示される、データ検索用のＧＵＩ（グラフィカルユーザインターフェース）の表示例を図４（ａ）に示す。
【００３７】
ユーザは入力部１００５を操作して検索条件設定領域４００１に表示されている検索条件を設定する。図４（ａ）では、「太郎」と「７月」の両方を属性として含むファイルを検索するための検索条件を設定している。検索条件を設定するための方法やそのための構成については特定の方法、構成に限らない。「太郎」と「７月」の両方を属性として含むファイルを検索するための検索条件を設定した場合に、アプリケーション２００３が生成するＳＱＬ文を図４（ｂ）に示す。
【００３８】
検索結果表示領域４００２には、検索条件設定領域４００１に設定した検索条件に基づいてデータベースから検索されたデータを表示するための領域である。この検索結果表示領域４００２に表示するものはデータ本体であっても良いし、それに加えて様々な属性を表示しても良い。また、データ本体は表示せずに、属性のみを表示しても良い。また、それらの表示形態を入力部１００５を介したユーザ入力に応じて切り替えても良い。図４（ａ）では、データ本体として画像が一覧表示されている。
【００３９】
次に、データ検索装置１０００（ＣＰＵ１００１）がアプリケーション２００３及びデータベースエンジン２００２を実行することで行うデータ検索処理について、同処理のフローチャートを示す図６を用いて説明する。
【００４０】
上記の通り、ユーザは入力部１００５を操作して検索条件設定領域４００１に検索条件を入力するので、ステップＳ６００１ではＣＰＵ１００１は、この入力された検索条件を取得する。そしてＣＰＵ１００１は、アプリケーション２００３を実行することで、この入力された検索条件からＳＱＬ文を生成し、生成したＳＱＬ文をデータベースエンジン２００２に対して供給する。
【００４１】
ステップＳ６００２では、ＣＰＵ１００１は、データベースエンジン２００２を実行することで、このＳＱＬ文に従ったデータ検索（インデックス検索）を実行する。即ち、ＳＱＬ文で指定されたインデックス（地名や人名などの属性）に対応するファイル名をインデックス群２００８から検索し、検索したファイル名を有するファイルをデータ群２００７から取得する。以下では、検索によりデータベースから得られるファイルを検索データと呼称する。そしてＣＰＵ１００１は、データ検索によりデータベースから取得した検索データを第２のデータ形式でデータベースキャッシュ２００５に格納する。
【００４２】
一方で、アプリケーション２００３が検索結果を利用者に提示するためには、この検索結果をアプリケーション２００３が取り扱うデータ形式（第１のデータ形式）でアプリケーションキャッシュ２００６に格納する必要がある。本実施形態では、アプリケーションキャッシュ２００６に格納するデータの量を削減するために、以下のような処理を行う。
【００４３】
ステップＳ６００３では、ＣＰＵ１００１は、ステップＳ６００２でデータベースキャッシュ２００５に格納した検索データと同じ検索結果を示すデータがすでにアプリケーションキャッシュ２００６に格納されているか否かを判断する。この判断処理は、アプリケーション２００３、データベースエンジン２００２の何れで行っても良い。
【００４４】
この判断では、関連付け番号によって同一視できるもの、基準値からの相対値あるいは絶対値で表現されるもの、単位変換によって導出できるもの等が挙げられる。前述した判定基準例、関連付け番号、基準値からの相対・絶対値、単位変換はいずれの手法でも、形式が異なるだけで相互に変換可能である。
【００４５】
例えば、検索データに含まれているＲｏｗＩＤと同じ若しくは規定範囲内のＲｏｗＩＤに対応するファイル若しくは該ファイルへの参照を示す参照データがすでにアプリケーションキャッシュ２００６に格納されているか否かを判断する。
【００４６】
この判断の結果、格納されていると判断された場合には、処理はステップＳ６００６に進み、格納されていなかったと判断された場合には、処理はステップＳ６００５に進む。
【００４７】
ステップＳ６００５では、ＣＰＵ１００１はアプリケーション２００３を実行し、ステップＳ６００２でデータベースキャッシュ２００５に格納した検索データへの参照を示す参照データをアプリケーションキャッシュ２００６に登録する。この参照データは参照を示す文字列情報であるため、検索データに比べてれば十分に小さいデータサイズのデータであり、アプリケーションキャッシュ２００６に検索データそのものを登録するよりも使用メモリ量は小さい。
【００４８】
そして、ステップＳ６００８では、ＣＰＵ１００１はアプリケーション２００３を実行し、ステップＳ６００２でデータベースキャッシュ２００５に格納した検索データのデータ形式を第１のデータ形式に変換する。
【００４９】
ステップＳ６００９では、ＣＰＵ１００１は、アプリケーション２００３を実行し、ステップＳ６００８でデータ形式の変換を行った検索データを用いて図４（ａ）に例示する如く、検索結果を表示する。なお、検索結果の出力先は表示部１００７に限るものではなく、ＲＡＭ１００３に格納するようにしても良いし、通信部１００６を介して外部装置に転送しても良い。
【００５０】
一方、ステップＳ６００６では、ＣＰＵ１００１は、検索データと同じ検索結果を示すデータが、データベースキャッシュ２００５にすでに格納されている検索データと同データへの参照を示す参照データであるか否かを判断する。この判断処理は、アプリケーション２００３、データベースエンジン２００２の何れで行っても良い。
【００５１】
この判断の結果、検索データと同データへの参照を示す参照データである場合には、処理はステップＳ６００８に進み、検索データと同データへの参照を示す参照データではない場合は、処理はステップＳ６００９に進む。
【００５２】
検索データと同データへの参照を示す参照データではない場合、即ち、アプリケーションキャッシュ２００６内に検索データと同データが格納されている場合、ＣＰＵ１００１はアプリケーション２００３を実行し、ステップＳ６００９の前に次の処理を行う。先ず、アプリケーションキャッシュ２００６から該同データを削除し、データベースキャッシュ２００５に格納した検索データへの参照を示す参照データをアプリケーションキャッシュ２００６に登録する。
【００５３】
一方、ステップＳ６００８では、ＣＰＵ１００１は、アプリケーション２００３を実行して、上記同データを第１のデータ形式のデータに変換する。
【００５４】
次に、アプリケーションキャッシュ２００６内を更新した場合に、データ検索装置１０００（ＣＰＵ１００１）が行う処理について、同処理のフローチャートを示す図７を用いて説明する。
【００５５】
写真撮影やデータ編集等によってデータ更新要求が発生し、アプリケーション２００３がその要求を受け付けると、ステップＳ７００１ではＣＰＵ１００１は、アプリケーション２００３を実行し、アプリケーションキャッシュ２００６内を更新する。
【００５６】
ステップＳ７００２では、ＣＰＵ１００１は、アプリケーション２００３を実行して、アプリケーションキャッシュ２００６内のデータを第２のデータ形式のデータに変換する。
【００５７】
ステップＳ７００３では、ＣＰＵ１００１は、ステップＳ７００２でデータ形式を変換したデータと同じデータがデータベースキャッシュ２００５に格納されているか否かを判断する。この判断処理は、上記のステップＳ６００３と同様にして行っても良い。この判断処理は、アプリケーション２００３、データベースエンジン２００２の何れで行っても良い。この判断の結果、格納されていると判断された場合には、処理はステップＳ７００５に進み、格納されていないと判断された場合には、処理はステップＳ７００６に進む。
【００５８】
ステップＳ７００６では、ＣＰＵ１００１は、アプリケーション２００３を実行し、ステップＳ７００２でデータ形式を変換したデータを、データベースキャッシュ２００５に登録する。
【００５９】
一方、ステップＳ７００５では、ＣＰＵ１００１は、アプリケーション２００３を実行し、ステップＳ７００２でデータ形式を変換したデータと同じデータとして特定されたデータベースキャッシュ２００５内のデータを、上記更新に合わせて更新する。例えば、ステップＳ７００１でアプリケーションキャッシュ２００６内の画像ファイル内の画像データ本体を更新したとする。この場合、データベースキャッシュ２００５内で該画像ファイルと同じＲｏｗＩＤを有する画像ファイル内の画像データ本体を更新画像データ本体と同じになるように更新する。
【００６０】
ステップＳ７００６からステップＳ７００７に処理が進んだ場合、ステップＳ７００７では、ＣＰＵ１００１は、アプリケーション２００３を実行する。これによりＣＰＵ１００１は、ステップＳ７００６でデータベースキャッシュ２００５に登録したデータへの参照を示す参照データをアプリケーションキャッシュ２００６に登録する。
【００６１】
一方、ステップＳ７００５からステップＳ７００７に処理が進んだ場合、ステップＳ７００７では、ＣＰＵ１００１は、アプリケーション２００３を実行する。これによりＣＰＵ１００１は、ステップＳ７００５で更新したデータへの参照を示す参照データをアプリケーションキャッシュ２００６に登録する。
【００６２】
ステップＳ７００８では、ＣＰＵ１００１は、アプリケーション２００３を実行し、アプリケーションキャッシュ２００６内に保持されているデータのうち、参照データ以外のデータを削除する。
【００６３】
なお、ステップＳ６００８およびステップＳ７００２において行うデータ形式変換については、写真や文書、さらにはそれらに格納される属性情報の構成によってカスタマイズできるようにする必要がある。そこで、データ形式変換手続きを外部から登録する為の機能部を別途設ける。データ形式変換は、上記のデータ形式変換手続きを用いて行う。こうすることによって任意のデータ形式に本実施形態を適用可能にする。
【００６４】
次に、上記の処理によってデータベースキャッシュ２００５、アプリケーションキャッシュ２００６の間で構築されるキャッシュ間参照について、図５を用いて説明する。アプリケーションキャッシュ２００６は、アプリケーションキャッシュ配列５００１と、アプリケーションキャッシュ実領域５００２と、を有する。また、データベースキャッシュ２００５は、データベースキャッシュ実領域５００３を有する。
【００６５】
アプリケーションキャッシュ配列５００１は、アプリケーション２００３が取得したデータを一元管理するためのメモリ配列であり、任意の検索結果のキャッシュ状態を管理する。アプリケーションキャッシュ実領域５００２は、第１のデータ形式でデータを格納するためのメモリ領域である。データベースキャッシュ実領域５００３は、第２のデータ形式でデータを格納するためのメモリ領域である。
【００６６】
登録されたデータの全件表示等、アプリケーション２００３がデータベースエンジン２００２を用いずにデータ走査を行う場合、アプリケーションキャッシュ２００６のみが利用される。このとき、アプリケーションキャッシュ実領域５００２にデータがキャッシュされることにより、データ処理が高速化される。一方、アプリケーション２００３がデータベースエンジン２００２を用いてデータ検索する場合、データベースキャッシュ２００５が利用され、データ処理が高速化される。
【００６７】
本実施形態では、上記のように、データベースキャッシュ２００５とアプリケーションキャッシュ２００６の各キャッシュに、実質的に同じデータが重複して格納されないようにキャッシュを構築する。具体的には、アプリケーションキャッシュ配列５００１には、アプリケーションキャッシュ実領域５００２又はデータベースキャッシュ実領域５００３に向けて、参照データが登録される。データを取得する際、アプリケーションキャッシュ配列５００１をたどってデータベースキャッシュ実領域５００３への参照である場合には、第１のデータ形式に変換した上で目的のデータを入手する。アプリケーションキャッシュ実領域５００２とデータベースキャッシュ実領域５００３とは、実質的に同一なデータが多重にキャッシュされないように管理される。
【００６８】
なお、データベースエンジン２００２を用いずにアプリケーションキャッシュ配列５００１を走査する場合には、取得しようとするデータの参照状況に応じてデータ取得を行う。即ち、アプリケーションキャッシュ実領域５００２、またはデータベースキャッシュ実領域５００３へのいずれかの参照をたどり、所望のデータを取得する。データベースキャッシュ実領域５００３への参照である場合には、第１のデータ形式に変換した上でデータを取得する。キャッシュの参照状況に応じてデータを取得することにより、必要となるメモリ容量を低減できる。
【００６９】
以上説明したように、本実施形態によれば、キャッシュ登録時にはアプリケーションキャッシュ２００６にデータベースキャッシュ２００５への参照のみを登録しておく。キャッシュ取得の際にはデータベースキャッシュ２００５から実体を取得し、データを変換して利用する。また、アプリケーションキャッシュ２００６のデータ更新時においては、データ形式をデータベースキャッシュ２００５用のデータ形式に変換した上で登録し、アプリケーションキャッシュ２００６のキャッシュ解放を行う。したがって、データベースエンジンを用いた検索を行う場合も、用いずにアプリケーションに完結してデータ走査を行う場合も、必要最小限のメモリ容量で処理可能となる。また、アプリケーションのデータ形式へのデータ変換が必要最小限に行われることによって、必要な計算量も最小限となる。
【００７０】
本実施形態では、アプリケーションとデータベースエンジンの間におけるキャッシュ連携を例として挙げたが、データベースキャッシュとファイルシステムキャッシュの間等、任意のキャッシュ間においても同様に適用可能である。例えば、ファイルシステムキャッシュ領域を直接データベースキャッシュが参照することによって、キャッシュ内容の複写が省略でき、メモリ容量の節約と動作速度の高速化を期待できる。
【００７１】
［第２の実施形態］
インデックスから検索するために消費されるデータベースキャッシュ２００５が枯渇し、必要容量を確保できなくなる場合がある。本実施形態ではこのような問題に鑑み、キャッシュ間の依存状況を分析した上で、分析結果に基づいてアプリケーションキャッシュに影響がないデータベースキャッシュの特定領域を解放し、解放領域を再利用することで新規領域の確保を行う。
【００７２】
本実施形態では、ＣＰＵ１００１は定期的若しくは不定期的に図８のフローチャートに従った処理を実行する。ステップＳ８００１では、ＣＰＵ１００１は、データベースキャッシュ２００５内に１ページ分の空き領域を確保するための要求を発生させる。
【００７３】
そしてステップＳ８００２では、ＣＰＵ１００１は、データベースキャッシュ２００５内に１ページ分の空き領域があるか否かを判断する。この判断の結果、データベースキャッシュ２００５内に１ページ分の空き領域が存在する場合には、処理はステップＳ８００７に進み、存在しない場合は、処理はステップＳ８００３に進む。ステップＳ８００７では、ＣＰＵ１００１は、データベースキャッシュ２００５を新規割当する。
【００７４】
なお、ＣＰＵ１００１は、データベースキャッシュ２００５内の空き容量を常に監視し、空き容量が規定量以下になれば、ステップＳ８００３からステップＳ８００６の処理を実行するようにしても良い。
【００７５】
ステップＳ８００３では、ＣＰＵ１００１は、アプリケーションキャッシュ２００６内の各参照データを参照し、参照対象となるデータベースキャッシュ２００５内のデータを特定する。
【００７６】
ステップＳ８００４では、ＣＰＵ１００１は、参照データと、該参照データにより参照されるデータと、のセットのうち削除対象を決定する。例えば、データベースキャッシュ２００５内のデータのうち、あるデータへの参照を示す参照データの数が規定数以下となるようなデータがあれば、このデータ及びこのデータへの参照データを削除対象とする。また、データベースキャッシュ２００５内のデータのうち、あるデータへの参照頻度が規定頻度以下となるようなデータがあれば、このデータ及びこのデータへの参照データを削除対象とする。
【００７７】
これらの分析はアプリケーションごとにカスタマイズできるよう、任意に外部ライブラリから定義可能にしておく。もちろん、どのデータを削除するのかの判断基準には他の基準を採用しても良い。
【００７８】
ステップＳ８００５では、ＣＰＵ１００１は、ステップＳ８００４で削除対象として決定したセットを削除することで、データベースキャッシュ２００５内に１ページ分の空き領域を確保する。そしてステップＳ８００６ではＣＰＵ１００１は、この確保した空き容量を解放する。
【００７９】
以上の処理により、装置内部の各ライブラリが消費するメモリ容量を効率的に分配することができ、動作に必要なメモリ容量を節約することができる。なお、本実施形態においてはデータベースキャッシュの内部に閉じて再利用を行う例を挙げた。この他にも、参照状況やそれぞれのキャッシュの空き容量を分析することにより、アプリケーションキャッシュの容量をデータベースキャッシュの容量として動的に振り分ける等も考えられる。こうすることで装置のメモリ資源を、利用状況に応じてメモリを必要とする機能に対して適切に分配することができ、応答性能を向上できる。
【００８０】
［第３の実施形態］
上記の各実施形態では、装置内にデータベースが備わっている構成を示したが、データベースが装置の外部に備わっているような場合、データベースキャッシュ２００５も装置の外部に備わっていることになる。しかし、このような構成であったとしても、上記の各実施形態で説明した構成はアプリケーションキャッシュ２００６の使用量を軽減させるためのものであるため、有用なものとなる。
【００８１】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013235397.tif 000003
【図２】
2013235397.tif 000004
【図３】
2013235397.tif 000005
【図４】
2013235397.tif 000006
【図５】
2013235397.tif 000007
【図６】
2013235397.tif 000008
【図７】
2013235397.tif 000009
【図８】
2013235397.tif 000010