図面 (/)

技術 事前検索処理装置

出願人 株式会社日立製作所
発明者 吉田功藤本弘士小菅恭之久保拓也芝田浩
出願日 2007年6月1日 (12年8ヶ月経過) 出願番号 2007-146433
公開日 2008年12月11日 (11年2ヶ月経過) 公開番号 2008-299685
状態 拒絶査定
技術分野 検索装置
主要キーワード 応答処理プログラム 検索処理装置 応答性能 検索処理プログラム 非同期通信 更新頻度 メニュ 集積回路化
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2008年12月11日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (15)

課題

キャッシュ技術を利用しても、クライアントからの検索要求頻度よりデータの更新頻度の方が高い場合には、キャッシュの利用率が低下し、処理時間が長くなってしまうという課題があった。そのために、クライアントから検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮する。

解決手段

クライアントがある検索要求を送信する前に高い確率で行われるアクションアプリケーションサーバが検知した場合に、その後で受信すると予想する検索要求に対応する検索処理事前に行い、クライアントから、その検索要求を受信した場合に事前に検索した結果を返信する。

概要

背景

IT技術の発展情報化社会進展に伴い、ネットワークを介してアクセスするデータ量も膨大になってきている。一般的にデータベースに格納するデータ量が多くなればなるほど、データベースの検索処理に要する時間も長くなるため、クライアント検索要求を送信してから結果を取得するまでの時間が長くなってしまう。

特許文献1では、この問題を解決するために、キャッシュ技術を利用している。以前に検索した結果をキャッシュに保持しておき、クライアントが要求するデータがキャッシュにある場合はキャッシュのデータをクライアントに返信することにより、処理時間を短縮することが可能になる。

特開2000-222272

概要

キャッシュ技術を利用しても、クライアントからの検索要求の頻度よりデータの更新頻度の方が高い場合には、キャッシュの利用率が低下し、処理時間が長くなってしまうという課題があった。そのために、クライアントから検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮する。 クライアントがある検索要求を送信する前に高い確率で行われるアクションアプリケーションサーバが検知した場合に、その後で受信すると予想する検索要求に対応する検索処理を事前に行い、クライアントから、その検索要求を受信した場合に事前に検索した結果を返信する。

目的

従来の検索処理装置は、クライアントからの検索要求の頻度よりデータの更新頻度の方が低い場合にはキャッシュの利用率が高くなり、検索要求から検索結果を返信するまでの処理時間を短縮できるが、反対にデータの更新頻度の方が高い場合には、キャッシュの利用率が低下するために処理時間が長くなってしまう課題があった。
本発明はこの課題を解決することを目的とする。

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

検索要求の前に行われる入出力要求の種類を定義した事前アクションリスト事前検索の状況を示すプレ検索情報、および事前アクションリストに定義している入出力要求と検索要求の履歴に基づいて、事前アクションリストに定義している入出力要求の後に同じ検索条件の検索要求を受信する確率を事前アクションリストと検索条件ごとに示すアクション履歴統計、事前に検索を行うかどうかを判断する基準値を示すプレ検索閾値、検索結果が有効であるかどうかを判断する基準値を示す検索結果有効時間を記憶する記憶部と、事前アクションリストに定義している入出力要求を受信した場合に当該入出力要求の後に高い確率で行われる検索条件をアクション履歴統計から取得し、当該検索が行われる確率がプレ検索閾値の値以上である場合に当該検索条件で検索を行い、プレ検索情報を登録するプレ検索判定処理部と、検索要求を受信した場合に当該検索要求の検索条件と一致するプレ検索情報がある場合にプレ検索情報を利用して検索結果を返信する検索処理部と、を有することを特徴とする事前検索処理装置。

請求項2

請求項1に記載の事前検索処理装置において、前記アクション履歴統計の確率を、事前アクションリストに定義している入出力要求を受信してから同じ検索条件の検索要求を受信するまでの時間間隔が規定された時間間隔の下限値以上でかつ規定された時間間隔の上限値以内である確率として算出することを特徴とする事前検索処理装置。

請求項3

請求項1に記載の事前検索処理装置において、前記検索処理部は、事前の検索の検索条件と検索要求の検索条件が一致しない場合でかつ検索要求の検索条件が事前の検索の検索条件と追加の検索条件のAND条件になっている場合に、事前の検索の結果に対して追加の検索条件で再検索を行うことを特徴とする事前検索処理装置。

技術分野

0001

本発明は、クライアントが指定する検索条件に該当するデータをデータベースから取得してクライアントに返信する検索処理装置に関するものである。

背景技術

0002

IT技術の発展情報化社会進展に伴い、ネットワークを介してアクセスするデータ量も膨大になってきている。一般的にデータベースに格納するデータ量が多くなればなるほど、データベースの検索処理に要する時間も長くなるため、クライアントが検索要求を送信してから結果を取得するまでの時間が長くなってしまう。

0003

特許文献1では、この問題を解決するために、キャッシュ技術を利用している。以前に検索した結果をキャッシュに保持しておき、クライアントが要求するデータがキャッシュにある場合はキャッシュのデータをクライアントに返信することにより、処理時間を短縮することが可能になる。

0004

特開2000-222272

発明が解決しようとする課題

0005

従来の検索処理装置は、クライアントからの検索要求の頻度よりデータの更新頻度の方が低い場合にはキャッシュの利用率が高くなり、検索要求から検索結果を返信するまでの処理時間を短縮できるが、反対にデータの更新頻度の方が高い場合には、キャッシュの利用率が低下するために処理時間が長くなってしまう課題があった。
本発明はこの課題を解決することを目的とする。

課題を解決するための手段

0006

本発明はアプリケーションサーバがクライアントから検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮するため、クライアントがある検索要求を送信する前によく行うアクション(以降、事前アクションと呼ぶ)をアプリケーションサーバが検知したときに、その後で受信すると予想する検索要求に対応する検索処理を事前に行い、クライアントからその検索要求を受信した場合に事前に行った検索処理の結果を利用して検索結果をクライアントに返信することを主要な特徴とする。

発明の効果

0007

本発明の検索処理装置では、アプリケーションサーバが検索処理を事前に行うことによりクライアントから検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮できるという利点がある。

発明を実施するための最良の形態

0008

本発明をWebアプリケーションに適用した場合の実施例について図面を用いて説明する。

0009

アプリケーションサーバ300は、図1に示すように応答処理部301、プレ検索判定処理部302、検索処理部304、事前アクションリスト311、プレ検索情報312、アクション履歴313、アクション履歴統計314、プレ検索閾値315、検索結果有効時間316を有する。

0010

応答処理部301、プレ検索判定処理部302、検索処理部304は、メモリやHDDなどの記憶部に格納された応答処理プログラム、プレ検索判定処理プログラム検索処理プログラムを、それぞれCPUが実施することで実現される。なお、これらの処理部は、各処理を行う処理部として集積回路化するなどしてハードウェアで実現することもできる。

0011

また、事前アクションリスト311、プレ検索情報312、アクション履歴313、アクション履歴統計314、プレ検索閾値315、検索結果有効時間316は、メモリやHDDなどの記憶部に格納されている。

0012

事前アクションリスト311は、図2に示すようにクライアント200において検索前に行う画面操作の中で検索要求を予測するのに適している画面操作(以後、事前アクションと呼ぶ)を定義したものである。プルダウンDを選択3114やテキスト入力など、通常はアプリケーションサーバ300との通信が発生しない事前アクションを事前アクションリスト311に登録する場合は、JavaScriptの非同期通信などを利用してアプリケーションサーバ300に事前アクションを通知させる。

0013

プレ検索情報312は、図3に示すようにユーザID3121、検索条件3122、検索開始時間3123、検索結果参照3124を有するデータである。

0014

アクション履歴313は、図4に示すようにユーザID3131、事前アクション3132、検索条件3133を有するデータである。

0015

アクション履歴統計314は、図5に示すようにユーザID3141、事前アクション3142、検索条件3143、プレ検索有効確率3144を有するデータである。アクション履歴313が図4である場合を例にして、ユーザID3141が”001”、 かつ事前アクション3142が”メニューAを選択”、かつ検索条件3143が”P=p1”であるアクション履歴統計314のプレ検索有効確率3144の算出方法を説明する。当該プレ検索有効確率3144は、ユーザID3131が”001”、かつ事前アクション3132が”メニューAを選択”、かつ検索条件3133が”P=p1”であるアクション履歴313の件数(1件)をユーザID3131が”001”、かつ事前アクション3132が”メニューAを選択”であるアクション履歴313の件数(4件)で割ることで算出する。アクション履歴統計314は、アクション履歴313が更新されたとき、またはアクション履歴統計314が参照されるとき、または定期的に算出する。

0016

プレ検索閾値315は、図6に示すように事前に検索を行うかどうかの判断基準となる確率の値である。

0017

検索結果有効時間316は、図7に示すように事前に行った検索の結果を利用するかどうかの判断基準となる時間間隔の上限値である。

0018

