特許第6626810号(P6626810)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧
特許6626810外部データベース収容装置、方法及びプログラム
<>
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000003
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000004
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000005
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000006
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000007
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000008
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000009
  • 特許6626810-外部データベース収容装置、方法及びプログラム 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6626810
(24)【登録日】2019年12月6日
(45)【発行日】2019年12月25日
(54)【発明の名称】外部データベース収容装置、方法及びプログラム
(51)【国際特許分類】
   G06F 16/951 20190101AFI20191216BHJP
【FI】
   G06F16/951
【請求項の数】4
【全頁数】14
(21)【出願番号】特願2016-198333(P2016-198333)
(22)【出願日】2016年10月6日
(65)【公開番号】特開2018-60415(P2018-60415A)
(43)【公開日】2018年4月12日
【審査請求日】2018年11月28日
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100103034
【弁理士】
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100075672
【弁理士】
【氏名又は名称】峰 隆司
(74)【代理人】
【識別番号】100179062
【弁理士】
【氏名又は名称】井上 正
(72)【発明者】
【氏名】辻 真彦
(72)【発明者】
【氏名】永徳 真一郎
(72)【発明者】
【氏名】片山 幸久
【審査官】 後藤 彰
(56)【参考文献】
【文献】 特開2010−015432(JP,A)
【文献】 特開2000−163440(JP,A)
【文献】 特開2014−232350(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/951
(57)【特許請求の範囲】
【請求項1】
取得対象とするデータを一意に識別できる複数のリクエストを1つ以上のシステムから受け付ける外部データベースからリクエストに対する応答を得る外部データベース収容装置であって、
前記外部データベースにおいてある頻度以上に参照されるデータと同一のデータである更新対象情報と、この更新対象情報の有効期限を含む更新情報とを保存している保持部を備え、
前記保持部は、データを取得するための取得リクエストを前記外部データベースが受け付けるより前に受け付け、
前記取得リクエストに対応する更新対象情報があれば、前記取得リクエストを送信したシステムにこの更新対象情報を送信し
記保持部に格納されている更新対象情報の前記更新情報に含まれる有効期限が切れているかを判断し、有効期限が切れている場合には前記外部データベースから対応する更新対象情報を取得して、この更新対象情報が更新されているかどうかを判定する処理部をさらに備え、
前記保持部は、前記更新対象情報が更新されている場合には、更新情報に含まれる有効期限を更新し、更新された更新情報と更新された更新対象情報とを格納する外部データベース収容装置。
【請求項2】
前記有効期限は、更新情報自動生成間隔に応じて決定され、更新を検知した確率である更新ヒット率の前回と前々回との差分から、更新間隔の最適化の指標となるF値が改善したかどうかの推定に基づいて、前記更新情報自動生成間隔を調整する請求項に記載の外部データベース収容装置。
【請求項3】
取得対象とするデータを一意に識別できる複数のリクエストを1つ以上のシステムから受け付ける外部データベースからリクエストに対する応答を得る外部データベース収容方法であって、
前記外部データベースにおいてある頻度以上に参照されるデータと同一のデータである更新対象情報と、この更新対象情報の有効期限を含む更新情報とを保存するステップを備え、
前記ステップでは、データを取得するための取得リクエストを前記外部データベースが受け付けるより前に受け付け、
前記取得リクエストに対応する更新対象情報があれば、前記取得リクエストを送信したシステムにこの更新対象情報を送信し
記保存するステップで格納されている更新対象情報の前記更新情報に含まれる有効期限が切れているかを判断し、有効期限が切れている場合には前記外部データベースから対応する更新対象情報を取得して、この更新対象情報が更新されているかどうかを判定するステップをさらに備え、
前記保存するステップでは、前記更新対象情報が更新されている場合には、更新情報に含まれる有効期限を更新し、更新された更新情報と更新された更新対象情報とを格納する外部データベース収容方法。
【請求項4】
コンピュータを、請求項1または2に記載の外部データベース収容装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、外部データベース収容装置、方法及びプログラムに関する。
【背景技術】
【0002】
リクエストに応じて別システムで使用している外部データベース(以下、外部DBとも称す)に随時問い合わせを実施し、リクエストに応答するシステムがある(例えば、非特許文献1参照)。例えば、端末からあるデータを要求するリクエストを別のシステムに行い、このシステムが外部DBへの問い合わせを実施する。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】中山 陽太郎, “PostgreSQLを活用した仮想データ統合基盤の実現”, UNISYS TECHNOLOGY REVIEW, 第111号, pp.25-37, 2012.3
【発明の概要】
【発明が解決しようとする課題】
【0004】
データ取得リクエストにより外部DBの更新情報を取得する場合に、外部DBへ問い合せを行う装置での処理及び外部DBの内部処理のため、リクエスト応答時間に、それ自体が本来の目的ではない処理のための負荷(すなわち、オーバーヘッド)が生じる。さらに外部DBへリクエストを出すシステムの数が多いほど、外部DBの負荷が増加する。
【0005】
外部DB内のデータは、当該システム以外からも更新されることがある。この場合に、外部DBを収容するシステムが外部DBの更新情報を検知するためには、リクエストを外部DBクエリに変換する処理及び取得した情報が更新された情報であることを判定する処理が必要であるため、リクエスト応答時間にオーバーヘッドが生じる。さらに更新の検知情報はシステムごとで独立して実施するため、更新の検知を行うシステムの数が多いほど外部DBにおけるクエリ処理負荷が増加する。
【0006】
この発明は上記事情に着目してなされたもので、その目的とするところは、外部データベースの負荷を減少させる外部データベース収容装置、方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
上記目的を達成するためにこの発明の観点は、以下のような構成要素を備えている。すなわち、外部データベース収容装置は、取得対象とするデータを一意に識別できる複数のリクエストを1つ以上のシステムから受け付ける外部データベースからリクエストに対する応答を得る。外部データベース収容装置は、外部データベースにおいてある頻度以上に参照されるデータと同一のデータである更新対象情報と、この更新対象情報が更新されたかを示す更新情報とを保存している保持部を備えている。保持部は、データを取得するための取得リクエストを前記外部データベースが受け付けるより前に受け付け、取得リクエストに対応する更新情報から更新があるかを判断し、この更新が無い場合には更新が無い旨の通知を前記取得リクエストを送信したシステムに送信し、取得リクエストが要求する更新対象情報と同一のデータがあるかを判断し、この同一のデータがあった場合には取得リクエストを送信したシステムにこのデータを送信する。
【発明の効果】
【0008】
この発明によれば、外部データベースの負荷を減少させる外部データベース収容装置、方法及びプログラムを提供することができる。
【図面の簡単な説明】
【0009】
図1】実施形態に係る外部データベース収容装置を示すブロック図。
図2図1の外部データベース収容装置に更新されたデータが存在しない場合のシーケンス図。
図3図1の外部データベース収容装置に更新されたデータが存在する場合のシーケンス図。
図4図1の外部データベース収容装置に所望のデータが無く外部DBに存在する場合のシーケンス図。
図5図1の外部データベース収容装置に所望のデータが無く外部DBにも無い場合のシーケンス図。
図6】更新対象情報及びまたはその有効期限を更新する場合のシーケンス図。
図7図6のステップで使用する更新情報自動生成間隔を生成する手順を示すフローチャート。
図8図1の外部DB高頻度更新情報保持部に更新対象情報を追加または削除する場合のシーケンス図。
【発明を実施するための形態】
【0010】
以下、図面を参照してこの発明に係わる実施形態の外部データベース収容装置、方法及びプログラムを説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
実施の形態の外部データベース収容装置は、リクエストに応じて別システムで使用している外部データベース内のデータに随時問い合わせを行い、リクエストに応答するための装置である。
【0011】
実施形態に係る外部データベース収容装置について図1を参照して説明する。
本実施形態の外部データベース収容装置は、外部データベース高頻度更新情報保持部101、外部データベース更新監視処理部102、及びリクエスト頻度監視部103を備えている。なお以下、データベースはDBと略す。また、本実施形態の外部データベース収容装置に関係する装置として、リクエストを受け付けデータベースにアクセスするシステム1〜N(Nは1以上の自然数)、外部DB用システム共通API111、及び外部DB112がある。システム1〜Nは、それぞれリクエスト受付部121−1〜121−Nを備えている。
【0012】
なお、本実施形態では、取得リクエストとデータは以下の2つの条件の少なくとも1つを前提とする。(条件1)取得リクエストは、取得対象とするデータを一意に識別できるものであり、例えば「特定種別データ群のうち、最新のデータ(最後に蓄積されたデータ)」がある。(条件2)外部DB112から取得リクエストにより取得するデータは、取得対象データを一意に識別するIDが付与されており、取得リクエストにより取得されるデータ内には当該IDを少なくとも1つ含んでいる。
【0013】
外部DB112は、システムから要求される取得リクエストに対して応答するデータと、データの更新情報とを格納している。更新情報は例えば、更新時刻、更新内容、更新属性、有効期限を含む。また、外部DB112は、システム1〜Nとは異なるシステムによっても更新されている。
【0014】
外部DB高頻度更新情報保持部101は、外部DB112においてある頻度以上に頻繁に参照されるデータ(例えば、単位時間当たりの参照回数が閾値以上のデータ)と同一のデータである更新対象情報と、この更新対象情報それぞれの更新情報と、を保存している。更新対象情報は、外部DB112がもつデータのうち、リクエスト頻度監視部103が求めるリクエスト頻度から定められるデータであり、かつリクエスト頻度監視部103が定義した更新の有無を監視する条件を適用するデータであり、有効期限のあるデータである。更新対象情報は、リクエスト頻度が高いデータほど外部DB高頻度更新情報保持部101に蓄積されやすいように設定される。更新情報は、対応する更新対象情報が更新されたかどうかを示す情報である。外部DB高頻度更新情報保持部101が保持しているデータは、システム1からシステムNまでが共有する。
【0015】
外部DB高頻度更新情報保持部101は、受けたリクエストに対応する更新情報があるかどうかを判定し、本実施形態ではこの更新情報の有無によって、対応する更新対象情報があるかどうかを判断する(例えば、図2を参照)。しかし、外部DB高頻度更新情報保持部101は更新対象情報を直接探してその有無を判断してもよい。外部DB高頻度更新情報保持部101は、システムから要求される取得リクエストを受けて取得リクエストに対する応答として返す情報(データ)があった場合は、外部DB112に問い合わせることなく応答を返す。この結果、外部DB112に問い合わせるリクエストが減少し、外部DB112の負荷を軽減することができる。
【0016】
外部DB更新監視処理部102は、外部DB高頻度更新情報保持部101を更新するために、外部DB高頻度更新情報保持部101が管理する更新対象情報のうちの有効期限切れのデータに関して外部DB112からデータを取得し、データの更新の有無によって外部DB高頻度更新情報保持部101で更新対象情報を更新するかどうかを決定する。外部DB更新監視処理部102は事前に、リクエスト頻度監視部103から外部DB高頻度更新情報保持部101にどのような更新対象情報が登録されているかを示すデータを取得している。有効期限は、例えば前回更新検知時刻に更新情報自動生成間隔を加算した時刻、またはシステムから外部DB112に対して外部DB用システム共通APIを介して更新対象情報の更新が行われた時刻に更新情報自動生成間隔を加算した時刻とする。この更新情報自動生成間隔はある定められた定数でもよいし、図7に記載のアルゴリズムから定まる値を用いてもよい。図7のアルゴリズムを用いて更新情報自動生成間隔を計算する場合には、更新対象情報の更新検知(更新があったかどうか)、及び更新ヒット率の更新を実施する。更新情報自動生成間隔以内に更新リクエストが来なかった場合は、外部DB更新監視処理部102が外部DB112に対して取得リクエストを送信する(例えば図6参照)。更新リクエストは、リクエスト受付部121が外部DB更新監視処理部102に送信する。
【0017】
外部DB更新監視処理部102は、リクエスト頻度監視部103から受け取る判定結果に基づいて、外部DB112に格納されているデータのうち、どのデータを更新対象情報とするかを再定義または更新する。外部DB更新監視処理部102は更新対象情報ごとに更新ヒット率を管理する。
【0018】
リクエスト頻度監視部103は、外部DB112に対する各データの取得リクエスト頻度を監視し、指定された条件を満たすデータを、外部DB高頻度更新情報保持部101に格納する更新対象情報として外部DB更新監視処理部102に通知する。リクエスト頻度監視部103は、リクエストがあったデータについて更新対象情報及びその対応する更新情報を蓄積する条件を満たすかどうかを判定し、判定結果を外部DB更新監視処理部102へ渡す。リクエスト頻度監視部103は、例えば、取得リクエストを受け取った旨と、それを受け取った時刻とをログとして記録しておき、その情報からリクエストを受けたデータごとにリクエスト頻度を算出する。指定された条件は、リクエスト頻度が閾値よりも大きいか否かで判定する。リクエスト頻度は単位時間当たりのリクエスト数であり、その閾値は例えば100回/秒である。
【0019】
外部DB用システム共通API(application program interface)111は、外部DB高頻度更新情報保持部101または外部DB更新監視処理部102からリクエストがあった場合は、リクエスト変換して外部DB高頻度更新情報保持部101に通知を行う。リクエスト変換は、外部DB用システム共通API111が受信したリクエストを外部DB112へ問い合わせを行うための仕様に変換することである。
【0020】
外部DB用システム共通API111は、上述した外部DB更新監視処理部102、リクエスト頻度監視部103、及びリクエスト受付部121が外部DB112に問い合せを行うためのAPIを提供する。
【0021】
リクエスト受付部121−1〜121−Nは、取得リクエストを受けた場合には、外部DB高頻度更新情報保持部101及びリクエスト頻度監視部103に取得リクエストを送信する。その後、リクエスト受付部121−1〜121−Nは、外部DB高頻度更新情報保持部101から対応するデータを受け取るか、またはそのデータが無い旨の通知を受け取る。他の場合には、リクエスト受付部121−1〜121−Nは、外部DB112から外部DB用システム共通API111を経由して対応するデータを受け取るか、または外部DB高頻度更新情報保持部101にも外部DB112にもデータが不存在である旨の通知を受け取る。
【0022】
まず、システム1〜Nのうちのあるシステムから取得リクエストが実施形態の外部データベース収容装置に送信され、更新されたデータが存在しない場合について図2を参照して説明する。以下、システム1〜Nのうちのある1つのシステムを代表として挙げて説明する。この「代表」としてシステムを挙げる場合、枝番号(例えば、「121−1」の場合「−1」のこと)は省いて、リクエスト受付部121と記載する。ただし、複数のシステムがそれぞれ任意のタイミングで取得リクエストを本実施形態の外部データベース収容装置に行ってもよいことを想定している。
システムが取得リクエストの入力を受け付け(ステップS201)、リクエスト受付部121が外部DB高頻度更新情報保持部101とリクエスト頻度監視部103へ取得リクエストを送信する(ステップS202、S203)。外部DB高頻度更新情報保持部101は、ステップ203の取得リクエストを受け付け、このリクエストに対応する更新情報を取得する(ステップS204)。外部DB高頻度更新情報保持部101は、この更新情報から対応する更新対象情報が更新されたか否かを判定する(ステップS205)。外部DB高頻度更新情報保持部101に対応する更新が無かった場合には、更新が無い旨の通知をリクエスト受付部121に送信し(ステップS206)、入力者へその旨を知らせる(ステップS207)。なお、ステップS206及びステップS207では、更新無しの場合は、更新が無かったという情報を送信すると共にデータの実体を送信してもよい。
【0023】
このように、システムからの取得リクエストを受けて、対応するデータが更新されているかどうかを外部DB112に問い合せること無く、外部DB高頻度更新情報保持部101に問い合せるだけで済むので、外部DB112への負荷を低減することが可能となる。
【0024】
次に、システム1〜Nのうちのあるシステムから取得リクエストが実施形態の外部データベース収容装置に送信され、更新されたデータが存在する場合について図3を参照して説明する。
ステップS205までには図2のフローチャートと同一である。ステップS205で外部DB高頻度更新情報保持部101に対応する更新があった場合には、外部DB高頻度更新情報保持部101が、この更新情報に対応する更新対象情報を探し出して用意する(ステップS301)。外部DB高頻度更新情報保持部101は、更新がある旨の通知と、取得リクエストに対応するデータの実体(更新対象情報)とをリクエスト受付部121に送信し(ステップS302)、リクエスト受付部121が入力者へそれらを送信する(ステップS303)。
【0025】
このように、システムからの取得リクエストに応答するデータが外部DB高頻度更新情報保持部101にある場合には、外部DB112に問い合わせる必要が無くなるので、外部DB112への負荷を低減することが可能となる。
【0026】
次に、システム1〜Nのうちのあるシステムから取得リクエストが実施形態の外部データベース収容装置に送信され、外部DB高頻度更新情報保持部101にリクエストに対応する情報が無く、外部DB112に対応するデータが存在する場合について図4を参照して説明する。
ステップS204までは図2と同一である。ステップS204で更新情報が取得できない場合には、更新情報が無くしたがって対応する更新対象情報が無いと判断する(ステップS401)。この場合、外部DB高頻度更新情報保持部101が外部DB用システム共通API111にステップS203で受け取ったものと同様の取得リクエストを送信する(ステップS402)。外部DB用システム共通API111は、受け取った取得リクエストをリクエスト変換して(ステップS403)、変換後のリクエストを外部DB112へ送信する(ステップS404)。外部DB112は、受け取った取得リクエストに対応するデータがある場合にはこのデータを取得する(ステップS405)。外部DB112は、取得したデータを外部DB用システム共通API111へ送信し(ステップS406)、外部DB用システム共通API111はリクエスト受付部121へ取得したデータを送信し(ステップS407)、その取得したデータを入力者へ送信する。またはその取得したデータと、更新の有無が不明である情報と、を入力者へ送信してもよい(ステップS408)。
【0027】
このように、システムからの取得リクエストを受けて、対応するデータが外部DB高頻度更新情報保持部101に無い場合でも、その後に外部DB112に同じ問い合せを行うことで応答となるデータをシステムは受け取ることができる。
【0028】
次に、システム1〜Nのうちのあるシステムから取得リクエストが実施形態の外部データベース収容装置に送信され、外部DB高頻度更新情報保持部101にリクエストに対応する情報が無く、外部DB112にも対応するデータが存在しない場合について図5を参照して説明する。
ステップS405までは図4と同一である。ステップS405で外部DB112が、取得リクエストに対応するデータが無くを取得できない場合に、データが外部DB112に存在していないという情報(データ不存在情報)を外部DB用システム共通API111へ送信する(ステップS501)。外部DB用システム共通API111はリクエスト受付部121へ取得したデータ不存在情報を送信し(ステップS502)、その取得したデータ不存在情報を入力者へ送信する(ステップS503)。
【0029】
このように、システムからの取得リクエストを受けて、対応するデータが外部DB高頻度更新情報保持部101に無い場合で、かつ、外部DB112にも対応するデータが無い場合には、データの実体が無い旨の情報を送ることができる。
【0030】
次に、外部DB更新監視処理部102が、外部DB高頻度更新情報保持部101が保持する更新対象情報及びまたはその有効期限を更新する動作について図6を参照して説明する。
外部DB更新監視処理部102が、外部DB高頻度更新情報保持部101に格納されている更新対象情報の有効期限の取得を外部DB高頻度更新情報保持部101に要請して、その有効期限の情報を取得する(ステップS601)。外部DB更新監視処理部102が、その情報から、更新対象情報ごとに対応するリクエストを受け取った最近の時刻から一定時間(例えば、図7で説明する更新情報自動生成間隔)が経過しているかどうかを判定する(ステップS602)。具体的には例えば、外部DB高頻度更新情報保持部101に格納されている全てのデータ(更新対象情報)のうちの有効期限が切れているデータを検索する。
【0031】
外部DB更新監視処理部102が、前回のリクエストから一定時間が経過したと判定した場合(例えば、有効期限が切れているデータがあると判定した場合)には、外部DB用システム共通API111へこの取得リクエストを送信する(ステップS603)。外部DB用システム共通API111はこの取得リクエストをリクエスト変換し変換後のリクエストを外部DB112へ送信し(ステップS605)、外部DB112が、リクエストに対応するデータを取得し(ステップS606)、このデータを外部DB用システム共通API111に送信する(ステップS607)。外部DB用システム共通API111はこのデータを外部DB更新監視処理部102に送信し(ステップS608)、外部DB更新監視処理部102は、受け取ったデータに対応するリクエストを外部DB高頻度更新情報保持部101に送信し(ステップS609)、このリクエストに対応するデータ(更新情報及び更新対象情報)を外部DB高頻度更新情報保持部101から取得する。外部DB更新監視処理部102は外部DB112から取得した情報と外部DB高頻度更新情報保持部101から取得した情報とを比較し、更新対象情報が更新されたかどうかを判定する(ステップS610)。
【0032】
ステップS610で更新があったと判定された場合は、外部DB更新監視処理部102は更新ヒット率を更新して(ステップS611)、更新された更新対象情報を外部DB高頻度更新情報保持部101へ送信し(ステップS612)、外部DB高頻度更新情報保持部101では更新対象情報と有効期限を更新する(ステップS613)。
【0033】
ステップS610で更新が無かったと判定された場合は、外部DB更新監視処理部102は更新ヒット率を更新して(ステップS614)、更新が無かった更新対象情報は送らず、有効期限の更新情報を外部DB高頻度更新情報保持部101へ送信し(ステップS615)、外部DB高頻度更新情報保持部101では有効期限のみを更新する(ステップS616)。
【0034】
このように、外部DB更新監視処理部102によって、更新対象情報の有効期限から外部DB高頻度更新情報保持部101内の更新対象情報をより適切に外部DB112の情報を更新することができる。
【0035】
次に、更新情報自動生成間隔を生成するための動作について図7を参照して説明する。ここの例では、更新情報自動生成間隔をC秒ごとに算出または更新するアルゴリズムである。このアルゴリズムは、更新情報自動生成間隔を使用する外部DB更新監視処理部102が実行するのが自然だが、異なる装置が行ってもよい。
このアルゴリズムをC秒ごとに実行する(ステップS701)。なお、C及び初回の更新情報自動生成間隔は任意の設定値とする。P[U]−P[U]>0であるかどうかを判定する(ステップS702)。ここで、更新情報自動生成間隔Tで既存システムへの問い合せをC秒間行った結果、実際に既存システムの更新を検知した確率を更新ヒット率P[U](=C秒間で更新を検知した回数/C秒間で外部DBを参照した回数)とする(X,Y=1,2)。P[U]及びP[U]はそれぞれ前回及び前々回の更新ヒット率を示す。なお、更新ヒット率では外部DB更新監視処理部102が更新を確認できた回数のみを考慮する。P[U]−P[U]>0である場合にはF値が改善されたと推定し、そうでない場合にはF値が劣化したと推定する。ここで、F値(F-measure)は下記の式の通り、適合率(precision)及び再現率(recall)の調和平均より求まる統計学の指標であり、F値は更新間隔の最適化の指標となる。
【0036】
【数1】
【0037】
なお、
true positive:正解であると推定した事象のうち、正解であった事象の集合
false positive:正解であると推定した事象のうち、不正解であった事象の集合
false negative:正解である事象のうち、推定されなかった事象の集合
である。また、適合率=推定数のうちで正解した数/推定数≦1、再現率=推定できた正解数/真の正解数≦1である。本アルゴリズムにおいて、F値における正解集合Xとは既存システムが更新された事象の集合であり、推定集合Yとは更新情報を自動生成した事象の集合である。正解集合Xと推定集合Yとが一致した場合にF値は最大となるため、F値の改善により更新情報自動生成間隔を最適化することが期待できる。一般に、F値を算出するには、正解集合X=false negative ∪ true positiveがわかる必要がある。本アルゴリズムでは、正解集合X(既存システムが更新された事象の集合)が不明である場合にも、前回及び前々回からの更新ヒット率P[U]及びP[U]の差分から(F値ではなく)F値の向上または低下を推定する。
【0038】
ステップS702でF値が改善されたと推定された場合にはステップS703へ進み、そうで無い場合にはステップS705へ進む。ステップS703ではT−T>0であるかどうか判定し、この不等式を満たす場合にはステップS704に進み、そうで無い場合にはステップS706へ進む。ここで、Tは前回の更新情報自動生成間隔であり、Tは前々回の更新情報自動生成間隔である。T−T>0を満たす場合には前々回よりも前回の方の間隔が長くなったことを示し、更新回数が減ることになる。一方、T−T>0を満たさない場合には前々回よりも前回の方の間隔が短くなった(または変らない)ことを示し、更新回数が増える(または変らない)ことになる。ただし、更新情報自動生成する単位時間当たりの更新回数は、システム1〜Nからの単位時間当たりのリクエスト回数(クライアントリクエスト回数とも呼ぶ)よりは増やさないように制御する。
【0039】
ステップS704では、更新情報自動生成間隔をt秒長くする。ここでtは任意の設定値とする。なお、更新情報自動生成間隔を長くする場合と短くする場合とで異なるtの値を用いてもよい。
【0040】
ステップS705では、T−T>0であるかどうかを判定し、この不等式を満たす場合にはステップS706に進み、そうで無い場合にはステップS708へ進む。
【0041】
ステップS706では、T−TClient>0であるかどうかを判定し、この不等式を満たす場合にはステップS707に進み、そうで無い場合にはステップS708へ進む。ここで、TClientは前回のシステム1〜Nからのリクエスト間隔(クライアントリクエスト間隔とも呼ぶ)である。
【0042】
ステップS707では更新情報自動生成間隔をt秒短くし、ステップS708では更新情報自動生成間隔をt秒長くする。
【0043】
例えば以上の動作によって、外部DB更新監視処理部102が更新情報自動生成間隔を調整する。
【0044】
このように、外部DB更新監視処理部102によって、更新対象情報の有効期限から外部DB高頻度更新情報保持部101内の更新対象情報をより適切な最適化された更新間隔で、外部DB112の情報を更新することができる。
【0045】
次に、外部DB高頻度更新情報保持部101に格納される更新対象情報を追加または削除する場合について図8を参照して説明する。
リクエスト頻度監視部103が、更新対象情報とする条件を満たすかどうか判定する(ステップS801)。具体的には、リクエスト頻度監視部103が、任意の期間または任意の量の参照リクエストのログを記録しておきこのログから、リクエストのあったデータごとに単位時間当たりの参照リクエスト回数を算出する。なお、リクエストログには少なくともリクエストされた時刻及びリクエストの対象データを一意に定める情報が含まれていればよい。この場合には、条件として、参照リクエスト回数が閾値Lを越えたデータまたは上位M個のデータを更新対象情報として定義する、または、過去に算出した参照リクエスト回数と比較してE回増加しているデータを更新対象情報として定義する(L、M、及びEは任意の自然数)。
【0046】
外部DB更新監視処理部102は、リクエスト頻度監視部103から更新対象情報とする条件を満たしたデータのリストを取得し(ステップS802)、外部DBのうち、どのデータを更新対象情報とするかを再定義または更新し、外部DB高頻度更新情報保持部101に追加または外部DB高頻度更新情報保持部101から削除する(ステップS803)。具体的には、その後、前回同様に受信したリストのうち、新たに受信したリストに記載されていないデータを削除候補とする(削除するタイミングは、削除候補に挙がった回数を用いて決定する。例えば削除候補に挙がった回数が連続E回であった等)。また、外部DB更新監視処理部102は更新対象情報ごとに更新ヒット率を格納して管理する。
【0047】
[追加される場合]追加が決定されたデータに対応するリクエストを外部DB用システム共通API111へ送信する(ステップS804)。外部DB用システム共通API111は、受け取った取得リクエストをリクエスト変換して(ステップS805)、変換後のリクエストを外部DB112へ送信する(ステップS806)。外部DB112は、受け取った取得リクエストに対応するデータがある場合にはこのデータを取得する(ステップS807)。外部DB112は取得したデータを外部DB更新監視処理部102へ送信し(ステップS808)、外部DB更新監視処理部102はそのデータを外部DB高頻度更新情報保持部101へ送信する(ステップS809)。外部DB高頻度更新情報保持部101は、この取得したデータを追加し(ステップS810)、追加した旨を外部DB更新監視処理部102へ通知する(ステップS811)。
また、外部DB更新監視処理部102がリクエスト受付部121から更新リクエストを受けた場合にも、外部DB更新監視処理部102は外部DB高頻度更新情報保持部101の情報を更新する(更新リクエストを受けた後、ステップS809〜S811を実行することになる)。
【0048】
[削除される場合]外部DB更新監視処理部102は削除することが決定されたデータを外部DB高頻度更新情報保持部101から削除するリクエストを外部DB高頻度更新情報保持部101へ送信し(ステップS812)、外部DB高頻度更新情報保持部101は対応するデータを削除し(ステップS813)、削除した旨を外部DB更新監視処理部102へ通知する(ステップS814)。
【0049】
このように、リクエスト頻度監視部103と外部DB更新監視処理部102とによって、外部DB高頻度更新情報保持部101に格納される更新対象情報を適切に追加及び削除することにより、最適化したデータに調整することができる。
【0050】
以上の実施形態によれば、1つの外部DBを複数のシステムが参照する場合に、高頻度に参照される情報を予め取得及び保持することで、リクエスト応答時間のオーバーヘッドの軽減及びシステム側での更新検知処理の削減が可能となる。加えて、リクエスト応答時間のオーバーヘッドを軽減しつつ、高頻度に参照される情報を外部DBに問い合わせる回数を削減することで、外部DBへの負荷を低減することが可能となる。
【0051】
また、以上の各装置及びそれらの装置部分は、それぞれハードウェア構成、またはハードウェア資源とソフトウェアとの組み合せ構成のいずれでも実施可能となっている。組み合せ構成のソフトウェアとしては、予めネットワークまたはコンピュータ読み取り可能な記憶媒体からコンピュータにインストールされ、当該コンピュータのプロセッサに実行されることにより、各装置の機能を当該コンピュータに実現させるためのプログラムが用いられる。
【0052】
なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【0053】
101…外部データベース高頻度更新情報保持部、102…外部データベース更新監視処理部、103…リクエスト頻度監視部、1〜N…システム、111…外部DB用システム共通API、112…外部DB、121−1〜121−N…リクエスト受付部。
図1
図2
図3
図4
図5
図6
図7
図8