JP2012003394A - データ処理の障害回復方法、システムおよびプログラム - Google Patents
データ処理の障害回復方法、システムおよびプログラム Download PDFInfo
- Publication number
- JP2012003394A JP2012003394A JP2010136099A JP2010136099A JP2012003394A JP 2012003394 A JP2012003394 A JP 2012003394A JP 2010136099 A JP2010136099 A JP 2010136099A JP 2010136099 A JP2010136099 A JP 2010136099A JP 2012003394 A JP2012003394 A JP 2012003394A
- Authority
- JP
- Japan
- Prior art keywords
- data
- data processing
- recovery
- execution state
- failure recovery
- 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
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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- 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/84—Using snapshots, i.e. a logical point-in-time copy of the data
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)
Abstract
【課題】ストリームデータ処理の障害発生後の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、全てのウィンドウ演算の利用を実現する。
【解決手段】クエリ解析部606は、クエリに対応するストリームデータ処理を行うオペレータ中、ウィンドウなどの実行状態を保持するオペレータと、その回復ポイントを解析する。バックアップデータ取得時に、バックアップデータ管理部652は、解析された回復ポイントのスナップショット取得に必要な容量を管理し、各々の回復ポイントまでの入力データのバックアップに必要な記憶領域655の記憶容量と、それで再現できないウィンドウに対してスナップショットを取得した場合に必要な記憶領域654の記憶容量を算出し、これらに必要な記憶容量の合計値が最も小さくなる回復ポイントを選択して、実行状態の記録を行う。
【選択図】図6
【解決手段】クエリ解析部606は、クエリに対応するストリームデータ処理を行うオペレータ中、ウィンドウなどの実行状態を保持するオペレータと、その回復ポイントを解析する。バックアップデータ取得時に、バックアップデータ管理部652は、解析された回復ポイントのスナップショット取得に必要な容量を管理し、各々の回復ポイントまでの入力データのバックアップに必要な記憶領域655の記憶容量と、それで再現できないウィンドウに対してスナップショットを取得した場合に必要な記憶領域654の記憶容量を算出し、これらに必要な記憶容量の合計値が最も小さくなる回復ポイントを選択して、実行状態の記録を行う。
【選択図】図6
Description
本発明は、データ処理の障害回復技術に関し、特に、ストリームデータ処理における障害回復に必要な再現データの保存技術に関する。
自動株取引、高度な交通情報処理、多地点から得たセンサ情報の解析といった、継続的に発生する多量のデータをリアルタイムに解析し即座に対応ために、ストリームデータ処理が注目されている。ストリームデータ処理は、様々な形式のデータのリアルタイム処理に適用可能な汎用ミドルウェア技術であるため、個別案件ごとにシステムを構築するのでは間に合わないようなビジネス環境の急激な変化にも応えつつ、実世界のデータをリアルタイムにビジネスに反映することを可能とする。このストリームデータ処理の原理、実現方式は非特許文献1に開示されている。
ストリームデータ処理は、前述のように多量のデータのリアルタイム処理であるため、処理結果の出力データも多量かつ継続的に発生することになる。従って、障害が発生してから復旧までに要する時間は、可能な限り短くすることが求められる。このとき、復旧されたサーバの実行状態は初期状態であるため、障害発生前の実行状態を復旧後のサーバにも再現する、実行状態再現が必要とされている。
実行状態再現の一つ目の方法として、正常動作中から入力ストリームをバックアップしておき、復旧時にはバックアップデータを待機系サーバで再実行して現用系サーバの実行状態に追付かせる、Upstream Backup方式が非特許文献2に開示されている。処理時間が長くなるほど、バックアップに必要なディスクやメモリなどの記憶容量は増大するが、次の理由で容量は一定以内に収まることが仮定できる。
ストリームデータ処理では、データ系列から直近の一部分を切り出すウィンドウ演算を利用することが可能である。ウィンドウ演算の定義は非特許文献3に開示されている。例えば、時間幅1分のウィンドウ演算によって切り出したデータに対して平均を算出する集約演算を適用すると、1分間の移動平均を算出する動作となる。この例においては、1分間データを流し続けるとウィンドウ内のデータが刷新されることになるため、初期状態から開始する復旧時においても直近1分間のデータを処理することで、障害発生前と同じ実行状態になる。このように、Upstream Backup方式においては、保持しておくべきデータの範囲が処理の進行に伴って未来に進むことを前提とすることで、バックアップのための記憶容量が一定以内に収まることを仮定できる。
実行状態再現の二つ目の方法として、次のようなものが存在する。まず、運用中のサーバを定期的に一時停止して実行状態を静止化し、その実行状態を複製(スナップショット)として保存する。そして、障害が発生し、復旧した時に保存したスナップショットから実行状態を再現する。静止化してスナップショットを保存する方法は、データベースやトランザクションシステムで広く利用されている方法である。インメモリデータベースにおける静止化を利用した再現方法が、特許文献1に開示されている。
B.Babcock、S.Babu、M.Datar、R.Motwani and J.Widom、"Models and issues in data stream systems"、In Proc. of PODS 2002、 pp.1−16.(2002)
J.H.Hwang、M.Balazinska、A.Rasin、U.Cetintemel、M.Stonebraker and S.B.Zdonik、"High−Availability Algorithms for Distributed Stream Processing"、In Proc. of ICDE 2005、 pp.779−790.(2005)
A.Arasu、S.Babu and J. Widom. "The CQL Continuous Query Language: Semantic Foundations and Query Execution"、(2005)
前述のUpstream Backup方式による実行状態再現において次のようの問題がある。ストリームデータ処理システムが処理するウィンドウ演算としては、前述の時間ウィンドウ(Rangeウィンドウ)以外にも、個数ウィンドウ(Rowsウィンドウ)、グループ別個数ウィンドウ(Partitionウィンドウ)、永続ウィンドウ(Unboundedウィンドウ)などが存在する。時間ウィンドウとは異なり、これらのウィンドウでは時間の経過のみではウィンドウが刷新されない可能性がある。例えば、証券取引の分析において銘柄毎に直近100件の出来高統計を算出する処理は、グループ別個数ウィンドウの利用により容易に定義できる。このとき、取引が低調な銘柄が存在すると、その銘柄の取引データがウィンドウに残り続けることになる。また、分析開始から全取引の集計を算出するといった処理は、永続ウィンドウを利用することで容易に定義できるが、同ウィンドウには処理開始以降の全てのデータが残り、全く刷新されない。
このようなケースにUpstream Backup方式を適用すると、保持しておくべきデータ範囲の起点が進行しないため、データの保持に必要な記憶容量が際限なく増大し、いずれオーバフローすることになる。
一方で、スナップショットを利用する実行状態再現方式では、全てのウィンドウ演算を利用可能である。但し、動作中のサーバを静止化する期間、結果の出力が停止するため、アプリケーションに対して処理の停止として影響を与えてしまうことになる。実行状態に「過去数分間に送られた全データ」といった非常にサイズの大きなものが複数含まれていた場合、スナップショットの取得に非常に大きな記憶容量を必要とする。
本発明の解決すべき課題は、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全てのウィンドウ演算の利用を実現することである。
すなわち、本発明の目的は、上記の課題を解決できるデータ処理障害回復方法、システムおよびプログラムを提供することにある。
上記の目的を達成するため、本発明においては、計算機を用いたストリームデータ処理の障害回復方法であって、計算機は、ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得しストリームデータの容量と複製データの容量の合計値が最少となる回復ポイントを算出し、算出した回復ポイントにおいてストリームデータと複製データを記録するストリームデータ処理の障害回復方法を提供する。
また、上記の目的を達成するため、本発明においては、処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、計算機の処理部は、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析するクエリ解析部と、クエリ解析部が解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、決定した回復ポイントにおいてストリームデータ処理の実行状態を記憶部に記録する障害回復システムを提供する。
更に、上記の目的を達成するため、本発明においては、クエリに基づきストリームデータ処理を実行する計算機の処理部で実行される障害回復プログラムであって、処理部を、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析し、解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定し、決定した回復ポイントにおいてストリームデータ処理の実行状態を記録するよう動作させる障害回復プログラムを提供する。
また更に、本発明の好適なデータ処理の障害回復方式においては、前述の課題を解決するために以下の手順で実行状態を再現する。
(1)ストリームデータ処理の中に含まれる全てのウィンドウ等の実行状態を保持するオペレータは、時間・個数・グループ別などの種類を問わず、それぞれが現在の状態を再現するために必要な最も古いデータが入力された時刻をUpstream Backup方式で再現可能な回復ポイントとして管理する。
(2)全てのウィンドウ等の実行状態を保持するオペレータの回復ポイント各々について、その回復ポイントより以降の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては、バックアップデータを保持するUpstream Backup方式、その回復ポイントより前の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては複製(スナップショット)を取得する方式で、実行状態を再現するために必要な記憶領域の大きさを計算し管理する。
(3)計算した全ての回復ポイントにおける実行状態再現に必要な記憶領域の総和の中で、容量がもっとも小さい回復ポイントを選択する。そして、その回復ポイント以降のストリームデータのバックアップデータを保持すると同時に、その回復ポイントより前の回復ポイントを持つウィンドウの複製(スナップショット)を取得する。
(4)障害回復のための実行状態再現時において、まず当該回復ポイントからデータを流し込み、その部分の処理が終わったら複製(スナップショット)のあるウィンドウはスナップショットからデータを上書きし、その後にバックアップデータ取得後のストリームの処理を始める。
本発明により、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全ての実行状態を保持するオペレータが利用可能となる。より具体的には、実行状態を保持するオペレータンごとにスナップショットを取得すべきかUpstream Backup方式により再現するかを比較し、より記憶領域が小さくなる方を選択することが可能となる。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、後で説明するように、本明細書において、オペレータには、Scanオペレータ、フィルタオペレータ等に加え、各種のウィンドウ演算も含まるので、留意されたい。
まず、図1および図2を用いて、第1の実施例に係る、ストリームデータ処理システムの基本構成を説明する。
図1に示すように、ネットワーク104にストリームデータ処理サーバ100と計算機101、102、103が接続されている。ストリームデータ処理サーバ100は、ネットワーク104を介して、データソース107が動作する計算機102からデータ108を受け取り、処理結果のデータ110を計算機103上の結果利用アプリケーション109に送信する。また、計算機101上では、クエリ登録コマンド実行インタフェース105が動作する。
図2に示すように、ストリームデータ処理サーバ100は、計算機200および210から構成され、計算機200および210は、記憶部であるメモリ202および212、処理部である中央処理部(Central Processing Unit:CPU)201および211、ネットワークインタフェース(Interface:I/F)204および214、記憶部であるストレージ203および213、およびそれらを結合するバス205および215によって構成される。メモリ202上に、ストリームデータ処理の論理動作を定義する、ストリームデータ処理システム206を配置する。ストリームデータ処理システム206は、後で詳述するようにCPU201によって解釈実行可能な実行イメージである。
図2に示すように、ストリームデータ処理サーバ100を構成する計算機200および210は、ネットワークI/F204および214を介して外部のネットワーク104に接続される。
ネットワーク104に接続された計算機101上で動作する、クエリ登録コマンド実行インタフェース105を介して、ユーザによって定義されたクエリ106を、ストリームデータ処理サーバ100を構成する計算機200が受取ると、ストリームデータ処理システム206は、この定義に従ってストリームデータ処理を実行可能なクエリグラフを自身の内部に構成する。この後、ネットワーク104に接続された計算機102上で動作するデータソース107によって送信されるデータ108を、ストリームデータ処理サーバ100を構成する計算機200が受取ると、このクエリグラフに従って処理し、結果データ110を生成し、計算機103上で動作する結果利用アプリケーション109に送信する。ストレージ203は、ストリームデータ処理システム206の他、一度受取ったクエリ106を保存する。ストリームデータ処理システム206は、起動時にストレージ203からこの定義をロードし、クエリグラフを構成することも可能である。
計算機210を構成するメモリ212には、ストリームデータ処理システム206に不具合が発生した際の復旧用にバックアップ用ストレージシステム(BSS)216が記憶されている。また、計算機210を構成するメモリ212およびストレージ213のいずれかもしくは双方は、ストリームデータ処理システム206に不具合が発生した際に復旧させるために必要な再現用データ217および218を保持している。
なお、ここで説明した本実施例のストリームデータ処理サーバの構成は一例であり、計算機200と210は一台の計算機であって、処理部であるCPU201および211は、同一計算機上の二つのプロセッサであっても構わない。あるいは、一つのマルチコアCPUにおける二つの計算コアであっても構わない。また、メモリ202および212、ネットワークI/F204および214、ストレージ203および213は、それぞれが一つであって、一つの計算機に接続されるのであっても、あるいは二つの計算機に接続されて共有されるのであっても構わない。本明細書において、計算機とはいずれの場合も含み、処理部、更に記憶部も同様である。
次に、図3および図4を用いて、本実施例のストリームデータ処理におけるクエリとクエリグラフの一例を説明する。
図3に示すように、クエリ300は、2つの入力ストリームsaおよびsb、3つのクエリq1、q2およびq3を定義するクエリである。
図4に示す通り、ストリームデータ処理システムは、クエリ300の定義を受取ると、自身の実行領域中に確保したクエリ実行ワークエリア420上に、オペレータ400〜410によって構成される、クエリグラフを生成する。このオペレータには、スキャン(Scan)オペレータ400、403、フィルタ(Filter)オペレータ402、405、結合オペレータ406、ストリーム化演算オペレータ407などに加え、各種のウィンドウ(Window)401、404、408等も含まれる。オペレータ400は入力ストリームsaをデータソースから受取るScanオペレータ、オペレータ403は入力ストリームsbをデータソースから受取るScanオペレータである。ストリームsaおよびsbは共に、文字列型のカラムidと、整数型のカラムvalの二つのカラムから構成されるデータの系列である。
オペレータ401、402、404、405、406および407は、クエリq1に対応する部分クエリグラフを構成するオペレータ群である。オペレータ401は、ストリームsaに対して施されるグループ別個数ウィンドウ(PARTITION BY id ROWS 2)であり、カラムid別に最新2個のデータを切り出す。オペレータ404は、ストリームsbに対して施される時間ウィンドウ(RANGE 5 MINUTES)であり、直近5分以内のデータを切り出す。オペレータ402は、ウィンドウ401で切り出したデータに対して施されるフィルタオペレータ(sa.val > 100)であり、カラムvalの値が100より大きいデータのみを通過させる。オペレータ405は、ウィンドウ404で切り出したデータに対して施されるフィルタオペレータ(sb.val <> −1)であり、カラムvalの値が−1以外のデータを通過させる。オペレータ406は、結合オペレータ(sa.id = sb.id)であり、オペレータ402および405を通過したデータにおいて、カラムidが一致する組合せを生成する。オペレータ407は、クエリの結果を正規化するストリーム化演算である。
オペレータ408および409は、クエリq2に対応する部分クエリグラフを構成するオペレータ群である。オペレータ408は、永続ウィンドウ(UNBOUNDED)であり、クエリq1の結果データを全て保持する。オペレータ409は集約オペレータであり、カラムid別にsa.valとsb.valの最大値を算出する。また、オペレータ410は、クエリq3に対応する部分クエリグラフを構成するストリーム化演算オペレータである。
一時保持領域(Temporal Store)411および412は、それぞれ結合オペレータ406および集約オペレータ409の実行状態を保持する領域である。一時保持領域411は、オペレータ406の左入力と右入力それぞれにおける、生存中のデータを保持する。これらは、反対側の入力に到来したデータの結合相手となる。一時保持領域412は、グループ別に集約結果のデータを一つずつ保持する。
前述したように、一時保存領域を持つ結合オペレータ、集約オペレータ以外に、ウィンドウ演算も、実行状態を保持するオペレータである。ウィンドウ演算は、個々の入力データに対して生存期間を定義し、生存中のデータを保持する。これら以外の、フィルタオペレータ、射影オペレータ、ストリーム化演算、Scanオペレータ等のオペレータについては、実行状態を保持する必要はない。
次に、図5を用いて、図4のクエリグラフの例における実行状態の一例を説明する。ウィンドウ演算W1 401にデータ501〜506を保持し、ウィンドウ演算W2 404にデータ511〜517を保持している状態を表している。各データの長楕円はデータのタイムスタンプを表し、左側の四角はカラムidの値を、右側の四角はカラムvalの値を表している。グループ別ウィンドウ401は、カラムid別に、最大2個のデータを保持している。時間ウィンドウ404は、タイムスタンプが9:55〜9:59までのデータを保持している。
一時保持領域W3 411は、左入力における生存中のデータ501、503、504、505、および右入力における生存中のデータ512、513、514、516、517を保持している。それぞれ、ウィンドウ演算401に保持しているデータ集合のうち、フィルタ条件sa.val>100を満たすデータの集合、およびウィンドウ演算404に保持しているデータ集合のうち、フィルタ条件sb.val<>−1を満たすデータの集合である。また、結合条件がカラムidに関する等号条件であるため、カラムidの値をキーとして索引付けしており、カラムidの値別にグループ分けして保持している。
ウィンドウ演算W4 408は、一時保持領域411に保持する、左入力のデータ集合と右入力のデータ集合の直積において、結合条件sa.id=sb.idを満たす組合せデータ521〜531を保持している。これらのデータのタイムスタンプは、組合せた左右データのうち遅い方のタイムスタンプをとる。ウィンドウ演算408は永続ウィンドウであるため、処理を開始した時刻から全てのデータを保持している。そのため、組合せデータ521のように非常に古いデータもウィンドウ内に存在する。
一時保持領域W5 412は、ウィンドウ演算408に保持しているデータをカラムid別にグループ分けして集約したデータを、各グループにつき一つずつ保持している。カラムidがa、bおよびcそれぞれについて、データ541、542、および543を保持している。ここで一時保持領域W5 412には、カラムid別に各グループの平均値、最大値、最小値等を保持するよう設定することが可能である。図5の場合、一時保持領域W5 412には最大値が保持されるよう設定されている。
続いて、図6を用いて本実施例のストリームデータ処理を実現するソフトウェアのブロック構成の一例を説明する。なお、同図において、太線のブロックはCPUで実行される各種のソフトウェア機能を、細線のブロックはソフトウェアの実行の際、メモリ上に形成される各種のデータの保存領域を模式的に示している。
同図において、ストリームデータ処理システム206は、それぞれ、入力データ108を受信する入力データ受信部601、クエリグラフとオペレータの実行状態を保持するクエリ実行ワークエリア420、クエリ実行ワークエリア420のデータに基づいてクエリを実行するクエリ実行部602、クエリ実行結果110を出力する出力データ送信部605を備える。クエリ実行ワークエリア420には、それぞれ、オペレータ毎の実行状態を保持するオペレータ実行状態保持領域621〜623および各オペレータ実行状態保持領域621〜623に対して各オペレータにおいてその内部状態に使用されている最古の入力データの時刻を示す回復ポイントとそれらをスナップショットとして記録したときの記憶量を記録したオペレータ回復ポイント記憶領域624〜626を確保する。
さらに、ストリームデータ処理システム206は、クエリ106を解析してクエリ実行ワークエリア上にクエリグラフを生成するクエリ解析部606を備える。クエリ解析部606は、クエリグラフ上のオペレータ群において、実行状態のスナップショットを取得するオペレータを選定する、スナップショット対象選定部607を含む。スナップショット対象選定部607で選定したオペレータ群は、スナップショット対象リスト記憶領域608に記憶する。
加えて、ストリームデータ処理システム206は、入力データ受信部601で受信した入力データ108の複製をバックアップ用ストレージシステム216に送信する、もしくはバックアップ用ストレージシステム216から送られた復旧用の複製入力データを受信し入力データ受信部601に送信する複製データ通信部609、復旧用のデータをバックアップ用ストレージシステム216から送信するよう要求する復旧要求送信部610、バックアップ用ストレージシステム216から送信されたバックアップ要求を受信するバックアップ通知受信部611、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域612、バックアップ用ストレージシステム216に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部613を備える。
ここで、クエリ実行部602は、各オペレータ実行状態保持領域621〜623の保持内容をスナップショット対象リスト記憶領域608に従いコピーバッファ領域612にコピーする実行状態書出部603と、コピーバッファ領域612にある保持内容を各オペレータ実行状態保持領域621〜623の保持内容にコピーする実行状態書込部604を備える。
一方、バックアップ用ストレージシステム216はストレージデータ処理システム206と入力データ108の複製を授受する複製データ通信部657、ストレージデータ処理システム206から送られた復旧要求を受信する復旧要求受信部658、バックアップ処理をストレージデータ処理システム206に要求するバックアップ通知送信部659、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域660、ストレージデータ処理システム206に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部661を備える。
さらに、バックアップ用ストレージシステム216は複製された入力データを保存しておく入力データ記憶領域655、スナップショットの対象リストを記憶するスナップショット対象リスト記憶領域656、スナップショットを記憶するスナップショット記憶領域654を備える。ここで、スナップショット記憶領域654はオペレータ実行状態記憶領域671〜673を備える。
加えて、バックアップ用ストレージシステム216はバックアップデータ管理部652を備える。バックアップデータ管理部652は入力データ記憶領域655の容量を監視する入力データ容量管理部653を備える。
次に、図7、図8において、本実施例におけるバックアップ用データの更新処理フローの一例を示す。
まず、図7はバックアップ用ストレージシステム216からバックアップ要求を送信し、バックアップ用データがストリームデータ処理システム206から送信され、バックアップ用ストレージシステム216の保持するバックアップ用データを更新する際のフローである。
処理700では入力データ容量管理部653が「入力データ容量が規定値に達した」、「前のバックアップから一定時間が経過した」、等を理由にバックアップ要求をバックアップ通知送信部659に送信する。続いて処理701ではバックアップ通知送信部659がバックアップ要求をストリームデータ処理システム206に送信する。次いで処理702ではバックアップ通知受信部611でバックアップ要求を受信したストリームデータ処理システム206がスナップショット対象選定部607で、実行状態を保持するオペレータの中から、スナップショット対象のオペレータを選定する。処理703でストリームデータ処理システム206が選定されたオペレータのスナップショットと回復ポイントデータをバックアップ用ストレージシステム216に送信する。最後に処理704ではバックアップ用ストレージシステム216でスナップショットを保存するとともに、送られた回復ポイント以前の複製された入力データを削除する。
続いて、図8は上述の処理702の詳細である。まず、処理800、801、812、813でオペレータ通番Iが対象オペレータの数に達するまで処理802〜811の処理を繰り返す。まず処理816で、オペレータ通番Iのオペレータが実行状態を保持しているかをチェックし、保持している場合、処理802ではオペレータ通番Iの回復ポイントIをオペレータ回復ポイント記憶領域から読み出す。続いて、処理803では回復ポイントI以降の入力データの記憶容量を、入力データ容量管理部653に問い合わせそれを必要記憶容量Iの初期値とする。
次いで、処理804、805、810、811でオペレータ通番Jが対象オペレータの数に達するまで処理806〜809の処理を繰り返す。まず、処理817では、オペレータ通番Jが実行状態を保持しているかをチェックし、保持している場合、処理806でオペレータ通番Jの回復ポイントJをオペレータ回復ポイント記憶領域から読み出す。処理807でオペレータ通番Iの回復ポイントIとオペレータ通番Jの回復ポイントJを比較し、回復ポイントIの方が回復ポイントJより現在時刻に近い場合は処理810に進み、そうでない場合は処理808に進む。処理808ではオペレータ通番Jを回復ポイントI選択時のスナップショット対象に指定する。続いて処理809ではオペレータ通番Jのスナップショットの記憶量を必要記憶量Iに加算する。全てのオペレータ通番Jに対して処理806〜809を繰り返す。そして、これを全てのオペレータ通番Iに対して繰り返す。
処理814において全てのオペレータ通番に対して最も小さい必要記憶容量を選択し、その回復ポイントKを決定する。続いて回復ポイントK時のスナップショット対象を スナップショット対象リスト記憶領域608に記憶する。
続いて図9、図10、図11、図12、図13A、図13Bを用いて、本実施例におけるスナップショット対象の選定の具体的な動作例を示す。
まず、図9は、図4で示した400〜412で構成されるクエリグラフ、図5で示した各オペレータの持つウィンドウの実行状態をもとに、それぞれのウィンドウの実行状態にスナップショット取得時の記憶量と回復ポイントを加えて図示したものである。図9において、記憶量はストリームデータのデータ数を示しているが、これに限定するものでなく、各データを記憶するメモリの記憶容量などであって良いことはいうまでもない。
この例では、ストリームデータ処理システムが時刻6:30から処理を実行し、現在時刻950が10:00のときにバックアップ処理を実施するものとする。このとき、ウィンドウW1 401においてデータは501〜506の6つ存在し、最も時刻の古いデータは「時刻9:48、ID=b、VAL=97」のデータ502である。そのため、ウィンドウW1 401のスナップショットに必要な記憶量901は6、回復ポイント902は9:48となる。同様にW2 404の記憶量911は6、回復ポイント912は9:55、W3 411の記憶量921は9、回復ポイント922は9:50となる。W4 408は永続ウィンドウであるためストリームデータ処理システムが起動してからW4に送られたデータすべてを記録している。
そのため、記憶量931は100と大きく、回復ポイント932も最古のデータである521と合わせて6:30と非常に前の時刻となっている。W5 412ではそれぞれのIDの最大値を記録しているため、記憶量941は3と小さいが、そのID=bの最大値データ542の由来となるデータは6:45に入力されたデータ522であるため、回復ポイント942は522と同じ6:45となる。このように各オペレータの持つウィンドウの実行状態の記憶量、回復ポイントが決められる。
続いて図10は入力データ記憶領域655に記録された入力データ108のバックアップと、図9で示した各オペレータにおける実行状態の回復ポイント以降のデータ数を示している。
データ群sa1001はScan400に入力されるデータ群でデータ501〜506およびデータ1020〜1023等から構成されている。データ群sb1002はScan430に入力されるデータ群でデータ511〜517およびデータ1030〜1035から構成されている。これを各回復ポイントで記録する場合、W4 408の回復ポイント932である6:30から保存する場合、記憶するデータ数1010は1000となる。同様にW5 412の回復ポイント942である6:45から保存する場合、記憶するデータ数1011は900となり、W1401の回復ポイント902である9:48の場合はデータ数1012が17、W3 411の回復ポイント922の9:50の場合、データ数1013は14、W2 404の回復ポイント912の9:55の場合はデータ数1014が9となる。
図11ではこれらの情報を用いて処理800〜813を行った結果をまとめたものを示した。W1の回復ポイント902である9:48を選択した場合は、W2の回復ポイントが9:55、W3の回復ポイントが9:50であるため、W1、W2、W3は入力データのバックアップから実行状態を再現できる。一方、W4とW5の回復ポイントはW1より古いため、入力データのバックアップから再現できない。そこで、W4とW5はスナップショットが必要となる。
その結果、この場合の必要記憶容量1101はW1の回復ポイント902での入力データバックアップのデータ数1012である17とW4とW5のスナップショットの記憶量931、941の合計である120となる。同様の処理をするとW2の回復ポイント選択時の必要記憶容量1102は127、W3の必要記憶容量1103は123、W4の必要記憶容量1103は1000、W5の必要記憶容量1104は1000となる。
図12では処理814、815により必要記憶容量の最も少ないW1の回復ポイントが選択された時の回復ポイントとスナップショットで再現するオペレータのリストである。
このときの回復ポイント1201はW1の回復ポイントである9:48、入力データのバックアップから再現するオペレータ1202はW1、W2、W3、スナップショットから再現するオペレータ1203はW4、W5となる。
図13A、図13Bそれぞれが、本具体例における、記録される入力データのバックアップ1300とスナップショット1310を示している。入力データのバックアップ1300は回復ポイントである9:48以降のデータ、スナップショット1310はW4とW5の実行状態を記録している。
続いて図14を用いて、本実施例における、入力データのバックアップとスナップショットから初期状態のストリームデータ処理システムに実行状態を再現する手順のフローチャートを示す。
処理1400においてストリームデータ処理システム206の復旧要求送信部610がバックアップ用ストレージシステム216に復旧要求を送信する。それを受けて処理1401においてバックアップ用ストレージシステム216が入力データのバックアップとスナップショットをストリームデータ処理システム206に送信する。処理1402において入力データのバックアップとスナップショットを送られたストリームデータ処理システム206は障害前の実行状態を復旧する。最後に処理1403において障害後の入力データから処理を継続する。
図15に図14の処理1402の詳細を示した。最初に処理1500において回復ポイントからバックアップデータ取得時刻までの入力データのバックアップを初期状態のストリームデータ処理システム206で処理する。続いて処理1501〜1504においてスナップショットを取得しているオペレータ全てにスナップショットの実行状態をコピーする。最後にバックアップデータ取得後から障害発生直前までの入力データのバックアップをストリームデータ処理システム206で処理する。
図16、図17、図18を用いて、図13で取得したスナップショットから初期状態のストリームデータ処理システムに対して図15のフローチャートに示した手順でバックアップデータ取得時の実行状態を再現する例を示す。
図16では初期状態のストリームデータ処理システムに対し処理1500の回復ポイントからバックアップデータ取得時までの入力データのバックアップ1300を入力している。
図17がその結果である。この場合、入力データのバックアップから実行状態の再現できるW1 401、W2 404、W3 411の3つはバックアップデータ取得時刻1750である10:00の実行状態が再現されている。一方、W4 408は本来6:30からのデータを保存していたため9:48のデータからではデータ量が足りず、W5 412は6:30からのデータの最大値を記憶していたため、9:48からの最大値であるデータ1701〜1703は本来のものと値が異なっている。
図18で図17の状態に対し処理1501〜1504を行う例を示す。入力データのバックアップ1300から再現できないW4 408、W5 412の実行状態についてスナップショット1310から実行状態をコピーする。その結果、W4 408、W5 412を含め全てのオペレータに対し図9と同様のバックアップデータ取得時の実行状態が再現される。
この後は処理1505にあるようにバックアップデータ取得後の入力データのバックアップを処理すれば障害直前の実行状態が再現される。
ここまでで、スナップショットの取得の処理は一定間隔、または入力データのバックアップの容量が一定値に達した場合に自動で行われてもかまわない。
また、図19に示すように(Graphic User Interface:GUI)1900を用いて、バックアップデータ取得化の最適化機能の使用の有無1901、一定間隔の時刻1902、バックアップデータの容量の限界値1903などを設定できるよう構成しても良い。なお、1094はユーザが、所望する任意の時間に、直ちに最適化を実行するために用いる「最適化実施」ボタンを示す。
以上の詳述した本発明の処理手順により、最小限の記憶領域でストリームデータ処理システムの実行状態を再現する手段が実現できる。
本発明は、ストリームデータ処理における障害回復技術に関し、特に、障害回復に必要な再現データの保存技術として有用である。
100…ストリーム処理サーバ
101、102、103、200、210…計算機
104…ネットワーク
201、211…CPU
202、212…メモリ
203、213…ストレージ装置
204、214…ネットワークI/F
205、215…計算機内部バス
206…ストリームデータ処理システム
216…バックアップ用ストレージシステム(BSS)
217、218…再現用バックアップデータ
400〜410…オペレータ
411、412…一時保持領域
601…入力データ受信部
602…クエリ実行部
605…出力データ送信部
606…クエリ解析部
608、656…スナップショット対象リスト記憶領域
609、657…複製データ通信部
610…復旧要求送信部
611…バックアップ通知受信部
612、660…コピーバッファ領域
613、661…ワークエリアデータ通信部
652…バックアップデータ管理部
655…入力データ記憶領域
658…復旧要求受信部
659…バックアップ通知送信部
621、622、623…オペレータ実行状態保持領域
624、625、626…オペレータ回復ポイント記録領域
671、672、673…オペレータ実行状態記憶領域
501〜506、511〜517、521〜531、541〜543、1020〜1023、1030〜1035、1701〜1703…データ
901、911、921、931、941…スナップショット記憶量
902、912、922、932、942…回復ポイント
1300…入力データバックアップ
1301…スナップショットデータ
1900…バックアップ方式設定GUI。
101、102、103、200、210…計算機
104…ネットワーク
201、211…CPU
202、212…メモリ
203、213…ストレージ装置
204、214…ネットワークI/F
205、215…計算機内部バス
206…ストリームデータ処理システム
216…バックアップ用ストレージシステム(BSS)
217、218…再現用バックアップデータ
400〜410…オペレータ
411、412…一時保持領域
601…入力データ受信部
602…クエリ実行部
605…出力データ送信部
606…クエリ解析部
608、656…スナップショット対象リスト記憶領域
609、657…複製データ通信部
610…復旧要求送信部
611…バックアップ通知受信部
612、660…コピーバッファ領域
613、661…ワークエリアデータ通信部
652…バックアップデータ管理部
655…入力データ記憶領域
658…復旧要求受信部
659…バックアップ通知送信部
621、622、623…オペレータ実行状態保持領域
624、625、626…オペレータ回復ポイント記録領域
671、672、673…オペレータ実行状態記憶領域
501〜506、511〜517、521〜531、541〜543、1020〜1023、1030〜1035、1701〜1703…データ
901、911、921、931、941…スナップショット記憶量
902、912、922、932、942…回復ポイント
1300…入力データバックアップ
1301…スナップショットデータ
1900…バックアップ方式設定GUI。
Claims (15)
- 計算機を用いたストリームデータ処理の障害回復方法であって、
前記計算機は、
ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ前記実行状態を保持するオペレータの、最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ前記実行状態を保持するオペレータの複製データの容量を取得し、前記ストリームデータの容量と前記複製データの容量の合計値が最少となる前記回復ポイントを算出し、算出した前記回復ポイントにおいて前記ストリームデータと前記複製データを記録する、
ことを特徴とするストリームデータ処理の障害回復方法。 - 請求項1に記載のデータ処理の障害回復方法であって、
前記容量の指標が前記ストリームデータのデータ数である、
ことを特徴とするデータ処理の障害回復方法。 - 請求項1に記載のデータ処理の障害回復方法であって、
前記計算機は、
前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
ことを特徴とするデータ処理の障害回復方法。 - 請求項1に記載のデータ処理の障害回復方法であって、
前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
ことを特徴とするデータ処理の障害回復方法。 - 請求項1に記載のデータ処理の障害回復方法であって、
前記計算機は、
障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
ことを特徴とするデータ処理の障害回復方法。 - 処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、
前記計算機の処理部は、
クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析するクエリ解析部と、
前記クエリ解析部が解析した、各々の前記回復ポイントに対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、
前記バックアップデータ管理部が決定した回復ポイントにおいてストリームデータ処理の実行状態を前記記憶部に記録する、
ことを特徴とずる障害回復システム。 - 請求項6に記載のデータ処理の障害回復システムであって、
前記容量の指標が前記ストリームデータのデータ数である、
ことを特徴とするデータ処理の障害回復システム。 - 請求項6に記載のデータ処理の障害回復システムであって、
前記処理部は、
前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
ことを特徴とするデータ処理の障害回復システム。 - 請求項6に記載のデータ処理の障害回復システムであって、
前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
ことを特徴とするデータ処理の障害回復システム。 - 請求項6に記載のデータ処理の障害回復システムであって、
前記処理部は、
障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
ことを特徴とするデータ処理の障害回復システム。 - クエリに基づきストリームデータ処理を実行する計算機の処理部で実行されるデータ処理の障害回復プログラムであって、
前記処理部を、
クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析し、
解析した前記回復ポイント各々に対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、
前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定し、
決定した回復ポイントにおいてストリームデータ処理の実行状態を記録する、
よう動作させる、
ことを特徴とずるデータ処理の障害回復プログラム。 - 請求項11に記載のデータ処理の障害回復プログラムであって、
前記容量の指標が前記ストリームデータのデータ数である、
ことを特徴とするデータ処理の障害回復プログラム。 - 請求項11に記載のデータ処理の障害回復プログラムであって、
前記処理部を、
前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行させる、
よう動作させる、
ことを特徴とするデータ処理の障害回復プログラム。 - 請求項11に記載のデータ処理の障害回復プログラムであって、
前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
ことを特徴とするデータ処理の障害回復プログラム。 - 請求項11に記載のデータ処理の障害回復プログラムであって、
前記処理部を、
障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
よう動作させることを特徴とするデータ処理の障害回復プログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010136099A JP5308403B2 (ja) | 2010-06-15 | 2010-06-15 | データ処理の障害回復方法、システムおよびプログラム |
US13/701,847 US9037905B2 (en) | 2010-06-15 | 2010-08-24 | Data processing failure recovery method, system and program |
PCT/JP2010/064288 WO2011158387A1 (ja) | 2010-06-15 | 2010-08-24 | データ処理の障害回復方法、システムおよびプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010136099A JP5308403B2 (ja) | 2010-06-15 | 2010-06-15 | データ処理の障害回復方法、システムおよびプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012003394A true JP2012003394A (ja) | 2012-01-05 |
JP5308403B2 JP5308403B2 (ja) | 2013-10-09 |
Family
ID=45347807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010136099A Expired - Fee Related JP5308403B2 (ja) | 2010-06-15 | 2010-06-15 | データ処理の障害回復方法、システムおよびプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US9037905B2 (ja) |
JP (1) | JP5308403B2 (ja) |
WO (1) | WO2011158387A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016110619A (ja) * | 2014-12-04 | 2016-06-20 | 知意圖股▲分▼有限公司 | リアルタイムにメッセージクエリを提供する情報システムとその方法 |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9654538B1 (en) * | 2013-03-11 | 2017-05-16 | DataTorrent, Inc. | Dynamic partitioning of instances in distributed streaming platform for real-time applications |
US9542397B1 (en) | 2013-03-14 | 2017-01-10 | EMC IP Holding Company LLC | File block addressing for backups |
KR20140134379A (ko) * | 2013-05-14 | 2014-11-24 | 엘에스산전 주식회사 | 데이터 수집 장치 |
US9477571B2 (en) * | 2014-01-20 | 2016-10-25 | International Business Machines Corporation | Streaming operator with trigger |
KR101632824B1 (ko) | 2015-01-12 | 2016-06-22 | 인제대학교 산학협력단 | 휠체어의 휠퍼 |
US9772910B1 (en) * | 2015-12-07 | 2017-09-26 | EMC IP Holding Co. LLC | Resource optimization for storage integrated data protection |
CN107665155B (zh) * | 2016-07-28 | 2021-07-09 | 华为技术有限公司 | 处理数据的方法和装置 |
US10346272B2 (en) | 2016-11-01 | 2019-07-09 | At&T Intellectual Property I, L.P. | Failure management for data streaming processing system |
US10439917B2 (en) | 2016-11-15 | 2019-10-08 | At&T Intellectual Property I, L.P. | Recovering a replica in an operator in a data streaming 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 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006338432A (ja) * | 2005-06-03 | 2006-12-14 | Hitachi Ltd | ストリームデータ処理システムのクエリ処理方法 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8813079B1 (en) * | 2006-06-07 | 2014-08-19 | Ca, Inc. | Thread management to prevent race conditions in computer programs |
JP5192226B2 (ja) | 2007-12-27 | 2013-05-08 | 株式会社日立製作所 | 待機系計算機の追加方法、計算機及び計算機システム |
JP5091894B2 (ja) * | 2009-03-13 | 2012-12-05 | 株式会社日立製作所 | ストリーム回復方法、ストリーム回復プログラム、および、障害回復装置 |
JP5439014B2 (ja) * | 2009-04-10 | 2014-03-12 | 株式会社日立製作所 | データ処理システム、その処理方法、及び計算機 |
US8726076B2 (en) * | 2011-05-27 | 2014-05-13 | Microsoft Corporation | Operator state checkpoint markers and rehydration |
-
2010
- 2010-06-15 JP JP2010136099A patent/JP5308403B2/ja not_active Expired - Fee Related
- 2010-08-24 US US13/701,847 patent/US9037905B2/en not_active Expired - Fee Related
- 2010-08-24 WO PCT/JP2010/064288 patent/WO2011158387A1/ja active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006338432A (ja) * | 2005-06-03 | 2006-12-14 | Hitachi Ltd | ストリームデータ処理システムのクエリ処理方法 |
Non-Patent Citations (3)
Title |
---|
JPN6013027499; Jeong-Hyon Hwang et al.: '"A Comparison of Stream-Oriented High-Availability Algorithms"' Technical Report CS-03-17 , 200309, P. 1-13 * |
JPN6013027500; Jeong-Hyon Hwang et al.: '"A Cooperative, Self-Configuring High-Availability Solution for Stream Processing"' Proceedings of 2007 IEEE 23rd International Conference on Data Engineering , 20070420, P. 176-185, IEEE * |
JPN6013027501; Gabriela Jacques-Silva et al.: '"Language-Level Checkpointing Suport for Stream Processing Applications"' Proceedings of 2009 IEEE/IFIP International Conference on Dependable Systems and Networks , 20090702, P. 145-154, IEEE * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016110619A (ja) * | 2014-12-04 | 2016-06-20 | 知意圖股▲分▼有限公司 | リアルタイムにメッセージクエリを提供する情報システムとその方法 |
Also Published As
Publication number | Publication date |
---|---|
WO2011158387A1 (ja) | 2011-12-22 |
JP5308403B2 (ja) | 2013-10-09 |
US20130086418A1 (en) | 2013-04-04 |
US9037905B2 (en) | 2015-05-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5308403B2 (ja) | データ処理の障害回復方法、システムおよびプログラム | |
US20200012568A1 (en) | Scalable log-based continuous data protection for distributed databases | |
US10353918B2 (en) | High availability and disaster recovery in large-scale data warehouse | |
US10621049B1 (en) | Consistent backups based on local node clock | |
JP5331737B2 (ja) | ストリームデータ処理障害回復方法および装置 | |
US9740582B2 (en) | System and method of failover recovery | |
US9141685B2 (en) | Front end and backend replicated storage | |
JP6254606B2 (ja) | バックアップシステムからのデータベースのストリーミング復元 | |
US9904721B1 (en) | Source-side merging of distributed transactions prior to replication | |
US20220188196A1 (en) | Continuous data protection | |
US20130262389A1 (en) | Parallel Backup for Distributed Database System Environments | |
GB2495079A (en) | Live migration of applications and file systems in a distributed system | |
AU2019347897B2 (en) | Methods, devices and systems for real-time checking of data consistency in a distributed heterogenous storage system | |
WO2019109854A1 (zh) | 分布式数据库数据处理方法、装置、存储介质及电子装置 | |
US20120084260A1 (en) | Log-shipping data replication with early log record fetching | |
US11748215B2 (en) | Log management method, server, and database system | |
US20220121527A1 (en) | Dynamically updating database archive log dependency and backup copy recoverability | |
US11042454B1 (en) | Restoration of a data source | |
US20230315713A1 (en) | Operation request processing method, apparatus, device, readable storage medium, and system | |
US20220121524A1 (en) | Identifying database archive log dependency and backup copy recoverability | |
Vasuja et al. | Daemons of Hadoop: An Overview | |
CN111522688A (zh) | 分布式***的数据备份方法及装置 | |
US20210141806A1 (en) | Maintain Constant Load on Global Database After Regionalization | |
Zeb | Comparative analysis of data stream processing systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130108 |
|
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: 20130611 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130628 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |