JP7208967B2 - 異種ターゲットに対して使用するために分散型データソースからの変更データをキャプチャするためのシステムおよび方法 - Google Patents

Description

著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

優先権の主張および関連出願の相互参照
本願は、２０１７年９月２９日に出願され「SYSTEM AND METHOD FOR CAPTURE OF CHANGE DATA FROM NOSQL DATABASES OR DISTRIBUTED DATA STREAMS, FOR USE WITH HETEROGENEOUS TARGETS」と題された米国仮特許出願第６２／５６６，１１３号に基づく優先権の利益を主張し、かつ、後に米国特許第８，５１０，２７０号として発行された、２０１０年７月２７日に出願され「HETEROGENEOUS LOG BASED REPLICATION FROM DATABASES SUCH AS MYSQL DATABASES」と題された米国仮特許出願第６１／３６８，１４１号に基づく優先権の利益を主張する２０１１年３月３１日に出願され「MYSQL DATABASE - HETEROGENEOUS LOG BASED REPLICATION」と題された米国特許出願第１３／０７７，７６０号に関連し、上記出願各々を、本明細書に引用により援用する。

技術分野
本願に記載の実施形態は、１つ以上の異種ターゲットに対して使用するために分散型データソースシステムからの変更データをキャプチャすることに関し、これは、分散型ソーストポロジー・アウェアネス、初期ロード、重複排除、およびリカバリなどの特徴に対するサポートを含む。

背景
組織は、時として、たとえばデータのバックアップを作成するためにまたは異なるデータアプリケーション間でデータを共有できるようにするために、異なるデータベース環境間でデータを移動させる必要がある場合がある。データレプリケーションシステムは、データベーステーブル全体とこのテーブル内のデータとをコピーするのではなく、たとえば行演算の結果生じたデータベーステーブル内のデータの変更を検出してレプリケートすることにより、上記必要への対応を支援する。このようなアプローチを用いることにより、ターゲットデータベース内のデータを、ソースデータベース内のデータと同期させることができる。

しかしながら、非常に大きなデータセットをサポートする環境、たとえばビッグデータ環境には、可用性、スケーラビリティ、およびフォールトトレランスに関する課題があり、従来のデータベースまたはデータレプリケーションシステムは、このような大量のデータを扱うのに十分拡張できない場合がある。このような懸案事項に対処するために、分散型データソース、たとえばApache Cassandra、Kafka、MongoDB、Oracle NoSQL、またはGoogle（登録商標） Bigtableといったデータベースを提供するシステムに移行する組織が増えている。これらは、本教示の実施形態を使用できる環境のタイプのいくつかの例である。

概要
ある実施形態に従い、本明細書では、１つ以上の異種ターゲット、たとえばデータベースまたはメッセージキューに対して使用するために、分散型データソースシステム、たとえば分散型データベースまたは分散型データストリームからの変更データをキャプチャし、カノニカルフォーマット出力を作成するための、システムおよび方法について説明する。変更データキャプチャシステムは、分散型ソーストポロジー・アウェアネス、初期ロード、重複排除、およびリカバリなどの特徴に対するサポートを含み得る。本明細書に記載のシステムおよび方法の技術的目的は、複数のノードに分散する大量のデータを含む分散型データソースにおけるデータに対してなされた変更を判断し１つ以上のターゲットコンピュータシステムに伝達することを含む。

ある実施形態に係る、異種ターゲットに対して使用するために分散型データソースからの変更データをキャプチャするためのシステムを示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするための方法のフローチャートを示す。 ある実施形態に係る、分散型データソースからの変更データのキャプチャに対して使用される、重複排除プロセスのフローチャートを示す。 ある実施形態に係る、重複排除プロセスを含む分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図をさらに示す。 ある実施形態に係る、分散型データソースからの変更データのキャプチャに対して使用されるリカバリプロセスのフローチャートを示す。 ある実施形態に係る、リカバリプロセスを含む分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。 別の実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。 さらに別の実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムに対して使用されるリカバリシナリオの一例を示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムに対して使用されるリカバリシナリオの別の例を示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムに対して使用されるリカバリシナリオの別の例を示す。 ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムに対して使用されるリカバリシナリオの別の例を示す。

詳細な説明
先に述べたように、組織は、時として、たとえばデータのバックアップを作成するためにまたは異なるデータアプリケーション間でデータを共有できるようにするために、異なるデータベース環境間でデータを移動させる必要がある場合がある。データレプリケーションシステムは、データベーステーブル全体とこのテーブル内のデータとをコピーするのではなく、たとえば行演算の結果生じたデータベーステーブル内のデータの変更を検出してレプリケートすることにより、上記必要への対応を支援する。このようなアプローチを用いることにより、ターゲットデータベース内のデータを、ソースデータベース内のデータと同期させることができる。しかしながら、非常に大きなデータセットをサポートする環境、たとえばビッグデータ環境には、可用性、スケーラビリティ、およびフォールトトレランスに関する課題がある。

たとえば、コミットログまたはトランザクションログを読み取ることによってデータソースにおける変更を抽出するように動作するデータレプリケーションシステムは、以下の課題に直面する。すなわち、ソースシステムはさまざまなノード上にデータの２つ以上のコピーを有する場合があること、ソースシステムは分断耐性を有すること、いくつかのノードが故障しネットワーク接続性を有しない場合があること、および、ソースシステムが１つ以上の追加された新たなノードを有し異なる場所からの新たなデータが存在する場合があること、である。

組織は、ソースシステムに接続されたジョブを用いてこの課題に対応しクエリを実行することにより異なるソースおよびターゲットシステムにまたがるデータセットまたはテーブルデータ全体を抜き出そうとすることができるものの、データ量が多いときはこのデータの移動に多大な遅延が生じる。

分散型データソースからのデータキャプチャ
ある実施形態に従い、本明細書では、１つ以上の異種ターゲット、たとえばデータベースまたはメッセージキューに対して使用するために、分散型データソースシステム、たとえば分散型データベースまたは分散型データストリームからの変更データをキャプチャし、カノニカルフォーマット出力を作成するための、システムおよび方法について説明する。変更データキャプチャ（change data capture）（ＣＤＣ）システムは、分散型ソーストポロジー・アウェアネス、初期ロード、重複排除、およびリカバリなどの特徴に対するサポートを含み得る。本明細書に記載のシステムおよび方法の技術的目的は、複数のノードに分散する大量のデータを含む分散型データソースにおけるデータに対してなされた変更を判断し１つ以上のターゲットコンピュータシステムに伝達することを含む。

ある実施形態に従うと、変更データキャプチャシステムは、たとえば以下を可能にする、分散型ソーストポロジー・アウェアネス、初期ロード、重複排除、およびリカバリなどの特徴に対するサポートを含む。

異種ターゲット、たとえばデータベースまたはメッセージキューに対して使用するための、分散型データソースからのインクリメンタル変更のキャプチャ。

分散型データソースから提供されたデータの自動重複排除。
ソース変更トレースエンティティに対するアクセスが設定可能である、分散型ソーストポロジーの自動発見、および、ノードの追加または削除などの、分散型データソースに対する動的変更をサポートする分散型ソーストポロジー・アウェアネス。

記録を活発に提供していた分散型データソースシステム内のノードがたとえば故障によって使用できなくなったときに、レプリカノードを選択し、故障したノードが処理した最後の記録に対するルックアップを実行できるようにするための、リカバリに対するサポート。キャプチャプロセス自体は、クラッシュに対する耐性があり、データ損失または重複記録を招くことなく、リカバリし自動的に自身をリポジショニングすることができる。

ある実施形態に従うと、概して、変更データキャプチャシステムは以下のように動作する。

変更データキャプチャシステムは、クラスタの分散型ソーストポロジーを発見するように動作する。分散型ソース変更トレースエンティティ（たとえばコミットログ、データベーステーブル、またはメッセージキュー）の場所に関する情報、または、異なるノード上のその他のログ情報またはファイルが、取り出される。ソース変更トレースエンティティが異なる物理マシン上に存在する場合、プロセスは、ネットワーク接続を通して変更トレースエンティティを個々のノードにプルすることができる。キャプチャプロセスは、変更トレースエンティティの発生ノードを追跡する。

上記変更データキャプチャシステムは、すべてのノードからのソース変更トレースエンティティを処理し、ソース変更トレースエンティティ内の利用できるすべての記録のための重複排除キャッシュをエンリッチ（enrich）するように、動作する。

新たな記録が処理されるたびに、重複排除キャッシュは、当該記録を通すかまたはフィルタリングによって重複を排除するかを決定することができる。これは、一般的にマルチノードシステムはクラスタ内の各種ポイントまたはノードからデータの複数のコピーをプッシュするので、好都合である。

重複排除キャッシュは、トポロジー・アウェア型であり、おそらくはアライブ（alive）ノードからのデータを受け入れる知能を有し、ネットワーク故障またはマシンシャットダウンが原因で機能停止する可能性が高いノードからのデータは無視しようとする。

キャプチャプロセスは、レプリカからの欠落データ記録を自動でリプレイすることができ、たとえば、レプリケーションのために使用されるアクティブノードが機能停止したときは履歴が最大であるレプリカを選択することを含む。キャプチャプロセスはまた、異なるタイムゾーンの各種ソースノードから記録を読み出す順序をタイムスタンプすることもできる。

図１は、ある実施形態に係る、異種ターゲットに対して使用するために分散型データソースからの変更データをキャプチャするためのシステムを示す。

図１に示すように、ある実施形態に従うと、１つ以上のコンピュータリソース（たとえばＣＰＵ、メモリ）１０２を含むコンピュータまたはコンピューティング環境に提供することができる、変更データキャプチャシステム１００、たとえばOracle GoldenGate環境は、１つ以上のターゲット、たとえばデータベースまたはメッセージキューに対して使用するために分散型データソース１１０からの変更データをキャプチャするように構成することができる。

ある実施形態に従うと、変更データキャプチャシステムは、抽出コンポーネント１０４、たとえばOracle GoldenGate抽出コンポーネントを含み得る。この抽出コンポーネントは、抽出プロセッサ１１１と、アクセスモジュール１１２、たとえばOracle GoldenGateベンダアクセスモジュール（vendor access module）（ＶＡＭ）と、分散型データソースとの通信を可能にするアクセスＡＰＩ１１４と、変更データキャプチャプロセスマネージャ（ＣＤＣプロセスマネージャ）１１６とを含み得る。

ある実施形態に従うと、アクセスモジュールは、分散型データソースにおける記録にアクセスする際に使用される、アクセススレッド１２０とリーダースレッド１２２とを含み得る。

ある実施形態に従うと、そのＣＤＣプロセスマネージャを含む抽出コンポーネントは、以下でさらに詳細に説明する、キャプチャプロセス１１７、重複排除プロセス１１８、およびリカバリプロセス１１９のうちの１つ以上を実行することができる。

ある実施形態に従うと、分散型データソースシステム、たとえば分散型データベース、分散型データストリーム、またはその他の分散型データソースは、複数のノード、たとえばノード１５０を含み得る。分散型データソースにおいて、データ書込経路１６０は、データがメモリ１６２からソース変更トレースエンティティ１７４（たとえばCassandra環境内のコミットログ）の形態でディスクに書き込まれる経路と、その後格納表現１８２としてディスクにフラッシュ１８０されるメモリ表現１６４（たとえばCassandra環境内のメモリテーブル）に書き込まれる経路とを含み得る。

たとえば、Cassandra環境において、データ書込は最初にノードのコミットログに書き込まれ、その後メモリテーブルに書き込まれる。メモリテーブルが満杯の場合は、格納された文字列テーブルとしてディスクに書き込まれる。書込は、メモリテーブルに、満杯になるまでひとまとめにされ、満杯になるとフラッシュされる。これにより、コミットログの付加を用いて書込を実行できる。フラッシュされると、格納された文字列テーブルファイルは変更できない。

ある実施形態に従うと、変更データキャプチャシステムは、分散型データソースシステムに対応付けられた分散型ソーストポロジーの自動発見を実行し、分散型データソースシステムのノードにおける、ソース変更トレースエンティティ、たとえばコミットログに対するアクセス２０２を提供する。

ある実施形態に従うと、キャプチャプロセスは、分散型データソースから読み出した変更データを、１つ以上のターゲットによる消費のために、カノニカルフォーマット出力２０５に変換する。

ある実施形態に従うと、出力として与えられた変更データ２０６は、任意で、たとえば、Oracle Goldengateトレイル情報として提供する、またはOracle Goldengateトレイル情報を含むことができる。

ある実施形態に従うと、上記１つ以上のターゲットは、ここではターゲットシステムＡ２１２およびターゲットシステムＢ２１４として示されている、異種ターゲット２１０であってもよく、その例は、データベース、メッセージキュー、またはその他のターゲットのうちの１つ以上を含み得る。

ある実施形態に従うと、重複排除プロセスは、分散型データソースから提供されたデータの自動重複排除を提供する。加えて、変更データキャプチャシステムは、分散型ソースシステムに対応付けられた分散型ソーストポロジーの自動発見を実行することができ、ノードが使用できなくなると、記録を取得する場所であるレプリカノードを選択するリカバリプロセスを実行する。

ある実施形態に従うと、アクセスモジュール、たとえばOracle GoldenGateベンダアクセスモジュール（ＶＡＭ）は、ソース変更トレースエンティティに対応付けられたイベントを処理するために使用できる複数のイベントクラスと、ソース変更トレースエンティティに対応付けられた記録を読み出して処理するために使用できるリーダーまたはプロセッサクラスとを含み得る。

ある実施形態に従うと、ＣＤＣプロセスマネージャは、位置ストレージ１４２と、重複排除キャッシュ１４４と、履歴キュー１４６とを含み得る、またはこれらとやり取りすることができる。

ある実施形態に従うと、位置ストレージは、１つ以上のノードのグローバルリカバリポジショニング情報を含み得るチェックポイント完了イベントを受けたときにチェックポイント情報を保存することを可能にし、また、シーケンス識別子（ＩＤ）が使用される環境では、最後に使用されたシーケンスＩＤを保存することを可能にする。

ある実施形態に従うと、重複排除キャッシュは、ソースシステムからの抽出記録から固有のトークン（たとえばCassandra環境におけるパーティショントークン）が検出されると常に構築される。これは、トークンとソースノードアドレスとを結び付ける。ソースノードがシャットダウン／クラッシュした場合、重複排除キャッシュは、更新されて、当該ソースノードに対応付けられたすべてのトークンを取り除く。これにより、プロセスは、別のアライブソースレプリカノードからの同じトークンを有する記録を受け入れることができる。このような記録を処理すると、重複排除キャッシュは再びエンリッチされる。

ある実施形態に従うと、新たなソースノードが分散型データソースに追加された場合、データ記録が再分配されてデータが均等に分散される可能性がある。そうなると、データの特定のパーティションがさまざまなノードにわたって移動する場合がある。重複排除キャッシュはリフレッシュする必要があり、有効なノードの一部ではないトークンはいずれもパージされる。これにより、プロセスは、新たなソースレプリカノードからパージされたトークンの記録を受け入れることができる。このような記録が処理されると、重複排除キャッシュは再びエンリッチされる。

ある実施形態に従うと、重複排除キャッシュは、修正されるたびに、永続性ストレージにコミットされる。キャプチャプロセスは、クラッシュまたはシャットダウン後にリスタートする場合であっても、永続化された重複排除キャッシュに対して常にアクセスできる。

ある実施形態に従うと、履歴キューは、１つ以上のソースノードから読み出された最後の記録のセットを含み得る。

図２は、ある実施形態に従う、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。

図２に示すように、ある実施形態に従うと、分散型データソースシステム、たとえば分散型データベース、分散型データストリーム、またはその他の分散型データソースシステムは、この例では、それぞれが自身のソース変更トレースエンティティ２１９および２２１に対応付けられているノードＡ ２１８およびノードＢ ２２０を含む、分散型ソーストポロジー２１６内に配置された複数のノードを含み得る。変更データキャプチャシステムは、分散型データソースシステムに対応付けられた分散型ソーストポロジーの自動発見を実行することができ、分散型データソースシステムのノードのソース変更トレースエンティティに対するアクセスを提供する。

図３は、ある実施形態に従う、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。

図３に示すように、ある実施形態に従うと、変更データ内の重複記録２２２が検出されると、重複排除プロセスは、分散型データソースが提供するデータの自動重複排除２２４を提供することができる。

図４は、ある実施形態に従う、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。

図４に示すように、ある実施形態に従うと、変更データキャプチャシステムは、分散型データソースシステムに対応付けられた分散型ソーストポロジーの自動発見２２６を実行することができ、これはたとえば、この例ではノードＮ ２２８である新たなノードの存在を、分散型ソーストポロジー内のそのソース変更トレースエンティティ２２９とともに、判断することを含む。

図５は、ある実施形態に従う分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。

図５に示すように、ある実施形態に従うと、変更データキャプチャシステムは同様に、たとえばこの例ではノードＢであるノードが使用不可２３０になったか否かを判断し、グローバルリカバリポジショニング情報２３２を用いてこの使用不可に応じることができる。

図６は、ある実施形態に従う、分散型データソースからの変更データをキャプチャするためのシステムをさらに示す。

図６に示すように、ある実施形態に従うと、ノードが使用不可になると、変更データキャプチャシステムは、リカバリ位置情報を用いるリカバリプロセスを実行して、記録を取得する場所である、この例ではノードＮであるレプリカノードをリポジショニングするかそうでなければ選択２３４することができる。

図７は、ある実施形態に従う、分散型データソースからの変更データをキャプチャするための方法のフローチャートを示す。

図７に示すように、ある実施形態に従うと、ステップ２６１で、分散型ソーストポロジーに対応付けられた複数のノードを含む分散型データソースシステムにアクセスが提供され、各ノードは自身のソース変更トレースエンティティに対応付けられる。

ステップ２６２で、分散型ソーストポロジーの自動発見が実行され、分散型データソースからの変更データのキャプチャにおいてキャプチャプロセスが使用する、１つ以上のノードのソース変更トレースエンティティにアクセスが提供される。

ステップ２６３で、分散型データソースに対応付けられた変更データにおいて１つ以上の重複記録を検出した場合、重複排除プロセスが、重複記録の自動重複排除を実行する。

ステップ２６４で、分散型データソースに対応付けられた分散型ソーストポロジーの自動発見を引続き実行する間に、１つ以上の新ノードの存在および／または１つ以上のノードの使用不可について、判断することができる。

ステップ２６５で、あるソースノードが使用不可であると判断された場合、リカバリプロセスが、分散型データソースにおけるレプリカノードを選択し、そこから変更データ記録を取得またはリプレイする。

ステップ２６６で、分散型データソースから読み出された、キャプチャされた変更データが、１つ以上のターゲットシステムに伝達するためおよび／または１つ以上のターゲットシステムによる消費のために、カノニカルフォーマット出力に変換される。

また、各種実施形態に従う上記ステップを説明する追加の記載を以下に示す。

分散型ソーストポロジーの自動発見およびキャプチャコンポーネント
分散型データソースシステムは、スケーラブルなので、変更データを探すための多数のキャプチャコンポーネントを含み得る。ある実施形態に従うと、システムは、実行時に異なるエンドポイントが動的に変化し得るように、いつ新たなコンポーネントが追加されたか、またはコンポーネントが削除されたかを含む、分散型システム内の分散型ソーストポロジー変更に、変更データキャプチャプロセスが対応できるよう、変更データのエンドポイント（たとえば、クラスタ内の各種ノード上のコミットログ、またはターゲットノード上のテーブル、または変更データのその他のソース）を自動的に発見することができる。

たとえば、Cassandraを使用するある実施形態に従うと、バイナリファイルとともに出荷されるＪＡＲは、Cassandraクラスタ（リング）に関する情報を取り出すために使用できるNodeProbeクラスを提供する。NodeProbeインスタンスは、クラスタ内の任意のノードとの接続を確立することができ、あるノードへの１つの接続により、クラスタ全体に関する必要情報すべてに対するアクセスが可能になる。

ある実施形態に従うと、ＣＤＣプロセスマネージャは、変更／イベントを、たとえば、ノードのデコミッション、ノードのシャットダウン、新たなノードの追加、ノードの出現（立ち上がり）、キースペースの追加／削除／修正、またはテーブルの追加／削除／修正などを、登録しリッスンすることができる。

ある実施形態に従うと、ノードがシャットダウンまたはクラスタ／リングからデコミッションされると、ＣＤＣプロセスマネージャは、以下のアクション、すなわち、重複排除キャッシュをクリアすることにより、このノードに対応付けられたすべてのトークンを削除すること、ダウンしたノードから読み出された最後の記録を発見すること、レプリカ記録のいずれかにある一致する記録を発見すること、最大の記録履歴を有するレプリカノードからの記録をリプレイすること、重複排除キャッシュを更新することにより、最後の記録のトークンを新たなレプリカノードにリンクさせること、および、ダウンしたノードに対する通信を閉じること、を実行できる。

重複排除プロセスおよび複数のレプリカからのデータのフィルタリング
分散型システムは、一般的にデータ冗長性を含み、そのため可用度が高い。ある実施形態に従うと、このようなシステムからの変更データキャプチャプロセスは、重複記録をフィルタリングによって取り除くことができ、必要であればタイムスタンプフィルタを適用することもできる。

ある実施形態に従うと、重複排除プロセスは、分散型システムの分散型ソーストポロジーの変更に対応することもできる。たとえば、変更キャプチャプロセスは、データ記録をフェッチするために使用されたアクティブコンポーネント／ノードがダウンしたときに、レプリカノード／コンポーネントから記録を読み出すことができる。重複排除中に、変更データキャプチャプロセスは、最初にデータ記録を供給するノードからデータ記録を選択する。このようにして、キャプチャプロセスは、低レイテンシでデータ記録をノードから読み出すことができる。

図８は、ある実施形態に係る、分散型データソースからの変更データのキャプチャに対して使用される、重複排除プロセスのフローチャートを示す。

図８に示すように、ある実施形態に従うと、ステップ２７１で、ソースノードから記録が読み出される。

ステップ２７２で、ソースノードから分散機構（たとえばCassandra環境におけるパーティショナー）を読み出す。

ステップ２７３で、決定した分散機構を用いて記録からトークン（たとえばCassandra環境におけるパーティショントークン）を生成する。

ステップ２７４で、重複排除キャッシュからトークンを判断する。
ステップ２７５で、重複排除キャッシュ内にトークンがある場合、このトークンに対応付けられたノードを重複排除キャッシュからフェッチする。

ステップ２７６で、重複排除キャッシュ内のノードがソースノードと一致する場合、記録をキャプチャプロセスに送る。

ステップ２７７で、重複排除キャッシュ内のノードがソースノードと一致しない場合、対応する記録は他のノードからの重複記録であり、この記録をフィルタリングによって取り除きキャプチャプロセスには送らない。

ステップ２７８で、重複排除キャッシュ内にトークンがない場合、ソースノードおよびトークンを重複排除キャッシュに挿入し、記録をキャプチャプロセスに送ってカノニカルフォーマット出力を生成する。

