JP7271670B2 - データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム - Google Patents

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

Info

Publication number
JP7271670B2
JP7271670B2 JP2021532087A JP2021532087A JP7271670B2 JP 7271670 B2 JP7271670 B2 JP 7271670B2 JP 2021532087 A JP2021532087 A JP 2021532087A JP 2021532087 A JP2021532087 A JP 2021532087A JP 7271670 B2 JP7271670 B2 JP 7271670B2
Authority
JP
Japan
Prior art keywords
data
transaction
state data
historical state
cluster
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.)
Active
Application number
JP2021532087A
Other languages
English (en)
Other versions
JP2022510460A (ja
Inventor
▲海▼翔 李
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Publication of JP2022510460A publication Critical patent/JP2022510460A/ja
Application granted granted Critical
Publication of JP7271670B2 publication Critical patent/JP7271670B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273Asynchronous replication or reconciliation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2282Tablespace storage structures; Management thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2365Ensuring data consistency and integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本出願は、2019年05月05日にて中国特許庁に提出され、出願番号が201910368297Xであり、出願の名称が「データレプリケーション方法、装置、コンピュータ機器及び記憶媒体」である中国特許出願の優先権を主張して、その全ての内容は本出願に援用される。
本出願は、データベース技術分野に関し、特にデータレプリケーション技術に関する。
データベース技術、特にOLAP(online analytical processing、オンライン分析処理)処理システム、データライブラリー、ビッグデータ分析などのシーンにおいて、よくデータベースからデータをレプリケーションし、既存のデータを即時的にバックアップする必要がある。
レプリケーション過程において、一般的にホスト機器とスタンバイ機器という2つの機器に係わり、現在のデータベース(例えば、Oracle、MySQL、またはInnoDBなど)にとって、ホスト機器は定期的にデータベースにおけるデータファイルをスタンバイ機器にレプリケーションし、データファイルによるホスト機器とスタンバイ機器との同期を実現する。また、レプリケーション過程において、データファイルに対する損壊による、ホスト機器とスタンバイ機器とのデータの不一致を避けるために、ホスト機器とスタンバイ機器とは通信接続を確立した後、両者のデータベースの間は、1つの再実行ログ(REDO LOG)を同期し、レプリケーション過程において異常が生じると、スタンバイ機器は再実行ログを再生することで、異常のデータを除去できる。
しかしながら、再実行ログの解析作業及び再生作業は複雑であり、データ量が大きいシーンで、スタンバイ機器による再実行ログの再生は、長い時間を費やし、データレプリケーション過程の効率に影響する。
本出願の実施例は、再実行ログに基づきデータをレプリケーションする場合、長い時間を費やし、解析再生作業が複雑であり、データレプリケーションの効率に影響するという問題を解決するための、データレプリケーション方法、装置、コンピュータ機器及び記憶媒体を提供する。
当該技術案は以下のようであり、
1つの態様によれば、コンピュータ機器(ノード機器)により実行されるデータレプリケーション方法を提供し、当該方法は、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加するステップと、
当該データキューにおける少なくとも1つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加するステップと、
第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションするステップと、を含む。
1つの態様によれば、コンピュータ機器(クラスタ機器)により実行されるデータレプリケーション方法を提供し、当該方法は、
受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも1つの履歴状態データを受信するステップと、
当該受信バッファにおける当該少なくとも1つの履歴状態データを転送バッファに追加し、履歴状態データに対してデータ形式の変換を行う当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得するステップと、
当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶するステップであって、1つのターゲットデータシートは、1つデータ項目の、当該ノード機器において所在する1つのオリジナルデータシートに対応するステップと、を含む。
1つの態様によれば、データレプリケーション装置を提供し、当該装置は、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加し、当該データキューにおける少なくとも1つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加する追加モジュールと、
第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションするためのレプリケーションモジュールと、を含む。
1つの態様によれば、データレプリケーション装置を提供し、当該装置は、
受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも1つの履歴状態データを受信するための受信モジュールと、
当該受信バッファにおける当該少なくとも1つの履歴状態データを転送バッファに追加し、履歴状態データに対してデータ形式の変換を行う当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得するための追加モジュールと、
当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶するための記憶モジュールであって、1つのターゲットデータシートは、1つデータ項目の、当該ノード機器において所在する1つのオリジナルデータシートに対応する記憶モジュールと、を含む。
1つの態様によれば、プロセッサーとメモリとを含むコンピュータ機器を提供し、当該メモリには少なくとも1つの命令が記憶され、当該少なくとも1つの命令は当該プロセッサーによりロードされるとともに、実行されることで、上記何れかの可能な実現形態のデータレプリケーション方法を実現する。
1つの態様によれば、コンピュータ可読記憶媒体を提供し、当該記憶媒体には少なくとも1つの命令が記憶され、当該少なくとも1つの命令はプロセッサーによりロードされるとともに、実行されることで、上記何れかの可能な実現形態のデータレプリケーション方法を実現する。
1つの態様によれば、命令を含むコンピュータプログラムを提供し、コンピュータで実行されると、コンピュータに上記何れかの可能な実現形態のデータレプリケーション方法を実行させる。
本出願の実施例が提供する技術案の有益な効果は、少なくとも以下を含み、
トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも1つの履歴状態データを送信バッファに追加し、これによって、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は、第1所定条件に合致する度に、少なくとも1つの送信バッファにおける履歴状態データをクラスタ機器にレプリケーションする。このように、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器はログをデータのオリジナル形式に解析して記憶する必要もなく、これによって、データをレプリケーションする場合、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。
本出願の実施例の技術案をより明らかに説明するために、以下は実施例の説明に必要な図面を簡単に紹介し、明らかに、以下の説明の図面は本出願のいくつかの実施例に過ぎず、当業者にとって、進歩性に値する労働をしない前提で、これらの図面に基づき他の図面を取得できる。
本出願の実施例が提供するデータレプリケーション方法の実施環境の概略図である。 本出願の実施例が提供するデータレプリケーション方法のインタラクションフローチャートである。 本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。 本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。 本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。 本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。 本出願の実施例が提供するオリジナルデータシートの構成概略図である。 本出願の実施例が提供するターゲットデータシートの構成概略図である。 本出願の実施例が提供するデータ検索過程のフローチャートである。 本出願の実施例が提供するトランザクションの一致性ポイントの原理的な概略図である。 本出願の実施例が提供するデータシステムのインタラクションフローチャートである。 本出願の実施例が提供するデータレプリケーション装置の構成概略図である。 本出願の実施例が提供するデータレプリケーション装置の構成概略図である。 本出願の実施例が提供するコンピュータ機器の構成概略図である。
本出願の目的、技術案及び利点をより明らかにするために、以下は図面を結合して、本出願の実施形態をさらに詳細に説明する。
本出願の実施例を紹介する前に、まずいくつかのデータベース技術における基本的な概念を紹介する。
本出願の実施例に係るデータベースには、タプルを記憶するための複数のデータシートが記憶される。当該データベースはMVCC(multi-version concurrency control、マルチバージョンコンカレンシーコントロール)による何れかのタイプのデータベースであってもよい。本出願の実施例において、当該データベースのタイプを具体的に限定しない。
なお、状態属性に基づき上記データベースにおけるデータを、現在状態、遷移状態及び履歴状態という3つの状態に区画し、当該3つの状態を「データフル状態(full state)」と総称し、フル状態データと略称し、フル状態データにおける各異なる状態属性は、データの、そのライフサイクル軌跡における状態を識別する。
現在状態(current state):タプルの最新バージョンのデータであって、現在階段にあるデータである。現在階段にあるデータの状態は、現在状態と呼ばれる。
遷移状態(transitional state):タプルの最新バージョンではなく、履歴状態バージョンでもなく、現在状態から履歴状態へ変換する過程にあり、遷移状態にあるデータは、半減データと称する。
履歴状態(historical state):タプルの履歴状態であり、その値は現在値ではなく、旧い値である。履歴階段にあるデータの状態は、履歴状態と称する。1つのタプルの履歴状態は複数あってもよく、データの状態変遷の過程を反映する。履歴状態にあるデータは、修正または削除できず、読み取りしかできない
なお、MVCCメカニズムで、データの上記3つの状態はいずれも存在し、非MVCCメカニズムで、データは履歴状態及び現在状態のみが存在してもよい。MVCCまたはブロッキング並行アクセス制御メカニズムで、トランザクションを提出(サブミット)した後のデータの新しい値は現在状態にある。MVCCメカニズムで、現在活発トランザクションリストにおける最小のトランザクションの前のトランザクションから生成されるデータの状態は、履歴状態にあり、ブロッキング並行アクセス制御メカニズムで、トランザクションを提出した後、提出する前のデータの値は、履歴状態の値になり、即ち、タプルの旧い値は履歴状態にある。読み取られたバージョンには、利用されている活発トランザクション(最新の関連トランザクションではない)があり、最新の関連トランザクションがタプルの値を修正したため、その最新の値は既に1つの現在状態にあり、読み取られた値は現在状態に対して既に1つの履歴状態にあるため、そのデータ状態は現在状態と履歴状態との間にあり、遷移状態と称する。
例えば、MVCCメカニズムで、ユーザテーブル(userテーブル)のAアカウントの残高は10元から、20元にチャージされ、そして、15元消費して、5元になり、この時点から、金融B機構はデータを読み取り始めて、検査トランザクションを行って、Aはその後、20元チャージされ、25元になり、25元は現在状態データであり、Bにより読み取られた5元は遷移状態であり、残りの20、10の2つの値は履歴状態であり、いずれも履歴状態データである。
上記用語の解釈に基づき、図1は、本出願の実施例が提供するデータレプリケーション方法の実施環境の概略図である。図1を参照し、当該実施環境はHTAC(hybrid transaction/analytical cluster、ハイブリッドトランザクション/分析クラスタ)アーキテクチャと総称し、HTACアーキテクチャ内には、TP(transaction processing、トランザクション処理)クラスタ101及びAP(analytical processing、分析処理)クラスタ102が含まれる。
当該TPクラスタ101は、トランザクション処理サービスを提供し、TPクラスタには複数のノード機器103が含まれ、データレプリケーションの過程において、当該複数のノード機器はレプリケーション対象となる履歴状態データを提供する。TPクラスタ101の各ノード機器にはノードデータベースが設けられ、各ノード機器はスタンドアロン機器であってもよいし、1台ホスト機器・2台スタンバイ機器からなるクラスタ機器であってもよく、本出願の実施例はノード機器のタイプを具体的に限定しない。
当該APクラスタ102は、履歴状態データに対する検索及び分析サービスを提供し、APクラスタにはクラスタ機器が含まれ、クラスタ機器にはクラスタデータベースが設けられ、データレプリケーションの過程において、当該クラスタ機器は当該複数のノード機器が送信した履歴状態データをクラスタデータベースにレプリケーションして記憶し、クラスタデータベースに記憶された履歴状態データに基づき、検索及び分析サービスを提供する。当該クラスタデータベースは、ロカールのデータベースであってもよいし、当該クラスタ機器がストレージインターフェースを介してアクセスする分散型ファイルシステムであってもよい。当該分散型ファイルシステムによりTPクラスタに無限記憶機能を提供でき、例えば、当該分散型ファイルシステムはHDFS(Hadoop distributed file system、Hadoop分散型ファイルシステム)、Ceph(Linux(登録商標)システムでの分散型ファイルシステム)、Alluxio(メモリによる分散型ファイルシステム)などであってもよい。
無論、当該クラスタ機器は、1つまたは複数のスタンドアロン機器、或いは1台ホスト機器・2台スタンバイ機器からなるクラスタ機器から構成されてもよく、各機器の間はオンライン通信を実現し、本出願の実施例はクラスタ機器のタイプを具体的に限定しない。
いくつかの実施例において、TPクラスタ101における複数のノード機器はトランザクション処理サービスを提供でき、何れかのトランザクションの提出が完了したタイミングで、新しい現在状態データを生成するとともに、当該現在状態データに対応する履歴状態データも生成する。履歴状態データが多い記憶空間を占めるが、履歴状態データは保存価値を具備するから、当該複数のノード機器は本出願の実施例が提供するデータレプリケーション方法に基づき、履歴状態データをクラスタ機器にレプリケーションし、クラスタ機器によりロカールアクチュエータ(local executor、LE)に基づき履歴状態データをデータシートに記憶し、レプリケーションが完了した後、当該ノード機器で、レプリケーションされた履歴状態データを削除することを支持する(無論、削除しなくてもよい)。履歴状態データをTPクラスタからAPクラスタに保存することで、HTACアーキテクチャは現在状態データ及び遷移状態データを記憶できるだけではなく、履歴状態データに対しても、適切に記憶でき、完備のフル状態データの記憶メカニズムを実現する。
上記過程において、当該複数のノード機器は、履歴状態データをクラスタ機器に成功的にレプリケーションした後、さらに、今回レプリケーションした履歴状態データのメタデータをクラスタ機器のメタデータ(metadata、MD)マネージャに登録してもよく、これによって、クラスタ機器は当該メタデータマネージャにより、記憶された履歴状態データのメタ情報を統計する。
いくつかの実施例において、ユーザはSQLルーティング(structured query language router、SQL Router、SR)層が提供する検索ステートメント、検索操作のセマンティック及びメタデータに基づき、TPクラスタ101またはAPクラスタ102内に記憶された何れかのデータをルーティング検索でき、無論、TPクラスタ101は主に現在状態データに対する検索サービスを提供し、APクラスタ102は主に履歴状態データに対する検索サービスを提供する。検索操作のセマンティックは、検索ステートメントに基づき分析することで得られた操作意図であり、例えば、WHERE句の条件はWHERE句の意図を示す。
いくつかの実施例において、特にビッグデータシーンで、一般的に、1つのトランザクションは、単一のノード機器のノードデータベースに対するデータ修正だけではなく、他の少なくとも1つのノード機器のノードデータベースに対するデータ修正にも係わり、この場合、分散型一致性アルゴリズム(例えば、two-phase commit、2PC)に基づき、クロスノードの書きトランザクションを実行することで、データ操作に対するトランザクションの原子性及び一致性を保証する。
上記アーキテクチャにおいて、TPクラスタ101における各ノード機器に対応する1つまたは複数のノードデータベースは、データベースインスタンスセットを構成でき、1つのSET(セット)と称する。無論、当該ノード機器がスタンドアロン機器であれば、当該スタンドアロン機器のデータベースインスタンスは1つのSETであり、当該ノード機器が1台ホスト機器・2台スタンバイ機器からなるクラスタ機器であれば、当該ノード機器のSETはホスト機器データベースインスタンスと2つのスタンバイ機器データベースインスタンスとの集合であり、この場合、クラウドデータベース(cloud database)の強い同期技術に基づき、ホスト機器のデータとスタンバイ機器のコピーデータとの間の一致性を保証する。好ましくは、各SETは線形拡張を行うことで、ビッグデータシーンでの業務処理に対処する。
いくつかの実施例において、TPクラスタ101はさらに、分散型協調システム(例えば、ZooKeeper)により当該複数のノード機器103に対する管理を実現するように支持し、例えば、ZooKeeperによりあるノード機器を失効させる(即ち、当該ノード機器をTPクラスタ101から削除する)。
上記実施環境に基づき、図2は、本出願の実施例が提供するデータレプリケーション方法のインタラクションフローチャートである。図2を参照し、TPクラスタにおける複数のノード機器のうちの何れかのノード機器、APクラスタにおけるクラスタ機器をインタラクション実行主体とすることを例として説明し、当該実施例はノード機器とクラスタ機器とのインタラクション過程に適用され、当該実施例は、以下のステップを含む。
201、ノード機器はトランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加する。
上記過程において、当該ノード機器は、TPクラスタ内の何れかのノード機器であってもよく、当該ノード機器にはノードデータベースが設けられてもよい。当該ノードデータベースの内部で、何れかのトランザクションの提出に伴い、相応的に履歴状態データ及び新しい現在状態データを生成する。
更新トランザクション(UPDATE操作)を例として説明し、1つのタプルに対して更新トランザクションを実行する場合、更新前のタプルに削除標識を追加するステップと、修正後のデータコンテンツを記憶するための1つの新しいタプルを生成するステップという2つのステップに分ける。更新トランザクションの提出が完了した後、当該更新前のタプル及び当該新しいタプルは、外部に対して「読み取り可能」状態を呈し、即ち、更新トランザクションの提出が完成した場合に限り、タプルは有効更新の過程を完成し、データベースエンジンは当該更新前のタプル及び当該新しいタプルに対して読み取り操作を実行するように支持し、これによって、ユーザは当該タプルが修正されたことを発見できる。
他の態様によれば、削除トランザクション(DELETE操作)も類似の過程を有し、1つのタプルに対して削除トランザクションを実行する場合、元のタプルに削除標識を追加し、削除トランザクションの提出が完了した後、タプルは有効削除の過程を完成し、当該元のタプルは外部に対して「読み取り可能」状態を呈し、即ち、削除トランザクションの提出が完了した場合に限り、ユーザは当該タプルが削除されたことを発見できる。
上記状況に鑑みて、ノード機器はトランザクション処理サービスを提供する場合、何れかのトランザクションの提出操作を検出した場合、ノードデータベースは当該トランザクションの履歴状態データを取得できる。当該ノードデータベースが履歴状態データに対する記憶を支持しないデータベースであれば、ノード機器はトランザクションの提出が完了したタイミングで、履歴状態データを同時に取得し、上記ステップ201の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを同期に実現する。
いくつかの実施例において、ロールバックセグメントの方式で、遷移状態データまたは履歴状態データを一時的に記憶するように支持するタイプのノードデータベース(例えばOracle、MySQL/InnoDBなど)もあり、この場合、トランザクションの提出操作とデータキューの追加操作とは非同期であり、ノードデータベースは履歴状態データを一時的に記憶するから、データベースエンジンはロールバックセグメントに記憶されるデータを定期的にクリーンアップする。この場合、ノード機器はデータベースエンジンがロールバックセグメントに対するクリーンアップ操作を実行する際に、ロールバックセグメントに記憶される履歴状態データを取得でき、上記ステップ201の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを非同期に実現する。
例えば、図3は、本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。図3を参照し、ユーザAの初期残高は100元であり、第1タイミングで100元チャージして、残高は200元になり、第2タイミング後のあるタイミングで、また100元チャージして、残高は300元になり、この時点で、金融機構はノードデータベースに対して読み取り操作を実行し、読み取り操作の実行過程における第3タイミングで、ユーザAはさらに100元チャージし、残高は400元になり、この時点で、ユーザAに対応する現在状態データは400であり、遷移状態データは300であり、履歴状態データは100と200とを含む。ノードデータベースがMySQLであることを例として、PURGE操作を実行することで、ロールバックセグメントをクリーンアップし、ノード機器はPURGE操作を検出した場合、PURGE操作が作用された履歴状態データ(ユーザAに対応する100及び200)をデータキューに追加する。ここで、ユーザAの履歴状態データのみを例として説明し、ユーザB、ユーザC及びユーザDに対しても、同じように使用するため、ここで贅言しない。
いくつかの実施例において、現在状態データ、遷移状態データ及び履歴状態データをデータページに記録するように支持するタイプのノードデータベース(例えば、PostgreSQL)もあり、データページにおける履歴状態データを定期的にクリーンアップし、この場合、ノード機器はデータベースエンジンがデータページに対するクリーンアップ操作を実行する際に、データページに記憶される履歴状態データを取得し、上記ステップ201の、当該履歴状態データをデータキューに追加する操作を実行し、これによって、トランザクションの提出操作とデータキューの追加操作とを非同期に実現する。
例えば、図4は本出願の実施例が提供する履歴状態データを取得する原理的な概略図である。図4を参照し、ノードデータベースがPostgreSQLであることを例として、ノードデータベースは複数のタプルの現在状態データ、遷移状態データ及び履歴状態データをデータページに記録し、データページにはさらに当該複数のタプルのタプル情報が記録されてもよく、ノードデータベースはVACUUM操作を実行することで、データページをクリーンアップする。ノード機器はVACUUM操作を検出した場合、VACUUM操作が作用された履歴状態データをデータキューに追加し、そして、データページにおける、現在最小の活発トランザクションの前のトランザクションから生成されるデータをクリーンアップする。
上記何れかの場合の、履歴状態データをデータキューに追加する過程で、ノード機器にはデータバッファ(buffer)が含まれてもよく、当該データバッファはデータキューという形態で、履歴状態データをキャッシングし、履歴状態データをノードデータベースのオリジナルデータシートから、当該データバッファのデータキューに追加する。
202:ノード機器は、第1所定期間ごとに、当該データキューにおける、現在タイミングの前の当該第1所定期間内に増加した少なくとも1つの履歴状態データを取得する。
当該第1所定期間(時間長)は、0以上の何れかの値であってもよく、例えば、当該第1所定期間は0.5ミリ秒であってもよい。
上記過程において、ノード機器は、第1所定期間ごとに、データキューから履歴状態データを1回取得するが、データキューにおける履歴状態データの順序が狂って、以下のステップ203を実行して、履歴状態データをソートした後、送信バッファに追加することで、履歴状態データを非同期に送信バッファに書き込むことを実現する。
いくつかの実施例において、ノード機器はさらに履歴状態データを同期に送信バッファに書き込んでもよく、同期過程は、データキューに1つの履歴状態データが増える度に、当該履歴状態データを同期に送信バッファに追加することである。上記同期に送信バッファに書き込む状況に基づき、ノードデータベースが履歴状態データに対する記憶を支持しないデータベースであれば、ノード機器はトランザクションの提出が完了したタイミングで、履歴状態データをデータキューに書き込み、同一のタイミングで、履歴状態データを送信バッファに書き込む。
上記過程において、本実施例のステップ202~204は以下のように差し替えられてもよい。即ち、当該データキューに何れか1つの履歴状態データが増えたことを検出した場合、当該履歴状態データを送信バッファに追加し、送信バッファに何れか1つの履歴状態データが増えたことを検出した場合、当該送信バッファにおける当該少なくとも1つの履歴状態データを当該クラスタ機器にレプリケーションし、これによって、履歴状態データの同期レプリケーションを実現し、履歴状態データを送信バッファに書き込む場合、トランザクション提出タイムスタンプの順序及びトランザクション標識の順序に従って書き込むように保証し、上記ステップ203のソート操作を実行する必要がなく、直接的に以下のステップ204を実行すればよい。
いくつかのシーンにおいて、履歴状態データの発生とデータキューへの履歴状態データの追加過程とが非同期であり、例えば、上記ステップ201に係るMySQL/InnoDBなどのタイプのノードデータベースにおいて、PURGE操作を採用して履歴状態データをクリーンアップするか、または、例えば、PostgreSQLなどのタイプのノードデータベースにおいて、VACUUM操作を採用して、履歴状態データをクリーンアップすると、データキュー自体にキャッシングされる履歴状態データの順序が狂ってしまい、そうすれば、履歴状態データが送信バッファに同期しても、履歴状態データは整然に送信バッファに書き込まれることを保証できないから、このシーンで、以下のステップ203を実行しなければならない。
図5は、本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。図5を参照し、何れかのトランザクションの提出操作を検出した後、元の現在状態データを履歴状態データに変換してもよく、この際、まず、履歴状態データをオリジナルデータシートからデータキューに追加し、そして、上記ステップ202の操作に基づき、履歴状態データをデータキューから非同期に送信バッファに追加する。但し、第1所定期間だけ間隔するから、データキューから取得した履歴状態データの順序が狂って、履歴状態データが整然に送信バッファに書き込まれることを保証するために、以下のステップ203を実行しなければならない。
203:ノード機器は、トランザクション提出タイムスタンプの昇順に従って、当該少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、少なくとも1つの順次配列された履歴状態データを取得し、当該少なくとも1つの順次配列された履歴状態データを送信バッファに追加する。
各履歴状態データは1つのトランザクションに対応し、当該トランザクション標識(identification、トランザクションID)は、1つのトランザクションを唯一に識別し、トランザクション標識はトランザクション発生タイムスタンプ(timestamp) に従って単調増加し、例えば、当該トランザクション標識はトランザクション発生タイムスタンプであってもよく、無論、当該トランザクション標識はトランザクション発生タイムスタンプに従って割り振られた、単調増加傾向を呈する値であってもよい。なお、1つのトランザクションは一般的に、トランザクション発生タイムスタンプ及びトランザクション提出タイムスタンプという2つのタイムスタンプに対応し、当該2つのタイムスタンプはそれぞれトランザクションの発生タイミング及び提出タイミングに対応する。
当該送信バッファは、データレプリケーションの過程で循環使用される部分であってもよく、当該送信バッファは送信プロセスまたは送信スレッドが送信タスク(履歴状態データをノード機器からクラスタ機器に送信する)を実行する際に呼び出すバッファであってく、好ましくは、送信プロセス、または送信スレッドの数は1つまたは複数であってもよいから、当該送信バッファの数も1つまたは複数であってもよい。上記ステップ203において、順序付けられた履歴状態データを何れかの送信バッファに書き込むことを例として説明する。
上記過程において、ノード機器は、履歴状態データを非同期に送信バッファに書き込む前に、まず、履歴状態データをソートし、ソートする際、まず、トランザクション提出タイムスタンプの昇順に従ってソートし、そして、トランザクション提出タイムスタンプが同じである履歴状態データに対して、トランザクション標識の昇順に従ってソートし、さらに、順次配列された履歴状態データを当該送信バッファに書き込み、送信バッファ内の履歴状態データは順序付けられるように保証する。
図6は、本出願の実施例が提供するストリーミングレプリケーション技術の原理的な概略図である。図6を参照し、送信バッファの数が複数である場合、各送信バッファによる履歴状態データの取得方法は、上記ステップ202~203で紹介した実現形態と類似するため、ここで、贅言しない。上記ステップ202~203において、ノード機器はデータキューにおける少なくとも1つの履歴状態データを少なくとも1つの送信バッファの何れかの送信バッファに追加し、データ量が大きいシーンで、送信バッファの数を増やすことで、データキューにおける履歴状態データをより早く送信バッファに書き込むことができる。
好ましくは、当送信バッファの数が複数である場合、ノード機器はデータキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加することで、複数の送信バッファの利用率、及び当該オリジナルデータシートにおける履歴状態データに対する送信レートを向上させる。
いくつかの実施例において、ノード機器は、履歴状態データをデータキューから送信バッファに追加した後、実際の必要に応じて、データキューにおいて、当該履歴状態データを多重化可能の状態としてマークすることで、ノード機器は当該履歴状態データをロカールに保存する。
204:第1所定条件に合致する場合、ノード機器は、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションする。
いくつかの実施例において、当該第1所定条件は、ノード機器が送信バッファに何れか1つの履歴状態データが増えたことを検出したことであってもよく、当該送信バッファはレプリケーション対象となる履歴状態データをキャッシングする。ノード機器による、データキューから履歴状態データを取得する実行過程で、送信バッファに1つの履歴状態データを成功に追加すると、送信バッファはクラスタ機器に当該履歴状態データをレプリケーションし、これによって、履歴状態データをクラスタ機器に絶えずレプリケーションでき、このようなデータレプリケーションの技術はストリーミングレプリケーション技術と称する。
いくつかの実施例において、当該第1所定条件はさらに、ノード機器が、当該送信バッファの容量に対する当該送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことであり、ノード機器による、データキューから履歴状態データを取得する実行過程で、送信バッファの総容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達した場合、送信バッファはクラスタ機器にキャッシングした当該履歴状態データをレプリケーションすることで、履歴状態データをクラスタ機器に絶えずレプリケーションすることができる。
当該比率閾値は、0より大きく且つ1以下の何れかの値であってもよく、例えば、当該比率閾値は100%または75%などの値であってもよい。
いくつかの実施例において、当該第1所定条件はさらに、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達することであってもよく、ノード機器による、データキューから履歴状態データを取得する実行過程で、ノード機器と、前回履歴状態データレプリケーションのタイミングとの時間差が第2所定期間に達した場合、送信バッファはクラスタ機器に当該履歴状態データをレプリケーションすることで、履歴状態データをクラスタ機器に絶えずレプリケーションすることができる。
当該第2所定期間は、第1所定期間以上の何れかの値であってもよく、例えば、第1所定期間が0.5ミリ秒である場合、当該第2所定期間は1ミリ秒であってもよく、この場合、送信バッファは1ミリ秒ごとに、クラスタ機器にデータレプリケーションを1回実行し、この1ミリ秒の間隔内で、送信バッファは0.5ミリ秒ごとに、データキューから前の0.5ミリ秒内で、データキューに新たに増えた履歴状態データ(1つまたは複数であってもよい)を取得する。
いくつかの実施例において、当該第1所定条件はさらに、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第3所定期間に達することであってもよく、当該第3所定期間は複数のノード機器のうちの各ノード機器に対して配置される同じ所定期間であり、当該第3所定期間は第2所定期間より大きく、複数のノード機器がそれぞれデータレプリケーションを実行する過程で、第3所定期間ごとに、複数のノード機器は同時にデータレプリケーションタスクを1回実行することで、各ノード機器がデータレプリケーション操作を実行する際、相互の間の遅延が最大で当該第3所定期間を超えていないように制御する。
いくつかの実施例において、当該第1所定条件はさらに、ノード機器が、当該送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達するか、または、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達したことを検出したことである。即ち、データレプリケーションの過程で、送信バッファの総容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達した場合、データレプリケーションタスクを1回実行するか、または、送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達していなくても、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達した場合、データレプリケーションタスクを1回実行する。
上記過程において、ノード機器は送信プロセス、または送信スレッドに基づき、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器に送信し、好ましくは、ノード機器はさらに、第1所定条件に合致する場合、当該送信バッファにキャッシングされる全ての履歴状態データを一回で当該クラスタ機器に送信してもよく、上記ステップ202~204は循環過程を形成し、ノード機器はストリーミングレプリケーション技術に基づき、持続的に履歴状態データをクラスタ機器にレプリケーションすることができる。
いくつかの実施例において、送信バッファからクラスタ機器に送信される各履歴状態データには、当該履歴状態データに対応するトランザクションのトランザクション標識、当該トランザクションの1つまたは複数のサブトランザクションに対応する1つまたは複数のノード機器のノード標識、または当該履歴状態データのフルデータのうちの少なくとも1つが含まれる。
1つのトランザクションは少なくとも1つのサブトランザクションを含み、各サブトランザクションは1つのノード機器に対応し、各ノード機器は唯一のノード標識を有し、当該ノード標識はノード機器のIPアドレス(internet protocol address、インターネットプロトコルアドレス)であってもよいし、ノード機器の標識番号であってもよく、当該標識番号とIPアドレスとは、一々対応するマッピング関係を有し、TPクラスタにおける何れかのノード機器には当該マッピング関係が記憶されてもよく、無論、APクラスタのクラスタ機器にも当該マッピング関係が記憶されてもよい。
いくつかの実施例において、ビットマップ符号化、または辞書圧縮などの方式を利用して、上記1つまたは複数のノード機器のノード標識を符号化することで、ノード機器から送信される履歴状態データの長さを短くして、データ伝送が占有するリソースをさらに圧縮させる。
いくつかの実施例において、上記データレプリケーション過程は、TPクラスタのCheckpoint(チェックポイント)操作により実現でき、ノード機器はさらにTPクラスタのCheckpoint操作頻度を設置してもよく、当該操作頻度はTPクラスタによるCheckpoint操作の実行頻度を示し、例えば、当該操作頻度は1秒で1回実行し、1回のCheckpoint操作において、TPクラスタにおける各ノード機器はいずれも上記ステップ204のデータレプリケーション過程を1回実行することで、TPクラスタにおける新たに生成した履歴状態データは、一回でAPクラスタに保存され、即ち、Checkpoint操作頻度は実際に、上記第3所定期間に対応する。
いくつかの実施例において、TPクラスタ内のノード機器の数が多い場合、相変わらずTPクラスタにおける各ノード機器に対して、Checkpoint操作を1回実行すると、TPクラスタがAPクラスタにデータをレプリケーションする際、かかる時間が大きく増えて、HTACのパフォーマンスが安定せず、HTACの安定性及びロバスト性に影響する恐れがあるため、TPクラスタ内の各ノード機器に対して、「マイクロCheckpoint」操作を実行し、マイクロCheckpointの操作頻度はCheckpointの操作頻度より速いため、ノード機器の履歴状態データがより早くAPクラスタに保存され、履歴状態データに対するAPクラスタの取得需求を満たし、履歴状態データのレプリケーション効率を保障し、APクラスタのリアルタイムの可用性を向上させる。
例えば、マイクロCheckpointの操作頻度を、Checkpointの操作頻度の千分の1の時間単位に設置し、即ち、Checkpoint操作が1秒で1回実行されると、マイクロCheckpoint操作は1ミリ秒で1回実行される。無論、ここで、マイクロCheckpointの操作頻度を例示的に説明し、本出願の実施例はマイクロCheckpointの操作頻度とCheckpointの操作頻度との間の比率を具体的に限定しない。
なお、マイクロCheckpointの操作頻度は実際に、上記第2所定期間に対応し、異なるノード機器に対して、異なるマイクロCheckpointの操作頻度を設置してもよく、マイクロCheckpointの操作頻度は、ノード機器の1秒あたりの活発トランザクションの数と正相関してもよく、例えば、1秒あたりの活発トランザクションの数が、TPクラスタの最初の10位を占めるノード機器に対して、高いマイクロCheckpointの操作頻度を設置できる。無論、異なるノード機器に対して、同じマイクロCheckpointの操作頻度を設置しても、送信バッファの総容量に対する異なるノード機器の送信バッファの使用済みデータ量の占有比率が、一般的に、同時に比率閾値に達することがないから、異なるノード機器の間のマイクロCheckpoint操作の非同期を招致する。
いくつかの実施例において、TPクラスタの異なるノード機器がそれぞれマイクロCheckpoint操作を実行すると同時に、TPクラスタにおける全てのノード機器が定期的にCheckpoint操作を1回実行するように強制することで、TPクラスタの内部の異なるノード機器が、マイクロCheckpoint操作の非同期のため、大きすぎるデータ遅延を招致して、APクラスタのリアルタイムの可用性に影響することを避ける。例えば、各ノード機器は1ミリ秒ごとに、マイクロCheckpoint操作を1回実行し、TPクラスタは1秒ごとに、全てのノード機器をトラバースするように、Checkpoint操作を1回実行し、APクラスタによる履歴状態データに対する受信のデータ遅延が最大で1秒を超えないように保証する(Checkpointの操作頻度を超えない)。
また、上記ステップ204のデータレプリケーション過程は、同期と非同期に分けてもよく、同期レプリケーションにおいて、データレプリケーションは履歴状態データのクリーンアップ操作と緊密に関連し、毎回のクリーンアップ操作(例えば、PRUGE操作、またはVACUUM操作)に対応するクリーンアップトランザクションは、提出階段で、履歴状態データのストリーミングレプリケーションを1回トリガーし、即ち、ノード機器はクリーンアップ操作が完了する前に、まず、クリーンアップされた全ての履歴状態データをクラスタ機器に同期し、クラスタ機器はARIESアルゴリズムに基づき、データレプリケーション過程のメタデータの再実行ログ(REDO LOG)を再生し、ノード機器は、再生が完了した後、クリーンアップトランザクションの状態を「提出済み」に設置する。これによって、履歴状態データはできるだけ早くクラスタ機器にレプリケーションされ、履歴状態データの安全性を保証する。
なお、オリジナルデータシートからクリーンアップされた履歴状態データに対して、ストリーミングレプリケーション技術に基づきデータレプリケーションを実現できるが、いくつかの実施例において、今回のデータレプリケーションのメタデータのみに対して、再実行ログの記録及び再生を行って、ノード機器とクラスタ機器との間の再検証及び再校正を実現し、今回のデータレプリケーション過程の安全性をよりよく保証する。この場合でも、オリジナルデータシートからクリーンアップされた履歴状態データに対して、再実行ログの再生を一々実行することを避けることができ、再生過程のデータ量を簡略化し、再生過程にかかる期間を短くし、データレプリケーションの効率を向上させる。
いくつかの実施例において、データレプリケーション過程は非同期であってもよく、この場合、データレプリケーションとクリーンアップトランザクションの提出は関連せず、ノード機器のクリーンアップトランザクションは提出階段で、履歴状態データのストリーミングレプリケーションをトリガーせず、ノード機器とクラスタ機器との間のストリーミングレプリケーションは第1所定条件に規定される第2所定期間に従ってトリガーされ、2回のストリーミングレプリケーションの間の時間間隔内で、ノード機器で修正された履歴状態データをクラスタ機器にレプリケーションし、データレプリケーション過程が占有するデータ伝送リソースを節約する。
上記ステップ204において、さらに、データレプリケーションの完成事項に対する確認に係り、この場合、再生確認レベル、受信確認レベル、送信確認レベルという3つの確認レベルに分けられ、以下詳しく説明する。
再生確認レベルにおいて、ノード機器はクラスタ機器のレプリケーション成功応答を受信した場合に限り、1回のデータレプリケーションタスクが完成したと認め、データレプリケーション過程の強い同期を実現する。強い同期は、各回のデータレプリケーションが原子的であるように保証でき、即ち、データレプリケーションの過程全体は成功するかまたは失敗し、中間状態が存在しない。何れかの一環に異常があると、今回のデータレプリケーションが失敗したと認めて、今回のデータレプリケーション全体に対して再実行を行う必要があり、データレプリケーション過程の安全性を保証する。好ましくは、当該レプリケーション成功応答は「Applied」命令である。
受信確認レベルにおいて、ノード機器はクラスタ機器のデータ受信応答を受信した後、1回のデータレプリケーションタスクが完成したと認めて、データレプリケーション過程の弱い同期を実現する。弱い同期は、クラスタ機器のメタデータの再生作業以外、データレプリケーション過程における他の操作がいずれも原子的であるように保証でき、この場合、メタデータの再生が失敗しても、今回のデータレプリケーション全体の再実行を行う必要がなく、データレプリケーション効率を考慮すると同時に、ある程度で、データレプリケーション過程の安全性を保証する。好ましくは、当該データ受信応答は「Received」命令である。
送信確認レベルにおいて、ノード機器はデータ送信操作を完成した後、1回のデータレプリケーションタスクが完成したと認めて、この場合、データレプリケーション過程が原子的であるように保証できないが、ノード機器とクラスタ機器との間は、互いに影響しない。クラスタ機器に応答が生じて、ダウンなどの異常が発生しても、ノード機器が再びデータレプリケーションをトリガーすることを阻止しなく、クラスタ機器が具備するスタンドアロン機器の数が1つより多い場合、1つのスタンドアロン機器に異常があっても、他のスタンドアロン機器に対するデータレプリケーション過程は正常に行われて、データレプリケーションの効率を保障する。
205:クラスタ機器は、受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも1つの履歴状態データを受信する。
当該受信バッファは、データレプリケーションの過程において、循環使用される部分であってもよく、当該受信バッファは受信プロセス、または受信スレッドが受信タスク(ノード機器が送信した履歴状態データを受信する)を実行する際呼び出されるバッファであってもよく、受信プロセス、または受信スレッドの数は1つまたは複数であってもよいから、当該受信バッファの数も1つまたは複数であってもよく、本出願の実施例は1つの受信バッファを例として説明し、他の受信バッファが類似の履歴状態データの受信過程を有することに対して、ここで贅言しない。
いくつかの実施例において、1つの受信バッファは1つのノード機器に対応してもよく、この場合、上記ステップ205は、クラスタ機器は、少なくとも1つの受信バッファからノード機器に対応する受信バッファを決定し、受信プロセス、または受信スレッドに基づき、当該ノード機器が送信した少なくとも1つの履歴状態データを当該受信バッファにキャッシングすることで、1つの受信バッファは、意図的に同一のノード機器からの履歴状態データを受信できる。
無論、当該受信バッファとノード機器との間に対応関係が存在しなくてもよく、クラスタ機器が、受信バッファの現在の利用可能な記憶空間に基づき、データ受信タスクを割り当て、この場合、上記ステップ205は、クラスタ機器は少なくとも1つの受信バッファから、現在の利用可能な記憶空間が最大である受信バッファを決定し、受信プロセス、または受信スレッドに基づき、ノード機器が送信した少なくとも1つの履歴状態データを当該受信バッファにキャッシングすることで、クラスタ機器は履歴状態データを現在の利用可能な記憶空間が最大である受信バッファに追加し、キャッシングリソースの合理的な利用を実現する。
206:クラスタ機器は、当該受信バッファにおける当該少なくとも1つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得し、当該転送バッファは履歴状態データに対してデータ形式の変換を行う。
上記過程において、受信バッファは、履歴状態データを転送バッファに追加する(即ち、レプリケーション)過程は、同期レプリケーションと非同期レプリケーションという2つの方式を含んでもよい。
同期レプリケーションの過程において、クラスタ機器は、受信バッファから履歴状態データ(1つまたは複数である可能性があるが、ノード機器が一度に送信するものである)を受信する度に、当該履歴状態データをすぐに転送バッファにレプリケーションする。
非同期レプリケーションの過程において、クラスタ機器は、受信バッファから履歴状態データを受信し、第4所定期間ごとに、当該受信バッファにおける全ての履歴状態データを転送バッファにレプリケーションする。 第4所定期間は0以上の任意の値である。
いくつかの実施例において、ノード機器が第2所定期間ごとにマイクロCheckpoint操作を1回実行すると、上記ステップ206は、第2所定期間ごとに、クラスタ機器は受信バッファからノード機器が送信した少なくとも1つの履歴状態データを受信する。無論、何れかのノード機器に対しても、このように類推し、異なるノード機器の第2所定期間は同様、または異なってもよい。
いくつかの実施例において、TPクラスタの全てのノード機器が第3所定期間ごとにCheckpoint操作を1回実行すると、上記ステップ206は、第3所定期間ごとに、クラスタ機器は受信バッファから、複数のノード機器が同時に送信した少なくとも1つの履歴状態データを受信し、TPクラスタの異なるノード機器の間のデータ遅延が第3所定期間を超えないように保証し、APクラスタによる履歴状態データに対する記憶のリアルタイムの可用性を向上させる。
いくつかの実施例において、同期レプリケーションであろうと、非同期レプリケーションであろうと、履歴状態データが成功に転送バッファにレプリケーションされた後、受信バッファにおいて今回でレプリケーションされた履歴状態データをクリアすることで、新しい履歴状態データを記憶するためのキャッシング空間を即時的にクリーンアップでき、データ伝送の速度を速くする。
上記ステップ206において、ノード機器が送信する少なくとも1つの履歴状態データの形式は、圧縮後のデータ形式であるから、転送バッファにおいて、当該少なくとも1つの履歴状態データをタプル形式に合致する元のデータに回復することで、以下のステップ207を実行し、いくつかの実施例において、タプル形式に合致する当該データは行形式のデータであってもよい。
207:クラスタ機器は、当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶し、1つのターゲットデータシートは、1つデータ項目が当該ノード機器において所在する1つのオリジナルデータシートに対応する。
上記ステップにおいて、業務ニーズに基づき、ターゲットデータシートは2つの記憶形式を含んでもよいため、クラスタ機器が当該少なくとも1つのデータ項目をターゲットデータシートに記憶する際も、2つの相応的な記憶過程が存在し、以下詳しく説明する。
いくつかの実施例において、タプルを単位とするデータ項目に対して、クラスタ機器は当該データ項目が所在するオリジナルデータシートにおける記憶形式に従って、当該データ項目を当該オリジナルデータシートに対応するターゲットデータシートに記憶することで、ターゲットデータシートとオリジナルデータシートとの記憶形式が完全に同様になり、汎用の場合で、1つのタプルのライフサイクルを便利に追跡する。
上記過程において、オリジナルデータシートとターゲットデータシートとの形式の一致を保証するために、何れかのノード機器とクラスタ機器とが接続を確立した後、論理レプリケーション技術(例えば、MySQLのBinLog技術)、または物理レプリケーション技術(例えばPostgreSQLの、REDO LOGによるレプリケーション技術)に基づき、クラスタ機器において、ノード機器における各オリジナルデータシートに対応する各ターゲットデータシートを確立する。なお、オリジナルデータシートは複数のタプルの現在状態データを記憶し、当該オリジナルデータシートに対応するターゲットデータシートは当該複数のタプルの履歴状態データを記憶する。
上記BinLog(バイナリログ、論理ログとも称する)技術において、BinLogはデータベースにおける操作を記録し、BinLogにおいて、特定の形式でデータの変更、テーブル構成の変更などのデータベーストランザクション操作を説明し、BinLogに記録できるトランザクション操作は、一般的に、提出またはロールバックが完了したものである。以下は、MySQLデータベースの論理レプリケーション技術を例として説明し、ノード機器とクラスタ機器とが接続を確立した後、ノード機器には1つまたは複数のDump-Threadスレッド(ダンプスレッド)が維持され、1つのDump-Threadスレッドにより、1つのクラスタ機器とマッチングし、ノード機器とクラスタ機器とが論理レプリケーションを行う場合、以下のステップを実行する。
クラスタ機器は、ノード機器に同期済みBinLogの情報(データファイル名及びデータファイル内の位置を含む)を送信し、ノードデータベースは同期済みBinLogの情報に基づき、現在の同期済み位置を決定する。ノード機器のDump-Threadスレッドは、未同期のメタデータのBinLogデータをクラスタ機器に送信し、クラスタ機器はIO-Thread(input/output thread、入出力スレッド)を介してノード機器による同期されたBinLogデータを受信し、BinLogデータをRelay-Log(リレーログ)が所在するファイルに書き込み、クラスタ機器はSQL-Thread(SQLスレッド)を介してRelay-LogファイルからBinLogデータを読み取り、BinLogデータを復号化して得られたSQLステートメントを実行し、これによって、ノード機器のメタデータを増分してクラスタ機器にレプリケーションする。
いくつかの実施例において、フィールドの変更状況を示すデータ項目に対して、クラスタ機器はキー値ペア(key-value)の記憶形式に従って、当該データ項目を当該オリジナルデータシートに対応するターゲットデータシートに記憶することで、データ項目にキャリアされた情報を保留できるだけではなく、キー値ペアの記憶形式により、何れかのフィールドの履歴状態データの変更状況をカスタマイズ的に追跡できる。
上記キー値ペア形式による記憶過程において、ターゲットデータシートのキー名(key)及びキー値(value)を決定する必要があり、いくつかの実施例において、具体的に、以下のような操作でキー名を決定する。即ち、クラスタ機器は、データ項目の、オリジナルデータシートにおけるキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該データ項目の、当該ターゲットデータシートにおけるキー名として決定する。オリジナルデータシートにキー名が存在する場合、オリジナルデータシートにおけるキー名及び当該データ項目の生成時間をターゲットデータシートにおけるキー名として決定してもよく、これによって、異なる次元から、履歴状態データの変更状況を追跡できる。無論、オリジナルデータシートにキー名が存在しないと、直接的にデータ項目の生成時間をターゲットデータシートにおけるキー名として決定してもよく、直観的にデータ項目の生成時間を記録できる。
いくつかの実施例において、さらに以下のような操作でキー値を決定し、即ち、クラスタ機器は、オリジナルデータシートにおけるデータ項目の修正されたフィールドを、当該データ項目の、ターゲットデータシートにおけるキー値として決定してもよい。修正されたフィールドは1つの文字列の形式に類似し、各修正されたフィールドの記憶形式は、「キー名:旧い値、新しい値」であってもよく、修正されたフィールドは1つまたは複数であってもよい。複数のフィールドが同時に修正されると、修正されたフィールドの間は、セミコロンで区切られてもよい。
例えば、図7は、本出願の実施例が提供するオリジナルデータシートの構成概略図である。図7を参照し、フィールドの変更状況を示す1つのデータ項目を例として説明し、オリジナルデータシートには、サーバー番号、サーバー状態、所属部門及び地区という4つのキー名が存在する。1回のトランザクション操作において、当該データ項目の「サーバー状態」及び「所属部門」を修正したと仮定し、図8は本出願の実施例が提供するターゲットデータシートの構成概略図である。図8を参照し、ターゲットデータシートから、「サーバー状態」、「所属部門」及び操作時間の動的な変更状況を直観的に観察でき、データ項目の「地区」が修正されていないため、ターゲットデータシートにおいて、「地区」の変更状況を表示する必要がなく、この場合、ターゲットデータシートにおいて、各キー値の記憶形式は「サーバー状態:サービス提供、サービス中断;所属部門:部門A、部門B」であってもよい。
いくつかの実施例において、クラスタ機器はさらに記憶プロセス、または記憶スレッドを介して、転送バッファにおけるデータ項目をストレージインターフェース(storage interface)により分散型ファイルシステムにアップロードし、永続性記憶することで、履歴状態データの無限記憶を実現してもよい。
分散型ファイルシステムがCephであり、クラスタ機器のクラスタデータベースがMySQLであることを例として説明し、MySQLでは、2つの方式でCephをマウンティングでき、例えば、CephFSをマウンティングすることで、配置を完了し、この場合、クラスタ機器に1つのモニター(Monitor)機器(node1)及び2つのスタンドアロン機器(node2及びnode3)が含まれると仮定し、具体的に以下のステップを実行する。
まず、クラスタ機器は、ディレクトリを構築し、bootstrap keyringファイルを準備し、「sudo mkdir-p/var/lib/ceph/mds/ceph-localhost」命令で実現でき、ディレクトリを構築した後、Cephはモニター機器が所在するnode1でbootstrap keyringファイルを自動に生成し、この場合、bootstrap keyringファイルをnode2及びnode3にレプリケーションし、「/var/lib/ceph/bootstrap-osd/ceph.keyring」命令でレプリケーションする。ここでは、クラスタ機器に2つのスタンドアロン機器が含まれることを例として説明し、クラスタ機器に2つ以上のスタンドアロン機器が含まれると、他のスタンドアロン機器でCephFSをマウンティングするとともに、bootstrap keyringファイルを当該スタンドアロン機器にレプリケーションしなければならない。
そして、クラスタ機器は、doneファイル及びsysvinitファイルを生成し、いくつかの実施例において、クラスタ機器はステートメント「sudo touch/var/lib/ceph/mds/ceph-mon1/done」を介してdoneファイルを生成し、ステートメント「sudo touch/var/lib/ceph/mds/ceph-mon1/sysvinit」を介してsysvinitファイルを生成する。
そして、クラスタ機器は、mdsのkeyringファイルを生成し、いくつかの実施例において、クラスタ機器はステートメント「sudo ceph auth get-or-create mds.mon1osd'allow rwx'mds'allow'mon'allow profile mds'-o/var/lib/ceph/mds/ceph-mon1/keyring」を介してkeyringファイルを生成する。
そして、クラスタ機器は、Cephfsのpoolを構築し、いくつかの実施例において、クラスタ機器はステートメント「ceph osd pool create cephfs_data 300」を介してCephfsのpoolのデータを構築し、ステートメント「ceph osd pool create cephfs_metadata 300」を介してCephfsのpoolのメタデータを構築する。
そして、クラスタ機器は、MDSファイル(ミラーリングファイル) を起動させ、いくつかの実施例において、クラスタ機器はステートメント「sudo/etc/init.d/ceph start|stop mds.localhost」を介してMDSを起動させる。
最後、クラスタ機器は、Cephfsを構築し及びCephfsをマウンティングし、いくつかの実施例において、クラスタ機器はステートメント「cephfs new cephfs cephfs_metadata cephfs_data」を介してCephfsを構築し、構築が完成した後、クラスタ機器はステートメント「mount-t ceph[monモニター機器ipアドレス]:6789://mnt/mycephfs」を介してCephfsのマウンティングを完成させる。
好ましくは、クラスタ機器は、さらにCephのRBD(ミラーリングファイル)をマウンティングする方式で配置を完了し、具体的に、以下のステップを実行する。
まず、クラスタ機器は、RBDのpoolを構築し、例えば、ステートメント「ceph osd pool create rbd 256」を介して構築する。
そして、クラスタ機器は、RBDブロック機器myrbdを構築し(即ち、1つのブロック記憶空間を申請する)、例えば、ステートメント「rbd create rbd/myrbd--size 204800-m[monモニター機器ipアドレス]-k/etc/ceph/ceph.client.admin.keyring」を介して構築する。
そして、クラスタ機器は、RBDマッピングを構築し、機器名称を取得し、RBDをモニター機器にマッピングし、例えばステートメント「sudo rbd map rbd/myrbd--name client.admin-m[monモニター機器ipアドレス]-k/etc/ceph/ceph.client.admin.keyring」を介してマッピングを行うとともに、モニター機器の名称を取得し、ここでは、モニター機器にマウンティングされることを例として説明する。実際には、どのスタンドアロン機器にマウンティングしようとすると、RBDを当該スタンドアロン機器にマッピングして、当該スタンドアロン機器の名称を取得するという操作を実行する。
最後、クラスタ機器は、取得した機器名称に基づき、ファイルシステムを構築し、RBDをマウンティングし、例えばステートメント「sudo mkfs.xfs/dev/rbd1」を介してファイルシステムを構築し、ステートメント「sudo mount/dev/rbd1/mnt/myrbd」を介してRBDをマウンティングする。
なお、いくつかの実施例において、クラスタ機器がストレージインターフェースを介して分散型ファイルシステムにアクセスできるだけではなく、TPクラスタにおける何れかのノード機器も、ストレージインターフェースを介して分散型ファイルシステムにアクセスでき、いずれも上記類似のマウンティング方式を実行して、配置を完成でき、ここで贅言しない。
208:クラスタ機器は、ノード機器にレプリケーション成功応答を送信する。
上記過程において、クラスタ機器は、履歴状態データを成功にターゲットデータシートに記憶した後、クラスタ機器はノード機器にACKデータ(acknowledgement、確認文字)を送信し、当該ACKデータは伝送類の制御文字であり、ノード機器が送信した履歴状態データを成功にレプリケーションしたことを示す。
209:ノード機器は、当該クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、当該レプリケーション成功応答に対応する送信バッファをクリアする。
上記過程において、ノード機器はレプリケーション成功応答を受信した場合に限り、送信バッファをクリアすることを許可し、ノード機器とクラスタ機器との間の強い同期、及びデータレプリケーション過程の安全性を保証する。
上記全ての好適な技術案に対して、任意に組み合わせで本開示の好適な実施例を形成でき、ここで、一々贅言しない。
本出願の実施例が提供する方法において、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、当該トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも1つの履歴状態データを送信バッファに追加し、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は、第1所定条件に合致する度に、送信バッファにおける履歴状態データをクラスタ機器にレプリケーションし、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器もログをデータのオリジナル形式に解析した後、記憶する必要がなく、これによって、データをレプリケーションする際、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。
また、ノード機器は、履歴状態データを同期的にレプリケーションすることで、履歴状態データがトランザクション提出の先後順序に従ってクラスタ機器にレプリケーションされるように保証し、履歴状態データをソートするというステップの実行を避け、ストリーミングレプリケーション過程のフローを簡略化する。無論、ノード機器は、データキューにおける履歴状態データを非同期的に送信バッファにレプリケーションすることで、データキューにおける履歴状態データを一括に送信バッファに追加し、履歴状態データのレプリケーション操作を頻繁に実行することを避け、さらに、ノード機器の処理効率に影響することを避けてもよいが、非同期レプリケーションの前に、履歴状態データをソートして、履歴状態データが順序付けられて送信バッファに追加されることを保証する必要があり、後続のクラスタ機器が最小のトランザクション標識を便利に取得できる。
また、第1所定条件に合致すると、送信バッファはクラスタ機器に履歴状態データをレプリケーションし、レプリケーションが成功した後、送信バッファをクリアし、その後、送信バッファは履歴状態データの追加及び履歴状態データの送信という過程を循環的に実行し、ノード機器の履歴状態データをクラスタ機器に絶えずにレプリケーションし、履歴状態データに対して再実行ログの再生を行うことを避け、データレプリケーション過程の効率を向上させる。
また、送信バッファの数が複数である場合、ノード機器はデータキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加することで、複数の送信バッファの利用率を向上させ、当該オリジナルデータシートにおける履歴状態データに対する送信レートを向上させる。
また、第1所定条件が、ノード機器が送信バッファに何れかの履歴状態データが増えたことを検出したことである場合、データレプリケーションの同期レプリケーションを実現でき、履歴状態データレプリケーション過程のリアルタイム性を保障する。第1所定条件が、ノード機器が当該送信バッファの容量に対する送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことである場合、送信バッファ容量に対する送信バッファの使用済みデータ量の占有比率を、比率閾値内に制御でき、データレプリケーション過程の効率を向上させる。第1所定条件が、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達したことである場合、2回のデータレプリケーションの間の最大の時間間隔を制御でき、履歴状態データレプリケーション過程のリアルタイム性を保障する。第1所定条件が、現在タイミングと、当該送信バッファが前回でクラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第3所定期間に達したことである場合、第3所定期間はTPクラスタの各ノード機器が具備する同じ所定期間であるから、TPクラスタの異なるノード機器のデータレプリケーション過程の遅延を制御できる。
また、クラスタ機器は、受信バッファからノード機器が送信した少なくとも1つの履歴状態データを受信した後、当該受信バッファにおける当該少なくとも1つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得し、これによって、圧縮された履歴状態データの形式を回復し、元の形式を保留する履歴状態データを直接的に取得するため、ログを解析して履歴状態データを取得することを避け、当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶し、履歴状態データに対する適切な保存を実現する。
また、業務のニーズに基づき、クラスタ機器のターゲットデータシートでは、2つの記憶形式を支持でき、タプルを単位とするデータ項目に対して、クラスタ機器はオリジナルデータシートにおける記憶形式に従って記憶でき、これによって、汎用の場合、1つのタプルのライフサイクルを便利に追跡する。フィールドの変更状況を示すデータ項目に対して、クラスタ機器はキー値ペアの記憶形式に従って記憶して、データ項目にキャリアされた情報を保留できるだけではなく、何れかのフィールドの履歴状態データの変更状況をカスタマイズ的に追跡できる。
また、キー値ペア形式による記憶過程において、クラスタ機器は、オリジナルデータシートにおけるデータ項目のキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該ターゲットデータシートにおける当該データ項目のキー名として決定することで、異なる次元から履歴状態データの変更状況を追跡し、直観的にデータ項目の生成時間を記録し、さらに、クラスタ機器は、データ項目のオリジナルデータシートにおいて修正されたフィールドを、ターゲットデータシートにおける当該データ項目のキー値として決定し、直観的に修正されたフィールドを確認し、何れかのフィールドの履歴状態データの変更状況を追跡できる。
上記実施例は、データレプリケーション方法を提供し、第1所定条件に合致する場合、ノード機器はストリーミングレプリケーション技術に基づき、履歴状態データをクラスタ機器にレプリケーションし、履歴状態データの安全性を向上させ、クラスタ機器は履歴状態データを適切に記憶した後、外部に、履歴状態データの検索、または分析などのサービスを提供できる。
上記実施例において、1つのトランザクションに1つまたは複数のサブトランザクションが含まれることを言及した。異なるサブトランザクションは異なるノード機器に対応し、ノード機器は第2所定期間ごとにデータレプリケーション過程を1回実行してもよいが、異なるノード機器の開始時点は異なってもよいため、ノード機器の間のデータレプリケーションは非同期である可能性がある。従って、いくつかのシーンにおいて、同一の提出されたトランザクションにとって、当該トランザクションの1つまたは複数のサブトランザクションに対応するノード機器はデータレプリケーションの過程において非同期であるため、あるノード機器は既にサブトランザクションに対応する履歴状態データをクラスタ機器にレプリケーションしたが、あるノード機器はサブトランザクションに対応する履歴状態データをクラスタ機器にレプリケーションしていないという状況の発生を招致し、さらに、クラスタ機器が同一のトランザクションにより影響される全ての履歴状態データを完全に読み取ることができず、APクラスタがデータを読み取る際、「不一致性」という問題が生じる。
クラスタ機器の読み取りの「不一致性」という問題を解決するために、本出願はさらにデータ検索方法を提供し、図9は、本出願の実施例が提供するデータ検索過程のフローチャートであり、図9を参照し、クラスタ機器で、履歴状態データを読み取るステップは以下のようである。
901:クラスタ機器は、トランザクション提出タイムスタンプの昇順に従って、少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、ターゲットデータシーケンスを取得する。
上記ソート過程は、トランザクション標識の値の昇順に従ってソートすることを指し、1つのトランザクションが他のトランザクションの前にあると、1つのトランザクションのトランザクション標識の値が、他のトランザクションのトランザクション標識の値より小さく、異なるトランザクションのトランザクション標識において、1つのトランザクションの提出タイミングが遅いほど、当該トランザクションのトランザクション標識の値が大きい。従って、トランザクション標識の値は、実際に提出タイミングのタイムスタンプに従って漸増する。上記ステップ901のソート過程は上記ステップ203と類似するから、ここで贅言しない。
上記過程において、各ノード機器の少なくとも1つの送信バッファはデータを送信する前に、いずれもソートが行われたが、クラスタ機器には少なくとも1つの受信バッファが設けられるため、各受信バッファが受信した履歴状態データは順序付けられるが(段階的に順序付けられる状況とみなしてもよい)、全ての受信バッファの履歴状態データは綜合的に順序付けられるように保証できないため、クラスタ機器は上記ステップ901を実行し、各受信バッファが受信した少なくとも1つの履歴状態データをソートする必要があり、当該少なくとも1つの履歴状態データは、複数のノード機器が送信した履歴状態データである。
上記過程において、TPクラスタは、定期的にCheckpoint操作を1回実行するため、クラスタ機器は少なくとも1つの受信バッファからCheckpoint操作により送信される少なくとも1つの履歴状態データを受信する度に、受信した少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプに従って順序付けられ、且つトランザクション標識に従って順序付けられるターゲットデータシーケンスを取得し、この場合、読み取りの一致性を保証するために、以下のステップ902~903を実行する。
902:クラスタ機器は、当該ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットAND操作を実行し、出力が真である履歴状態データに対応するトランザクションが、第2所定条件に合致すると決定する。
上記ステップ204で言及したように、何れかのノード機器はクラスタ機器に履歴状態データを送信する際、1つのトランザクションの1つまたは複数のサブトランザクションが1つまたは複数のノード機器に対応するため、当該トランザクションに関連するノード機器(即ち、サブトランザクションに対応するノード機器)を記録するために、一般的に、ビットマップ符号化、または辞書圧縮などの方式で、当該1つまたは複数のノード機器のノード標識を符号化することで、履歴状態データの長さを圧縮し、データ伝送が占有するリソースを減少させる。
当該少なくとも1つのトランザクションは、第2所定条件に合致するトランザクションであり、当該第2所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目が、いずれもクラスタデータベースに記憶されたことを示す。
上記ステップ902において、クラスタ機器は、当該ターゲットデータシーケンスから、当該第2所定条件に合致する少なくとも1つのトランザクションを取得し、少なくとも1つのトランザクションを取得する方式は、ノード機器の、履歴状態データに対する圧縮方式で决定される。
上記過程は、ノード機器がビットマップ符号化を利用して、データを圧縮する場合、第2所定条件に合致する少なくとも1つのトランザクションを決定する方法を提供し、即ち、ターゲットデータシーケンスにおける各履歴状態データに対してビットAND操作を行って、全てのビットがいずれも1(真)であれば、当該履歴状態データに対応するトランザクションが第2所定条件に合致することを示し、なぜならば、当該トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶され、この場合、当該少なくとも1つのトランザクションは「候補一致性ポイント」と称する。
いくつかの実施例において、ノード機器が辞書圧縮という方式でデータを圧縮する場合、上記ステップ902はさらに以下の方式で差し替えられてもよく、即ち、クラスタ機器は当該ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定した場合、当該グローバルトランザクション標識に対応するトランザクションが当該第2所定条件に合致すると決定し、これによって、辞書圧縮という状況に対しても、候補一致性ポイントを決定でき、そして、以下のステップ903を介して、候補一致性ポイントから「完備の最小のトランザクションID」を見つける。
なお、1つのトランザクションが複数のサブトランザクションを含むと、当該トランザクションは1つの「グローバルトランザクション」と称し、1つのグローバルトランザクションは、当該トランザクションに係る複数のサブトランザクションが複数のノード機器に対応することを意味し、そうすれば、何れかのグローバルトランザクションにとって、グローバルトランザクション標識及びローカルトランザクション標識という2つのタイプのトランザクション標識を含む。グローバルトランザクション標識は、TPクラスタ全体において全てのグローバルトランザクションにおける唯一の標識情報を示し、ローカルトランザクション標識は、それぞれのノード機器において全てのトランザクションにおける唯一の標識情報を示し、1つのグローバルトランザクションにとって、全てのサブトランザクションは同じグローバルトランザクション標識を有し、各サブトランザクションはそれぞれのローカルトランザクション標識を有する。
上記に基づき、グローバルトランザクション標識に対応するサブトランザクションのデータ項目はいずれも当該クラスタデータベースに記憶されたと決定する過程は以下のようであってもよい。即ち、クラスタ機器は、当該グローバルトランザクション標識に基づき、当該クラスタデータベースに記憶され、且つ当該グローバルトランザクション標識を有するデータ項目を取得し、取得した当該データ項目及び復号化による得られた当該履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定する。
903:クラスタ機器は、当該少なくとも1つのトランザクションにおける、順番が最も前にあるトランザクションに対応するトランザクション標識を最小トランザクション標識として決定する。
上記過程において、クラスタ機器は、ステップ901において各履歴状態データに対してトランザクション標識の昇順に従ってソートを行っているため、少なくとも1つのトランザクションにおける、順番が最も前にあるトランザクションに対応するトランザクション標識を直接的に取得でき、つまり、少なくとも1つのトランザクションのトランザクション標識における最小トランザクション標識を取得し、ノード機器において、トランザクション標識はタイムスタンプに従って漸増するため、最小トランザクション標識を取得することは、今回のCheckpoint操作により受信した履歴状態データにおいて最も完備(第2所定条件に合致する)且つタイムスタンプが最小であるトランザクションを取得することを意味し、当該最小トランザクション標識は「完備の最小のトランザクションID」と称し、トランザクションIDが当該最小トランザクション標識より小さいデータ項目に対して、「マイクロ一致性ポイント」と見なしてもよい。
上記ステップ901~903において、クラスタ機器は、少なくとも1つの履歴状態データのトランザクション標識から、第2所定条件に合致する最小トランザクション標識を決定し、当該第2所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶されたことを示し、これによって、今回のCheckpoint操作における完備の最小のトランザクションIDを見つける。いくつかの実施例において、今回のCheckpoint操作で、前回のCheckpoint操作により決定された最小トランザクション標識より大きい新しいラウンドの最小トランザクション標識を発見できないと、最小トランザクション標識をしばらく更新せず、TPクラスタの次回のCheckpoint操作で、上記ステップ901~903の操作を実行し、新しい最小トランザクション標識を決定した後、以下のステップ904を実行し、TPクラスタで、新しいトランザクションの持続的な提出過程において、トランザクション標識がより大きい履歴状態データが絶えず生じるように保証し、これらの履歴状態データはCheckpoint操作を介してAPクラスタに保存され、その同時、APクラスタは最小トランザクション標識の値を絶えず更新することで、完備の最小のトランザクションIDの値がますます大きくなり、前にスクロールする過程と類似し、APクラスタによるデータ検索サービスの提供のリアルタイム性を保障する。
904:クラスタ機器は、当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供し、当該可視データ項目のトランザクション標識は、当該最小トランザクション標識の以下である。
上記ステップ904において、クラスタ機器は、MVCC技術のタプル可視性判定アルゴリズムに基づき、トランザクション標識が当該最小トランザクション標識の以下であるデータ項目を外部に可視にして、マイクロCheckpoint操作メカニズムでの、APクラスタの読み取り一致性を保障する。
いくつかの実施例において、クラスタ機器が可視データ項目に基づきデータ検索サービスを提供する場合、フル状態データの任意の読み取り操作の読み取り一致性を実現でき、なぜならば、読み取り一致性は本質で、履歴状態データに基づき構築されるトランザクション一致性とみなしてもよいため、読み取り一致性を実現すると、APクラスタから読み取られた任意の時点の履歴状態データがいずれも1つのトランザクション一致性ポイントにあることを確保する。
例えば、図10は、本出願の実施例が提供するトランザクション一致性ポイントの原理的な概略図である。図10を参照し、クラスタデータベースには、r1、r2、r3(三者はAPクラスタにおける異なるスタンドアロン機器に分布されてもよい)という3つのデータ項目が存在すると仮定する。初期のデータ状態は白い丸で示し、r1、r2、r3は一致性状態(実線で示す)にあり、新しいトランザクションが生じると、データのバージョンを変更させ、例えば、T1トランザクションはt1タイミングで提出され、データ項目r1を修正し、r1の1つの新バージョンを生成し、図面において黒い丸で示す。その後、トランザクションT2はt2タイミングで提出され、データ項目r2及びr3を修正し、r2とr3との新バージョンを生成し、図面において斜線の丸で示し、そして、T3トランザクションはt3タイミングで提出され、データ項目r1及びr3を修正し、r1とr3との新バージョンを生成し、図面において、グリッド丸で示す。そして、T4トランザクションはt4タイミングで提出され、データ項目r2を修正し、r2の新バージョンを生成し、図面において、点付け丸で示す。T1~T4という一連のトランザクションの操作を経て、フル状態データの次元から観察し、図面に示す実線、長破線、短破線、破線、点線という5つの一致性状態が生じて、各線分はいずれも1つの一致性状態を代表できる。そうすれば、t1.5、t3.5などの履歴タイミングの履歴状態データを検索しようとすると、図面の曲線に示すデータバージョンが所在し、一致性状態に合致する履歴状態データ(いずれもトランザクション一致性を満たす)を介してデータ検索サービスを提供できる。
いくつかの実施例において、ユーザは、図1のSR層が提供する検索ステートメント、検索操作のセマンティック及びメタデータに基づき、TPクラスタまたはAPクラスタ内に記憶される何れかのデータをルーティング検索でき、無論、TPクラスタは主に現在状態データに対する検索サービスを提供し、APクラスタは主に履歴状態データに対する検索サービスを提供する。
好ましくは、TPクラスタが現在状態(または遷移状態)データに対する検索サービスを提供する場合、分散型並行アクセス制御アルゴリズムに基づき現在状態(または遷移状態)データのトランザクション一致性を保証し、例えば、当該分散型並行アクセス制御アルゴリズムは、ブロッキング技術による並行アクセス制御アルゴリズム、OCC(optimstic concurrency control、楽観的並行性制御)技術による並行アクセス制御アルゴリズム、TO(time ordering、時系列)技術による並行アクセス制御アルゴリズム、MVCC技術による並行アクセス制御アルゴリズムなどであってもよく、本出願の実施例は分散型並行アクセス制御アルゴリズムのタイプを具体的に限定しない。
好ましくは、APクラスタは、履歴状態データに対する検索サービスを提供する場合、上記トランザクション一致性の基礎に基づき、一致性条件を満たす履歴状態データを読み取る。
いくつかの実施例において、HTACアーキテクチャ全体はさらに、複合検索のサービスを提供でき、即ち、1つの検索操作は同時にタプルの現在状態データ及び履歴状態データに対する検索に用いられ、当該検索操作は一般的に、1つの履歴の時点を指定し、現在タイミングの現在状態データを検索するまで、当該時点からタプルの履歴状態データを持続的に読み取る。
例えば、以下のステートメントに基づき複合検索を実現できる。
SELECT
[ALL|DISTINCT|DISTINCTROW]
[HIGH_PRIORITY]
[STRAIGHT_JOIN]
[SQL_SMALL_RESULT][SQL_BIG_RESULT][SQL_BUFFER_RESULT]
[SQL_CACHE|SQL_NO_CACHE][SQL_CALC_FOUND_ROWS]
select_expr[,select_expr...]
[FROM table_references
[PARTITION partition_list]
[WHERE where_condition]
[GROUP BY{col_name|expr|position}
[ASC|DESC],...[WITH ROLLUP]]
[HAVING where_condition]
[ORDER BY{col_name|expr|position}
[ASC|DESC],...]
[LIMIT{[offset,]row_count|row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
[INTO OUTFILE'file_name'
[CHARACTER SET charset_name]
export_options
|INTO DUMPFILE'file_name'
|INTO var_name[,var_name]]
[FOR UPDATE|LOCK IN SHARE MODE]]
上記ステートメントにおいて、table_referencesの形式は、tbl_name[[AS]alias][index_hint][SNAPSHOT START snapshot_name[TO snapshot_name2][WITH type]]という形式であってもよい。
SNAPSHOTは、トランザクションスナップショット(データブロックのデータスナップショットと異なる)であり、スナップショットと略称し、「[SNAPSHOT[START snapshot_name][TO snapshot_name2][WITH type]]」は、1つの「tbl_name」オブジェクトに対して1つのスナップショット区間を指定することを示し、DQL(data query language、データ検索言語)を基に新たに追加した内容であり、ステートメントの全ての句はいずれも (SNAPSHOT、START、TO)を含み、「スナップショット読み取り始め」を示し、即ち、他のスナップショットを読み取るまで、1つのスナップショットから読み取り始める。
本出願の実施例が提供するデータ検索過程は、HTACアーキテクチャでの全体の読み取り一致性を保証し、TPクラスタの読み取り一致性だけではなく、APクラスタの読み取り一致性も保証し、APクラスタの内部で、Checkpoint操作が作用される履歴状態データを1回受信する度に、1つの新しい最小トランザクション標識(完備の最小のトランザクションID)の取得を試し、即ち、最小トランザクション標識の値の更新を試し、MVCC技術のタプル可視性判定アルゴリズムに基づき、トランザクション標識が最小トランザクション標識より小さいトランザクションに対応するデータ項目を可視にして、APクラスタに記憶される履歴状態データのトランザクションにおけるトランザクション一致性を保証する。HTACがさらに外部一致性(線形一致性、因果一致性などを含む)を支持する場合、外部一致性及びトランザクション一致性は全体的に、グローバル一致性とみなしてもよく、HTACアーキテクチャに基づきトリガーされる何れかの1項の読み取り操作はグローバル一致性を満たし、Checkpoint操作に起因して、一定のデータ遅延を招致するが、APクラスタは大体リアルタイムに、分析類業務の、データ正確性とリアルタイム性に対する検索需要、及び計算需要を満たすと認めてもよい。
上記実施例は、データレプリケーション方法に基づきデータ検索を実行する過程を提供し、第1所定条件に合致する場合、ノード機器はストリーミングレプリケーション技術に基づき、履歴状態データをクラスタ機器にレプリケーションすることで、クラスタ機器は履歴状態データの検索、分析などのサービスを提供でき、履歴状態データの安全性及び可用性を向上させる。
いくつかの実施例において、TPクラスタにおける各ノード機器に対してCheckpoint操作をトラバースして1回実行すると、TPクラスタがAPクラスタにデータをレプリケーションすることにかかる期間が大きく増えて、さらに、HTACのパフォーマンスが不安定で、HTACの安定性及びロバスト性に影響するから、マイクロCheckpoint操作を導入する。
図11は、本出願の実施例が提供するデータシステムのインタラクションフローチャートである。図11を参照し、当該データシステムはAPクラスタのクラスタ機器及びTPクラスタの複数のノード機器を含み、以下はTPクラスタがAPクラスタに対してマイクロCheckpoint操作及びCheckpoint操作を実行する過程を、詳しく説明する。
1101:第2所定期間ごとに、当該複数のノード機器のうちの何れかのノード機器に対して、当該ノード機器の少なくとも1つの履歴状態データを当該クラスタ機器にレプリケーションする。
上記ステップ1101において、TPクラスタにおける各ノード機器はいずれも第2所定期間ごとに、マイクロCheckpoint操作を1回実行し、当該ノード機器における少なくとも1つの履歴状態データをクラスタ機器にレプリケーションする。
当該第2所定期間は上記ステップ202と同様であり、当該マイクロCheckpoint操作について、上記ステップ204において既に詳しく説明し、データレプリケーションの過程は上記ステップ201-209と類似するから、ここで贅言しない。
1102:第3所定期間ごとに、当該複数のノード機器は自体の少なくとも1つの履歴状態データを同時に当該クラスタ機器にレプリケーションし、当該第3所定期間は当該第2所定期間より大きい。
当該第3所定期間は、第2所定期間より大きい何れかの値であってもよい。第2所定期間はマイクロCheckpointの操作頻度に対応し、第3所定期間はCheckpointの操作頻度に対応してもよい。
上記ステップ204において、TPクラスタは第3所定期間ごとに、TPクラスタの各ノード機器をトラバースし、Checkpoint操作を1回実行し、TPクラスタにおける全てのノード機器の少なくとも1つの履歴状態データをクラスタ機器にレプリケーションし、データレプリケーションの過程は上記ステップ201~209と類似するから、ここで贅言しない。
1103:当該第3所定期間ごとに、当該クラスタ機器は、当該複数のノード機器が送信した全ての履歴状態データのトランザクション標識から、第2所定条件に合致する最小トランザクション標識を決定し、当該第2所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれもクラスタデータベースに記憶されたことを示し、当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供し、当該可視データ項目のトランザクション標識は当該最小トランザクション標識の以下である。
上記ステップ1103は上記ステップ901~904と類似するから、ここで贅言しない。
本出願の実施例が提供するデータシステムは、TPクラスタとAPクラスタとの間のインタラクション過程を介して、システムで、TPクラスタにおける各ノード機器がそれぞれ第2所定期間ごとに、マイクロCheckpoint操作を実行し、TPクラスタ全体の全てのノード機器が第3所定期間ごとに、Checkpoint操作を1回実行するように体現し、これによって、APクラスタの履歴状態データに対するリアルタイム更新の需要を満たし、APクラスタのリアルタイムの可用性を保証する上に、マイクロCheckpoint操作を介してデータレプリケーション過程にかかるトラバース確認期間を低減させ、データレプリケーションの効率を向上させる。
図12は、本出願の実施例が提供するデータレプリケーション装置の構成概略図である。図12を参照し、当該装置は、追加モジュール1201とレプリケーションモジュール1202とを含み、以下詳しく説明する。
追加モジュール1201は、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データを、履歴状態データをキャッシングするためのデータキューに追加し、
当該追加モジュール1201はさらに、当該データキューにおける少なくとも1つの履歴状態データを、レプリケーション対象となる履歴状態データをキャッシングするための送信バッファに追加し、
レプリケーションモジュール1202は、第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションする。
本出願の実施例が提供する装置において、トランザクションの提出操作を検出した場合、当該トランザクションの履歴状態データをデータキューに追加することで、当該トランザクションの履歴状態データをデータキューにキャッシングし、当該データキューにおける少なくとも1つの履歴状態データを送信バッファに追加し、これによって、送信バッファに基づき送信プロセスまたは送信スレッドを実行し、第1所定条件に合致する場合、当該送信バッファにおける当該少なくとも1つの履歴状態データをクラスタ機器にレプリケーションすることで、ノード機器は第1所定条件に合致する度に、送信バッファにおける履歴状態データをクラスタ機器にレプリケーションし、ノード機器は元の履歴状態データ形式をログ形式に変換する必要がなく、クラスタ機器もログをデータのオリジナル形式に解析して記憶する必要がなく、データをレプリケーションする際、履歴状態データに対して再実行ログの再生を行う必要がなく、煩雑な再生フローを避け、再実行ログの再生過程の期間を短くて、データレプリケーション過程の効率を向上させる。
可能な実施形態において、当該追加モジュール1201は、
当該データキューに履歴状態データが増加したことを検出した場合、当該履歴状態データを当該送信バッファに追加し、
当該レプリケーションモジュール1202は、
当該送信バッファに履歴状態データが増加したことを検出した場合、当該送信バッファにおける当該少なくとも1つの履歴状態データを当該クラスタ機器にレプリケーションする。
可能な実施形態において、当該追加モジュール1201は、
第1所定期間ごとに、当該データキューにおける、現在タイミングの前の当該第1所定期間内に増加した少なくとも1つの履歴状態データを取得し、
トランザクション提出タイムスタンプの昇順に従って、当該少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、少なくとも1つの順次配列された履歴状態データを取得し、当該少なくとも1つの順次配列された履歴状態データを当該送信バッファに追加する。
可能な実施形態において、当該第1所定条件は、当該送信バッファに何れかの履歴状態データが増加したことを検出したことであるか、または、
当該第1所定条件は、当該送信バッファの容量に対する当該送信バッファの使用済みデータ量の占有比率が、比率閾値に達したことを検出したことであるか、または、
当該第1所定条件は、現在タイミングと、当該送信バッファが前回で当該クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達したことであるか、または、
当該第1所定条件は、現在タイミングと、当該送信バッファが前回で当該クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第3所定期間に達したことであり、当該第3所定期間は、複数のノード機器のうちの各ノード機器に対して配置される同じ所定期間であり、当該第3所定期間は当該第2所定期間より大きい。
可能な実施形態において、図12の装置構成に基づき、当該装置はさらに、
当該クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、当該レプリケーション成功応答に対応する送信バッファをクリアするためのクリアモジュールを含む。
可能な実施形態において、当該追加モジュール1201はさらに、
当該データキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の送信バッファに追加する。
なお、上記実施例が提供するデータレプリケーション装置は、データをレプリケーションする際、上記各機能モジュールの区画のみに対して例を挙げて説明したが、実際の応用で、必要に応じて、上記機能を異なる機能モジュールにより完成するように割り当て、即ち、ノード機器の内部構成を異なる機能モジュールに区画することで、以上説明した全てまたは一部の機能を完成させる。また、上記実施例が提供するデータレプリケーション装置とデータレプリケーション方法との実施例は同一の構想に属して、その具体的な実現過程について、データレプリケーション方法の実施例を参照すればよいから、ここで贅言しない。
図13は、本出願の実施例が提供するデータレプリケーション装置の構成概略図であり、図13を参照し、当該装置は受信モジュール1301、追加モジュール1302及び記憶モジュール1203を含み、以下詳しく説明する。
受信モジュール1301は、受信した履歴状態データをキャッシングするための受信バッファから、ノード機器が送信した少なくとも1つの履歴状態データを受信し、
追加モジュール1302は、当該受信バッファにおける当該少なくとも1つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得し、当該転送バッファは履歴状態データに対してデータ形式の変換を行って、
記憶モジュール1303は、当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶し、1つのターゲットデータシートは、1つデータ項目の、当該ノード機器において所在する1つのオリジナルデータシートに対応する。
本出願の実施例が提供する装置は、受信バッファからノード機器が送信した少なくとも1つの履歴状態データを受信した後、当該受信バッファにおける少なくとも1つの履歴状態データを転送バッファに追加し、当該転送バッファを介して、当該少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得し、これによって、圧縮された履歴状態データの形式を回復し、元の形式を保留する履歴状態データを直接的に取得するから、ログを解析し履歴状態データを取得する操作の実行を避け、さらに、当該少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶し、履歴状態データに対する適切な保存を実現する。
可能な実施形態において、図13の装置構成に基づき、当該記憶モジュール1303は、
タプルを単位とするデータ項目に対して、当該データ項目が所在するオリジナルデータシートにおける記憶形式に従って、当該データ項目を、当該オリジナルデータシートに対応するターゲットデータシートに記憶するための第1記憶ユニットと、
フィールドの変更状況を示すデータ項目に対して、キー値ペアの記憶形式に従って、当該データ項目を、当該オリジナルデータシートに対応するターゲットデータシートに記憶するための第2記憶ユニットと、を含む。
可能な実施形態において、当該第2記憶ユニットは、
当該オリジナルデータシートにおける当該データ項目のキー名と当該データ項目の生成時間とのうちの少なくとも一項を、当該ターゲットデータシートにおける当該データ項目のキー名として決定し、
当該オリジナルデータシートにおける当該データ項目の修正されたフィールドを、当該ターゲットデータシートにおける当該データ項目のキー値として決定する。
可能な実施形態において、図13の装置構成に基づき、当該装置はさらに、
当該少なくとも1つの履歴状態データのトランザクション標識から、第2所定条件に合致する最小トランザクション標識を決定するための決定モジュールであって、当該第2所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれも当該クラスタデータベースに記憶されたことを示す決定モジュールと、
当該最小トランザクション標識に基づき、可視データ項目を決定し、当該可視データ項目に基づき、データ検索サービスを提供するための検索モジュールであって、当該可視データ項目のトランザクション標識が当該最小トランザクション標識の以下である検索モジュールとを含む。
可能な実施形態において、図13の装置構成に基づき、当該決定モジュールは、
トランザクション提出タイムスタンプの昇順に従って、当該少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、当該複数の履歴状態データをソートし、ターゲットデータシーケンスを取得するためのソートユニットと、
当該ターゲットデータシーケンスから、当該第2所定条件に合致する少なくとも1つのトランザクションを取得するための取得ユニットと、
当該少なくとも1つのトランザクションにおける、順番が最も前にあるトランザクションのトランザクション標識を、当該最小トランザクション標識として決定するための決定ユニットとを含む。
可能な実施形態において、当該取得ユニットは、
当該ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットAND操作を実行し、出力が真である履歴状態データに対応するトランザクションが、第2所定条件に合致すると決定し、
または、当該ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定した場合、当該グローバルトランザクション標識に対応するトランザクションが当該第2所定条件に合致すると決定するためのトラバース決定サブユニットを含む。
可能な実施形態において、トラバース決定サブユニットはさらに、
当該グローバルトランザクション標識に基づき、当該クラスタデータベースに記憶され、且つ当該グローバルトランザクション標識を有するデータ項目を取得し、取得した当該データ項目及び復号化により得られた当該履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、当該グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも当該クラスタデータベースに記憶されたと決定する。
可能な実施形態において、当該受信モジュール1301は、
第2所定期間ごとに、当該受信バッファから、何れかのノード機器が送信した少なくとも1つの履歴状態データを受信するか、または、
第3所定期間ごとに、当該受信バッファから複数のノード機器が同時に送信した少なくとも1つの履歴状態データを受信する。
なお、上記実施例が提供するデータレプリケーション装置は、データをレプリケーションする際、上記各機能モジュールの区画のみに対して、例を挙げて説明したが、実際の応用において、必要に応じて、上記機能を異なる機能モジュールにより完成するように割り当て、即ち、クラスタ機器の内部構成を異なる機能モジュールに区画することで、以上説明した全てまたは一部の機能を完成させる。また、上記実施例が提供するデータレプリケーション装置とデータレプリケーション方法との実施例は同一の構想に属して、その具体的な実現過程について、データレプリケーション方法の実施例を参照すればよいから、ここで贅言しない。
図14は、本出願の実施例が提供するコンピュータ機器の構成概略図であり、当該コンピュータ機器1400は、配置またはパフォーマンスにより、大きい差が生じて、1つまたは複数のプロセッサー(central processing units、CPU)1401及び1つまたは複数のメモリ1402を含んでもよく、当該メモリ1402には少なくとも1つの命令が記憶され、当該少なくとも1つの命令は当該プロセッサー1401によりロードされ、実行されることで、上記各データレプリケーション方法の実施例が提供するデータレプリケーション方法を実現する。無論、当該コンピュータ機器はさらに、入出力を行うための有線または無線ネットワークインターフェース、キーボード及び入出力インターフェースなどの構成要素を有してもよく、当該コンピュータ機器はさらに、機器機能を実現するための他の構成要素を含んでもよく、ここで贅言しない。
例示的な実施例において、さらにコンピュータ可読記憶媒体を提供し、例えば少なくとも1つの命令を含むメモリであり、上記少なくとも1つの命令は端末のプロセッサーにより実行されることで、上記実施例のデータレプリケーション方法を完成させる。例えば、当該コンピュータ可読記憶媒体は、ROM、ランダムアクセスメモリ(RAM)、CD-ROM、磁気テープ、フレキシブルディスク及び光データ記憶装置などであってもよい。
上記実施例を実現するための全てまたは一部のステップは、ハードウェアにより完成されてもよいし、プログラムにより関連するハードウェアに命令することで完成されてもよく、当該プログラムはコンピュータ可読記憶媒体に記憶され、上記言及された記憶媒体は、読み取り専用メモリ、磁気ディスクまたは光ディスクなどであってもよい。
以上は本出願の好適な実施例であり本出願を限定するためのものではなく、本出願の精神及び原則内でなされた任意の修正、等価置換、改良などは、いずれも本出願の保護範囲に該当する。
1201 追加モジュール
1202 レプリケーションモジュール
1301 受信モジュール
1302 追加モジュール
1303 記憶モジュール
1400 コンピュータ機器
1401 プロセッサー
1402 メモリ

Claims (18)

  1. マルチバージョンコンカレンシーコントロール(MVCC)によるデータベースに基づくハイブリッドトランザクション/分析クラスタ(HTAC)アーキテクチャのトランザクション処理クラスタのノード機器により実行されるデータレプリケーション方法であって、前記MVCCによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の3つの状態を含み、
    トランザクションの提出操作を検出した場合、前記トランザクションの履歴状態データをデータキューに追加するステップであって、前記データキューは、履歴状態データをキャッシングするためのものであるステップと、
    前記データキューにおける少なくとも1つの履歴状態データを送信バッファに追加するステップであって、前記送信バッファは、レプリケーション対象となる履歴状態データをキャッシングするためのものであるステップと、
    第1所定条件に合致する場合、前記送信バッファにおける前記少なくとも1つの履歴状態データを前記MVCCによるデータベースに基づく前記HTACアーキテクチャの分析処理クラスタのクラスタ機器にレプリケーションするステップであって、前記クラスタ機器は、前記少なくとも1つの履歴状態データを記憶し、前記少なくとも1つの履歴状態データに基づき、検索及び分析サービスを提供するために使用され、前記少なくとも1つの履歴状態データは読み取ることだけができ、修正または削除することはできない、ステップと、
    前記ノード機器において、レプリケーションされた前記少なくとも1つの履歴状態データをレプリケーションが完了した後で削除するステップと
    を含み、
    前記MVCCによるデータベースにおいて、前記トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、方法。
  2. 前記データキューにおける少なくとも1つの履歴状態データを送信バッファに追加する前記ステップは、
    前記データキューに履歴状態データが増加したことを検出した場合、前記履歴状態データを前記送信バッファに追加するステップを含み、
    前記第1所定条件に合致する場合、前記送信バッファにおける前記少なくとも1つの履歴状態データをクラスタ機器にレプリケーションする前記ステップは、
    前記送信バッファに履歴状態データが増加したことを検出した場合、前記送信バッファにおける前記少なくとも1つの履歴状態データを前記クラスタ機器にレプリケーションするステップを含む請求項1に記載の方法。
  3. 前記データキューにおける少なくとも1つの履歴状態データを送信バッファに追加する前記ステップは、
    第1所定期間ごとに、前記データキューにおける、現在タイミングの前の前記第1所定期間内に増加した少なくとも1つの履歴状態データを取得するステップと、
    トランザクション提出タイムスタンプの昇順に従って、前記少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、前記複数の履歴状態データをソートし、少なくとも1つの順次配列された履歴状態データを取得し、前記少なくとも1つの順次配列された履歴状態データを前記送信バッファに追加するステップと、を含む請求項1に記載の方法。
  4. 前記第1所定条件は、
    前記送信バッファに何れかの履歴状態データが増加したことを検出したことと、
    前記送信バッファの容量に対する前記送信バッファの使用済みデータ量の占有比率が比率閾値に達したことを検出したことと、
    現在タイミングと、前記送信バッファが前回で前記クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第2所定期間に達したことと、
    現在タイミングと、前記送信バッファが前回で前記クラスタ機器に履歴状態データをレプリケーションしたタイミングとの時間差が第3所定期間に達したこととのうちの、何れかの1つまたは複数を含み、
    前記第3所定期間は、複数のノード機器のうちの各ノード機器に対して配置する同じ所定期間であり、前記第3所定期間が前記第2所定期間より大きい、請求項1~3の何れかの1項に記載の方法。
  5. 前記方法はさらに、前記クラスタ機器によって送信されたレプリケーション成功応答を受信した場合、前記レプリケーション成功応答に対応する送信バッファをクリアするステップを含む請求項1に記載の方法。
  6. 前記送信バッファの数が複数である場合、前記方法はさらに、
    前記データキューにおける、同一のオリジナルデータシートからの履歴状態データを均一に複数の前記送信バッファに追加するステップを含む請求項1に記載の方法。
  7. マルチバージョンコンカレンシーコントロール(MVCC)によるデータベースに基づくハイブリッドトランザクション/分析クラスタ(HTAC)アーキテクチャの分析処理クラスタのクラスタ機器により実行されるデータレプリケーション方法であって、前記MVCCによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の3つの状態を含み、前記クラスタ機器は、履歴状態データを記憶し、前記履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記履歴状態データは読み取ることだけができ、修正または削除することはできず、
    受信バッファから、前記MVCCによるデータベースに基づく前記HTACアーキテクチャのトランザクション処理クラスタのノード機器が送信した少なくとも1つの履歴状態データを受信するステップであって、前記受信バッファは、受信した履歴状態データをキャッシングするためのものであり、受信した前記履歴状態データは、前記ノード機器においてレプリケーションが完了した後に削除され、前記ノード機器はトランザクション処理サービスを提供するために使用される、ステップと、
    前記受信バッファにおける前記少なくとも1つの履歴状態データを転送バッファに追加し、前記転送バッファを介して、前記少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得するステップであって、前記転送バッファは、履歴状態データに対してデータ形式の変換を行うためのものであるステップと、
    前記少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶するステップであって、1つのターゲットデータシートは、1つのデータ項目の、前記ノード機器において所在する1つのオリジナルデータシートに対応するステップと、を含み、
    前記MVCCによるデータベースにおいて、トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、方法。
  8. 前記少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶する前記ステップは、
    タプルを単位とするデータ項目に対して、前記データ項目が所在するオリジナルデータシートにおける記憶形式に従って、前記データ項目を、前記オリジナルデータシートに対応するターゲットデータシートに記憶するステップ、又は
    フィールドの変更状況を示すデータ項目に対して、キー値ペアの記憶形式に従って、前記データ項目を、前記オリジナルデータシートに対応するターゲットデータシートに記憶するステップを含む請求項7に記載の方法。
  9. 前記キー値ペアの記憶形式に従って、前記データ項目を前記オリジナルデータシートに対応するターゲットデータシートに記憶する前記ステップは、
    前記オリジナルデータシートにおける前記データ項目のキー名と前記データ項目の生成時間とのうちの少なくとも一項を、前記ターゲットデータシートにおける前記データ項目のキー名として決定するステップと、
    前記オリジナルデータシートにおける前記データ項目の修正されたフィールドを、前記ターゲットデータシートにおける前記データ項目のキー値として決定するステップと、を含む請求項8に記載の方法。
  10. 前記方法はさらに、
    前記少なくとも1つの履歴状態データのトランザクション標識から、第2所定条件に合致する最小トランザクション標識を決定するステップであって、前記第2所定条件は、トランザクションの全てのサブトランザクションに対応するデータ項目がいずれも前記クラスタデータベースに記憶されたことを示すステップと、
    前記最小トランザクション標識に基づき、可視データ項目を決定するステップであって、前記可視データ項目のトランザクション標識が前記最小トランザクション標識の以下であるステップと、
    前記可視データ項目に基づき、データ検索サービスを提供するステップと、を含む請求項7に記載の方法。
  11. 前記少なくとも1つの履歴状態データのトランザクション標識から、第2所定条件に合致する最小トランザクション標識を決定する前記ステップは、
    トランザクション提出タイムスタンプの昇順に従って、前記少なくとも1つの履歴状態データをソートし、トランザクション提出タイムスタンプが同じである複数の履歴状態データが存在する場合、トランザクション標識の昇順に従って、前記複数の履歴状態データをソートし、ターゲットデータシーケンスを取得するステップと、
    前記ターゲットデータシーケンスから、前記第2所定条件に合致する少なくとも1つのトランザクションを取得するステップと、
    前記少なくとも1つのトランザクションにおける、順番が最も前にあるトランザクションのトランザクション標識を前記最小トランザクション標識として決定するステップと、を含む請求項10に記載の方法。
  12. 前記ターゲットデータシーケンスから、前記第2所定条件に合致する少なくとも1つのトランザクションを取得する前記ステップは、
    前記ターゲットデータシーケンスをトラバースし、各履歴状態データのビットマップ符号化に対してビットAND操作を実行し、出力が真である履歴状態データに対応するトランザクションが前記第2所定条件に合致すると決定するステップ、又は
    前記ターゲットデータシーケンスをトラバースし、各履歴状態データの圧縮辞書を復号化し、各履歴状態データに対応するグローバルトランザクション標識を取得し、前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定した場合、前記グローバルトランザクション標識に対応するトランザクションが前記第2所定条件に合致すると決定するステップを含む請求項11に記載の方法。
  13. 前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定する前記ステップは、
    前記グローバルトランザクション標識に基づき、前記クラスタデータベースに記憶され、且つ前記グローバルトランザクション標識を有するデータ項目を取得し、取得した前記データ項目及び復号化により得られた前記履歴状態データがトランザクションの全てのサブトランザクションに対応する場合、前記グローバルトランザクション標識に対応するサブトランザクションのデータ項目がいずれも前記クラスタデータベースに記憶されたと決定するステップを含む請求項12に記載の方法。
  14. 前記受信バッファからノード機器が送信した少なくとも1つの履歴状態データを受信する前記ステップは、
    第2所定期間ごとに、前記受信バッファから、何れかのノード機器が送信した少なくとも1つの履歴状態データを受信するステップ、又は
    第3所定期間ごとに、前記受信バッファから、複数のノード機器が同時に送信した少なくとも1つの履歴状態データを受信するステップを含む請求項7に記載の方法。
  15. マルチバージョンコンカレンシーコントロール(MVCC)によるデータベースに基づくハイブリッドトランザクション/分析クラスタ(HTAC)アーキテクチャのトランザクション処理クラスタに含まれる、データレプリケーション装置であって、前記MVCCによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の3つの状態を含み、
    トランザクションの提出操作を検出した場合、前記トランザクションの履歴状態データをデータキューに追加し、前記データキューにおける少なくとも1つの履歴状態データを送信バッファに追加するための追加モジュールであって、前記データキューは、履歴状態データをキャッシングするためのものであり、前記送信バッファは、レプリケーション対象となる履歴状態データをキャッシングするためのものである追加モジュールと、
    第1所定条件に合致する場合、前記送信バッファにおける前記少なくとも1つの履歴状態データを前記MVCCによるデータベースに基づく前記HTACアーキテクチャの分析処理クラスタのクラスタ機器にレプリケーションするためのレプリケーションモジュールであって、前記クラスタ機器は、前記少なくとも1つの履歴状態データを記憶し、前記少なくとも1つの履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記少なくとも1つの履歴状態データは読み取ることだけができ、修正または削除することはできず、前記データレプリケーション装置において、レプリケーションされた前記少なくとも1つの履歴状態データをレプリケーションが完了した後で削除する、レプリケーションモジュールと、を含み、
    前記MVCCによるデータベースにおいて、前記トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、装置。
  16. マルチバージョンコンカレンシーコントロール(MVCC)によるデータベースに基づくハイブリッドトランザクション/分析クラスタ(HTAC)アーキテクチャの分析処理クラスタに含まれる、データレプリケーション装置であって、前記MVCCによるデータベースにおけるデータは、それぞれ前記データのライフサイクル軌跡における異なる状態を識別する、現在状態、遷移状態、及び履歴状態の3つの状態を含み、前記データレプリケーション装置は、履歴状態データを記憶し、前記履歴状態データに基づき、検索及び分析サービスを提供するために用いられ、前記履歴状態データは読み取ることだけができ、修正または削除することはできず、
    受信バッファから、前記MVCCによるデータベースに基づく前記HTACアーキテクチャのトランザクション処理クラスタのノード機器が送信した少なくとも1つの履歴状態データを受信するための受信モジュールであって、前記受信バッファは、受信した履歴状態データをキャッシングするためのものであり、受信した前記履歴状態データは、前記ノード機器においてレプリケーションが完了した後に削除され、前記ノード機器はトランザクション処理サービスを提供するために使用される、受信モジュールと、
    前記受信バッファにおける前記少なくとも1つの履歴状態データを転送バッファに追加し、前記転送バッファを介して、前記少なくとも1つの履歴状態データを、タプル形式に合致するデータに変換し、少なくとも1つのデータ項目を取得するための追加モジュールであって、前記転送バッファは、履歴状態データに対してデータ形式の変換を行うためのものである追加モジュールと、
    前記少なくとも1つのデータ項目をクラスタデータベースの少なくとも1つのターゲットデータシートに記憶するための記憶モジュールであって、1つのターゲットデータシートは、1つのデータ項目の、前記ノード機器において所在する1つのオリジナルデータシートに対応する記憶モジュールと、を含み、
    前記MVCCによるデータベースにおいて、トランザクションが提出された後の前記データの新しい値を前記現在状態、前記トランザクションが提出される前の前記データの値を前記履歴状態の値とし、前記現在状態と前記履歴状態との間のデータ状態を前記遷移状態と称する、装置。
  17. コンピュータ機器であって、前記コンピュータ機器は、プロセッサーとメモリとを含み、前記メモリには少なくとも1つの命令が記憶され、前記少なくとも1つの命令は前記プロセッサーによりロードされ、実行されることで、請求項1~請求項6または請求項7~請求項14の何れかの1項に記載のデータレプリケーション方法を実現することを特徴とするコンピュータ機器。
  18. 命令を含むコンピュータプログラムであって、コンピュータで実行される場合、コンピュータに請求項1~請求項6または請求項7~請求項14の何れかの1項に記載のデータレプリケーション方法を実行させるコンピュータプログラム。
JP2021532087A 2019-05-05 2020-04-10 データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム Active JP7271670B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910368297.XA CN110209734B (zh) 2019-05-05 2019-05-05 数据复制方法、装置、计算机设备及存储介质
CN201910368297.X 2019-05-05
PCT/CN2020/084085 WO2020224374A1 (zh) 2019-05-05 2020-04-10 数据复制方法、装置、计算机设备及存储介质

Publications (2)

Publication Number Publication Date
JP2022510460A JP2022510460A (ja) 2022-01-26
JP7271670B2 true JP7271670B2 (ja) 2023-05-11

Family

ID=67786863

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021532087A Active JP7271670B2 (ja) 2019-05-05 2020-04-10 データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム

Country Status (5)

Country Link
US (1) US11921746B2 (ja)
EP (1) EP3968175B1 (ja)
JP (1) JP7271670B2 (ja)
CN (1) CN110209734B (ja)
WO (1) WO2020224374A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110209734B (zh) * 2019-05-05 2022-11-18 深圳市腾讯计算机系统有限公司 数据复制方法、装置、计算机设备及存储介质
CN110955612B (zh) * 2019-11-07 2022-03-08 浪潮电子信息产业股份有限公司 一种数据缓存方法及相关装置
CN111694825B (zh) * 2020-05-27 2024-04-09 平安银行股份有限公司 机构撤并数据核验方法、装置、计算机设备及存储介质
CN112380266A (zh) * 2020-10-16 2021-02-19 广州市百果园网络科技有限公司 消息数据处理方法、装置、设备和存储介质
US11159617B1 (en) * 2021-01-22 2021-10-26 Juniper Networks, Inc Apparatus, system, and method for synchronizing replicated objects across network nodes in highly scaled environments
CN113193947B (zh) * 2021-04-23 2022-11-15 北京百度网讯科技有限公司 实现分布式全局序的方法、设备、介质及程序产品
CN113297605B (zh) * 2021-06-24 2023-05-05 中国建设银行股份有限公司 复制数据管理方法、装置、电子设备及计算机可读介质
CN113722396B (zh) * 2021-08-25 2023-12-22 武汉达梦数据库股份有限公司 一种数据同步接收端服务主备切换的方法及设备
CN113704340B (zh) * 2021-08-30 2023-07-21 远景智能国际私人投资有限公司 数据处理方法、装置、服务器及存储介质
US11922026B2 (en) 2022-02-16 2024-03-05 T-Mobile Usa, Inc. Preventing data loss in a filesystem by creating duplicates of data in parallel, such as charging data in a wireless telecommunications network
CN114860824A (zh) * 2022-04-11 2022-08-05 远景智能国际私人投资有限公司 数据传输方法、装置、设备及存储介质
CN115134266A (zh) * 2022-05-31 2022-09-30 西安北方华创微电子装备有限公司 数据上传方法、数据接收方法和半导体工艺设备
CN114884774B (zh) * 2022-06-01 2023-10-03 北京东土军悦科技有限公司 数据包转发方法及装置、网络设备和计算设备
CN114741206B (zh) * 2022-06-09 2022-09-06 深圳华锐分布式技术股份有限公司 客户端数据回放处理方法、装置、设备及存储介质
CN116301593B (zh) * 2023-02-09 2024-02-02 安超云软件有限公司 在云平台下跨集群跨存储拷贝块数据的方法及应用
CN115951846B (zh) * 2023-03-15 2023-06-13 苏州浪潮智能科技有限公司 数据写入方法、装置、设备及介质
CN116644103B (zh) * 2023-05-17 2023-11-24 本原数据(北京)信息技术有限公司 基于数据库的数据排序方法和装置、设备、存储介质
CN116385001B (zh) * 2023-06-07 2023-08-22 建信金融科技有限责任公司 交易日志回放方法、装置、电子设备及存储介质
CN116578655B (zh) * 2023-07-06 2023-09-15 舟谱数据技术南京有限公司 一种数据传输系统及其控制方法
CN116644215B (zh) * 2023-07-27 2023-09-29 北京亿中邮信息技术有限公司 一种跨组织结构的数据更新方法以及更新系统
CN116980475A (zh) * 2023-07-31 2023-10-31 深圳市亲邻科技有限公司 一种基于binlog与双环形缓冲区的数据推送系统
CN116701544B (zh) * 2023-08-07 2023-11-24 金篆信科有限责任公司 分布式数据库日志处理方法和装置、电子设备和存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003263350A (ja) 2002-03-07 2003-09-19 Ricoh Co Ltd データベースシステム
JP2006092005A (ja) 2004-09-21 2006-04-06 Hitachi Ltd データ処理方法、データベースシステム及びストレージ装置
JP2006260292A (ja) 2005-03-17 2006-09-28 Fujitsu Ltd リモートコピー方法及びストレージシステム
WO2007028249A1 (en) 2005-09-09 2007-03-15 Avokia Inc. Method and apparatus for sequencing transactions globally in a distributed database cluster with collision monitoring
JP2010061559A (ja) 2008-09-05 2010-03-18 Hitachi Ltd 情報処理システム、データ更新方法およびデータ更新プログラム
JP2010527087A (ja) 2007-05-21 2010-08-05 エヌエイチエヌ コーポレーション データベースマネジメントシステム(dbms)におけるデータ複製方法およびシステム
JP2015064850A (ja) 2013-09-26 2015-04-09 日本電気株式会社 データベース監視装置、データベース監視方法、並びにコンピュータ・プログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170480A (en) * 1989-09-25 1992-12-08 International Business Machines Corporation Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time
US5799305A (en) * 1995-11-02 1998-08-25 Informix Software, Inc. Method of commitment in a distributed database transaction
WO2003044697A1 (en) * 2001-11-16 2003-05-30 Paralleldb, Incorporated Data replication system and method
CA2472887A1 (en) * 2003-06-30 2004-12-30 Gravic, Inc. Methods for ensuring referential integrity in multithreaded replication engines
CN101719165B (zh) * 2010-01-12 2014-12-17 浪潮电子信息产业股份有限公司 一种实现数据库高效快速备份的方法
CN102609479B (zh) 2012-01-20 2015-11-25 北京思特奇信息技术股份有限公司 一种内存数据库节点复制方法
CN104239476B (zh) * 2014-09-04 2018-09-25 上海天脉聚源文化传媒有限公司 一种数据库同步的方法、装置及系统
US9965359B2 (en) * 2014-11-25 2018-05-08 Sap Se Log forwarding to avoid deadlocks during parallel log replay in asynchronous table replication
US20180096018A1 (en) * 2016-09-30 2018-04-05 Microsoft Technology Licensing, Llc Reducing processing for comparing large metadata sets
US10168928B2 (en) * 2017-03-10 2019-01-01 International Business Machines Corporation Managing data storage by an asynchronous copy service
CN109902127B (zh) * 2019-03-07 2020-12-25 腾讯科技(深圳)有限公司 历史态数据处理方法、装置、计算机设备及存储介质
CN109992628B (zh) * 2019-04-15 2022-10-25 深圳市腾讯计算机系统有限公司 数据同步的方法、装置、服务器及计算机可读存储介质
CN110209734B (zh) * 2019-05-05 2022-11-18 深圳市腾讯计算机系统有限公司 数据复制方法、装置、计算机设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003263350A (ja) 2002-03-07 2003-09-19 Ricoh Co Ltd データベースシステム
JP2006092005A (ja) 2004-09-21 2006-04-06 Hitachi Ltd データ処理方法、データベースシステム及びストレージ装置
JP2006260292A (ja) 2005-03-17 2006-09-28 Fujitsu Ltd リモートコピー方法及びストレージシステム
WO2007028249A1 (en) 2005-09-09 2007-03-15 Avokia Inc. Method and apparatus for sequencing transactions globally in a distributed database cluster with collision monitoring
JP2010527087A (ja) 2007-05-21 2010-08-05 エヌエイチエヌ コーポレーション データベースマネジメントシステム(dbms)におけるデータ複製方法およびシステム
JP2010061559A (ja) 2008-09-05 2010-03-18 Hitachi Ltd 情報処理システム、データ更新方法およびデータ更新プログラム
JP2015064850A (ja) 2013-09-26 2015-04-09 日本電気株式会社 データベース監視装置、データベース監視方法、並びにコンピュータ・プログラム

Also Published As

Publication number Publication date
CN110209734B (zh) 2022-11-18
EP3968175B1 (en) 2023-10-18
US11921746B2 (en) 2024-03-05
JP2022510460A (ja) 2022-01-26
US20210279254A1 (en) 2021-09-09
EP3968175A4 (en) 2022-05-25
EP3968175A1 (en) 2022-03-16
WO2020224374A1 (zh) 2020-11-12
CN110209734A (zh) 2019-09-06

Similar Documents

Publication Publication Date Title
JP7271670B2 (ja) データレプリケーション方法、装置、コンピュータ機器及びコンピュータプログラム
US20200285549A1 (en) Method and apparatus for reading and writing committed data
JP7410181B2 (ja) ハイブリッド・インデックス作成方法、システム、プログラム
CN111143389B (zh) 事务执行方法、装置、计算机设备及存储介质
US10078682B2 (en) Differentiated secondary index maintenance in log structured NoSQL data stores
USRE47106E1 (en) High-performance log-based processing
CN111159252B (zh) 事务执行方法、装置、计算机设备及存储介质
US8868512B2 (en) Logging scheme for column-oriented in-memory databases
US7653668B1 (en) Fault tolerant multi-stage data replication with relaxed coherency guarantees
JP2019036353A (ja) 索引更新パイプライン
CN109992628B (zh) 数据同步的方法、装置、服务器及计算机可读存储介质
US20080222159A1 (en) Database system with active standby and nodes
WO2013174305A1 (zh) 基于SSD的Key-Value型本地存储方法及系统
JP2016524750A5 (ja)
CN112084258A (zh) 一种数据同步方法和装置
US20230418811A1 (en) Transaction processing method and apparatus, computing device, and storage medium
CN115114370B (zh) 主从数据库的同步方法、装置、电子设备和存储介质
CN112328702A (zh) 数据同步方法及系统
CN113051221A (zh) 数据存储方法、装置、介质、设备及分布式文件系统
CN114385577A (zh) 一种分布式文件系统
CN111522688A (zh) 分布式系统的数据备份方法及装置
US20240126782A1 (en) Configuration and management of replication units for asynchronous database transaction replication
CN117591552A (zh) 数据处理方法、介质、装置和计算设备
CN112818018A (zh) 分布式数据库的数据处理方法、装置及系统
CN117420947A (zh) 一种分布式数据库实时储存功能的方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210604

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210604

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220719

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220822

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221122

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: 20230327

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230426

R150 Certificate of patent or registration of utility model

Ref document number: 7271670

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150