マテリアライズド・ビューについて

マテリアライズド・ビューの仕組み

以下の手順では、DSEが更新をベース・テーブルからマテリアライズド・ビューに伝播する方法を示します。

1. コーディネーター・ノードはベース・テーブルのクライアントから更新を受け取り、構成済みのレプリカ・ノードに転送します。
   1. cassandra.mv_enable_coordinator_batchlogプロパティが有効になっている場合、コーディネーターはベース・テーブルの書き込みを含んでいるQUORUMノードにバッチログを書き込んでからレプリカに転送します。この構成によって、コーディネーターで要求の中間部分が欠落するのを効果的に防げるようになりますが、ビューの書き込み操作の速度はかなり低下します。バッチログ・コーディネーターの詳細については、「CASSANDRA-10230」を参照してください。
2. ベース・テーブルのコーディネーターから更新を受け取ると、各レプリカ・ノードは以下のタスクを完了します。
   1. ベース・テーブルのマテリアライズド・ビューごとにビューの更新を生成します。
      • 前のビューの行を削除または変更する必要があるかどうかを確認するために、ベース・テーブルでローカル読み取りが完了します。
      • ビューの更新がシリアライズ化されていることを確認するためにビューの更新が生成されると、ベース・テーブルでローカル・ロックが取得されます。このロックは、ビューの更新がレプリカに伝播してベースの更新がローカルに適用されると解除されます。
   2. ビューの更新が生成された後、ビューの更新ごとにそのペア化されたビューのレプリカを決定的に計算し、ビューのレプリケーション作業がベース・レプリカ間で分散されるようにします。
      • ベース・レプリカもビューのレプリカである場合は、ベース・レプリカはそれ自体をペア化されたビュー・レプリカとして選択し、ビューの更新を同期して適用します。
      • それ以外の場合、永続性を保つために更新はローカルのバッチログに同期して書き込まれ、リモートのペア化されたビュー・レプリカに非同期で送信されます。
   3. コーディネーター・ノードへの書き込みを確認します。
   4. すべての非同期ペア化ビュー書き込みの確認応答を受け取ったら、ローカル・バッチログを削除します。それ以外の場合、後でバッチログをリプライしてビューの更新をレプリカに伝播します。バッチログのリプライ時にレプリカがダウンしている場合は、ミューテーションごとに1つのヒントが書き込まれます。
3. 整合性レベルに基づいてすべてのノードから確認応答を受け取ると、コーディネーター・ノードはクライアントに対して正常な書き込み応答を返します。

パフォーマンスに関する注意事項

マテリアライズド・ビューでは、通常の読み取りパスを使用してデータを高速でルックアップできます。ただし、各マテリアライズド・ビューを更新するために追加の「書き込み前の読み取り」操作が実行されるため、マテリアライズド・ビューの書き込みパフォーマンスは通常のテーブル書き込みと同等ではありません。更新を完了するため、各レプリカでデータ整合性チェックが行われます。ソース・テーブルへの書き込みでレイテンシーが発生し（各マテリアライズド・ビューで10%以下）、ソース・テーブルでの削除パフォーマンスも低下します。

ソース・テーブルに対する削除が複数の連続する行に影響を及ぼす場合、この削除は1つのトゥームストーンでタグ付けされます。ただし、ソース・テーブルから派生したマテリアライズド・ビューでは、これらの同じ行が連続していない場合があります。その場合、マテリアライズド・ビューでは複数のトゥームストーンが作成されます。

指定の行に対するすべての適切な状態変更を確実にマテリアライズド・ビューに適用するには、特に同時更新に関しては、追加の作業が必要になります。マテリアライズド・ビューを使用することによって、データの正確性を保つためにパフォーマンスが相殺されます。

整合性に関する注意事項

各ベース・テーブル・レプリカは、ビューの更新をローカルに書き込むか（ベース・テーブル・レプリカがビュー・レプリカである場合も）、2.bに記載されているように、ベース・テーブル書き込みを返す前にローカル・バッチログを書き込みます。書き込み操作時にベース・テーブル・レプリカがリモート・ビューを更新できない場合、レプリカはバッチログ・リプライ時に更新を再試行します。このメカニズムにより、ベース・テーブル・レプリカでデータ損失が発生しない限り、各ベース・テーブル・レプリカへのすべての変更がビューに反映されます。

ビュー・レプリカの書き込み操作は、可用性が損なわれないようにするため非同期です。その結果、書き込み操作がベース・レプリカによって伝播されるまで、ビューの読み取り操作がベース・テーブルへの正常な書き込みをすぐに確認できない場合があります。 通常の状態では、データをすぐにビューで利用することができます。ビューの伝播時間を追跡するには、ViewWriteMetricsメトリックを使用します。

ベースとビューの不整合をもたらす可能性があるシナリオ

通常のDSEテーブルでは、行が整合性レベルのレプリカに正常に書き込まれた場合、更新が残りのレプリカに伝播される前にそれらのレプリカが永続的に使用できなくなると、データが失われる可能性があります。以下の例でこのシナリオを示します。

1. レプリケーション係数が3（RF=3）で整合性レベルが1のテーブルに書き込みます。
2. ベース・レプリカはコーディネーター・ノードでもあります。
3. コーディネーターは書き込みが正常に行われたクライアントに応答します。
4. コーディネーター・ノードをホストしているマシンがダウンします。

マテリアライズド・ビューの場合は、前の例に補足的意味合いがあります。ベース・テーブル（コーディネーター・ノード）がビューの更新を別のノードに正常に書き込んだ場合、行はベース・デーブルではなくビューのみに存在し、孤立したビュー行を作成します。

孤立したビュー行を作成できるもう1つのナリオは、障害の間に修復せずに、ベース・テーブル行がすべてのレプリカを失う場合です。ビュー行がレプリカを失うと、ベース・テーブル行は対応するビュー行を持たなくなります。

ベース・テーブルとマテリアライズド・ビューの不整合を回避するには、「マテリアライズド・ビューのベスト・プラクティスを確認してください。