特許 7271670 データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-04-28

(45)【発行日】2023-05-11

(54)【発明の名称】データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム

(51)【国際特許分類】

   G06F 16/178 20190101AFI20230501BHJP

   G06F 16/28 20190101ALI20230501BHJP

【ＦＩ】

G06F16/178

G06F16/28

【請求項の数】 18

(21)【出願番号】P 2021532087

(86)(22)【出願日】2020-04-10

(65)【公表番号】

(43)【公表日】2022-01-26

(86)【国際出願番号】 CN2020084085

(87)【国際公開番号】W WO2020224374

(87)【国際公開日】2020-11-12

【審査請求日】2021-06-04

(31)【優先権主張番号】201910368297.X

(32)【優先日】2019-05-05

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】李 ▲海▼翔

【審査官】松尾 真人

(56)【参考文献】

【文献】特開２０１０－０６１５５９（ＪＰ，Ａ）

【文献】特開２００３－２６３３５０（ＪＰ，Ａ）

【文献】国際公開第２００７／０２８２４９（ＷＯ，Ａ１）

【文献】特開２００６－０９２００５（ＪＰ，Ａ）

【文献】特表２０１０－５２７０８７（ＪＰ，Ａ）

【文献】特開２００６－２６０２９２（ＪＰ，Ａ）

【文献】特開平０３－１２２７２９（ＪＰ，Ａ）

【文献】特開２０１５－０６４８５０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

マルチバージョンコンカレンシーコントロール（ＭＶＣＣ）によるデータベースに基づくハイブリッドトランザクション／分析クラスタ（ＨＴＡＣ）アーキテクチャのトランザクション処理クラスタのノード機器により実行されるデータレプリケーション方法であって、前記ＭＶＣＣによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の３つの状態を含み、
トランザクションの提出操作を検出した場合、前記トランザクションの履歴状態データをデータキューに追加するステップであって、前記データキューは、履歴状態データをキャッシングするためのものであるステップと、
前記データキューにおける少なくとも１つの履歴状態データを送信バッファに追加するステップであって、前記送信バッファは、レプリケーション対象となる履歴状態データをキャッシングするためのものであるステップと、
第１所定条件に合致する場合、前記送信バッファにおける前記少なくとも１つの履歴状態データを前記ＭＶＣＣによるデータベースに基づく前記ＨＴＡＣアーキテクチャの分析処理クラスタのクラスタ機器にレプリケーションするステップであって、前記クラスタ機器は、前記少なくとも１つの履歴状態データを記憶し、前記少なくとも１つの履歴状態データに基づき、検索及び分析サービスを提供するために使用され、前記少なくとも１つの履歴状態データは読み取ることだけができ、修正または削除することはできない、ステップと、
前記ノード機器において、レプリケーションされた前記少なくとも１つの履歴状態データをレプリケーションが完了した後で削除するステップと
を含み、
前記ＭＶＣＣによるデータベースにおいて、前記トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、方法。

【請求項2】

前記データキューにおける少なくとも１つの履歴状態データを送信バッファに追加する前記ステップは、
前記データキューに履歴状態データが増加したことを検出した場合、前記履歴状態データを前記送信バッファに追加するステップを含み、
前記第１所定条件に合致する場合、前記送信バッファにおける前記少なくとも１つの履歴状態データをクラスタ機器にレプリケーションする前記ステップは、
前記送信バッファに履歴状態データが増加したことを検出した場合、前記送信バッファにおける前記少なくとも１つの履歴状態データを前記クラスタ機器にレプリケーションするステップを含む請求項１に記載の方法。

【請求項3】

前記データキューにおける少なくとも１つの履歴状態データを送信バッファに追加する前記ステップは、
第１所定期間ごとに、前記データキューにおける、現在タイミングの前の前記第１所定期間内に増加した少なくとも１つの履歴状態データを取得するステップと、
トランザクション提出タイムスタンプの昇順に従って、前記少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、前記複数の履歴状態データをソートし、少なくとも１つの順次配列された履歴状態データを取得し、前記少なくとも１つの順次配列された履歴状態データを前記送信バッファに追加するステップと、を含む請求項１に記載の方法。

【請求項4】

前記第１所定条件は、
前記送信バッファに何れかの履歴状態データが増加したことを検出したことと、
前記送信バッファの容量に対する前記送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことと、
現在タイミングと、前記送信バッファが前回で前記クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達したことと、
現在タイミングと、前記送信バッファが前回で前記クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第３所定期間に達したこととのうちの、何れかの１つまたは複数を含み、
前記第３所定期間は、複数のノード機器のうちの各ノード機器に対して配置する同じ所定期間であり、前記第３所定期間が前記第２所定期間より大きい、請求項１～３の何れかの１項に記載の方法。

【請求項5】

前記方法はさらに、前記クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、前記レプリケーション成功応答に対応する送信バッファをクリアするステップを含む請求項１に記載の方法。

【請求項6】

前記送信バッファの数が複数である場合、前記方法はさらに、
前記データキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の前記送信バッファに追加するステップを含む請求項１に記載の方法。

【請求項7】

マルチバージョンコンカレンシーコントロール（ＭＶＣＣ）によるデータベースに基づくハイブリッドトランザクション／分析クラスタ（ＨＴＡＣ）アーキテクチャの分析処理クラスタのクラスタ機器により実行されるデータレプリケーション方法であって、前記ＭＶＣＣによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の３つの状態を含み、前記クラスタ機器は、履歴状態データを記憶し、前記履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記履歴状態データは読み取ることだけができ、修正または削除することはできず、
受信バッファから、前記ＭＶＣＣによるデータベースに基づく前記ＨＴＡＣアーキテクチャのトランザクション処理クラスタのノード機器が送信した少なくとも１つの履歴状態データを受信するステップであって、前記受信バッファは、受信した履歴状態データをキャッシングするためのものであり、受信した前記履歴状態データは、前記ノード機器においてレプリケーションが完了した後に削除され、前記ノード機器はトランザクション処理サービスを提供するために使用される、ステップと、
前記受信バッファにおける前記少なくとも１つの履歴状態データを転送バッファに追加し、前記転送バッファを介して、前記少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得するステップであって、前記転送バッファは、履歴状態データに対してデータ形式の変換を行うためのものであるステップと、
前記少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶するステップであって、１つのターゲットデータシートは、１つのデータ項目の、前記ノード機器において所在する１つのオリジナルデータシートに対応するステップと、を含み、
前記ＭＶＣＣによるデータベースにおいて、トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、方法。

【請求項8】

前記少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶する前記ステップは、
タプルを単位とするデータ項目に対して、前記データ項目が所在するオリジナルデータシートにおける記憶形式に従って、前記データ項目を、前記オリジナルデータシートに対応するターゲットデータシートに記憶するステップ、又は
フィールドの変更状況を示すデータ項目に対して、キー値ペアの記憶形式に従って、前記データ項目を、前記オリジナルデータシートに対応するターゲットデータシートに記憶するステップを含む請求項７に記載の方法。

【請求項9】

前記キー値ペアの記憶形式に従って、前記データ項目を前記オリジナルデータシートに対応するターゲットデータシートに記憶する前記ステップは、
前記オリジナルデータシートにおける前記データ項目のキー名と前記データ項目の生成時間とのうちの少なくとも一項を、前記ターゲットデータシートにおける前記データ項目のキー名として決定するステップと、
前記オリジナルデータシートにおける前記データ項目の修正されたフィールドを、前記ターゲットデータシートにおける前記データ項目のキー値として決定するステップと、を含む請求項８に記載の方法。

【請求項10】

前記方法はさらに、
前記少なくとも１つの履歴状態データのトランザクション標識から、第２所定条件に合致する最小トランザクション標識を決定するステップであって、前記第２所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれも前記クラスタデータベースに記憶されたことを示すステップと、
前記最小トランザクション標識に基づき、可視データ項目を決定するステップであって、前記可視データ項目のトランザクション標識が前記最小トランザクション標識の以下であるステップと、
前記可視データ項目に基づき、データ検索サービスを提供するステップと、を含む請求項７に記載の方法。

【請求項11】

前記少なくとも１つの履歴状態データのトランザクション標識から、第２所定条件に合致する最小トランザクション標識を決定する前記ステップは、
トランザクション提出タイムスタンプの昇順に従って、前記少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、前記複数の履歴状態データをソートし、ターゲットデータシーケンスを取得するステップと、
前記ターゲットデータシーケンスから、前記第２所定条件に合致する少なくとも１つのトランザクションを取得するステップと、
前記少なくとも１つのトランザクションにおける、順番が最も前にあるトランザクションのトランザクション標識を前記最小トランザクション標識として決定するステップと、を含む請求項１０に記載の方法。

【請求項12】

前記ターゲットデータシーケンスから、前記第２所定条件に合致する少なくとも１つのトランザクションを取得する前記ステップは、
前記ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットＡＮＤ操作を実行し、出力が真である履歴状態データに対応するトランザクションが前記第２所定条件に合致すると決定するステップ、又は
前記ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定した場合、前記グローバルトランザクション標識に対応するトランザクションが前記第２所定条件に合致すると決定するステップを含む請求項１１に記載の方法。

【請求項13】

前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定する前記ステップは、
前記グローバルトランザクション標識に基づき、前記クラスタデータベースに記憶され、且つ前記グローバルトランザクション標識を有するデータ項目を取得し、取得した前記データ項目及び復号化により得られた前記履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定するステップを含む請求項１２に記載の方法。

【請求項14】

前記受信バッファからノード機器が送信した少なくとも１つの履歴状態データを受信する前記ステップは、
第２所定期間ごとに、前記受信バッファから、何れかのノード機器が送信した少なくとも１つの履歴状態データを受信するステップ、又は
第３所定期間ごとに、前記受信バッファから、複数のノード機器が同時に送信した少なくとも１つの履歴状態データを受信するステップを含む請求項７に記載の方法。

【請求項15】

マルチバージョンコンカレンシーコントロール（ＭＶＣＣ）によるデータベースに基づくハイブリッドトランザクション／分析クラスタ（ＨＴＡＣ）アーキテクチャのトランザクション処理クラスタに含まれる、データレプリケーション装置であって、前記ＭＶＣＣによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の３つの状態を含み、
トランザクションの提出操作を検出した場合、前記トランザクションの履歴状態データをデータキューに追加し、前記データキューにおける少なくとも１つの履歴状態データを送信バッファに追加するための追加モジュールであって、前記データキューは、履歴状態データをキャッシングするためのものであり、前記送信バッファは、レプリケーション対象となる履歴状態データをキャッシングするためのものである追加モジュールと、
第１所定条件に合致する場合、前記送信バッファにおける前記少なくとも１つの履歴状態データを前記ＭＶＣＣによるデータベースに基づく前記ＨＴＡＣアーキテクチャの分析処理クラスタのクラスタ機器にレプリケーションするためのレプリケーションモジュールであって、前記クラスタ機器は、前記少なくとも１つの履歴状態データを記憶し、前記少なくとも１つの履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記少なくとも１つの履歴状態データは読み取ることだけができ、修正または削除することはできず、前記データレプリケーション装置において、レプリケーションされた前記少なくとも１つの履歴状態データをレプリケーションが完了した後で削除する、レプリケーションモジュールと、を含み、
前記ＭＶＣＣによるデータベースにおいて、前記トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、装置。

【請求項16】

マルチバージョンコンカレンシーコントロール（ＭＶＣＣ）によるデータベースに基づくハイブリッドトランザクション／分析クラスタ（ＨＴＡＣ）アーキテクチャの分析処理クラスタに含まれる、データレプリケーション装置であって、前記ＭＶＣＣによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の３つの状態を含み、前記データレプリケーション装置は、履歴状態データを記憶し、前記履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記履歴状態データは読み取ることだけができ、修正または削除することはできず、
受信バッファから、前記ＭＶＣＣによるデータベースに基づく前記ＨＴＡＣアーキテクチャのトランザクション処理クラスタのノード機器が送信した少なくとも１つの履歴状態データを受信するための受信モジュールであって、前記受信バッファは、受信した履歴状態データをキャッシングするためのものであり、受信した前記履歴状態データは、前記ノード機器においてレプリケーションが完了した後に削除され、前記ノード機器はトランザクション処理サービスを提供するために使用される、受信モジュールと、
前記受信バッファにおける前記少なくとも１つの履歴状態データを転送バッファに追加し、前記転送バッファを介して、前記少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得するための追加モジュールであって、前記転送バッファは、履歴状態データに対してデータ形式の変換を行うためのものである追加モジュールと、
前記少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶するための記憶モジュールであって、１つのターゲットデータシートは、１つのデータ項目の、前記ノード機器において所在する１つのオリジナルデータシートに対応する記憶モジュールと、を含み、
前記ＭＶＣＣによるデータベースにおいて、トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、装置。

【請求項17】

コンピュータ機器であって、前記コンピュータ機器は、プロセッサーとメモリとを含み、前記メモリには少なくとも１つの命令が記憶され、前記少なくとも１つの命令は前記プロセッサーによりロードされ、実行されることで、請求項１～請求項６または請求項７～請求項１４の何れかの１項に記載のデータレプリケーション方法を実現することを特徴とするコンピュータ機器。

【請求項18】

命令を含むコンピュータプログラムであって、コンピュータで実行される場合、コンピュータに請求項１～請求項６または請求項７～請求項１４の何れかの１項に記載のデータレプリケーション方法を実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１９年０５月０５日にて中国特許庁に提出され、出願番号が２０１９１０３６８２９７Ｘであり、出願の名称が「データレプリケーション方法、装置、コンピュータ機器及び記憶媒体」である中国特許出願の優先権を主張して、その全ての内容は本出願に援用される。

【0002】

本出願は、データベース技術分野に関し、特にデータレプリケーション技術に関する。

【背景技術】

【0003】

データベース技術、特にＯＬＡＰ（ｏｎｌｉｎｅ ａｎａｌｙｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ、オンライン分析処理）処理システム、データライブラリー、ビッグデータ分析などのシーンにおいて、よくデータベースからデータをレプリケーションし、既存のデータを即時的にバックアップする必要がある。

【0004】

レプリケーション過程において、一般的にホスト機器とスタンバイ機器という２つの機器に係わり、現在のデータベース（例えば、Ｏｒａｃｌｅ、ＭｙＳＱＬ、またはＩｎｎｏＤＢなど）にとって、ホスト機器は定期的にデータベースにおけるデータファイルをスタンバイ機器にレプリケーションし、データファイルによるホスト機器とスタンバイ機器との同期を実現する。また、レプリケーション過程において、データファイルに対する損壊による、ホスト機器とスタンバイ機器とのデータの不一致を避けるために、ホスト機器とスタンバイ機器とは通信接続を確立した後、両者のデータベースの間は、１つの再実行ログ（ＲＥＤＯ ＬＯＧ）を同期し、レプリケーション過程において異常が生じると、スタンバイ機器は再実行ログを再生することで、異常のデータを除去できる。

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、再実行ログの解析作業及び再生作業は複雑であり、データ量が大きいシーンで、スタンバイ機器による再実行ログの再生は、長い時間を費やし、データレプリケーション過程の効率に影響する。