応答処理部301は、図8に示すようにステップS101でクライアント200から受信するデータからユーザIDと画面操作の種類を抽出する。次にステップS102の判定処理において、抽出した画面操作の種類が事前アクションリスト311に登録されている事前アクションである場合はステップS103に進み、抽出した画面操作の種類が検索を要求するアクション(以後、検索アクションと呼ぶ)である場合はステップS104に進み、事前アクションでも検索アクションでもない場合はステップS105に進む。ステップS103ではユーザID3131と事前アクション3132の値が当該事前アクションを行ったユーザIDと当該事前アクションと等しく、かつ検索条件3133の値がセットされていないアクション履歴313が存在しなければ、当該ユーザIDと当該事前アクションをユーザID3131と事前アクション3132としてアクション履歴313に登録し、当該ユーザIDと当該事前アクションを引数としてプレ検索判定処理部302を実行する。ステップS104では検索アクションを実行したユーザIDと当該検索アクションの検索条件を引数として検索処理部304を実行する。また、ユーザID3131の値が当該ユーザIDと一致するアクション履歴313のレコードの検索条件3133を当該検索条件で更新する。最後にステップS105において応答データを生成し、当該クライアント200に返信する。

0019

プレ検索判定処理部302は、図9に示すようにステップS201でユーザID3121の値が引数のユーザIDと等しいプレ検索情報312のレコードを検索し、レコードが存在しない場合はステップS202に進み、レコードが存在する場合は当該レコードの検索開始時間3123から現在時刻までの時間間隔を算出し、当該時間間隔が検索結果有効時間316以内であればプレ検索判定処理を終了し、当該時間間隔が検索結果有効時間316を超過している場合は当該レコードを削除してステップS202に進む。次にステップS202でアクション履歴統計314を参照し、ユーザID3141と事前アクション3142が引数のユーザIDと引数の事前アクションと等しいアクション履歴統計314のレコードの中でプレ検索有効確率3144の値が最も高いレコードの検索条件3143とプレ検索有効確率3144を取得する。次にステップS203で当該プレ検索有効確率3144の値がプレ検索閾値315以上であるかどうか判定し、プレ検索閾値315以上である場合はステップS204に進み、プレ検索閾値315に満たない場合はプレ検索判定処理を終了する。ステップS204ではステップS202で取得した検索条件に基づいてデータベースサーバ400に対して事前に検索処理(以後、プレ検索と呼ぶ)を実行し、当該ユーザID、当該検索条件、当該プレ検索の検索開始時間、当該プレ検索の検索結果への参照をそれぞれユーザID3121、検索条件3122、検索開始時間3123、検索結果参照3124としてプレ検索情報312に登録する。

0020

検索処理部304は、図10に示すようにステップS401でユーザID3121の値が引数のユーザIDと一致するプレ検索情報312のレコードを検索し、レコードが存在する場合はステップS402に進み、レコードが存在しない場合はステップS406に進む。ステップS402で当該レコードの検索開始時間3123から現在時刻までの時間間隔が検索結果有効時間316以内である場合はステップS403に進み、当該時間間隔が検索結果有効時間316を超過している場合はステップS405に進む。

0021

ステップS403で当該レコードの検索条件3143の値が引数の検索条件と一致する場合はステップS404に進み、検索条件が一致しない場合はステップS406に進む。ステップS404では、当該レコードの検索結果参照3124の値が参照している検索結果を取得する。ステップS405では当該レコードを削除し、ステップS406に進む。ステップS406では引数のユーザIDと引数の検索条件でデータベースサーバ400に対して検索処理を実行し、検索結果を取得する。

0022

本実施例ではアクションのパターンの傾向がユーザIDごとに異なるケースを想定して、アクション履歴313やアクション履歴統計314をユーザIDごとに保持しているが、アクションのパターンの傾向がユーザグループ権限の種類ごとに異なるケースでは、アクション履歴313やアクション履歴統計314をユーザグループや権限の種類ごとに保持すると効果的である。また全てのユーザIDで傾向に差がないケースではアクション履歴313やアクション履歴統計314をユーザIDごとに保持する必要はなく、システムで共通的に保持すればよい。

0023

本実施例では、プレ検索有効確率3144が高い場合にプレ検索を行うことにより、クライアント200から検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮できる。

0024

次に実施例1のプレ検索を行うかどうかの判断基準に、アプリケーションサーバ300Bが事前アクションを検知してから検索アクションを検知するまでの時間間隔を含める場合の実施例について、実施例1と異なる部分を中心に図面を用いて説明する。

0025

本実施例におけるアプリケーションサーバ300Bは、図11に示すように応答処理部301、プレ検索判定処理部302、検索処理部304、事前アクションリスト311、プレ検索情報312、アクション履歴313B、アクション履歴統計314、プレ検索閾値315、検索結果有効時間316、時間下限値317を有する。

0026

時間下限値317、アクション履歴313Bは、事前アクションリスト311などと同様に、メモリやHDDなどの記憶部に格納されている。

0027

時間下限値317は、図12に示すように事前に行った検索の結果を利用するかどうかの判断基準となる時間間隔の下限値である。

0028

本実施例のアクション履歴313Bは、実施例1のアクション履歴313に対して、検知日時3134、時間間隔3135、時間判定結果3136を追加している。検知日時3134の値は、アプリケーションサーバ300Bが事前アクション3132を検知した日時である。

