JP2009223507A - 周期更新データ管理システム - Google Patents

Abstract

【課題】大量レコードの更新処理を高速化した周期更新データ管理システムを得る。
【解決手段】記憶部１は、外部の情報源７ａ〜７ｃと１対１に対応するレコード３を、各々の次回更新時刻に基づいて異なるバケット２ａ〜２ｃに格納する。更新処理部６は、各バケットのうち、現在時刻に対応するものを処理対象バケットとして選択し、処理対象バケット内の対象レコードについて、情報源７ａ〜７ｃの中から対象レコードに対応する対象情報源を参照し、対象情報源から取得した取得情報に基づいて、対象レコードの更新後の値を決定するとともに、取得情報の前回参照時からの変化の有無または大きさに基づいて、対象レコードの次回更新時刻を決定し、決定された次回更新時刻に対応するバケットの末尾に、対象レコードの更新後の値を格納し、処理対象バケット内のすべての対象レコードを処理し終えた後に、処理対象バケットを削除する。
【選択図】図１

Description

この発明は、記憶部と更新処理部とを備えた周期更新データ管理システムに関するものである。

一般に、コンピュータが記憶する多数の情報（レコード）の中から特定の１つを更新する際には、まず、更新対象を特定するキー（ＩＤ）に基づいてレコードを検索する必要がある。このとき、扱う情報量が大きくなると、主記憶装置に比べて極めて低速な２次記憶装置にアクセスする必要が生じる。

したがって、多数のレコードを管理するデータベースにおいては、少ない２次記憶アクセスでキーに対応するレコードを検索するために、「Ｂ−ｔｒｅｅ」などの木構造索引が利用されることが一般的である。また、一度アクセスしたレコードを主記憶に留めるバッファリングにより、頻繁にアクセスされるレコードについては、２次記憶装置へのアクセスを回避できるようにしている。

２次記憶装置は、磁気ディスク装置に代表されるように、連続するアドレスに対するアクセス（シーケンシャルアクセス）速度（数１０ＭＢ／ｓ〜数１００ＭＢ／ｓ）に対して、不連続なアドレスに対するアクセス（ランダムアクセス）速度（数ＭＢ／ｓ）が著しく低いという特性がある。
この結果、多数のレコードを更新する際には、２次記憶へのアクセスパターンがシーケンシャルであるかランダムであるかによって、得られる性能が著しく異なってしまう。

キー（ＩＤ）に基づく検索のための「Ｂ−ｔｒｅｅ索引」では、キー順のアクセスにおいてはシーケンシャルアクセスに近い性能が得られるものの、キー順と一致しない任意順序のアクセスに対しては、巨大な主記憶バッファがない限り、ランダムアクセスの性能しか得られない。

そこで、上記特性を考慮して、複数レコードに対するアクセス要求をまとめ、キー順に並べ替えてから、実際のアクセスを行うことにより、性能低下を防ぐ方法が提案されている（たとえば、特許文献１参照）。

なお、更新ではなく、新規レコードを追加する際には、レコードの検索が不要であることから、書き込み順にレコードを格納することでシーケンシャルアクセスを実現することができる。これは書き込みの時刻にしたがう格納方式であり、ログ形式として知られる一般的な方式であるが、追加したレコードを再度更新しようとすると、ランダムアクセスが発生するため、更新には不適である。

特開平１０−３１６０２号公報、第１頁、図１

従来の周期更新データ管理システムでは、特許文献１に記載のように、レコードをキー順に格納し、複数レコードに対するアクセス要求をキー順に並べ替えてから実際にアクセスしているので、多数のレコードが存在する場合には、アクセス対象がまばらとなり、連続するレコードをアクセスすることがまれになって、性能低下の防止効果が得られないという課題があった。

この発明は、上記のような課題を解決するためになされたもので、各レコードに対する更新時刻があらかじめ判明している場合（システム自体が更新をスケジュールする場合）には、記憶部（２次記憶装置）への読み込みおよび書き込みがシーケンシャルアクセスとなるようにして、大量レコードの更新処理を高速化することのできる周期更新データ管理システムを得ることを目的とする。

この発明による周期更新データ管理システムは、記憶部と更新処理部とを備えた周期更新データ管理システムであって、記憶部は、外部の複数の情報源と１対１に対応する複数のレコードを、各々の次回更新時刻に基づいて異なる複数の領域に格納し、更新処理部は、複数の領域のうち、現在時刻に対応するものを処理対象領域として選択し、処理対象領域内の対象レコードについて、複数の情報源の中から対象レコードに対応する対象情報源を参照し、対象情報源から取得した取得情報に基づいて、対象レコードの更新後の値を決定するとともに、取得情報の前回参照時からの変化の有無または大きさに基づいて、対象レコードの次回更新時刻を決定し、決定された次回更新時刻に対応する領域の末尾に、対象レコードの更新後の値を格納し、処理対象領域内のすべての対象レコードを処理し終えた後に、処理対象領域を削除するものである。

この発明に係る周期更新データ管理システムよれば、大量レコードの更新処理を高速化することができる。

実施の形態１．
図１はこの発明の実施の形態１に係る周期更新データ管理システムを示すブロック構成図である。
図１において、周期更新データ管理システムは、記憶部１と、記憶部１に接続された読込バッファ４と、記憶部１に接続された書込バッファ５ａ、５ｂ、・・・と、書込バッファ５ａ、５ｂ、・・・を制御する更新処理部６と、記憶部１とは異なる第２の記憶部８と、第２の記憶部８に接続された要求受付部１０とを備えている。
以下、代表的に、複数の書込バッファのうちの２つの書込バッファ５ａ、５ｂに注目して説明する。

また、周期更新データ管理システムの外部構成として、複数の情報源（Ａ、Ｂ、Ｃ、・・・）７ａ、７ｂ、７ｃ、・・・と、制御端末１１とを備えている。以下、代表的に、複数の情報源のうちの３つの情報源７ａ〜７ｃに注目して説明する・

記憶部１は、記憶用の複数の領域（以下、「バケット」という）２ａ、２ｂ、２ｃ、・・・を有し、各バケット２ａ、２ｂ、２ｃ、・・・は、それぞれ、情報すなわちレコード３を格納する。
以下、代表的に、複数のバケットのうちの３つのバケット２ａ〜２ｃに注目して説明する。

更新処理部６は、複数の情報源７ａ〜７ｃに基づいて、要求受付部１０に登録要求を送信するとともに、書込バッファ５ａ、５ｂの保持データ（レコード）を制御する。
第２の記憶部８は、情報源登録テーブル９ａを有しており、たとえば情報源７ａ〜７ｃに対応した識別子Ａ〜Ｃを格納する。
要求受付部１０は、更新処理部６および制御端末１１からの登録要求に応答して、書込バッファ５ａ、５ｂの保持データを制御する。

周期更新データ管理システムの外部に存在する情報源７ａ〜７ｃおよび制御端末１１は、インターネットやＬＡＮなどの通信回線を介して周期更新データ管理システムに接続されている。
ここでは、代表例として、情報源７ａ〜７ｃは、Ｗｅｂサーバ上のＷｅｂページにより構成され、制御端末１１は、一般的なコンピュータにより構成されるものとする。
たとえば、情報源７ａ〜７ｃは、論理的な実体であり、物理的な実体であるＷｅｂサーバに、各情報源７ａ〜７ｃを識別するＵＲＬを指定して、Ｗｅｂページ取得要求を送付することに対応する。

図１に示したこの発明の実施の形態１によるシステムの目的は、各Ｗｅｂページの時間的な変化をとらえるために、各Ｗｅｂページを取得するタイミングを決定するための情報をレコードとして管理することにある。
ここで、レコードは、Ｗｅｂページを取得するごとに更新され、次の取得タイミングは、適応的に制御されるものとする。実際に取得したＷｅｂページの内容自体は、ログ形式などで、記憶部１以外の別の記憶手段に格納されてもよい。

また、図１の周期更新データ管理システムは、一般的なコンピュータを用いて実現することができる。
すなわち、記憶部１および第２の記憶部８を磁気ディスク装置で実現し、読込バッファ４および書込バッファ５ａ〜５ｂをランダムアクセスメモリで実現し、更新処理部および要求受付部１０を、ランダムアクセスメモリに格納されプロセッサで実行されるコンピュータプログラムとして実現することができる。