【0006】

本出願の実施例は、再実行ログに基づきデータをレプリケーションする場合、長い時間を費やし、解析再生作業が複雑であり、データレプリケーションの効率に影響するという問題を解決するための、データレプリケーション方法、装置、コンピュータ機器及び記憶媒体を提供する。

【課題を解決するための手段】

【0007】

当該技術案は以下のようであり、
１つの態様によれば、コンピュータ機器（ノード機器）により実行されるデータレプリケーション方法を提供し、当該方法は、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加するステップと、
当該データキューにおける少なくとも１つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加するステップと、
第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションするステップと、を含む。

【0008】

１つの態様によれば、コンピュータ機器（クラスタ機器）により実行されるデータレプリケーション方法を提供し、当該方法は、
受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも１つの履歴状態データを受信するステップと、
当該受信バッファにおける当該少なくとも１つの履歴状態データを転送バッファに追加し、履歴状態データに対してデータ形式の変換を行う当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得するステップと、
当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶するステップであって、１つのターゲットデータシートは、１つデータ項目の、当該ノード機器において所在する１つのオリジナルデータシートに対応するステップと、を含む。

【0009】

１つの態様によれば、データレプリケーション装置を提供し、当該装置は、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加し、当該データキューにおける少なくとも１つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加する追加モジュールと、
第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションするためのレプリケーションモジュールと、を含む。

【0010】

１つの態様によれば、データレプリケーション装置を提供し、当該装置は、
受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも１つの履歴状態データを受信するための受信モジュールと、
当該受信バッファにおける当該少なくとも１つの履歴状態データを転送バッファに追加し、履歴状態データに対してデータ形式の変換を行う当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得するための追加モジュールと、
当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶するための記憶モジュールであって、１つのターゲットデータシートは、１つデータ項目の、当該ノード機器において所在する１つのオリジナルデータシートに対応する記憶モジュールと、を含む。

【0011】

１つの態様によれば、プロセッサーとメモリとを含むコンピュータ機器を提供し、当該メモリには少なくとも１つの命令が記憶され、当該少なくとも１つの命令は当該プロセッサーによりロードされるとともに、実行されることで、上記何れかの可能な実現形態のデータレプリケーション方法を実現する。

【0012】

１つの態様によれば、コンピュータ可読記憶媒体を提供し、当該記憶媒体には少なくとも１つの命令が記憶され、当該少なくとも１つの命令はプロセッサーによりロードされるとともに、実行されることで、上記何れかの可能な実現形態のデータレプリケーション方法を実現する。

【0013】

１つの態様によれば、命令を含むコンピュータプログラムを提供し、コンピュータで実行されると、コンピュータに上記何れかの可能な実現形態のデータレプリケーション方法を実行させる。

【0014】

本出願の実施例が提供する技術案の有益な効果は、少なくとも以下を含み、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも１つの履歴状態データを送信バッファに追加し、これによって、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は、第１所定条件に合致する度に、少なくとも１つの送信バッファにおける履歴状態データをクラスタ機器にレプリケーションする。このように、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器はログをデータのオリジナル形式に解析して記憶する必要もなく、これによって、データをレプリケーションする場合、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。

【図面の簡単な説明】

【0015】

本出願の実施例の技術案をより明らかに説明するために、以下は実施例の説明に必要な図面を簡単に紹介し、明らかに、以下の説明の図面は本出願のいくつかの実施例に過ぎず、当業者にとって、進歩性に値する労働をしない前提で、これらの図面に基づき他の図面を取得できる。

【0016】

【図1】本出願の実施例が提供するデータレプリケーション方法の実施環境の概略図である。

【図2】本出願の実施例が提供するデータレプリケーション方法のインタラクションフローチャートである。

【図3】本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。

【図4】本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。

【図5】本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。

【図6】本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。

【図7】本出願の実施例が提供するオリジナルデータシートの構成概略図である。

【図8】本出願の実施例が提供するターゲットデータシートの構成概略図である。

【図9】本出願の実施例が提供するデータ検索過程のフローチャートである。

【図10】本出願の実施例が提供するトランザクションの一致性ポイントの原理的な概略図である。

【図11】本出願の実施例が提供するデータシステムのインタラクションフローチャートである。

【図12】本出願の実施例が提供するデータレプリケーション装置の構成概略図である。

【図13】本出願の実施例が提供するデータレプリケーション装置の構成概略図である。

【図14】本出願の実施例が提供するコンピュータ機器の構成概略図である。

【発明を実施するための形態】

【0017】

本出願の目的、技術案及び利点をより明らかにするために、以下は図面を結合して、本出願の実施形態をさらに詳細に説明する。

【0018】

本出願の実施例を紹介する前に、まずいくつかのデータベース技術における基本的な概念を紹介する。

【0019】

本出願の実施例に係るデータベースには、タプルを記憶するための複数のデータシートが記憶される。当該データベースはＭＶＣＣ（ｍｕｌｔｉ－ｖｅｒｓｉｏｎ ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ、マルチバージョンコンカレンシーコントロール）による何れかのタイプのデータベースであってもよい。本出願の実施例において、当該データベースのタイプを具体的に限定しない。

【0020】

なお、状態属性に基づき上記データベースにおけるデータを、現在状態、遷移状態及び履歴状態という３つの状態に区画し、当該３つの状態を「データフル状態（ｆｕｌｌ ｓｔａｔｅ）」と総称し、フル状態データと略称し、フル状態データにおける各異なる状態属性は、データの、そのライフサイクル軌跡における状態を識別する。

【0021】

現在状態（ｃｕｒｒｅｎｔ ｓｔａｔｅ）：タプルの最新バージョンのデータであって、現在階段にあるデータである。現在階段にあるデータの状態は、現在状態と呼ばれる。

【0022】

遷移状態（ｔｒａｎｓｉｔｉｏｎａｌ ｓｔａｔｅ）：タプルの最新バージョンではなく、履歴状態バージョンでもなく、現在状態から履歴状態へ変換する過程にあり、遷移状態にあるデータは、半減データと称する。

【0023】

履歴状態（ｈｉｓｔｏｒｉｃａｌ ｓｔａｔｅ）：タプルの履歴状態であり、その値は現在値ではなく、旧い値である。履歴階段にあるデータの状態は、履歴状態と称する。１つのタプルの履歴状態は複数あってもよく、データの状態変遷の過程を反映する。履歴状態にあるデータは、修正または削除できず、読み取りしかできない

【0024】

なお、ＭＶＣＣメカニズムで、データの上記３つの状態はいずれも存在し、非ＭＶＣＣメカニズムで、データは履歴状態及び現在状態のみが存在してもよい。ＭＶＣＣまたはブロッキング並行アクセス制御メカニズムで、トランザクションを提出（サブミット）した後のデータの新しい値は現在状態にある。ＭＶＣＣメカニズムで、現在活発トランザクションリストにおける最小のトランザクションの前のトランザクションから生成されるデータの状態は、履歴状態にあり、ブロッキング並行アクセス制御メカニズムで、トランザクションを提出した後、提出する前のデータの値は、履歴状態の値になり、即ち、タプルの旧い値は履歴状態にある。読み取られたバージョンには、利用されている活発トランザクション（最新の関連トランザクションではない）があり、最新の関連トランザクションがタプルの値を修正したため、その最新の値は既に１つの現在状態にあり、読み取られた値は現在状態に対して既に１つの履歴状態にあるため、そのデータ状態は現在状態と履歴状態との間にあり、遷移状態と称する。

【0025】

例えば、ＭＶＣＣメカニズムで、ユーザテーブル（ｕｓｅｒテーブル）のＡアカウントの残高は１０元から、２０元にチャージされ、そして、１５元消費して、５元になり、この時点から、金融Ｂ機構はデータを読み取り始めて、検査トランザクションを行って、Ａはその後、２０元チャージされ、２５元になり、２５元は現在状態データであり、Ｂにより読み取られた５元は遷移状態であり、残りの２０、１０の２つの値は履歴状態であり、いずれも履歴状態データである。

【0026】

上記用語の解釈に基づき、図１は、本出願の実施例が提供するデータレプリケーション方法の実施環境の概略図である。図１を参照し、当該実施環境はＨＴＡＣ（ｈｙｂｒｉｄ ｔｒａｎｓａｃｔｉｏｎ／ａｎａｌｙｔｉｃａｌ ｃｌｕｓｔｅｒ、ハイブリッドトランザクション／分析クラスタ）アーキテクチャと総称し、ＨＴＡＣアーキテクチャ内には、ＴＰ（ｔｒａｎｓａｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ、トランザクション処理）クラスタ１０１及びＡＰ（ａｎａｌｙｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ、分析処理）クラスタ１０２が含まれる。

【0027】

当該ＴＰクラスタ１０１は、トランザクション処理サービスを提供し、ＴＰクラスタには複数のノード機器１０３が含まれ、データレプリケーションの過程において、当該複数のノード機器はレプリケーション対象となる履歴状態データを提供する。ＴＰクラスタ１０１の各ノード機器にはノードデータベースが設けられ、各ノード機器はスタンドアロン機器であってもよいし、１台ホスト機器・２台スタンバイ機器からなるクラスタ機器であってもよく、本出願の実施例はノード機器のタイプを具体的に限定しない。

【0028】

当該ＡＰクラスタ１０２は、履歴状態データに対する検索及び分析サービスを提供し、ＡＰクラスタにはクラスタ機器が含まれ、クラスタ機器にはクラスタデータベースが設けられ、データレプリケーションの過程において、当該クラスタ機器は当該複数のノード機器が送信した履歴状態データをクラスタデータベースにレプリケーションして記憶し、クラスタデータベースに記憶された履歴状態データに基づき、検索及び分析サービスを提供する。当該クラスタデータベースは、ロカールのデータベースであってもよいし、当該クラスタ機器がストレージインターフェースを介してアクセスする分散型ファイルシステムであってもよい。当該分散型ファイルシステムによりＴＰクラスタに無限記憶機能を提供でき、例えば、当該分散型ファイルシステムはＨＤＦＳ（Ｈａｄｏｏｐ ｄｉｓｔｒｉｂｕｔｅｄ ｆｉｌｅ ｓｙｓｔｅｍ、Ｈａｄｏｏｐ分散型ファイルシステム）、Ｃｅｐｈ（Ｌｉｎｕｘ（登録商標）システムでの分散型ファイルシステム）、Ａｌｌｕｘｉｏ（メモリによる分散型ファイルシステム）などであってもよい。

【0029】

無論、当該クラスタ機器は、１つまたは複数のスタンドアロン機器、或いは１台ホスト機器・２台スタンバイ機器からなるクラスタ機器から構成されてもよく、各機器の間はオンライン通信を実現し、本出願の実施例はクラスタ機器のタイプを具体的に限定しない。

【0030】

いくつかの実施例において、ＴＰクラスタ１０１における複数のノード機器はトランザクション処理サービスを提供でき、何れかのトランザクションの提出が完了したタイミングで、新しい現在状態データを生成するとともに、当該現在状態データに対応する履歴状態データも生成する。履歴状態データが多い記憶空間を占めるが、履歴状態データは保存価値を具備するから、当該複数のノード機器は本出願の実施例が提供するデータレプリケーション方法に基づき、履歴状態データをクラスタ機器にレプリケーションし、クラスタ機器によりロカールアクチュエータ（ｌｏｃａｌ ｅｘｅｃｕｔｏｒ、ＬＥ）に基づき履歴状態データをデータシートに記憶し、レプリケーションが完了した後、当該ノード機器で、レプリケーションされた履歴状態データを削除することを支持する（無論、削除しなくてもよい）。履歴状態データをＴＰクラスタからＡＰクラスタに保存することで、ＨＴＡＣアーキテクチャは現在状態データ及び遷移状態データを記憶できるだけではなく、履歴状態データに対しても、適切に記憶でき、完備のフル状態データの記憶メカニズムを実現する。

【0031】

上記過程において、当該複数のノード機器は、履歴状態データをクラスタ機器に成功的にレプリケーションした後、さらに、今回レプリケーションした履歴状態データのメタデータをクラスタ機器のメタデータ（ｍｅｔａｄａｔａ、ＭＤ）マネージャに登録してもよく、これによって、クラスタ機器は当該メタデータマネージャにより、記憶された履歴状態データのメタ情報を統計する。

【0032】

いくつかの実施例において、ユーザはＳＱＬルーティング（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ ｒｏｕｔｅｒ、ＳＱＬ Ｒｏｕｔｅｒ、ＳＲ）層が提供する検索ステートメント、検索操作のセマンティック及びメタデータに基づき、ＴＰクラスタ１０１またはＡＰクラスタ１０２内に記憶された何れかのデータをルーティング検索でき、無論、ＴＰクラスタ１０１は主に現在状態データに対する検索サービスを提供し、ＡＰクラスタ１０２は主に履歴状態データに対する検索サービスを提供する。検索操作のセマンティックは、検索ステートメントに基づき分析することで得られた操作意図であり、例えば、ＷＨＥＲＥ句の条件はＷＨＥＲＥ句の意図を示す。

【0033】

いくつかの実施例において、特にビッグデータシーンで、一般的に、１つのトランザクションは、単一のノード機器のノードデータベースに対するデータ修正だけではなく、他の少なくとも１つのノード機器のノードデータベースに対するデータ修正にも係わり、この場合、分散型一致性アルゴリズム（例えば、ｔｗｏ－ｐｈａｓｅ ｃｏｍｍｉｔ、２ＰＣ）に基づき、クロスノードの書きトランザクションを実行することで、データ操作に対するトランザクションの原子性及び一致性を保証する。

【0034】

上記アーキテクチャにおいて、ＴＰクラスタ１０１における各ノード機器に対応する１つまたは複数のノードデータベースは、データベースインスタンスセットを構成でき、１つのＳＥＴ（セット）と称する。無論、当該ノード機器がスタンドアロン機器であれば、当該スタンドアロン機器のデータベースインスタンスは１つのＳＥＴであり、当該ノード機器が１台ホスト機器・２台スタンバイ機器からなるクラスタ機器であれば、当該ノード機器のＳＥＴはホスト機器データベースインスタンスと２つのスタンバイ機器データベースインスタンスとの集合であり、この場合、クラウドデータベース（ｃｌｏｕｄ ｄａｔａｂａｓｅ）の強い同期技術に基づき、ホスト機器のデータとスタンバイ機器のコピーデータとの間の一致性を保証する。好ましくは、各ＳＥＴは線形拡張を行うことで、ビッグデータシーンでの業務処理に対処する。

【0035】

いくつかの実施例において、ＴＰクラスタ１０１はさらに、分散型協調システム（例えば、ＺｏｏＫｅｅｐｅｒ）により当該複数のノード機器１０３に対する管理を実現するように支持し、例えば、ＺｏｏＫｅｅｐｅｒによりあるノード機器を失効させる（即ち、当該ノード機器をＴＰクラスタ１０１から削除する）。

【0036】

上記実施環境に基づき、図２は、本出願の実施例が提供するデータレプリケーション方法のインタラクションフローチャートである。図２を参照し、ＴＰクラスタにおける複数のノード機器のうちの何れかのノード機器、ＡＰクラスタにおけるクラスタ機器をインタラクション実行主体とすることを例として説明し、当該実施例はノード機器とクラスタ機器とのインタラクション過程に適用され、当該実施例は、以下のステップを含む。

【0037】

２０１、ノード機器はトランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加する。

【0038】

上記過程において、当該ノード機器は、ＴＰクラスタ内の何れかのノード機器であってもよく、当該ノード機器にはノードデータベースが設けられてもよい。当該ノードデータベースの内部で、何れかのトランザクションの提出に伴い、相応的に履歴状態データ及び新しい現在状態データを生成する。

【0039】

更新トランザクション（ＵＰＤＡＴＥ操作）を例として説明し、１つのタプルに対して更新トランザクションを実行する場合、更新前のタプルに削除標識を追加するステップと、修正後のデータコンテンツを記憶するための１つの新しいタプルを生成するステップという２つのステップに分ける。更新トランザクションの提出が完了した後、当該更新前のタプル及び当該新しいタプルは、外部に対して「読み取り可能」状態を呈し、即ち、更新トランザクションの提出が完成した場合に限り、タプルは有効更新の過程を完成し、データベースエンジンは当該更新前のタプル及び当該新しいタプルに対して読み取り操作を実行するように支持し、これによって、ユーザは当該タプルが修正されたことを発見できる。

【0040】

他の態様によれば、削除トランザクション（ＤＥＬＥＴＥ操作）も類似の過程を有し、１つのタプルに対して削除トランザクションを実行する場合、元のタプルに削除標識を追加し、削除トランザクションの提出が完了した後、タプルは有効削除の過程を完成し、当該元のタプルは外部に対して「読み取り可能」状態を呈し、即ち、削除トランザクションの提出が完了した場合に限り、ユーザは当該タプルが削除されたことを発見できる。

【0041】

上記状況に鑑みて、ノード機器はトランザクション処理サービスを提供する場合、何れかのトランザクションの提出操作を検出した場合、ノードデータベースは当該トランザクションの履歴状態データを取得できる。当該ノードデータベースが履歴状態データに対する記憶を支持しないデータベースであれば、ノード機器はトランザクションの提出が完了したタイミングで、履歴状態データを同時に取得し、上記ステップ２０１の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを同期に実現する。

【0042】

いくつかの実施例において、ロールバックセグメントの方式で、遷移状態データまたは履歴状態データを一時的に記憶するように支持するタイプのノードデータベース（例えばＯｒａｃｌｅ、ＭｙＳＱＬ／ＩｎｎｏＤＢなど）もあり、この場合、トランザクションの提出操作とデータキューの追加操作とは非同期であり、ノードデータベースは履歴状態データを一時的に記憶するから、データベースエンジンはロールバックセグメントに記憶されるデータを定期的にクリーンアップする。この場合、ノード機器はデータベースエンジンがロールバックセグメントに対するクリーンアップ操作を実行する際に、ロールバックセグメントに記憶される履歴状態データを取得でき、上記ステップ２０１の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを非同期に実現する。

【0043】

例えば、図３は、本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。図３を参照し、ユーザＡの初期残高は１００元であり、第１タイミングで１００元チャージして、残高は２００元になり、第２タイミング後のあるタイミングで、また１００元チャージして、残高は３００元になり、この時点で、金融機構はノードデータベースに対して読み取り操作を実行し、読み取り操作の実行過程における第３タイミングで、ユーザＡはさらに１００元チャージし、残高は４００元になり、この時点で、ユーザＡに対応する現在状態データは４００であり、遷移状態データは３００であり、履歴状態データは１００と２００とを含む。ノードデータベースがＭｙＳＱＬであることを例として、ＰＵＲＧＥ操作を実行することで、ロールバックセグメントをクリーンアップし、ノード機器はＰＵＲＧＥ操作を検出した場合、ＰＵＲＧＥ操作が作用された履歴状態データ（ユーザＡに対応する１００及び２００）をデータキューに追加する。ここで、ユーザＡの履歴状態データのみを例として説明し、ユーザＢ、ユーザＣ及びユーザＤに対しても、同じように使用するため、ここで贅言しない。

【0044】

いくつかの実施例において、現在状態データ、遷移状態データ及び履歴状態データをデータページに記録するように支持するタイプのノードデータベース（例えば、ＰｏｓｔｇｒｅＳＱＬ）もあり、データページにおける履歴状態データを定期的にクリーンアップし、この場合、ノード機器はデータベースエンジンがデータページに対するクリーンアップ操作を実行する際に、データページに記憶される履歴状態データを取得し、上記ステップ２０１の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを非同期に実現する。

【0045】

例えば、図４は本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。図４を参照し、ノードデータベースがＰｏｓｔｇｒｅＳＱＬであることを例として、ノードデータベースは複数のタプルの現在状態データ、遷移状態データ及び履歴状態データをデータページに記録し、データページにはさらに当該複数のタプルのタプル情報が記録されてもよく、ノードデータベースはＶＡＣＵＵＭ操作を実行することで、データページをクリーンアップする。ノード機器はＶＡＣＵＵＭ操作を検出した場合、ＶＡＣＵＵＭ操作が作用された履歴状態データをデータキューに追加し、そして、データページにおける、現在最小の活発トランザクションの前のトランザクションから生成されるデータをクリーンアップする。

【0046】

上記何れかの場合の、履歴状態データをデータキューに追加する過程で、ノード機器にはデータバッファ（ｂｕｆｆｅｒ）が含まれてもよく、当該データバッファはデータキューという形態で、履歴状態データをキャッシングし、履歴状態データをノードデータベースのオリジナルデータシートから、当該データバッファのデータキューに追加する。

【0047】

２０２：ノード機器は、第１所定期間ごとに、当該データキューにおける、現在タイミングの前の当該第１所定期間内に増加した少なくとも１つの履歴状態データを取得する。

【0048】

当該第１所定期間（時間長）は、０以上の何れかの値であってもよく、例えば、当該第１所定期間は０．５ミリ秒であってもよい。

【0049】

上記過程において、ノード機器は、第１所定期間ごとに、データキューから履歴状態データを１回取得するが、データキューにおける履歴状態データの順序が狂って、以下のステップ２０３を実行して、履歴状態データをソートした後、送信バッファに追加することで、履歴状態データを非同期に送信バッファに書き込むことを実現する。

【0050】

いくつかの実施例において、ノード機器はさらに履歴状態データを同期に送信バッファに書き込んでもよく、同期過程は、データキューに１つの履歴状態データが増える度に、当該履歴状態データを同期に送信バッファに追加することである。上記同期に送信バッファに書き込む状況に基づき、ノードデータベースが履歴状態データに対する記憶を支持しないデータベースであれば、ノード機器はトランザクションの提出が完了したタイミングで、履歴状態データをデータキューに書き込み、同一のタイミングで、履歴状態データを送信バッファに書き込む。

【0051】

上記過程において、本実施例のステップ２０２～２０４は以下のように差し替えられてもよい。即ち、当該データキューに何れか１つの履歴状態データが増えたことを検出した場合、当該履歴状態データを送信バッファに追加し、送信バッファに何れか１つの履歴状態データが増えたことを検出した場合、当該送信バッファにおける当該少なくとも１つの履歴状態データを当該クラスタ機器にレプリケーションし、これによって、履歴状態データの同期レプリケーションを実現し、履歴状態データを送信バッファに書き込む場合、トランザクション提出タイムスタンプの順序及びトランザクション標識の順序に従って書き込むように保証し、上記ステップ２０３のソート操作を実行する必要がなく、直接的に以下のステップ２０４を実行すればよい。

【0052】

いくつかのシーンにおいて、履歴状態データの発生とデータキューへの履歴状態データの追加過程とが非同期であり、例えば、上記ステップ２０１に係るＭｙＳＱＬ／ＩｎｎｏＤＢなどのタイプのノードデータベースにおいて、ＰＵＲＧＥ操作を採用して履歴状態データをクリーンアップするか、または、例えば、ＰｏｓｔｇｒｅＳＱＬなどのタイプのノードデータベースにおいて、ＶＡＣＵＵＭ操作を採用して、履歴状態データをクリーンアップすると、データキュー自体にキャッシングされる履歴状態データの順序が狂ってしまい、そうすれば、履歴状態データが送信バッファに同期しても、履歴状態データは整然に送信バッファに書き込まれることを保証できないから、このシーンで、以下のステップ２０３を実行しなければならない。

【0053】

図５は、本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。図５を参照し、何れかのトランザクションの提出操作を検出した後、元の現在状態データを履歴状態データに変換してもよく、この際、まず、履歴状態データをオリジナルデータシートからデータキューに追加し、そして、上記ステップ２０２の操作に基づき、履歴状態データをデータキューから非同期に送信バッファに追加する。但し、第１所定期間だけ間隔するから、データキューから取得した履歴状態データの順序が狂って、履歴状態データが整然に送信バッファに書き込まれることを保証するために、以下のステップ２０３を実行しなければならない。

【0054】

２０３：ノード機器は、トランザクション提出タイムスタンプの昇順に従って、当該少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、少なくとも１つの順次配列された履歴状態データを取得し、当該少なくとも１つの順次配列された履歴状態データを送信バッファに追加する。

【0055】

各履歴状態データは１つのトランザクションに対応し、当該トランザクション標識（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ、トランザクションＩＤ）は、１つのトランザクションを唯一に識別し、トランザクション標識はトランザクション発生タイムスタンプ（ｔｉｍｅｓｔａｍｐ） に従って単調増加し、例えば、当該トランザクション標識はトランザクション発生タイムスタンプであってもよく、無論、当該トランザクション標識はトランザクション発生タイムスタンプに従って割り振られた、単調増加傾向を呈する値であってもよい。なお、１つのトランザクションは一般的に、トランザクション発生タイムスタンプ及びトランザクション提出タイムスタンプという２つのタイムスタンプに対応し、当該２つのタイムスタンプはそれぞれトランザクションの発生タイミング及び提出タイミングに対応する。

【0056】

当該送信バッファは、データレプリケーションの過程で循環使用される部分であってもよく、当該送信バッファは送信プロセスまたは送信スレッドが送信タスク（履歴状態データをノード機器からクラスタ機器に送信する）を実行する際に呼び出すバッファであってく、好ましくは、送信プロセス、または送信スレッドの数は１つまたは複数であってもよいから、当該送信バッファの数も１つまたは複数であってもよい。上記ステップ２０３において、順序付けられた履歴状態データを何れかの送信バッファに書き込むことを例として説明する。

【0057】

上記過程において、ノード機器は、履歴状態データを非同期に送信バッファに書き込む前に、まず、履歴状態データをソートし、ソートする際、まず、トランザクション提出タイムスタンプの昇順に従ってソートし、そして、トランザクション提出タイムスタンプが同じである履歴状態データに対して、トランザクション標識の昇順に従ってソートし、さらに、順次配列された履歴状態データを当該送信バッファに書き込み、送信バッファ内の履歴状態データは順序付けられるように保証する。

【0058】

図６は、本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。図６を参照し、送信バッファの数が複数である場合、各送信バッファによる履歴状態データの取得方法は、上記ステップ２０２～２０３で紹介した実現形態と類似するため、ここで、贅言しない。上記ステップ２０２～２０３において、ノード機器はデータキューにおける少なくとも１つの履歴状態データを少なくとも１つの送信バッファの何れかの送信バッファに追加し、データ量が大きいシーンで、送信バッファの数を増やすことで、データキューにおける履歴状態データをより早く送信バッファに書き込むことができる。

【0059】

好ましくは、当送信バッファの数が複数である場合、ノード機器はデータキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加することで、複数の送信バッファの利用率、及び当該オリジナルデータシートにおける履歴状態データに対する送信レートを向上させる。

【0060】

いくつかの実施例において、ノード機器は、履歴状態データをデータキューから送信バッファに追加した後、実際の必要に応じて、データキューにおいて、当該履歴状態データを多重化可能の状態としてマークすることで、ノード機器は当該履歴状態データをロカールに保存する。

【0061】

２０４：第１所定条件に合致する場合、ノード機器は、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションする。

【0062】

いくつかの実施例において、当該第１所定条件は、ノード機器が送信バッファに何れか１つの履歴状態データが増えたことを検出したことであってもよく、当該送信バッファはレプリケーション対象となる履歴状態データをキャッシングする。ノード機器による、データキューから履歴状態データを取得する実行過程で、送信バッファに１つの履歴状態データを成功に追加すると、送信バッファはクラスタ機器に当該履歴状態データをレプリケーションし、これによって、履歴状態データをクラスタ機器に絶えずレプリケーションでき、このようなデータレプリケーションの技術はストリーミングレプリケーション技術と称する。

【0063】

いくつかの実施例において、当該第１所定条件はさらに、ノード機器が、当該送信バッファの容量に対する当該送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことであり、ノード機器による、データキューから履歴状態データを取得する実行過程で、送信バッファの総容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達した場合、送信バッファはクラスタ機器にキャッシングした当該履歴状態データをレプリケーションすることで、履歴状態データをクラスタ機器に絶えずレプリケーションすることができる。

【0064】

当該比率閾値は、０より大きく且つ１以下の何れかの値であってもよく、例えば、当該比率閾値は１００％または７５％などの値であってもよい。

【0065】

いくつかの実施例において、当該第１所定条件はさらに、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達することであってもよく、ノード機器による、データキューから履歴状態データを取得する実行過程で、ノード機器と、前回履歴状態データレプリケーションのタイミングとの時間差が第２所定期間に達した場合、送信バッファはクラスタ機器に当該履歴状態データをレプリケーションすることで、履歴状態データをクラスタ機器に絶えずレプリケーションすることができる。

【0066】

当該第２所定期間は、第１所定期間以上の何れかの値であってもよく、例えば、第１所定期間が０．５ミリ秒である場合、当該第２所定期間は１ミリ秒であってもよく、この場合、送信バッファは１ミリ秒ごとに、クラスタ機器にデータレプリケーションを１回実行し、この１ミリ秒の間隔内で、送信バッファは０．５ミリ秒ごとに、データキューから前の０．５ミリ秒内で、データキューに新たに増えた履歴状態データ（１つまたは複数であってもよい）を取得する。

【0067】

いくつかの実施例において、当該第１所定条件はさらに、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第３所定期間に達することであってもよく、当該第３所定期間は複数のノード機器のうちの各ノード機器に対して配置される同じ所定期間であり、当該第３所定期間は第２所定期間より大きく、複数のノード機器がそれぞれデータレプリケーションを実行する過程で、第３所定期間ごとに、複数のノード機器は同時にデータレプリケーションタスクを１回実行することで、各ノード機器がデータレプリケーション操作を実行する際、相互の間の遅延が最大で当該第３所定期間を超えていないように制御する。

【0068】

いくつかの実施例において、当該第１所定条件はさらに、ノード機器が、当該送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達するか、または、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達したことを検出したことである。即ち、データレプリケーションの過程で、送信バッファの総容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達した場合、データレプリケーションタスクを１回実行するか、または、送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達していなくても、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達した場合、データレプリケーションタスクを１回実行する。

【0069】

上記過程において、ノード機器は送信プロセス、または送信スレッドに基づき、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器に送信し、好ましくは、ノード機器はさらに、第１所定条件に合致する場合、当該送信バッファにキャッシングされる全ての履歴状態データを一回で当該クラスタ機器に送信してもよく、上記ステップ２０２～２０４は循環過程を形成し、ノード機器はストリーミングレプリケーション技術に基づき、持続的に履歴状態データをクラスタ機器にレプリケーションすることができる。

【0070】

いくつかの実施例において、送信バッファからクラスタ機器に送信される各履歴状態データには、当該履歴状態データに対応するトランザクションのトランザクション標識、当該トランザクションの１つまたは複数のサブトランザクションに対応する１つまたは複数のノード機器のノード標識、または当該履歴状態データのフルデータのうちの少なくとも１つが含まれる。

【0071】

１つのトランザクションは少なくとも１つのサブトランザクションを含み、各サブトランザクションは１つのノード機器に対応し、各ノード機器は唯一のノード標識を有し、当該ノード標識はノード機器のＩＰアドレス（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ａｄｄｒｅｓｓ、インターネットプロトコルアドレス）であってもよいし、ノード機器の標識番号であってもよく、当該標識番号とＩＰアドレスとは、一々対応するマッピング関係を有し、ＴＰクラスタにおける何れかのノード機器には当該マッピング関係が記憶されてもよく、無論、ＡＰクラスタのクラスタ機器にも当該マッピング関係が記憶されてもよい。

【0072】

いくつかの実施例において、ビットマップ符号化、または辞書圧縮などの方式を利用して、上記１つまたは複数のノード機器のノード標識を符号化することで、ノード機器から送信される履歴状態データの長さを短くして、データ伝送が占有するリソースをさらに圧縮させる。

【0073】

いくつかの実施例において、上記データレプリケーション過程は、ＴＰクラスタのＣｈｅｃｋｐｏｉｎｔ（チェックポイント）操作により実現でき、ノード機器はさらにＴＰクラスタのＣｈｅｃｋｐｏｉｎｔ操作頻度を設置してもよく、当該操作頻度はＴＰクラスタによるＣｈｅｃｋｐｏｉｎｔ操作の実行頻度を示し、例えば、当該操作頻度は１秒で１回実行し、１回のＣｈｅｃｋｐｏｉｎｔ操作において、ＴＰクラスタにおける各ノード機器はいずれも上記ステップ２０４のデータレプリケーション過程を１回実行することで、ＴＰクラスタにおける新たに生成した履歴状態データは、一回でＡＰクラスタに保存され、即ち、Ｃｈｅｃｋｐｏｉｎｔ操作頻度は実際に、上記第３所定期間に対応する。

【0074】

いくつかの実施例において、ＴＰクラスタ内のノード機器の数が多い場合、相変わらずＴＰクラスタにおける各ノード機器に対して、Ｃｈｅｃｋｐｏｉｎｔ操作を１回実行すると、ＴＰクラスタがＡＰクラスタにデータをレプリケーションする際、かかる時間が大きく増えて、ＨＴＡＣのパフォーマンスが安定せず、ＨＴＡＣの安定性及びロバスト性に影響する恐れがあるため、ＴＰクラスタ内の各ノード機器に対して、「マイクロＣｈｅｃｋｐｏｉｎｔ」操作を実行し、マイクロＣｈｅｃｋｐｏｉｎｔの操作頻度はＣｈｅｃｋｐｏｉｎｔの操作頻度より速いため、ノード機器の履歴状態データがより早くＡＰクラスタに保存され、履歴状態データに対するＡＰクラスタの取得需求を満たし、履歴状態データのレプリケーション効率を保障し、ＡＰクラスタのリアルタイムの可用性を向上させる。

【0075】

例えば、マイクロＣｈｅｃｋｐｏｉｎｔの操作頻度を、Ｃｈｅｃｋｐｏｉｎｔの操作頻度の千分の１の時間単位に設置し、即ち、Ｃｈｅｃｋｐｏｉｎｔ操作が１秒で１回実行されると、マイクロＣｈｅｃｋｐｏｉｎｔ操作は１ミリ秒で１回実行される。無論、ここで、マイクロＣｈｅｃｋｐｏｉｎｔの操作頻度を例示的に説明し、本出願の実施例はマイクロＣｈｅｃｋｐｏｉｎｔの操作頻度とＣｈｅｃｋｐｏｉｎｔの操作頻度との間の比率を具体的に限定しない。

【0076】

なお、マイクロＣｈｅｃｋｐｏｉｎｔの操作頻度は実際に、上記第２所定期間に対応し、異なるノード機器に対して、異なるマイクロＣｈｅｃｋｐｏｉｎｔの操作頻度を設置してもよく、マイクロＣｈｅｃｋｐｏｉｎｔの操作頻度は、ノード機器の１秒あたりの活発トランザクションの数と正相関してもよく、例えば、１秒あたりの活発トランザクションの数が、ＴＰクラスタの最初の１０位を占めるノード機器に対して、高いマイクロＣｈｅｃｋｐｏｉｎｔの操作頻度を設置できる。無論、異なるノード機器に対して、同じマイクロＣｈｅｃｋｐｏｉｎｔの操作頻度を設置しても、送信バッファの総容量に対する異なるノード機器の送信バッファの使用済みデータ量の占有比率が、一般的に、同時に比率閾値に達することがないから、異なるノード機器の間のマイクロＣｈｅｃｋｐｏｉｎｔ操作の非同期を招致する。

【0077】

いくつかの実施例において、ＴＰクラスタの異なるノード機器がそれぞれマイクロＣｈｅｃｋｐｏｉｎｔ操作を実行すると同時に、ＴＰクラスタにおける全てのノード機器が定期的にＣｈｅｃｋｐｏｉｎｔ操作を１回実行するように強制することで、ＴＰクラスタの内部の異なるノード機器が、マイクロＣｈｅｃｋｐｏｉｎｔ操作の非同期のため、大きすぎるデータ遅延を招致して、ＡＰクラスタのリアルタイムの可用性に影響することを避ける。例えば、各ノード機器は１ミリ秒ごとに、マイクロＣｈｅｃｋｐｏｉｎｔ操作を１回実行し、ＴＰクラスタは１秒ごとに、全てのノード機器をトラバースするように、Ｃｈｅｃｋｐｏｉｎｔ操作を１回実行し、ＡＰクラスタによる履歴状態データに対する受信のデータ遅延が最大で１秒を超えないように保証する（Ｃｈｅｃｋｐｏｉｎｔの操作頻度を超えない）。

【0078】

また、上記ステップ２０４のデータレプリケーション過程は、同期と非同期に分けてもよく、同期レプリケーションにおいて、データレプリケーションは履歴状態データのクリーンアップ操作と緊密に関連し、毎回のクリーンアップ操作（例えば、ＰＲＵＧＥ操作、またはＶＡＣＵＵＭ操作）に対応するクリーンアップトランザクションは、提出階段で、履歴状態データのストリーミングレプリケーションを１回トリガーし、即ち、ノード機器はクリーンアップ操作が完了する前に、まず、クリーンアップされた全ての履歴状態データをクラスタ機器に同期し、クラスタ機器はＡＲＩＥＳアルゴリズムに基づき、データレプリケーション過程のメタデータの再実行ログ（ＲＥＤＯ ＬＯＧ）を再生し、ノード機器は、再生が完了した後、クリーンアップトランザクションの状態を「提出済み」に設置する。これによって、履歴状態データはできるだけ早くクラスタ機器にレプリケーションされ、履歴状態データの安全性を保証する。

【0079】

なお、オリジナルデータシートからクリーンアップされた履歴状態データに対して、ストリーミングレプリケーション技術に基づきデータレプリケーションを実現できるが、いくつかの実施例において、今回のデータレプリケーションのメタデータのみに対して、再実行ログの記録及び再生を行って、ノード機器とクラスタ機器との間の再検証及び再校正を実現し、今回のデータレプリケーション過程の安全性をよりよく保証する。この場合でも、オリジナルデータシートからクリーンアップされた履歴状態データに対して、再実行ログの再生を一々実行することを避けることができ、再生過程のデータ量を簡略化し、再生過程にかかる期間を短くし、データレプリケーションの効率を向上させる。

【0080】

いくつかの実施例において、データレプリケーション過程は非同期であってもよく、この場合、データレプリケーションとクリーンアップトランザクションの提出は関連せず、ノード機器のクリーンアップトランザクションは提出階段で、履歴状態データのストリーミングレプリケーションをトリガーせず、ノード機器とクラスタ機器との間のストリーミングレプリケーションは第１所定条件に規定される第２所定期間に従ってトリガーされ、２回のストリーミングレプリケーションの間の時間間隔内で、ノード機器で修正された履歴状態データをクラスタ機器にレプリケーションし、データレプリケーション過程が占有するデータ伝送リソースを節約する。

【0081】

上記ステップ２０４において、さらに、データレプリケーションの完成事項に対する確認に係り、この場合、再生確認レベル、受信確認レベル、送信確認レベルという３つの確認レベルに分けられ、以下詳しく説明する。

【0082】

再生確認レベルにおいて、ノード機器はクラスタ機器のレプリケーション成功応答を受信した場合に限り、１回のデータレプリケーションタスクが完成したと認め、データレプリケーション過程の強い同期を実現する。強い同期は、各回のデータレプリケーションが原子的であるように保証でき、即ち、データレプリケーションの過程全体は成功するかまたは失敗し、中間状態が存在しない。何れかの一環に異常があると、今回のデータレプリケーションが失敗したと認めて、今回のデータレプリケーション全体に対して再実行を行う必要があり、データレプリケーション過程の安全性を保証する。好ましくは、当該レプリケーション成功応答は「Ａｐｐｌｉｅｄ」命令である。

【0083】

受信確認レベルにおいて、ノード機器はクラスタ機器のデータ受信応答を受信した後、１回のデータレプリケーションタスクが完成したと認めて、データレプリケーション過程の弱い同期を実現する。弱い同期は、クラスタ機器のメタデータの再生作業以外、データレプリケーション過程における他の操作がいずれも原子的であるように保証でき、この場合、メタデータの再生が失敗しても、今回のデータレプリケーション全体の再実行を行う必要がなく、データレプリケーション効率を考慮すると同時に、ある程度で、データレプリケーション過程の安全性を保証する。好ましくは、当該データ受信応答は「Ｒｅｃｅｉｖｅｄ」命令である。

【0084】

送信確認レベルにおいて、ノード機器はデータ送信操作を完成した後、１回のデータレプリケーションタスクが完成したと認めて、この場合、データレプリケーション過程が原子的であるように保証できないが、ノード機器とクラスタ機器との間は、互いに影響しない。クラスタ機器に応答が生じて、ダウンなどの異常が発生しても、ノード機器が再びデータレプリケーションをトリガーすることを阻止しなく、クラスタ機器が具備するスタンドアロン機器の数が１つより多い場合、１つのスタンドアロン機器に異常があっても、他のスタンドアロン機器に対するデータレプリケーション過程は正常に行われて、データレプリケーションの効率を保障する。

【0085】

２０５：クラスタ機器は、受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも１つの履歴状態データを受信する。

【0086】

当該受信バッファは、データレプリケーションの過程において、循環使用される部分であってもよく、当該受信バッファは受信プロセス、または受信スレッドが受信タスク（ノード機器が送信した履歴状態データを受信する）を実行する際呼び出されるバッファであってもよく、受信プロセス、または受信スレッドの数は１つまたは複数であってもよいから、当該受信バッファの数も１つまたは複数であってもよく、本出願の実施例は１つの受信バッファを例として説明し、他の受信バッファが類似の履歴状態データの受信過程を有することに対して、ここで贅言しない。

【0087】

いくつかの実施例において、１つの受信バッファは１つのノード機器に対応してもよく、この場合、上記ステップ２０５は、クラスタ機器は、少なくとも１つの受信バッファからノード機器に対応する受信バッファを決定し、受信プロセス、または受信スレッドに基づき、当該ノード機器が送信した少なくとも１つの履歴状態データを当該受信バッファにキャッシングすることで、１つの受信バッファは、意図的に同一のノード機器からの履歴状態データを受信できる。

【0088】

無論、当該受信バッファとノード機器との間に対応関係が存在しなくてもよく、クラスタ機器が、受信バッファの現在の利用可能な記憶空間に基づき、データ受信タスクを割り当て、この場合、上記ステップ２０５は、クラスタ機器は少なくとも１つの受信バッファから、現在の利用可能な記憶空間が最大である受信バッファを決定し、受信プロセス、または受信スレッドに基づき、ノード機器が送信した少なくとも１つの履歴状態データを当該受信バッファにキャッシングすることで、クラスタ機器は履歴状態データを現在の利用可能な記憶空間が最大である受信バッファに追加し、キャッシングリソースの合理的な利用を実現する。

【0089】

２０６：クラスタ機器は、当該受信バッファにおける当該少なくとも１つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得し、当該転送バッファは履歴状態データに対してデータ形式の変換を行う。

【0090】

上記過程において、受信バッファは、履歴状態データを転送バッファに追加する（即ち、レプリケーション）過程は、同期レプリケーションと非同期レプリケーションという２つの方式を含んでもよい。

【0091】

同期レプリケーションの過程において、クラスタ機器は、受信バッファから履歴状態データ（１つまたは複数である可能性があるが、ノード機器が一度に送信するものである）を受信する度に、当該履歴状態データをすぐに転送バッファにレプリケーションする。

【0092】

非同期レプリケーションの過程において、クラスタ機器は、受信バッファから履歴状態データを受信し、第４所定期間ごとに、当該受信バッファにおける全ての履歴状態データを転送バッファにレプリケーションする。 第４所定期間は０以上の任意の値である。

【0093】

いくつかの実施例において、ノード機器が第２所定期間ごとにマイクロＣｈｅｃｋｐｏｉｎｔ操作を１回実行すると、上記ステップ２０６は、第２所定期間ごとに、クラスタ機器は受信バッファからノード機器が送信した少なくとも１つの履歴状態データを受信する。無論、何れかのノード機器に対しても、このように類推し、異なるノード機器の第２所定期間は同様、または異なってもよい。

【0094】

いくつかの実施例において、ＴＰクラスタの全てのノード機器が第３所定期間ごとにＣｈｅｃｋｐｏｉｎｔ操作を１回実行すると、上記ステップ２０６は、第３所定期間ごとに、クラスタ機器は受信バッファから、複数のノード機器が同時に送信した少なくとも１つの履歴状態データを受信し、ＴＰクラスタの異なるノード機器の間のデータ遅延が第３所定期間を超えないように保証し、ＡＰクラスタによる履歴状態データに対する記憶のリアルタイムの可用性を向上させる。

【0095】

いくつかの実施例において、同期レプリケーションであろうと、非同期レプリケーションであろうと、履歴状態データが成功に転送バッファにレプリケーションされた後、受信バッファにおいて今回でレプリケーションされた履歴状態データをクリアすることで、新しい履歴状態データを記憶するためのキャッシング空間を即時的にクリーンアップでき、データ伝送の速度を速くする。

【0096】

上記ステップ２０６において、ノード機器が送信する少なくとも１つの履歴状態データの形式は、圧縮後のデータ形式であるから、転送バッファにおいて、当該少なくとも１つの履歴状態データをタプル形式に合致する元のデータに回復することで、以下のステップ２０７を実行し、いくつかの実施例において、タプル形式に合致する当該データは行形式のデータであってもよい。

【0097】

２０７：クラスタ機器は、当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶し、１つのターゲットデータシートは、１つデータ項目が当該ノード機器において所在する１つのオリジナルデータシートに対応する。

【0098】

上記ステップにおいて、業務ニーズに基づき、ターゲットデータシートは２つの記憶形式を含んでもよいため、クラスタ機器が当該少なくとも１つのデータ項目をターゲットデータシートに記憶する際も、２つの相応的な記憶過程が存在し、以下詳しく説明する。
いくつかの実施例において、タプルを単位とするデータ項目に対して、クラスタ機器は当該データ項目が所在するオリジナルデータシートにおける記憶形式に従って、当該データ項目を当該オリジナルデータシートに対応するターゲットデータシートに記憶することで、ターゲットデータシートとオリジナルデータシートとの記憶形式が完全に同様になり、汎用の場合で、１つのタプルのライフサイクルを便利に追跡する。

【0099】

上記過程において、オリジナルデータシートとターゲットデータシートとの形式の一致を保証するために、何れかのノード機器とクラスタ機器とが接続を確立した後、論理レプリケーション技術（例えば、ＭｙＳＱＬのＢｉｎＬｏｇ技術）、または物理レプリケーション技術（例えばＰｏｓｔｇｒｅＳＱＬの、ＲＥＤＯ ＬＯＧによるレプリケーション技術）に基づき、クラスタ機器において、ノード機器における各オリジナルデータシートに対応する各ターゲットデータシートを確立する。なお、オリジナルデータシートは複数のタプルの現在状態データを記憶し、当該オリジナルデータシートに対応するターゲットデータシートは当該複数のタプルの履歴状態データを記憶する。

【0100】

上記ＢｉｎＬｏｇ（バイナリログ、論理ログとも称する）技術において、ＢｉｎＬｏｇはデータベースにおける操作を記録し、ＢｉｎＬｏｇにおいて、特定の形式でデータの変更、テーブル構成の変更などのデータベーストランザクション操作を説明し、ＢｉｎＬｏｇに記録できるトランザクション操作は、一般的に、提出またはロールバックが完了したものである。以下は、ＭｙＳＱＬデータベースの論理レプリケーション技術を例として説明し、ノード機器とクラスタ機器とが接続を確立した後、ノード機器には１つまたは複数のＤｕｍｐ－Ｔｈｒｅａｄスレッド（ダンプスレッド）が維持され、１つのＤｕｍｐ－Ｔｈｒｅａｄスレッドにより、１つのクラスタ機器とマッチングし、ノード機器とクラスタ機器とが論理レプリケーションを行う場合、以下のステップを実行する。

【0101】

クラスタ機器は、ノード機器に同期済みＢｉｎＬｏｇの情報（データファイル名及びデータファイル内の位置を含む）を送信し、ノードデータベースは同期済みＢｉｎＬｏｇの情報に基づき、現在の同期済み位置を決定する。ノード機器のＤｕｍｐ－Ｔｈｒｅａｄスレッドは、未同期のメタデータのＢｉｎＬｏｇデータをクラスタ機器に送信し、クラスタ機器はＩＯ－Ｔｈｒｅａｄ（ｉｎｐｕｔ／ｏｕｔｐｕｔ ｔｈｒｅａｄ、入出力スレッド）を介してノード機器による同期されたＢｉｎＬｏｇデータを受信し、ＢｉｎＬｏｇデータをＲｅｌａｙ－Ｌｏｇ（リレーログ）が所在するファイルに書き込み、クラスタ機器はＳＱＬ－Ｔｈｒｅａｄ（ＳＱＬスレッド）を介してＲｅｌａｙ－ＬｏｇファイルからＢｉｎＬｏｇデータを読み取り、ＢｉｎＬｏｇデータを復号化して得られたＳＱＬステートメントを実行し、これによって、ノード機器のメタデータを増分してクラスタ機器にレプリケーションする。

【0102】

いくつかの実施例において、フィールドの変更状況を示すデータ項目に対して、クラスタ機器はキー値ペア（ｋｅｙ－ｖａｌｕｅ）の記憶形式に従って、当該データ項目を当該オリジナルデータシートに対応するターゲットデータシートに記憶することで、データ項目にキャリアされた情報を保留できるだけではなく、キー値ペアの記憶形式により、何れかのフィールドの履歴状態データの変更状況をカスタマイズ的に追跡できる。

【0103】

上記キー値ペア形式による記憶過程において、ターゲットデータシートのキー名（ｋｅｙ）及びキー値（ｖａｌｕｅ）を決定する必要があり、いくつかの実施例において、具体的に、以下のような操作でキー名を決定する。即ち、クラスタ機器は、データ項目の、オリジナルデータシートにおけるキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該データ項目の、当該ターゲットデータシートにおけるキー名として決定する。オリジナルデータシートにキー名が存在する場合、オリジナルデータシートにおけるキー名及び当該データ項目の生成時間をターゲットデータシートにおけるキー名として決定してもよく、これによって、異なる次元から、履歴状態データの変更状況を追跡できる。無論、オリジナルデータシートにキー名が存在しないと、直接的にデータ項目の生成時間をターゲットデータシートにおけるキー名として決定してもよく、直観的にデータ項目の生成時間を記録できる。

【0104】

いくつかの実施例において、さらに以下のような操作でキー値を決定し、即ち、クラスタ機器は、オリジナルデータシートにおけるデータ項目の修正されたフィールドを、当該データ項目の、ターゲットデータシートにおけるキー値として決定してもよい。修正されたフィールドは１つの文字列の形式に類似し、各修正されたフィールドの記憶形式は、「キー名：旧い値、新しい値」であってもよく、修正されたフィールドは１つまたは複数であってもよい。複数のフィールドが同時に修正されると、修正されたフィールドの間は、セミコロンで区切られてもよい。

【0105】

例えば、図７は、本出願の実施例が提供するオリジナルデータシートの構成概略図である。図７を参照し、フィールドの変更状況を示す１つのデータ項目を例として説明し、オリジナルデータシートには、サーバー番号、サーバー状態、所属部門及び地区という４つのキー名が存在する。１回のトランザクション操作において、当該データ項目の「サーバー状態」及び「所属部門」を修正したと仮定し、図８は本出願の実施例が提供するターゲットデータシートの構成概略図である。図８を参照し、ターゲットデータシートから、「サーバー状態」、「所属部門」及び操作時間の動的な変更状況を直観的に観察でき、データ項目の「地区」が修正されていないため、ターゲットデータシートにおいて、「地区」の変更状況を表示する必要がなく、この場合、ターゲットデータシートにおいて、各キー値の記憶形式は「サーバー状態：サービス提供、サービス中断；所属部門：部門Ａ、部門Ｂ」であってもよい。

【0106】

いくつかの実施例において、クラスタ機器はさらに記憶プロセス、または記憶スレッドを介して、転送バッファにおけるデータ項目をストレージインターフェース（ｓｔｏｒａｇｅ ｉｎｔｅｒｆａｃｅ）により分散型ファイルシステムにアップロードし、永続性記憶することで、履歴状態データの無限記憶を実現してもよい。

【0107】

分散型ファイルシステムがＣｅｐｈであり、クラスタ機器のクラスタデータベースがＭｙＳＱＬであることを例として説明し、ＭｙＳＱＬでは、２つの方式でＣｅｐｈをマウンティングでき、例えば、ＣｅｐｈＦＳをマウンティングすることで、配置を完了し、この場合、クラスタ機器に１つのモニター（Ｍｏｎｉｔｏｒ）機器（ｎｏｄｅ１）及び２つのスタンドアロン機器（ｎｏｄｅ２及びｎｏｄｅ３）が含まれると仮定し、具体的に以下のステップを実行する。

【0108】

まず、クラスタ機器は、ディレクトリを構築し、ｂｏｏｔｓｔｒａｐ ｋｅｙｒｉｎｇファイルを準備し、「ｓｕｄｏ ｍｋｄｉｒ－ｐ／ｖａｒ／ｌｉｂ／ｃｅｐｈ／ｍｄｓ／ｃｅｐｈ－ｌｏｃａｌｈｏｓｔ」命令で実現でき、ディレクトリを構築した後、Ｃｅｐｈはモニター機器が所在するｎｏｄｅ１でｂｏｏｔｓｔｒａｐ ｋｅｙｒｉｎｇファイルを自動に生成し、この場合、ｂｏｏｔｓｔｒａｐ ｋｅｙｒｉｎｇファイルをｎｏｄｅ２及びｎｏｄｅ３にレプリケーションし、「／ｖａｒ／ｌｉｂ／ｃｅｐｈ／ｂｏｏｔｓｔｒａｐ－ｏｓｄ／ｃｅｐｈ．ｋｅｙｒｉｎｇ」命令でレプリケーションする。ここでは、クラスタ機器に２つのスタンドアロン機器が含まれることを例として説明し、クラスタ機器に２つ以上のスタンドアロン機器が含まれると、他のスタンドアロン機器でＣｅｐｈＦＳをマウンティングするとともに、ｂｏｏｔｓｔｒａｐ ｋｅｙｒｉｎｇファイルを当該スタンドアロン機器にレプリケーションしなければならない。

【0109】

そして、クラスタ機器は、ｄｏｎｅファイル及びｓｙｓｖｉｎｉｔファイルを生成し、いくつかの実施例において、クラスタ機器はステートメント「ｓｕｄｏ ｔｏｕｃｈ／ｖａｒ／ｌｉｂ／ｃｅｐｈ／ｍｄｓ／ｃｅｐｈ－ｍｏｎ１／ｄｏｎｅ」を介してｄｏｎｅファイルを生成し、ステートメント「ｓｕｄｏ ｔｏｕｃｈ／ｖａｒ／ｌｉｂ／ｃｅｐｈ／ｍｄｓ／ｃｅｐｈ－ｍｏｎ１／ｓｙｓｖｉｎｉｔ」を介してｓｙｓｖｉｎｉｔファイルを生成する。

【0110】

そして、クラスタ機器は、ｍｄｓのｋｅｙｒｉｎｇファイルを生成し、いくつかの実施例において、クラスタ機器はステートメント「ｓｕｄｏ ｃｅｐｈ ａｕｔｈ ｇｅｔ－ｏｒ－ｃｒｅａｔｅ ｍｄｓ．ｍｏｎ１ｏｓｄ'ａｌｌｏｗ ｒｗｘ'ｍｄｓ'ａｌｌｏｗ'ｍｏｎ'ａｌｌｏｗ ｐｒｏｆｉｌｅ ｍｄｓ'－ｏ／ｖａｒ／ｌｉｂ／ｃｅｐｈ／ｍｄｓ／ｃｅｐｈ－ｍｏｎ１／ｋｅｙｒｉｎｇ」を介してｋｅｙｒｉｎｇファイルを生成する。

【0111】

そして、クラスタ機器は、Ｃｅｐｈｆｓのｐｏｏｌを構築し、いくつかの実施例において、クラスタ機器はステートメント「ｃｅｐｈ ｏｓｄ ｐｏｏｌ ｃｒｅａｔｅ ｃｅｐｈｆｓ＿ｄａｔａ ３００」を介してＣｅｐｈｆｓのｐｏｏｌのデータを構築し、ステートメント「ｃｅｐｈ ｏｓｄ ｐｏｏｌ ｃｒｅａｔｅ ｃｅｐｈｆｓ＿ｍｅｔａｄａｔａ ３００」を介してＣｅｐｈｆｓのｐｏｏｌのメタデータを構築する。

【0112】

そして、クラスタ機器は、ＭＤＳファイル（ミラーリングファイル） を起動させ、いくつかの実施例において、クラスタ機器はステートメント「ｓｕｄｏ／ｅｔｃ／ｉｎｉｔ．ｄ／ｃｅｐｈ ｓｔａｒｔ|ｓｔｏｐ ｍｄｓ．ｌｏｃａｌｈｏｓｔ」を介してＭＤＳを起動させる。

【0113】

最後、クラスタ機器は、Ｃｅｐｈｆｓを構築し及びＣｅｐｈｆｓをマウンティングし、いくつかの実施例において、クラスタ機器はステートメント「ｃｅｐｈｆｓ ｎｅｗ ｃｅｐｈｆｓ ｃｅｐｈｆｓ＿ｍｅｔａｄａｔａ ｃｅｐｈｆｓ＿ｄａｔａ」を介してＣｅｐｈｆｓを構築し、構築が完成した後、クラスタ機器はステートメント「ｍｏｕｎｔ－ｔ ｃｅｐｈ［ｍｏｎモニター機器ｉｐアドレス］：６７８９：／／ｍｎｔ／ｍｙｃｅｐｈｆｓ」を介してＣｅｐｈｆｓのマウンティングを完成させる。

【0114】

好ましくは、クラスタ機器は、さらにＣｅｐｈのＲＢＤ（ミラーリングファイル）をマウンティングする方式で配置を完了し、具体的に、以下のステップを実行する。
まず、クラスタ機器は、ＲＢＤのｐｏｏｌを構築し、例えば、ステートメント「ｃｅｐｈ ｏｓｄ ｐｏｏｌ ｃｒｅａｔｅ ｒｂｄ ２５６」を介して構築する。

【0115】

そして、クラスタ機器は、ＲＢＤブロック機器ｍｙｒｂｄを構築し（即ち、１つのブロック記憶空間を申請する）、例えば、ステートメント「ｒｂｄ ｃｒｅａｔｅ ｒｂｄ／ｍｙｒｂｄ－－ｓｉｚｅ ２０４８００－ｍ［ｍｏｎモニター機器ｉｐアドレス］－ｋ／ｅｔｃ／ｃｅｐｈ／ｃｅｐｈ．ｃｌｉｅｎｔ．ａｄｍｉｎ．ｋｅｙｒｉｎｇ」を介して構築する。

【0116】

そして、クラスタ機器は、ＲＢＤマッピングを構築し、機器名称を取得し、ＲＢＤをモニター機器にマッピングし、例えばステートメント「ｓｕｄｏ ｒｂｄ ｍａｐ ｒｂｄ／ｍｙｒｂｄ－－ｎａｍｅ ｃｌｉｅｎｔ．ａｄｍｉｎ－ｍ［ｍｏｎモニター機器ｉｐアドレス］－ｋ／ｅｔｃ／ｃｅｐｈ／ｃｅｐｈ．ｃｌｉｅｎｔ．ａｄｍｉｎ．ｋｅｙｒｉｎｇ」を介してマッピングを行うとともに、モニター機器の名称を取得し、ここでは、モニター機器にマウンティングされることを例として説明する。実際には、どのスタンドアロン機器にマウンティングしようとすると、ＲＢＤを当該スタンドアロン機器にマッピングして、当該スタンドアロン機器の名称を取得するという操作を実行する。

【0117】

最後、クラスタ機器は、取得した機器名称に基づき、ファイルシステムを構築し、ＲＢＤをマウンティングし、例えばステートメント「ｓｕｄｏ ｍｋｆｓ．ｘｆｓ／ｄｅｖ／ｒｂｄ１」を介してファイルシステムを構築し、ステートメント「ｓｕｄｏ ｍｏｕｎｔ／ｄｅｖ／ｒｂｄ１／ｍｎｔ／ｍｙｒｂｄ」を介してＲＢＤをマウンティングする。

【0118】

なお、いくつかの実施例において、クラスタ機器がストレージインターフェースを介して分散型ファイルシステムにアクセスできるだけではなく、ＴＰクラスタにおける何れかのノード機器も、ストレージインターフェースを介して分散型ファイルシステムにアクセスでき、いずれも上記類似のマウンティング方式を実行して、配置を完成でき、ここで贅言しない。

【0119】

２０８：クラスタ機器は、ノード機器にレプリケーション成功応答を送信する。

【0120】

上記過程において、クラスタ機器は、履歴状態データを成功にターゲットデータシートに記憶した後、クラスタ機器はノード機器にＡＣＫデータ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、確認文字）を送信し、当該ＡＣＫデータは伝送類の制御文字であり、ノード機器が送信した履歴状態データを成功にレプリケーションしたことを示す。

【0121】

２０９：ノード機器は、当該クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、当該レプリケーション成功応答に対応する送信バッファをクリアする。

【0122】

上記過程において、ノード機器はレプリケーション成功応答を受信した場合に限り、送信バッファをクリアすることを許可し、ノード機器とクラスタ機器との間の強い同期、及びデータレプリケーション過程の安全性を保証する。

【0123】

上記全ての好適な技術案に対して、任意に組み合わせで本開示の好適な実施例を形成でき、ここで、一々贅言しない。

【0124】

本出願の実施例が提供する方法において、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、当該トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも１つの履歴状態データを送信バッファに追加し、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は、第１所定条件に合致する度に、送信バッファにおける履歴状態データをクラスタ機器にレプリケーションし、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器もログをデータのオリジナル形式に解析した後、記憶する必要がなく、これによって、データをレプリケーションする際、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。

【0125】

また、ノード機器は、履歴状態データを同期的にレプリケーションすることで、履歴状態データがトランザクション提出の先後順序に従ってクラスタ機器にレプリケーションされるように保証し、履歴状態データをソートするというステップの実行を避け、ストリーミングレプリケーション過程のフローを簡略化する。無論、ノード機器は、データキューにおける履歴状態データを非同期的に送信バッファにレプリケーションすることで、データキューにおける履歴状態データを一括に送信バッファに追加し、履歴状態データのレプリケーション操作を頻繁に実行することを避け、さらに、ノード機器の処理効率に影響することを避けてもよいが、非同期レプリケーションの前に、履歴状態データをソートして、履歴状態データが順序付けられて送信バッファに追加されることを保証する必要があり、後続のクラスタ機器が最小のトランザクション標識を便利に取得できる。

【0126】

また、第１所定条件に合致すると、送信バッファはクラスタ機器に履歴状態データをレプリケーションし、レプリケーションが成功した後、送信バッファをクリアし、その後、送信バッファは履歴状態データの追加及び履歴状態データの送信という過程を循環的に実行し、ノード機器の履歴状態データをクラスタ機器に絶えずにレプリケーションし、履歴状態データに対して再実行ログの再生を行うことを避け、データレプリケーション過程の効率を向上させる。

【0127】

また、送信バッファの数が複数である場合、ノード機器はデータキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加することで、複数の送信バッファの利用率を向上させ、当該オリジナルデータシートにおける履歴状態データに対する送信レートを向上させる。

【0128】

また、第１所定条件が、ノード機器が送信バッファに何れかの履歴状態データが増えたことを検出したことである場合、データレプリケーションの同期レプリケーションを実現でき、履歴状態データレプリケーション過程のリアルタイム性を保障する。第１所定条件が、ノード機器が当該送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことである場合、送信バッファ容量に対する送信バッファの使用済みデータ量の占有比率を、比率閾値内に制御でき、データレプリケーション過程の効率を向上させる。第１所定条件が、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達したことである場合、２回のデータレプリケーションの間の最大の時間間隔を制御でき、履歴状態データレプリケーション過程のリアルタイム性を保障する。第１所定条件が、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第３所定期間に達したことである場合、第３所定期間はＴＰクラスタの各ノード機器が具備する同じ所定期間であるから、ＴＰクラスタの異なるノード機器のデータレプリケーション過程の遅延を制御できる。

【0129】

また、クラスタ機器は、受信バッファからノード機器が送信した少なくとも１つの履歴状態データを受信した後、当該受信バッファにおける当該少なくとも１つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得し、これによって、圧縮された履歴状態データの形式を回復し、元の形式を保留する履歴状態データを直接的に取得するため、ログを解析して履歴状態データを取得することを避け、当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶し、履歴状態データに対する適切な保存を実現する。

【0130】

また、業務のニーズに基づき、クラスタ機器のターゲットデータシートでは、２つの記憶形式を支持でき、タプルを単位とするデータ項目に対して、クラスタ機器はオリジナルデータシートにおける記憶形式に従って記憶でき、これによって、汎用の場合、１つのタプルのライフサイクルを便利に追跡する。フィールドの変更状況を示すデータ項目に対して、クラスタ機器はキー値ペアの記憶形式に従って記憶して、データ項目にキャリアされた情報を保留できるだけではなく、何れかのフィールドの履歴状態データの変更状況をカスタマイズ的に追跡できる。

【0131】

また、キー値ペア形式による記憶過程において、クラスタ機器は、オリジナルデータシートにおけるデータ項目のキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該ターゲットデータシートにおける当該データ項目のキー名として決定することで、異なる次元から履歴状態データの変更状況を追跡し、直観的にデータ項目の生成時間を記録し、さらに、クラスタ機器は、データ項目のオリジナルデータシートにおいて修正されたフィールドを、ターゲットデータシートにおける当該データ項目のキー値として決定し、直観的に修正されたフィールドを確認し、何れかのフィールドの履歴状態データの変更状況を追跡できる。

【0132】

上記実施例は、データレプリケーション方法を提供し、第１所定条件に合致する場合、ノード機器はストリーミングレプリケーション技術に基づき、履歴状態データをクラスタ機器にレプリケーションし、履歴状態データの安全性を向上させ、クラスタ機器は履歴状態データを適切に記憶した後、外部に、履歴状態データの検索、または分析などのサービスを提供できる。

【0133】

上記実施例において、１つのトランザクションに１つまたは複数のサブトランザクションが含まれることを言及した。異なるサブトランザクションは異なるノード機器に対応し、ノード機器は第２所定期間ごとにデータレプリケーション過程を１回実行してもよいが、異なるノード機器の開始時点は異なってもよいため、ノード機器の間のデータレプリケーションは非同期である可能性がある。従って、いくつかのシーンにおいて、同一の提出されたトランザクションにとって、当該トランザクションの１つまたは複数のサブトランザクションに対応するノード機器はデータレプリケーションの過程において非同期であるため、あるノード機器は既にサブトランザクションに対応する履歴状態データをクラスタ機器にレプリケーションしたが、あるノード機器はサブトランザクションに対応する履歴状態データをクラスタ機器にレプリケーションしていないという状況の発生を招致し、さらに、クラスタ機器が同一のトランザクションにより影響される全ての履歴状態データを完全に読み取ることができず、ＡＰクラスタがデータを読み取る際、「不一致性」という問題が生じる。

【0134】

クラスタ機器の読み取りの「不一致性」という問題を解決するために、本出願はさらにデータ検索方法を提供し、図９は、本出願の実施例が提供するデータ検索過程のフローチャートであり、図９を参照し、クラスタ機器で、履歴状態データを読み取るステップは以下のようである。

【0135】

９０１：クラスタ機器は、トランザクション提出タイムスタンプの昇順に従って、少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、ターゲットデータシーケンスを取得する。

【0136】

上記ソート過程は、トランザクション標識の値の昇順に従ってソートすることを指し、１つのトランザクションが他のトランザクションの前にあると、１つのトランザクションのトランザクション標識の値が、他のトランザクションのトランザクション標識の値より小さく、異なるトランザクションのトランザクション標識において、１つのトランザクションの提出タイミングが遅いほど、当該トランザクションのトランザクション標識の値が大きい。従って、トランザクション標識の値は、実際に提出タイミングのタイムスタンプに従って漸増する。上記ステップ９０１のソート過程は上記ステップ２０３と類似するから、ここで贅言しない。

【0137】

上記過程において、各ノード機器の少なくとも１つの送信バッファはデータを送信する前に、いずれもソートが行われたが、クラスタ機器には少なくとも１つの受信バッファが設けられるため、各受信バッファが受信した履歴状態データは順序付けられるが（段階的に順序付けられる状況とみなしてもよい）、全ての受信バッファの履歴状態データは綜合的に順序付けられるように保証できないため、クラスタ機器は上記ステップ９０１を実行し、各受信バッファが受信した少なくとも１つの履歴状態データをソートする必要があり、当該少なくとも１つの履歴状態データは、複数のノード機器が送信した履歴状態データである。

【0138】

上記過程において、ＴＰクラスタは、定期的にＣｈｅｃｋｐｏｉｎｔ操作を１回実行するため、クラスタ機器は少なくとも１つの受信バッファからＣｈｅｃｋｐｏｉｎｔ操作により送信される少なくとも１つの履歴状態データを受信する度に、受信した少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプに従って順序付けられ、且つトランザクション標識に従って順序付けられるターゲットデータシーケンスを取得し、この場合、読み取りの一致性を保証するために、以下のステップ９０２～９０３を実行する。

【0139】

９０２：クラスタ機器は、当該ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットＡＮＤ操作を実行し、出力が真である履歴状態データに対応するトランザクションが、第２所定条件に合致すると決定する。

【0140】

上記ステップ２０４で言及したように、何れかのノード機器はクラスタ機器に履歴状態データを送信する際、１つのトランザクションの１つまたは複数のサブトランザクションが１つまたは複数のノード機器に対応するため、当該トランザクションに関連するノード機器（即ち、サブトランザクションに対応するノード機器）を記録するために、一般的に、ビットマップ符号化、または辞書圧縮などの方式で、当該１つまたは複数のノード機器のノード標識を符号化することで、履歴状態データの長さを圧縮し、データ伝送が占有するリソースを減少させる。

【0141】

当該少なくとも１つのトランザクションは、第２所定条件に合致するトランザクションであり、当該第２所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目が、いずれもクラスタデータベースに記憶されたことを示す。

【0142】

上記ステップ９０２において、クラスタ機器は、当該ターゲットデータシーケンスから、当該第２所定条件に合致する少なくとも１つのトランザクションを取得し、少なくとも１つのトランザクションを取得する方式は、ノード機器の、履歴状態データに対する圧縮方式で决定される。

【0143】

上記過程は、ノード機器がビットマップ符号化を利用して、データを圧縮する場合、第２所定条件に合致する少なくとも１つのトランザクションを決定する方法を提供し、即ち、ターゲットデータシーケンスにおける各履歴状態データに対してビットＡＮＤ操作を行って、全てのビットがいずれも１（真）であれば、当該履歴状態データに対応するトランザクションが第２所定条件に合致することを示し、なぜならば、当該トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶され、この場合、当該少なくとも１つのトランザクションは「候補一致性ポイント」と称する。

【0144】

いくつかの実施例において、ノード機器が辞書圧縮という方式でデータを圧縮する場合、上記ステップ９０２はさらに以下の方式で差し替えられてもよく、即ち、クラスタ機器は当該ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定した場合、当該グローバルトランザクション標識に対応するトランザクションが当該第２所定条件に合致すると決定し、これによって、辞書圧縮という状況に対しても、候補一致性ポイントを決定でき、そして、以下のステップ９０３を介して、候補一致性ポイントから「完備の最小のトランザクションＩＤ」を見つける。

【0145】

