JP2010217968A - ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム - Google Patents

ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム Download PDF

Info

Publication number
JP2010217968A
JP2010217968A JP2009060783A JP2009060783A JP2010217968A JP 2010217968 A JP2010217968 A JP 2010217968A JP 2009060783 A JP2009060783 A JP 2009060783A JP 2009060783 A JP2009060783 A JP 2009060783A JP 2010217968 A JP2010217968 A JP 2010217968A
Authority
JP
Japan
Prior art keywords
data
query
computer
stream
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009060783A
Other languages
English (en)
Other versions
JP4870183B2 (ja
Inventor
Noriaki Takahashi
則明 高橋
Satoshi Watanabe
聡 渡辺
Tomohiro Hanai
知広 花井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009060783A priority Critical patent/JP4870183B2/ja
Priority to US12/644,973 priority patent/US8369207B2/en
Publication of JP2010217968A publication Critical patent/JP2010217968A/ja
Application granted granted Critical
Publication of JP4870183B2 publication Critical patent/JP4870183B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】現用系の計算機に障害が発生した場合に待機系の計算機に処理を切り替える障害回復方法において、待機系の計算機及びネットワークの負荷を低減させる。
【解決手段】時刻情報が付与されたデータを時系列順に受信し、あらかじめ登録された複数のクエリによって処理する計算機システムで、受信したデータを処理する現用系の計算機と、障害発生時に現用系の計算機の替わりに受信したデータを処理する待機系の計算機とが含まれ、現用系の計算機は、あらかじめ定義された順序で各クエリによって受信したデータを処理し、各クエリによる受信したデータの処理結果を中間データとして、所定のタイミングで、クエリごとに待機系の計算機に送信し、待機系の計算機は、現用系の計算機に障害が発生した場合には、受信したデータ及び中間データを処理することによってデータを復元する。
【選択図】図１

Description

本発明は、ストリームデータ処理システムにおいて障害を回復する技術に関する。
従来、企業情報システムのデータ管理の中心にはデータベース管理システム（以下、「ＤＢＭＳ」とする）が位置づけられていた。ＤＢＭＳは、処理対象のデータを記憶装置に格納し、格納されたデータに対してトランザクション処理に代表される高信頼な処理を実現していた。
これに対し、近年、時々刻々と到着する大量のデータをリアルタイム処理するデータ処理システムに対する要求が高まっている。例えば、株取引を支援する金融アプリケーションの場合、株価の変動にいかに迅速に対応するかがシステムの最重要の課題の一つとなる。従来のＤＢＭＳのように、株式のデータを記憶装置に一旦格納し、当該格納データを検索するようなシステムでは株価変動のスピードに対応できないおそれがある。
そこで、以上のようなリアルタイムデータ処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えば、非特許文献１には、ストリームデータ処理システムＳＴＲＥＡＭが開示されている。
ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、あらかじめクエリ（問合せ）がシステムに登録され、データの到来と共に登録されたクエリが継続的に実行される。ここでのストリームデータとは、映像ストリームのような論理的に継続する一つの大きなデータではなく、金融アプリケーションにおける株価配信データ、小売業でのＰＯＳデータ、交通情報システムにおけるプローブカーデータ、計算機システム管理におけるエラーログ、センサ又はＲＦＩＤなどのユビキタスデバイスから発生するセンシングデータなど、比較的小さな論理的に独立した大量の時系列データである。ストリームデータをリアルタイムに処理することをストリーム処理という。
ストリームデータは、システムに到着し続けるため、到着の終わりを待ってから処理を開始するのでは実時間での処理は不可能である。また、システムに到着したデータは、データ処理の負荷に影響されることなく、到着順に従って処理されなければならない。
ＳＴＲＥＡＭでは、システムに到着するストリームデータを、最新１０分間などの時間の幅、又は最新１０００件などの個数の幅を指定することによってストリームデータの一部を切り取ってリアルタイムの処理を実現するためのスライディングウィンドウ（以下単に「ウィンドウ」と呼ぶ）と呼ばれる概念を導入している。
このようなウィンドウ指定を含むクエリの記述言語の好適な例としては、ＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）が非特許文献１に開示されている。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を、ウィンドウ指定が可能となるように拡張したものである。
図２２は、ＣＱＬの一例を示す図である。図２２に示したクエリ２２０１は非特許文献１に示されているクエリの一例である。
クエリ２２０１は、あるＷｅｂプロキシサーバにおいて、ドメインｓｔａｎｆｏｒｄ．ｅｄｕからの現時点から過去１日分のアクセスの総数を計算するクエリである。「Ｒｅｑｕｅｓｔｓ」は、Ｗｅｂプロキシサーバに到来し続けるＷｅｂアクセスデータであり、ＤＢＭＳで取り扱われるテーブル（表）のような静止化されたデータではなく、切れ目のないストリームデータとなる。そのため、ウィンドウ指定“［Ｒａｎｇｅ １ Ｄａｙ Ｐｒｅｃｅｄｉｎｇ］”のように、ストリームデータのどの部分を対象とするかを指定しなければアクセスの総数を計算することはできない。
ウィンドウによって切り取られたストリームデータは、メモリに保持され、クエリ処理に使用される。代表的なウィンドウの指定方法には、ウィンドウの幅を時間で指定するＲａｎｇｅウィンドウ（以下、「時間ウィンドウ」）と、ウィンドウの幅をデータ数で指定するＲｏｗウィンドウ（以下、「行ウィンドウ」）とがある。例えば、時間ウィンドウを１０分とすると、最新の１０分間分がクエリ処理の対象となり、行ウィンドウを１０件とすると、最新の１０件がクエリ処理の対象となる。
また、ストリームデータ処理システムの復旧方法として、非特許文献２には、平常時から現用系と待機系を稼動させるＡｃｔｉｖｅＳｔａｎｄｂｙ方式、現用系から待機系に定期的にメモリコピーするＰａｓｓｉｖｅＳｔａｎｄｂｙ方式が開示されている。
ＡｃｔｉｖｅＳｔａｎｄｂｙ方式は、データ送信アプリケーションから現用系及び待機系両システムに対しデータを送信し、現用系及び待機系が共にストリームデータ処理を行う方式である。そして、結果受信アプリケーションでは、両システムから出力された出力ストリームデータの整合性をチェックし、一方の出力ストリームデータのみを扱う。現用系で障害が発生しても待機系が常時稼動しているため、待機系に切り替えてストリーム処理システムを継続することができる。
ＰａｓｓｉｖｅＳｔａｎｄｂｙ方式は、現用系では入力ストリームをストリーム処理し、待機系ではストリーム処理を行わずに入力ストリームデータをバッファリングし、現用系における処理結果を定期的に待機系にコピーする方式である。現用系で障害が発生した場合は待機系にコピーしてあるメモリの状態から入力ストリームデータを処理することによって、ストリーム処理システムを継続することができる。
R. Motwani,J. Widom,A. Arasu,B. Babcock,S. Babu,M. Datar,G. Manku,C. Olston,J. Rosenstein and R. Varma著:"Query Processing, Resource Management, and Approximation in a Data Stream Management System",In Proc. of the 2003 Conf. on Innovative Data Systems Research (CIDR),January 2003 Hwang, J.-H. Balazinska, M. Rasin, A. Cetintemel, U. Stonebraker, M. Zdonik, S. 著:"High-Availability Algorithms for Distributed Stream Processing"Proceedings of the 21st International Conference on Data Engineering, (ICDE2005) April 2005
信頼性の高いストリームデータ処理システムを提供するためには、バックアップシステムを用意する必要がある。また、ストリームデータ処理システムでは、時々刻々と到着する大量のストリームデータをリアルタイムに処理する必要があるため、迅速に障害から復旧しなければならない。
しかし、非特許文献２に開示された技術において、ＡｃｔｉｖｅＳｔａｎｄｂｙ方式では、現用系が正常に稼働している平常時であっても待機系が現用系と同様に稼働し、多くのリソースを消費してしまうという問題がある。
また、ＰａｓｓｉｖｅＳｔａｎｄｂｙ方式では、常にストリームデータ処理システム内のすべてのメモリの内容を待機系にコピーする必要があるため、膨大なメモリ量を転送することによってネットワークに大きな負荷を与えてしまう。さらに、待機系では膨大な情報を受信することによって大きなオーバヘッドが生じてしまう。
本発明の目的は、待機系システム及びネットワークの負荷を増大させずに、現用系システムに障害が発生した場合に迅速にストリームデータ処理システムを復旧させる技術を提供することにある。
本発明の一形態によれば、時刻情報が付与されたデータを時系列順に受信し、前記受信したデータをあらかじめ登録された複数のクエリによって処理する計算機システムにおける障害回復方法であって、前記計算機システムには、複数の計算機が含まれ、前記各計算機は、前記データを受信するインタフェースと、前記インタフェースを介して受信したデータを記憶する記憶部と、前記記憶部に記憶されたデータを処理するプロセッサと、を備え、前記複数の計算機には、前記受信したデータを前記複数のクエリによって処理した結果を出力する第１の計算機（現用系）と、前記第１の計算機に障害が発生した場合に前記第１の計算機に替わって前記受信したデータを処理する第２の計算機（待機系）とが含まれ、前記複数のクエリには、前記受信したデータを処理する順序があらかじめ定義され、前記方法は、前記第１の計算機及び前記第２の計算機が、前記データをそれぞれ受信し、前記第１の計算機が、前記あらかじめ定義された順序に従って、順次、前記クエリによって前記受信したデータを処理し、前記第１の計算機が、前記受信したデータの前記クエリごとの処理結果を、中間データとして前記第１の計算機の記憶部に記憶し、前記第１の計算機が、所定のタイミングで、前記複数のクエリの一部のクエリに対応する中間データを前記第２の計算機に送信し、前記第２の計算機が、前記第１の計算機から送信された中間データを前記第２の計算機の記憶部に記憶し、前記第１の計算機に障害が発生した場合には、前記第２の計算機が、前記第２の計算機が受信したデータ及び前記第１の計算機から送信された中間データを処理することによって、前記第１の計算機の記憶部に格納されたデータを前記第２の計算機の記憶部に復元する。
本発明の代表的な一形態によれば、ネットワークの負荷及び待機系（第２の計算機）のリソース消費を抑制しながら、迅速にシステムの障害から復旧させることができる。
本発明の実施の形態の計算機システムの構成及び各構成の関係を示す図である。 本発明の実施の形態のシステムへのログイン情報を入力データとして正常又は異常ログインを判別するストリーム処理部の一例を示す図である。 本発明の実施の形態のストリーム処理部で実行されるクエリの定義例を示す図である。 本発明の実施の形態のストリーム処理部におけるクエリグループ定義の一例を示す図である。 本発明の実施の形態のストリーム処理部において、クエリグループ定義を適用した場合にメモリコピーの対象となるクエリのグループを示す図である。 本発明の実施の形態の現用系のストリーム処理部から待機系のストリーム処理部にクエリグループのメモリコピーを行う手順を説明する図である。 本発明の実施の形態の現用系のストリーム処理部から待機系のストリーム処理部にクエリグループのメモリコピーを行う手順を説明する図である。 本発明の実施の形態の現用系のストリーム処理部から待機系のストリーム処理部にクエリグループのメモリコピーを行う手順を説明する図である。 本発明の実施の形態のコピー容量管理テーブルの一例を示す図である。 本発明の実施の形態のタプル管理テーブルの一例を示す図である。 本発明の実施の形態の現用系の計算機に障害が発生し、待機系の計算機に処理を切り替える手順を説明する図である。 本発明の実施の形態のデータ受信部による処理の手順を示すフローチャートである。 本発明の実施の形態のデータ送信部による処理の手順を示すフローチャートである。 本発明の実施の形態の主制御部による処理の手順を示すフローチャートである。 本発明の実施の形態の入力データ制御部による処理の手順を示すフローチャートである。 本発明の実施の形態のメモリコピー制御部による処理の手順を示すフローチャートである。 本発明の実施の形態の入力ストリーム保存管理部による処理の手順を示すフローチャートである。 本発明の実施の形態のクエリ処理部による処理の手順を示すフローチャートである。 本発明の実施の形態の定義ファイル解析制御部による処理の手順を示すフローチャートである。 本発明の実施の形態のメモリ送受信制御部による処理の手順を示すフローチャートである。 本発明の実施の形態のハートビート送受信部による処理の手順を示すフローチャートである。 本発明の実施の形態のクエリ処理言語ＣＱＬによるクエリ記述例である。
以下、本発明を実施するための形態について図面を参照して詳細に説明する。
図１は、本発明の実施の形態の計算機システムの構成及び各構成の関係を示す図である。
本発明の実施の形態の計算機システムは、現用系の計算機１１０及び待機系の計算機１４０を含む。現用系の計算機１１０及び待機系の計算機１４０は、ネットワーク１００を介して互いに接続される。待機系の計算機１４０は、現用系の計算機１１０に障害が発生した場合などに、現用系の計算機１１０に替わってストリームデータを処理する。
また、現用系の計算機１１０及び待機系の計算機１４０には、データ送信クライアント１９０及びデータ受信クライアント１９１が接続される。データ送信クライアント１９０は、未処理のストリームデータを計算機１１０及び計算機１４０に送信する。データ受信クライアント１９１は、計算機１１０又は計算機１４０によって処理されたストリームデータの処理結果を受信する。
計算機１１０は、プロセッサ１１１、メモリ１１２、通信インタフェース１１３、ディスクインタフェース（Ｉ／Ｆ）１１４及びハードディスク装置１１５を備える。
プロセッサ１１１は、メモリ１１２に記憶されたプログラムを処理することによって、各種業務処理を実行する。例えば、所定のプログラムを実行することによって、あらかじめ定義されているクエリを、受信したストリームデータに適用することによって処理結果を取得する。
メモリ１１２は、プロセッサ１１１によって実行されるプログラム及び当該プログラムを実行する際に使用されるデータを記憶する。メモリ１１２に記憶されたプログラム及びデータについては後述する。
通信インタフェース１１３は、ネットワーク１００に接続するためのインタフェースである。ディスクインタフェース１１４は、プロセッサ１１１などとハードディスク装置１１５を接続するためのインタフェースである。
ハードディスク装置１１５は、クエリが定義されたファイルなどを格納する。具体的には、定義されたクエリが記録されているクエリ定義ファイル１１６、及び定義されたクエリを管理するグループの定義情報が記録されたクエリグループ定義ファイル１１７が格納される。クエリ定義ファイル１１６の詳細については、図３にて後述する。クエリグループ定義ファイル１１７の詳細については、図４にて後述する。
メモリ１１２には、ストリーム処理部１２０が記憶される。ストリーム処理部１２０は、プログラム及びデータによって構成される。プロセッサ１１１がストリーム処理部１２０に含まれるプログラムを実行することによって、データ送信クライアント１９０から送信されたストリームデータを処理し、処理結果をデータ受信クライアント１９１に送信する。また、ストリーム処理部１２０には、複数のプログラムが含まれる。
また、計算機１４０は、計算機１１０と同様に、プロセッサ１４１、メモリ１４２、通信インタフェース１４３、ディスクインタフェース１４４及びハードディスク装置１４５を備える。各構成の機能については、計算機１１０と同様である。
メモリ１４２には、計算機１１０と同様に、ストリーム処理部１５０が記憶される。プロセッサ１４１がストリーム処理部１５０を実行することによって、各種処理が実行される。計算機１４０は待機系であるため、現用系の計算機１１０で実行される処理と相違する。しかし、待機系の計算機１４０は、前述のように、現用系の計算機１１０に障害が発生した場合には、現用系に替わってストリームデータを処理するため、ストリーム処理部１２０とストリーム処理部１５０とは同じ構成を含み、同じ処理を実行することが可能である。
ストリーム処理部１２０は、データ受信部１２１、データ送信部１２２、主制御部１２３、タプル管理テーブル１２５、入力データ制御部１２４、クエリ処理部１２６、入力ストリーム保存管理部１２７、コピー容量管理テーブル１２８、定義ファイル解析制御部１２９、メモリコピー制御部１３０、メモリ送受信制御部１３１、及びハートビート送受信部１３２を有する。
データ受信部１２１、データ送信部１２２、主制御部１２３、入力データ制御部１２４、クエリ処理部１２６、入力ストリーム保存管理部１２７、定義ファイル解析制御部１２９、メモリコピー制御部１３０、メモリ送受信制御部１３１、及びハートビート送受信部１３２は、プロセッサ１１１によって実行されるプログラムである。
本発明の実施の形態では、入力データ制御部１２４、タプル管理テーブル１２５及びクエリ処理部１２６に関しては、定義されたクエリごとに生成される。また、ストリーム処理部１５０についても対応する構成が含まれている。
データ受信部１２１及びデータ受信部１５１は、ネットワーク１００を介して外部からストリームデータを受信する。データ送信部１２２及びデータ送信部１５２は、処理されたストリームデータを、ネットワークを介して外部に送信する。
主制御部１２３及び主制御部１５３は、ストリームデータ処理全体を制御する。タプル管理テーブル１２５及びタプル管理テーブル１５５は、クエリ単位に入力タプルを格納する。入力データ制御部１２４及び入力データ制御部１５４は、タプル管理テーブル１２５及びタプル管理テーブル１５５に格納された入力タプルを管理する。クエリ処理部１２６及びクエリ処理部１５６は、定義されたクエリ処理を行う。
入力ストリーム保存管理部１２７及び入力ストリーム保存管理部１５７は、現用系に障害が発生した場合に、待機系で処理を継続するために、入力されたストリームデータを保存する。
コピー容量管理テーブル１２８は、待機系にメモリ１１２に記憶されている情報をコピーするためのメモリコピー情報を記録する。定義ファイル解析制御部１２９は、クエリ定義ファイル１１６及びクエリグループ定義ファイル１１７を読み出し、メモリコピー情報をコピー容量管理テーブル１２８に設定する。
同様に、コピー容量管理テーブル１５８は、待機系の計算機１４０が現用系として動作する場合に、待機系にメモリ１４２に記憶されている情報をコピーするためのメモリコピー情報を記録する。同様に、定義ファイル解析制御部１５９は、クエリ定義ファイル１４６及びクエリグループ定義ファイル１４７を読み出し、メモリコピー情報をコピー容量管理テーブル１５８に設定する。
メモリコピー制御部１３０は、コピー容量管理テーブル１２８に基づいて、コピーする情報量を管理し、さらに、受信した情報をクエリごとにコピーする。同様に、メモリコピー制御部１６０は、コピー容量管理テーブル１５８に基づいて、コピーする情報量を管理し、さらに、受信した情報をクエリごとにコピーする。
メモリ送受信制御部１３１及びメモリ送受信制御部１６１は、現用系と待機系との間でメモリに記憶された情報の送受信を制御する。ハートビート送受信部１３２及びハートビート送受信部１６２は、現用系と待機系との間で稼動状況通知を送受信する。
ここで、受信したストリームデータを処理し、外部に送信する場合において、各構成によって処理する手順の概要を説明する。
データ受信部１２１は、データ送信クライアント１９０から送信されたストリームデータを、通信インタフェース１１３を介して受信する。同じく、データ受信部１５１は、データ送信クライアント１９０から送信されたストリームデータを、通信インタフェース１１３を介して受信する。
データ受信部１２１及びデータ受信部１５１は、ストリームデータを受信すると、クエリ処理を実行するために主制御部１２３及び主制御部１５３を起動し、受信したストリームデータを送信する。
主制御部１２３は、自ストリーム処理部が現用系のストリーム処理部であるため、入力データ制御部１２４を起動する。入力データ制御部１２４は、クエリ処理を実行するためにクエリ処理部１２６を起動する。また、入力データ制御部１２４は、タプル管理テーブル１２５に受信したストリームデータに基づいて、入力データ情報を格納する。
主制御部１２３は、受信したストリームデータがクエリ処理部１２６によって処理された結果である出力タプルをデータ受信クライアント１９１に送信するために、データ送信部１２２を起動する。そして、出力タプルをデータ送信部１２２に送信する。
データ送信部１２２は、出力タプルを受信すると、通信インタフェース１１３を介してデータ受信クライアント１９１に送信する。データ送信クライアント１９０からストリームデータを受信するごとに以上の処理手順を繰り返し、受信したストリームデータを処理して外部に送信する。
一方、主制御部１５３は、自ストリーム処理部が待機系のストリーム処理部であるため、入力ストリーム保存管理部１５７を起動し、受信データを送信する。
入力ストリーム保存管理部１５７は、入力されたストリームデータの削除要求がメモリコピー制御部１６０から通知されるまで、入力されたストリームデータを保存及び管理する。
定義ファイル解析制御部１２９は、ハードディスク装置１１５に格納されているクエリ定義ファイル１１６及びクエリグループ定義ファイル１１７を、ディスクインタフェース１１４を介して読み出す。そして、クエリ実行シーケンス、メモリコピータイミング、メモリコピー容量、及びコピーサイクルなどの定義情報をコピー容量管理テーブル１２８に格納する。
クエリ定義ファイル１１６には、クエリの具体的な内容の他に、クエリの連結順番（クエリ実行順序）が定義されている。詳細については、図３にて後述する。
クエリグループ定義ファイル１１７には、時間間隔でメモリコピーを行う場合のメモリコピー間隔時間、メモリコピー対象となる先頭クエリ名称、ストリームデータの入力量でメモリコピーを行う先頭クエリ名称及び入力件数が定義されている。
また、連結されているクエリの中で、指定したクエリを先頭として、以降の連結されているクエリがメモリコピー対象のクエリグループとなる。クエリグループは、定義ファイル解析制御部１２９によって自動的に作成される。クエリグループの詳細については、図４にて後述する。
メモリコピー制御部１３０は、メモリ送受信制御部１３１によって、コピー容量管理テーブル１２８に設定されたメモリコピー間隔時間で、通信インタフェース１１３を介して待機系の計算機１４０のメモリ送受信制御部１６１に所定の情報を送信する。
なお、メモリコピー間隔時間は、定義ファイル解析制御部１２９によってコピー容量管理テーブル１２８に設定される。また、所定の情報には、クエリグループに含まれるストリームデータ、データ送信部１２２に保持されているデータ受信クライアント１９１に対する未送信ストリームデータ、及びタプル管理テーブル１２５に記録された各クエリに入力済の最新タプル情報が含まれる。
メモリ送受信制御部１６１は、受信したデータをそれぞれメモリ１４２の対応する構成に格納する。例えば、クエリ処理中のストリームデータは対応するクエリのクエリ処理部１５６に格納される。また、各クエリの入力済最新タプル情報は各クエリに対応するタプル管理テーブル１５５に格納される。さらに、未送信のストリームデータはデータ送信部１５２に格納される。
また、各クエリに対応する入力データ制御部１２４は、クエリグループ定義ファイル１１７によってストリームデータの入力量が定義されている場合には、入力されたストリームデータの量が定義されたデータ量に達すると、メモリコピー制御部１３０を起動する。メモリコピー制御部１３０は、さらにメモリ送受信制御部１３１によって、通信インタフェース１１３を介して待機系のメモリ送受信制御部１６１に所定のデータを送信する。所定のデータには、前述したように、対象クエリグループのクエリに含まれるストリームデータ、タプル管理テーブル１２５に含まれる各クエリに入力済の最新タプル情報、及びデータ送信部１２２に保持された未送信ストリームデータが含まれる。
ハートビート送受信部１３２は、現用系が稼動中であることを待機系に通知するために、通信インタフェース１１３を介して所定の間隔でハートビートを待機系のハートビート送受信部１６２に送信する。所定の間隔は、例えば、１秒間隔である。
図２は、本発明の実施の形態のシステムへのログイン情報を入力して正常又は異常ログインを判別するストリーム処理部１２０の一例を示す図である。
ストリーム処理部１２０は、データ送信クライアント１９０から各ホストのログインデータを入力し、正常又は異常なログイン情報を検出し、検出結果をデータ受信クライアント１９１に送信する。ストリーム処理部１２０は、いわゆる「なりすまし」を検知するための処理を実行する。
まず、ストリーム処理部１２０に含まれる各クエリの関係について説明する。
ストリーム処理部１２０には、クエリ２１１からクエリ２１６までの６つのクエリが連結されている。クエリ２１１は、データ送信クライアント１９０から送信されたデータを入力データとする。クエリ２１２は、クエリ２１１の出力データを入力データとする。クエリ２１２の出力データは、クエリ２１３及びクエリ２１５の入力データとなる。クエリ２１３の出力データはクエリ２１４の入力データとなり、クエリ２１５の出力データはクエリ２１６の入力データとなる。最後に、クエリ２１４及びクエリ２１６の出力データがストリーム処理部１２０の処理結果としてデータ受信クライアント１９１に送信される。
続いて、ストリーム処理部１２０に含まれる各クエリによる処理の内容について説明する。
クエリ２１１は、同一ホストからの多重ログインを１分間検出しないようにフィルタリングする。具体的には、クエリ２１１は、１分間のＲａｎｇｅＷｉｎｄｏｗを有し、１分間に、同一のホストに同じユーザがログインした情報を除いたデータを出力する。
クエリ２１２は、ユーザ毎に１分間のログイン数を集計する。具体的には、クエリ２１２は、１分間のＲａｎｇｅＷｉｎｄｏｗを有し、クエリ２１１から出力されたログインデータを入力データとし、ユーザ毎にログインした数の集計データのデータを出力する。
クエリ２１３は、１分間に別ホストからのログイン数が２件以上あるユーザを検出する。具体的には、クエリ２１３は、クエリ２１２から出力されたユーザ毎の集計データを入力データとし、ログイン回数が２回以上のユーザをフィルタリングし、異常なユーザとして集計データを出力する。すなわち、別のホストから同じユーザがログインされたことを検出する。
クエリ２１４は、クエリ２１３で検出されたユーザに対し、ホスト情報及びログイン時間を付与し、データ受信クライアント１９１に出力ストリームを送信する。すなわち、クエリ２１４は、異常なユーザとして検出されたデータにホスト情報及びログイン時間などの情報を付与し、データ受信クライアント１９１に送信する。
クエリ２１５は、１分間に別ホストからのログイン件数が２件未満のユーザを検出する。すなわち、クエリ２１５は、クエリ２１２から出力したユーザ毎の集計データを入力し、ログイン回数が２回未満のユーザをフィルタリングし、正常なユーザを検出する。
クエリ２１６は、クエリ２１５で検出されたユーザに対してホスト情報及びログイン時間を付与し、データ受信クライアント１９１に出力ストリームを送信する。すなわち、クエリ２１４は、正常なユーザとして検出されたデータにホスト情報及びログイン時間などの情報を付与し、データ受信クライアント１９１に送信する。
図３は、本発明の実施の形態のストリーム処理部１２０で実行されるクエリの定義例を示す図である。
図３に示すクエリ定義３００は、クエリ定義ファイル１１６に記録されている情報の一例である。以下、具体的な内容について説明する。
「ｒｅｇｉｓｔｅｒ ｓｔｒｅａｍ」はストリームの登録を指示する定義項目である。また、「ｒｅｇｉｓｔｅｒ ｑｕｅｒｙ」はクエリの登録を指示する定義項目である。「ｒｅｇｉｓｔｅｒ ｓｔｒｅａｍ」に続くオペランドがストリーム名称であり、「ｒｅｇｉｓｔｅｒ ｑｕｅｒｙ」に続くオペランドがクエリ名称を示している。
さらに、「ＦＲＯＭ」に続くオペランドは、どのクエリの後続クエリであるかを指示している。「ＦＲＯＭ」に続くオペランドがストリーム名称である場合には先頭のクエリとなる。「ＦＲＯＭ」に続くオペランドがクエリ名称である場合には当該クエリに続く後続のクエリとなることを指示している。
したがって、クエリ定義３００のストリーム名称は「ＡｃｃｅｓｓＬｏｇ＿Ｓｑｕｉｄ」となり、先頭のクエリ名称が「ＬｏｇｉｎＣｏｕｎｔ１」となる。さらに、「ＬｏｇｉｎＣｏｕｎｔ１」に続くクエリは、順に、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ２」、クエリ名称「ＦｉｌｔｅｒＲｕｌｅ１」及びクエリ名称「ＬｏｇｉｎＲｕｌｅ１」となることを示している。
また、クエリ定義３００は、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ２」の後に、さらに、クエリ名称「ＦｉｌｔｅｒＲｕｌｅ２」及びクエリ名称「ＬｏｇｉｎＲｕｌｅ２」のクエリが続くことを示している。
図４は、本発明の実施の形態のストリーム処理部１２０におけるクエリグループ定義４００の一例を示す図である。
クエリグループ定義４００に記述された「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」は、ストリームデータの入力量（件数）に基づいてメモリコピーを行なうことを指示する定義項目である。
具体的に説明すると、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ１、１００」は、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ１」に１００件のデータが入力された場合にメモリコピーを行うことを指示する。この定義項目によってメモリコピーの対象となるクエリは、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ１」以降に実行される後続のクエリである。
また、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ２、５０」は、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ２」に５０件のデータが入力された場合にメモリコピーを行うことを指示するものである。この定義項目によるメモリコピーの対象となるクエリは、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ２」以降に実行される後続のクエリである。
「ｑｕｅｒｙ＿ｇｒｏｕｐ」は、時間間隔でメモリコピーを行うことを指示する定義項目である。具体的に説明すると、「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ１」は、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ１」以降に実行される後続のクエリを対象としたメモリコピーを行うことを指示するものである。「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ２」は、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ２」以降に実行される後続のクエリを対象としたメモリコピーを行うことを指示するものである。「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＦｉｌｔｅｒＲｕｌｅ２」は、クエリ名称「ＦｉｌｔｅｒＲｕｌｅ２」以降に実行される後続のクエリを対象としたメモリコピーを行うことを指示するものである。
「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」は、メモリコピーを行う間隔時間を指示する定義項目である。「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ＝１０」は、１０秒間隔にメモリコピーを行うことを指示するものである。
図５は、本発明の実施の形態のストリーム処理部１２０において、クエリグループ定義４００を適用した場合にメモリコピーの対象となるクエリのグループを示す図である。
「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ１，１００」によってメモリコピーの対象となるクエリグループは、クエリ２１１以降のクエリ２１１、クエリ２１２、クエリ２１３、クエリ２１４、クエリ２１５及びクエリ２１６を含むクエリグループ５１１となる。同じく「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ２，５０」によってメモリコピーの対象となるクエリグループは、クエリ２１２以降のクエリ２１２、クエリ２１３、クエリ２１４、クエリ２１５及びクエリ２１６を含むクエリグループ５１２となる。
「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ１」によってメモリコピーの対象となるクエリグループは、クエリ名称「ＬｏｇｉｎＣｏｕｎｔ１」がストリーム内での先頭クエリであるため、クエリ２１１以降のすべてのクエリを含むクエリグループ５１１となる。
「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ２」によってメモリコピーの対象となるクエリグループは、クエリ２１２以降のクエリ２１２、クエリ２１３、クエリ２１４、クエリ２１５及びクエリ２１６を対象としたクエリグループ５１２となる。
「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＦｉｌｔｅｒＲｕｌｅ２」によってメモリコピーの対象となるクエリグループは、クエリ２１５以降のクエリ２１５及びクエリ２１６を含むクエリグループ５１３となる。
クエリグループ定義４００を適用した場合、ストリーム処理部１２０では、各クエリグループの先頭クエリ名に基づいてクエリグループのコピーサイクルを自動的に決定する。クエリグループ５１１の先頭クエリは「ＬｏｇｉｎＣｏｕｎｔ１」、クエリグループ５１２の先頭クエリは「ＬｏｇｉｎＣｏｕｎｔ２」、クエリグループ５１３の先頭クエリは「ＦｉｌｔｅｒＲｕｌｅ２」であるため、クエリの実行順序からコピーサイクルは、クエリグループ５１１、クエリグループ５１２、クエリグループ５１３の順となる。
クエリグループ定義４００には、「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ＝１０」と記述されているため、クエリグループ５１１、クエリグループ５１２、クエリグループ５１３の順に、１０秒間隔でメモリコピーが実行される。メモリコピーは、ストリーム処理システムが終了するまで順次繰り返される。
また、時間間隔のメモリコピーとは非同期に入力データ件数に達したクエリグループ５１１及び５１２のメモリコピーが行われる。
なお、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」の定義は必須ではなく、入力データ件数によるメモリコピーを必要としない場合は定義を省略することが可能である。この場合には、入力データ件数によるメモリコピーは行わない。
また、「ｑｕｅｒｙ＿ｇｒｏｕｐ」の定義も必須ではなく、省略した場合には、定義ファイル解析制御部１２９が自動的にクエリグループを決定する。ストリーム処理部１２０の場合には、クエリグループ５１１、５１２、５１３、５１４、５１５及び５１６が自動的に作成される。ただし、「ｑｕｅｒｙ＿ｇｒｏｕｐ」を定義する場合には、必ずストリーム内の先頭のクエリを定義しなければならない。
「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」は、値の設定が省略された場合に指定される値をあらかじめ設定しておけば省略することが可能である。
図６、図７及び図８は、現用系のストリーム処理部１２０から待機系のストリーム処理部１５０にメモリコピーを行う処理を説明する図である。
図４に示したクエリグループ定義４００に記述された「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」及び「ｑｕｅｒｙ＿ｇｒｏｕｐ」によって、図５に示したクエリグループ５１１、５１２及び５１３が作成される。
現用系のストリーム処理部１２０は、「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」によって定義された１０秒間隔でクエリグループ５１１、５１２及び５１３のクエリグループ単位でメモリコピーを行う。なお、コピーするクエリグループの順序を決定する方法については図９にて後述する。
図６は、本発明の実施の形態の現用系のストリーム処理部１２０から待機系のストリーム処理部１５０に、クエリグループ５１１のメモリコピーを行う手順を説明する図である。
ストリーム処理システムが開始されると、ストリーム処理部１２０は、最初にコピーするクエリグループ５１１に含まれるクエリに関連するデータをメモリ１１２から取得し、待機系のストリーム処理部１５０にコピーする。具体的にコピーされるデータは、クエリグループ５１１に含まれる各クエリに対応するタプル管理テーブル１２５に記録された入力データ管理情報、クエリ内のストリームデータ、送信待ちストリームデータ６１２及び６１３である。
待機系のストリーム処理部１５０は、現用系のストリーム処理部１２０から受信したデータに基づいて、タプル管理テーブル１５５に記録された入力データ管理情報を更新し、クエリ内のストリームデータを更新する。さらに、送信待ちストリームデータ６１２及び６１３を待機系のストリーム処理部１５０の送信待ちストリームデータ６２２及び６２３としてコピーする。
また、メモリコピーの対象がクエリグループ５１１である場合には、ストリーム処理部１５０内のメモリ状態がストリーム処理部１２０と同一のものとなるため、クエリ内データを回復する必要がなくなる。このため、待機系の入力ストリームデータ６２４をすべて削除する。こうすることによって、待機系のメモリ１４２の使用量を削減することができる。
図７は、本発明の実施の形態の現用系のストリーム処理部１２０から待機系のストリーム処理部１５０に、クエリグループ５１２のメモリコピーを行う手順を説明する図である。
ストリーム処理部１２０は、クエリグループ５１１の次にクエリグループ５１２をメモリコピーの対象とする。ストリーム処理部１２０は、クエリグループ５１２に含まれるクエリに関連するデータをメモリ１１２から取得し、待機系のストリーム処理部１５０にコピーする。具体的には、クエリグループ５１２に含まれる各クエリに対応するタプル管理テーブル１２５に記録された入力データ管理情報、クエリ内のストリームデータ、送信待ちストリームデータ７１２及び７１３である。
待機系のストリーム処理部１５０は、現用系のストリーム処理部１２０から受信したデータに基づいて、タプル管理テーブル１５５に記録された入力データ管理情報を更新し、クエリ内のストリームデータを更新する。さらに、送信待ちストリームデータ７１２及び７１３を待機系のストリーム処理部１５０の送信待ちストリームデータ７２２及び７２３としてコピーする。
また、メモリコピーの対象がクエリグループ５１２である場合には、ストリーム処理部１５０内のメモリ状態がストリーム処理部１２０内のメモリ状態とすべて同一にはならないため、クエリを実行することによってクエリ内のデータを回復する必要がある。このため、待機系の入力ストリームデータ７２４を削除せずにそのまま保持する。
図８は、本発明の実施の形態の現用系のストリーム処理部１２０から待機系のストリーム処理部１５０に、クエリグループ５１３のメモリコピーを行う手順を説明する図である。
ストリーム処理部１２０は、クエリグループ５１２の次にクエリグループ５１３をメモリコピーの対象とする。ストリーム処理部１２０は、クエリグループ５１３に含まれるクエリに関連するデータをメモリ１１２から取得し、待機系のストリーム処理部１５０にコピーする。具体的には、クエリグループ５１３に含まれる各クエリに対応するタプル管理テーブル１２５に記録された入力データ管理情報、クエリ内のストリームデータ、送信待ちストリームデータ８１２及び８１３である。
待機系のストリーム処理部１５０は、現用系のストリーム処理部１２０から受信したデータに基づいて、タプル管理テーブル１５５に記録された入力データ管理情報を更新し、クエリ内のストリームデータを更新する。さらに、送信待ちストリームデータ８１２及び８１３を待機系のストリーム処理部１５０の送信待ちストリームデータ８２２及び８２３としてコピーする。
また、メモリコピーの対象がクエリグループ５１３である場合には、ストリーム処理部１５０のメモリ状態がストリーム処理部１２０のメモリ状態とすべて同一にはならないため、クエリを実行することによってクエリ内に保持されるデータを回復する必要がある。このため、待機系の入力ストリームデータ８２４を削除せずにそのまま保持する。
現用系のストリーム処理部１２０は、クエリグループ５１３のメモリコピーが終了すると、再びクエリグループ５１１から順次メモリコピーを行う。
また、時間間隔で実行されるメモリコピーとは別に、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」で定義されたクエリグループ５１１及び５１２のメモリコピーが、それぞれ入力件数が１００件、５０件に達した場合に行われる。この場合のメモリコピーでは、各クエリに対応する入力データ管理情報、クエリ内のストリームデータ及び送信待ちストリームデータを待機系のストリーム処理部１５０に送信する。そして、現用系のストリーム処理部１２０からデータを受信した待機系のストリーム処理部１５０は、受信した情報をメモリ１４２にコピーする。なお、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」で指定されたクエリグループは、コピータイミングが異なるのみであり、現用系におけるメモリ送信処理及び待機系におけるメモリコピー処理の手順は同じである。
ここで、クエリグループ定義を「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ２」としているのは、クエリ２１２（ＬｏｇｉｎＣｏｕｎｔ２）のクエリ処理内容がユーザ毎に１分間のログイン数を集計するクエリであって、集計結果をクエリ２１３及びクエリ２１５の各クエリに出力するためである。すなわち、複数のクエリに入力データを提供するクエリを対象としているのである。
クエリグループ定義に「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＦｉｌｔｅｒＲｕｌｅ２」としているのは、例示したストリーム処理が異常なユーザ及び正常なユーザを検出するため、クエリ２１５による正常なユーザの検出量がクエリ２１３による異常なユーザの検出量よりも多いことが想定されるためである。したがって、待機系のストリーム処理部１５０で回復処理を行う場合に、クエリ２１５以降のメモリコピー回数が多い方が回復時のクエリ２１５以降のクエリ処理の実行を少なくすることができ、回復に要する時間を削減することができるためである。
「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」に「ＬｏｇｉｎＣｏｕｎｔ１」及び「ＬｏｇｉｎＣｏｕｎｔ２」が指定されているのは、クエリ２１１及びクエリ２１２にＲａｎｇｅＷｉｎｄｏｗが指定されているためである。ＲａｎｇｅＷｉｎｄｏｗは、時間当たりのデータ数を保持するため、保持しなければならないタプルの数を想定することができず、ストリームデータが大量に入力される場合には、大量のデータを保持しなければならない。そこで、時間間隔によるメモリコピーだけでなく、入力データ数でメモリコピーを行うことによって、待機系で保持されていないデータを現用系で大量に保持することを防止しているのである。なお、時間当たりの入力されるストリームデータが少ない場合には「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」を定義しなくてもよい。
図９は、本発明の実施の形態のコピー容量管理テーブル１２８の一例を示す図である。
図９に示すコピー容量管理テーブル１２８は、ストリーム処理システムの起動時に、定義ファイル解析制御部１２９が、図３に示したクエリ定義及び図４に示したクエリグループ定義４００を解析することによって作成されたものである。
コピー容量管理テーブル１２８には、実行されたメモリコピーの対象を含むメモリコピー状態管理部９０１及びメモリコピーが実行される単位であるグループの定義情報が含まれる。
メモリコピー状態管理部９０１は、メモリコピーが実行されたクエリグループを管理する。メモリコピー状態管理部９０１には、例えば、メモリコピーが実行されたグループの識別情報であるメモリコピー状態情報、及びメモリコピーの実行間隔であるメモリコピー間隔時間が記録される。
メモリコピー状態情報は、前述のように実行されたメモリコピーが実行されたグループの識別情報であり、「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」で設定された時間間隔で変化する動的な情報である。メモリコピー状態情報に格納された情報に基づいて、次に実行されるクエリグループを特定することができる。なお、メモリコピー状態情報には、実行されたグループではなく、次に実行されるクエリグループを格納してもよい。メモリコピー間隔時間には、「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」で設定された値が格納される。
さらに、メモリコピーが実行される単位であるグループには、インターバルグループ及びデータ入力グループが含まれる。インターバルグループは「ｑｕｅｒｙ＿ｇｒｏｕｐ」に定義された情報に基づいて作成されたクエリグループのコピーサイクルを管理する。データ入力グループは「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」に定義された情報に基づいて作成されたクエリグループを管理する。インターバルグループ及びデータ入力グループは、ストリームデータ処理システムの起動時に作成されてから値が変化しない静的な情報である。
ここで、クエリ定義３００及びクエリグループ定義４００に基づいて、具体的に作成されるインターバルグループ及びデータ入力グループについて説明する。
インターバルグループには、クエリグループ定義４００の「ｑｕｅｒｙ＿ｇｒｏｕｐ」に定義された情報に基づいて、インターバルグループＡ９１１、インターバルグループＢ９１２及びインターバルグループＣ９１３が作成される。したがって、コピー容量管理テーブル１２８のメモリコピー状態情報には、インターバルグループＡ９１１、インターバルグループＢ９１２又はインターバルグループＣ９１３のいずれかが記録される。
インターバルグループＡ９１１は、「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ１」の定義に基づいて作成されるクエリグループである。インターバルグループＡ９１１は、クエリ「ＬｏｇｉｎＣｏｕｎｔ１」を先頭クエリとし、後続のすべてのクエリが含まれるクエリグループである。クエリグループに含まれないクエリに保持されるデータは、入力されたストリームデータにクエリを適用することによって復元される。このように、後続のクエリをすべて含むようにクエリグループを定義することによって、クエリグループの先頭クエリを境界として、入力されたストリームデータを処理する必要があるか否かを判断することができる。
同様に、インターバルグループＢ９１２は「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＬｏｇｉｎＣｏｕｎｔ２」の定義に基づいて作成されるクエリグループ情報、インターバルグループＣ９１３は「ｑｕｅｒｙ＿ｇｒｏｕｐ＝ＦｉｌｔｅｒＲｕｌｅ２」の定義に基づいて作成されるクエリグループ情報である。
また、クエリグループ定義ファイル１１７によらずに、クエリ定義ファイル１１６に含まれる各クエリを先頭クエリとしてクエリグループ（インターバルグループ）を作成するようにしてもよい。こうすることによって、クエリグループの作成を自動化することができる。
クエリグループのコピーサイクルは、各クエリグループの先頭クエリによって決定される。インターバルグループＡ９１１の先頭クエリは「ＬｏｇｉｎＣｏｕｎｔ１」、インターバルグループＢ９１２の先頭クエリは「ＬｏｇｉｎＣｏｕｎｔ２」、インターバルグループＣ９１３の先頭クエリは「ＦｉｌｔｅｒＲｕｌｅ２」であるため、「ＬｏｇｉｎＣｏｕｎｔ１」「ＬｏｇｉｎＣｏｕｎｔ２」「ＦｉｌｔｅｒＲｕｌｅ２」の順で処理される。ストリーム処理の順序をメモリコピー優先度と位置付けると、クエリグループのコピーサイクルはインターバルグループＡ９１１、インターバルグループＢ９１２、インターバルグループＣ９１３となる。また、図５に示すように、クエリ２１３及びクエリ２１５は、ストリーム処理の順序に基づいて判断すると同位の優先度となるが、この場合にはクエリが定義された順序に基づいて優先度を決定する。
なお、クエリグループのコピーサイクルは、必ずしも、ストリーム処理の順序に従う必要はない。例えば、各クエリグループを独立した時間間隔で実行するようにしてもよい。この場合には、計算機の負荷の増大を抑制するため、複数のクエリグループのコピーが同時に実行されないように留意するとよい。
また、ネットワークの負荷が小さい場合には転送するデータ量が多いクエリグループ（例えば、インターバルグループＡ９１１）のコピーを実行し、ネットワークの負荷が小さい場合には転送するデータ量が少ないクエリグループ（例えば、インターバルグループＣ９１３）のコピーを実行するようにしてもよい。
データ入力グループには、クエリグループ定義４００の「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」に定義された情報に基づいて、データ入力グループＡ９２１及びデータ入力グループＢ９２２が作成される。
データ入力グループＡ９２１は、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ１、１００」の定義に基づいて作成されるクエリグループ情報を保持する。データ入力グループＢ９２２は、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ＝ＬｏｇｉｎＣｏｕｎｔ２、５０」の定義に基づいて作成されるクエリグループ情報を保持する。
図１０は、本発明の実施の形態のタプル管理テーブル１２５の一例を示す図である。
タプル管理テーブル１２５は、ストリーム処理システム起動時に、定義ファイル解析制御部１２９によってコピー容量管理テーブル１２８が作成された後、クエリ構成に基づいてクエリ単位に作成される。
タプル管理テーブル１２５は、クエリ名称、入力データ閾値数、入力データ最新時刻、同時刻データ入力数及び入力データ数を含む。
クエリ名称は、定義されているクエリを識別する名称である。入力データ閾値数は、クエリグループ定義４００に、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」が定義されている場合にメモリコピーを実行する閾値となる入力データの数である。クエリ名称及び入力データ閾値数は、ストリーム処理システム起動時に設定され、その後、値が変更されない静的な情報である。
入力データ最新時刻は、当該クエリに最新のストリームデータが入力された時刻である。同時刻データ入力数は、入力データ最新時刻において当該クエリに入力されているストリームデータの入力数である。入力データ数は、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」定義でメモリコピー実施対象となる入力データ数の動的な情報からなり、「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」が定義されている場合にメモリコピーの対象となる入力データ数である。
図１０には、クエリ定義３００及びクエリグループ定義４００に基づいて作成されるタプル管理テーブル１２５の具体例が示されている。
タプル管理テーブル１００１は、クエリ名「ＬｏｇｉｎＣｏｕｎｔ１」の入力タプル情報を保持する。同じく、タプル管理テーブル１００２はクエリ名「ＬｏｇｉｎＣｏｕｎｔ２」の入力タプル情報、タプル管理テーブル１００３はクエリ名「ＦｉｌｔｅｒＲｕｌｅ１」の入力タプル情報、タプル管理テーブル１００４はクエリ名「ＬｏｇｉｎＲｕｌｅ１」の入力タプル情報、タプル管理テーブル１００５はクエリ名「ＦｉｌｔｅｒＲｕｌｅ２」の入力タプル情報、タプル管理テーブル１００６はクエリ名「ＬｏｇｉｎＲｕｌｅ２」の入力タプル情報をそれぞれ保持する。
入力データ最新時刻、同時刻データ入力数及び入力データ数は、クエリにデータが入力された時点で更新される動的な情報である。
図１１は、本発明の実施の形態の現用系の計算機１１０に障害が発生し、待機系の計算機１４０に処理を切り替える手順を説明する図である。
図１１には、図８に示したクエリグループ５１６に対応するメモリコピーが実行され、待機系におけるクエリグループ５１６に対応するタプル管理テーブル１１４５及びタプル管理テーブル１１４６が最新の情報となっている状態を示している。
現用系のストリーム処理部１２０に含まれるハートビート送受信部１３２は、ストリーム処理部１２０が動作中であることを、１秒間隔でハートビートを送信することによって、待機系のストリーム処理部１５０のハートビート送受信部１６２に通知する。ハートビートとは、現用系のストリーム処理部１２０が正常に稼動していることを外部に知らせるために送信される信号である。
ハートビート送受信部１６２は、ハートビートを受信すると、現用系のストリーム処理部１２０が動作中であると認識する。ハートビート送受信部１６２は、現用系のストリーム処理部１２０からのハートビートの送信遅れを考慮し、最大２秒間までハートビートの受信を待機する。２秒間待機しても現用系のストリーム処理部１２０によって送信されたハートビートを受信できなかった場合には、ハートビート送受信部１６２は現用系のストリーム処理部１２０に障害が発生したと認識する。
ハートビート送受信部１６２は、現用系のストリーム処理部１２０の障害を認識すると、ストリーム処理部１５０において回復処理を開始するために、主制御部１５３を起動する。主制御部１５３は、ストリーム処理システムの回復処理を開始するため、まず、入力ストリーム保存管理部１５７を起動する。入力ストリーム保存管理部１５７は、最古のストリームデータ１−１を主制御部１５３に送信する。
主制御部１５３は、入力データを最初に処理するクエリに対応する入力データ制御部１１２１を起動する。さらに、起動された入力データ制御部１１２１に、受信したストリームデータ１−１を送信する。
入力データ制御部１１２１は、タプル管理テーブル１１４１の最新時刻（入力データ最新時刻）とストリームデータ１−１の時刻を比較し、当該最新時刻よりもストリームデータ１−１の時刻が新しい場合にはクエリ処理部１１３１を起動する。
クエリ処理部１１３１は、クエリ処理を実行してストリームデータ１−１を処理し、結果タプルを出力する。このとき、結果タプルの時刻は、クエリ処理部１１３１内の最古時刻（０９：５９：３０）を設定し、主制御部１５３に送信する。ここで、クエリ処理部１１３１が保持する最新時刻のタプルは１０：００：３０のタプルとなり、また、タプル管理テーブル１１４１にある最新時刻を１０：００：３０に、同時刻のデータ入力数を１に変更する。
この際、対応するクエリのＲａｎｇｅＷｉｎｄｏｗが１分であるため、クエリ処理部１１３１が保持していた０９：５９：３０のタプルは消滅し、クエリ処理部１１３１には１０：００：００と１０：００：３０のタプルが保持される。
主制御部１５３は、入力データ制御部１１２２を起動し、起動した入力データ制御部１１２２にクエリ処理部１１３１の処理結果（０９：５９：３０）を送信する。入力データ制御部１１２２は、タプル管理テーブル１１４２にある最新時刻（０９：５９：００）と入力データの時刻（０９：５９：３０）とを比較し、最新時刻よりも入力データの時刻が新しい場合にはクエリ処理部１１３２を起動する。
クエリ処理部１１３２は、クエリ処理を実行し、結果タプルを出力する。さらに、出力された結果タプルは、クエリ処理部１１３２に保持された最古時刻（０９：５８：３０）が設定され、主制御部１５３に送信される。
ここで、クエリ処理部１１３２に保持されている最新時刻のタプルは０９：５９：３０のタプルとなり、また、タプル管理テーブル１１４２にある最新時刻を０９：５９：３０に、同時刻のデータ入力数を１に変更する。
この際、対応するクエリのＲａｎｇｅＷｉｎｄｏｗが１分であるため、クエリ処理部１１３２に保持されていた０９：５８：３０のタプルは消滅し、クエリ処理部１１３２には０９：５９：００と０９：５９：３０のタプルが保持される。
主制御部１５３は、さらに、入力データ制御部１１２３を起動し、起動した入力データ制御部１１２３にクエリ処理部１１３２の処理結果（０９：５８：３０）を送信する。入力データ制御部１１２３は、タプル管理テーブル１１４３にある最新時刻（０９：５８：０）と入力タプルの時刻（０９：５８：３０）とを比較し、最新時刻よりも入力タプルに設定された時刻が新しい場合には、クエリ処理部１１３３を起動する。
クエリ処理部１１３３は、クエリ処理を実行し、入力されたタプルが異常ユーザのデータである場合にはタプルを出力する。クエリ処理部１１３３にはＷｉｎｄｏｗが定義されていないため、入力データ時刻（０９：５８：３０）をそのまま出力タプルに設定し、主制御部１５３に送信する。そして、タプル管理テーブル１１４２にある最新時刻を０９：５８：３０に、同時刻の入力数を１に変更する。
主制御部１５３は、さらに、入力データ制御部１１２４を起動し、起動した入力データ制御部１１２４にクエリ処理部１１３３の処理結果（０９：５８：３０）を送信する。入力データ制御部１１２４は、タプル管理テーブル１１４４にある最新時刻（０９：５８：００）と入力タプルの時刻（０９：５８：３０）とを比較し、最新時刻よりも入力タプルに設定された時刻が新しい場合には、クエリ処理部１１３４を起動する。
クエリ処理部１１３４は、クエリ処理を実行し、入力されたタプルにホスト情報及びログイン時間を付与する。クエリ処理部１１３４にはＷｉｎｄｏｗが定義されていないため、入力データ時刻（０９：５８：３０）をそのまま出力タプルに設定し、主制御部１５３に送信する。そして、タプル管理テーブル１１４２にある最新時刻を０９：５８：３０に、同時刻の入力数を１に変更する。クエリ処理部１１３４から出力された出力タプルは、以降、処理されるクエリが定義されていないため、データ受信クライアント１９１に送信される。
次に、主制御部１５３は、入力データ制御部１１２５を起動し、起動された入力データ制御部１１２５にクエリ処理部１１３２の処理結果（０９：５８：３０）を送信する。
入力データ制御部１１２５は、タプル管理テーブル１１４５にある最新時刻（１０：００：００）と入力タプルの時刻（０９：５８：３０）とを比較し、入力タプルに設定された時刻よりも最新時刻が新しいため、入力タプルを破棄する。
続いて、入力ストリーム保存管理部１５７に保持されたストリームデータ１−２を、ストリームデータ１−１の場合と同様に処理を開始する。ストリームデータ１−２が正常データの場合には、クエリ処理部１１３３から結果タプルが出力されずに入力されたタプルが破棄される。さらに、クエリ処理部１１３５では、入力タプルに設定された時刻よりも最新時刻が新しいため、入力タプルが破棄される。ストリームデータ１−３についても同様に処理される。
主制御部１５３は、ストリームデータ１−３の処理が完了した後、入力ストリーム保存管理部１５７によって次のストリームデータを入力しようとする。しかし、入力ストリーム保存管理部１５７に保存されているストリームデータの処理がすべて完了したため、入力ストリーム保存管理部１５７は、処理対象のデータが存在しないことを主制御部１５３に通知する。
主制御部１５３は、入力ストリーム保存管理部１５７から処理対象のデータが存在しないことが通知されると、ストリームデータの回復処理を終了する。以降、ストリーム処理部１５０が、障害が発生したストリーム処理部１２０の替わりに実行系としてストリーム処理を継続する。
以下、本発明の実施の形態のストリームデータ処理システムの処理手順についてフローチャートを示しながら説明する。以下に示す各処理は、現用系の計算機１１０のプロセッサ１１１又は待機系の計算機１４０のプロセッサ１４１によって、ストリーム処理部１２０又はストリーム処理部１５０に含まれるプログラムが実行されることによって実行される。したがって、以下のフローチャートに示す処理の主体は、プロセッサ１１１又はプロセッサ１４１となるが、理解を容易にするために、処理を実行するためにプロセッサによって実行された処理部（プログラム）を主体として記述する。
また、各計算機は、現用系としても待機系としても機能するため、各処理部に対応するフローチャートには、現用系で実行される処理及び待機系で実行される処理の両方が示されている。特に断らない限り、フローチャートの各処理の動作主体は、現用系に含まれる各処理部とする。
図１２は、本発明の実施の形態のデータ受信部１２１による処理の手順を示すフローチャートである。本処理は、現用系及び待機系の計算機で実行される処理であり、待機系の計算機１４０で実行される場合も同様である。
ストリーム処理システムが開始されると、現用系の計算機１１０及び待機系の計算機１４０において、データ受信部１２１及びデータ受信部１５１が実行され、ストリームデータの受信が開始される（ステップ１２０１）。
データ受信部１２１は、通信インタフェース１１３を介してストリームデータの受信要求を受け付ける（ステップ１２０２）。さらに、ストリームデータを受信したか否かを判定する（ステップ１２０３）。ストリームデータを受信できなかった場合には（ステップ１２０３の結果が「Ｎｏ」）、所定の条件を満たすまで待機するＷＡＩＴ状態に移行する（ステップ１２０５）。
データ受信部１２１は、ストリームデータを受信した場合には（ステップ１２０３の結果が「Ｙｅｓ」）、主制御部１２３を起動し、受信したストリームデータを処理する（ステップ１２０４）。
データ受信部１２１は、データ送信クライアント１９０から送信されたデータを受信し、通信インタフェース１１３からデータの受信が通知された場合、又はストリーム処理システムの終了要求を受け付けた場合にＷＡＩＴ状態が解除される。
データ受信部１２１は、ＷＡＩＴ状態を解除された場合には、ストリーム処理システムの終了要求でＷＡＩＴ状態が解除されたか否かを判定する（ステップ１２０６）。すなわち、データの受信によってＷＡＩＴ状態が解除されたか、又はストリーム処理システムの終了要求でＷＡＩＴ状態が解除されたかを判定する。
データ受信部１２１は、データの受信によってＷＡＩＴ状態が解除された場合には（ステップ１２０６の結果が「Ｎｏ」）、データ受信要求を受け付ける（ステップ１２０２）。一方、ストリーム処理システムの終了要求によってＷＡＩＴ状態が解除された場合には（ステップ１２０６の結果が「Ｙｅｓ」）、データ受信部１２１の処理を終了する（ステップ１２０７）。
図１３は、本発明の実施の形態のデータ送信部１２２による処理の手順を示すフローチャートである。
データ送信部１２２は、主制御部１２３によるデータ送信要求時に起動され、クエリ処理部１２６によって処理されたデータの送信を開始する（ステップ１３０１）。
データ送信部１２２は、まず、データの送信処理が実行中であるか否か判定する（ステップ１３０２）。送信処理が実行中でない場合には（ステップ１３０２の結果が「Ｎｏ」）、通信インタフェース１１３にデータ送信要求を送信し（ステップ１３０３）、データ受信クライアント１９１にデータを送信する。
データ送信部１２２は、データ送信要求の送信後、送信待ちデータが存在するか否かを判定する（ステップ１３０４）。送信待ちデータが存在する場合には（ステップ１３０４の結果が「Ｙｅｓ」）、先頭のデータをメモリチェインから切り離し（ステップ１３０５）、再度、通信インタフェース１１３にデータ送信要求を送信する（ステップ１３０３）。メモリチェインとは、未送信のデータを送信する順序にリスト状に連結して保持するデータ構造である。その後、メモリチェインの先頭から順次データを送信し、送信待ちデータがなくなると、データ送信部１２２の処理を終了する（ステップ１３０７）。
データ送信部１２２は、データの送信処理が実行中の場合には（ステップ１３０２の結果が「Ｎｏ」）、送信データをメモリチェインの最後尾に保存し（ステップ１３０６）、データ送信部１２２の処理を終了する（ステップ１３０７）。
図１４は、本発明の実施の形態の主制御部１２３による処理の手順を示すフローチャートである。
主制御部１２３は、ストリームデータを受信した場合、又は現用系に障害が発生し、待機系で回復処理を実行する場合に起動される（ステップ１４０１）。
主制御部１２３又は主制御部１５３は、自ストリーム処理部が現用系か否かを判定する（ステップ１４０２）。自ストリーム処理部が現用系の場合には（ステップ１４０２の結果が「Ｙｅｓ」）、ストリームデータを受信したことによって本処理が開始されたと認識し、クエリ定義に基づいて、入力データ制御部１２４を起動する（ステップ１４０３）。
主制御部１２３は、入力データ制御部１２４の処理が終了すると、出力データが存在するか否かを判定する（ステップ１４０４）。出力データが存在する場合には（ステップ１４０４の結果が「Ｙｅｓ」）、再度クエリ定義に基づいて後続のクエリが存在するか否かを判定する（ステップ１４０５）。後続のクエリが存在する場合には（ステップ１４０５の結果が「Ｙｅｓ」）、定義されたクエリをすべて処理するまで、入力データ制御部１２４を実行する（ステップ１４０３）。
主制御部１２３は、後続のクエリが存在せず（ステップ１４０５の結果が「Ｎｏ」）、かつ、出力データがある場合には（ステップ１４０４の結果が「Ｙｅｓ」）、データ送信部１２２を起動し、出力データを送信する（ステップ１４０６）。
主制御部１２３は、出力データの送信が完了した場合、又は、後続のクエリが存在せず（ステップ１４０５の結果が「Ｎｏ」）、かつ、出力データがない場合には（ステップ１４０４の結果が「Ｎｏ」）、他に処理すべきクエリが存在するか否か、すなわち、定義されたすべてのクエリを処理したか否かを判定する（ステップ１４０７）。すべてのクエリを処理していない場合、すなわち、未処理のクエリが残されている場合には（ステップ１４０７の結果が「Ｎｏ」）、残りのクエリを処理する。
主制御部１２３は、すべてのクエリを処理した場合には（ステップ１４０７の結果が「Ｙｅｓ」）、自ストリーム処理部が現用系か否かを判定する（ステップ１４０８）。現用系である場合には（ステップ１４０８の結果が「Ｙｅｓ」）、主制御部１２３の処理を終了する（ステップ１４１３）。
主制御部１５３は、自ストリーム処理部が現用系でない場合、すなわち、待機系の場合には（ステップ１４０２の結果が「Ｎｏ」）、要求された処理が回復処理であるか否かを判定する（ステップ１４０９）。
主制御部１５３は、回復処理を要求された場合には（ステップ１４０９の結果が「Ｙｅｓ」）、入力ストリーム保存管理部１５７を起動し、保存されたストリームデータの取り出しを要求する（ステップ１４１０）。さらに、入力データが存在するか否かを判定する（ステップ１４１２）。入力データが存在する場合には（ステップ１４１２の結果が「Ｙｅｓ」）、定義されたクエリに基づいて、入力データ制御部１５４を起動し（ステップ１４０３）、入力データを処理する。入力データが存在しない場合には（ステップ１４１２の結果が「Ｎｏ」）、主制御部１５３の処理を終了する（ステップ１４１３）。
一方、主制御部１５３は、回復処理を要求されていない場合には（ステップ１４０９の結果が「Ｙｅｓ」）、入力ストリーム保存管理部１５７を実行し、受信したストリームデータの保存を要求する（ステップ１４１１）。その後、主制御部１５３の処理を終了する（ステップ１４１３）。
図１５は、本発明の実施の形態の入力データ制御部１２４による処理の手順を示すフローチャートである。
本処理は、現用系及び待機系の両方で実行される処理であるが、入力データ制御部１２４を主体として説明する。
入力データ制御部１２４は、主制御部１２３によって起動される（ステップ１５０１）。このとき、主制御部１２３によってデータが入力される。
入力データ制御部１２４は、入力データに付与された時刻を取得する（ステップ１５０２）。さらに、タプル管理テーブル１２５から入力データ最新時刻を取得する（ステップ１５０３）。続いて、自ストリーム処理部が回復処理を実行中であるか否かを判定する（ステップ１５０４）。
入力データ制御部１２４は、自ストリーム処理部が回復処理を実行中でない場合には（ステップ１５０４の結果が「Ｎｏ」）、入力データに付与された時刻とタプル管理テーブル１２５の入力データ最新時刻が同じであるか否かを判定する（ステップ１５０５）。
入力データ制御部１２４は、入力データに付与された時刻とタプル管理テーブル１２５の入力データ最新時刻が同じである場合には（ステップ１５０５の結果が「Ｙｅｓ」）、タプル管理テーブル１２５の同一時刻入力データ数の値を１加算した値に更新する（ステップ１５０８）。
一方、入力データ制御部１２４は、入力データに付与された時刻と、タプル管理テーブル１２５の入力データ最新時刻とが異なる場合には（ステップ１５０５の結果が「Ｎｏ」）、タプル管理テーブル１２５の入力データ最新時刻を更新する（ステップ１５０６）。さらに、同一時刻入力データ数を１に初期化し、タプル管理テーブル１２５の同一時刻入力データ数を更新する。
入力データ制御部１２４は、タプル管理テーブル１２５の各項目の更新が終了すると、クエリ処理部１２６を起動し（ステップ１５０９）、定義されたクエリで入力データを処理する。クエリの処理が終了すると、入力データ制御部１２４の処理を終了する（ステップ１５１５）。
入力データ制御部１２４は、自ストリーム処理部が回復処理を実行中の場合には（ステップ１５０４の結果が「Ｙｅｓ」）、入力データに付与された時刻とタプル管理テーブル１２５の入力データ最新時刻とを比較する（ステップ１５１０）。
入力データ制御部１２４は、入力データに付与された時刻よりもタプル管理テーブル１２５の入力データ最新時刻が古い場合には（ステップ１５１０の結果が「＞」）、クエリ処理部１２６を起動し（ステップ１５０９）、定義されたクエリで入力データを処理する。クエリの処理が終了すると、入力データ制御部１２４の処理を終了する（ステップ１５１５）。
入力データ制御部１２４は、入力データに付与された時刻よりもタプル管理テーブル１２５の入力データ最新時刻が新しい場合には（ステップ１５１０の結果が「＜」）、タプル管理テーブル１２５の同一時刻入力データ数を１に設定する（ステップ１５１２）。その後、入力データを破棄し（ステップ１５１４）、入力データ制御部１２４の処理を終了する（ステップ１５１５）。
入力データ制御部１２４は、入力データに付与された時刻がタプル管理テーブル１２５の入力データ最新時刻と一致する場合には（ステップ１５１０の結果が「＝」）、入力データの数とタプル管理テーブル１２５の同一時刻入力データ数とを比較する（ステップ１５１１）。
入力データ制御部１２４は、入力データの数がタプル管理テーブル１２５の同一時刻入力データ数よりも大きい場合、又は同じ場合には（ステップ１５１１の結果が「＝＞」）、定義されたクエリで入力データを処理する。クエリの処理が終了すると、入力データ制御部１２４の処理を終了する（ステップ１５１５）。
入力データ制御部１２４は、入力データの数がタプル管理テーブル１２５の同一時刻入力データ数よりも小さい場合には（ステップ１５１１の結果が「＜」）、タプル管理テーブル１２５の同一時刻入力データ数の値を１加算した値に更新する（ステップ１５０８）。その後、入力データを破棄し（ステップ１５１４）、入力データ制御部１２４の処理を終了する（ステップ１５１５）。
図１６は、本発明の実施の形態のメモリコピー制御部１３０による処理の手順を示すフローチャートである。
メモリコピー制御部１３０は、ストリーム処理部１２０の開始時に起動される（ステップ１６０１）。起動後、現用系では定義されたメモリコピー間隔時間分だけ待機し、ＷＡＩＴ状態となる（ステップ１６０２）。一方、待機系では現用系によって送信されたメモリの内容のコピー要求を受信するまで待機する（ステップ１６０２）。
現用系のメモリコピー制御部１３０では、メモリ送信時間間隔の満了、所定のデータ入力量の充足又はシステムの終了によるＷＡＩＴ解除要求によってＷＡＩＴ状態が解除される。また、待機系のメモリコピー制御部１６０では、メモリコピー要求の受信又はシステムの終了によるＷＡＩＴ解除要求によってＷＡＩＴ状態が解除される。
メモリコピー制御部１３０は、まず、ＷＡＩＴ状態が解除された要因が、メモリ送信要求、メモリコピー要求、又はシステム終了要求のいずれであるかを判定する（ステップ１６０３）。
メモリコピー制御部１３０は、メモリ送信要求によってＷＡＩＴ状態が解除された場合には（ステップ１６０３の結果が「メモリ送信要求」）、さらに、メモリ送信要求が、メモリコピー間隔時間によるものか、入力データ量によるものかを判定する（ステップ１６０４）。
メモリコピー制御部１３０は、メモリコピー間隔時間によってメモリ送信要求が通知された場合には（ステップ１６０４の結果が「Ｙｅｓ」）、メモリ容量管理テーブルに含まれるメモリコピー状態情報を取得し（ステップ１６０５）、メモリコピーの対象となるインターバルグループを取得する（ステップ１６０６）。その後、メモリコピー状態情報を次のインターバルグループに更新する（ステップ１６０７）。
メモリコピー制御部１３０は、クエリに対する入力データ量の充足によってメモリ送信要求が通知された場合には（ステップ１６０４の結果が「Ｎｏ」）、当該クエリに対応するデータ入力グループ情報を取得する（ステップ１６０８）。
メモリコピー制御部１３０は、インターバルグループ又はデータ入力グループの情報を取得すると、各情報からクエリに含まれるストリームデータ、すなわち、クエリ処理部１２４に保持されているストリームデータを取得する（ステップ１６０９）。さらに、各クエリに対応するタプル管理テーブル１２５に含まれる入力データ最新時刻及び入力データ数を取得する（ステップ１６１０）。
さらに、メモリコピー制御部１３０は、データ受信クライアント１９１への未送信の出力データが存在するか否かを判定する（ステップ１６１１）。未送信の出力データが存在する場合には（ステップ１６１１の結果が「Ｙｅｓ」）、データ送信部１２２に保持された未送信の出力データを取得する（ステップ１６１２）。待機系に送信するデータの取得が完了すると、メモリ送受信制御部１３１を起動する（ステップ１６１３）。メモリ送受信制御部１３１による処理が終了すると、再びＷＡＩＴ状態に移行する（ステップ１６０２）。
メモリコピー制御部１６０は、メモリコピー要求によってＷＡＩＴ状態が解除された場合には（ステップ１６０３の結果が「メモリコピー要求」）、まず、受信したデータから該当するクエリ情報を取得する（ステップ１６１４）。そして、該当するクエリに対応するクエリ処理部１５４に保持されているストリームデータを更新し（ステップ１６１５）、さらに、該当するクエリに対応するタプル管理テーブル１５５を更新する（ステップ１６１６）。
また、メモリコピー制御部１６０は、データ受信クライアント１９１への未送信の出力データが存在するか否かを判定する（ステップ１６１７）。未送信の出力データが存在する場合には（ステップ１６１７の結果が「Ｙｅｓ」）、データ送信部１５２に保持された未送信の出力データを取得する（ステップ１６１８）。
メモリコピー制御部１６０は、受信したデータをすべてコピーし、すべてのデータ及び情報が更新された後、受信したデータがすべてのクエリに対するデータであるか否かを判定する（ステップ１６１９）。受信したデータがすべてのクエリに対するデータであった場合には（ステップ１６１９の結果が「Ｙｅｓ」）、入力されたストリームデータを削除する（ステップ１６２０）。その後、再びＷＡＩＴ状態に移行する（ステップ１６０２）。
メモリコピー制御部１３０は、システムの終了要求によってＷＡＩＴ状態が解除された場合には（ステップ１６０３の結果が「システム終了」）、メモリコピー制御部１３０の処理を終了する（ステップ１６２１）。
図１７は、本発明の実施の形態の入力ストリーム保存管理部１２７による処理の手順を示すフローチャートである。
入力ストリーム保存管理部１２７は、主制御部１２３によって起動される（ステップ１７０１）。入力ストリーム保存管理部１２７は、起動されると、まず、主制御部１２３からの要求を受け付ける。そして、受け付けた要求がデータの保存要求であるか否かを判定する（ステップ１７０２）。
入力ストリーム保存管理部１２７は、データの保存要求を受け付けた場合には（ステップ１７０２の結果が「Ｙｅｓ」）、入力されたデータを入力ストリーム保存管理部１２７に保存する（ステップ１７０３）。入力されたデータは、前述したメモリチェインによって格納される。その後、入力ストリーム保存管理部１２７による処理を終了する（ステップ１７０６）。
入力ストリーム保存管理部１２７は、データの保存要求でない要求を受け付けた場合、すなわち、データの取出し要求を受け付けた場合には（ステップ１７０２の結果が「Ｎｏ」）、保存されているストリームデータが存在するか否かを判定する（ステップ１７０４）。保存中のストリームデータが存在しない場合には（ステップ１７０４の結果が「Ｎｏ」）、入力ストリーム保存管理部１２７による処理を終了する（ステップ１７０６）。
入力ストリーム保存管理部１２７は、保存中のストリームデータが存在する場合には（ステップ１７０４の結果が「Ｙｅｓ」）、メモリチェインの先頭に格納されたデータを切り離し、切り離されたデータを返却する（ステップ１７０５）。その後、入力ストリーム保存管理部１２７の処理を終了する（ステップ１７０６）。
図１８は、本発明の実施の形態のクエリ処理部１２６による処理の手順を示すフローチャートである。
クエリ処理部１２６は、入力データ制御部１２４によって起動される（ステップ１８０１）。さらに、クエリ処理部１２６に対応するＣＱＬを、入力データに基づいて実行する（ステップ１８０２）。ＣＱＬの実行が完了すると、クエリ処理部１２６による処理を終了する（ステップ１８０３）。
図１９は、本発明の実施の形態の定義ファイル解析制御部１２９による処理の手順を示すフローチャートである。
定義ファイル解析制御部１２９は、ストリーム処理部１２０の開始時に起動される（ステップ１９０１）。
定義ファイル解析制御部１２９は、まず、ハードディスク装置１１５に格納されたクエリ定義ファイル１１６を、ディスクインタフェース１１４を介してオープンする（ステップ１９０２）。同じくディスクインタフェース１１４を介してクエリ定義ファイル１１６に含まれる１行単位に定義内容の読み出しを要求する（ステップ１９０３）。
定義ファイル解析制御部１２９は、クエリ定義ファイル１１６から１行単位に定義内容を読み出し、データが取得されたか否かを判定する（ステップ１９０４）。データが取得された場合には（ステップ１９０４の結果が「Ｙｅｓ」）、さらに定義項目を判定する（ステップ１９０５）。
定義ファイル解析制御部１２９は、定義項目が「ｒｅｇｉｓｔｅｒ ｓｔｒｅａｍ」の場合には（ステップ１９０５の結果が「ｒｅｇｉｓｔｅｒ ｓｔｒｅａｍ」）、一時的にクエリ実行順序を格納するためのストリーム領域をメモリ１１２に割り当てる（ステップ１９０６）。
定義ファイル解析制御部１２９は、定義項目が「ｒｅｇｉｓｔｅｒ ｑｕｅｒｙ」の場合には（ステップ１９０５の結果が「ｒｅｇｉｓｔｅｒ ｑｕｅｒｙ」）、メモリ上に割り当てられたストリーム領域にクエリ名称を実行順に格納する（ステップ１９０７）。
定義ファイル解析制御部１２９は、ステップ１９０３からステップ１９０７までの処理をクエリ定義ファイル１１６に定義されたすべての行について実行し、クエリの実行順序を決定する。
定義ファイル解析制御部１２９は、すべての行を読み出して処理すると（ステップ１９０４の結果が「Ｎｏ」）、ハードディスク装置１１５に格納されたクエリ定義ファイル１１６を、ディスクインタフェース１１４を介してクローズする（ステップ１９０８）。さらに、コピー容量管理テーブル１２８を作成するための領域をメモリ１１２に割り当てる（ステップ１９０９）。
定義ファイル解析制御部１２９は、その後、ハードディスク装置１１５に格納されたクエリグループ定義ファイル１１７を、ディスクインタフェース１１４を介してオープンする（ステップ１９１０）。同じくディスクインタフェース１１４を介して１行単位に定義内容の読み出しを要求する（ステップ１９１１）。
定義ファイル解析制御部１２９は、クエリグループ定義ファイル１１７から１行単位に定義内容を読み出し、データが取得されたか否かを判定する（ステップ１９１２）。データが取得された場合には（ステップ１９１２の結果が「Ｙｅｓ」）、さらに定義項目を判定する（ステップ１９１３）。
定義ファイル解析制御部１２９は、定義項目が「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」の場合には（ステップ１９１３の結果が「ｉｎｐｕｔ＿ｄａｔａ＿ｎｕｍｂｅｒ」）、コピー容量管理テーブル１２８にデータ入力グループを作成し、該当するクエリのクエリ名称を設定する（ステップ１９１４）。
定義ファイル解析制御部１２９は、定義項目が「ｑｕｅｒｙ＿ｇｒｏｕｐ」の場合には（ステップ１９１３の結果が「ｑｕｅｒｙ＿ｇｒｏｕｐ」）、コピー容量管理テーブル１２８にインターバルグループを作成し、該当するクエリのクエリ名称を設定する（ステップ１９１５）。
定義ファイル解析制御部１２９は、定義項目が「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」の場合には（ステップ１９１３の結果が「ｍｅｍｏｒｙ＿ｃｏｐｙ＿ｉｎｔｅｒｖａｌ」）、コピー容量管理テーブル１２８のメモリコピー間隔時間を設定する（ステップ１９１６）。
定義ファイル解析制御部１２９は、クエリグループ定義ファイル１１７のすべての行を処理すると（ステップ１９１２の結果が「Ｎｏ」）、ハードディスク装置１１５に格納されたクエリグループ定義ファイル１１７を、ディスクインタフェース１１４を介してクローズする（ステップ１９１７）。その後、クエリごとのタプル管理テーブル１２５を作成する。
定義ファイル解析制御部１２９は、ステップ１９０６の処理で作成されたストリーム領域に含まれるクエリに対応するタプル管理テーブル１２５がすべて作成されたか否かを判定する（ステップ１９１８）。
定義ファイル解析制御部１２９は、すべてのタプル管理テーブル１２５が作成されていない場合には（ステップ１９１８の結果が「Ｎｏ」）、タプル管理テーブル１２５を作成するための領域をメモリ１１２に割り当てる（ステップ１９１９）。さらに、割り当てられた領域にタプル管理テーブル１２５が作成されていないクエリに対応するタプル管理テーブル１２５を作成し、対応するクエリの名称を設定する（ステップ１９２０）。さらに、入力データ閾値数を設定する（ステップ１９２１）。
定義ファイル解析制御部１２９は、すべてのクエリに対するタプル管理テーブル１２５の作成が終了した場合には（ステップ１９１８の結果が「Ｙｅｓ」）、定義ファイル解析制御部１２９の処理を終了する（ステップ１９２２）。
図２０は、本発明の実施の形態のメモリ送受信制御部１３１による処理の手順を示すフローチャートである。
メモリ送受信制御部１３１は、ストリーム処理部１２０の開始時に起動される（ステップ２００１）。メモリ送受信制御部１３１は、通信インタフェース１１３を介してデータの受信要求を受け付ける（ステップ２００２）。
メモリ送受信制御部１３１は、データを受信したか否かを判定する（ステップ２００３）。データを受信した場合には（ステップ２００３の結果が「Ｙｅｓ」）、メモリコピー制御部１３０を起動し、メモリコピーの実行を指示する（ステップ２００４）。
メモリ送受信制御部１３１は、データを受信していない場合には（ステップ２００３の結果が「Ｎｏ」）、データを受信するまで待機し、ＷＡＩＴ状態に移行する（ステップ２００５）。このとき、現用系から送信されたデータを、通信インタフェース１１３を介して受信したことが通知された場合、メモリコピー制御部１３０から送信要求を受け付けた場合、又はストリーム処理部の終了要求によるＷＡＩＴ解除要求を受け付けた場合には、ＷＡＩＴ状態が解除される。
メモリ送受信制御部１３１は、ＷＡＩＴ状態が解除されると、まず、メモリ受信要求によってＷＡＩＴ状態が解除されたか否かを判定する（ステップ２００６）。メモリ受信要求によってＷＡＩＴ状態が解除された場合には（ステップ２００６の結果が「Ｙｅｓ」）、通信インタフェース１１３を介してデータ受信要求を受け付ける（ステップ２００２）。その後、データを受信し、メモリコピー制御部１３０を実行することによって（ステップ２００４）、メモリコピーを実行する。
メモリ送受信制御部１３１は、メモリ受信要求によってＷＡＩＴ状態が解除されたのではない場合には（ステップ２００６の結果が「Ｎｏ」）、メモリ送信要求によってＷＡＩＴ状態が解除されたか否かを判定する（ステップ２００７）。メモリ送信要求によってＷＡＩＴ状態が解除された場合には（ステップ２００７の結果が「Ｙｅｓ」）、通信インタフェースを介してメモリの送信要求を現用系の計算機に送信する（ステップ２００８）。
メモリ送受信制御部１３１は、メモリ送信要求によってＷＡＩＴ状態が解除されたのではない場合には（ステップ２００７の結果が「Ｎｏ」）、ストリーム処理部の終了要求によってＷＡＩＴ状態が解除されたため、メモリ送受信制御部１３１の処理を終了する（ステップ２００９）。
図２１は、本発明の実施の形態のハートビート送受信部１３２による処理の手順を示すフローチャートである。
ハートビート送受信部１３２は、ストリーム処理部１２０の開始時に起動される（ステップ２１０１）。ハートビート送受信部１３２は、まず、自ストリーム処理部が現用系であるか否かを判定する（ステップ２１０２）。
ハートビート送受信部１３２は、自ストリーム処理部が現用系である場合には（ステップ２１０２の結果が「Ｙｅｓ」）、ハートビートを送信するまで、１秒間のＷＡＩＴ状態に移行する（ステップ２１０３）。ＷＡＩＴ状態は、ＷＡＩＴ時間の満了又はストリーム処理部からのシステム終了要求によるＷＡＩＴ解除要求によって解除される。
ハートビート送受信部１３２は、ＷＡＩＴ状態が解除されると、ストリーム処理部１２０からのシステム終了要求によってＷＡＩＴ状態が解除されたか否かを判定する（ステップ２１０４）。ストリーム処理部１２０からのシステム終了要求によってＷＡＩＴ状態が解除された場合には（ステップ２１０４の結果が「Ｙｅｓ」）、ハートビート送受信部１３２の処理を終了する（ステップ２１１３）。
一方、ハートビート送受信部１３２は、ストリーム処理部からのシステム終了要求によってＷＡＩＴ状態が解除されたのではない場合には（ステップ２１０４の結果が「Ｎｏ」）、ＷＡＩＴ時間の満了によってＷＡＩＴ状態が解除されたため、通信インタフェースを介してハートビートの送信を要求する（ステップ２１０５）。ハートビート送信後、再びハートビートを送信するまで待機する（ステップ２１０３）。以上の処理がシステムの終了まで繰り返される。
ハートビート送受信部１６２は、自ストリーム処理部が現用系でない場合（ステップ２１０２の結果が「Ｙｅｓ」）、すなわち、待機系の場合には、ハートビートを受信するまでＷＡＩＴ状態に移行する（ステップ２１０６）。ＷＡＩＴ状態は、ハートビートを受信した場合又はストリーム処理部からのシステム終了要求によるＷＡＩＴ解除要求によって解除される。
ハートビート送受信部１６２は、ＷＡＩＴ状態が解除されると、ストリーム処理部１５０からのシステム終了要求によってＷＡＩＴ状態が解除されたか否かを判定する（ステップ２１０７）。ストリーム処理部１５０からのシステム終了要求によってＷＡＩＴ状態が解除された場合には（ステップ２１０７の結果が「Ｙｅｓ」）、ハートビート送受信部１６２の処理を終了する（ステップ２１１３）。
一方、ハートビート送受信部１６２は、ストリーム処理部からのシステム終了要求によってＷＡＩＴ状態が解除されたのではない場合には（ステップ２１０４の結果が「Ｎｏ」）、ハートビートの受信によってＷＡＩＴ状態が解除されたため、通信インタフェース１１３を介してハートビートのデータ受信を要求する（ステップ２１０８）。
ハートビート送受信部１６２は、さらにデータを受信したか否かを判定する（ステップ２１０９）。受信データが存在する場合には（ステップ２１０９の結果が「Ｙｅｓ」）、受信したハートビートのデータを破棄する（ステップ２１１０）。その後、再びハートビートを受信するために２秒間のＷＡＩＴ状態に移行する（ステップ２１１１）。現用系からのハートビートは１秒間隔で送信されるが、ネットワークの輻輳などの影響による遅れを考慮して２秒間待機する。以上の処理がシステムの終了まで繰り返される。
このとき、ＷＡＩＴ状態は、ステップ２１０６の処理によるＷＡＩＴ状態と同様に、ハートビートを受信した場合又はストリーム処理部からのシステム終了要求によるＷＡＩＴ解除要求によって解除される。
一方、ハートビート送受信部１６２は、受信データが存在しない場合には（ステップ２１０９の結果が「Ｎｏ」）、現用系のストリーム処理部１２０に障害が発生したと判定し、主制御部１５３を起動し（ステップ２１１２）、回復処理の実行を要求する。回復処理が完了した後、ハートビート送受信部１６２の処理を終了する（ステップ２１１３）。
本発明の実施の形態によれば、現用系の計算機１１０のメモリ１１２に格納されたすべての情報を待機系の計算機１４０に毎回送信するのではないため、送信されるデータ量が削減され、ネットワーク１００の負荷を軽減することができる。
さらに、本発明の実施の形態によれば、待機系の計算機１４０においてすべての入力されたストリームデータに対してクエリを実行する必要がないため、待機系の計算機１４０の負荷を軽減することができる。
また、本発明の実施の形態によれば、現用系の計算機１１０のメモリ１１２に記憶された情報の一部又は全部を周期的に待機系に送信するため、入力されたストリームデータにすべてのクエリを適用する必要がなく、迅速に障害から回復させることができる。
１００ ネットワーク
１１０、１４０ 計算機
１１１、１４１ プロセッサ
１１２、１４２ メモリ
１１３、１４３ 通信インタフェース
１１４、１４４ ディスクインタフェース
１１５、１４５ ハードディスク装置
１１６、１４６ クエリ定義ファイル
１１７、１４７ クエリグループ定義ファイル
１２０、１５０ ストリーム処理部
１２１、１５１ データ受信部
１２２、１５２ データ送信部
１２３、１５３ 主制御部
１２４、１５４ 入力データ制御部
１２５、１５５ タプル管理テーブル
１２６、１５６ クエリ処理部
１２７、１５７ 入力ストリーム保存管理部
１２８、１５８ コピー容量管理テーブル
１２９、１５９ 定義ファイル解析制御部
１３０、１６０ メモリコピー制御部
１３１、１６１ メモリ送受信制御部
１３２、１６２ ハートビート送受信部
１９０ データ送信クライアント
１９１ データ受信クライアント
９０１ メモリコピー状態管理
９１１、９１２、９１３ インターバルグループ
９２１、９２２ データ入力グループ

Claims (14)

  1. 時刻情報が付与されたデータを時系列順に受信し、前記受信したデータをあらかじめ登録された複数のクエリによって処理する計算機システムにおける障害回復方法であって、
    前記計算機システムには、複数の計算機が含まれ、
    前記各計算機は、前記データを受信するインタフェースと、前記インタフェースを介して受信したデータを記憶する記憶部と、前記記憶部に記憶されたデータを処理するプロセッサと、を備え、
    前記複数の計算機には、前記受信したデータを前記複数のクエリによって処理した結果を出力する第１の計算機と、前記第１の計算機に障害が発生した場合に前記第１の計算機に替わって前記受信したデータを処理する第２の計算機とが含まれ、
    前記複数のクエリには、前記受信したデータを処理する順序があらかじめ定義され、
    前記方法は、
    前記第１の計算機及び前記第２の計算機が、前記データをそれぞれ受信し、
    前記第１の計算機が、前記あらかじめ定義された順序に従って、順次、前記クエリによって前記受信したデータを処理し、
    前記第１の計算機が、前記受信したデータの前記クエリごとの処理結果を、中間データとして前記第１の計算機の記憶部に記憶し、
    前記第１の計算機が、所定のタイミングで、前記複数のクエリの一部のクエリに対応する中間データを前記第２の計算機に送信し、
    前記第２の計算機が、前記第１の計算機から送信された中間データを前記第２の計算機の記憶部に記憶し、
    前記第１の計算機に障害が発生した場合には、前記第２の計算機が、前記第２の計算機が受信したデータ及び前記第１の計算機から送信された中間データを処理することによって、前記第１の計算機の記憶部に格納されたデータを前記第２の計算機の記憶部に復元することを特徴とする障害回復方法。
  2. 前記計算機システムには、少なくとも一つのクエリを含むクエリグループが定義され、
    前記方法は、前記第１の計算機が、前記クエリグループごとに前記中間データを前記第２の計算機に送信することを特徴とする請求項１に記載の障害回復方法。
  3. 前記クエリグループは、前記複数のクエリに含まれるいずれか一つのクエリが対応し、
    前記クエリグループには、前記対応するクエリと、前記対応するクエリの後に実行されるクエリが含まれることを特徴とする請求項２に記載の障害回復方法。
  4. 前記方法は、前記第１の計算機が、前記クエリグループに対応するクエリが実行される順序に基づいて、前記中間データを前記第２の計算機に送信することを特徴とする請求項３に記載の障害回復方法。
  5. 前記複数のクエリに含まれるすべてのクエリに対応するクエリグループが定義されることを特徴とする請求項３に記載の障害回復方法。
  6. 前記計算機システムには、複数のクエリグループが定義され、
    前記複数のクエリグループには、前記複数のクエリをすべて含むクエリグループが含まれ、
    前記方法は、前記第２の計算機が、前記複数のクエリをすべて含むクエリグループに対応する中間データを受信した場合には、前記第２の計算機が受信したデータを削除することを特徴とする請求項２に記載の障害回復方法。
  7. 前記方法は、前記第１の計算機が、前記所定のタイミングとして、周期的に、前記中間データを前記第２の計算機に送信することを特徴とする請求項１に記載の障害回復方法。
  8. 前記方法は、前記第１の計算機が、前記所定のタイミングとして、前記クエリが前記受信したデータを処理した数が所定の閾値を超えた場合に、前記中間データを前記第２の計算機に送信することを特徴とする請求項１に記載の障害回復方法。
  9. 前記方法は、
    前記第１の計算機が、第１の所定の間隔で正常に稼働していることを通知するために、前記第２の計算機と通信し、
    前記第２の計算機が、前記第１の所定の間隔よりも長い第２の所定の間隔で前記第１の計算機と通信できなかった場合には、前記第１の計算機に障害が発生したと判定することを特徴とする請求項１に記載の障害回復方法。
  10. 前記記憶部には、前記クエリごとに作成されたタプル管理情報が格納され、
    前記タプル管理情報には、当該タプル管理情報に対応するクエリが処理した最新のデータに付与された時刻情報である入力データ最新時刻が記録され、
    前記方法は、
    前記第１の計算機が、前記第１の計算機の記憶部に格納された前記タプル管理情報を、前記中間データとともに前記第２の計算機に送信し、
    前記第２の計算機が、前記受信したデータに付与された時刻情報と前記入力データ最新時刻とを比較し、
    前記受信したデータに付与された時刻情報が前記入力データ最新時刻よりも新しい場合には、前記入力データ最新時刻を前記受信したデータに付与された時刻情報に更新することを特徴とする請求項１に記載の障害回復方法。
  11. 複数の計算機を含み、時刻情報が付与されたデータを時系列順に受信し、前記受信したデータをあらかじめ登録された複数のクエリによって処理する計算機システムであって、
    前記各計算機は、前記データを受信するインタフェースと、前記インタフェースを介して受信したデータを記憶する記憶部と、前記記憶部に記憶されたデータを処理するプロセッサと、を備え、
    前記複数の計算機には、前記受信したデータを前記複数のクエリによって処理した結果を出力する第１の計算機と、前記第１の計算機に障害が発生した場合に前記第１の計算機に替わって前記受信したデータを処理する第２の計算機とが含まれ、
    前記複数のクエリには、前記受信したデータを処理する順序があらかじめ定義され、
    前記第１の計算機及び前記第２の計算機は、前記データをそれぞれ受信し、
    前記第１の計算機は、
    前記あらかじめ定義された順序に従って、順次、前記クエリによって前記受信したデータを処理し、
    前記受信したデータの前記クエリごとの処理結果を、中間データとして前記第１の計算機の記憶部に記憶し、
    所定のタイミングで、前記複数のクエリの一部のクエリに対応する中間データを前記第２の計算機に送信し、
    前記第２の計算機は、
    前記第１の計算機から送信された中間データを前記第２の計算機の記憶部に記憶し、
    前記第１の計算機に障害が発生した場合には、前記第２の計算機が受信したデータ及び前記第１の計算機から送信された中間データを処理することによって、前記第１の計算機の記憶部に格納されたデータを前記第２の計算機の記憶部に復元することを特徴とする計算機システム。
  12. 前記第１の計算機は、少なくとも一つのクエリを含むように定義されたクエリグループごとに、前記中間データを前記第２の計算機に送信することを特徴とする請求項１１に記載の計算機システム。
  13. 時刻情報が付与されたデータを時系列順に受信し、あらかじめ登録された複数のクエリによって処理する計算機システムに含まれる計算機で実行されるプログラムであって、
    前記データを受信する手順と、
    前記クエリによって前記受信したデータを、あらかじめ定義された順序に従って処理する手順と、
    前記各クエリによって前記受信したデータを処理した結果を中間データとして記憶する手順と、
    前記複数のクエリの一部のクエリに対応する中間データを、所定のタイミングで、前記クエリごとに送信する手順と、
    前記中間データを受信する手順と、
    前記中間データを送信した計算機に障害が発生した場合に、前記受信したデータ及び前記受信した中間データを処理することによって、前記中間データを送信した計算機に格納されたデータを復元する手順と、を含むことを特徴とする障害回復プログラム。
  14. 前記中間データを送信する手順は、少なくとも一つのクエリを含むように定義されたクエリグループごとに、前記中間データを送信することを特徴とする請求項１３に記載の障害回復プログラム。
JP2009060783A 2009-03-13 2009-03-13 ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム Expired - Fee Related JP4870183B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009060783A JP4870183B2 (ja) 2009-03-13 2009-03-13 ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム
US12/644,973 US8369207B2 (en) 2009-03-13 2009-12-22 Failure recovery method, computer system, and storage medium recorded failure recovery program for a stream data processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009060783A JP4870183B2 (ja) 2009-03-13 2009-03-13 ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム

Publications (2)

Publication Number Publication Date
JP2010217968A true JP2010217968A (ja) 2010-09-30
JP4870183B2 JP4870183B2 (ja) 2012-02-08

Family

ID=42730623

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009060783A Expired - Fee Related JP4870183B2 (ja) 2009-03-13 2009-03-13 ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム

Country Status (2)

Country Link
US (1) US8369207B2 (ja)
JP (1) JP4870183B2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012059976A1 (ja) * 2010-11-02 2012-05-10 株式会社日立製作所 プログラム、ストリームデータ処理方法及びストリームデータ処理計算機
WO2013072975A1 (ja) * 2011-11-18 2013-05-23 株式会社日立製作所 計算機システム、情報処理方法及びプログラム
WO2016035128A1 (ja) * 2014-09-02 2016-03-10 株式会社日立製作所 ストリームデータ処理システム及び処理方法
JP2016528616A (ja) * 2013-07-22 2016-09-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ セカンダリ・コンピュータ中のメモリ・エラーに応じたプライマリ・コンピュータ中のオブジェクトの移動
WO2018002976A1 (ja) * 2016-06-27 2018-01-04 株式会社日立製作所 管理装置、実行環境設定方法、ストリームデータ処理システム
US9984134B2 (en) 2013-12-13 2018-05-29 International Business Machines Corporation Extraction device, data processing system, and extraction method

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8880493B2 (en) * 2011-09-28 2014-11-04 Hewlett-Packard Development Company, L.P. Multi-streams analytics
US20140261995A1 (en) 2013-03-15 2014-09-18 Logitech Europe S.A. Systems and methods for imprinting font on a key cap
US9654538B1 (en) * 2013-03-11 2017-05-16 DataTorrent, Inc. Dynamic partitioning of instances in distributed streaming platform for real-time applications
US9122651B1 (en) * 2014-06-06 2015-09-01 Sas Institute Inc. Computer system to support failover in an event stream processing system
US20180268001A1 (en) * 2017-03-16 2018-09-20 International Business Machines Corporation Managing a database management system using a set of stream computing data
US11037168B1 (en) 2019-12-20 2021-06-15 Capital One Services, Llc Transaction exchange platform with watchdog microservice
US11023528B1 (en) 2019-12-20 2021-06-01 Capital One Services, Llc Transaction exchange platform having configurable microservices
US10891615B1 (en) 2019-12-20 2021-01-12 Capital One Services, Llc Transaction exchange platform having streaming transaction data and microservices
US11080120B2 (en) 2019-12-20 2021-08-03 Capital One Services, Llc Transaction exchange platform with watchdog microservice
US10789600B1 (en) * 2019-12-20 2020-09-29 Capital One Services, Llc Transaction exchange platform with snapshot microservice
US11341006B1 (en) * 2020-10-30 2022-05-24 International Business Machines Corporation Dynamic replacement of degrading processing elements in streaming applications

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07262069A (ja) * 1994-03-17 1995-10-13 Hitachi Ltd 障害回復方法
JP2006338432A (ja) * 2005-06-03 2006-12-14 Hitachi Ltd ストリームデータ処理システムのクエリ処理方法
JP2007026373A (ja) * 2005-07-21 2007-02-01 Hitachi Ltd ストリームデータ処理システムおよびストリームデータ処理方法
JP2007241323A (ja) * 2004-05-11 2007-09-20 Nippon Telegr & Teleph Corp <Ntt> 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044216A (en) * 1996-06-24 2000-03-28 Oracle Corporation Method and apparatus for implementing cursor variables for accessing data from database
US6122754A (en) * 1998-05-22 2000-09-19 International Business Machines Corporation Method and system for data recovery using a distributed and scalable data structure
US6347322B1 (en) * 1998-11-09 2002-02-12 Lucent Technologies Inc. Transaction state data replication by transaction forwarding in replicated database systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07262069A (ja) * 1994-03-17 1995-10-13 Hitachi Ltd 障害回復方法
JP2007241323A (ja) * 2004-05-11 2007-09-20 Nippon Telegr & Teleph Corp <Ntt> 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム
JP2006338432A (ja) * 2005-06-03 2006-12-14 Hitachi Ltd ストリームデータ処理システムのクエリ処理方法
JP2007026373A (ja) * 2005-07-21 2007-02-01 Hitachi Ltd ストリームデータ処理システムおよびストリームデータ処理方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012059976A1 (ja) * 2010-11-02 2012-05-10 株式会社日立製作所 プログラム、ストリームデータ処理方法及びストリームデータ処理計算機
JP5472885B2 (ja) * 2010-11-02 2014-04-16 株式会社日立製作所 プログラム、ストリームデータ処理方法及びストリームデータ処理計算機
WO2013072975A1 (ja) * 2011-11-18 2013-05-23 株式会社日立製作所 計算機システム、情報処理方法及びプログラム
JP2016528616A (ja) * 2013-07-22 2016-09-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ セカンダリ・コンピュータ中のメモリ・エラーに応じたプライマリ・コンピュータ中のオブジェクトの移動
US9984134B2 (en) 2013-12-13 2018-05-29 International Business Machines Corporation Extraction device, data processing system, and extraction method
US10089370B2 (en) 2013-12-13 2018-10-02 International Business Machines Corporation Extraction device, data processing system, and extraction method
WO2016035128A1 (ja) * 2014-09-02 2016-03-10 株式会社日立製作所 ストリームデータ処理システム及び処理方法
JPWO2016035128A1 (ja) * 2014-09-02 2017-04-27 株式会社日立製作所 ストリームデータ処理システム及び処理方法
WO2018002976A1 (ja) * 2016-06-27 2018-01-04 株式会社日立製作所 管理装置、実行環境設定方法、ストリームデータ処理システム
JPWO2018002976A1 (ja) * 2016-06-27 2019-04-11 株式会社日立製作所 管理装置、実行環境設定方法、ストリームデータ処理システム

Also Published As

Publication number Publication date
JP4870183B2 (ja) 2012-02-08
US8369207B2 (en) 2013-02-05
US20100232286A1 (en) 2010-09-16

Similar Documents

Publication Publication Date Title
JP4870183B2 (ja) ストリームデータ処理システムにおける障害回復方法、計算機システム及び障害回復プログラム
US9916201B2 (en) Write performance in fault-tolerant clustered storage systems
EP2062139B1 (en) Method for improving transfer of event logs for replication of executing programs
US8868492B2 (en) Method for maximizing throughput and minimizing transactions response times on the primary system in the presence of a zero data loss standby replica
US10942823B2 (en) Transaction processing system, recovery subsystem and method for operating a recovery subsystem
JP5075736B2 (ja) 仮想サーバのシステム障害回復方法及びそのシステム
JP5308403B2 (ja) データ処理の障害回復方法、システムおよびプログラム
US10459805B2 (en) Method and system for data recovery in a data system
CN107430606B (zh) 具有并行持久性的消息代理系统
US20040193583A1 (en) Method and database system for duplicating transactions between remote sites
US20100229047A1 (en) Method for displaying pair state of copy pairs
JP5686034B2 (ja) クラスタシステム、同期制御方法、サーバ装置および同期制御プログラム
US9798639B2 (en) Failover system and method replicating client message to backup server from primary server
US20180101558A1 (en) Log-shipping data replication with early log record fetching
US8527454B2 (en) Data replication using a shared resource
US20130332507A1 (en) Highly available servers
JP4289056B2 (ja) 計算機システム間のデータ二重化制御方法
Wang et al. A comprehensive study on fault tolerance in stream processing systems
Gog et al. Falkirk wheel: Rollback recovery for dataflow systems
JP2014038564A (ja) データベースに対する処理を行うシステム及び方法
JP6056408B2 (ja) フォールトトレラントシステム
JP2010244117A (ja) レプリケーションシステム、マスタサーバ、レプリカサーバ、レプリケーション方法、及びプログラム
Jiang et al. Lightweight live migration for high availability cluster service
Wang et al. Fast log replication in highly available data store
US20220308921A1 (en) Non-transitory computer-readable storage medium, information processing system, and data processing method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110223

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110726

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110922

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111018

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111116

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141125

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees