ストリーム回復方法、ストリーム回復プログラム、および、障害回復装置
【課題】ストリーム処理システムの効率的な障害対策を実施すること。
【解決手段】入力ストリーム１６は、クエリ処理の対象であるデータタプルと、そのデータタプルのストリームデータ内における位置を示す回復ポイントタプル６１と、を含めて構成され、計算機２１は、計算機３１に発生する障害を検知すると、ストリーム処理装置のクエリ処理が済んだデータタプルの位置を示す、ストリームデータ内における位置情報を回復ポイント６２から読み取り、その回復ポイント６２のうちの最も後に位置する回復ポイント６２を入力ストリーム１６内の再投入位置とし、その再投入位置を起点とする入力ストリーム１６を、計算機３１に再投入する旨をストリーム配信装置に指示することを特徴とする。
【解決手段】入力ストリーム１６は、クエリ処理の対象であるデータタプルと、そのデータタプルのストリームデータ内における位置を示す回復ポイントタプル６１と、を含めて構成され、計算機２１は、計算機３１に発生する障害を検知すると、ストリーム処理装置のクエリ処理が済んだデータタプルの位置を示す、ストリームデータ内における位置情報を回復ポイント６２から読み取り、その回復ポイント６２のうちの最も後に位置する回復ポイント６２を入力ストリーム１６内の再投入位置とし、その再投入位置を起点とする入力ストリーム１６を、計算機３１に再投入する旨をストリーム配信装置に指示することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーム回復方法、ストリーム回復プログラム、および、障害回復装置の技術に関する。
【背景技術】
【０００２】
ストリーム処理システムは、無限に到来する時刻順データ系列であるストリームデータを処理する機能を持つデータ処理システムである。ストリーム処理システムは、多量のストリームデータをメモリ上でリアルタイム処理（選択、射影、結合、集合演算、集計、…）する機能を持つ。ストリーム処理システムではリアルタイム処理するために、必要なデータをメモリ上で管理している。そのため障害が発生した場合、メモリ上に展開しているデータは消失してしまう可能性がある。
【０００３】
このようなメモリ上にデータを保持するシステムで障害が発生した場合、大きく分けて二つの障害回復方法が考えられる。一つは、ある計算機に障害が発生した場合でも即座に動作できるように、複数のシステムを並列化して冗長性を上げ、信頼性を向上する方法。もう一つは単体のシステムに、障害回復機能を持たせ、回復する方法である。前者の方が信頼性、可用性は高いがコストも高くなるというデメリットもある。
【０００４】
また、ストリーム処理システムと同様に、性能向上を目的としてメモリ上にデータを置くシステムとしてインメモリデータベースがある。インメモリデータベースでは、メモリが消滅するとデータベースが消えてしまうため、一定期間ごとにデータベース内容のスナップショットを取得し、それ以降は更新ジャーナルを保存することで障害回復を行っている（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２００１１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術のように、メモリ上のデータに対しスナップショットを取る方法をストリーム処理システムに適用した場合、データの入出力が多いために、処理が遅くなることが考えられる。また、ストリーム処理システムを並列化する方法もあるが、信頼性、可用性が上がる代わりに、コストも押し上げられることになる。
【０００７】
一方でストリーム処理システムはインメモリデータベースと異なり、データベースをメモリ上に保持し続けるわけではなく、処理に必要な入力データと編集データを一定期間だけ保持している。そのため、ストリーム処理システムが障害によりデータを消失した場合、処理に必要となる一定期間の入力ストリームバックアップからストリームデータを再投入する方法で、ストリーム処理システムを回復可能である。
【０００８】
しかし、入力ストリームバックアップからストリームデータを再投入する方法では、いつからどれだけの量を再投入すべきか分からないため、入力ストリームバックアップに格納されている全てのストリームデータを再投入することになり、既に処理したストリームデータを再び処理することになり、非効率である。
【０００９】
そこで、本発明は、前記した問題を解決し、ストリーム処理システムの効率的な障害対策を実施することを、主な目的とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するために、本発明は、ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムによるストリーム回復方法であって、
前記ストリームデータが、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置が、
前記データタプルをクエリ処理するとともに、前記回復ポイントタプルをクエリ処理から除外して一時的にバッファにプールし、前記データタプルが前記ストリーム処理装置内で削除指示されると、その削除指示対象の前記データタプルより前に位置する前記回復ポイントタプルを前記バッファから読み取って、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、記憶手段に書き出し、
前記障害回復装置が、
前記ストリーム処理装置に発生する障害を検知すると、前記記憶手段から前記ストリームデータ内における位置情報を読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１１】
本発明によれば、ストリーム処理システムの効率的な障害対策を実施することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に関するストリーム処理システムを示す構成図である。
【図２】本発明の一実施形態に関するストリームデータの受信側が回復ポイントタプル６１を追加する形態を示す説明図である。
【図３】本発明の一実施形態に関するストリームデータの送信側が回復ポイントタプル６１を追加する形態を示す説明図である。
【図４】本発明の一実施形態に関するクエリ処理部４５の回復ポイントタプル６１の処理の流れを示す説明図である。
【図５】本発明の一実施形態に関するストリーム処理システムの各データ構造を示す構成図である。
【図６】本発明の一実施形態に関するストリームデータ処理部４１での、通常運用時における回復ポイントタプル６１の生成から消滅までの処理を示すフローチャートである。
【図７】本発明の一実施形態に関する図６のフローチャートの処理を示す説明図である。
【図８】本発明の一実施形態に関するストリームデータ処理部４１が実行する、Ｓ１０２（回復ポイントタプル６１の追加処理）の詳細を示すフローチャートである。
【図９】本発明の一実施形態に関するクエリ処理部４５が実行する、Ｓ１０３（回復ポイントタプル６１の受信処理）の詳細を示すフローチャートである。
【図１０】本発明の一実施形態に関するＳ２０２における回復ポイントタプル６１の追加条件の一例を示す説明図である。
【図１１】本発明の一実施形態に関するクエリ処理部４５が実行する、Ｓ１０４（回復ポイントタプル６１の出力処理）の詳細を示すフローチャートである。
【図１２】本発明の一実施形態に関するストリームデータ送信部４３が実行する、Ｓ１０５（回復ポイントタプル６１の削除処理）の詳細を示すフローチャートである。
【図１３】本発明の一実施形態に関するＳ５０５の整合性の判定処理の一例を示す説明図である。
【図１４】本発明の一実施形態に関するストリームサーバ回復処理部２６が実行する、障害発生時の入力ストリーム１６の回復処理を示すフローチャートである。
【図１５】本発明の一実施形態に関する図１４のフローチャートの処理を示す説明図である。
【発明を実施するための形態】
【００１３】
以下、図面を用いて、本発明の一実施形態を説明する。
【００１４】
図１は、ストリーム処理システムを示す構成図である。ストリーム処理システムは、計算機１１と、計算機２１と、計算機３１と、計算機５１とを含めて構成される。ネットワーク８は、計算機１１と、計算機２１と、計算機３１と、を接続する。ネットワーク９は、計算機３１と、計算機５１と、を接続する。
計算機１１は、ストリームデータを計算機３１に送信する。計算機２１は、計算機１１から送信されるストリームデータのバックアップを行うとともに、そのバックアップを用いて、障害時に失われるストリームの回復処理を実行する。計算機３１は、計算機１１から送信されるストリームデータのクエリ処理を行うとともに、そのストリームデータを計算機５１へと転送する。計算機５１は、計算機３１から送信されるストリームデータおよび計算機３１でのクエリ処理結果を受信し、それらのデータをもとに、業務アプリケーションを実行する。
【００１５】
計算機１１は、メモリ１２、ＣＰＵ１４、および、ｄｉｓｋ１５を有する。メモリ１２上には、ストリームデータを送信するためのアプリケーション実行部１３、および回復ポイントタプル６１（詳細は、図５（ａ）参照）の追加位置をアプリケーション実行部１３で指定するための回復ポイント指定処理部１７を有する。
計算機２１は、メモリ２２、ＣＰＵ２４、および、入力ストリームバックアップ２５を有する。メモリ２２上には、ストリームサーバの状態を監視するためのストリームサーバ監視処理部２３、ストリームサーバ回復処理を行うためのストリームサーバ回復処理部２６を有する。また、入力ストリームバックアップ２５は、フラッシュメモリなど不揮発性の記憶装置により構成してもよい。
【００１６】
計算機３１は、メモリ３２、ＣＰＵ３４、および、ｄｉｓｋ３５を有する。メモリ３２上には、オペレーティングシステム３３が動作し、そのオペレーティングシステム３３上でストリームデータ処理部４１が動作する。ストリームデータ処理部４１は、ストリームデータ受信部４２、ストリームデータ送信部４３、制御部４４、クエリ処理部４５、および、回復ポイント管理部４６を有する。回復ポイント管理部４６は、管理テーブル４７を含む。クエリ処理部４５は、ＣＱＬ（Continuous Query Language）などで記載された、ストリームデータを対象とする処理内容を実行する。
計算機５１は、メモリ５２、ＣＰＵ５４、および、ｄｉｓｋ５５を有する。メモリ５２上には、ストリームデータ処理部４１で処理されたデータを受信するアプリケーション実行部５３を有する。
【００１７】
以上説明した図１のストリーム処理システムでは、計算機３１上での障害により失われてしまったストリームデータを、計算機２１が入力ストリームバックアップ２５から読み出して再投入する。このとき、計算機３１の障害発生時より前の時間帯では、既に一部のストリームデータが計算機３１上ですでに処理されている。よって、計算機２１は、入力ストリームバックアップ２５のストリームデータのうち、計算機３１によってまだ処理されていない部分のストリームデータを選択して、計算機３１に再投入する。これにより、計算機３１は、同じストリームデータを重複して処理する必要が無くなるため、入力ストリームバックアップ２５のストリームデータを全て再投入する方式にくらべ、障害回復時の処理効率を高めることができる。
【００１８】
このような高効率の再投入処理を実現するために、入力ストリームバックアップ２５のストリームデータのうち、再投入をするストリームデータの位置を選択するための手がかりが必要になる。本実施形態では、その手がかりとして、回復ポイントタプル６１を用いる。回復ポイントタプル６１は、ストリームデータを構成するタプルの一種であるため、ストリームデータのデータタプルとともに、送信される。しかし、回復ポイントタプル６１は、ストリームデータのデータ内容とは関係なく、障害回復の制御用のタプルであるため、クエリ処理部４５の演算に関与せず、分岐はすべて分岐し、追い越しなどは行わない。
【００１９】
本実施形態では、回復ポイントタプル６１をストリームデータに追加する処理について、ストリームデータの受信側（計算機３１のストリームデータ受信部４２）が追加する形態（図２参照）と、ストリームデータの送信側（計算機１１の回復ポイント指定処理部１７）が追加する形態（図３参照）と、をそれぞれ挙げる。
【００２０】
図２は、ストリームデータの受信側が回復ポイントタプル６１を追加する形態を示す説明図である。本実施形態では、入力ストリームバックアップ２５などに存在するストリームデータの表記について、そのストリームデータを構成する各タプル（データタプル、回復ポイントタプル６１など）を矩形で示し、古いデータを右側に、新しいデータを左側に示す（図面内の矢印を参照）。
【００２１】
まず、図２（ａ）では、通常運用時の回復ポイントタプル６１の追加処理を示す。
ストリームデータ受信部４２は、アプリケーション実行部１３から送信されるストリームデータに対して、回復ポイントタプル６１の追加条件を満たすときに、回復ポイントタプル６１を追加する。追加条件は、例えば、「１０００タプルごとに追加」および「３０分ごとに追加」などが挙げられる。
回復ポイント管理部４６は、回復ポイントタプル６１がストリームデータ処理部４１から出力される時点を回復ポイント６２（詳細は、図５（ｃ）参照）とし、その回復ポイント６２をｄｉｓｋ３５内の不揮発性のファイルとして出力する。つまり、回復ポイント６２は、入力ストリームバックアップ２５のストリームデータのうちの再投入するストリームデータの位置を示す。
【００２２】
次に、図２（ｂ）は、障害発生時の回復ポイントタプル６１の利用処理を示す。
ストリームサーバ回復処理部２６は、ストリーム処理システムダウンを検知すると、ｄｉｓｋ３５から最新の回復ポイント６２（例えば、「１０：５２．１２」）を読み取る。
そして、ストリームサーバ回復処理部２６は、その最新の回復ポイント６２に該当する入力ストリームバックアップ２５のタプルを検索し、その検索結果として見つかったタプル（再投入ポイント）より新しいタプルを、ストリームデータ処理部４１に再投入する。これにより、障害回復が可能となる。
なお、回復ポイントタプル６１の追加条件にタプル数が指定されている場合、システム回復時に使用するタプル数を計算できるため、システム回復時間を見積もることができるようになる。
また、回復ポイントタプル６１の追加条件に時間が指定されている場合、システムを指定時間まで回復させることができる。これは、ログ解析や音声解析などのあらかじめシステムに投入するデータ持つ場合、つまりリアルタイムに情報の解析でない場合に、入力タプル量などを計算することなく回復ポイントを決定できる利点がある。
【００２３】
図３は、ストリームデータの送信側が回復ポイントタプル６１を追加する形態を示す説明図である。
まず、図３（ａ）では、通常運用時の回復ポイントタプル６１の追加処理を示す。図２（ａ）との違いは、回復ポイントタプル６１を追加する処理の主体が、計算機３１のストリームデータ受信部４２から、計算機１１の回復ポイント指定処理部１７へと置き換わっている点である。
このように、ストリームデータの送信側で回復ポイントタプル６１を追加する形態は、ストリームデータを構成するデータタプルの意味情報を、回復ポイントタプル６１の追加位置に反映させるときに、特に有効である。
例えば、図３（ａ）では、１つのストリームデータを構成する各データタプルが、３つのタプル群（Ａ，Ｂ，Ｃ）に分類されている。アプリケーション実行部１３は、ユーザから、データタプルの意味情報（タプル群の生成に要する情報）の入力を受け付ける。アプリケーション実行部１３は、回復ポイント指定処理部１７を呼び出すときに、データタプルの意味情報を併せて回復ポイント指定処理部１７に通知する。回復ポイント指定処理部１７は、データタプルの意味情報を参照して、タプル群を区切る位置に回復ポイントタプル６１を挿入する。これにより、ユーザの意図する箇所に回復ポイント６２を設定することが可能となる。
なお、データタプルの意味情報としては、例えば、文字列のストリームデータにおける文法情報（段落単位、文単位、文節単位など）、ラジオ放送やテレビ放送のストリームデータにおける番組情報（番組単位、シーン単位など）、および、数値解析用データのストリームデータにおける構造情報（投資用情報では、会社単位など）が、一例としてあげられる。
【００２４】
次に、図３（ｂ）は、障害発生時の回復ポイントタプル６１の利用処理を示す。図３（ｂ）は、図２（ｂ）と同様である。ストリームサーバ回復処理部２６は、例えば、タプル群Ｂ，Ｃ間の回復ポイントタプル６１が通知された回復ポイント６２の時刻（１１：１０．１０）が、最新の回復ポイント６２であるので、その回復ポイント６２以降のタプル（タプル群Ｂ，Ａ）を再投入の対象とする。
【００２５】
図４は、クエリ処理部４５の回復ポイントタプル６１の処理の流れを示す説明図である。
【００２６】
図４（ａ）では、クエリ処理部４５は、ストリームデータのデータタプル（３番以外のタプル）をクエリ演算処理の対象とするが、ストリームデータの回復ポイントタプル６１（３番のタプル）をクエリ演算処理の対象からは除外する。そして、クエリ処理部４５は、入力された回復ポイントタプル６１を、図４（ｃ）で出力するまで一時的にバッファ（キューなど）に貯めておく。
【００２７】
図４（ｂ）では、クエリ処理部４５ａからクエリ処理部４５ｂおよびクエリ処理部４５ｃへ分岐している場合を示す。クエリ処理部４５ａは、回復ポイントタプル６１（７番のタプル）の出力先が分岐しているときには、それぞれの分岐先に回復ポイントタプル６１を複製して出力する。分岐先のクエリ処理部４５ｂおよびクエリ処理部４５ｃは、それぞれクエリ処理部４５ａから出力された回復ポイントタプル６１（３番のタプル）をクエリ演算処理の対象からは除外する。
【００２８】
図４（ｃ）は、クエリ処理部４５の回復ポイントタプル６１の出力処理を示す。クエリ処理部４５は、データタプルの消滅タプル（４番タプルの消滅指示が記載されている）が入力された場合に、その消滅タプルより前に存在する回復ポイントタプル６１（例えば、３番のタプル）を、制御部４４ｂへ出力する。
つまり、制御部４４が発行する消滅タプルには、クエリ処理部４５内で生存期間の過ぎたタプルに対し、該当タプルをクエリ処理部４５から消滅させる旨の制御指示が記載されている。制御部４４は、消滅タプルは、クエリ演算処理において、データタプルが不要になると、そのデータタプルを消滅させるための消滅タプルを発行する。
これにより、クエリ処理部４５は３番の回復ポイントタプル６１が出力された時点で、３番の回復ポイントタプル６１以前に存在した、１番や２番のデータタプルについては、すべてクエリ処理部４５からは出力されているものと判断できる。
【００２９】
図５（ａ）は、回復ポイントタプル６１を示す構成図である。この図５（ａ）の表の１行（１レコード）が、１つの回復ポイントタプル６１を示す。回復ポイントタプル６１は、時刻と、データ（ストリームＩＤ）と、フラグ（タプルの種類）とが対応づけられている。
回復ポイントタプル６１の「時刻」は、ストリームデータ内のデータタプルの位置を特定するためのデータであり、例えば、生成時に付加された時刻（ライブ中継などで配信時刻が特定可能な場合）、ストリームデータ内の相対的な時刻（すでに記録された番組の再生時刻）などが、挙げられる。なお、時刻情報だけでは、ストリームデータ内のデータタプルの位置を一義的に特定できないときには、時刻情報と別の識別情報との組を、データタプルの位置特定用情報として利用すればよい。
回復ポイントタプル６１の「データ（ストリームＩＤ）」は、タプルのデータ格納欄に、ストリームＩＤを格納する旨を示している。ストリームＩＤとは、入力ストリームごとに振られたユニークなＩＤである。この「データ（ストリームＩＤ）」は、クエリ演算処理の対象外であるため、とくに書き換えは発生しない。
回復ポイントタプル６１の「フラグ（タプルの種類）」は、タプルの種類がデータタプルではなく、制御用の回復ポイントタプル６１である旨を示している。
【００３０】
図５（ｂ）は、管理テーブル４７を示す構成図である。管理テーブル４７は、１つの行（１つのレコード）で、１つの回復ポイントタプル６１を管理する。管理テーブル４７は、ストリームＩＤと、時刻と、分岐数と、出力数とを対応づけて管理する。
管理テーブル４７の「ストリームＩＤ」および「時刻」は、図５（ａ）で説明したように、回復ポイントタプル６１の特定情報であり、回復ポイントタプル６１の生成時に登録される。
管理テーブル４７の「分岐数」は、分岐処理が実行された回数を示す。クエリ処理部４５から分岐が発生するたびに通知される分岐通知を受けると、分岐数が初期値「１」から始めて、「１」ずつ増加される。
管理テーブル４７の「出力数」は、含まれるレコードの回復ポイントタプル６１がストリームデータ送信部４３から出力されるたびに、１ずつ増加される。そして、管理テーブル４７の「分岐数」と「出力数」とが同じ値になるレコードは、管理テーブル４７から削除されるとともに、ｄｉｓｋ３５に回復ポイント６２として書き込まれる。
【００３１】
図５（ｃ）は、ｄｉｓｋ３５で格納されている回復ポイント６２を示す構成図である。回復ポイント６２は、入力ストリームごとに振られたユニークＩＤ、回復ポイントタプル生成時に付加された時刻を持つ。回復ポイント６２は、回復ポイント管理部４６から管理テーブル４７に基づいて、ｄｉｓｋ３５に出力される。
回復ポイント６２は、障害発生時に参照される。つまり、図２（ｂ）などで説明したように、障害発生時には、ストリームデータの再投入の位置を特定する必要があるが、回復ポイント６２から該当ストリームをストリームＩＤで検索し、そのストリームＩＤに対応する時刻の内の最新時刻が、ストリームデータの再投入の位置の特定情報として参照される。
【００３２】
図６は、ストリームデータ処理部４１での、通常運用時における回復ポイントタプル６１の生成から消滅までを示すフローチャートである。図７は、図６のフローチャートの処理を示す説明図である。以下、図６および図７を参照して、ストリームデータ処理部４１での、通常運用時の処理を説明する。
【００３３】
ストリームデータ受信部４２は、計算機１１から、入力ストリーム１６のタプル（データタプル、回復ポイントタプル６１など）を受信する（Ｓ１０１）。なお、図７では、入力ストリーム１６が、入力ストリームバックアップ２５へとバックアップされるとともに、ストリームデータ処理部４１へと入力される形態を示した。この形態は、入力ストリーム１６がリアルタイムに生成されるライブ放送などに適した形態である。一方、入力ストリームバックアップ２５内にすでに蓄積されている入力ストリーム１６が、ストリームデータ処理部４１へと入力される形態（オンデマンド配信）としてもよい。
【００３４】
ストリームデータ受信部４２は、入力ストリーム１６のデータタプルの間に回復ポイントタプル６１（６１ａ）を追加（挿入）する（Ｓ１０２）。なお、回復ポイントタプル６１を追加する位置について、例えば、所定の追加条件を満たす位置とする。そして、回復ポイント管理部４６は、ストリームデータ受信部４２から回復ポイントタプル６１の追加通知を受けると、その内容を管理テーブル４７に新規登録する。
【００３５】
ストリームデータ受信部４２は、制御部４４に回復ポイントタプル６１を出力する。クエリ処理部４５ａ，４５ｂは、制御部４４から回復ポイントタプル６１を受信する（Ｓ１０３）。図４（ａ）に示したように、クエリ処理部４５ａ，４５ｂは、回復ポイントタプル６１ｂ、６１ｃをクエリ演算処理の対象とせずに、バッファにプールする。
【００３６】
クエリ処理部４５は、図４（ｃ）に示したように、消滅タプルの受信に伴い、回復ポイントタプル６１を制御部４４に出力する（Ｓ１０４）。回復ポイント管理部４６は、クエリ処理部４５ａ、４５ｂから、回復ポイントタプル６１が出力された旨の通知を受け、管理テーブル４７の情報を更新する。
【００３７】
ストリームデータ送信部４３は、制御部４４から出力された回復ポイントタプル６１を受信し、回復ポイント管理部４６に通知した後、回復ポイントタプル６１を削除する（Ｓ１０５）。回復ポイント管理部４６は、ストリームデータ送信部４３からの通知を受け、管理テーブル４７の「出力数」を１つ増加させる。もし、管理テーブル４７の「分岐数」と「出力数」とが等しくなったときには、回復ポイント管理部４６は、入力ストリームバックアップ２５にある回復ポイントタプル６１ｄ以前のデータはストリームデータ処理部４１から出力されたと判断し、ｄｉｓｋ３５に回復ポイント６２を出力する。
これにより、回復ポイント６２には、Ｓ１０５で削除された回復ポイントタプル６１に関する情報が、追加される。なお、最新の回復ポイント６２が示す時刻より前の時刻のデータタプルは、再投入の対象から除外される。よって、再投入の対象にならないデータタプルを、入力ストリームバックアップ２５から削除することで、入力ストリームバックアップ２５を記憶する記憶装置の空き容量を増やすことができる。
【００３８】
図８は、ストリームデータ処理部４１が実行する、Ｓ１０２（回復ポイントタプル６１の追加処理）の詳細を示すフローチャートである。
【００３９】
Ｓ２０１において、入力された入力ストリーム１６のタプルが、回復ポイントタプル６１か否かを判定する。入力ストリーム１６に回復ポイントタプル６１が含まれている場合は、例えば、図３（ａ）で説明したように、送信側のユーザが回復ポイントタプル６１を明示的に設定した場合が挙げられる。
しかし、送信側のユーザが指定した回復ポイントタプル６１を、受信側で無視する設定がなされている場合には、入力された回復ポイントタプル６１を削除して、Ｓ２０１の処理を次のタプルに対して行うこととしてもよい。
Ｓ２０１でＹＥＳならＳ２０４へ、Ｓ２０１でＮＯならＳ２０２へ、それぞれ移行する。
【００４０】
Ｓ２０２において、回復ポイントタプル６１の追加条件（詳細は、図１０参照）を満たしているか否かを判断する。Ｓ２０２でＹＥＳならＳ２０３へ、Ｓ２０２でＮＯならＳ２０５へ、それぞれ移行する。
Ｓ２０３において、回復ポイントタプル６１を生成して、ストリームデータ受信部４２に追加する。
Ｓ２０４において、回復ポイント管理部４６の管理テーブル４７に、回復ポイントタプル６１の情報（レコード）を追加する。
Ｓ２０５において、ストリームデータ受信部４２にあるタプルを、制御部４４に出力する。
【００４１】
図９は、クエリ処理部４５が実行する、Ｓ１０３（回復ポイントタプル６１の受信処理）の詳細を示すフローチャートである。
Ｓ３０１において、制御部４４からタプルを受信する。
Ｓ３０２において、受信したタプルが回復ポイントタプル６１であるか否かを判定する。Ｓ３０２でＹＥＳならＳ３０３へ、Ｓ３０２でＮＯならＳ３０４へ、それぞれ移行する。
Ｓ３０３において、受信した回復ポイントタプル６１を、クエリ演算処理に関与させずに、バッファにプールする。
Ｓ３０４において、受信したデータタプルに対して、クエリ演算処理を行う。
【００４２】
図１０は、Ｓ２０２における回復ポイントタプル６１の追加条件の一例を示す説明図である。
図１０（ａ）は、所定の入力ストリーム量ごとに回復ポイントタプル６１を追加する条件を示す。これにより、一定の入力ストリーム量ごとに回復ポイントを設定するため、障害時に再投入する入力ストリーム量を簡単に計算できる。再投入量が簡単に計算できるため、それに伴い回復までの時間を見積もることも可能となる。
図１０（ｂ）は、所定時間ごとに回復ポイントタプル６１を追加する条件を示す。これにより、回復時点の時間指定が可能となる。また、ログの解析、音声解析などのように、あらかじめ入力するデータを用意でき、入力量が時間により変動しないデータである場合、指定した時間ごとに回復ポイントを取得できるため、ストリーム処理システムの回復時間を一定にすることが可能となる。
図１０（ｃ）は、ハードウェア負荷の増加などの外部要因を検知して、回復ポイントタプル６１を追加する条件を示す。外部要因としては、ハードウェア（ＣＰＵ、メモリ、Ｉ／Ｏ）などの負荷が「高い」または「低い」場合が挙げられる。
以上、図１０（ａ）〜（ｃ）に示した追加条件は、それぞれ単独で用いてもよいし、組み合わせで用いてもよい。さらに、これらの追加条件は、時間経過にかかわらず、同じ設定を使い続けてもよいし、時間帯やイベント発生などにより、複数の設定を切り替えてもよい。
【００４３】
図１１は、クエリ処理部４５が実行する、Ｓ１０４（回復ポイントタプル６１の出力処理）の詳細を示すフローチャートである。
Ｓ４０１において、制御部４４からタプルを受信する。
Ｓ４０２において、受信したタプルが、消滅タプルか否かを判定する。なお、制御部４４は、クエリ処理部４５内での生存期間を過ぎたタプルを消滅させる指示を記述した消滅タプルを生成して、クエリ処理部４５に適宜通知する。Ｓ４０２でＹＥＳならＳ４０３へ、Ｓ４０２でＮＯなら処理終了へ、それぞれ移行する。
Ｓ４０３において、消滅タプルで消滅を指定されたデータタプルが、Ｓ３０３でプールされている回復ポイントタプル６１より後に受信したデータタプルであるか否かを判断する。Ｓ４０３でＹＥＳならＳ４０４へ、Ｓ４０３でＮＯならＳ４０６へ、それぞれ移行する。
Ｓ４０４において、Ｓ３０３でプールされている回復ポイントタプル６１を、制御部４４に出力する。
Ｓ４０５において、回復ポイント管理部４６に対して、出力する回復ポイントタプル６１の分岐数などの情報を通知する。回復ポイント管理部４６は、通知された分岐数をもとに、管理テーブル４７の出力された回復ポイントタプル６１を示すレコードの「分岐数」を更新する。
Ｓ４０６において、受信した消滅タプルの指示に従い、データタプル（通常タプル）をクエリ処理部４５から削除する。
【００４４】
図１２は、ストリームデータ送信部４３が実行する、Ｓ１０５（回復ポイントタプル６１の削除処理）の詳細を示すフローチャートである。
Ｓ５０１において、制御部４４からタプルを受信する。
Ｓ５０２において、受信したタプルが、回復ポイントタプル６１であるか否かを判定する。Ｓ５０２でＹＥＳならＳ５０３へ、Ｓ５０２でＮＯなら処理終了へ、それぞれ移行する。
Ｓ５０３において、回復ポイントタプル６１が出力されたという情報を、回復ポイント管理部４６に通知する。
Ｓ５０４において、受信した回復ポイントタプル６１を削除する。
【００４５】
Ｓ５０５において、受信した回復ポイントタプル６１の管理テーブル４７における「分岐数」と「出力数」との整合性が取れたか否かを判定する。この判定処理は、所定の回復ポイントタプル６１が次々に分岐して数を増やしていった場合に、その回復ポイントタプル６１を全て出力側で回収できたときに、整合性がとれたものとする。回復ポイントタプル６１の数はクエリ処理部４５の分岐処理などにより増減する可能性があるため、回復ポイントタプル６１の出力の際に、正しい増減結果の数が出力されたか否かの整合性を確認する必要がある。なお、分岐が１回も行われなかった回復ポイントタプル６１については、回復ポイントタプル６１の分岐数および出力数は、ともに「１」となり整合性がとれる。Ｓ５０５でＹＥＳならＳ５０６へ、Ｓ５０５でＮＯならＳ５０８へ、それぞれ移行する。
Ｓ５０６において、回復ポイント６２に記載する回復ポイントタプル６１の情報を、ｄｉｓｋ３５に出力する。
Ｓ５０７において、回復ポイント管理部４６は、Ｓ５０６で出力した回復ポイントタプル６１の情報を、管理テーブル４７から削除する。
Ｓ５０８において、回復ポイント管理部４６の管理テーブル４７の出力数の項目を「１増加する」旨の更新を行う。
【００４６】
図１３は、Ｓ５０５の整合性の判定処理の一例を示す。
図１３（ａ）では、１つの入力された回復ポイントタプル６１が、クエリ処理部４５で１回分岐することにより、２つの出力された回復ポイントタプル６１となる場合を示す。このときには、１つのストリームデータ送信部４３で２回の回復ポイントタプル６１の出力が行われるため、管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
図１３（ｂ）では、１つの入力された回復ポイントタプル６１が、クエリ処理部４５で１回分岐することにより、２つの出力された回復ポイントタプル６１となる場合を示す。このときには、２つのストリームデータ送信部４３でそれぞれ１回の回復ポイントタプル６１の出力が行われるため、管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
【００４７】
図１３（ｃ）では、２つの入力された回復ポイントタプル６１（ユニークＩＤは、互いに異なる）が、クエリ処理部４５でそれぞれ１回ずつ分岐することにより、４つの出力された回復ポイントタプル６１となる場合を示す。このときには、回復ポイントタプル６１の整合性判定は、ユニークＩＤごとに（つまり、２回分）実行される。つまり、２つのストリームデータ送信部４３でそれぞれ２回の回復ポイントタプル６１の出力が行われるため、第１の回復ポイントタプル６１における管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合し、第２の回復ポイントタプル６１における管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
なお、図１３（ｃ）のように回復ポイントタプル６１の種類が多く存在する場合、各回復ポイントタプル６１の最新の回復ポイント６２を抽出し、一番古い回復ポイント６２を再投入時点として採用する。
【００４８】
図１４は、ストリームサーバ回復処理部２６が実行する、障害発生時の入力ストリーム１６の回復処理を示すフローチャートである。図１５は、図１４のフローチャートの処理を示す説明図である。以下、図１４および図１５を参照して、入力ストリーム１６の回復処理を説明する。
Ｓ６０１において、ストリームデータ処理部４１で障害が発生する。
Ｓ６０２において、ストリームサーバ監視処理部２３は、ストリームデータ処理部４１の停止（障害）を検知する。
Ｓ６０３において、Ｓ６０２の検知を受け、ストリームサーバ回復処理部２６を実行する。
Ｓ６０４において、ストリームサーバ回復処理部２６は、ｄｉｓｋ３５から最新の回復ポイント６２を取得する。なお、ｄｉｓｋ３５には、出力済の回復ポイントタプル６１に関する情報が、格納されている。
Ｓ６０５において、ストリームサーバ回復処理部２６は、入力ストリームバックアップ２５から、取得した回復ポイント６２が示す時刻より新しい時刻に対応するデータタプルをストリームデータ処理部４１に入力ストリーム１６として再投入することで、ストリームデータ処理部４１を回復させる。
【００４９】
以上説明した本実施形態によれば、入力ストリームバックアップ２５を使用してストリームデータ処理部４１の障害回復をする場合、入力ストリームバックアップ２５からの再投入するデータタプルの位置を特定することができる。
そのため、回復ポイント指定処理部１７およびストリームデータ受信部４２は、回復ポイントタプル６１を入力ストリーム１６に追加する。そして、ストリームデータ処理部４１から回復ポイントタプル６１が出力される時点で、回復ポイント管理部４６は、ｄｉｓｋ３５に回復ポイント６２を出力する。障害時には、最新の回復ポイント６２が示す時刻位置以降のデータタプルを入力ストリームバックアップ２５から取得して、新しい入力ストリーム１６として再投入することで、ストリームデータ処理部４１を回復できる。
【符号の説明】
【００５０】
８，９ ネットワーク
１１ 計算機（ストリーム配信装置）
２１ 計算機（障害回復装置）
３１ 計算機（ストリーム処理装置）
５１ 計算機
１２，２２，３２，５２ メモリ
１３，５３ アプリケーション実行部
１４，２４，３４，５４ ＣＰＵ
１５，３５，５５ ｄｉｓｋ
１６ 入力ストリーム
１７ 回復ポイント指定処理部
２３ ストリームサーバ監視処理部
２５ 入力ストリームバックアップ
２６ ストリームサーバ回復処理部
３３ オペレーティングシステム
４１ ストリームデータ処理部
４２ ストリームデータ受信部
４３ ストリームデータ送信部
４４ 制御部
４５，４５ａ，４５ｂ，４５ｃ クエリ処理部
４６ 回復ポイント管理部
４７ 管理テーブル
５６ 出力ストリーム
６１，６１ａ，６１ｂ，６１ｃ，６１ｄ 回復ポイントタプル
６２ 回復ポイント
【技術分野】
【０００１】
本発明は、ストリーム回復方法、ストリーム回復プログラム、および、障害回復装置の技術に関する。
【背景技術】
【０００２】
ストリーム処理システムは、無限に到来する時刻順データ系列であるストリームデータを処理する機能を持つデータ処理システムである。ストリーム処理システムは、多量のストリームデータをメモリ上でリアルタイム処理（選択、射影、結合、集合演算、集計、…）する機能を持つ。ストリーム処理システムではリアルタイム処理するために、必要なデータをメモリ上で管理している。そのため障害が発生した場合、メモリ上に展開しているデータは消失してしまう可能性がある。
【０００３】
このようなメモリ上にデータを保持するシステムで障害が発生した場合、大きく分けて二つの障害回復方法が考えられる。一つは、ある計算機に障害が発生した場合でも即座に動作できるように、複数のシステムを並列化して冗長性を上げ、信頼性を向上する方法。もう一つは単体のシステムに、障害回復機能を持たせ、回復する方法である。前者の方が信頼性、可用性は高いがコストも高くなるというデメリットもある。
【０００４】
また、ストリーム処理システムと同様に、性能向上を目的としてメモリ上にデータを置くシステムとしてインメモリデータベースがある。インメモリデータベースでは、メモリが消滅するとデータベースが消えてしまうため、一定期間ごとにデータベース内容のスナップショットを取得し、それ以降は更新ジャーナルを保存することで障害回復を行っている（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２００１１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術のように、メモリ上のデータに対しスナップショットを取る方法をストリーム処理システムに適用した場合、データの入出力が多いために、処理が遅くなることが考えられる。また、ストリーム処理システムを並列化する方法もあるが、信頼性、可用性が上がる代わりに、コストも押し上げられることになる。
【０００７】
一方でストリーム処理システムはインメモリデータベースと異なり、データベースをメモリ上に保持し続けるわけではなく、処理に必要な入力データと編集データを一定期間だけ保持している。そのため、ストリーム処理システムが障害によりデータを消失した場合、処理に必要となる一定期間の入力ストリームバックアップからストリームデータを再投入する方法で、ストリーム処理システムを回復可能である。
【０００８】
しかし、入力ストリームバックアップからストリームデータを再投入する方法では、いつからどれだけの量を再投入すべきか分からないため、入力ストリームバックアップに格納されている全てのストリームデータを再投入することになり、既に処理したストリームデータを再び処理することになり、非効率である。
【０００９】
そこで、本発明は、前記した問題を解決し、ストリーム処理システムの効率的な障害対策を実施することを、主な目的とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するために、本発明は、ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムによるストリーム回復方法であって、
前記ストリームデータが、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置が、
前記データタプルをクエリ処理するとともに、前記回復ポイントタプルをクエリ処理から除外して一時的にバッファにプールし、前記データタプルが前記ストリーム処理装置内で削除指示されると、その削除指示対象の前記データタプルより前に位置する前記回復ポイントタプルを前記バッファから読み取って、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、記憶手段に書き出し、
前記障害回復装置が、
前記ストリーム処理装置に発生する障害を検知すると、前記記憶手段から前記ストリームデータ内における位置情報を読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１１】
本発明によれば、ストリーム処理システムの効率的な障害対策を実施することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に関するストリーム処理システムを示す構成図である。
【図２】本発明の一実施形態に関するストリームデータの受信側が回復ポイントタプル６１を追加する形態を示す説明図である。
【図３】本発明の一実施形態に関するストリームデータの送信側が回復ポイントタプル６１を追加する形態を示す説明図である。
【図４】本発明の一実施形態に関するクエリ処理部４５の回復ポイントタプル６１の処理の流れを示す説明図である。
【図５】本発明の一実施形態に関するストリーム処理システムの各データ構造を示す構成図である。
【図６】本発明の一実施形態に関するストリームデータ処理部４１での、通常運用時における回復ポイントタプル６１の生成から消滅までの処理を示すフローチャートである。
【図７】本発明の一実施形態に関する図６のフローチャートの処理を示す説明図である。
【図８】本発明の一実施形態に関するストリームデータ処理部４１が実行する、Ｓ１０２（回復ポイントタプル６１の追加処理）の詳細を示すフローチャートである。
【図９】本発明の一実施形態に関するクエリ処理部４５が実行する、Ｓ１０３（回復ポイントタプル６１の受信処理）の詳細を示すフローチャートである。
【図１０】本発明の一実施形態に関するＳ２０２における回復ポイントタプル６１の追加条件の一例を示す説明図である。
【図１１】本発明の一実施形態に関するクエリ処理部４５が実行する、Ｓ１０４（回復ポイントタプル６１の出力処理）の詳細を示すフローチャートである。
【図１２】本発明の一実施形態に関するストリームデータ送信部４３が実行する、Ｓ１０５（回復ポイントタプル６１の削除処理）の詳細を示すフローチャートである。
【図１３】本発明の一実施形態に関するＳ５０５の整合性の判定処理の一例を示す説明図である。
【図１４】本発明の一実施形態に関するストリームサーバ回復処理部２６が実行する、障害発生時の入力ストリーム１６の回復処理を示すフローチャートである。
【図１５】本発明の一実施形態に関する図１４のフローチャートの処理を示す説明図である。
【発明を実施するための形態】
【００１３】
以下、図面を用いて、本発明の一実施形態を説明する。
【００１４】
図１は、ストリーム処理システムを示す構成図である。ストリーム処理システムは、計算機１１と、計算機２１と、計算機３１と、計算機５１とを含めて構成される。ネットワーク８は、計算機１１と、計算機２１と、計算機３１と、を接続する。ネットワーク９は、計算機３１と、計算機５１と、を接続する。
計算機１１は、ストリームデータを計算機３１に送信する。計算機２１は、計算機１１から送信されるストリームデータのバックアップを行うとともに、そのバックアップを用いて、障害時に失われるストリームの回復処理を実行する。計算機３１は、計算機１１から送信されるストリームデータのクエリ処理を行うとともに、そのストリームデータを計算機５１へと転送する。計算機５１は、計算機３１から送信されるストリームデータおよび計算機３１でのクエリ処理結果を受信し、それらのデータをもとに、業務アプリケーションを実行する。
【００１５】
計算機１１は、メモリ１２、ＣＰＵ１４、および、ｄｉｓｋ１５を有する。メモリ１２上には、ストリームデータを送信するためのアプリケーション実行部１３、および回復ポイントタプル６１（詳細は、図５（ａ）参照）の追加位置をアプリケーション実行部１３で指定するための回復ポイント指定処理部１７を有する。
計算機２１は、メモリ２２、ＣＰＵ２４、および、入力ストリームバックアップ２５を有する。メモリ２２上には、ストリームサーバの状態を監視するためのストリームサーバ監視処理部２３、ストリームサーバ回復処理を行うためのストリームサーバ回復処理部２６を有する。また、入力ストリームバックアップ２５は、フラッシュメモリなど不揮発性の記憶装置により構成してもよい。
【００１６】
計算機３１は、メモリ３２、ＣＰＵ３４、および、ｄｉｓｋ３５を有する。メモリ３２上には、オペレーティングシステム３３が動作し、そのオペレーティングシステム３３上でストリームデータ処理部４１が動作する。ストリームデータ処理部４１は、ストリームデータ受信部４２、ストリームデータ送信部４３、制御部４４、クエリ処理部４５、および、回復ポイント管理部４６を有する。回復ポイント管理部４６は、管理テーブル４７を含む。クエリ処理部４５は、ＣＱＬ（Continuous Query Language）などで記載された、ストリームデータを対象とする処理内容を実行する。
計算機５１は、メモリ５２、ＣＰＵ５４、および、ｄｉｓｋ５５を有する。メモリ５２上には、ストリームデータ処理部４１で処理されたデータを受信するアプリケーション実行部５３を有する。
【００１７】
以上説明した図１のストリーム処理システムでは、計算機３１上での障害により失われてしまったストリームデータを、計算機２１が入力ストリームバックアップ２５から読み出して再投入する。このとき、計算機３１の障害発生時より前の時間帯では、既に一部のストリームデータが計算機３１上ですでに処理されている。よって、計算機２１は、入力ストリームバックアップ２５のストリームデータのうち、計算機３１によってまだ処理されていない部分のストリームデータを選択して、計算機３１に再投入する。これにより、計算機３１は、同じストリームデータを重複して処理する必要が無くなるため、入力ストリームバックアップ２５のストリームデータを全て再投入する方式にくらべ、障害回復時の処理効率を高めることができる。
【００１８】
このような高効率の再投入処理を実現するために、入力ストリームバックアップ２５のストリームデータのうち、再投入をするストリームデータの位置を選択するための手がかりが必要になる。本実施形態では、その手がかりとして、回復ポイントタプル６１を用いる。回復ポイントタプル６１は、ストリームデータを構成するタプルの一種であるため、ストリームデータのデータタプルとともに、送信される。しかし、回復ポイントタプル６１は、ストリームデータのデータ内容とは関係なく、障害回復の制御用のタプルであるため、クエリ処理部４５の演算に関与せず、分岐はすべて分岐し、追い越しなどは行わない。
【００１９】
本実施形態では、回復ポイントタプル６１をストリームデータに追加する処理について、ストリームデータの受信側（計算機３１のストリームデータ受信部４２）が追加する形態（図２参照）と、ストリームデータの送信側（計算機１１の回復ポイント指定処理部１７）が追加する形態（図３参照）と、をそれぞれ挙げる。
【００２０】
図２は、ストリームデータの受信側が回復ポイントタプル６１を追加する形態を示す説明図である。本実施形態では、入力ストリームバックアップ２５などに存在するストリームデータの表記について、そのストリームデータを構成する各タプル（データタプル、回復ポイントタプル６１など）を矩形で示し、古いデータを右側に、新しいデータを左側に示す（図面内の矢印を参照）。
【００２１】
まず、図２（ａ）では、通常運用時の回復ポイントタプル６１の追加処理を示す。
ストリームデータ受信部４２は、アプリケーション実行部１３から送信されるストリームデータに対して、回復ポイントタプル６１の追加条件を満たすときに、回復ポイントタプル６１を追加する。追加条件は、例えば、「１０００タプルごとに追加」および「３０分ごとに追加」などが挙げられる。
回復ポイント管理部４６は、回復ポイントタプル６１がストリームデータ処理部４１から出力される時点を回復ポイント６２（詳細は、図５（ｃ）参照）とし、その回復ポイント６２をｄｉｓｋ３５内の不揮発性のファイルとして出力する。つまり、回復ポイント６２は、入力ストリームバックアップ２５のストリームデータのうちの再投入するストリームデータの位置を示す。
【００２２】
次に、図２（ｂ）は、障害発生時の回復ポイントタプル６１の利用処理を示す。
ストリームサーバ回復処理部２６は、ストリーム処理システムダウンを検知すると、ｄｉｓｋ３５から最新の回復ポイント６２（例えば、「１０：５２．１２」）を読み取る。
そして、ストリームサーバ回復処理部２６は、その最新の回復ポイント６２に該当する入力ストリームバックアップ２５のタプルを検索し、その検索結果として見つかったタプル（再投入ポイント）より新しいタプルを、ストリームデータ処理部４１に再投入する。これにより、障害回復が可能となる。
なお、回復ポイントタプル６１の追加条件にタプル数が指定されている場合、システム回復時に使用するタプル数を計算できるため、システム回復時間を見積もることができるようになる。
また、回復ポイントタプル６１の追加条件に時間が指定されている場合、システムを指定時間まで回復させることができる。これは、ログ解析や音声解析などのあらかじめシステムに投入するデータ持つ場合、つまりリアルタイムに情報の解析でない場合に、入力タプル量などを計算することなく回復ポイントを決定できる利点がある。
【００２３】
図３は、ストリームデータの送信側が回復ポイントタプル６１を追加する形態を示す説明図である。
まず、図３（ａ）では、通常運用時の回復ポイントタプル６１の追加処理を示す。図２（ａ）との違いは、回復ポイントタプル６１を追加する処理の主体が、計算機３１のストリームデータ受信部４２から、計算機１１の回復ポイント指定処理部１７へと置き換わっている点である。
このように、ストリームデータの送信側で回復ポイントタプル６１を追加する形態は、ストリームデータを構成するデータタプルの意味情報を、回復ポイントタプル６１の追加位置に反映させるときに、特に有効である。
例えば、図３（ａ）では、１つのストリームデータを構成する各データタプルが、３つのタプル群（Ａ，Ｂ，Ｃ）に分類されている。アプリケーション実行部１３は、ユーザから、データタプルの意味情報（タプル群の生成に要する情報）の入力を受け付ける。アプリケーション実行部１３は、回復ポイント指定処理部１７を呼び出すときに、データタプルの意味情報を併せて回復ポイント指定処理部１７に通知する。回復ポイント指定処理部１７は、データタプルの意味情報を参照して、タプル群を区切る位置に回復ポイントタプル６１を挿入する。これにより、ユーザの意図する箇所に回復ポイント６２を設定することが可能となる。
なお、データタプルの意味情報としては、例えば、文字列のストリームデータにおける文法情報（段落単位、文単位、文節単位など）、ラジオ放送やテレビ放送のストリームデータにおける番組情報（番組単位、シーン単位など）、および、数値解析用データのストリームデータにおける構造情報（投資用情報では、会社単位など）が、一例としてあげられる。
【００２４】
次に、図３（ｂ）は、障害発生時の回復ポイントタプル６１の利用処理を示す。図３（ｂ）は、図２（ｂ）と同様である。ストリームサーバ回復処理部２６は、例えば、タプル群Ｂ，Ｃ間の回復ポイントタプル６１が通知された回復ポイント６２の時刻（１１：１０．１０）が、最新の回復ポイント６２であるので、その回復ポイント６２以降のタプル（タプル群Ｂ，Ａ）を再投入の対象とする。
【００２５】
図４は、クエリ処理部４５の回復ポイントタプル６１の処理の流れを示す説明図である。
【００２６】
図４（ａ）では、クエリ処理部４５は、ストリームデータのデータタプル（３番以外のタプル）をクエリ演算処理の対象とするが、ストリームデータの回復ポイントタプル６１（３番のタプル）をクエリ演算処理の対象からは除外する。そして、クエリ処理部４５は、入力された回復ポイントタプル６１を、図４（ｃ）で出力するまで一時的にバッファ（キューなど）に貯めておく。
【００２７】
図４（ｂ）では、クエリ処理部４５ａからクエリ処理部４５ｂおよびクエリ処理部４５ｃへ分岐している場合を示す。クエリ処理部４５ａは、回復ポイントタプル６１（７番のタプル）の出力先が分岐しているときには、それぞれの分岐先に回復ポイントタプル６１を複製して出力する。分岐先のクエリ処理部４５ｂおよびクエリ処理部４５ｃは、それぞれクエリ処理部４５ａから出力された回復ポイントタプル６１（３番のタプル）をクエリ演算処理の対象からは除外する。
【００２８】
図４（ｃ）は、クエリ処理部４５の回復ポイントタプル６１の出力処理を示す。クエリ処理部４５は、データタプルの消滅タプル（４番タプルの消滅指示が記載されている）が入力された場合に、その消滅タプルより前に存在する回復ポイントタプル６１（例えば、３番のタプル）を、制御部４４ｂへ出力する。
つまり、制御部４４が発行する消滅タプルには、クエリ処理部４５内で生存期間の過ぎたタプルに対し、該当タプルをクエリ処理部４５から消滅させる旨の制御指示が記載されている。制御部４４は、消滅タプルは、クエリ演算処理において、データタプルが不要になると、そのデータタプルを消滅させるための消滅タプルを発行する。
これにより、クエリ処理部４５は３番の回復ポイントタプル６１が出力された時点で、３番の回復ポイントタプル６１以前に存在した、１番や２番のデータタプルについては、すべてクエリ処理部４５からは出力されているものと判断できる。
【００２９】
図５（ａ）は、回復ポイントタプル６１を示す構成図である。この図５（ａ）の表の１行（１レコード）が、１つの回復ポイントタプル６１を示す。回復ポイントタプル６１は、時刻と、データ（ストリームＩＤ）と、フラグ（タプルの種類）とが対応づけられている。
回復ポイントタプル６１の「時刻」は、ストリームデータ内のデータタプルの位置を特定するためのデータであり、例えば、生成時に付加された時刻（ライブ中継などで配信時刻が特定可能な場合）、ストリームデータ内の相対的な時刻（すでに記録された番組の再生時刻）などが、挙げられる。なお、時刻情報だけでは、ストリームデータ内のデータタプルの位置を一義的に特定できないときには、時刻情報と別の識別情報との組を、データタプルの位置特定用情報として利用すればよい。
回復ポイントタプル６１の「データ（ストリームＩＤ）」は、タプルのデータ格納欄に、ストリームＩＤを格納する旨を示している。ストリームＩＤとは、入力ストリームごとに振られたユニークなＩＤである。この「データ（ストリームＩＤ）」は、クエリ演算処理の対象外であるため、とくに書き換えは発生しない。
回復ポイントタプル６１の「フラグ（タプルの種類）」は、タプルの種類がデータタプルではなく、制御用の回復ポイントタプル６１である旨を示している。
【００３０】
図５（ｂ）は、管理テーブル４７を示す構成図である。管理テーブル４７は、１つの行（１つのレコード）で、１つの回復ポイントタプル６１を管理する。管理テーブル４７は、ストリームＩＤと、時刻と、分岐数と、出力数とを対応づけて管理する。
管理テーブル４７の「ストリームＩＤ」および「時刻」は、図５（ａ）で説明したように、回復ポイントタプル６１の特定情報であり、回復ポイントタプル６１の生成時に登録される。
管理テーブル４７の「分岐数」は、分岐処理が実行された回数を示す。クエリ処理部４５から分岐が発生するたびに通知される分岐通知を受けると、分岐数が初期値「１」から始めて、「１」ずつ増加される。
管理テーブル４７の「出力数」は、含まれるレコードの回復ポイントタプル６１がストリームデータ送信部４３から出力されるたびに、１ずつ増加される。そして、管理テーブル４７の「分岐数」と「出力数」とが同じ値になるレコードは、管理テーブル４７から削除されるとともに、ｄｉｓｋ３５に回復ポイント６２として書き込まれる。
【００３１】
図５（ｃ）は、ｄｉｓｋ３５で格納されている回復ポイント６２を示す構成図である。回復ポイント６２は、入力ストリームごとに振られたユニークＩＤ、回復ポイントタプル生成時に付加された時刻を持つ。回復ポイント６２は、回復ポイント管理部４６から管理テーブル４７に基づいて、ｄｉｓｋ３５に出力される。
回復ポイント６２は、障害発生時に参照される。つまり、図２（ｂ）などで説明したように、障害発生時には、ストリームデータの再投入の位置を特定する必要があるが、回復ポイント６２から該当ストリームをストリームＩＤで検索し、そのストリームＩＤに対応する時刻の内の最新時刻が、ストリームデータの再投入の位置の特定情報として参照される。
【００３２】
図６は、ストリームデータ処理部４１での、通常運用時における回復ポイントタプル６１の生成から消滅までを示すフローチャートである。図７は、図６のフローチャートの処理を示す説明図である。以下、図６および図７を参照して、ストリームデータ処理部４１での、通常運用時の処理を説明する。
【００３３】
ストリームデータ受信部４２は、計算機１１から、入力ストリーム１６のタプル（データタプル、回復ポイントタプル６１など）を受信する（Ｓ１０１）。なお、図７では、入力ストリーム１６が、入力ストリームバックアップ２５へとバックアップされるとともに、ストリームデータ処理部４１へと入力される形態を示した。この形態は、入力ストリーム１６がリアルタイムに生成されるライブ放送などに適した形態である。一方、入力ストリームバックアップ２５内にすでに蓄積されている入力ストリーム１６が、ストリームデータ処理部４１へと入力される形態（オンデマンド配信）としてもよい。
【００３４】
ストリームデータ受信部４２は、入力ストリーム１６のデータタプルの間に回復ポイントタプル６１（６１ａ）を追加（挿入）する（Ｓ１０２）。なお、回復ポイントタプル６１を追加する位置について、例えば、所定の追加条件を満たす位置とする。そして、回復ポイント管理部４６は、ストリームデータ受信部４２から回復ポイントタプル６１の追加通知を受けると、その内容を管理テーブル４７に新規登録する。
【００３５】
ストリームデータ受信部４２は、制御部４４に回復ポイントタプル６１を出力する。クエリ処理部４５ａ，４５ｂは、制御部４４から回復ポイントタプル６１を受信する（Ｓ１０３）。図４（ａ）に示したように、クエリ処理部４５ａ，４５ｂは、回復ポイントタプル６１ｂ、６１ｃをクエリ演算処理の対象とせずに、バッファにプールする。
【００３６】
クエリ処理部４５は、図４（ｃ）に示したように、消滅タプルの受信に伴い、回復ポイントタプル６１を制御部４４に出力する（Ｓ１０４）。回復ポイント管理部４６は、クエリ処理部４５ａ、４５ｂから、回復ポイントタプル６１が出力された旨の通知を受け、管理テーブル４７の情報を更新する。
【００３７】
ストリームデータ送信部４３は、制御部４４から出力された回復ポイントタプル６１を受信し、回復ポイント管理部４６に通知した後、回復ポイントタプル６１を削除する（Ｓ１０５）。回復ポイント管理部４６は、ストリームデータ送信部４３からの通知を受け、管理テーブル４７の「出力数」を１つ増加させる。もし、管理テーブル４７の「分岐数」と「出力数」とが等しくなったときには、回復ポイント管理部４６は、入力ストリームバックアップ２５にある回復ポイントタプル６１ｄ以前のデータはストリームデータ処理部４１から出力されたと判断し、ｄｉｓｋ３５に回復ポイント６２を出力する。
これにより、回復ポイント６２には、Ｓ１０５で削除された回復ポイントタプル６１に関する情報が、追加される。なお、最新の回復ポイント６２が示す時刻より前の時刻のデータタプルは、再投入の対象から除外される。よって、再投入の対象にならないデータタプルを、入力ストリームバックアップ２５から削除することで、入力ストリームバックアップ２５を記憶する記憶装置の空き容量を増やすことができる。
【００３８】
図８は、ストリームデータ処理部４１が実行する、Ｓ１０２（回復ポイントタプル６１の追加処理）の詳細を示すフローチャートである。
【００３９】
Ｓ２０１において、入力された入力ストリーム１６のタプルが、回復ポイントタプル６１か否かを判定する。入力ストリーム１６に回復ポイントタプル６１が含まれている場合は、例えば、図３（ａ）で説明したように、送信側のユーザが回復ポイントタプル６１を明示的に設定した場合が挙げられる。
しかし、送信側のユーザが指定した回復ポイントタプル６１を、受信側で無視する設定がなされている場合には、入力された回復ポイントタプル６１を削除して、Ｓ２０１の処理を次のタプルに対して行うこととしてもよい。
Ｓ２０１でＹＥＳならＳ２０４へ、Ｓ２０１でＮＯならＳ２０２へ、それぞれ移行する。
【００４０】
Ｓ２０２において、回復ポイントタプル６１の追加条件（詳細は、図１０参照）を満たしているか否かを判断する。Ｓ２０２でＹＥＳならＳ２０３へ、Ｓ２０２でＮＯならＳ２０５へ、それぞれ移行する。
Ｓ２０３において、回復ポイントタプル６１を生成して、ストリームデータ受信部４２に追加する。
Ｓ２０４において、回復ポイント管理部４６の管理テーブル４７に、回復ポイントタプル６１の情報（レコード）を追加する。
Ｓ２０５において、ストリームデータ受信部４２にあるタプルを、制御部４４に出力する。
【００４１】
図９は、クエリ処理部４５が実行する、Ｓ１０３（回復ポイントタプル６１の受信処理）の詳細を示すフローチャートである。
Ｓ３０１において、制御部４４からタプルを受信する。
Ｓ３０２において、受信したタプルが回復ポイントタプル６１であるか否かを判定する。Ｓ３０２でＹＥＳならＳ３０３へ、Ｓ３０２でＮＯならＳ３０４へ、それぞれ移行する。
Ｓ３０３において、受信した回復ポイントタプル６１を、クエリ演算処理に関与させずに、バッファにプールする。
Ｓ３０４において、受信したデータタプルに対して、クエリ演算処理を行う。
【００４２】
図１０は、Ｓ２０２における回復ポイントタプル６１の追加条件の一例を示す説明図である。
図１０（ａ）は、所定の入力ストリーム量ごとに回復ポイントタプル６１を追加する条件を示す。これにより、一定の入力ストリーム量ごとに回復ポイントを設定するため、障害時に再投入する入力ストリーム量を簡単に計算できる。再投入量が簡単に計算できるため、それに伴い回復までの時間を見積もることも可能となる。
図１０（ｂ）は、所定時間ごとに回復ポイントタプル６１を追加する条件を示す。これにより、回復時点の時間指定が可能となる。また、ログの解析、音声解析などのように、あらかじめ入力するデータを用意でき、入力量が時間により変動しないデータである場合、指定した時間ごとに回復ポイントを取得できるため、ストリーム処理システムの回復時間を一定にすることが可能となる。
図１０（ｃ）は、ハードウェア負荷の増加などの外部要因を検知して、回復ポイントタプル６１を追加する条件を示す。外部要因としては、ハードウェア（ＣＰＵ、メモリ、Ｉ／Ｏ）などの負荷が「高い」または「低い」場合が挙げられる。
以上、図１０（ａ）〜（ｃ）に示した追加条件は、それぞれ単独で用いてもよいし、組み合わせで用いてもよい。さらに、これらの追加条件は、時間経過にかかわらず、同じ設定を使い続けてもよいし、時間帯やイベント発生などにより、複数の設定を切り替えてもよい。
【００４３】
図１１は、クエリ処理部４５が実行する、Ｓ１０４（回復ポイントタプル６１の出力処理）の詳細を示すフローチャートである。
Ｓ４０１において、制御部４４からタプルを受信する。
Ｓ４０２において、受信したタプルが、消滅タプルか否かを判定する。なお、制御部４４は、クエリ処理部４５内での生存期間を過ぎたタプルを消滅させる指示を記述した消滅タプルを生成して、クエリ処理部４５に適宜通知する。Ｓ４０２でＹＥＳならＳ４０３へ、Ｓ４０２でＮＯなら処理終了へ、それぞれ移行する。
Ｓ４０３において、消滅タプルで消滅を指定されたデータタプルが、Ｓ３０３でプールされている回復ポイントタプル６１より後に受信したデータタプルであるか否かを判断する。Ｓ４０３でＹＥＳならＳ４０４へ、Ｓ４０３でＮＯならＳ４０６へ、それぞれ移行する。
Ｓ４０４において、Ｓ３０３でプールされている回復ポイントタプル６１を、制御部４４に出力する。
Ｓ４０５において、回復ポイント管理部４６に対して、出力する回復ポイントタプル６１の分岐数などの情報を通知する。回復ポイント管理部４６は、通知された分岐数をもとに、管理テーブル４７の出力された回復ポイントタプル６１を示すレコードの「分岐数」を更新する。
Ｓ４０６において、受信した消滅タプルの指示に従い、データタプル（通常タプル）をクエリ処理部４５から削除する。
【００４４】
図１２は、ストリームデータ送信部４３が実行する、Ｓ１０５（回復ポイントタプル６１の削除処理）の詳細を示すフローチャートである。
Ｓ５０１において、制御部４４からタプルを受信する。
Ｓ５０２において、受信したタプルが、回復ポイントタプル６１であるか否かを判定する。Ｓ５０２でＹＥＳならＳ５０３へ、Ｓ５０２でＮＯなら処理終了へ、それぞれ移行する。
Ｓ５０３において、回復ポイントタプル６１が出力されたという情報を、回復ポイント管理部４６に通知する。
Ｓ５０４において、受信した回復ポイントタプル６１を削除する。
【００４５】
Ｓ５０５において、受信した回復ポイントタプル６１の管理テーブル４７における「分岐数」と「出力数」との整合性が取れたか否かを判定する。この判定処理は、所定の回復ポイントタプル６１が次々に分岐して数を増やしていった場合に、その回復ポイントタプル６１を全て出力側で回収できたときに、整合性がとれたものとする。回復ポイントタプル６１の数はクエリ処理部４５の分岐処理などにより増減する可能性があるため、回復ポイントタプル６１の出力の際に、正しい増減結果の数が出力されたか否かの整合性を確認する必要がある。なお、分岐が１回も行われなかった回復ポイントタプル６１については、回復ポイントタプル６１の分岐数および出力数は、ともに「１」となり整合性がとれる。Ｓ５０５でＹＥＳならＳ５０６へ、Ｓ５０５でＮＯならＳ５０８へ、それぞれ移行する。
Ｓ５０６において、回復ポイント６２に記載する回復ポイントタプル６１の情報を、ｄｉｓｋ３５に出力する。
Ｓ５０７において、回復ポイント管理部４６は、Ｓ５０６で出力した回復ポイントタプル６１の情報を、管理テーブル４７から削除する。
Ｓ５０８において、回復ポイント管理部４６の管理テーブル４７の出力数の項目を「１増加する」旨の更新を行う。
【００４６】
図１３は、Ｓ５０５の整合性の判定処理の一例を示す。
図１３（ａ）では、１つの入力された回復ポイントタプル６１が、クエリ処理部４５で１回分岐することにより、２つの出力された回復ポイントタプル６１となる場合を示す。このときには、１つのストリームデータ送信部４３で２回の回復ポイントタプル６１の出力が行われるため、管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
図１３（ｂ）では、１つの入力された回復ポイントタプル６１が、クエリ処理部４５で１回分岐することにより、２つの出力された回復ポイントタプル６１となる場合を示す。このときには、２つのストリームデータ送信部４３でそれぞれ１回の回復ポイントタプル６１の出力が行われるため、管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
【００４７】
図１３（ｃ）では、２つの入力された回復ポイントタプル６１（ユニークＩＤは、互いに異なる）が、クエリ処理部４５でそれぞれ１回ずつ分岐することにより、４つの出力された回復ポイントタプル６１となる場合を示す。このときには、回復ポイントタプル６１の整合性判定は、ユニークＩＤごとに（つまり、２回分）実行される。つまり、２つのストリームデータ送信部４３でそれぞれ２回の回復ポイントタプル６１の出力が行われるため、第１の回復ポイントタプル６１における管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合し、第２の回復ポイントタプル６１における管理テーブル４７における「分岐数＝２」と「出力数＝２」とが整合する。
なお、図１３（ｃ）のように回復ポイントタプル６１の種類が多く存在する場合、各回復ポイントタプル６１の最新の回復ポイント６２を抽出し、一番古い回復ポイント６２を再投入時点として採用する。
【００４８】
図１４は、ストリームサーバ回復処理部２６が実行する、障害発生時の入力ストリーム１６の回復処理を示すフローチャートである。図１５は、図１４のフローチャートの処理を示す説明図である。以下、図１４および図１５を参照して、入力ストリーム１６の回復処理を説明する。
Ｓ６０１において、ストリームデータ処理部４１で障害が発生する。
Ｓ６０２において、ストリームサーバ監視処理部２３は、ストリームデータ処理部４１の停止（障害）を検知する。
Ｓ６０３において、Ｓ６０２の検知を受け、ストリームサーバ回復処理部２６を実行する。
Ｓ６０４において、ストリームサーバ回復処理部２６は、ｄｉｓｋ３５から最新の回復ポイント６２を取得する。なお、ｄｉｓｋ３５には、出力済の回復ポイントタプル６１に関する情報が、格納されている。
Ｓ６０５において、ストリームサーバ回復処理部２６は、入力ストリームバックアップ２５から、取得した回復ポイント６２が示す時刻より新しい時刻に対応するデータタプルをストリームデータ処理部４１に入力ストリーム１６として再投入することで、ストリームデータ処理部４１を回復させる。
【００４９】
以上説明した本実施形態によれば、入力ストリームバックアップ２５を使用してストリームデータ処理部４１の障害回復をする場合、入力ストリームバックアップ２５からの再投入するデータタプルの位置を特定することができる。
そのため、回復ポイント指定処理部１７およびストリームデータ受信部４２は、回復ポイントタプル６１を入力ストリーム１６に追加する。そして、ストリームデータ処理部４１から回復ポイントタプル６１が出力される時点で、回復ポイント管理部４６は、ｄｉｓｋ３５に回復ポイント６２を出力する。障害時には、最新の回復ポイント６２が示す時刻位置以降のデータタプルを入力ストリームバックアップ２５から取得して、新しい入力ストリーム１６として再投入することで、ストリームデータ処理部４１を回復できる。
【符号の説明】
【００５０】
８，９ ネットワーク
１１ 計算機（ストリーム配信装置）
２１ 計算機（障害回復装置）
３１ 計算機（ストリーム処理装置）
５１ 計算機
１２，２２，３２，５２ メモリ
１３，５３ アプリケーション実行部
１４，２４，３４，５４ ＣＰＵ
１５，３５，５５ ｄｉｓｋ
１６ 入力ストリーム
１７ 回復ポイント指定処理部
２３ ストリームサーバ監視処理部
２５ 入力ストリームバックアップ
２６ ストリームサーバ回復処理部
３３ オペレーティングシステム
４１ ストリームデータ処理部
４２ ストリームデータ受信部
４３ ストリームデータ送信部
４４ 制御部
４５，４５ａ，４５ｂ，４５ｃ クエリ処理部
４６ 回復ポイント管理部
４７ 管理テーブル
５６ 出力ストリーム
６１，６１ａ，６１ｂ，６１ｃ，６１ｄ 回復ポイントタプル
６２ 回復ポイント
【特許請求の範囲】
【請求項１】
ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムによるストリーム回復方法であって、
前記ストリームデータは、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置は、
前記データタプルをクエリ処理するとともに、前記回復ポイントタプルをクエリ処理から除外して一時的にバッファにプールし、前記データタプルが前記ストリーム処理装置内で削除指示されると、その削除指示対象の前記データタプルより前に位置する前記回復ポイントタプルを前記バッファから読み取って、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、記憶手段に書き出し、
前記障害回復装置は、
前記ストリーム処理装置に発生する障害を検知すると、前記記憶手段から前記ストリームデータ内における位置情報を読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする
ストリーム回復方法。
【請求項２】
前記ストリーム配信装置は、入力手段を介してユーザから入力された位置情報を、前記ストリームデータ内の前記回復ポイントタプルの追加位置として、前記ストリームデータを構成することを特徴とする
請求項１に記載のストリーム回復方法。
【請求項３】
前記ストリーム処理装置は、所定の追加条件を満たすか否かを判定し、前記所定の追加条件を満たした時点で前記ストリーム配信装置から受信する前記ストリームデータに対して、前記回復ポイントタプルを挿入することを特徴とする
請求項１に記載のストリーム回復方法。
【請求項４】
前記ストリーム処理装置は、前記所定の追加条件として、受信する前記ストリームデータのデータ量が所定量になる度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項５】
前記ストリーム処理装置は、前記所定の追加条件として、所定時間が経過する度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項６】
前記ストリーム処理装置は、前記所定の追加条件として、前記ストリーム処理装置のハードウェア資源への負荷が所定量以上に増加する度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項７】
前記ストリーム処理装置は、
前記クエリ処理において分岐処理を行うときには、分岐ごとに前記回復ポイントタプルを複製し、削除指示に伴って前記回復ポイントタプルの全てを前記バッファから読み取ったときに、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、前記記憶手段に書き出すことを特徴とする
請求項１〜請求項６のいずれか１項に記載のストリーム回復方法。
【請求項８】
前記回復ポイントタプルには、その所属する前記ストリームデータを特定するためのストリームＩＤが格納され、
前記ストリーム処理装置は、前記ストリームデータ内における位置情報を、ストリームＩＤごとに前記記憶手段に書き出し、
前記障害回復装置は、ストリームＩＤごとに前記記憶手段から位置情報を読み取り、その位置情報のうちの最も前に位置する位置情報を前記ストリームデータ内の再投入位置とすることを特徴とする
請求項１〜請求項７のいずれか１項に記載のストリーム回復方法。
【請求項９】
請求項１〜請求項８のいずれか１項に記載のストリーム回復方法を、前記ストリーム処理システムの各装置に実行させるためのストリーム回復プログラム。
【請求項１０】
ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムにおける障害回復装置であって、
前記ストリームデータは、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置に発生する障害を検知すると、前記ストリーム処理装置のクエリ処理が済んだ前記データタプルの位置を示す、前記ストリームデータ内における位置情報を記憶手段から読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする
障害回復装置。
【請求項１】
ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムによるストリーム回復方法であって、
前記ストリームデータは、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置は、
前記データタプルをクエリ処理するとともに、前記回復ポイントタプルをクエリ処理から除外して一時的にバッファにプールし、前記データタプルが前記ストリーム処理装置内で削除指示されると、その削除指示対象の前記データタプルより前に位置する前記回復ポイントタプルを前記バッファから読み取って、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、記憶手段に書き出し、
前記障害回復装置は、
前記ストリーム処理装置に発生する障害を検知すると、前記記憶手段から前記ストリームデータ内における位置情報を読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする
ストリーム回復方法。
【請求項２】
前記ストリーム配信装置は、入力手段を介してユーザから入力された位置情報を、前記ストリームデータ内の前記回復ポイントタプルの追加位置として、前記ストリームデータを構成することを特徴とする
請求項１に記載のストリーム回復方法。
【請求項３】
前記ストリーム処理装置は、所定の追加条件を満たすか否かを判定し、前記所定の追加条件を満たした時点で前記ストリーム配信装置から受信する前記ストリームデータに対して、前記回復ポイントタプルを挿入することを特徴とする
請求項１に記載のストリーム回復方法。
【請求項４】
前記ストリーム処理装置は、前記所定の追加条件として、受信する前記ストリームデータのデータ量が所定量になる度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項５】
前記ストリーム処理装置は、前記所定の追加条件として、所定時間が経過する度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項６】
前記ストリーム処理装置は、前記所定の追加条件として、前記ストリーム処理装置のハードウェア資源への負荷が所定量以上に増加する度に、前記回復ポイントタプルを挿入することを特徴とする
請求項３に記載のストリーム回復方法。
【請求項７】
前記ストリーム処理装置は、
前記クエリ処理において分岐処理を行うときには、分岐ごとに前記回復ポイントタプルを複製し、削除指示に伴って前記回復ポイントタプルの全てを前記バッファから読み取ったときに、その回復ポイントタプルが示す前記ストリームデータ内における位置情報を、前記記憶手段に書き出すことを特徴とする
請求項１〜請求項６のいずれか１項に記載のストリーム回復方法。
【請求項８】
前記回復ポイントタプルには、その所属する前記ストリームデータを特定するためのストリームＩＤが格納され、
前記ストリーム処理装置は、前記ストリームデータ内における位置情報を、ストリームＩＤごとに前記記憶手段に書き出し、
前記障害回復装置は、ストリームＩＤごとに前記記憶手段から位置情報を読み取り、その位置情報のうちの最も前に位置する位置情報を前記ストリームデータ内の再投入位置とすることを特徴とする
請求項１〜請求項７のいずれか１項に記載のストリーム回復方法。
【請求項９】
請求項１〜請求項８のいずれか１項に記載のストリーム回復方法を、前記ストリーム処理システムの各装置に実行させるためのストリーム回復プログラム。
【請求項１０】
ストリームデータを配信するストリーム配信装置と、配信される前記ストリームデータをクエリ処理するストリーム処理装置と、前記ストリーム処理装置の障害発生により失われる前記ストリームデータを前記ストリーム処理装置に再投入するための制御を行う障害回復装置と、を用いるストリーム処理システムにおける障害回復装置であって、
前記ストリームデータは、クエリ処理の対象であるデータタプルと、そのデータタプルの前記ストリームデータ内における位置を示す回復ポイントタプルと、を含めて構成され、
前記ストリーム処理装置に発生する障害を検知すると、前記ストリーム処理装置のクエリ処理が済んだ前記データタプルの位置を示す、前記ストリームデータ内における位置情報を記憶手段から読み取り、その位置情報のうちの最も後に位置する位置情報を前記ストリームデータ内の再投入位置とし、その再投入位置を起点とする前記ストリームデータを、前記ストリーム処理装置に再投入する旨を前記ストリーム配信装置に指示することを特徴とする
障害回復装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−２１９６１３（Ｐ２０１０−２１９６１３Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６０７６６（Ｐ２００９−６０７６６）
【出願日】平成２１年３月１３日（２００９．３．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１３日（２００９．３．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]