なお、１つのトランザクションが複数のサブトランザクションを含むと、当該トランザクションは１つの「グローバルトランザクション」と称し、１つのグローバルトランザクションは、当該トランザクションに係る複数のサブトランザクションが複数のノード機器に対応することを意味し、そうすれば、何れかのグローバルトランザクションにとって、グローバルトランザクション標識及びローカルトランザクション標識という２つのタイプのトランザクション標識を含む。グローバルトランザクション標識は、ＴＰクラスタ全体において全てのグローバルトランザクションにおける唯一の標識情報を示し、ローカルトランザクション標識は、それぞれのノード機器において全てのトランザクションにおける唯一の標識情報を示し、１つのグローバルトランザクションにとって、全てのサブトランザクションは同じグローバルトランザクション標識を有し、各サブトランザクションはそれぞれのローカルトランザクション標識を有する。

【0146】

上記に基づき、グローバルトランザクション標識に対応するサブトランザクションのデータ項目はいずれも当該クラスタデータベースに記憶されたと決定する過程は以下のようであってもよい。即ち、クラスタ機器は、当該グローバルトランザクション標識に基づき、当該クラスタデータベースに記憶され、且つ当該グローバルトランザクション標識を有するデータ項目を取得し、取得した当該データ項目及び復号化による得られた当該履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定する。

【0147】

９０３：クラスタ機器は、当該少なくとも１つのトランザクションにおける、順番が最も前にあるトランザクションに対応するトランザクション標識を最小トランザクション標識として決定する。

【0148】

上記過程において、クラスタ機器は、ステップ９０１において各履歴状態データに対してトランザクション標識の昇順に従ってソートを行っているため、少なくとも１つのトランザクションにおける、順番が最も前にあるトランザクションに対応するトランザクション標識を直接的に取得でき、つまり、少なくとも１つのトランザクションのトランザクション標識における最小トランザクション標識を取得し、ノード機器において、トランザクション標識はタイムスタンプに従って漸増するため、最小トランザクション標識を取得することは、今回のＣｈｅｃｋｐｏｉｎｔ操作により受信した履歴状態データにおいて最も完備（第２所定条件に合致する）且つタイムスタンプが最小であるトランザクションを取得することを意味し、当該最小トランザクション標識は「完備の最小のトランザクションＩＤ」と称し、トランザクションＩＤが当該最小トランザクション標識より小さいデータ項目に対して、「マイクロ一致性ポイント」と見なしてもよい。

【0149】

上記ステップ９０１～９０３において、クラスタ機器は、少なくとも１つの履歴状態データのトランザクション標識から、第２所定条件に合致する最小トランザクション標識を決定し、当該第２所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶されたことを示し、これによって、今回のＣｈｅｃｋｐｏｉｎｔ操作における完備の最小のトランザクションＩＤを見つける。いくつかの実施例において、今回のＣｈｅｃｋｐｏｉｎｔ操作で、前回のＣｈｅｃｋｐｏｉｎｔ操作により決定された最小トランザクション標識より大きい新しいラウンドの最小トランザクション標識を発見できないと、最小トランザクション標識をしばらく更新せず、ＴＰクラスタの次回のＣｈｅｃｋｐｏｉｎｔ操作で、上記ステップ９０１～９０３の操作を実行し、新しい最小トランザクション標識を決定した後、以下のステップ９０４を実行し、ＴＰクラスタで、新しいトランザクションの持続的な提出過程において、トランザクション標識がより大きい履歴状態データが絶えず生じるように保証し、これらの履歴状態データはＣｈｅｃｋｐｏｉｎｔ操作を介してＡＰクラスタに保存され、その同時、ＡＰクラスタは最小トランザクション標識の値を絶えず更新することで、完備の最小のトランザクションＩＤの値がますます大きくなり、前にスクロールする過程と類似し、ＡＰクラスタによるデータ検索サービスの提供のリアルタイム性を保障する。

【0150】

９０４：クラスタ機器は、当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供し、当該可視データ項目のトランザクション標識は、当該最小トランザクション標識の以下である。

【0151】

上記ステップ９０４において、クラスタ機器は、ＭＶＣＣ技術のタプル可視性判定アルゴリズムに基づき、トランザクション標識が当該最小トランザクション標識の以下であるデータ項目を外部に可視にして、マイクロＣｈｅｃｋｐｏｉｎｔ操作メカニズムでの、ＡＰクラスタの読み取り一致性を保障する。

【0152】

いくつかの実施例において、クラスタ機器が可視データ項目に基づきデータ検索サービスを提供する場合、フル状態データの任意の読み取り操作の読み取り一致性を実現でき、なぜならば、読み取り一致性は本質で、履歴状態データに基づき構築されるトランザクション一致性とみなしてもよいため、読み取り一致性を実現すると、ＡＰクラスタから読み取られた任意の時点の履歴状態データがいずれも１つのトランザクション一致性ポイントにあることを確保する。

【0153】

例えば、図１０は、本出願の実施例が提供するトランザクション一致性ポイントの原理的な概略図である。図１０を参照し、クラスタデータベースには、ｒ１、ｒ２、ｒ３（三者はＡＰクラスタにおける異なるスタンドアロン機器に分布されてもよい）という３つのデータ項目が存在すると仮定する。初期のデータ状態は白い丸で示し、ｒ１、ｒ２、ｒ３は一致性状態（実線で示す）にあり、新しいトランザクションが生じると、データのバージョンを変更させ、例えば、Ｔ１トランザクションはｔ１タイミングで提出され、データ項目ｒ１を修正し、ｒ１の１つの新バージョンを生成し、図面において黒い丸で示す。その後、トランザクションＴ２はｔ２タイミングで提出され、データ項目ｒ２及びｒ３を修正し、ｒ２とｒ３との新バージョンを生成し、図面において斜線の丸で示し、そして、Ｔ３トランザクションはｔ３タイミングで提出され、データ項目ｒ１及びｒ３を修正し、ｒ１とｒ３との新バージョンを生成し、図面において、グリッド丸で示す。そして、Ｔ４トランザクションはｔ４タイミングで提出され、データ項目ｒ２を修正し、ｒ２の新バージョンを生成し、図面において、点付け丸で示す。Ｔ１～Ｔ４という一連のトランザクションの操作を経て、フル状態データの次元から観察し、図面に示す実線、長破線、短破線、破線、点線という５つの一致性状態が生じて、各線分はいずれも１つの一致性状態を代表できる。そうすれば、ｔ１．５、ｔ３．５などの履歴タイミングの履歴状態データを検索しようとすると、図面の曲線に示すデータバージョンが所在し、一致性状態に合致する履歴状態データ（いずれもトランザクション一致性を満たす）を介してデータ検索サービスを提供できる。

【0154】

いくつかの実施例において、ユーザは、図１のＳＲ層が提供する検索ステートメント、検索操作のセマンティック及びメタデータに基づき、ＴＰクラスタまたはＡＰクラスタ内に記憶される何れかのデータをルーティング検索でき、無論、ＴＰクラスタは主に現在状態データに対する検索サービスを提供し、ＡＰクラスタは主に履歴状態データに対する検索サービスを提供する。

【0155】

好ましくは、ＴＰクラスタが現在状態（または遷移状態）データに対する検索サービスを提供する場合、分散型並行アクセス制御アルゴリズムに基づき現在状態（または遷移状態）データのトランザクション一致性を保証し、例えば、当該分散型並行アクセス制御アルゴリズムは、ブロッキング技術による並行アクセス制御アルゴリズム、ＯＣＣ（ｏｐｔｉｍｓｔｉｃ ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ、楽観的並行性制御）技術による並行アクセス制御アルゴリズム、ＴＯ（ｔｉｍｅ ｏｒｄｅｒｉｎｇ、時系列）技術による並行アクセス制御アルゴリズム、ＭＶＣＣ技術による並行アクセス制御アルゴリズムなどであってもよく、本出願の実施例は分散型並行アクセス制御アルゴリズムのタイプを具体的に限定しない。

【0156】

好ましくは、ＡＰクラスタは、履歴状態データに対する検索サービスを提供する場合、上記トランザクション一致性の基礎に基づき、一致性条件を満たす履歴状態データを読み取る。

【0157】

いくつかの実施例において、ＨＴＡＣアーキテクチャ全体はさらに、複合検索のサービスを提供でき、即ち、１つの検索操作は同時にタプルの現在状態データ及び履歴状態データに対する検索に用いられ、当該検索操作は一般的に、１つの履歴の時点を指定し、現在タイミングの現在状態データを検索するまで、当該時点からタプルの履歴状態データを持続的に読み取る。

【0158】

例えば、以下のステートメントに基づき複合検索を実現できる。
ＳＥＬＥＣＴ
［ＡＬＬ|ＤＩＳＴＩＮＣＴ|ＤＩＳＴＩＮＣＴＲＯＷ］
［ＨＩＧＨ＿ＰＲＩＯＲＩＴＹ］
［ＳＴＲＡＩＧＨＴ＿ＪＯＩＮ］
［ＳＱＬ＿ＳＭＡＬＬ＿ＲＥＳＵＬＴ］［ＳＱＬ＿ＢＩＧ＿ＲＥＳＵＬＴ］［ＳＱＬ＿ＢＵＦＦＥＲ＿ＲＥＳＵＬＴ］
［ＳＱＬ＿ＣＡＣＨＥ|ＳＱＬ＿ＮＯ＿ＣＡＣＨＥ］［ＳＱＬ＿ＣＡＬＣ＿ＦＯＵＮＤ＿ＲＯＷＳ］
ｓｅｌｅｃｔ＿ｅｘｐｒ［,ｓｅｌｅｃｔ＿ｅｘｐｒ．．．］
［ＦＲＯＭ ｔａｂｌｅ＿ｒｅｆｅｒｅｎｃｅｓ
［ＰＡＲＴＩＴＩＯＮ ｐａｒｔｉｔｉｏｎ＿ｌｉｓｔ］
［ＷＨＥＲＥ ｗｈｅｒｅ＿ｃｏｎｄｉｔｉｏｎ］
［ＧＲＯＵＰ ＢＹ｛ｃｏｌ＿ｎａｍｅ|ｅｘｐｒ|ｐｏｓｉｔｉｏｎ｝
［ＡＳＣ|ＤＥＳＣ］,．．．［ＷＩＴＨ ＲＯＬＬＵＰ］］
［ＨＡＶＩＮＧ ｗｈｅｒｅ＿ｃｏｎｄｉｔｉｏｎ］
［ＯＲＤＥＲ ＢＹ｛ｃｏｌ＿ｎａｍｅ|ｅｘｐｒ|ｐｏｓｉｔｉｏｎ｝
［ＡＳＣ|ＤＥＳＣ］,．．．］
［ＬＩＭＩＴ｛［ｏｆｆｓｅｔ,］ｒｏｗ＿ｃｏｕｎｔ|ｒｏｗ＿ｃｏｕｎｔ ＯＦＦＳＥＴ ｏｆｆｓｅｔ｝］
［ＰＲＯＣＥＤＵＲＥ ｐｒｏｃｅｄｕｒｅ＿ｎａｍｅ（ａｒｇｕｍｅｎｔ＿ｌｉｓｔ）］
［ＩＮＴＯ ＯＵＴＦＩＬＥ'ｆｉｌｅ＿ｎａｍｅ'
［ＣＨＡＲＡＣＴＥＲ ＳＥＴ ｃｈａｒｓｅｔ＿ｎａｍｅ］
ｅｘｐｏｒｔ＿ｏｐｔｉｏｎｓ
|ＩＮＴＯ ＤＵＭＰＦＩＬＥ'ｆｉｌｅ＿ｎａｍｅ'
|ＩＮＴＯ ｖａｒ＿ｎａｍｅ［,ｖａｒ＿ｎａｍｅ］］
［ＦＯＲ ＵＰＤＡＴＥ|ＬＯＣＫ ＩＮ ＳＨＡＲＥ ＭＯＤＥ］］

【0159】

上記ステートメントにおいて、ｔａｂｌｅ＿ｒｅｆｅｒｅｎｃｅｓの形式は、ｔｂｌ＿ｎａｍｅ［［ＡＳ］ａｌｉａｓ］［ｉｎｄｅｘ＿ｈｉｎｔ］［ＳＮＡＰＳＨＯＴ ＳＴＡＲＴ ｓｎａｐｓｈｏｔ＿ｎａｍｅ［ＴＯ ｓｎａｐｓｈｏｔ＿ｎａｍｅ２］［ＷＩＴＨ ｔｙｐｅ］］という形式であってもよい。

【0160】

ＳＮＡＰＳＨＯＴは、トランザクションスナップショット（データブロックのデータスナップショットと異なる）であり、スナップショットと略称し、「［ＳＮＡＰＳＨＯＴ［ＳＴＡＲＴ ｓｎａｐｓｈｏｔ＿ｎａｍｅ］［ＴＯ ｓｎａｐｓｈｏｔ＿ｎａｍｅ２］［ＷＩＴＨ ｔｙｐｅ］］」は、１つの「ｔｂｌ＿ｎａｍｅ」オブジェクトに対して１つのスナップショット区間を指定することを示し、ＤＱＬ（ｄａｔａ ｑｕｅｒｙ ｌａｎｇｕａｇｅ、データ検索言語）を基に新たに追加した内容であり、ステートメントの全ての句はいずれも （ＳＮＡＰＳＨＯＴ、ＳＴＡＲＴ、ＴＯ）を含み、「スナップショット読み取り始め」を示し、即ち、他のスナップショットを読み取るまで、１つのスナップショットから読み取り始める。

【0161】

本出願の実施例が提供するデータ検索過程は、ＨＴＡＣアーキテクチャでの全体の読み取り一致性を保証し、ＴＰクラスタの読み取り一致性だけではなく、ＡＰクラスタの読み取り一致性も保証し、ＡＰクラスタの内部で、Ｃｈｅｃｋｐｏｉｎｔ操作が作用される履歴状態データを１回受信する度に、１つの新しい最小トランザクション標識（完備の最小のトランザクションＩＤ）の取得を試し、即ち、最小トランザクション標識の値の更新を試し、ＭＶＣＣ技術のタプル可視性判定アルゴリズムに基づき、トランザクション標識が最小トランザクション標識より小さいトランザクションに対応するデータ項目を可視にして、ＡＰクラスタに記憶される履歴状態データのトランザクションにおけるトランザクション一致性を保証する。ＨＴＡＣがさらに外部一致性（線形一致性、因果一致性などを含む）を支持する場合、外部一致性及びトランザクション一致性は全体的に、グローバル一致性とみなしてもよく、ＨＴＡＣアーキテクチャに基づきトリガーされる何れかの１項の読み取り操作はグローバル一致性を満たし、Ｃｈｅｃｋｐｏｉｎｔ操作に起因して、一定のデータ遅延を招致するが、ＡＰクラスタは大体リアルタイムに、分析類業務の、データ正確性とリアルタイム性に対する検索需要、及び計算需要を満たすと認めてもよい。