図９は、ある実施形態に係る、重複排除プロセスを含む、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。

図９に示すように、ある実施形態に従うと、示されている重複排除プロセス２８０～３０２は、ソースノードから記録を読み出し、ソースノードから分散機構を読み出し、分散メカニズムを用いて記録からトークンを生成し、重複排除キャッシュからのトークンをルックアップすることができる。

ある実施形態に従うと、重複排除キャッシュ内にトークンがある場合、プロセスは、このトークンに対応付けられたノードを重複排除キャッシュからフェッチする。

ある実施形態に従うと、重複排除キャッシュ内のノードがソースノードと一致する場合、プロセスは記録をキャプチャプロセスに渡す。

ある実施形態に従うと、重複排除キャッシュ内のノードがソースノードと一致しない場合、対応する記録は他のノードからの重複記録である。この記録はフィルタリングによって取り除かれ、キャプチャプロセスには渡されない。

ある実施形態に従うと、重複排除キャッシュ内にトークンがない場合、プロセスは、ソースノードおよびトークンを重複排除キャッシュに挿入し、記録をキャプチャプロセスに渡してカノニカルフォーマット出力を生成する。

たとえば、Cassandra環境に対して使用される実施形態に従うと、以下のステップを実行することができる。テーブルのいずれかの行がコミットログから読み出されると、ＣＤＣプロセスマネージャは、パーティションキーに基づいてこの特定の行のパーティショントークンを生成し、また、この行の起点のノードアドレスをキャッシュする。パーティショントークンを生成するために使用されるパーティショナーは、ライブノードから動的にフェッチされる。分散型ソース内のすべての記録は、あるノード内のあるパーティション（またはアドレス範囲または一般的なストレージ範囲）内に位置付けられる。異なるノード上には記録の２つ以上のコピーが存在し得る。パーティショントークンは、ノード内のパーティションを示すために生成される。パーティショントークンの生成は、分散型ソースシステムに対応付けられた分散機構（たとえばパーティショニング）を用いて行われる。ＣＤＣプロセスマネージャは、最初に、分散型ライブソースノードが使用するパーティショニング機構に関する情報をフェッチする。ＣＤＣプロセスマネージャは、コミットログから読み出したすべての記録からパーティショントークンを生成し、パーティショントークンおよびノードアドレスに対応付けられたキャッシュを構築する。新たな行が処理されると、ＣＤＣプロセスマネージャは、トークンの一致についてキャッシュを調べる。ＣＤＣプロセスマネージャキャッシュ内にトークンがある場合、ソース行の起点（ノード）を調べる。ソース行の起点（ノード）がキャッシュ内のノードと一致する場合、この行データはパスされる。その後、同じパーティションの新たな行はいずれもこのノードから受け入れられる。ソース行の起点（ノード）がキャッシュ内のノードと異なる場合、この行は重複でありフィルタリングによって取り除かれる。

ある実施形態に従うと、ノードはクラッシュ／シャットダウンする、または、デコミッションされる可能性がある。ノードがダウンし、ＣＤＣプロセスマネージャが、ダウンしたノードから特定のトークンのために行を読み出すプロセス中である場合、重複排除キャッシュはいくつかの無効エントリを有するであろう。このシナリオにおいて、ＣＤＣプロセスマネージャは、他のノードからの同じ行の受け入れを開始する。これは、分散型ソーストポロジーの現在の状態に基づいて重複排除キャッシュをリフレッシュすることによって実現される。

加えて、抽出コンポーネント／キャプチャプロセスが停止しリスタートした場合、重複排除キャッシュはスタートアップ時に再構築されて重複を回避する。

図１０は、ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。

図１０に示すように、ある実施形態に従うと、示されているプロセス３１０～３３４は、抽出コンポーネント／キャプチャプロセスが停止すると、キャッシュがトークンおよびノードマッピングとともに永続性ストレージにシリアライズされ、抽出コンポーネント／キャプチャプロセスがリスタートすると、デシリアライズされる。

異種ターゲットに対して使用するための変更データの作成
ある実施形態に従うと、変更キャプチャプロセスは、分散型システムから読み出したデータを、いずれかの異種ターゲットシステムが消費できるカノニカルフォーマット出力に変換することができる。新たなターゲットは、プラガブルアダプタコンポーネントを導入してカノニカル変更キャプチャデータを読み出しそれをターゲットシステムフォーマットに変換することで、サポートできる。

ある実施形態に従うと、ターゲットシステムに基づいて、カノニカルフォーマット出力データ記録を、ターゲットに合うように変換することができる。たとえば、INSERTをターゲットシステム上のUPSERTとして適用することができる。

ある実施形態に従うと、カノニカルフォーマット出力は、データがキャプチャされた分散型システム内のコンポーネント／ノードに関する情報を埋め込むこともできる。ある実施形態に従うと、たとえば、システムは、Oracle GoldenGateトレイルフォーマットをカノニカルフォーマット出力として用いることができる。

一般的に、クライアントアプリケーションが、データ冗長性を有する分散型ソースシステムからデータを読み出すとき、クライアントアプリケーションのみに、（分散型システム）上のソースノードではなくデータ記録が与えられる。データ記録は、ライブノードのうちのいずれかから、分散型ソースシステムクライアント（たとえばCassandra環境、CQLSHクライアント）がフェッチすることができる。ある実施形態に従うと、分散型キャプチャアプリケーションは、データ記録を、これもこのデータ記録を生成したソースノードに関する情報を有する、カノニカルフォーマット出力に変換する。

変更データキャプチャリカバリプロセス
ある実施形態に従うと、アクティブノードが故障すると、キャプチャプロセスは、レプリカノードの履歴キャッシュからの別のレプリカノードの記録を自動的にリプレイすることができる。これは、分散型ソーストポロジーの変更によりキャプチャプロセスがあるノードから別のノードに切り替えられるときのデータ損失の可能性を回避するのに役立つ。キャプチャプロセスは、突然クラッシュしたとしても（たとえばkill -9信号が原因で）、データ損失を伴うことなくリカバリし分散型システム内に配置することができる。

たとえば、Cassandraを使用する実施形態に従うと、記録を活発に供給していたノードが故障すると、CassandraTopologyManagerは、レプリカノードを選択し、故障したノードが処理した最後の記録をルックアップすることができる。一致する記録を有するレプリカノードが２つ以上ある場合、記録履歴が最大のレプリカを選択し、シャットダウンしたノードの最後の記録において発見されたトークンを供給する。

ある実施形態に従うと、一致する記録がレプリカのうちのいずれにも発見されなかった場合、再び、記録履歴が最大のレプリカを選択し、また、データ損失の可能性を示すために警告メッセージをログしてもよい。このシナリオにおいて、警告またはシャットダウン動作（たとえばABEND抽出動作）を制御するためにパラメータを提供してもよい。

分散型ソースシステムは、記録の読み出しを開始する固有位置を示すためのグローバル識別子を有する場合と有しない場合がある。多くの場合、分散型システムのすべてのノード／コンポーネント内の固有位置を識別することは可能である。分散型ソースシステムのすべてのノードからの固有位置を蓄積した場合、これは、分散型システム全体の固有位置を提供する。

ある実施形態に従うと、キャプチャプロセスは、分散型ソースシステムのグローバルリスタート／リカバリポジションを生成することにより、データ記録を失うことなく、リスタート、リカバリおよびリポジショニングが可能である。

分散型ソースノードは、さまざまな形態の位置情報を有し得る。キャプチャプロセスは、ソースノード位置のフォーマットに適合する固有位置を構築することができる。

ある実施形態に従うと、キャプチャプロセスは、位置ストレージに、グローバル位置を定期的にコミットする。位置ストレージは、１つ以上のノードのグローバルリカバリポジショニング情報を含みシーケンス識別子（ＩＤ）が使用される環境では最後に使用されたシーケンスＩＤを含むチェックポイント情報の保管を可能にする。永続性ストレージにデータをコミットすることは高コストの動作であり、パフォーマンスを考慮することはキャプチャプロセスにとって重要であるので、一般的にコミットは設定可能な周期、たとえばＮ秒またはＮ分で発生する。グローバルポジションが一定の間隔でコミットされるので、キャプチャプロセスがその間隔ウィンドウ内でクラッシュした場合は、コミットされたグローバル位置が最後でないというリスクがある。

これに対応するために、ある実施形態に従うと、キャプチャプロセスリカバリ機構は、このような場合であっても、カノニカル出力コンポーネントおよび位置ストレージコンポーネントからすべてのノードの位置情報を抽出しマージすることにより、データ損失および重複を伴うことなくレジリエンスを有する。ソースノードがシャットダウン／クラッシュすると、重複排除キャッシュは更新されて対応するソースノードに対応付けられたすべてのトークンを取り除く。これにより、プロセスは、別のアライブソースレプリカノードから同じトークンを有する記録を受け入れることができる。この新たなレプリカノードの選択は次の通りである。プロセスは、すべてのライブレプリカノードをルックアップする。このプロセスは、重複として先にフィルタリングにより取り除かれた記録の履歴キャッシュを保持する。このプロセスは、レプリカノード内のソースノードから与えられた最後の記録を求めて履歴キャッシュを検索し、記録が一致するレプリカノードを選択する。２つ以上のレプリカノードがある場合、プロセスは、履歴キャッシュ内の記録の数が最大であるレプリカノードを選択する。レプリカノードからの記録をリプレイすることにより、プロセスは、データ損失を伴うことなく、あるノードから別のノードへとグレースフルに切り替わることができる。

このようにして、システムは、データソースのまたはキャプチャプロセス内のエラーを処理することができ、レジリエンスを提供する。なぜなら、キャプチャプロセスに必要なのは、トレースエンティティの位置を知ることのみだからである。

上述のように、トレースエンティティの例は、たとえばCassandra環境におけるコミットログを含む。トークンを生成するために使用するパーティショナーは、読取装置によって動的に取得される。ソース内の各記録の位置は、何らかのアドレス範囲に位置付けることができる。

ある実施形態に従うと、さまざまなノード上に記録の２つ以上のコピーが存在する可能性がある。たとえば、高い可用性の必要を満たすために、３つ以上のノードで同じ記録が使用できるようにしてもよい。トークンは、たとえばノード内のパーティションを示すために生成することができる。リカバリプロセスは、分散型ソースが既に使用しているのであればどのような分散機構でも使用して、分散型ソース内に位置しようとする。たとえば、Cassandraは、Murmur3を分散機構として使用する。

抽出コンポーネントが記録を受けると、分散機構を決定することができる。分散機構により、システムは、トレース内のすべての記録についてトークンを生成し重複排除キャッシュを構築することができる。一般的に、このことは、分散型ソースシステムのトポロジーに何の変更もない（たとえばノードの追加または削除がない）とすると、あるノードのバケットからの記録はすべて、やや難しいやり方で、同じノード／バケットから読み出されるであろうことを、意味する。ある実施形態に従うと、
ノードのルックアップが成功であれば、読み出された記録が送られる。

ノードが一致しなければ、新たなノードから読み出し、重複排除プロセスに従う。
トークンが全くない場合、これは、重複排除キャッシュに追加する新たなノードである。

ある実施形態に従うと、記録そのものは、データがどのノードから来たかを示さない。しかしながら、カノニカルフォーマット出力（たとえばGoldenGate環境ではトレイルファイル）はこの情報を含む。カノニカルフォーマット出力が書き込まれると、位置ストレージを更新してデータがどのノードから来たかを示さなければならない。クラッシュがあると、抽出コンポーネントは、カノニカルフォーマット出力を見直すことにより、どのノードがどの記録に貢献するかを見出してから、各ノードの位置を見出すためにストレージに使用される。

ある実施形態に従うと、チェックポイントを、当該チェックポイントに対応付けられた情報を含み定期的に更新される、JavaScript（登録商標） Object Notation（ＪＳＯＮ）などのチェックポイントファイルに、書き込むことができる。チェックポイントイベントは、それに応じて位置ストレージを更新する。

ある実施形態に従うと、リカバリスキャン中に、抽出コンポーネントは、カノニカルフォーマット出力から与えられた情報を用いて、ノードに対応付けられた各位置を決定することにより、ノードのグローバルリカバリポジショニング情報を決定し、その後、これらの位置でリスタートすることができる。

ある実施形態に従うと、リカバリ中に、重複記録をノードから受けた場合、重複記録は、直ちに破棄されるのではなく、リカバリ中に使用するために、ある期間、履歴キューに入れられる。履歴キューに対して記録マッチングを実行することにより、そのトークンに対してどの記録を配置するかを判断することができる。

図１１は、ある実施形態に係る、分散型データソースからの変更データのキャプチャに対して使用されるリカバリプロセスのフローチャートを示す。

図１１に示すように、ある実施形態に従うと、ステップ３４１で、分散型データソースシステムの複数のノードの各々の中の固有位置を特定し、すべてのノードから固有位置を蓄積することにより、分散型データソースで使用されるグローバルリカバリポジショニング情報を提供する。

ステップ３４２で、キャプチャプロセスは、位置ストレージにグローバルリカバリポジショニング情報を定期的にコミットする。

ステッ３４３で、ソースノードがシャットダウンまたはクラッシュしたと判断すると、重複排除キャッシュを更新してそのソースノードに対応付けられたトークンをすべて削除する。

ステップ３４４で、いくつかインスタンスでは、カノニカルフォーマット出力からグローバルリカバリポジショニング情報を読み出す。

ステップ３４５で、いくつかのインスタンスでは、レプリカノード内のソースノードから与えられた最後の記録を求めて履歴キューを検索し、記録が一致するレプリカノードを選択するか、２つ以上のレプリカノードがある場合は履歴キュー内で記録の数が最大であるレプリカノードを選択し、レプリカノードから記録をリレーする。

図１２は、ある実施形態に係る、リカバリプロセス３５０～３６４を含む分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。

その他の重複排除およびリカバリの例（Cassandra）
先に述べたように、ある実施形態に従うと、システムは、分散型データソースシステムから与えられたデータの自動重複排除を提供する重複排除プロセスを実行することができる。

図１３は、別の実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。

図１３に示すように、たとえばCassandraデータベースのような別の実施形態に従うと、示されている重複排除プロセス４１２～４４４を用いて、分散型データソースから与えられたデータの自動重複排除を提供することができる。

図１４は、さらに別の実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムのフロー図を示す。

図１４に示すように、さらに別の実施形態に従うと、示されている重複排除プロセス４６２～４９４を用いて、分散型データソースから与えられたデータの自動重複排除を提供することができる。

その他の実施形態に従うと、その他の種類の分散型データソースもしくはデータベース、または重複排除プロセスをサポートすることができる。上記例は限定を意図したものではない。

リカバリのシナリオ
図１５～図１８は、ある実施形態に係る、分散型データソースからの変更データをキャプチャするためのシステムに対して使用されるリカバリのシナリオの例を示す。

下記リカバリのシナリオの例のうちのいくつかにおいては、例示のために、リカバリプロセスが、たとえばCassandra環境に対して使用し得る、シーケンスＩＤの使用を考慮する。しかしながら、このようなシーケンスＩＤの使用は任意であって、その他の種類の分散型データソースを利用してもよい。

リカバリのシナリオ１－チェックポイント更新イベント（クラッシュ／ストップなし）
図１５に示す実施形態に従うと、このリカバリシナリオにおいて、チェックポイント完了イベントを受けると、チェックポイント情報が位置ストレージにおいて更新され、トークンがカノニカルフォーマット出力にシリアライズされる。

この例において、シーケンスＩＤが４である記録をカノニカルフォーマット出力に書き込んだ後でチェックポイント完了イベントがある場合、位置ストレージ内のチェックポイント情報は、グローバルリカバリポジショニング情報Node1:Position1; Node3:Position2; Node2:Position1を有するであろう。

シーケンスＩＤを使用する環境では、最後に使用されたシーケンスＩＤ：４は、チェックポイント情報に格納することもできる。

リカバリのシナリオ２－グレースフルストップおよびリスタート
ある実施形態に従うと、前の例を用いると、代わりにストップコマンドが抽出コンポーネントに対して出された場合、最後の記録に対するチェックポイント完了イベントが処理される。

この例において、シーケンスＩＤが６である記録は、そのシーケンスＩＤの値が６に更新された位置ストレージにチェックポイント情報が書き込まれるようトリガする。チェックポイント情報は、Node1:Position3; Node3:Position2; Node2:Position1という位置で更新される。

リスタートすると、抽出コンポーネントは、チェックポイント情報内のすべての情報を有して、ノード各々に対する正確なポジショニングを実行する。

リカバリのシナリオ３－抽出クラッシュおよびリスタート
図１６に示す実施形態に従うと、このリカバリシナリオでは、チェックポイントイベントに際し、位置ストレージに書き込まれたチェックポイント情報は、シーケンスＩＤ：２、Node1:Position1; Node3:Position1を有する。

ある実施形態に従うと、抽出コンポーネントが、シーケンスＩＤ：７の記録の書込中に突然キルされた場合、カノニカルフォーマット出力に保管された最後の記録が部分記録となる。

ある実施形態に従うと、リスタート時には以下のアクションが実行される。シーケンスＩＤ：２の記録である最後のチェックポイント位置から転送されたカノニカルフォーマット出力をスキャンし、カノニカルフォーマット出力のトランザクションＩＤトークンからのノード位置を蓄積し、ノードごとに最後にわかったトランザクションＩＤトークンを格納する：Node1:Position3; Node2:Position1; Node3:Position2。

この例において、スキャン中に、カノニカルフォーマット出力からの最後に使用されたシーケンスＩＤは６である。抽出コンポーネントは、シーケンスＩＤおよびノード位置をパスするので、グローバルリカバリポジショニング情報は、シーケンスＩＤ：６；Node1:Position3; Node2:Position1; Node3:Position2であろう。

リカバリのシナリオ４－分散型ソーストポロジーの変更
図１７に示す実施形態に従うと、この例において、Node1がレプリカノードReplicaNode1に対応付けられておりチェックポイントイベントがシーケンスＩＤ：６の記録の処理後に発生した場合、抽出コンポーネントの現在の位置は、シーケンスＩＤ：６；Node1:Position3; Node2:Position1; Node3:Position2であろう。

Node1がダウン－シナリオ１
上記例を用いるある実施形態に従うと、Node1がダウンすると、抽出コンポーネントは、Node1のレプリカノードを探す。これは、ReplicaNode1を発見し、それ以降、Node1から与えられたすべてのトークンは、ReplicaNode1から与えられることになる。

ある実施形態に従うと、新たなレプリカノード（ReplicaNode1）の選択の一部として、抽出コンポーネントは、その履歴キューを、この例ではNode1:Position3であったNode1から与えられた最後の記録を求めて検索する。履歴キューにおいて発見された記録は、カノニカルフォーマット出力ファイルにリプレイされる。

この例においてReplicaNode1の履歴が以下の通りであるとする。

その場合、ある実施形態に従うと、ReplicaNode1で一致したNode1の最後の記録が第３の記録であれば、システムは、ReplicaNode1:Position4およびReplicaNode1:Position5という位置で記録をリプレイする。ReplicaNode1:Position5の処理後にチェックポイント完了イベントがあった場合、ポジショニング情報は、シーケンスＩＤ：８; Node1:Position3; Node2:Position1; Node3:Position2; ReplicaNode1:Position5であろう。

このようにして、抽出コンポーネントは、データの重複なしで、分散型ソーストポロジーの変更に反応することができる。グレースフルストップおよびリスタート時に、新たな記録が、ReplicaNode1、Node2およびNode3から読み出される。Node1からの記録はいずれも（Node1がブートされても）フィルタリングにより取り除かれる。

Node1がダウン－シナリオ２
ある実施形態に従い、上記例を用いるが、代わりに抽出コンポーネントがReplicaNode1からの記録をチェックポイントできるようになる前にクラッシュすると想定する。

この例において、先に述べたのと同じ記録がReplicaNode1から抽出コンポーネントに送られ、抽出コンポーネントはクラッシュしており、カノニカルフォーマット出力は、チェックポイントされなかった記録ReplicaNode1:Position4およびReplicaNode1:Position5を有する。

ある実施形態に従うと、リスタート時に、グローバルリカバリポジショニング情報は、シーケンスＩＤ：８；Node1:Position3; Node2:Position1; Node3:Position2; ReplicaNode1:Position5である。これは、Node1がダウンした場合、記録はReplicaNode1から与えられ、ReplicaNode1の位置を有するので、データの重複はないことを、意味する。

リスタートし、Node1およびReplicaNode1双方がアップした場合、Node1が引続き、ReplicaNode1：Position5という位置の後の記録を提供し、データの重複はない。

リスタートし、ReplicaNode1がダウンしNode1がアップした場合、Node1は、自身をNode1:Position3に配置することによって抽出コンポーネントへの記録の提供を開始する。これは、先にReplicaNode1:Position5（シーケンスＩＤ：７およびＩＤ：８）から読み出された記録が、カノニカルフォーマット出力において重複記録のまま残ることを、意味する。

Node1がダウン－シナリオ３
ある実施形態に従い、上記例を用いるが、代わりに記録がカノニカルフォーマット出力に書き込まれる前に抽出コンポーネントがクラッシュしたと想定する。

ある実施形態に従い、リスタートすると、抽出ポジショニングは、シーケンスＩＤ：８；Node1:Position3; Node2:Position1; Node3:Position2であろう。

リスタートし、Node1がアップした場合、データの重複はない。
リスタートし、Node1がまだダウンしている場合、抽出コンポーネントは、ReplicaNode1からの読み出しを開始し、これにより、記録の重複が、前のNode1がこれらの記録を提供していた場合、発生し得る。

Node1がダウン－シナリオ４
図１８に示す実施形態に従うと、この例においてReplicaNode1は履歴記録を十分有していない。たとえば、ReplicaNode1の履歴キューにおける記録は、ReplicaNode1:Position6; ReplicaNode1:Position7; ReplicaNode1:Position8; ReplicaNode1:Position9である。

ここでは、ReplicaNode1の履歴キューの深さが十分ではないので、データ損失の可能性がある。デフォルトで、抽出コンポーネントはこのシナリオにおいてABENDし、この状況について顧客に警告する。これに代えて、アドミニストレータがABEND特徴をオフし抽出をリスタートすることを選択してもよい。

ある実施形態に従うと、リスタート時において、ポジショニングは、シーケンスＩＤ:６；Node1:Position3; Node2:Position1; Node3:Position2であろう。Node1がなおもダウンしている場合、その最初に使用できるソース変更トレースエンティティから始まるReplicaNode1から、データをソースする。これは記録の重複につながる可能性がある。Node1がアップした場合、データの重複はない。

Node1がダウン－シナリオ５
ある実施形態に従うと、このリカバリシナリオにおいて、抽出コンポーネントはいくつかの記録を処理しており、グローバルリカバリポジショニング情報は、シーケンスＩＤ：６；Node1:Position3; Node2:Position1; Node3:Position2であろう。

ある実施形態に従うと、リスタート時に、Node1がダウンしている場合、抽出コンポーネントは、ReplicaNode1であるNode1のレプリカノードからの記録の読み出しを開始する。ReplicaNode1に関する位置情報は利用できないので、ReplicaNode1からの利用できる記録すべてを読み出す。これは、カノニカルフォーマット出力ファイルにおける記録の重複につながる可能性がある。

実装例（Cassandra）
以下のセクションは、たとえばCassandraデータベースのような分散型データソースシステムからの変更データをキャプチャする実施形態の例の説明を提供する。

その他の実施形態に従うと、その他の種類の分散型データソースまたはデータベースをサポートすることができる。説明のために、以下では各種実施形態が理解されるようさまざまな詳細を提供する。しかしながら、実施形態は特定の詳細がなくても実施することができる。以下の説明は限定を意図したものではない。

Cassandraは、大規模にスケーラブルなオープンソースのＮｏＳＱＬデータベースであり、これは、単一障害点なしで、多数のコモディティサーバーにわたる、連続可用性、リニアスケーラビリティ、および、運用の簡易性を提供する。Cassandraシステムは、データがクラスタ（リング）内のすべてのノード間で分配される、異種ノードにまたがるピアツーピア分散システムを用いることにより、障害の問題に対処する。

各種実施形態に従うと、システムは、以下の特徴のうちのいくつかまたはすべてを、含むまたは利用することができる。

ノード：データを格納するハードウェアであり、クラスタのメンバである。
データセンター：関連するノードの集まり。別々のデータセンターを用いることで、トランザクションが他のワークロードの影響を受けることを防止し、レイテンシが低くなるように要求を互いに近くに置いておく。データセンターは一般的に物理的な場所を占有しない。

クラスタ：クラスタは、１つ以上のデータセンターを含み、物理的な場所を占有できる。

コミットログ（CommitLog）：すべてのデータは永続性のために先ずコミットログに書き込まれる（ロギング先行書込（write-ahead logging））。そのすべてのデータがSSTableにフラッシュされると、コミットログは、アーカイブ、削除、またはリサイクルすることができる。ＣＤＣ特徴が可能にされた場合、アーカイブされた（ＣＤＣ）コミットログは、予め構成されたＣＤＣディレクトリ（デフォルト値：$CASSANDRA_HOME/data/cdc_raw）内にあり、アクティブコミットログは、予め構成されたアクティブログディレクトリ（デフォルト値：$CASSANDRA_HOME/data/commitlog）内にある。すべてのノードには自身のコミットログのコピーがある。

SSTable：ソート済み文字列テーブル（sorted string table）（SSTable）は、システムがmemtableを定期的に書き込む不変データファイルである。

MemTable：memtableは、ディスク（SSTable）にまだフラッシュされていないメモリ内にあるキャッシュである。

ゴシップ：リング内の他のノードに関する位置および状態情報を発見し共有するためのピアツーピア通信プロトコル。

パーティショナー：パーティショナーは、どのノードがデータの最初のレプリカを受けるか、および、クラスタ内の他のレプリカノードにデータをいかにして分散させるかを決定する。パーティショナーは、ある行のプライマリキーからパーティショントークンを取り出すハッシュ関数である。Murmur3Partitionerは、Cassandraの最新バージョンのデフォルトパーティショナーである。

レプリケーション係数（replication factor）：クラスタ全体にわたって格納されるべきデータのレプリカの総数。

レプリカ配置ストラテジ（replica placement strategy）：Cassandraは、データのコピー（レプリカ）を複数のノードに格納することにより、信頼性およびフォールト耐性を保証する。レプリケーションストラテジは、どのノードにレプリカを配置するかを決定する。

キースペース：キースペース（keyspace）は、ＲＤＢＭＳワールドにおけるスキーマと同様であり、アプリケーションデータのためのコンテナとして機能する。キースペースを画定するときは、たとえば以下のようにレプリケーションストラテジおよびレプリケーション係数を指定しなければならない。

スニッチ：スニッチは、マシンのグループを、レプリケーションストラテジがレプリカを配置するために使用するデータセンターおよびラックに定める。

プライマリキー（primary key）：テーブルのプライマリキーは、パーティションキーカラム（partition key column）と任意のクラスタ化キーカラム（clustering key column）とで構成される。パーティションキーカラムおよびクラスタ化カラムは、特定の行をその他のデューティに加えて特定する役割を有する場合がある。パーティションキーカラムは、行を配置すべきノードを特定する役割を有する。パーティショナーは、テーブル内のパーティションキーカラムに基づいてパーティショントークン（ハッシュ値）を生成するために使用される。このパーティショントークンは、クラスタ内の特定のノード（１または複数）にマッピングされる。クラスタ化キーカラムは、たとえば以下のように、ノード内のデータのソート順を定めるために使用される。

ある実施形態に従うと、ＣＤＣ特徴は、ＣＤＣの特定のテーブルにタグ付けするメカニズムを提供する（アーカイブ／リカバリ／バックアップ）。この特徴は、（テーブルを作成するときに、または、それを変更することにより）テーブル上で、テーブルプロパティcdc=trueを設定することにより、有効にする（enabled）ことができる。加えて、ＣＤＣ特徴は、ノードごとに、プロパティcdc_enabled: trueを、対応するノード構成ファイルであるcassandra.yamlにおいて設定することにより、有効にしなければならない。Cassandraは、ロギング先行書込を用いることでリカバリを確実にする。データベースに対するどの変更も、先ずコミットログに書き込まれる。データベース変更のコピーも、memtableとしてインメモリに保持される。データベース変更は、最終的に、memtableからSSTableにフラッシュされる。SSTableは、永続性データベースストレージであるディスク上のファイルである。

ある実施形態に従うと、Cassandraは、アクティブコミットログディレクトリの下でコミットログセグメントとしてコミットログにグループ分けされたデータベース変更を書き込む。CassandraがmemtableをSSTable（ディスク）にフラッシュした後に、ＣＤＣ特徴が、コンテキストにおいてノードおよびテーブル上で有効にされると、アクティブコミットログ内のコミットログセグメントは、ＣＤＣコミットログディレクトリに書き込まれる（アーカイブされる）。コミットログセグメントをＣＤＣコミットログディレクトリおよびアクティブログディレクトリから読み出すことにより、データベース変更の完全な履歴が得られる。ＣＤＣは、たとえば以下のようにｃｄｃテーブルプロパティを用いて有効または無効にすることができる。

ＣＤＣのcassandra.yamlでは以下のパラメータを利用できる。
cdc_enabled（デフォルト：false)：ノード全体にわたるＣＤＣ動作を有効または無効にする。

cdc_raw_directory（デフォルト：$CASSANDRA_HOME/data/cdc_raw)：対応するすべてのmemtableがフラッシュされた後にCommitLogSegmentsを移動させる宛先。

cdc_free_space_in_mb：（デフォルト：最小４０９６、ボリューム空間の８分の１）：cdc_raw_directoryにおけるＣＤＣ＋フラッシュされたすべてのＣＤＣセグメントを許可するアクティブなすべてのCommitLogSegmentsの和として計算される。

cdc_free_space_check_interval_ms（デフォルト：２５０）：キャパシティの場合、cdc_raw_directoryが占有する空間を限定することにより不必要にＣＰＵサイクルを壊すことを防止する頻度。デフォルトは毎秒４回のチェック。

Cassandraは、データを書込経路上において数段階で処理する。先ず書込を即時ロギングし、コミットログにデータをロギングし、memTableにデータを書き込み、memTableからデータをフラッシュし、ディスク上のSSTableにデータを格納する。

アクティブコミットログのデータは、memtable内の対応するデータがSSTableにフラッシュされた後に、パージされる。どのデータベース動作も先ずアクティブコミットログに書き込まれ続いてmemtableにコピーされる。アクティブコミットログのデータは、memtableがそれをSSTableにフラッシュするまで持続される。memtableのフラッシュは以下のシナリオで発生し得る。

パラメータmemtable_heap_space_in_mb（典型的にはヒープサイズの４分の１）、memtable_offheap_space_in_mb（典型的にはヒープサイズの４分の１）、およびmemtable_cleanup_thresholdが、memtableのフラッシュ頻度を決定する。

memtable_heap_space_in_mb：memtableに割り当てられたオンヒープメモリの量。
memtable_offheap_space_in_mb：memtableに割り当てられるオフヒープメモリの総量を設定。

memtable_cleanup_threshold：デフォルトは、1 / (memtable_flush_writers + 1)。
ある実施形態に従うと、Cassandraは、memtable_heap_space_in_mbを、memtable_offheap_space_in_mbに加算し、合計をmemtable_cleanup_thresholdで乗算することにより、ＭＢにおける空間量を得る。フラッシュしていないすべてのmemtableが使用するメモリの総量がこの量を超えると、Cassandraは最大のmemtableをディスクにフラッシュする。

memtable_cleanup_thresholdの値が大きいことは、フラッシュが大きく、フラッシュの頻度が低く、場合によってはコンパクションアクティビティが少ないが、同時フラッシュアクティビティも少ないことを意味し、これは、書込負荷が重いときにディスクを飽和させ続けるのを難しくする可能性がある。

パラメータcommitlog_segment_size_in_mb（デフォルト値３２）は、個々のコミットログセグメント（ディスク上のコミットログ）のサイズを決定する。コミットログセグメントは、そのデータすべてがSSTableにフラッシュされた後に、アーカイブ（ＣＤＣディレクトリに移動）、削除、またはリサイクルすることができる。このデータは、場合によっては、システム内のすべてのテーブルからのコミットログセグメントを含み得る。コミットログの総空間が小さい場合、アクティブ度が低いテーブル上でより多くのフラッシュアクティビティを生じさせる傾向がある。

Cassandraは、コミットログ空間しきい値を超えると、ディスクにmemtableをフラッシュし、SSTableを作成する。データベースがリスタートされると、アクティブコミットログはアーカイブされる（ＣＤＣディレクトリに移動）。ノードツールフラッシュコマンドを用いることにより、SSTableにmemtableを手作業でフラッシュし、ＣＤＣディレクトリにおけるコミットログの可用性をトリガする。

ＣＤＣデータが利用できるようになるときのレイテンシは周知の制限であり、その原因は、cdc_rawにおいてデータを利用できるようにするために廃棄されるコミットログセグメントへの依存にある。低速で書き込まれたテーブルが、コミットログセグメントをＣＤＣデータと共存させる場合、コミットログセグメントは、システムが、memtableに対するメモリ圧力またはコミットログ制限圧力を受けるまで、フラッシュされない。その結果、有効なコミットログセグメントをコンシューマがパースしなければ、ＣＤＣ消費用にデータが利用できるようになったときに、非決定論的要素が残る。

ある実施形態に従うと、この制限に対処し半リアルタイムのＣＤＣ消費をエンドユーザにとってより都合の良いものにするために、システムは以下をサポートする。

コンシューマが、フラッシュ／廃棄およびファイル移動を待つ代わりに、cdc_rawにおけるアクティブなコミットログセグメントのハードリンクをパースする。

Cassandraが、cdc_rawにおけるコミットログセグメントごとに別々のインデックス（idx）ファイルに最も良く見るＣＤＣミューテーション（Mutation）のオフセットを格納する。クライアントは、このインデックスファイルをテーリング（tail）し、変更に対する最後にパースされたローカルオフセットのデルタを求め（delta）、最後にパースされたオフセットを最小として用いて対応するコミットログセグメントをパースする。

Cassandraは、インデックスファイルがフラッシュされてクライアントが自身でクリーンアップできることを知ると、そのインデックスファイルに対し、オフセットおよびDONEを用いてフラグを立てる。

Cassandraデータベース変更のキャプチャ
ある実施形態に従うと、ＣＤＣ特徴は、データベース変更が（ＲＡＭに格納された）Memtableからフラッシュされたときに、コミットログセグメントをＣＤＣディレクトリにアーカイブするメカニズムを提供する。テーブルデータは、バイナリフォーマットになるようシリアライズされコミットログに書き込まれたコミットログセグメントとしてグループ分けされる。

データベース自体の一部としてパッケージ化されたCassandra JAR（Java（登録商標） Archive）は、コミットログセグメントをデコードするために実現できるインターフェイスCommitLogReadHandlerを提供する。ある実施形態に従うと、システムは、インターフェイスCommitLogReadHandlerの実現を収容することができる。

ある実施形態に従うと、この手法の利点は、データベース変更に関するコミットログの読み出しが高速であることを含む。キャプチャプロセス（抽出コンポーネント）は、Cassandraデータベースサーバに対する負荷がまさしく最小の状態で、ＣＤＣディレクトリまたはアーカイブログディレクトリ内のコミットログを読み出してデータベース変更をキャプチャすることができ、これは非イントルーシブなキャプチャである。キャプチャプロセスは、コミットログを読み出すときに特定のテーブルデータをフィルタリングによって取り除く。これはまた、全体のキャプチャ性能を改善する。

ある実施形態に従うと、キャプチャプロセスを、アーカイブされた（ＣＤＣ）コミットログおよびアクティブなコミットログからデータベース変更を読み出すように構成することができる。アクティブなコミットログを読み出すことにより、キャプチャのレイテンシは非常に低くなる。キャプチャプロセスは、コミットログ内の有効なオフセットに対して停止およびリスタートすることができる。キャプチャプロセスは、コミットログ内のタイムスタンプまたは特定のコミットログセグメントオフセットに基づいて位置付けることができる。ＣＤＣディレクトリ内のコミットログは決してパージされない。キャプチャプロセスが必要なハウスキーピングを実行するようにするのは、ＣＤＣコンシューマの役割である。これは、キャプチャプロセスは延長ダウンタイム後にリスタートすることができそれでもなおデータベース変更をキャプチャできることを意味する。

この手法に関するいくつかの考察は、コミットログ読み出しセグメントがINSERTまたはUPDATEソース動作をタグ付けしないことを含む。これは、キャプチャプロセスが、すべてのソースUPDATE動作をINSERT（または、以下で説明するUPSERT）としてトレイル（trail）に書き込む必要があることを、意味する。コミットログセグメントは、TRUNCATE動作を格納しない。コミットログセグメントは、変更された行のイメージの前に格納しない。コミットログセグメントは、ミューテーションオブジェクトとしてシリアライズされたデータを収容する。Cassandraの将来のバージョンがミューテーションオブジェクトフォーマットまたはＡＰＩを修正する場合は、キャプチャプロセスもそれに応じて修正することができる。

各ノードにおける入力クエリ（ＣＱＬ）のインターセプト
ある実施形態に従うと、インストール時にパックされるCassandra JARは、入力ユーザクエリをインターセプトするように実現できるインターフェイスであるQueryHandlerを提供する。ユーザからの入力クエリは、ＳＱＬと同様のCassandraクエリ言語（Cassandra Query Language）（ＣＱＬ）である。

ある実施形態に従うと、この手法の利点は、すべての入力クエリ（ＣＱＬ）にアクセスできる点である。システムは、UPDATEおよびTRUNCATE動作の認識も可能でなければならない。Cassandraログセグメントに対するいかなる変更も、入力されたＣＱＬシンタックスが変わらなければ、キャプチャプロセスの機能を破壊することはない。

この手法に関するいくつかの考察は、QueryHandlerが、Cassandraデータベースプロセスの入力クエリ処理のための追加レイヤであることを含む。QueryHandlerにおける欠陥は、データベースプロセスのクラッシュまたはデータ破壊につながる可能性がある。QueryHandlerは、クラスタ内のすべてのノードにインストールする必要があるイントルーシブな（intrusive）ソリューションである。QueryHandlerにおけるレイテンシは、Cassandraデータベース入力クエリ処理エンジンにパスされ、最終的にはエンドユーザに伝えられる。入力されたＣＱＬは、（コミットログ内の）コミットログセグメントはこのコンテキストでは利用できないので、位置情報を有しない。キャプチャプロセスは、抽出ポジショニング機能を複雑にするかまたは先送りする可能性がある疑似ポジションを構築することができる。キャプチャプロセスがダウンしリスタートされた場合、ダウンタイム中のデータベース変更は読み出すことができない。

ある実施形態に従うと、UPDATE動作をINSERTとしてデリバリーすることができ、デリバリー（レプリケーション）は、[UPDATEINSERTS + INSERTMISSINGUPDATES]を使用することができる。システムは、新たなデータベースタイプ名を「CASSANDRA」としてトレイルに書き込み、これは、このトレイルにおけるINSERT動作がUPSERT動作であることを示す。

コミットログへのアクセス
ある実施形態に従うと、Cassandraクラスタは典型的に、１つのデータベースインスタンスとしてともに機能する１つ以上のノード（サーバ）を含む。コミットログは、クラスタ上の各ノード上に存在する。ある実施形態に従うと、コミットログへのアクセスのオプションは、たとえば以下を含む。

ローカルファイルシステムによるアクセス
ある実施形態に従うと、コミットログは、抽出コンポーネントが実行されているマシンにアクセスする。この構成はネットワークコストを伴わない。

ＮＦＳ（ネットワークファイルシステム）プロトコルによるリモートコミットログへのアクセス
ある実施形態に従うと、コミットログは、抽出コンポーネントが実行されているマシンに搭載されたＮＦＳを通して利用可能にされる必要がある。この構成は、コミットログの読み出しのためのネットワーク帯域幅を要しない。

ＳＦＴＰを介したリモートコミットログへのアクセス
ある実施形態に従うと、必要なコミットログはリモートノードから、抽出コンポーネントが実行されているマシンに、セキュア・ファイル・トランスファー・プロトコル（secure file transfer protocol）（ＳＦＴＰ）を用いて転送される。この構成も、ファイルの転送のためのネットワークコストを要しない。

抽出エージェントを介したリモートコミットログへのアクセス
ある実施形態に従うと、リモートプログラムは、コミットログから必要なテーブルデータをフィルタリングにより取り除くために抽出テーブルパラメータのコンテキストを有するノードの各々にインストールすることができる。フィルタリングされたこのコミットログデータは、抽出コンポーネントプロセスが実行されているマシンに、ネットワークを通して転送しなければならない。抽出コンポーネントは、すべてのノードからのリモートプログラムからデータを再度アセンブルし、必要な処理を続けることができる。

ノードの発見
ある実施形態に従うと、抽出コンポーネントによるノード発見は、たとえば以下を含み得る。

スタティック構成
ある実施形態に従うと、アドミニストレータは、クラスタ内のすべてのノードについて、以下の詳細を、すなわち、ＣＤＣコミットログディレクトリのリスト、アクティブコミットログディレクトリのリスト、およびCassandraノードアドレスのリストを、提供する必要がある。コミットログディレクトリは、ローカルディレクトリまたはＮＦＳによって搭載されたリモートディレクトリであってもよい。

ダイナミック構成
ある実施形態に従うと、ユーザ／オペレータは、クラスタ内のノードのうち１つのノードだけに関する情報を提供する。１つのノードの構成は、個々のノードアドレスを特定するためにコミットログディレクトリ経路内に（$nodeAddressのような）メタフィールドを有することができる。クラスタ内のすべてのノードを自動的に発見する。

Cassandra抽出およびＣＤＣプロセスマネージャ
ある実施形態に従うと、Cassandra ＣＤＣプロセスマネージャは、コミットログ内の生テーブルデータ（ミューテーション）を読み出し、フィルタリングし、変換するＪａｖａアプリケーションである。変換されたコミットログデータは、Ｃ＋＋ライブラリによりJava Native Interface（ＪＮＩ）を通してアクセスされる。Cassandra ＶＡＭは、抽出コンポーネントプロセスがトレイルファイルを書き込むために使用するＣ＋＋／Ｃバイナリ（共有ライブラリ）として提供することができる。

ビッグデータＶＡＭモジュール
ある実施形態に従うと、ビッグデータＶＡＭモジュールは、すべてのビッグデータソースに対して再使用されることが提案される汎用ＶＡＭモジュールである。これは非トランザクションテーブルデータを扱う。これはマルチスレッドであり、あるスレッド（ＶＡＭ ＡＰＩスレッド）はＶＡＭ ＡＰＩとやり取りし、第２のスレッド（ＪＮＩリーダースレッド）はＪＮＩを用いて対応するビッグデータソースから動作記録を読み出す。ＪＮＩリーダースレッドは、動作記録のプロデューサとして機能し、ＶＡＭ ＡＰＩスレッドは、これらの動作記録を消費する。汎用ＶＡＭモジュールはファクトリクラスを用いて、ソースデータベースに基づき、特定のＪＮＩリーダー実現をインスタンス化する。キャプチャプロセスは、クラスCassJNIReaderを用いてＪａｖａアプリケーションＣＤＣプロセスマネージャとやり取りする。

CommitLogReadHandlerインターフェイス
ある実施形態に従うと、Cassandraデータベースプロセスは、データベースに対するいかなる変更もコミットログに書き込む。CommitLogReadHandlerインターフェイスを実現することにより、ミューテーションオブジェクトの形態のデータベース変更を読み出すことができる。

コミットログからのミューテーションのデコード
ある実施形態に従うと、クラスCDCHandlerImplは、CommitLogReadHandlerインターフェイスの実現である。CDCHandlerImplには、コミットログ内に存在するコミットログ読出セグメントから構成されたミューテーションオブジェクトへのアクセスが提供される。クラスCassandraMutationProcessorは、ミューテーションオブジェクトをデコードしCassandra ＶＡＭライブラリがＪＮＩを通して簡単にアクセスできるフォーマットに変換する役割を有する。CassandraMutationProcessorはまた、クラスタが現在使用するパーティショナーからすべてのミューテーション記録のパーティショントークンを生成する。クラスタが使用するパーティショナーは、いずれかのライブノード上のNodeProbeを用いて動的に取り出される。

処理されたミューテーション
ある実施形態に従うと、コミットログセグメントからの生のミューテーション記録は、データベース動作のデコードされたフォーマットであるCassandraCDCMutationに変換される。

カラム定義（Column Definition）
ある実施形態に従うと、ミューテーションオブジェクトから抽出されたカラム定義は、CassandraColumnDefinitionクラスに格納される。このクラスはカラム属性を格納する。

カラムデータ（Column Data）
ある実施形態に従うと、クラスColumnDataは、ミューテーションオブジェクトから読み出された１つのカラムのデータをカプセル化する。

CassandraTopologyManager
ある実施形態に従うと、このクラスは、CassandraCDCProcessManagerに代わり、以下のタスクを実行する。リング内の分散ソーストポロジー変化（ノード状態変化）をリッスンする／に反応する。リング内のスキーマ変更をリッスンする／に反応する。重複排除（deduplication）キャッシュをレプリカからdedup行に維持する。履歴キャッシュからの記録をリプレイすることにより、ノード故障からリカバリする。ClusterPositionを通してポジション／チェックポイント情報を管理する。SchemaLoaderを通してキースペースおよびテーブルメタデータにアクセスする。埋め込まれたＳＦＴＰクライアントであるCassandraClusterSFTPClientにコミットログのリモートアクセスを指示する。