0029

時間間隔3135の値は、アプリケーションサーバ300Bが事前アクション3132を検知してから検索条件3133の検索アクションを検知するまでの時間間隔である。時間判定結果3136の値は、時間間隔3135が時間下限値317以上かつプレ検索閾値315以下という時間間隔の条件を満たす場合は”OK”、 時間間隔の条件を満たさない場合は”NG”となる。

0030

アクション履歴統計314のデータ構造は実施例1と同じであるが、算出方法が異なる。アクション履歴313Bが図13である場合を例にして、ユーザID3141が”001”、 かつ事前アクション3142が”メニューAを選択”、かつ検索条件3143が”P=p1”であるアクション履歴統計314のプレ検索有効確率3144の算出方法を説明する。
当該プレ検索有効確率3144は、ユーザID3131が”001”、かつ事前アクション3132が”メニューAを選択”、かつ検索条件3133が”P=p1”、かつ時間判定結果3136が”OK”であるアクション履歴313Bの件数をユーザID3131が”001”、かつ事前アクション3132が”メニューAを選択”であるアクション履歴313の件数で割ることで算出する。

0031

応答処理部301に関して実施例1と異なる部分は、次の2点である。1点目はステップS103でアクション履歴313Bを登録する際、登録する事前アクション3132を検知した日時を検知日時3134としてアクション履歴313Bに登録することである。2点目はステップS104でアクション履歴313Bを更新する際、更新するアクション履歴313Bのレコードの時間間隔3135、時間判定結果3136を事前アクション3132を検知してから検索条件3133の検索アクションを検知するまでの時間間隔と、当該時間間隔3135が時間下限値317以上かつプレ検索閾値315以下であるかどうかの判定結果で更新することである。

0032

本実施例では、事前アクションと検索アクションの時間間隔が時間下限値317以上かつプレ検索閾値315以下である確率が高い事前アクションを検知した場合にプレ検索を行うことにより、無駄なプレ検索を行われないため、より効果的にクライアント200から検索要求を受信してから検索結果をクライアントに返信するまでの時間を短縮できる。

0033

次に実施例1の検索処理において検索条件が一致しない場合でも、検索アクションの検索条件がプレ検索の検索条件を含んでいる場合に、プレ検索の検索結果に対して再検索する実施例について、実施例1と異なる部分を説明する。

0034

本実施例が実施例1と異なる部分は検索処理部304Cの処理フローである。
検索処理部304Cは、図14に示すようにステップS403において当該レコードの検索条件3143の値が引数の検索条件と一致しない場合にステップS407に進む。ステップS407で当該レコードの検索条件3143と引数の検索条件を比較し、引数の検索条件が当該レコードの検索条件3143と追加の検索条件とのAND条件になっている場合はステップS408に進み、そうでない場合はステップS406に進む。ステップS407で当該レコードの検索結果参照3124が参照する検索結果に対して、当該追加の検索条件で検索し、その検索結果を取得する。

0035

本実施例では、検索アクションの検索条件がプレ検索の検索条件を含んでいる場合に、プレ検索の検索結果に対してさらに絞込検索することにより、検索条件が一致しない場合でも検索結果を早く取得できるようになる。

0036

Webブラウザ画面に検索結果を表示する場合だけでなく、ファイル出力してダウンロードする場合やPDF出力する場合にも応用できる。また、Webアプリケーションに適用する場合だけでなく、検索処理の応答性能を向上させる必要がある任意のシステムに応用できる。

図面の簡単な説明

0037

事前検索の実施方法を示した説明図である。(実施例1)
事前アクションのリストを示した説明図である。(実施例1)
プレ検索の情報を示した説明図である。(実施例1)
アクションの履歴を示した説明図である。(実施例1)
アクション履歴統計を示した説明図である。(実施例1)
プレ検索閾値を示した説明図である。(実施例1)
検索結果有効時間を示した説明図である。(実施例1)
応答処理のフローを示した説明図である。(実施例1)
プレ検索判定処理のフローを示した説明図である。(実施例1)
検索処理のフローを示した説明図である。(実施例1)
事前検索の実施方法を示した説明図である。(実施例2)
時間下限値を示した説明図である。(実施例2)
実施例2におけるアクション履歴を示した説明図である。(実施例2)
実施例2における検索処理のフローを示した説明図である。(実施例2)

符号の説明

0038

100通信ネットワーク
200クライアント
300アプリケーションサーバ
301応答処理部
302プレ検索判定処理部
304検索処理部
311事前アクションリスト
312プレ検索情報
313アクション履歴
314アクション履歴統計
315 プレ検索式閾値
316検索結果有効時間
317 時間下限値
400 データベースサーバ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