バケット２ａ〜２ｃは、記憶部１の互いに異なる領域を占めており、それぞれ、独立に新規作成、拡張および削除が可能である。
記憶部１内のバケット２ａ〜２ｃは、たとえばＬｉｎｕｘやＷｉｎｄｏｗｓ（登録商標）などの一般的なオペレーティングシステムが提供するファイルとして実現することができる。

各バケット２ａ〜２ｃには、レコード３が複数格納される。
各レコード３は、各情報源７ａ〜７ｃと１対１に対応しており、それぞれ、独立の周期で、対応する情報源７ａ〜７ｃの情報に基づいて更新される。

レコード３は、所定単位（時間分解能）、たとえば「日」で表した次回更新時刻を含んでおり、各バケット２ａ〜２ｃに格納されるレコード３は、すべて同一の次回更新時刻を持つようにする。
すなわち、レコード３の次回更新時刻に応じて格納するバケット２ａ〜２ｃを定める。また、各バケット２ａ〜２ｃ内でのレコード３の配置は格納順であり、特定の情報源識別子を持つレコード３を検索するためには、バケット２ａ〜２ｃの全体の走査を必要とする。

書込バッファ５ａ〜５ｂは、バケット２ａ〜２ｃと同様に、次回更新時刻ごとに存在する。
情報源登録テーブル９ａは、既知の情報源の識別子を格納しており、たとえば、公知の「Ｂ−ｔｒｅｅ」などの木構造を用いて、特定の情報源識別子の検索が効率的に行えるようにする。

情報源登録テーブル９ａへのアクセスは、本質的にランダムアクセスとなるが、レコード３の全体と比較して小規模なので、全体をランダムアクセスメモリでキャッシュすることにより、記憶部１および第２の記憶部８（磁気ディスク装置）へのアクセスを回避することができる。

図２はバケット２内のレコード３に含まれる情報を詳細に示す説明図である。
図２において、レコード３は、情報源識別子３１と、次回更新時刻３２と、最終状態３３と、最終更新時刻３４と、更新周期３５とを、情報として含む。

情報源識別子３１は、情報源であるＷｅｂページのＵＲＬを表す。
次回更新時刻３２は、レコードが次に更新される予定の時刻であり、前述の通り、同一バケット内の各レコード３は、所定単位（たとえば、「日」）で表した同一の次回更新時刻を持つ。

最終状態３３は、情報源識別子３１に対応する情報源から最後に取得した情報を表す。
なお、レコード３の次回更新時刻３２を決定するために、情報の値自体ではなく、値の変化の有無のみ、が重要な場合には、最終状態３３には値自体に代えて、値にハッシュ関数（ｈａｓｈ ｆｕｎｃｔｉｏｎ）を適用してデータ長を圧縮した表現を用いることができる。

上述したように、次回更新時刻３２の決定以外の目的（たとえば、取得したＷｅｂページに対する全文検索索引の生成など）のために、情報の値自体や値の履歴が必要な場合には、別の記憶手段にこれらを格納する。

レコード３内の最終更新時刻３４および更新周期３５は、次回更新時刻３２を決定する際に、参照されるとともに更新されるデータである。
なお、レコード３は、情報源７ａ〜７ｃから情報を取得する際に必要な補助的なデータ（たとえば、Ｗｅｂサイトの認証情報やクッキー情報など）をさらに含んでいてもよい。

次に、図３および図４のフローチャートを参照しながら、更新処理部６および要求受付部１０の各動作について説明する。まず、図３に示した更新処理部６の動作について説明する。
図３において、更新処理部６は、まず、バケット２ａ〜２ｃのうち、最小（ｔ）の次回更新時刻３２に対応するものを、処理対象バケット（処理対象領域）ｔ（以下、単に「バケットｔ」ともいう）として選択する（ステップＳ１）。

このとき、次回更新時刻３２の最小値ｔに対応するバケットｔとしては、単に現在時刻に対応するバケットを選択することもできるが、次回更新時刻３２の単位期間（たとえば、１日）内に処理が完了しないバケットが存在した場合には、処理されないバケットが生じる可能性がある。

続いて、現在時刻が「ｔ」に至るまで待機する（ステップＳ２）。ステップＳ２は、単位期間内に更新されるレコード３が存在しない場合に、バケット２がまばらになる可能性があるために実行される。

以下、更新処理部６は、バケットｔの内容を一括して、読込バッファ４に読み込む（ステップＳ３）。これにより、記憶部１に対する読み込みを、シーケンシャルアクセスとする。
続いて、読込バッファ４内のすべてのレコードが処理されたか否かを判定して（ステップＳ４）、すべてのレコードが処理済み（すなわち、ＹＥＳ）と判定されれば、ステップＳ１０に進み、未処理レコードが残っている（すなわち、ＮＯ）と判定されれば、ステップＳ５に進む。

ステップＳ５において、更新処理部６は、未処理のレコードの１つを選択し、選択されたレコードの情報源識別子３１に基づいて、情報源から情報を取得する。
なお、上述したように、取得した情報を別の記憶手段に格納する必要がある場合は、ステップＳ５の時点で格納する。

また、ここで、取得した情報はＷｅｂページであり、ハイパーリンクとして別のＷｅｂページのＵＲＬが含まれているので、更新処理部６は、それらのＵＲＬを取り出して、各ＵＲＬを情報源識別子とする登録要求を、要求受付部１０に送付することにより、新たな情報源を発見することができる。

また、ステップＳ５において、更新処理部６は、取得した情報に基づいて、次回更新時刻ｔ’を決定する。
次回更新時刻ｔ’は、たとえば、レコード３に格納された最終状態３３と、取得した情報に基づく新たな最終状態とを比較して、情報の更新の検出有無に基づいて設定される。すなわち、情報の更新が検出された場合には、更新周期３５の１／２を現在時刻に加算し、情報の更新が検出されなかった場合には、更新周期３５に「１」を加算した値を現在時刻に加算する、などの方法により決定することができる。

さらに、ステップＳ５において、更新処理部６は、次回更新時刻３２を「ｔ’」に設定し、最終状態３３を新たな値に設定し、最終更新時刻３４を現在時刻に設定し、更新周期３５を、情報の更新が検出された場合には「元の値の１／２」に設定し、情報の更新が検出されなかった場合には「元の値に１を加算した値」に設定する。

なお、より高度な更新周期の決定方法は、公知文献（たとえば、日本データベース学会Ｌｅｔｔｅｒｓ、Ｖｏｌ．６、Ｎｏ．１、ｐｐ．１７３−１７６「大規模Ｗｅｂアーカイブのための更新クローラの設計と実装」田村孝之、喜連川優。または、特願２００７−０１８０１２「Ｗｅｂページ再収集方式」参照）に述べられている。

続いて、レコードが棄却対象か否かを判定する（ステップＳ６）。
一般に、情報源からの情報取得は、異常終了することもあり、また、情報の更新がないと更新周期３５が非常に大きくなる。したがって、たとえば、異常終了が「３回」続いた場合や、更新周期３５が「２年以上」になった場合など、の所定条件を設けることにより、所定条件に当てはまる場合に「棄却対象」と判定することができる。

ステップＳ６において、レコードが棄却対象である（すなわち、ＹＥＳ）と判定された場合には、直ちにステップＳ４に戻り、棄却対象でない（すなわち、ＮＯ）と判定された場合には、次のステップＳ７に進む。

ステップＳ７においては、次回更新時刻ｔ’に対応する書込バッファｔ’の空き容量を調べて、書込バッファｔ’がフルである（空きがない）か否かを判定する。
ステップＳ７において、空きがない（すなわち、ＹＥＳ）と判定されれば、次のステップＳ８に進み、空きがある（すなわち、ＮＯ）と判定されれば、ステップＳ８をスキップしてテップＳ９に進む。

ステップＳ８においては、書込バッファｔ’のフラッシュ処理を行う。すなわち、書込バッファｔ’内のすべてのレコードをバケットｔ’の末尾に追加し、書込バッファｔ’を空にする。ステップＳ８の動作により、記憶部１に対する書き込みをシーケンシャルアクセスとする。
続いて、ステップＳ５で更新したレコードの値を書込バッファｔ’の末尾に追加して（ステップＳ９）、ステップＳ４に戻る。