NodeProbe
ある実施形態に従うと、Cassandraバイナリ（インストールｔａｒ）とともに出荷されるＪＡＲは、リングに関する情報を取り出すために使用できるNodeProbeクラスを提供する。NodeProbeインスタンスは、クラスタ内のいずれかのノードとの接続を確立することができる。あるノードへの１つの接続は、クラスタに関する必要な情報すべてにアクセスするのに十分である。

パーティショナーおよびパーティショントークン
ある実施形態に従うと、NodeProbeは、ライブノードが使用するパーティショナーを取り出すために使用される。クラスタ内のすべてのノードに、パーティショントークン（ハッシュ値）の範囲が割り当てられる。キースペースのレプリケーション係数が１よりも大きい場合、パーティショントークンの値は、クラスタ内の２つ以上のノードを示し得る。パーティショナーは、特定のハッシングアルゴリズムを用いてパーティショントークン値を生成する。Cassandraの最近のバージョンは、Murmur3パーティショナーを用いてパーティショントークンを生成する。

レプリカからの行データの重複排除
ある実施形態に従うと、１よりも大きいレプリケーション係数を有するキースペース内にあるソーステーブル上でキャプチャが有効にされると、ＣＤＣプロセスマネージャは、同じ行の２つ以上のコピーが与えられ、レプリカから重複行をフィルタリングにより取り除くことができる。以下は、重複排除のためにＣＤＣプロセスマネージャが実行するステップである。

ある実施形態に従い、テーブルのいずれかの行がコミットログから読み出されると、ＣＤＣプロセスマネージャは、パーティションキーに基づいてこの特定の行のパーティショントークンを生成し、また、この行の起点のノードアドレスをキャッシュする。パーティショントークンを生成するために使用されるパーティショナーは、ライブノードから動的にフェッチされる。

新たな行が処理されるとき、ＣＤＣプロセスマネージャは、パーティショントークンの一致（行パーティションキーから生成されたもの）について、キャッシュをチェックする。

ＣＤＣプロセスマネージャキャッシュ内にパーティショントークンがある場合、ソース行の起点（ノード）を調べる。

ソース行の起点（ノード）がキャッシュ内のノードと一致する場合、この行データはパスされる。その後、同じパーティションキー（パーティショントークン）の新たな行はいずれもこのノードから受け入れられる。

ソース行の起点（ノード）がキャッシュ内のノードと異なる場合、この行は重複でありフィルタリングによって取り除かれる。

ある実施形態に従い、ノードは、クラッシュ／シャットダウンする、または、デコミッションされる可能性がある。ノードがダウンし、ＣＤＣプロセスマネージャが、ダウンしたノードから特定のパーティショントークンのために行を読み出すプロセス中である場合、このＣＤＣプロセスマネージャにおける重複排除キャッシュはいくつかの無効エントリを有するであろう。このシナリオにおいて、ＣＤＣプロセスマネージャは、他のノードからの同じ行の受け入れを開始する。これは、現在のリング状態に基づいて重複排除キャッシュをリフレッシュすることによって実現される。

加えて、抽出コンポーネントプロセスが停止しリスタートした場合、重複排除キャッシュはスタートアップ時に再構築されて重複を回避する。パーティショントークンおよびノードマッピングを有するキャッシュは、抽出コンポーネントプロセスが停止され抽出コンポーネントプロセスのリスタート時にデシリアライズされたときに、ファイルにシリアライズされる。

記録処理フロー
ある実施形態に従い、ＣＤＣプロセスマネージャは、ミューテーションタイプの生記録をCassandraMutationProcessorに与えることにより、CassandraCDCMutationオブジェクトを生成する。ミューテーションがバルク動作を有する場合、CassandraMutationProcessorからの出力は、CassandraCDCMutation記録のリストであろう。処理されたCassandraCDCMutation記録はその後、フィルタリングプロセスを経る。抽出コンポーネントが開始タイムスタンプに位置していた場合、開始タイムスタンプよりも小さいタイムスタンプを有するいずれの記録もフィルタリングによって取り除かれる。これがレプリカノードからの重複記録である場合、これはフィルタリングによって取り除かれる。

ある実施形態に従い、レプリカからフィルタリングによって取り除かれた重複記録は履歴キャッシュに格納される。履歴キャッシュの深さは設定可能である。この深さは、履歴キュー内の最初の記録および最後の記録のタイムスタンプならびに記録カウントに基づく。システムはまた、すべてのノードから処理されたフィルタリングされていない最後の記録を追跡するために別のキャッシュを格納することもできる。

リングにおける変更は、結果としてパーティショントークン（パーティショントークン範囲）がノード全体にわたってシャッフルされることにつながる。パーティショントークンの移動が完了しない場合があり、リングにより多くの変更がある場合がある。ＣＤＣプロセスマネージャが、コミットログからの記録から生成された特定のパーティショントークンのレプリカを検出できない可能性がある。このシナリオが発生した場合（発生は非常に稀であるが）、このような記録はフィルタリングによって取り除かれない。メッセージもロギングされて重複記録の可能性を示す。

リングにおける変更イベント
ある実施形態に従い、CassandraTopologyManagerは、リングにおける、ノードのデコミッション、ノードのシャットダウン、新たなノードの追加、ノードの発生（ブート）、キースペースの追加／削除／修正、および、テーブルの追加／削除／修正、という変化／イベントを、登録しリッスンする。

ノードデコミッション／シャットダウンイベント
ある実施形態に従い、ノードがシャットダウンされるまたはリングからデコミッションされると、CassandraTopologyManagerは、以下のアクションを実行する。重複排除キャッシュをクリアすることにより、このノードに対応付けられたすべてのパーティショントークンを削除する。削除されたノードのレプリカノードを発見する。ダウンしたノードから読み出された最後の記録を発見する。レプリカノードのいずれかにおける一致する記録を発見する。最大の記録履歴を有するいずれかのレプリカノードからの記録をリプレイする。重複排除キャッシュを更新することにより、最後の記録のパーティショントークンを新たなレプリカノードにリンクさせる。ダウンしたノードに対するＳＳＨ接続を閉じる。

レプリカノードからの記録のリプレイ
ある実施形態に従い、記録を活発に供給していたノードがダウンすると、CassandraTopologyManagerは、レプリカノードを選択するとともに、ダウンしたノードが処理した最後の記録をルックアップする必要がある。一致する記録を有するレプリカノードが２つ以上ある場合、最大の記録履歴を有するレプリカが選択されて、シャットダウンしたノードの最後の記録において発見されたパーティショントークンを供給する。レプリカのうちいずれにおいても一致する記録が発見されなかった場合も、最大の記録履歴を有するレプリカが選択され、また、起こり得るデータ損失を示すために警告メッセージがロギングされてもよい。このシナリオにおける警告またはABEND抽出アクションを制御するためにパラメータを与えることができる。

ノード追加／ブートイベント
ある実施形態に従い、新たなノードがリングに追加されると、または、ダウンしたノードが現れると、Cassandraがリング内のパーティショントークン範囲のシャッフルに取り掛かる機会がある。抽出コンポーネントが既存のノードからいくつかのパーティショントークンについてデータを読み出しており何らかのやり方でこれらのパーティショントークンがリング内の別のノードに移動した場合、このようなパーティショントークンについての新たなデータがフィルタリングによって取り除かれるというリスクがある。CassandraTopologyManagerは、このシナリオに対処するために以下のアクションを実行するであろう。重複排除キャッシュを更新しいずれかのパーティションノードがリング内の新たなノードが原因で無効であるか否かをチェックする。接続をオープンすることにより新たなノードからコミットログをプルする。新たなノードに対して位置／チェックポイントエントリ（casschek.sonに）を生成する。

リモートコミットログの転送
ある実施形態に従い、クラスCassandraClusterSFTPClientは、処理のためにリモートコミットログを転送するのに使用されるＳＦＴＰクライアントである。このクラスはＪＳｃｈライブラリを使用する。ＳＳＨ接続がクラスタ内のすべてのライブノードに対してオープンされ、抽出コンポーネントプロセスが実行されているマシンにコミットログがプルされる。独立した専用スレッド上の１ノード当たり１つのＳＳＨ接続が存在するであろう。この接続は、ノードがリングの一部になるまで引続きオープンされる。

クラスタポジショニング
ある実施形態に従い、キャプチャを開始／リスタート／変更する固有位置を示すのに１つのログシーケンス番号で十分であるＲＤＢＭＳとは異なり、複数のノードを有するCassandraクラスタは、１ノード当たり１つの位置を格納する必要があるであろう。「ｎ」のノードリングに対して「ｎ」の位置がある。クラスClusterPositionは、マルチノード位置を格納する。このクラスはまた、１つのノードに対して位置を格納する別のクラスNodePositionも収容する。このクラスはまた、抽出のために開始タイムスタンプも格納する。位置情報はＪＳＯＮファイルに保存される。位置ファイルは、設定可能な間隔（典型的には１０秒ごと）で、シャットダウン中にも更新される。抽出コンポーネントのポジショニングは、この位置ファイルに基づく。このＪＳＯＮ位置ファイルは、抽出をポジショニングするために手作業で編集することができる。

ある実施形態に従うと、一例としての位置ＪＳＯＮファイルは次のように表すことができる。

データのポーリング
ある実施形態に従うと、ＣＤＣプロセスマネージャは、コミットログ内の新たなデータを継続して探す。Java ScheduledExecutorサービスを、設定可能なジョブ頻度で使用する。

スキーマローダ（Schema Loader）
ある実施形態に従うと、クラスSchemaLoaderは以下の役割を有する。Cassandra ＶＡＭモジュールからテーブルワイルドカードエントリを読み出し、ワイルドカードを拡張する。Cassandraクライアントアプリケーションにより、必要に応じてスキーマインスタンスをロードする。CommitLogReadHandlerインターフェイスは、ＣＤＣプロセスマネージャであるクライアントアプリケーションの現在のスキーマインスタンスにロードされるテーブルおよびキースペースについてのみ、コミットログセグメントデータを読み出すことができる。

アクティブコミットログからの読み出し
ある実施形態に従うと、アクティブコミットログ内のコミットログセグメントのフォーマットは、ＣＤＣコミットログと同様である。これにより、アクティブコミットログの読み出しおよびアクティブコミットログ内へのポジショニングを行うことができる。アクティブコミットログの読み出しは、レイテンシを低減するので、望ましい特徴である。また、これは、Cassandraデータベースプロセスはアクティブコミットログをトランケートし将来のデータベース変更のために再使用する場合があるので、リスクを伴う。アクティブコミットログをトランケートするときは、アクティブコミットの内容を、ＣＤＣディレクトリに移動させ新たなコミットログに入れる。これはまた、結果としてデータの重複を生じさせるが、レイテンシを低くする。

データタイプ
ある実施形態に従うと、表１はデータタイプマッピングおよびOracle Golden Gateのためにサポートされるデータタイプを示す。

トランザクションＩＤ（TranID GGSパーティショントークン）
ある実施形態に従うと、Cassandraにはトランザクションがない。すべての動作記録は、１つの動作記録とともに疑似トランザクションに包含される。これはＶＡＭ ＡＰＩとの互換性のためである。ある実施形態に従うと、トランザクションＩＤは、ノードアドレス、コミットログＩＤおよびコミットログ内のオフセットの連結によって構成される。

シーケンス番号（シーケンスＩＤまたはＣＳＮ ＧＧＳパーティショントークン）
ある実施形態に従うと、これは１から始まる単純なシーケンス番号である。トレイルに書き込まれるすべての記録は固有のシーケンス番号を有し、このシーケンス番号の値は、トレイルに書き込まれる新たな記録ごとに増大する。

