| Oracle® Fusion Middleware Oracle GoldenGate for Big Dataの統合 リリース12.3.0.1 E88297-01 |
|
 前 |
 次 |
この章では、Cassandraハンドラについて説明し、その機能を理解できるように例を示します。
内容は次のとおりです。
Cassandraハンドラは、Apache Cassandraデータベースへのインタフェースを提供します。
Apache Cassandraは、大量のデータを格納するために設計されたNoSQLデータベース管理システムです。Cassandraクラスタ構成によって、複数のマシン間でデータの水平スケーリングおよびレプリケーションが行われます。Cassandraクラスタ内の複数のノードにデータを複製することによって、高可用性が実現し、単一点障害を防ぐことができます。Apache Cassandraはオープン・ソースで、低価格のコモディティ・ハードウェアで実行できるように設計されています。
Cassandraでは、原子性、整合性、独立性および永続性に関して、従来のリレーショナル・データベース管理システムの原理が緩和されています。Cassandraの実装を検討する場合は、従来のRDBMSとの相違点と、その相違点が個々のユースケースにどのように影響するかを理解しておくことが重要です。
Cassandraでは最終的に整合性が保たれます。最終的整合性モデルでは、特定の行のデータの状態にアクセスすると、最新の変更によって定義されたとおりに、その行のデータの最新状態を最終的には返します。ただし、行の状態の作成および変更と、その行の状態を問い合せたときの戻り値の間に、レイテンシ期間が生じる場合があります。最終的整合性では、Cassandra構成およびCassandraクラスタが現在置かれているワークロードのレベルに応じてレイテンシ期間は予測可能であることが約束されます。詳細は、次に示すApache CassandraのWebサイトを参照してください。
Cassandraハンドラは、Javaアダプタ・プロパティ・ファイルのgg.handler.name.consistencyLevelプロパティの構成を使用して、整合性の一部を制御します。
Cassandraには多くの列データ型が用意されており、そのデータ型のほとんどがCassandraハンドラでサポートされています。ソース証跡ファイルの列値から、CassandraハンドラでCassandra列タイプを表す対応するJavaタイプへのデータ型変換が必要です。このデータ変換プロセスは、実行時変換エラーのリスクを引き起こします。フィールドが適切にマップされていないと(英数字データを含むvarcharのソースをCassandraのintにマップするなど)、実行時エラーが発生し、Cassandraハンドラが異常終了することがあります。Cassandraデータ型のマッピングを説明するリンクを次に示します。
https://github.com/datastax/java-driver/tree/3.x/manual#cql-to-java-type-mapping
次のCassandra列データ型はサポートされていません。
list
map
set
tuple
Cassandraに取り込むために対応するJavaタイプにデータを変換する特別な処理が必要になるユースケースが存在する場合があります。この場合、次のオプションがあります。
一般的な正規表現の検索と置換機能を使用して、Cassandraで使用するJavaデータ型に変換できる方法にフォーマットされたソース列値データを取得できる場合があります。
デフォルトのデータ型変換ロジックを実装または拡張して、個々のユースケース用のカスタム・ロジックにオーバーライドできます。これが必要な場合、詳細はOracleサポートに連絡してください。
従来のRDBMSでは、構造化データを表に分割します。関連表は、データベースと呼ばれる高いレベルのコレクションに含まれます。Cassandraには、これら両方の概念が含まれています。RDBMSでの表はCassandraでも表ですが、RDBMSでのデータベースはCassandraではキースペースになります。
ソース証跡ファイルのメタデータ定義からのデータ・マップを対応するCassandraのキースペースと表にマップする方法を理解することが重要です。ソース表は通常、schema.tableで定義される2部構成の名前またはcatalog.schema.tableで定義される3部構成の名前のいずれかになります。次の表では、カタログ、スキーマおよび表の名前をCassandraにマップする方法について説明します。特別な構文を使用しなくても、Cassandraでは、すべてのキースペース、表名および列名は小文字に変換されます。
| ソース証跡ファイルの表名 | Cassandraキースペース名 | Cassandra表名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
Cassandraハンドラは、Cassandraのキースペースを自動的に作成しません。Cassandraのキースペースでは、レプリケーション・ファクタ、レプリケーション・ストラテジおよびトポロジを定義します。Cassandraハンドラには、キースペースを作成するための十分な情報がないため、キースペースを手動で作成する必要があります。
CassandraシェルからCREATE KEYSPACEコマンドを使用して、Cassandraのキースペースを作成できます。
Cassandraハンドラは、Cassandraの表を作成するよう構成した場合、自動的に作成できます。ソース表定義は、Cassandraの表を作成するための情報のソースが不十分でもかまいません。Cassandraの主キーは次の部分に分かれます。
パーティショニング・キーは、表のデータをCassandraのパーティションに分割する方法を定義します。
クラスタリング・キーパーティション内のアイテムの順序を定義します。
自動表作成のデフォルト・マッピングでは、最初の主キーがパーティショニング・キーになり、その他の主キーがクラスタリング・キーになるようにマッピングされます。
Cassandraハンドラによる自動表作成は、概念の証明としては適切ですが、データ定義で正常にスケーリングが行われない可能性があります。Cassandraで主キーの構成が不十分な表を作成した場合、Cassandraに格納されるデータの量が増えると、収集および取得のパフォーマンスが低下する可能性があります。複製される表のメタデータを分析し、対応するCassandraの表を戦略的に手動で作成することをお薦めします。その表は適切にパーティション化およびクラスタ化され、正常にスケーリングできるものにします。
Cassandraの表の主キー定義は、いったん作成すると変更することができません。Cassandra表の主キー定義を変更するには、次の手動の手順を実行する必要があります。
ステージング表を作成します。
元の表からステージング表にデータを移入します。
元の表を削除します。
変更された主キー定義を使用して、元の表を再作成します。
ステージング表から元の表にデータを移入します。
ステージング表を削除します。
Cassandraハンドラを構成して、ソース証跡ファイルの表定義には存在するが、Cassandra表定義には存在しない列を追加できます。Cassandraハンドラは、列を追加するメタデータ変更イベントに対応できます。ソース表定義をターゲットCassandra表定義に調整する調整プロセスが発生します。列を追加するよう構成すると、ソース表定義に存在し、Cassandra表定義には存在しない列が追加されます。表の調整プロセスは、アプリケーションの起動後、表に対する操作が最初に発生したときに実行されます。調整プロセスは、ソース表でのメタデータ変更イベント後、その変更イベント後にソース表に対する操作が最初に発生したときに再実行されます。
Cassandraハンドラを構成して、ソース証跡ファイルの定義には存在しないが、Cassandra表定義には存在する列を削除できます。Cassandraハンドラは、列を削除するメタデータ変更イベントに対応できます。ソース表定義をターゲットCassandra表定義に調整する調整プロセスが発生します。列を削除するよう構成すると、Cassandra表定義に存在し、ソース表定義には存在しない列が削除されます。
注意:
列を削除すると、Cassandra表からデータが永久に削除されるため、危険を伴う可能性があります。このモードを構成する前に、個々のユースケースを慎重に考慮する必要があります。
注意:
主キー列は削除できません。試行すると、異常終了します。
注意:
実際にDDL処理が行われないため、列名の変更は適切に処理されません。ソース・データベースでの列名の変更イベントは、Cassandraハンドラでは、既存の列を削除し新しい列を追加した場合と同じように解釈されます。
Cassandraハンドラは、非同期APIまたは同期APIのいずれかを使用して、Cassandraに操作をプッシュします。非同期モードでは、トランザクションのコミット(GROUPTRANSOPSを使用したグループ化されたトランザクションのコミット)時に操作がフラッシュされ、書込み永続性が保証されます。Cassandraハンドラは、トランザクションの方法でのCassandraとのインタフェースがありません。
Cassandraでは、挿入、更新および削除操作が、従来のRDBMSとは異なる方法で処理されます。次に、挿入、更新および削除操作がCassandraでどのように解釈されるかについて説明します。
挿入 - Cassandraに行がまだ存在しない場合、挿入操作は挿入として処理されます。Cassandraに行がすでに存在する場合、挿入操作は更新として処理されます。
更新 - Cassandraに行が存在しない場合、更新操作は挿入として処理されます。Cassandraに行がすでに存在する場合、更新操作は挿入として処理されます。
削除 - Cassandraに行が存在しない場合、削除操作は無効です。Cassandraに行が存在する場合、削除操作は削除として処理されます。
Cassandraのデータの状態は、最終的には冪等です。ソース証跡ファイルまたは証跡ファイルのセクションを再生できます。最終的には、証跡データがCassandraに書き込まれた回数に関係なく、Cassandraデータベースの状態は同じになります。
Oracle GoldenGateを使用すると、更新が発生した場合にソース証跡ファイルに伝播されるデータを制御できます。ソース証跡ファイルの更新のデータは、更新の圧縮または完全イメージのいずれかで、次のように列情報が指定されます。
値が変更された主キーおよび列が対象です。変更されなかった列のデータは、証跡ファイルには提供されません。
値が変更された主キーおよび列を含むすべての列と、値が変更されなかった列が対象です。
Cassandraハンドラにとっては、更新で使用可能な情報の量が重要です。ソース証跡ファイルに完全イメージの変更データが含まれる場合、Cassandraハンドラはプリコンパイルされた文を使用して、Cassandraで行更新を実行できます。完全イメージを使用すると、CassandraハンドラはCassandraの行に対して主キー更新を実行することもできます。Cassandraでは、主キーを変更することができないため、主キーを変更する更新は、削除と挿入として処理される必要があります。逆に、圧縮更新は、Cassandraの行更新にプリコンパイルされた文を使用できないということです。値と主キーの変更を特定する単純な文を動的に作成し、実行する必要があります。つまり、圧縮更新では、主キー更新は不可能で、その結果Cassandraハンドラは異常終了します。
ハンドラが圧縮更新または完全イメージ更新を指定できるように、制御プロパティgg.handler.name.compressedUpdatesおよびgg.handler.name.compressedUpdatesforを設定する必要があります。
デフォルト値のtrueは、Cassandraハンドラが圧縮更新を指定することを意味します。プリコンパイルされた文は更新に使用されず、主キー更新によってハンドラは異常終了します。
値をfalseに設定すると、プリコンパイルされた文は更新に使用され、主キー更新を処理できます。ソース証跡ファイルに完全イメージ・データが含まれていないと、危険を伴い、データが破損する可能性があります。これは、データが欠落している列がnullと見なされてしまい、null値がCassandraにプッシュされるためです。ソース証跡ファイルに圧縮データまたは完全イメージ・データのどちらが含まれているか疑わしい場合は、gg.handler.name.compressedUpdatesをtrueに設定する必要があります。
また、CLOBおよびBLOBデータ型は、LOB列値が変更された場合を除き、更新時にLOBデータを伝播しません。そのため、ソース表にLOBデータが含まれる場合は、gg.handler.name.compressedUpdatesをtrueに設定する必要があります。
主キーの更新
Cassandraの行の主キー値は、変更することができません。Cassandraの行の主キー値を変更する更新操作は、削除と挿入として処理される必要があります。Cassandraハンドラは、削除と挿入としてのみCassandraの主キーの変更となる更新操作を処理できます。この操作を正常に処理するには、ソース証跡ファイルに、すべての列の変更前と変更後の完全なデータ・イメージが含まれている必要があります。主キーの更新を正常に処理するには、Cassandraハンドラのgg.handler.name.compressed構成プロパティをfalseに設定する必要があります。
ドライバ・ライブラリの取得
Datastax Java Driver for Cassandraは、Oracle GoldenGate for Big Dataに付属しません。Datastax Java Driver for Cassandraの推奨バージョンは3.1で、次の場所からダウンロードします。
https://github.com/datastax/java-driver
クラスパスの設定
gg.classpath構成プロパティを構成して、Datastax Java Driver for CassandraのJARを指定する必要があります。 gg.classpath={download_dir}/cassandra-java-driver-3.1.0/*:{download_dir}/cassandra-java-driver-3.1.0/lib/*
ここでは、Cassandraハンドラのコンポーネントの構成とハンドラの実行について説明します。
Cassandraハンドラの構成可能な値は次のとおりです。これらのプロパティは、Javaアダプタ・プロパティ・ファイルにあります(Replicatプロパティ・ファイルにはありません)。
表6-1 Cassandraハンドラの構成プロパティ
| プロパティ | 必須/オプション | 有効な値 | デフォルト | 説明 |
|---|---|---|---|---|
|
必須 |
任意の文字列 |
いいえ |
Cassandraハンドラの名前を指定します。Cassandraハンドラ名は、この表にリストしたプロパティ名の一部になります。 |
|
必須 |
|
いいえ |
Cassandraハンドラを選択し、変更データ取得をCassandraにストリーミングします。 |
|
オプション |
|
|
デフォルトが推奨されます。 |
|
オプション |
Cassandraハンドラの接続先となるホスト名のカンマ区切りリスト。 |
|
Cassandraクラスタへの初期接続を確立するドライバのCassandraホスト・マシンのカンマ区切りリスト。この構成プロパティには、Cassandraクラスタに登録されたすべてのマシンを含める必要はありません。1つのマシンに接続することによって、ドライバはCassandraクラスタ内の他のマシンについて理解し、必要に応じてそのマシンへの接続を確立できます。 |
|
オプション |
有効なユーザー名の文字列。 |
いいえ |
Cassandraに接続するためのユーザー名。これは、資格証明が必要なCassandraを構成する場合に必須です。 |
|
オプション |
有効なパスワードの文字列。 |
いいえ |
Cassandraに接続するためのパスワード。これは、資格証明が必要なCassandraを構成する場合に必須です。 |
|
オプション |
|
|
Cassandraハンドラがソース証跡ファイルからの完全イメージ更新を必要とするかどうかを設定します。
|
|
オプション |
|
いいえ |
指定するDDL機能についてCassandraハンドラを構成します。オプションには、
|
|
オプション |
|
|
CassandraハンドラとCassandraの間の相互作用を設定します。な相互作用の場合は 同期的な相互作用の場合は |
|
オプション |
|
Cassandraのデフォルト。 |
Cassandraでの操作の整合性レベルを設定します。操作の実行時にCassandraクラスタに格納するために満たす必要がある基準を構成します。整合性レベルを低くするとパフォーマンスが向上し、高くすると安全になります。 Cassandraの書込み整合性レベルの詳細を確認するには、https://docs.datastax.com/en/cassandra/3.x/cassandra/dml/dmlConfigConsistency.htmlを参照してください |
Javaアダプタ・プロパティ・ファイルからのCassandraハンドラの構成例を次に示します。
gg.handlerlist=cassandra #The handler properties gg.handler.cassandra.type=cassandra gg.handler.cassandra.mode=op gg.handler.cassandra.contactPoints=localhost gg.handler.cassandra.ddlHandling=CREATE,ADD,DROP gg.handler.cassandra.compressedUpdates=true gg.handler.cassandra.cassandraMode=async gg.handler.cassandra.consistencyLevel=ONE
ユーザー名資格証明およびパスワード資格証明を使用して、CassandraクラスタへのCassandraハンドラの接続を保護できます。ユーザー名資格証明およびパスワード資格証明は、アダプタ・プロパティ・ファイルのCassandraハンドラ構成の一部として構成されます。「Cassandraハンドラ構成」を参照してください。
起動すると、Cassandraハンドラは、ソース表に対する操作が最初に発生したときに表チェックおよび調整プロセスを実行します。また、DDLイベントやメタデータ変更イベントが発生すると、Cassandraハンドラの表定義がダーティとマークされるため、次に表に対する操作が発生したとき、ハンドラは、次の項で説明されている表チェックおよび調整プロセスを繰り返します。
Cassandraハンドラは、最初に、ターゲットCassandraキースペースが存在するかどうかをターゲットCassandraデータベースに問い合せます。ターゲットCassandraキースペースが存在しない場合、Cassandraハンドラは異常終了します。キースペースはユーザーが作成する必要があります。ログ・ファイルには、Cassandraハンドラが必要とする正確なキースペース名のエラーが含まれている必要があります。
次に、Cassandraハンドラは、表定義が存在するかどうかをターゲットCassandraデータベースに問い合せます。表が存在しない場合、Cassandraハンドラは次の2つのいずれかを実行します。gg.handler.name.ddlHandlingにCREATEが含まれる場合、Cassandraに表が作成されます。それ以外の場合、プロセスは異常終了します。Cassandraに表が存在しないことを示すメッセージが記録されます。
Cassandraに表が存在する場合、Cassandraハンドラは、ソース証跡ファイルの表定義とCassandraの表定義の間で調整を実行します。この調整プロセスは、ソース表定義に存在し、対応するCassandra表定義に存在しない列を検索します。この基準に一致する列が見つかり、gg.handler.name.ddlHandlingプロパティにADDが含まれている場合、Cassandraハンドラは、新しい列を追加するCassandraのターゲット表を変更します。それ以外の場合、これらの列は無視されます。
次に、調整プロセスは、ターゲットCassandra表に存在するが、ソース表定義に存在しない列を検索します。この基準に一致する列が見つかり、gg.handler.name.ddlHandlingプロパティにDROPが含まれている場合、Cassandraハンドラは、これらの列を削除するCassandraのターゲット表を変更します。それ以外の場合、これらの列は無視されます。
最後に、プリコンパイルされた文が作成されます。
Cassandraハンドラをasyncモードに構成すると、syncモードの場合よりパフォーマンスが向上します。ReplicatプロパティGROUPTRANSOPSをデフォルトの1000に設定する必要があります。
整合性レベルの設定は、パフォーマンスに直接影響します。整合性レベルを高くするほど、特定の操作の伝送が完了と見なされる前に、Cassandraクラスタでの動作が適切になります。個々のユースケースの要件を満たす最低限の整合性レベルを選択する必要があります。整合性レベルの情報は、次を参照してください。
https://docs.datastax.com/en/cassandra/3.x/cassandra/dml/dmlConfigConsistency.html
Cassandraハンドラは、操作(op)モードまたはトランザクション(tx)モードのいずれかで動作します。最高のパフォーマンスを得るためには、操作モードが推奨されます。
gg.handler.name.mode=op
Cassandraデータベースでは少なくとも1つの主キーが必要で、主キーの値はnullにできません。主キーがないソース表の自動表作成は失敗します。
gg.handler.name.compressedUpdates=falseを設定すると、Cassandraハンドラは、データの完全な操作前イメージと操作後イメージを更新する必要があります。部分的なイメージ更新が行われたソース証跡ファイルでこのプロパティを設定すると、データが欠落した列に対してnull値が更新されます。この構成は正しくありません。更新操作を行うと、変更されなかった列のnull値のターゲット・データは汚染されます。
ソース・データベースでDDLが指定されていても、Cassandraハンドラはソース・データベースからのDDLを処理しません。かわりに、ソース表定義とターゲットCassandra表定義の間で調整プロセスを実行します。ソース・データベースで実行される、列名を変更するDDL文は、Cassandraハンドラでは、列がソース表から削除され、新しい列がソース表に追加された場合と同じように解釈されます。この動作は、gg.handler.name.ddlHandlingプロパティがどのように構成されているかに応じて異なります。
| gg.handler.name.ddlHandlingの構成 | 動作 |
|---|---|
|
Cassandraで古い列名とデータが保持されます。Cassandraで新しい列が作成されないため、DDLの変更から新しい列名のデータは複製されません。 |
|
Cassandraで古い列名とデータが保持されます。Cassandraで新しい列が追加され、DDLの変更から新しい列名のデータが複製されます。DDL変更の前と後で、データが存在する列が一致しません。 |
|
Cassandraで古い列名とデータが削除されます。Cassandraで新しい列が作成されないため、新しい列名のデータは複製されません。 |
|
Cassandraで古い列名とデータが削除されます。Cassandraで新しい列が作成され、DDLの変更から新しい列名のデータが複製されます。 |
この項では、様々な問題のトラブルシューティングに役立つ情報を示します。その他のヘルプについては、次のトピックを確認してください。
最も一般的な初期エラーは、必要なすべてのクライアント・ライブラリを含めるクラスパスが正しくないことす。ログ・ファイルにClassNotFound例外が作成されます。Javaアダプタ・ロギングをDEBUGに設定してトラブルシューティングを行い、プロセスを再実行できます。デバッグ・レベルで、ロギングには、gg.classpath構成変数からクラスパスに追加されたJARの情報が含まれます。gg.classpath変数は、構成されたディレクトリのすべてのJARを選択するワイルドカード(*)文字をサポートします。たとえば、/usr/cassandra/cassandra-java-driver-3.1.0/*:/usr/cassandra/cassandra-java-driver-3.1.0/lib/*のようになります。
クラスパスの設定の詳細は、「Cassandraハンドラの設定および実行」および「Cassandraハンドラ・クライアント依存性」を参照してください。
**** Begin Cassandra Handler - Configuration Summary ****
Mode of operation is set to op.
The Cassandra cluster contact point(s) is [localhost].
The handler has been configured for GoldenGate compressed updates (partial image updates).
Sending data to Cassandra in [ASYNC] mode.
The Cassandra consistency level has been set to [ONE].
Cassandra Handler DDL handling:
The handler will create tables in Cassandra if they do not exist.
The handler will add columns to Cassandra tables for columns in the source metadata that do not exist in Cassandra.
The handler will drop columns in Cassandra tables for columns that do not exist in the source metadata.
**** End Cassandra Handler - Configuration Summary ****
Cassandraハンドラを実行すると、Replicatプロセスが異常終了する原因となるcom.datastax.driver.core.exceptions.WriteTimeoutException例外が発生することがあります。これは、次に示す一部またはすべての条件下で発生する可能性があります。
Cassandraハンドラが、かなりの処理ロードでCassandraクラスタを配置する多数の操作を処理する。
GROUPTRANSOPSがデフォルトの1000より高く構成されている。
Cassandraハンドラが非同期モードで構成されている。
CassandraハンドラがONEより高い整合性レベルで構成されている。
問題は、CassandraハンドラがCassandraクラスタの処理速度より速くデータをストリーミングすることです。Cassandraクラスタの書込みレイテンシは、最終的に書込みリクエスト・タイムアウト期間を超え、例外が発生します。
考えられる解決策は、次のとおりです。
書込みリクエスト・タイムアウト期間を増やします。これは、Cassandraのwrite_request_timeout_in_msプロパティで制御され、cassandra_install/confディレクトリのcassandra.yamlファイルにあります。デフォルトは2000 (2秒)です。この値を増やすと、エラーを回避できます。変更を有効にするには、Cassandraノードを再起動します。
このエラーが発生した場合、ReplicatプロセスのGROUPTRANSOPS構成値を減らすことも推奨されています。通常、GROUPTRANSOPS構成を減らすと、処理されるトランザクションのサイズが減少し、CassandraハンドラがCassandraクラスタに負担をかけすぎる可能性が少なくなります。
Cassandraハンドラの整合性レベルを下げると、書込みと見なされている操作に対してCassandraクラスタが完了する必要がある作業の量が減少します。