一方、ステップＳ４において、読込バッファ４によるレコード処理完了（すなわち、ＹＥＳ）と判定された場合には、ステップＳ１０が実行され、ステップＳ１０においては、書込バッファｔ＋１のフラッシュを実行した後に、書込バッファｔ＋１を削除する。

ステップＳ１０は、バケットｔ＋１が次に処理対象となるための処理である。
最後に、読込バッファを空にし（ステップＳ１１）、処理を終えたバケットｔを削除して（ステップＳ１２）、ステップＳ１に戻る。

次に、図４に示した要求受付部１０の動作について説明する。
図４において、要求受付部１０は、まず、登録要求を受信する（ステップＳ２１）。
このとき、登録要求は、登録対象となる情報源の情報源識別子Ｒを含んでいる。

続いて、要求受付部１０は、登録要求の情報源識別子Ｒを参照して、第２の記憶部８内の情報源登録テーブル９ａを検索し、登録要求の情報源識別子Ｒが情報源登録テーブル９ａに存在する（見付かる）か否かを判定する（ステップＳ２２）。

ステップＳ２２において、情報源登録テーブル９ａ内に情報源識別子Ｒが存在する（すなわち、ＹＥＳ）と判定されれば、情報源登録テーブル９ａにすでに情報源識別子Ｒが登録済みなので、ステップＳ２１に戻る。
一方、ステップＳ２２において、情報源登録テーブル９ａ内に情報源識別子Ｒが存在しない（すなわち、ＮＯ）と判定されれば、次のステップＳ２３に進み、情報源識別子Ｒを情報源登録テーブル９ａに追加登録する。

続いて、情報源識別子Ｒに対応するレコードを初期化し、次回（初回）更新時刻ｔ’を決定する（ステップＳ２４）。
更新時刻ｔ’は、現在時刻ｔに所定の定数（たとえば、「１」）、または所定範囲内の乱数を加算して決定することができる。
最後に、要求受付部１０は、更新処理部６（図３）のステップＳ７〜Ｓ９と同様のレコード書き込み処理（ステップＳ２５〜Ｓ２７）を実行して、ステップＳ２１に戻る。

以上のように、この発明の実施の形態１（図１〜図４）によれば、記憶部１と更新処理部６とを備えた周期更新データ管理システムであって、記憶部１は、外部の複数の情報源７ａ〜７ｃと１対１に対応する複数のレコード３を、各々の次回更新時刻に基づいて異なる複数のバケット２ａ〜２ｃに格納する。

更新処理部６は、複数のバケット２ａ〜２ｃのうち、現在時刻に対応するものを処理対象バケットとして選択し、処理対象バケット内の対象レコードについて、複数の情報源７ａ〜７ｃの中から対象レコードに対応する対象情報源を参照し、対象情報源から取得した取得情報に基づいて、対象レコードの更新後の値を決定するとともに、取得情報の前回参照時からの変化の有無または大きさに基づいて、対象レコードの次回更新時刻ｔ’を決定し、決定された次回更新時刻ｔ’に対応するバケットの末尾に、対象レコードの更新後の値を格納し、処理対象バケット内のすべての対象レコードを処理し終えた後に、処理対象バケットを削除する。

このように、複数のレコード３を次回更新時刻ｔ’に基づいて格納する複数のバケット２ａ〜２ｃを有することにより、同時に更新されるレコードをバケット単位に一括して読み込むことができ、大量レコードの更新処理を高速化することができる。
また、レコード単位のランダムアクセスを回避して、記憶部１（磁気ディスク装置）の性能低下を防ぐことができる。

また、この発明の実施の形態１に係る周期更新データ管理システムは、記憶部１に接続された単一の読込バッファ４と、記憶部１内の複数のバケット２ａ〜２ｃと１対１に対応する所定容量の複数の書込バッファ５ａ、５ｂとを、さらに備えている。
この場合、更新処理部６は、処理対象バケットに格納されたすべての対象レコードを一括して読込バッファ４に読み込み、読込バッファ４内の各対象レコードについて、複数の情報源７ａ〜７ｃの中から対象レコードに対応する対象情報源を参照して、更新後の値および次回更新時刻ｔ’を決定する。

また、更新処理部６は、決定された次回更新時刻ｔ’に対応する第１の書込バッファを、複数の書込バッファ５ａ、５ｂから選択し、第１の書込バッファにすでに所定容量のレコードが格納されている場合には、第１の書込バッファ内のすべてのレコードを第１の書込バッファに対応するバケットの末尾に書き込んで、第１の書込バッファを空にしてから、第１の書込バッファの末尾に対象レコードの更新後の値を格納し、読込バッファ４のすべてのレコードを処理し終えた後に、次に処理対象となる次回処理対象バケットに対応する第２の書込バッファ内のすべての次回対象レコードを、次回処理対象バケットの末尾に書き込んで、第２の書込バッファを空にしてから、第２の書込バッファおよび処理対象バケットを削除する。

このように、更新後のレコードを元の位置に書き戻さず、同一の次回更新時刻ｔ’を持つ複数のレコード３を一括して書き込むための書込バッファ５ａ〜５ｂを備えることにより、書き込み時のランダムアクセスを回避するとともに、レコードごとに更新周期が異なっていても、次回以降の読み込み動作がシーケンシャルアクセスとなることを保証することができる。
また、一括して読み込まれたバケットは、直ちに再利用可能となるので、バケット（記憶領域）の断片化を回避することができる。

また、この発明の実施の形態１に係る周期更新データ管理システムは、記憶部１とは異なる第２の記憶部８と、第２の記憶部８に接続された要求受付部１０とを、さらに備えている。
第２の記憶部８は、記憶部１に格納されたすべてのレコードに対応する各情報源の識別子を格納する情報源登録テーブル９ａを有する。
要求受付部１０は、複数の情報源のいずれか１つに対応する識別子を含む登録要求を受け付け、その識別子が情報源登録テーブル９ａに格納されていない場合には、その識別子を情報源登録テーブル９ａに追加するとともに、その識別子に対応するレコードを所定値に初期化して、記憶部１内の複数のバケット２ａ〜２ｃのうちの１つ、または書込バッファ５ａ、５ｂの１つの末尾に書き込む。

このように、情報源登録テーブル９ａを備えることにより、重複を避けながら、新たな情報源を動的に追加する処理を、バケット全体を検索せずに効率的に行うことができる。
特に、情報源の情報がＷｅｂサイト上のＷｅｂページの場合には、情報源の識別子は、ＷｅｂページのＵＲＬであり、更新処理部６は、処理対象バケット内の対象レコードに対応するＷｅｂページの内容をダウンロードして、対象レコードの更新後の値を決定するとともに、対象レコードに対応するＷｅｂページからリンクを抽出して、得られたＵＲＬの各々を登録要求として要求受付部１０に送付することにより、ハイパーリンクから新たな情報源の候補を発見することができ、自律的なＷｅｂ情報収集が可能になる。

また、更新処理部６は、レコードの棄却処理（ステップＳ６）を有し、レコードの更新後の値が所定条件を満たす場合には、そのレコードを複数のバケット２ａ〜２ｃまたは書込バッファのいずれにも書き込まないので、更新する必要のなくなったレコードの読み書きを回避することができる。

なお、更新処理部６は、ステップＳ６において、レコードを書き込まないことにより、レコードの棄却処理を実現したが、さらに、情報源登録テーブル９ａから対応する情報源識別子（そのレコードに対応する識別子）を削除してもよい。
これにより、一度不要と判定された情報源を、再度登録することが可能になる。

また、この発明の実施の形態１による更新処理部６は、読込バッファ４のすべてのレコードを処理し終えた後に、次回処理対象バケットに対応する第２の書込バッファを新たな読込バッファとし、元の読込バッファおよび処理対象バケットを削除する。すなわち、ステップＳ１０、Ｓ１１においては、書込バッファｔ＋１を削除して読込バッファ４を空にしたが、代わりに、読込バッファ４を削除し、書込バッファｔ＋１を新たな読込バッファとしてもよい。
これにより、書込バッファｔ＋１のレコードをバケットｔ＋１に書き込み、再度読込バッファに読み込むオーバーヘッドを回避することができる。