【0162】

上記実施例は、データレプリケーション方法に基づきデータ検索を実行する過程を提供し、第１所定条件に合致する場合、ノード機器はストリーミングレプリケーション技術に基づき、履歴状態データをクラスタ機器にレプリケーションすることで、クラスタ機器は履歴状態データの検索、分析などのサービスを提供でき、履歴状態データの安全性及び可用性を向上させる。

【0163】

いくつかの実施例において、ＴＰクラスタにおける各ノード機器に対してＣｈｅｃｋｐｏｉｎｔ操作をトラバースして１回実行すると、ＴＰクラスタがＡＰクラスタにデータをレプリケーションすることにかかる期間が大きく増えて、さらに、ＨＴＡＣのパフォーマンスが不安定で、ＨＴＡＣの安定性及びロバスト性に影響するから、マイクロＣｈｅｃｋｐｏｉｎｔ操作を導入する。

【0164】

図１１は、本出願の実施例が提供するデータシステムのインタラクションフローチャートである。図１１を参照し、当該データシステムはＡＰクラスタのクラスタ機器及びＴＰクラスタの複数のノード機器を含み、以下はＴＰクラスタがＡＰクラスタに対してマイクロＣｈｅｃｋｐｏｉｎｔ操作及びＣｈｅｃｋｐｏｉｎｔ操作を実行する過程を、詳しく説明する。

【0165】

１１０１：第２所定期間ごとに、当該複数のノード機器のうちの何れかのノード機器に対して、当該ノード機器の少なくとも１つの履歴状態データを当該クラスタ機器にレプリケーションする。

【0166】

上記ステップ１１０１において、ＴＰクラスタにおける各ノード機器はいずれも第２所定期間ごとに、マイクロＣｈｅｃｋｐｏｉｎｔ操作を１回実行し、当該ノード機器における少なくとも１つの履歴状態データをクラスタ機器にレプリケーションする。

【0167】

当該第２所定期間は上記ステップ２０２と同様であり、当該マイクロＣｈｅｃｋｐｏｉｎｔ操作について、上記ステップ２０４において既に詳しく説明し、データレプリケーションの過程は上記ステップ２０１－２０９と類似するから、ここで贅言しない。

【0168】

１１０２：第３所定期間ごとに、当該複数のノード機器は自体の少なくとも１つの履歴状態データを同時に当該クラスタ機器にレプリケーションし、当該第３所定期間は当該第２所定期間より大きい。

【0169】

当該第３所定期間は、第２所定期間より大きい何れかの値であってもよい。第２所定期間はマイクロＣｈｅｃｋｐｏｉｎｔの操作頻度に対応し、第３所定期間はＣｈｅｃｋｐｏｉｎｔの操作頻度に対応してもよい。

【0170】

上記ステップ２０４において、ＴＰクラスタは第３所定期間ごとに、ＴＰクラスタの各ノード機器をトラバースし、Ｃｈｅｃｋｐｏｉｎｔ操作を１回実行し、ＴＰクラスタにおける全てのノード機器の少なくとも１つの履歴状態データをクラスタ機器にレプリケーションし、データレプリケーションの過程は上記ステップ２０１～２０９と類似するから、ここで贅言しない。

【0171】

１１０３：当該第３所定期間ごとに、当該クラスタ機器は、当該複数のノード機器が送信した全ての履歴状態データのトランザクション標識から、第２所定条件に合致する最小トランザクション標識を決定し、当該第２所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶されたことを示し、当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供し、当該可視データ項目のトランザクション標識は当該最小トランザクション標識の以下である。

【0172】

上記ステップ１１０３は上記ステップ９０１～９０４と類似するから、ここで贅言しない。

【0173】

本出願の実施例が提供するデータシステムは、ＴＰクラスタとＡＰクラスタとの間のインタラクション過程を介して、システムで、ＴＰクラスタにおける各ノード機器がそれぞれ第２所定期間ごとに、マイクロＣｈｅｃｋｐｏｉｎｔ操作を実行し、ＴＰクラスタ全体の全てのノード機器が第３所定期間ごとに、Ｃｈｅｃｋｐｏｉｎｔ操作を１回実行するように体現し、これによって、ＡＰクラスタの履歴状態データに対するリアルタイム更新の需要を満たし、ＡＰクラスタのリアルタイムの可用性を保証する上に、マイクロＣｈｅｃｋｐｏｉｎｔ操作を介してデータレプリケーション過程にかかるトラバース確認期間を低減させ、データレプリケーションの効率を向上させる。

【0174】

図１２は、本出願の実施例が提供するデータレプリケーション装置の構成概略図である。図１２を参照し、当該装置は、追加モジュール１２０１とレプリケーションモジュール１２０２とを含み、以下詳しく説明する。

【0175】

追加モジュール１２０１は、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加し、
当該追加モジュール１２０１はさらに、当該データキューにおける少なくとも１つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加し、
レプリケーションモジュール１２０２は、第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションする。

【0176】

本出願の実施例が提供する装置において、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、当該トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも１つの履歴状態データを送信バッファに追加し、これによって、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第１所定条件に合致する場合、当該送信バッファにおける当該少なくとも１つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は第１所定条件に合致する度に、送信バッファにおける履歴状態データをクラスタ機器にレプリケーションし、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器もログをデータのオリジナル形式に解析して記憶する必要がなく、データをレプリケーションする際、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。

【0177】

可能な実施形態において、当該追加モジュール１２０１は、
当該データキューに履歴状態データが増加したことを検出した場合、当該履歴状態データを当該送信バッファに追加し、
当該レプリケーションモジュール１２０２は、
当該送信バッファに履歴状態データが増加したことを検出した場合、当該送信バッファにおける当該少なくとも１つの履歴状態データを当該クラスタ機器にレプリケーションする。

【0178】

可能な実施形態において、当該追加モジュール１２０１は、
第１所定期間ごとに、当該データキューにおける、現在タイミングの前の当該第１所定期間内に増加した少なくとも１つの履歴状態データを取得し、
トランザクション提出タイムスタンプの昇順に従って、当該少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、少なくとも１つの順次配列された履歴状態データを取得し、当該少なくとも１つの順次配列された履歴状態データを当該送信バッファに追加する。

【0179】

可能な実施形態において、当該第１所定条件は、当該送信バッファに何れかの履歴状態データが増加したことを検出したことであるか、または、
当該第１所定条件は、当該送信バッファの容量に対する当該送信バッファの使用済みデータ量の占有比率が、比率閾値に達したことを検出したことであるか、または、
当該第１所定条件は、現在タイミングと、当該送信バッファが前回で当該クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第２所定期間に達したことであるか、または、
当該第１所定条件は、現在タイミングと、当該送信バッファが前回で当該クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第３所定期間に達したことであり、当該第３所定期間は、複数のノード機器のうちの各ノード機器に対して配置される同じ所定期間であり、当該第３所定期間は当該第２所定期間より大きい。

【0180】

可能な実施形態において、図１２の装置構成に基づき、当該装置はさらに、
当該クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、当該レプリケーション成功応答に対応する送信バッファをクリアするためのクリアモジュールを含む。

【0181】

可能な実施形態において、当該追加モジュール１２０１はさらに、
当該データキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加する。

【0182】

なお、上記実施例が提供するデータレプリケーション装置は、データをレプリケーションする際、上記各機能モジュールの区画のみに対して例を挙げて説明したが、実際の応用で、必要に応じて、上記機能を異なる機能モジュールにより完成するように割り当て、即ち、ノード機器の内部構成を異なる機能モジュールに区画することで、以上説明した全てまたは一部の機能を完成させる。また、上記実施例が提供するデータレプリケーション装置とデータレプリケーション方法との実施例は同一の構想に属して、その具体的な実現過程について、データレプリケーション方法の実施例を参照すればよいから、ここで贅言しない。

【0183】

図１３は、本出願の実施例が提供するデータレプリケーション装置の構成概略図であり、図１３を参照し、当該装置は受信モジュール１３０１、追加モジュール１３０２及び記憶モジュール１２０３を含み、以下詳しく説明する。

【0184】

受信モジュール１３０１は、受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも１つの履歴状態データを受信し、
追加モジュール１３０２は、当該受信バッファにおける当該少なくとも１つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得し、当該転送バッファは履歴状態データに対してデータ形式の変換を行って、
記憶モジュール１３０３は、当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶し、１つのターゲットデータシートは、１つデータ項目の、当該ノード機器において所在する１つのオリジナルデータシートに対応する。

【0185】

本出願の実施例が提供する装置は、受信バッファからノード機器が送信した少なくとも１つの履歴状態データを受信した後、当該受信バッファにおける少なくとも１つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも１つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも１つのデータ項目を取得し、これによって、圧縮された履歴状態データの形式を回復し、元の形式を保留する履歴状態データを直接的に取得するから、ログを解析し履歴状態データを取得する操作の実行を避け、さらに、当該少なくとも１つのデータ項目をクラスタデータベースの少なくとも１つのターゲットデータシートに記憶し、履歴状態データに対する適切な保存を実現する。

【0186】

可能な実施形態において、図１３の装置構成に基づき、当該記憶モジュール１３０３は、
タプルを単位とするデータ項目に対して、当該データ項目が所在するオリジナルデータシートにおける記憶形式に従って、当該データ項目を、当該オリジナルデータシートに対応するターゲットデータシートに記憶するための第１記憶ユニットと、
フィールドの変更状況を示すデータ項目に対して、キー値ペアの記憶形式に従って、当該データ項目を、当該オリジナルデータシートに対応するターゲットデータシートに記憶するための第２記憶ユニットと、を含む。

【0187】

可能な実施形態において、当該第２記憶ユニットは、
当該オリジナルデータシートにおける当該データ項目のキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該ターゲットデータシートにおける当該データ項目のキー名として決定し、
当該オリジナルデータシートにおける当該データ項目の修正されたフィールドを、当該ターゲットデータシートにおける当該データ項目のキー値として決定する。

【0188】

可能な実施形態において、図１３の装置構成に基づき、当該装置はさらに、
当該少なくとも１つの履歴状態データのトランザクション標識から、第２所定条件に合致する最小トランザクション標識を決定するための決定モジュールであって、当該第２所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれも当該クラスタデータベースに記憶されたことを示す決定モジュールと、
当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供するための検索モジュールであって、当該可視データ項目のトランザクション標識が当該最小トランザクション標識の以下である検索モジュールとを含む。

【0189】

可能な実施形態において、図１３の装置構成に基づき、当該決定モジュールは、
トランザクション提出タイムスタンプの昇順に従って、当該少なくとも１つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、ターゲットデータシーケンスを取得するためのソートユニットと、
当該ターゲットデータシーケンスから、当該第２所定条件に合致する少なくとも１つのトランザクションを取得するための取得ユニットと、
当該少なくとも１つのトランザクションにおける、順番が最も前にあるトランザクションのトランザクション標識を、当該最小トランザクション標識として決定するための決定ユニットとを含む。

【0190】

可能な実施形態において、当該取得ユニットは、
当該ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットＡＮＤ操作を実行し、出力が真である履歴状態データに対応するトランザクションが、第２所定条件に合致すると決定し、
または、当該ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定した場合、当該グローバルトランザクション標識に対応するトランザクションが当該第２所定条件に合致すると決定するためのトラバース決定サブユニットを含む。

【0191】

可能な実施形態において、トラバース決定サブユニットはさらに、
当該グローバルトランザクション標識に基づき、当該クラスタデータベースに記憶され、且つ当該グローバルトランザクション標識を有するデータ項目を取得し、取得した当該データ項目及び復号化により得られた当該履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定する。

【0192】

可能な実施形態において、当該受信モジュール１３０１は、
第２所定期間ごとに、当該受信バッファから、何れかのノード機器が送信した少なくとも１つの履歴状態データを受信するか、または、
第３所定期間ごとに、当該受信バッファから複数のノード機器が同時に送信した少なくとも１つの履歴状態データを受信する。

【0193】

なお、上記実施例が提供するデータレプリケーション装置は、データをレプリケーションする際、上記各機能モジュールの区画のみに対して、例を挙げて説明したが、実際の応用において、必要に応じて、上記機能を異なる機能モジュールにより完成するように割り当て、即ち、クラスタ機器の内部構成を異なる機能モジュールに区画することで、以上説明した全てまたは一部の機能を完成させる。また、上記実施例が提供するデータレプリケーション装置とデータレプリケーション方法との実施例は同一の構想に属して、その具体的な実現過程について、データレプリケーション方法の実施例を参照すればよいから、ここで贅言しない。

【0194】

図１４は、本出願の実施例が提供するコンピュータ機器の構成概略図であり、当該コンピュータ機器１４００は、配置またはパフォーマンスにより、大きい差が生じて、１つまたは複数のプロセッサー（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ、ＣＰＵ）１４０１及び１つまたは複数のメモリ１４０２を含んでもよく、当該メモリ１４０２には少なくとも１つの命令が記憶され、当該少なくとも１つの命令は当該プロセッサー１４０１によりロードされ、実行されることで、上記各データレプリケーション方法の実施例が提供するデータレプリケーション方法を実現する。無論、当該コンピュータ機器はさらに、入出力を行うための有線または無線ネットワークインターフェース、キーボード及び入出力インターフェースなどの構成要素を有してもよく、当該コンピュータ機器はさらに、機器機能を実現するための他の構成要素を含んでもよく、ここで贅言しない。

【0195】

例示的な実施例において、さらにコンピュータ可読記憶媒体を提供し、例えば少なくとも１つの命令を含むメモリであり、上記少なくとも１つの命令は端末のプロセッサーにより実行されることで、上記実施例のデータレプリケーション方法を完成させる。例えば、当該コンピュータ可読記憶媒体は、ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ－ＲＯＭ、磁気テープ、フレキシブルディスク及び光データ記憶装置などであってもよい。

【0196】

上記実施例を実現するための全てまたは一部のステップは、ハードウェアにより完成されてもよいし、プログラムにより関連するハードウェアに命令することで完成されてもよく、当該プログラムはコンピュータ可読記憶媒体に記憶され、上記言及された記憶媒体は、読み取り専用メモリ、磁気ディスクまたは光ディスクなどであってもよい。

【0197】

以上は本出願の好適な実施例であり本出願を限定するためのものではなく、本出願の精神及び原則内でなされた任意の修正、等価置換、改良などは、いずれも本出願の保護範囲に該当する。

【符号の説明】

【0198】

1201 追加モジュール
1202 レプリケーションモジュール
1301 受信モジュール
1302 追加モジュール
1303 記憶モジュール
1400 コンピュータ機器
1401 プロセッサー
1402 メモリ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】