JP6021741B2

JP6021741B2 - 時空間データベースの処理方法、プログラム及びシステム

Info

Publication number: JP6021741B2
Application number: JP2013118759A
Authority: JP
Inventors: 美紀榎; 洋堀井
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2013-06-05
Filing date: 2013-06-05
Publication date: 2016-11-09
Anticipated expiration: 2033-06-05
Also published as: JP2014235690A; US20140365478A1; US10614072B2; US9529844B2; US20170103109A1

Description

この発明は、ストリーム処理から時空間データベースを照会する技法に関するものである。

近年、ストリーム処理が普及するにつれて、ストリーム処理から時空間データベースを照会する機会が増えている。そのような例として、図１に示す、視聴数集計システムがある。

図１において、複数の家庭内のテレビに配置されたセットトップ・ボックス（ＳＴＢ）から刻々と入力される視聴情報は、{ユーザＩＤ(UserID),CH(チャンネル),Time(現在時刻)}というタプルを含む。

入力された視聴情報ストリームは、チャンネル毎視聴数集計１０２と示されているストリーム処理オペレータで、{CH,Time(現在時刻),num(集計数)}というタプルに集計される。追加情報取得１０４と示されているストリーム処理オペレータは、{CH,Time(現在時刻),num(集計数)}というタプルを受け取り、この中のチャンネル(CH)をキーとして、コンピュータ・システムのハードディスクに保存されている、Programテーブルとして図示されている番組データベース１０６にＤＢ問い合わせし、その問い合わせ結果と{CH,Time(現在時刻),num(集計数)}というタプルをjoinして、{CH,Time(現在時刻),num(集計数),Title(番組名),・・・}というタプルを生成し、出力する。なお、番組データベース１０６は、時間のフィールドも含むので、時空間データベースとも呼ばれる。

しかし、このようなシステムにおいて、ストリーム処理オペレータから時空間データベースへ照会するには、スキーマ・マッピング、ＳＱＬなどの複雑な記述が必要である。ＳＱＬの記述例は以下のとおりである。
SELECT Title, ・・・ FROM Program
WHERE CH = ? and Start <= CT and End > CT
// ここで、CTは現在時刻のタイムスタンプを示す

さらに、もしストリーム処理にリアルタイム性が要求されるなら、さらなる最適化が必要である。すなわち、ハードディスク・アクセスを伴うデータベース照会処理では、アクセスのボトルネックが生じる。しかし、データベースのデータを主記憶にロードするのはメモリを消費しすぎるので困難がある。さらには、問い合わせパラメータが現在時刻を含むので、データベースのキャッシュを利用するのもまた難しい。

このような処理に関して、以下のような従来技術が知られている。
先ず、特開２００６−３３８４３２号公報は、ストリームデータの一部、もしくは全部複製し、不揮発性の記憶媒体にアーカイブし、リアルタイムデータとアーカイブデータをシームレスに利用できる機構を提供し、複数のストリームデータ処理システムを連携させ、クエリ処理の性能を向上させる機構を提供する、ストリームデータ処理システムを開示する。

特開２００７−３２８７１６号公報は、ストリームデータとの突き合わせ対象と予測できるリレーションデータの階層的なキャッシュであるストリームプレディクトキャッシュをおくことで、データベースへのアクセス回数を削減し、性能を向上させることを開示する。

特開２０１１−２８６５８公報は、データベース装置が、キャッシュ装置のキャッシュトラック部により、キャッシュ上の最新のキャッシュエントリを把握し、これをキャッシュ管理テーブルに記録し、ベーステーブルの更新処理が発生したとき、キャッシュ管理テーブルを参照して、ベーステーブルの更新処理により影響を受け、かつ、キャッシュ上に存在するベーステーブル上のデータを特定し、この特定したデータのキャッシュエントリの破棄メッセージをキャッシュ装置へ送信し、キャッシュ装置が、破棄メッセージにより指示された、キャッシュ上のキャッシュエントリを破棄するデータベース装置を開示する。

Mohamed F. Mokbel, Xiaopeng Xiong, Walid G. Aref, Susanne E. Hambrusch, Sunil Prabhakar, Moustafa A. Hammad, "PLACE: a query processor for handling real-time spatio-temporal data streams", VLDB '04 Proceedings of the Thirtieth international conference on Very large data bases - Volume 30 Pages 1377-1380は、ある領域内に含まれるオブジェクトを検索するための時空間データの実現手法について記述する。