また、上記説明では、情報源をＷｅｂページの情報としたが、ファイルサーバ上のファイルとしてもよい。
この場合、情報源の識別子は、ファイルのパス名であり、更新処理部６は、処理対象バケット内の対象レコードに対応するファイルの内容をダウンロードして、対象レコードの更新後の値を決定するとともに、対象レコードに対応するファイルがディレクトリである場合には、そのディレクトリ内のファイルおよびサブディレクトリの各パス名を登録要求として要求受付部１０に送付する。

このように、Ｗｅｂページのハイパーリンクに代えて、ディレクトリ（フォルダ）の情報を利用し、更新処理部６は、ステップＳ５において、ディレクトリ内のファイルのパス名を情報源識別子とする登録要求を要求受付部１０に送信することにより、ファイルの追加に自律的に対応することができる。
また、ファイルの削除に対しては、ステップＳ６の棄却処理で対応することができる。

実施の形態２．
なお、上記実施の形態１（図３）では、ステップＳ４の判定結果がＮＯ（レコード処理が未完了）の場合に、無条件で次回更新時刻ｔ’の決定処理（ステップＳ５）を実行したが、図５のように、所定数処理または所定時間経過の判定条件（ステップＳ５１）の正否に応じて、次回更新時刻ｔ’の決定処理（ステップＳ５２、Ｓ５３）を実行してもよい。

図５はこの発明の実施の形態２による更新処理部６の動作を示すフローチャートであり、前述（図３参照）と同様の処理については、図示が省略されている。
なお、この発明の実施の形態２に係る周期更新データ管理システムの全体構成は、前述（図１参照）と同様であり、更新処理部６の一部動作が異なるのみである。

図５において、更新処理部６は、ステップＳ４の判定結果がＮＯ（読込バッファ４に未処理レコードが残存）の場合には、読込バッファ４の処理を開始してから所定数のレコードを処理したか否か、または、所定時間が経過したか否かを判定する（ステップＳ５１）。

ステップＳ５１において、条件が不成立（すなわち、ＮＯ）と判定されれば、未処理レコードの１つを選択して、前述のステップＳ５と同様の処理（ステップＳ５２）を実行する。
ただし、ステップＳ５３において選択されるレコードは、未処理レコードのうち、以下の値Ｋが最も大きいものとする。

Ｋ＝（現在時刻ｔ−最終更新時刻３４）／更新周期３５

この値Ｋは、レコードの更新周期に対する相対的な累積待ち時間の大きさを表しており、累積待ち時間の影響が大きいレコードから優先して処理することに対応する。

一方、ステップＳ５１において、条件が成立する（すなわち、ＹＥＳ）と判定されれば、読込バッファ４の更新に要する時間（負荷）が大き過ぎて、後続バケットの更新に悪影響を及ぼすことを意味するので、未処理レコードの１つを選択して情報源から情報取得する処理（ステップＳ５２）を実行せずに、次回更新時刻ｔ’のみを設定して（ステップＳ５３）、ステップＳ７に進む。
このとき、次回更新時刻ｔ’は、現在時刻ｔに所定の定数（たとえば、「１」）または所定範囲の乱数を加算することにより、決定することができる。

以上のように、この発明の実施の形態２（図５）によれば、更新処理部６は、処理対象バケットの所定数のレコードを処理し終えたか、処理対象バケットの処理開始から所定時間が経過した際（ステップＳ５１の判定結果がＮＯの場合）に、未処理のレコードに対応する情報源を参照せずに、次回更新時刻ｔ’を所定値に更新して（ステップＳ５３）、複数のバケット２ａ〜２ｃのうちの１つ、または書込バッファ５ａ、５ｂの１つの末尾に書き込む。

このように、バケットの更新処理を打ち切る処理（ステップＳ５１、Ｓ５３）を有することにより、特定バケットへの更新負荷の集中によって、後続バケットの更新時刻に悪影響を及ぼすことを回避することができる。
また、更新処理部６は、ステップＳ５１の条件が不成立の場合に、レコードを相対累積待ち時間に基づいて、処理対象バケットの各レコードを優先度順に処理（ステップＳ５２）するので、高負荷時であってもレコードの更新を公平に実行することができる。

実施の形態３．
なお、上記実施の形態１、２では特に言及しなったが、図６のように、次々回以降に処理対象となるすべてのバケットに書き込まれるレコードを一時的に格納するために、第１の書込バッファ５ｘとは別に、第２の書込バッファ５ｙを設けてもよい。
図６はこの発明の実施の形態３に係る周期更新データ管理システムを示すブロック構成図であり、前述（図１参照）と同様のものについては、前述と同一符号を付して、または符号の後に「Ａ」を付して詳述を省略する。

図６において、第１の書込バッファ５ｘおよび第２の書込バッファ５ｙは、更新処理部６Ａおよび要求受付部１０Ａの制御下で、記憶部１Ａ内のバケット２ａ〜２ｃに対する格納データを保持する。
この場合、前述の書込バッファ５ａ、５ｂの数とは異なり、書込バッファ数は、バケット２ａ〜２ｃの数とは無関係に、２つ（第１および第２の書込バッファ５ｘ、５ｙ）である。

第１の書込バッファ５ｘは、記憶部１Ａ内の単一バケット（処理対象バケットの次のバケット）に対応し、第１の書込バッファ５ｘには、単一バケットに書き込まれるレコードが格納される。
また、第２の書込バッファ５ｙには、単一バケット以外のバケットに書き込まれるレコードが格納される。

第２の記憶部８Ａは、前述の情報源登録テーブル９ａに対応した情報源登録テーブル９ｂに加えて、棄却バケット１２ａ、１２ｂ、・・・を備えている。
棄却バケット１２ａ、１２ｂ、・・・は、前述と同様に、バケット２ａ〜２ｃに対応した複数のレコードを格納する。
さらに、制御端末１１から要求受付部１０Ａに対しては、前述の登録要求のみならず、検索要求および更新要求が送信される。

図７は第２の記憶部８Ａ内の情報源登録テーブル９ｂを詳細に示す説明図である。
図７において、情報源登録テーブル９ｂは、前述（図１参照）の情報源登録テーブル９ａとは異なり、情報源識別子９１に加えて、情報源（Ａ、Ｂ、Ｃ、・・・）７ａ、７ｂ、７ｃ、・・・ごとに、次回更新時刻９２を格納している。
次回更新時刻９２は、情報源識別子９１に対応するレコード３の次回更新時刻３２（図２参照）の値であり、一部の情報源については、棄却済みであることを示す場合がある。

図８は記憶部１Ａ内のバケット２ａ〜２ｃに含まれる情報を詳細に示す説明図であり、前述（図２参照）と同様のものについては、前述と同一符号を付して詳述を省略する。
図８において、バケット２は、前述（図２）とは異なり、レコード３に加えて、形式の異なる更新レコード３０を含む場合がある。

更新レコード３０は、前述と同様の情報源識別子３１および次回更新時刻３２などに加えて、固定更新周期３６と、同一情報源に対応するレコードへの更新を指示する更新内容３７とを含む。
更新内容３７は、レコード３の更新対象項目名およびその値を含む。

次に、図９〜図１２のフローチャートを参照しながら、この発明の実施の形態３による更新処理部６Ａおよび要求受付部１０Ａの動作について説明する。
まず、図９を参照しながら、更新処理部６Ａの動作について説明する。
図９において、ステップＳ１０１〜Ｓ１０４、Ｓ１０６、Ｓ１０７およびＳ１１８は、それぞれ、前述（図３参照）のステップＳ１〜Ｓ６およびＳ１２と同様の処理である。

まず、更新処理部６Ａは、バケットｔの内容を読込バッファ４に読み込み（ステップＳ１０１〜Ｓ１０３）、ステップＳ１０４で未処理レコードが残っている（すなわち、ＮＯ）と判定されれば、読込バッファ４内の未処理レコードの１つを選択して処理対象とし、読込バッファ４中に処理対象レコードと同一の情報源識別子３１（図８参照）を持つ更新レコードが存在すれば、その更新レコードの更新内容３７にしたがって処理対象レコードを更新し、更新内容３７をその更新レコードに反映させる（ステップＳ１０５）。