ＶＡＭ位置－＞コンテキスト
ある実施形態に従うと、ＶＡＭデータ構造位置－＞コンテキストは、トランザクションＩＤと同一の値でポピュレートされるであろう。このデータは、抽出コンポーネントによるポジショニングには使用されない。抽出コンポーネントのポジショニングは、チェックポイント情報と、正確なポジショニングのためのフルオーディットリカバリ（full audit recovery）（ＦＡＲ）ロジックとに依拠する。

ポジショニングおよびリカバリ
ある実施形態に従うと、ＯＧＧ抽出をポジショニングすることにより下記のようにキャプチャすることができる。
利用できるすべてのデータを最初から読み出すことを開始：
GGSCI> ADD EXTRACT cassvam, TRANLOG
現在のタイムスタンプから開始：
GGSCI> ADD EXTRACT cassvam, TRANLOG, BEGIN NOW
所定の日付および時間から開始：
GGSCI> ADD EXTRACT cassvam, TRANLOG, BEGIN 2017-03-27 23:05:05.123456
前の実行からリスタート：
このインスタンスにおいて、ＪａｖａモジュールＣＤＣプロセスマネージャは、クラスタ内のすべてのノードへのポジショニングに関する情報を有するdirchk/casschk.jsonの下でＪＳＯＮ位置を書き込む。

ポジショニングおよびリカバリのシナリオ

ある実施形態に従うと、キャプチャプロセスは、チェックポイント情報（たとえば、上記のようにＪＳＯＮチェックポイントファイルなどの拡張されたチェックポイントファイル）を維持することにより、クラスタ内のすべてのノードのコミットログ位置を格納する。

ある実施形態に従うと、抽出コンポーネント／キャプチャプロセスがチェックポイント完了イベント（GG_CONTROL_CHECKPOINT_COMPLETE）を発行するときは常に、Cassandra ＶＡＭモジュールがデータ記録を供給しているクラスタ内のすべてのノードの位置を有するようにチェックポイント情報を更新する。

各種実施形態に従うと、本明細書の教示は、本開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または専用コンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを使用して、適宜実現し得るものである。ソフトウェア技術の当業者にとっては明らかであるように、熟練したプログラマは本開示の教示に基づいて適切なソフトウェアコーディングを容易に作成することが可能である。

いくつかの実施形態において、本明細書の教示は、本教示のプロセスのうちのいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された非一時的なコンピュータ読取可能記憶媒体（複数の媒体）である、コンピュータプログラムプロダクトを含み得る。このような記憶媒体の例は、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、またはその他の電気機械データ記憶装置、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム、または、命令および／またはデータの非一時記憶に適したその他の種類の記憶媒体もしくは装置を含むが、これらに限定される訳ではない。

その他の実施形態に従うと、本明細書の教示は、代替的に、本教示のプロセスのうちのいずれかを実行するためにコンピュータをプログラムするのに使用できる命令を保持または伝達する一時的なコンピュータ読取可能媒体であってもよい、コンピュータプログラムプロダクトを含み得る。その例は、コンピュータシステム内および／または間で起こり得る、キャリア信号および伝送を含む。

ここまでの記載は例示と説明を目的として提供されている。すべてを網羅することまたは保護範囲を開示されている形態そのものに限定することを意図しているのではない。多くの修正および変形が当業者には明らかであろう。

たとえば、本明細書に記載の特徴および教示の多くは、Cassandraデータベース環境からデータをキャプチャする例を用いて示されているが、各種実施形態に従うと、上記特徴および教示は、たとえばApache Cassandra、Kafka、MongoDB、Oracle NoSQL、Google Bigtable、DB2、MySQL、またはHDFSを含むがこれに限定されない、その他のタイプの分散型データソースシステム、データベース、データ構造、またはデータストリームから同様にデータをキャプチャするのに使用できる。

このように、１つの視点から、１つ以上の異種ターゲット、たとえばデータベースまたはメッセージキューに対して使用するために、分散型データソースシステム、たとえば分散型データベースまたは分散型データストリームからの変更データをキャプチャし、カノニカルフォーマット出力を作成するための、システムおよび方法について説明してきた。変更データキャプチャシステムは、分散型ソーストポロジー・アウェアネス、初期ロード、重複排除、およびリカバリなどの特徴に対するサポートを含み得る。本明細書に記載のシステムおよび方法の技術的目的は、複数のノードに分散する大量のデータを含む分散型データソースにおけるデータに対してなされた変更を判断し１つ以上のターゲットコンピュータシステムに伝達することを含む。

実施形態は、この教示の原則およびその実際の応用を最適に説明することにより、意図する特定の用途に適した各種実施形態および各種変形を当業者が理解できるようにするために、選択され記載されている。範囲は以下の請求項およびその均等物によって定められることを意図している。

Claims (17)

1. 異種ターゲットに対して使用するために、少なくとも１つのノードを含む分散型データソースからの変更データをキャプチャするためのシステムであって、前記システムは、
   プロセッサを含むコンピュータと、前記コンピュータ上で実行される変更データキャプチャプロセスマネージャとを備え、
   前記変更データキャプチャプロセスマネージャは、１つ以上のターゲットに対して使用するために、キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャし、前記変更データに含まれる記録から生成された固有のトークンと前記分散型データソースから当該記録を提供するノードとの対応付けを生成するように構成される、システム。
2. 異種ターゲットに対して使用するために分散型データソースからの変更データをキャプチャするためのシステムであって、前記システムは、
   プロセッサを含むコンピュータと、前記コンピュータ上で実行される変更データキャプチャプロセスマネージャとを備え、
   前記変更データキャプチャプロセスマネージャは、１つ以上のターゲットに対して使用するために、キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャするように構成され、
   前記変更データキャプチャプロセスマネージャは、前記分散型データソース内の、記録を提供してきた特定のノードが、使用できないノードになったと判断すると、前記特定のノードに含まれる記録を取得するための特定のレプリカノードを選択し、前記特定のノードに対応付けられたトークンをすべて削除し、前記特定のノードから読み出された最後の記録のトークンを前記特定のレプリカノードにリンクさせるリカバリプロセスを実行する、システム。
3. 異種ターゲットに対して使用するために、少なくとも１つのノードを含む分散型データソースからの変更データをキャプチャするためのシステムであって、前記システムは、
   プロセッサを含むコンピュータと、前記コンピュータ上で実行される変更データキャプチャプロセスマネージャとを備え、
   前記変更データキャプチャプロセスマネージャは、１つ以上のターゲットに対して使用するために、キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャするように構成され、
   一致する最後の記録を有するレプリカノードが２つ以上ある場合、最大の記録履歴を有する特定のレプリカノードが選択されて、前記少なくとも１つのノードのうち使用できないノードが処理した最後の記録から生成されたパーティショントークンを前記特定のレプリカノードにリンクさせる、システム。
4. 異種ターゲットに対して使用するために、少なくとも１つのノードを含む分散型データソースからの変更データをキャプチャするための、コンピュータによって実行される方法であって、前記方法は、
   キャプチャプロセスを含む変更データキャプチャプロセスマネージャを提供するステップと、
   １つ以上のターゲットに対して使用するために、前記キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャするステップと、
   前記変更データに含まれる記録から生成された固有のトークンと前記分散型データソースから当該記録を提供するノードとの対応付けを生成するステップとを含む、方法。
5. 前記分散型データソースは、分散型データベース、または分散型データストリーム、またはその他の分散型データソース、のうちの１つとすることができ、前記１つ以上のターゲットは、データベース、メッセージキュー、またはその他のターゲット、のうちの１つ以上を含み得る、請求項４に記載の方法。
6. 前記変更データキャプチャプロセスマネージャは、前記分散型データソースから読み出された前記変更データを、前記１つ以上のターゲットによる消費のために、前記変更データのカノニカルフォーマット出力に変換する変更データキャプチャプロセスを実行する、請求項４または５に記載の方法。
7. 前記変更データの前記カノニカルフォーマット出力は、前記変更データを伝達する対象であるターゲットシステムに基づいて、前記ターゲットシステムが使用するフォーマットに変換される、請求項６に記載の方法。
8. 前記変更データキャプチャプロセスマネージャは、前記変更データの前記カノニカルフォーマット出力を新たなターゲットシステムが使用するフォーマットにプラガブルアダプタコンポーネントを用いて変換する、請求項６または７に記載の方法。
9. 前記変更データキャプチャプロセスマネージャは、前記分散型データソースから提供された特定の記録の自動重複排除を前記対応付けに基づいて提供する重複排除プロセスを実行する、請求項４～８のいずれか１項に記載の方法。
10. 前記変更データキャプチャプロセスマネージャは、前記特定の記録を提供するノードと、前記対応付けにおいて前記特定の記録に固有のトークンに対応付けられたノードとが一致しない場合、前記特定の記録を前記変更データから削除する、請求項９に記載の方法。
11. 前記分散型データソースに対応付けられた分散型ソーストポロジーに対し、前記分散型ソーストポロジーへの１つ以上のノードの追加または前記分散型ソーストポロジーからの１つ以上のノードの削除を含む変更がなされると、前記重複排除プロセスは、前記分散型ソーストポロジーに対する前記変更を検出し、前記対応付けを更新する、請求項９または１０に記載の方法。
12. 前記変更データキャプチャプロセスマネージャは、前記分散型データソースに対応付けられた分散型ソーストポロジーの自動発見を実行し、前記分散型データソースのノードのコミットログへのアクセスを前記キャプチャプロセスに提供する、請求項４～１１のいずれか１項に記載の方法。
13. 前記変更データキャプチャプロセスマネージャは、前記分散型データソース内の、記録を提供してきた特定のノードが、使用できないノードになったと判断すると、前記特定のノードに含まれる記録を取得するためのレプリカノードを選択するリカバリプロセスを実行する、請求項４～１２のいずれか１項に記載の方法。
14. 一致する最後の記録を有するレプリカノードが２つ以上ある場合、最大の記録履歴を有する特定のレプリカノードが選択されて、前記少なくとも１つのノードのうち使用できないノードが処理した最後の記録から生成されたパーティショントークンを前記特定のレプリカノードに与える、請求項４～１３のいずれか１項に記載の方法。
15. 異種ターゲットに対して使用するために分散型データソースからの変更データをキャプチャするための、コンピュータによって実行される方法であって、前記方法は、
    キャプチャプロセスを含む変更データキャプチャプロセスマネージャを提供するステップと、
    １つ以上のターゲットに対して使用するために、前記キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャするステップとを含み、
    前記変更データキャプチャプロセスマネージャは、前記分散型データソース内の、記録を提供してきた特定のノードが、使用できないノードになったと判断すると、前記特定のノードに含まれる記録を取得するための特定のレプリカノードを選択し、前記特定のノードに対応付けられたトークンをすべて削除し、前記特定のノードから読み出された最後の記録のトークンを前記特定のレプリカノードにリンクさせるリカバリプロセスを実行する、方法。
16. 異種ターゲットに対して使用するために、少なくとも１つのノードを含む分散型データソースからの変更データをキャプチャするための、コンピュータによって実行される方法であって、前記方法は、
    キャプチャプロセスを含む変更データキャプチャプロセスマネージャを提供するステップと、
    １つ以上のターゲットに対して使用するために、前記キャプチャプロセスを用いて分散型データソースからの変更データをキャプチャするステップとを含み、
    一致する最後の記録を有するレプリカノードが２つ以上ある場合、最大の記録履歴を有する特定のレプリカノードが選択されて、前記少なくとも１つのノードのうち使用できないノードが処理した最後の記録から生成されたパーティショントークンを前記特定のレプリカノードにリンクさせる、方法。
17. １つ以上のコンピュータに請求項４～１６のいずれか１項に記載の方法を実行させるためのコンピュータ読取可能プログラム。

Images