T. Y. Cliff Leung, Richard R. Muntz, "Generalized data stream indexing and temporal query processing", Research Issues on Data Engineering, 1992: Transaction and Query Processing, Second International Workshop on 2-3/02/1992, Pages 124 - 131には、時区間データの様々なjoinを実現させるためのindexの張り方の提案が記述されている。

しかし、これらの従来技術は、ストリーム処理オペレータから時空間データベースへ照会する際のパフォーマンスの問題を解決することを示唆するものではない。

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

Mohamed F. Mokbel, Xiaopeng Xiong, Walid G. Aref, Susanne E. Hambrusch, Sunil Prabhakar, Moustafa A. Hammad, "PLACE: a query processor for handling real-time spatio-temporal data streams", VLDB '04 Proceedings of the Thirtieth international conference on Very large data bases - Volume 30 Pages 1377-1380 T. Y. Cliff Leung, Richard R. Muntz, "Generalized data stream indexing and temporal query processing", Research Issues on Data Engineering, 1992: Transaction and Query Processing, Second International Workshop on 2-3/02/1992, Pages 124 - 131

従って、この発明の目的は、時空間データベースのデータを利用可能なストリーム処理を実現するための技法を提供することにある。

この発明は、時空間データベースのレコード内の時刻データを基にデータストリームを生成し、時空間を考慮したデータストリームのオペレーションを実現することによって、上記課題を解決する。

ここで、この発明の記述で使用される用語を改めて定義すると先ず、時空間データストリームとは、ストリーム内のタプルに有効期間（開始時刻、終了時刻）を含むものである。このようなタプルを時空間タプルとも呼ぶ。また、時空間データストリーム処理とは、タプルの有効期間に応じて処理を選択的に行うストリーム処理である。
さらに、Temporal Join（時間的JOIN)とは、有効期間が重複するタプルに対してJoinすることをいう。

さて、本発明に係る処理は、時空間データベースから時空間データストリームを生成する処理と、Temporal Joinを行う時空間データストリーム処理からなる。

本発明に係るシステムは、時空間データベースから時空間データストリームを生成する処理において、以下を実行する。
− 時空間データベースのレコードをレコード内の有効開始時刻順にソートし、現在時刻から一定時間分のレコードを、定期的に主記憶などにバッファする。
− バッファ内のレコードを、そのレコードの有効開始時刻以降になった時点で、時空間タプルとして出力する。
また好適には、本発明に係るシステムは、時空間データベースから時空間データストリームを生成する処理において、バッファ内のレコードの有効終了通知を、そのレコードの有効終了時刻以降になった時点で、時空間ストリームの受信側に送信する処理を実行する。

本発明に係るシステムはさらに、時空間データストリーム処理において、以下を実行する。
− 入力となる時空間タプルの有効期限を利用して、処理対象となる時空間タプルを選択し、ストリーム処理を行う。その結果、出力結果も時空間タプルとなる。
− 有効期限が切れた時点で、オペレータ内でバッファされた時空間タプルを削除する。
また好適には、本発明に係るシステムはさらに、時空間データストリーム処理において、有効終了時刻を受信した時刻で、オペレータ内でバッファされた時空間タプルをフラッシュする処理を実行する。

この発明によれば、時空間データベースのレコードをレコード内の有効開始時刻順にソートし、現在時刻から一定時間分のレコードを、定期的に主記憶などにバッファし、これに基づきストリームデータを生成するようにしたことにより、入来したストリームデータとのJoin処理が高速で行われるという効果が得られる。

従来技術の視聴数集計システムの概要を示す図である。本発明の実施例を実装するためのハードウェアの構成を示す図である。本発明の実施例の機能ブロック図である。バッファ・テーブル生成ルーチンの処理のフローチャートを示す図である。 Programテーブルからバッファ・テーブルにデータを抽出する様子を示す図である。データストリーム生成ルーチンの処理のフローチャートを示す図である。 Temporal Join処理のフローチャートを示す図である。 Temporal Join処理のフローチャートを示す図である。複数のデータベースに対してJoin処理を行う、従来技術の構成の例の図である。複数のデータベースに対してJoin処理を行う、本発明の構成の例の図である。料金変動制有料道路の課金処理システムの例を示す図である。時間制約のある株の注文処理の例を示す図である。

以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。

図２は、本発明を実施するためのシステムの一例の概要構成を示す図である。本発明は、これには限定されるわけではないが、ここでは視聴情報集計システムを例にとって説明する。

図２において、インターネット２０２には、各家庭のテレビに設置されたセットトップボツクス（ＳＴＢ）２０４ａ、２０４ｂ、・・・、２０４ｚが接続され、セットトップボツクス（ＳＴＢ）２０４ａ、２０４ｂ、・・・、２０４ｚは、時々刻々と、各ＳＴＢのユーザーＩＤと、チャンネル(CH)と、時刻の情報をインターネット２０２を介して送信する。

セットトップボツクス（ＳＴＢ）２０４ａ、２０４ｂ、・・・、２０４ｚからインターネット２０２を介して送られたユーザーＩＤと、チャンネル(CH)と、時刻の情報を含むタプルは、サーバ２０６ａによって受け取られる。

サーバ２０６ａは、ＬＡＮ、ＷＡＮ、ＦＨＨＴなどのどれかの接続構成であるネットワーク２０８に接続され、ネットワーク２０８にはさらに、サーバ２０６ｂ、２０６ｃ、・・・、２０６ｎ、サーバ２１０及びサーバ２１４が接続されている。これらのサーバとして、これには限定されないが、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、IBM(R) System X、System i、System pなどの機種のサーバを使うことができる。これらのサーバで使用可能なオペレーティング・システムとして、AIX（商標）、UNIX(商標)、Linux(商標)、Windows(商標)2008 Serverなどがあるが、この実施例では、Linux(商標)を導入するものとする。

サーバ２０６ａ、２０６ｂ、２０６ｃ、・・・、２０６ｎには、IBM(R) InfoSphere Streamsが導入され、これにより、サーバ２０６ａ、２０６ｂ、２０６ｃ、・・・、２０６ｎは、ストリーム・サーバを構成する。なお、ストリーム・サーバを構成するサーバの台数は一台でもよく、台数はストリーム・データの処理量に応じて決められる。

サーバ２１０は、データベース・サーバであり、データベース２１２が接続されている。データベース２１２は、サーバ２１０のローカル・ディスクに格納してもよいし、ＳＡＮ(Storage Area Network)、ＮＡＳ(Network Attached Storage)などで構成され、ネットワークを介してデータベース・サーバ２１０に接続されていてもよい。サーバ２１０には、ＤＢ２などの、データベース管理プログラムが導入されている。データベース２１２には、Program（番組）データベースが含まれている。Programデータベースは、チャンネル(CH)、開始時間(START)、終了時間(END)、タイトル(TITLE)などのフィールドを含む。

サーバ２１４は、アプリケーション・サーバであり、オペレーティング・システムとしてのLinux(商標)と、Java(R)上に、IBM(R) WebSphere(商標) Application Server(WAS)が導入されている。サーバ２１４には、クライアント・コンピュータ２１６が接続されており、管理者あるいはオペレータは、クライアント・コンピュータ２１６を操作して、WASの管理ツールなどを通じてストリーム・サーバであるサーバ２０６ａ、２０６ｂ、２０６ｃ、・・・、２０６ｎや、データベース・サーバであるサーバ２１０の構成を適宜変更したりする。

次に図３を参照して、当該実施例に係る処理の機能構成について説明する。図３において、Programテーブル３０２は、図２のデータベース２１２に含まれ、チャンネル(CH)、開始時間(START)、終了時間(END)、タイトル(TITLE)などのフィールドを含む。

バッファ・テーブル生成ルーチン３０４は、好適にはサーバ２１０のハードディスク（図示しない）に格納され、動作により、Programテーブル３０２から所定の条件でレコードを抽出し、バッファ・テーブル３０６を生成する機能をもつ。バッファ・テーブル３０６は、好適にはストリーム・サーバ２０６ａ、２０６ｂ、２０６ｃ、・・・、２０６ｎうちのどれかの主記憶（図示しない）に、現在時刻以降の一定期間（例えば30分)のデータをSTART順にソートし、ロードする。バッファ・テーブル生成ルーチン３０４は、Java(R)、C、C++、C#などの既存の適当なコンピュータ・プログラミング言語で作成することができる。バッファ・テーブル生成ルーチン３０４の処理については、図４のフローチャートを参照して後で説明する。