続いて、情報源から情報を取得し、レコードの更新処理および次回更新時刻ｔ’の決定処理（ステップＳ１０６）を行い、レコードが棄却対象であるか否かを判定する（ステップＳ１０７）。
ステップＳ１０７でレコードが棄却対象である（すなわち、ＹＥＳ）と判定されればステップＳ１０８に進み、レコードが棄却対象でない（すなわち、ＮＯ）と判定されればステップＳ１０９に進む。

ステップＳ１０８においては、更新後のレコードを棄却バケット１２ａ、１２ｂ、・・・のいずれかの末尾に追加する。なお、棄却バケットは単一でもよいが、所定サイズに達したら新たな棄却バケットに書き込むようにして、複数に分割してもよい。
さらに、ステップＳ１０８においては、レコードの情報源識別子に対応する情報源登録テーブル９ｂの次回更新時刻９２に対し、書き込んだ棄却バケットを識別するための情報を設定して、ステップＳ１０４に戻る。

一方、ステップＳ１０９においては、次回更新時刻ｔ’と現在時刻ｔに「１」を加算した時刻とを比較して、「ｔ’＝ｔ＋１」であるか否かを判定する。
ステップＳ１０９において、ｔ’＝ｔ＋１（すなわち、ＹＥＳ）と判定されればステップＳ１１０に進み、ｔ’≠ｔ＋１（すなわち、ＮＯ）と判定されればステップＳ１１３に進む。

ステップＳ１１０〜Ｓ１１２においては、レコードの書き込み先として第１の書込バッファ５ｘを選択する。
まず、第１の書込バッファ５ｘが満杯（フル）であるか否かを判定し（ステップＳ１１０）、満杯でない（すなわち、ＮＯ）と判定されれば、直ちにステップＳ１１２に進み、満杯である（すなわち、ＹＥＳ）と判定されれば、第１の書込バッファ５ｘの各レコードを一括してバケットｔ＋１の末尾に追加して、第１の書込バッファ５ｘを空にする（ステップＳ１１１）。

続いて、ステップＳ１１２において、ステップＳ１０６で更新したレコードを第１の書込バッファ５ｘの末尾に追加するとともに、そのレコードの情報源識別子に対応する情報源登録テーブル９ｂの次回更新時刻９２を「ｔ＋１（＝ｔ’）」に設定して、ステップＳ１０４に戻る。

一方、ステップＳ１１３〜Ｓ１１５においては、レコードの書き込み先として第２の書込バッファ５ｙを選択する。
まず、第２の書込バッファ５ｙが満杯（フル）であるか否かを判定し（ステップＳ１１３）、満杯でない（すなわち、ＮＯ）と判定されれば、直ちにステップＳ１１５に進み、満杯である（すなわち、ＹＥＳ）と判定されれば、第２の書込バッファ５ｙの各レコードを次回更新時刻順にソートして、同一の次回更新時刻ごとに一括して対応するバケットの末尾に追加し、すべてのレコードを書き込み終えたら第２の書込バッファを空にする（ステップＳ１１４）。

続いて、ステップＳ１１５において、ステップＳ１０６で更新したレコードを第２の書込バッファ５ｙの末尾に追加するとともに、そのレコードの情報源識別子に対応する情報源登録テーブルの次回更新時刻９２を「ｔ’」に設定してステップＳ１０４に戻る。

一方、ステップＳ１０４において、読込バッファ４のすべてのレコード処理が完了した（すなわち、ＹＥＳ）と判定されれば、第１の書込バッファ５ｘを「新たな読込バッファ」とし、元の読込バッファ４を空にして「新たな第１の書込バッファ」とし、読込バッファ４と第１の書込バッファ５ｘとの役割を交換する（ステップＳ１１６）。

最後に、ステップＳ１１４と同様に、第２の書込バッファ５ｙをフラッシュして空にし（ステップＳ１１７）、処理し終えたバケットｔを削除して（ステップＳ１１８）、ステップＳ１０１に戻る。

次に、図１０を参照しながら、登録要求を受信したときの要求受付部１０Ａの動作について説明する。
図１０において、ステップＳ２０１、Ｓ２０２およびＳ２０４は、それぞれ、前述（図４参照）のステップＳ２１、Ｓ２２およびＳ２４と同様の処理である。

まず、要求受付部１０Ａは、ステップＳ２０１で登録要求を受信すると、ステップＳ２０２で情報源登録テーブル９ｂを検索し、登録要求の情報源識別子Ｒが見付かった場合にはステップＳ２０５に進み、情報源識別子Ｒが見付からなかった場合にはステップＳ２０３に進む。

ステップＳ２０３においては、登録要求の情報源識別子Ｒに対応するレコードを初期化し、そのときの次回（初回）更新時刻ｔ’を決定する。次回更新時刻ｔ’は、前述のように、現在時刻ｔに所定定数（たとえば、「１」）、または所定範囲の乱数を加算して決定することができる。
続いて、ステップＳ２０４で情報源識別子Ｒを情報源登録テーブル９ｂに追加登録し、ステップＳ２０８に進む。

ステップＳ２０８においては、図９内のステップＳ１０９〜Ｓ１１５と同様に、次回更新時刻ｔ’の値に応じて、第１または第２の書込バッファ５ｘ、５ｙの末尾に情報源識別子Ｒに対応するレコードを書き込み、ステップＳ２０１に戻る。

一方、ステップＳ２０５においては、情報源登録テーブル９ｂ内の情報源識別子Ｒに対応する次回更新時刻９２が棄却バケットを示しているか否かを判定し、棄却バケットを示す（すなわち、ＹＥＳ）と判定されればステップＳ２０６に進み、棄却バケットを示していない（すなわち、ＮＯ）と判定されればステップＳ２０１に戻る。

ステップＳ２０６においては、情報源識別子Ｒに対応する棄却バケットを末尾から走査し、情報源識別子Ｒに対応するレコードが最後に棄却された時点の値を取得する。
続いて、ステップＳ２０３と同様に、次回更新時刻ｔ’の値を決定して（ステップＳ２０７）、ステップＳ２０８に進む。

次に、図１１を参照しながら、検索要求（検索対象情報源の情報源識別子Ｑを含む）を受信したときの要求受付部１０Ａの動作について説明する。
図１１において、ステップＳ２１１は、前述（図１０参照）のステップＳ２０１と同様の処理である。

まず、要求受付部１０Ａは、ステップＳ２１１で検索要求を受信すると、検索要求の情報源識別子Ｑに関して情報源登録テーブル９ｂを検索し（ステップＳ２１２）、情報源識別子Ｑが見付かった場合にはステップＳ２１３に進み、情報源識別子Ｑが見付からなかった場合にはステップＳ２１６に進む。

ステップＳ２１３においては、情報源登録テーブル９ｂから情報源識別子Ｑに対応する次回更新時刻９２を取得して、「ｓ」とする。
続いて、読込バッファ４、第１の書込バッファ５ｘ、第２の書込バッファ５ｙ、およびバケットｓの順に、先頭から走査を行い、情報源識別子Ｑに対応するレコードを取得する（ステップＳ２１４）。

ただし、次回更新時刻ｓ＝現在時刻ｔでない場合には、ステップＳ２１４において、読込バッファ４の走査処理をスキップすることができる。
以下、取得したレコードを要求元に送信して（ステップＳ２１５）、ステップＳ２１１に戻る。
一方、ステップＳ２１６においては、検索失敗通知を要求元に送信し、ステップＳ２１１に戻る。

次に、図１２を参照しながら、更新要求（検索対象情報源の情報源識別子Ｕと、更新内容とを含む）を受信したときの要求受付部１０Ａの動作について説明する。
図１２において、ステップＳ２２１は、前述（図１１参照）のステップＳ２１１と同様の処理である。

