この章では、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
に設定する必要があります。
ここでは、Cassandraハンドラのコンポーネントの構成とハンドラの実行について説明します。
次を構成する必要があります。
ドライバ・ライブラリの取得
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ハンドラの構成可能な値は次のとおりです。これらのプロパティは、Javaアダプタ・プロパティ・ファイルにあります(Replicatプロパティ・ファイルにはありません)。
表2-1 Cassandraハンドラの構成プロパティ
プロパティ | 必須/オプション | 有効な値 | デフォルト | 説明 |
---|---|---|---|---|
|
必須 |
任意の文字列 |
なし |
Cassandraハンドラの名前を指定します。Cassandraハンドラ名は、この表にリストしたプロパティ名の一部になります。 |
|
必須 |
|
なし |
Cassandraハンドラを選択し、変更データ取得をCassandraにストリーミングします。 |
|
オプション |
|
|
デフォルトが推奨されます。 |
|
オプション |
Cassandraハンドラの接続先となるホスト名のカンマ区切りリスト。 |
|
Cassandraクラスタへの初期接続を確立するドライバのCassandraホスト・マシンのカンマ区切りリスト。この構成プロパティには、Cassandraクラスタに登録されたすべてのマシンを含める必要はありません。1つのマシンに接続することによって、ドライバはCassandraクラスタ内の他のマシンについて理解し、必要に応じてそのマシンへの接続を確立できます。 |
|
オプション |
有効なユーザー名の文字列。 |
なし |
Cassandraに接続するためのユーザー名。これは、資格証明が必要なCassandraを構成する場合に必須です。 |
|
オプション |
有効なパスワードの文字列。 |
なし |
Cassandraに接続するためのパスワード。これは、資格証明が必要なCassandraを構成する場合に必須です。 |
|
オプション |
|
|
Cassandraハンドラがソース証跡ファイルからの完全イメージ更新を必要とするかどうかを設定します。
|
|
オプション |
|
なし |
指定するDDL機能についてCassandraハンドラを構成します。オプションには、
|
|
オプション |
|
|
CassandraハンドラとCassandraの間の相互作用を設定します。な相互作用の場合は 同期的な相互作用の場合は |
|
オプション |
|
Cassandraのデフォルト。 |
Cassandraでの操作の整合性レベルを設定します。操作の実行時にCassandraクラスタに格納するために満たす必要がある基準を構成します。整合性レベルを低くするとパフォーマンスが向上し、高くすると安全になります。 SSLの |
gg.handler. name. withSSL |
オプション |
|
|
SSLを使用したCassandraクラスタへのセキュアな接続を有効にするには、trueに設定します。これには、追加のJavaブート・オプションの構成が必要です。詳細は、http://docs.datastax.com/en/developer/java-driver/3.3/manual/ssl/を参照してください。 |
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ハンドラ接続は、ユーザー名とパスワードの資格証明を使用して保護できます。これは、次の構成プロパティを使用して設定します。
gg.handler.name.username gg.handler.name.password
オプションで、SSLを使用してCassandraクラスタへの接続を保護できます。SSLのセキュリティを有効にするには、次のパラメータを設定します。
gg.handler.name.withSSL=true
さらに、Javaのbootoptions
は、keystore
の場所とパスワード、truststore
の場所とパスワードを含むように構成する必要があります。次に例を示します。
javawriter.bootoptions=-Xmx512m -Xms32m -Djava.class.path=.:ggjava/ggjava.jar:./dirprm -Djavax.net.ssl.trustStore=/path/to/client.truststore -Djavax.net.ssl.trustStorePassword=password123 -Djavax.net.ssl.keyStore=/path/to/client.keystore -Djavax.net.ssl.keyStorePassword=password123
起動すると、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クラスタが完了する必要がある作業の量が減少します。