チャネル毎視聴数集計オペレータ３０８は、ストリーム・サーバにおいて動作するように、例えばIBM(R) InfoSphere Streamsで使用されるSPL(Streams Processing Language)で作成されたものであり、セットトップボックス２０４ａ、２０４ｂ・・・２０４ｚから受け取った、[UserID,CH(チャンネル),Time(現在時刻)]のタプルを一定時間ごとに集計して、[CH(チャンネル),Time(現在時刻),num(集計数)]を出力する。

データストリーム生成ルーチン３１０は、現在時刻がSTARTに達した時点で、[CH, START, END, TITLE,..]の時空間タプルを出力する。データストリーム生成ルーチン３１０は同様に、SPL(Streams Processing Language)などの適当なストリーム言語で作成することができる。そのコードの一例は、以下のようになる。
stream<Temporal_tuple> T_stream = GenTemporal() {
param
table : Program
timeS : Program.Start
timeE : Program.End
}
データストリーム生成ルーチン３１０の処理については、図６のフローチャートを参照して後で説明する。

Temporal Join(時間的Join)オペレータ３１２もまた、好適にはストリーム・サーバにおいて動作するように、IBM InfoSphere Streamsで使用されるSPL(Streams Processing Language)で書かれたものであり、チャネル毎視聴数集計オペレータ３０８からの出力ストリームと、データストリーム生成ルーチン３１０からの出力ストリームを受け取って、時間に関してJoinし、[CH, Time(現在時刻),num(集計数),Title(番組名),...]というストリームを出力する。
コードの例は、以下のようになる。
stream<Combined_tuple> Join =
TemporalJoin(Input_stream: T_stream) {
param
match: Input_stream.CH = T_stream.CH
}
Temporal Joinオペレータ３１２の処理については、図７及び図８のフローチャートを参照して後で説明する。

次に、図４のフローチャートを参照して、バッファ・テーブル生成ルーチン３０４の処理について、説明する。

図４において、バッファ・テーブル生成ルーチン３０４は、ステップ４０２で、Time0 = 現在時刻にセットし、ステップ４０４からステップ４１６までは、時間n毎に実行するループである。但し、nは以下で述べるxより小さい値である。

ステップ４０６では、Querytime = Time0 + xとセットする。これは、開始時間が時間x後のデータを取得するという意味である。

バッファ・テーブル生成ルーチン３０４は、ステップ４０８で、Time0 <= [START] and [START] < Querytimeという条件でデータベース、すなわちProgramテーブル３０２に問い合わせする。ここでSTARTは、Programテーブル３０２の開始時刻のフィールドを指す。

バッファ・テーブル生成ルーチン３０４は、ステップ４１０で、取得したデータをSTARTが早い順にソートし、ステップ４１２でソートしたデータをバッファ・テーブル３０６に格納する。そしてステップ４１４でTime0 = Querytimeとセットして、ステップ４０４に戻り、時間nを待って次のループに入る。

図５は、バッファ・テーブル生成ルーチン３０４によって、Programテーブル３０２からバッファ・テーブル３０６にデータが格納される様子が示されている。ここでは、開始時刻12:00以降のデータがバッファ・テーブル３０６に格納されることが見て取れる。

次に図６のフローチャートを参照して、データストリーム生成ルーチン３１０の処理について説明する。

図６のステップ６０２で、データストリーム生成ルーチン３１０は、バッファ・テーブル３０６の１レコード目にポインタをさす。

ステップ６０４からステップ６２０までは外側のループである。ステップ６０６で、データストリーム生成ルーチン３１０は、現在時刻をCurrenttimeにセットする。

ステップ６０８からステップ６１８までは内側のループである。ステップ６１０で、データストリーム生成ルーチン３１０は、ポインタのさすレコードの開始時間がCurrenttime以下かどうか判断し、そうでないなら、ステップ６０４に戻る。

ポインタのさすレコードの開始時間がCurrenttime以下なら、データストリーム生成ルーチン３１０は、ステップ６１２で、そのレコードを時空間タプルとしてストリームに出力し、ステップ６１４で、ポインタを次のレコードに移動し、ステップ６１６で、出力したそのレコードをバッファ・テーブル３０６からフラッシュして、内側のループの開始点であるステップ６０８に戻る。

次に、図７及び図８のフローチャートを参照して、Temporal Joinオペレータ３１２の処理について説明する。

図７のフローチャートは、Temporal Joinオペレータ３１２への、データストリーム生成ルーチン３１０からの入力の処理を示す。具体的には、図６のステップ６１２からの出力が、時空間タプルとして入力となり、ステップ７０２で結合オペレータ内に格納される。

図８のフローチャートは、Temporal Joinオペレータ３１２への、チャンネル毎視聴数集計オペレータ３０８からの入力の処理を示す。図８のステップ８０２で、Temporal Joinオペレータ３１２は、結合オペレータ内の、Match条件を満たす時空間タプルを取得する。ここで、Match条件とは、下記のコードの例で、match:以下に書かれる条件である。
stream<Combined_tuple> Join =
TemporalJoin(Input_stream: T_stream) {
param
match: Input_stream.CH = T_stream.CH
}

ステップ８０４で、Temporal Joinオペレータ３１２は、合致した時空間タプルの有効期間が現在有効であるかどうか判断し、もしそうなら、ステップ８０６で、データを結合する。

もし、合致した時空間タプルの有効期間が現在有効でないなら、Temporal Joinオペレータ３１２は、ステップ８０８で例外処理する。ここでの例外処理とは、結合処理を実施せず入力ストリームを破棄したり、あるいは、指定時間待ち、再び最初から図８のフローチャートの処理を繰り返し、ある回数繰り返して結合されなかった場合、エラーログを出力する、などである。

図９及び図１０は、本発明による効果をよりよく説明するための図である。すなわち、図９に模式的に示す従来技術において、入力ストリームに対して、Join処理を行うべきデータベースが３個ある場合、ストリーム９０２を入力した後、データベース９０４とJoin処理９０６を行い、その後、データベース９０８とJoin処理９１０を行い、その後、データベース９１２とJoin処理９１４を行うことでようやく出力が得られる。このような直列的なJoin処理は明らかに時間がかかる。

一方、図１０に模式的に示す本発明の処理において、入力ストリーム１００２とは別に、データベース１００４からバッファ・テーブルを生成してTemporal Stream生成処理１００６を行うことと、データベース１００８からバッファ・テーブルを生成してTemporal Stream生成処理１０１０を行うことと、データベース１０１２からバッファ・テーブルを生成してTemporal Stream生成処理１０１４を行うことが各々並列に実行でき、これらを一括でJoin処理１０１６を行うことで、高速に出力が得られる。

図１１は、この発明の別の実施例として、渋滞度合いによる料金変動制有料道路の課金処理システムに適用した例を示す。

図１１において、交通ストリーム１１０２は、有料道路を通過する車の情報をストリームとして流すものであり、車両ＩＤ(CarID)、道路ＩＤ(RoadID)、時刻(Timestamp)を含む。一方、道路料金データベース１１０４は、通過する区間の道路ＩＤ(RoadID)と、適用する時区間である開始時間(Start)及び終了時間(End)と、その区間の料金(Fee)を含む。

本発明によれば、道路料金データベース１１０４から、バッファ・テーブルを生成して時空間の料金ストリームが生成される。料金ストリームは、有効開始時間になったデータを含む。道路料金は、通過する区間のRoadIDとその区間の直前X分の渋滞度合いに応じて、シミュレーションなどでその後の料金を決定し、その料金を適用する時区間を決定する。

料金判定オペレータ１１０８は、交通ストリーム１１０２と、道路料金データベース１１０４からの料金ストリームを用いて、車が到着した時刻とその有料道路のＩＤに基づき、道路の料金を問い合わせる。課金オペレータ１１１０は、料金判定オペレータ１１０８で取得した道路料金で車毎に課金処理を行う。履歴は課金履歴データベース１１１２に随時格納される。

次に、図１２は、この発明のさらに別の実施例として、時間制約のある株の注文処理に適用した例を示す。