まず、要求受付部１０Ａは、ステップＳ２２１で検索要求を受信すると、更新要求の情報源識別子Ｕに関して情報源登録テーブル９ｂを検索し（ステップＳ２２２）、情報源識別子Ｕが見付かった場合にはステップＳ２２３に進み、情報源識別子Ｑが見付からなかった場合にはステップＳ２２１に戻る。

ステップＳ２２３においては、情報源登録テーブル９ｂから情報源識別子Ｕに対応する次回更新時刻９２を取得して、「ｒ」とする。
続いて、情報源識別子３１を「Ｕ」、次回更新時刻３２を「ｒ」、更新内容３７を更新要求に含まれる更新内容として、更新レコード３０を構成し、次回更新時刻３２の値ｒに応じて、適当なバッファに書き込む（ステップＳ２２４）。

すなわち、更新レコード３０を、次回更新時刻ｒ＝現在時刻ｔであれば読込バッファ４に追加し、ｒ＝ｔ＋１であれば第１の書込バッファ５ｘに追加し、ｒ＞ｔ＋１であれば第２の書込バッファ５ｙに追加する。
なお、第１の書込バッファ５ｘおよび第２の書込バッファ５ｙが満杯であれば、図９内のステップＳ１１１、ステップＳ１１４と同様にフラッシュ処理を行う。以下、ステップＳ２２１に戻る。

以上のように、この発明の実施の形態３（図６）に係る周期更新データ管理システムは、記憶部１Ａに接続された単一の読込バッファ４と、記憶部１Ａに接続された第１および第２の書込バッファ５ｘ、５ｙとを備え、更新処理部６Ａは、処理対象バケットに格納されたすべての対象レコードを一括して読込バッファ４に読み込み、読込バッファ４内の各対象レコードについて、複数の情報源の中から対象レコードに対応する対象情報源を参照して、更新後の値および次回更新時刻を決定する。

また、更新処理部６Ａは、決定された次回更新時刻が現在時刻ｔよりも１単位だけ大きな値であって、かつ第１の書込バッファ５ｘにすでに所定数のレコードが格納されている場合には、第１の書込バッファ５ｘ内のすべてのレコードを次回更新時刻に対応する領域の末尾に書き込んで、第１の書込バッファ５ｘを空にし、決定された次回更新時刻が現在時刻よりも１単位だけ大きな値である場合には、第１の書込バッファ５ｘの末尾にすべてのレコードの各々の更新後の値を格納する。

また、更新処理部６Ａは、決定された次回更新時刻が現在時刻ｔよりも２単位以上大きな値であって、かつ第２の書込バッファ５ｙにすでに所定数のレコードが格納されている場合には、第２の書込バッファ５ｙ内のすべてのレコードを次回更新時刻の順に、すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、第２の書込バッファ５ｙを空にし、決定された前記次回更新時刻が前記現在時刻よりも２単位以上大きな値である場合には、第２の書込バッファ５ｙの末尾にすべてのレコードの各々の更新後の値を格納し、読込バッファ４のすべてのレコードを処理し終えた後に、読込バッファ４と第１の書込バッファ５ｘとの役割を交換し、第２の書込バッファ５ｙ内のすべてのレコードを次回更新時刻の順に、すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、第２の書込バッファ５ｙを空にしてから、処理対象バケットを削除する。

このように、次々回以降に処理対象となるすべてのバケットに書き込まれるレコードを一時的に格納する第２の書込バッファ５ｙを備えることにより、前述（図１）のようにバケットごとに書込バッファ５ａ、５ｂ、・・・を用意した場合と比較して、書込バッファごとの使用率の違いによる記憶効率の低下を防ぐことができ、記憶部１Ａ（磁気ディスク装置）への書き込み頻度を抑制することができる。

また、更新処理部６Ａは、第２の書込バッファ５ｙに格納されたレコードを複数のバケット２に振り分けて書き込む際に、次回更新時刻ごと、すなわちバケットごとにレコードを並べ替えて処理する（ステップＳ１１４、Ｓ１１７）ので、シーケンシャルアクセスに近い性能を得ることができる。

また、次回処理対象となるバケットに書き込まれるレコードを一時的に格納する第１の書込バッファ５ｘを備え、処理対象バケットの切り換え時に、第１の書込バッファ５ｘを新たな読込バッファとする（ステップＳ１１６）ので、次回処理対象バケットへの書き込みと再読み込みによるオーバーヘッドを低減することができる。

また、この発明の実施の形態３によれば、第２の記憶部８Ａ内の情報源登録テーブル９ｂは、各情報源に対応するレコードが格納されているバケット（領域）を識別するための領域識別情報（次回更新時刻）を含み、更新処理部６Ａおよび要求受付部１０Ａは、複数の情報源のいずれかに対応するレコードを記憶部１Ａ内の複数のバケット（領域）２のいずれかに書き込む際に、情報源登録テーブル９ｂのそのレコードに対応する領域識別情報を更新する。

また、要求受付部１０Ａは、識別子を含む検索要求を受け付け、その識別子が情報源登録テーブル９ｂに格納されている場合には、その識別子に対応するバケット（領域）を走査してその識別子に対応するレコードを読み込み、そのレコードの内容を検索要求の要求元に返信する。

このように、情報源登録テーブル９ｂにおいて、情報源識別子とともに次回更新時刻を格納することにより、すべてのバケットを走査することなく、情報源に対応するレコードの内容を検索することができる。

また、この発明の実施の形態３によれば、要求受付部１０Ａは、複数の情報源のいずれかに対応する識別子と、その情報源に対応するレコードに対する更新内容とを含む更新要求を受け付け、識別子が情報源登録テーブル９ｂに格納されている場合には、その識別子に対応するバケット（領域）の末尾にその更新要求を書き込む。

また、更新処理部６Ａは、処理対象バケットに格納されたレコードおよび更新要求を識別子の順に処理し、対応する情報源を参照した結果と、更新要求とに基づいてレコードの更新後の値を決定する。
このように、バケット２ａ〜２ｃには、通常のレコード３に加えて、更新レコード３０を格納し、更新処理部６Ａでその処理（ステップＳ１０５）を行うことにより、情報源に対応するレコードの内容を外部から更新することができる。

また、この発明の実施の形態３によれば、第２の記憶部８Ａは、複数のレコードを格納する棄却バケット１２ａ、１２ｂを有し、更新処理部６Ａは、レコードの更新後の値が所定条件を満たす場合には、そのレコードを棄却バケットの末尾に書き込むとともに、情報源登録テーブル９ｂのそのレコードに対応する領域識別情報を棄却バケットに設定する。

また、要求受付部１０Ａは、受け付けた登録要求の情報源識別子が情報源登録テーブル９ｂに格納されており、かつ対応する領域識別情報が棄却バケットを示している場合には、棄却バケットを走査してその識別子に対応するレコードの値を読み込み、そのレコードの値に基づいてそのレコードを再設定して、複数のバケット２のうちの１つ、または書込バッファの１つの末尾に書き込むとともに、情報源登録テーブル９ｂのそのレコードに対応する領域識別情報を更新する。

このように、棄却バケット１２ａ、１２ｂ、・・・を有し、棄却されたレコードの値を棄却バケットに格納するとともに、棄却レコードの格納先を情報源登録テーブル９ｂに記録する（ステップＳ１０８）ことにより、要求受付部１０Ａが登録要求を受け付けた際に、棄却済みレコードを棄却時点の値で再登録することができる。

なお、上記実施の形態３では、第１および第２の書込バッファ５ｘ、５ｙを用いたが、第１の書込バッファ５ｘを用いず、次回更新時刻ｔ＋１のレコードをも合わせて第２の書込バッファ（単一の書込バッファ）５ｙに書き込んでもよい。
この場合、周期更新データ管理システムは、記憶部１Ａに接続された単一の読込バッファ４と、記憶部１Ａに接続された単一の書込バッファ５ｙとを備え、更新処理部６Ａは、処理対象バケットに格納されたすべての対象レコードを一括して読込バッファ４に読み込み、読込バッファ４内の各対象レコードについて、複数の情報源の中から対象レコードに対応する対象情報源を参照して、更新後の値および次回更新時刻を決定する。

また、更新処理部６Ａは、書込バッファ５ｙにすでに所定数のレコードが格納されている場合には、書込バッファ５ｙ内のすべてのレコードを次回更新時刻の順に、すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、書込バッファ５ｙを空にしてから、書込バッファ５ｙの末尾に対象レコードの更新後の値を格納する。

また、更新処理部６Ａは、読込バッファ４のすべてのレコードを処理し終えた後に、書込バッファ５ｙが空でない場合には、書込バッファ５ｙ内のすべてのレコードを次回更新時刻の順に、すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、書込バッファ５ｙを空にしてから、処理対象バッファを削除する。

これにより、次回処理対象バケットのレコードの一部に対する書き込みおよび読み込みを回避する効果は得られないが、前述（図１）のようにバケット２ごとに書込バッファ５ａ、５ｂ、・・・を用意した場合の記憶効率の低下を防ぐことができ、記憶部１Ａ（磁気ディスク装置）への書き込み頻度を抑制する効果は維持される。

また、上記実施の形態１〜３では、次回更新時刻の単位を固定（たとえば、１日に設定）したが、たとえば１日以内の更新については、１時間単位、１日以上後の更新については、１日単位、のように単位を可変設定してもよい。

このように、次回更新時刻の時間分解能に対応する単位を、現在時刻との差の大きさに応じて異なる値に設定することにより、最短更新周期を小さくしながら、非常に小さなバケットが多数必要になることを回避し、記憶部１Ａ（磁気ディスク）へのアクセス効率および更新速度の向上を両立させることができる。

さらに、上記実施の形態１〜３では、記憶部１Ａとして磁気ディスク装置を用い、情報源７ａ〜７ｃとしてＷｅｂページやファイルを用いたが、記憶部１Ａとしてフラッシュメモリを用い、情報源７ａ〜７ｃとして通信機能を有するセンサ素子を用いてもよい。
たとえば、情報源７ａ〜７ｃとして通信機能を有するセンサ素子を用いた場合、更新処理部６、６Ａは、処理対象バッファ内の対象レコードに対応するセンサ素子からデータを取得して、対象レコードの更新後の値を決定し、要求受付部１０、１０Ａは、センサ素子からの登録要求を受け付けることになる。

一般に、フラッシュメモリは、純粋なランダムアクセスには適さないが、ブロック単位でのアクセスが機能面や性能面から要求されるので、バケット２ａ〜２ｃとしてフラッシュメモリのブロックを用いることにより、これらの制約による性能低下を回避することができる。

また、この場合、レコード３の最終状態３３（図２、図８参照）には、センサ素子から取得したデータ値自体を格納し、更新処理手段６、６Ａは、ステップ５、Ｓ１０６（図３、図９参照）において、最終状態３３の値の変化率（単位時間当たり）に比例して次回更新時刻を決定することもできる。
さらに、要求受付部１０、１０Ａは、センサ素子自体からの登録要求を受け付けることにより、センサ素子がアドホック（ａｄ ｈｏｃ）に追加設置される環境にも対応することができる。

この発明の実施の形態１に係る周期更新データ管理システムを示すブロック構成図である。 この発明の実施の形態１によるバケット内のレコードに含まれる情報を詳細に示す説明図である。 この発明の実施の形態１による更新処理部の動作を示すフローチャートである。 この発明の実施の形態１による要求受付部の動作を示すフローチャートである。 この発明の実施の形態２による更新処理部の要部動作を示すフローチャートである。 この発明の実施の形態３に係る周期更新データ管理システムを示すブロック構成図である。 この発明の実施の形態３による情報源登録テーブルを詳細に示す説明図である。 この発明の実施の形態３によるバケット内のレコードに含まれる情報を詳細に示す説明図である。 この発明の実施の形態３による更新処理部の動作を示すフローチャートである。 この発明の実施の形態３による登録要求受信時の要求受付部の動作を示すフローチャートである。 この発明の実施の形態３による検索要求受信時の要求受付部の動作を示すフローチャートである。 この発明の実施の形態３による更新要求受信時の要求受付部の動作を示すフローチャートである。

符号の説明

１、１Ａ 記憶部、２、２ａ〜２ｃ バケット（領域）、３ レコード、４ 読込バッファ、５ａ、５ｂ 書込バッファ、５ｘ 第１の書込バッファ、５ｙ 第２の書込バッファ、６、６Ａ 更新処理部、７ａ〜７ｃ 情報源、８、８Ａ 第２の記憶部、９ａ、９ｂ 情報源登録テーブル、１０、１０Ａ 要求受付部、１１ 制御端末、１２ａ、１２ｂ 棄却バケット。

Claims (19)

1. 記憶部と更新処理部とを備えた周期更新データ管理システムであって、
   前記記憶部は、外部の複数の情報源と１対１に対応する複数のレコードを、各々の次回更新時刻に基づいて異なる複数の領域に格納し、
   前記更新処理部は、
   前記複数の領域のうち、現在時刻に対応するものを処理対象領域として選択し、
   前記処理対象領域内の対象レコードについて、前記複数の情報源の中から前記対象レコードに対応する対象情報源を参照し、前記対象情報源から取得した取得情報に基づいて、前記対象レコードの更新後の値を決定するとともに、
   前記取得情報の前回参照時からの変化の有無または大きさに基づいて、前記対象レコードの次回更新時刻を決定し、
   決定された前記次回更新時刻に対応する領域の末尾に、前記対象レコードの更新後の値を格納し、
   前記処理対象領域内のすべての対象レコードを処理し終えた後に、前記処理対象領域を削除することを特徴とする周期更新データ管理システム。
2. 前記記憶部に接続された単一の読込バッファと、
   前記記憶部内の複数の領域と１対１に対応する所定容量の複数の書込バッファとを備え、
   前記更新処理部は、
   前記処理対象領域に格納されたすべての対象レコードを一括して前記読込バッファに読み込み、
   前記読込バッファ内の各対象レコードについて、前記複数の情報源の中から前記対象レコードに対応する対象情報源を参照して、前記更新後の値および前記次回更新時刻を決定するとともに、
   決定された前記次回更新時刻に対応する第１の書込バッファを、前記複数の書込バッファから選択し、
   前記第１の書込バッファにすでに所定容量のレコードが格納されている場合には、
   前記第１の書込バッファ内のすべてのレコードを前記第１の書込バッファに対応する領域の末尾に書き込んで、前記第１の書込バッファを空にしてから、
   前記第１の書込バッファの末尾に前記対象レコードの更新後の値を格納し、
   前記読込バッファのすべてのレコードを処理し終えた後に、
   次に処理対象となる次回処理対象領域に対応する第２の書込バッファ内のすべての次回対象レコードを、前記次回処理対象領域の末尾に書き込んで、前記第２の書込バッファを空にしてから、
   前記第２の書込バッファおよび前記処理対象領域を削除することを特徴とする請求項１に記載の周期更新データ管理システム。
3. 前記更新処理部は、
   前記読込バッファのすべてのレコードを処理し終えた後に、
   前記次回処理対象領域に対応する第２の書込バッファを新たな読込バッファとし、
   元の前記読込バッファおよび前記処理対象領域を削除することを特徴とする請求項２に記載の周期更新データ管理システム。
4. 前記記憶部に接続された単一の読込バッファと、
   前記記憶部に接続された単一の書込バッファとを備え、
   前記更新処理部は、
   前記処理対象領域に格納されたすべての対象レコードを一括して前記読込バッファに読み込み、
   前記読込バッファ内の各対象レコードについて、前記複数の情報源の中から前記対象レコードに対応する対象情報源を参照して、前記更新後の値および前記次回更新時刻を決定するとともに、
   前記書込バッファにすでに所定数のレコードが格納されている場合には、
   前記書込バッファ内のすべてのレコードを前記次回更新時刻の順に、前記すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、前記書込バッファを空にしてから、
   前記書込バッファの末尾に前記対象レコードの更新後の値を格納し、
   前記読込バッファのすべてのレコードを処理し終えた後に、
   前記書込バッファが空でない場合には、
   前記書込バッファ内のすべてのレコードを前記次回更新時刻の順に、前記すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、前記書込バッファを空にしてから、
   前記処理対象領域を削除することを特徴とする請求項１に記載の周期更新データ管理システム。