図１２において、株価ストリーム１２０２は、株ＩＤ(StockID)、株価(Price)、時刻(Timestamp)のタプルを含む。一方、買い注文データベース１２０４は、注文ＩＤ(OrderID)、株ＩＤ(StockID)、ユーザＩＤ(UserID)、株価(Price)、期間(Duration)のフィールドをもつ。

買い注文ストリーム１２０６は、バッファ・テーブルを使用して買い注文データベース１２０４のデータをストリーム化する。

注文判定オペレータ１２０８は、株価ストリーム１２０２と買い注文ストリーム１２０６を株価でシーケンスマッチングして(Stock.Price <= Order.Price)、マッチングしたOrderIDを出力する。

注文オペレータ１２１０は、注文判定オペレータ１２０８から出力されたOrderIDで注文し、その結果を注文済データベース１２１２に記録する。

以上、視聴数集計処理と、料金変動制有料道路の課金処理と、時間制約のある株の注文処理の実施例について説明したが、この発明はこれには限定されず、予めハードディスクなどに保存された時空間データベースと、ストリームデータのJoinを行う任意の例に適用可能である。

また、本発明は、実施例で使用されているJava(R)などに限定されず、任意のコンピュータ・システムあるいはプラットフォームで実装可能である。

２０６ａ、２０６ｂ、・・・、２０６ｎストリーム・サーバ
２１０データベース・サーバ
３０２ Programテーブル
３０４バッファ・テーブル作成ルーチン
３０６バッファ・テーブル
３１０データストリーム生成ルーチン
３１２

Claims

コンピュータの処理により、データベースに問い合わせを行うシステムであって、
記憶手段と、
前記記憶手段に保存された、時間フィールドを含むデータベースと、
現在時間から所定の期間の間のデータを、前記データベースから抽出して、前記時間フィールドでソートして主記憶にバッファする手段と、
時間情報を含むタプルの第１のストリームを受け付ける手段と、
前記時間フィールドに基づき現在時刻に対して有効である前記バッファしたデータを第２のストリームとして出力する手段と、
前記第１のストリームに対し、前記第２のストリームを用いてストリーム処理を行う手段を有する、
システム。
前記ストリーム処理は、前記２つのストリームに含まれるデータのうち、所定の一致条件を満たすデータ同士をジョインして出力する処理である、請求項１に記載のシステム。
前記主記憶にバッファする手段は、前記主記憶にバッファする処理を所定期間毎に実行する、請求項１に記載のシステム。
前記ストリーム処理は、時間情報が重複することを更なる条件として前記第１のストリームのタプルと前記第２のストリームのタプルをジョインしてストリームとして出力する、請求項１に記載のシステム。
コンピュータの処理により、データベースに問い合わせを行う方法であって、
現在時間から所定の期間の間のデータを、記憶手段に保存された、時間フィールドを含むデータベースから抽出して、前記時間フィールドでソートして主記憶にバッファするステップと、
時間情報を含むタプルの第１のストリームを受領するステップと、
前記時間フィールドに基づき現在時刻に対して有効である前記バッファしたデータを第２のストリームとして出力するステップと、
前記第１のストリームに対し、前記第２のストリームを用いてストリーム処理を行うステップを有する、
方法。
前記主記憶にバッファするステップは、所定期間毎に実行する、請求項５に記載の方法。
前記出力されたデータを前記バッファから削除するステップをさらに有する、請求項５に記載の方法。
コンピュータの処理により、データベースに問い合わせを行うプログラムであって、
前記コンピュータに、
現在時間から所定の期間の間のデータを、記憶手段に保存された、時間フィールドを含むデータベースから抽出して、前記時間フィールドでソートして主記憶にバッファするステップと、
時間情報を含むタプルの第１のストリームを受領するステップと、
前記時間フィールドに基づき現在時刻に対して有効である前記バッファしたデータを第２のストリームとして出力するステップと、
前記第１のストリームに対し、前記第２のストリームを用いてストリーム処理を行うステップを実行させる、
プログラム。
前記主記憶にバッファするステップは、所定期間毎に実行する、請求項８に記載のプログラム。
前記出力されたデータを前記バッファから削除するステップをさらに前記コンピュータに実行させる、請求項８に記載のプログラム。