5. 前記記憶部に接続された単一の読込バッファと、
   前記記憶部に接続された第１および第２の書込バッファとを備え、
   前記更新処理部は、前記処理対象領域に格納されたすべての対象レコードを一括して前記読込バッファに読み込み、
   前記読込バッファ内の各対象レコードについて、前記複数の情報源の中から前記対象レコードに対応する対象情報源を参照して、前記更新後の値および前記次回更新時刻を決定するとともに、
   決定された前記次回更新時刻が前記現在時刻よりも１単位だけ大きな値であって、かつ前記第１の書込バッファにすでに所定数のレコードが格納されている場合には、
   前記第１の書込バッファ内のすべてのレコードを前記次回更新時刻に対応する領域の末尾に書き込んで、前記第１の書込バッファを空にし、決定された前記次回更新時刻が前記現在時刻よりも１単位だけ大きな値である場合には、
   前記第１の書込バッファの末尾に前記すべてのレコードの各々の更新後の値を格納し、
   決定された前記次回更新時刻が前記現在時刻よりも２単位以上大きな値であって、かつ前記第２の書込バッファにすでに所定数のレコードが格納されている場合には、
   前記第２の書込バッファ内のすべてのレコードを前記次回更新時刻の順に、前記すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、前記第２の書込バッファを空にし、決定された前記次回更新時刻が前記現在時刻よりも２単位以上大きな値である場合には、
   前記第２の書込バッファの末尾に前記すべてのレコードの各々の更新後の値を格納し、
   前記読込バッファのすべてのレコードを処理し終えた後に、
   前記読込バッファと前記第１の書込バッファとの役割を交換し、
   前記第２の書込バッファ内のすべてのレコードを前記次回更新時刻の順に、前記すべてのレコードの各々の次回更新時刻に対応する領域の末尾に書き込んで、前記第２の書込バッファを空にしてから、
   前記処理対象領域を削除することを特徴とする請求項１に記載の周期更新データ管理システム。
6. 前記次回更新時刻の時間分解能に対応する単位は、前記現在時刻との差の大きさに応じて異なる値に設定されたことを特徴とする請求項１から請求項５までのいずれか１項に記載の周期更新データ管理システム。
7. 前記記憶部とは異なる第２の記憶部と、
   前記第２の記憶部に接続された要求受付部とを備え、
   前記第２の記憶部は、前記記憶部に格納されたすべてのレコードに対応する各情報源の識別子を格納する情報源登録テーブルを有し、
   前記要求受付部は、
   前記複数の情報源のいずれか１つに対応する識別子を含む登録要求を受け付け、前記識別子が前記情報源登録テーブルに格納されていない場合には、前記識別子を前記情報源登録テーブルに追加するとともに、
   前記識別子に対応するレコードを所定値に初期化して、前記記憶部内の複数の領域のうちの１つ、または前記書込バッファの１つの末尾に書き込むことを特徴とする請求項１から請求項６までのいずれか１項に記載の周期更新データ管理システム。
8. 前記情報源登録テーブルは、前記各情報源に対応するレコードが格納されている領域を識別するための領域識別情報を含み、
   前記更新処理部および前記要求受付部は、
   前記複数の情報源のいずれかに対応するレコードを前記記憶部内の複数の領域のいずれかに書き込む際に、前記情報源登録テーブルの前記レコードに対応する領域識別情報を更新し、
   前記要求受付部は、
   前記識別子を含む検索要求を受け付け、前記識別子が前記情報源登録テーブルに格納されている場合には、前記識別子に対応する領域を走査して前記識別子に対応するレコードを読み込み、前記レコードの内容を前記検索要求の要求元に返信することを特徴とする請求項７に記載の周期更新データ管理システム。
9. 前記要求受付部は、
   前記複数の情報源のいずれかに対応する識別子と、前記情報源に対応するレコードに対する更新内容とを含む更新要求を受け付け、
   前記識別子が前記情報源登録テーブルに格納されている場合には、
   前記識別子に対応する領域の末尾に更新要求を書き込み、
   前記更新処理部は、前記処理対象領域に格納されたレコードおよび更新要求を前記識別子の順に処理し、
   対応する情報源を参照した結果と、更新要求とに基づいてレコードの更新後の値を決定することを特徴とする請求項８に記載の周期更新データ管理システム。
10. 前記更新処理部は、
    前記レコードの更新後の値が所定条件を満たす場合には、
    前記レコードを前記複数の領域または前記書込バッファのいずれにも書き込まないことを特徴とする請求項１から請求項９までのいずれか１項に記載の周期更新データ管理システム。
11. 前記更新処理部は、
    前記レコードの更新後の値が所定条件を満たす場合には、
    前記レコードを前記複数の領域または前記書込バッファのいずれにも書き込まず、
    前記レコードに対応する識別子を前記情報源登録テーブルから削除することを特徴とする請求項７から請求項９までのいずれか１項に記載の周期更新データ管理システム。
12. 前記第２の記憶部は、複数のレコードを格納する棄却領域を有し、
    前記更新処理部は、
    前記レコードの更新後の値が所定条件を満たす場合には、
    前記レコードを前記棄却領域の末尾に書き込むとともに、
    前記情報源登録テーブルの前記レコードに対応する領域識別情報を前記棄却領域に設定し、
    前記要求受付部は、
    受け付けた登録要求の情報源識別子が前記情報源登録テーブルに格納されており、かつ対応する領域識別情報が前記棄却領域を示している場合には、
    前記棄却領域を走査して前記識別子に対応するレコードの値を読み込み、前記レコードの値に基づいて前記レコードを再設定して、前記複数の領域のうちの１つ、または前記書込バッファの１つの末尾に書き込むとともに、
    前記情報源登録テーブルのレコードに対応する領域識別情報を更新することを特徴とする請求項８または請求項９に記載の周期更新データ管理システム。
13. 前記更新処理部は、
    前記処理対象領域の所定数のレコードを処理し終えたか、前記処理対象領域の処理開始から所定時間が経過した際に、
    未処理のレコードに対応する情報源を参照せずに、前記次回更新時刻を所定値に更新して、前記複数の領域のうちの１つ、または前記書込バッファの１つの末尾に書き込むことを特徴とする請求項１から請求項１２までのいずれか１項に記載の周期更新データ管理システム。
14. 前記更新処理部は、前記処理対象領域の各レコードを優先度順に処理することを特徴とする請求項１３に記載の周期更新データ管理システム。
15. 前記記憶部は、磁気ディスク装置であることを特徴とする請求項１から請求項１４までのいずれか１項に記載の周期更新データ管理システム。
16. 前記記憶部は、フラッシュメモリであることを特徴とする請求項１から請求項１４までのいずれか１項に記載の周期更新データ管理システム。
17. 前記情報源は、Ｗｅｂサイト上のＷｅｂページであり、
    前記情報源の識別子は、ＷｅｂページのＵＲＬであり、
    前記更新処理部は、
    前記処理対象領域内の対象レコードに対応するＷｅｂページの内容をダウンロードして、前記対象レコードの更新後の値を決定するとともに、
    前記対象レコードに対応するＷｅｂページからリンクを抽出して、得られたＵＲＬの各々を登録要求として前記要求受付部に送付することを特徴とする請求項７から請求項１２までのいずれか１項に記載の周期更新データ管理システム。
18. 前記情報源は、ファイルサーバ上のファイルであり、
    前記情報源の識別子は、前記ファイルのパス名であり、
    前記更新処理部は、
    前記処理対象領域内の対象レコードに対応するファイルの内容をダウンロードして、前記対象レコードの更新後の値を決定するとともに、
    前記対象レコードに対応するファイルがディレクトリである場合には、前記ディレクトリ内のファイルおよびサブディレクトリの各パス名を登録要求として前記要求受付部に送付することを特徴とする請求項７から請求項１２までのいずれか１項に記載の周期更新データ管理システム。
19. 前記情報源は、通信機能を有するセンサ素子であり、
    前記更新処理部は、前記処理対象領域内の対象レコードに対応するセンサ素子からデータを取得して、前記対象レコードの更新後の値を決定し、
    前記要求受付部は、前記センサ素子からの登録要求を受け付けることを特徴とする請求項７から請求項１２までのいずれか１項に記載の周期更新データ管理システム。

Images