索引ビューに関する一般的な考慮事項

索引ビューを作成すると、(データ・セットのサイズおよびそれに対する質問の種類に応じて)ストアの読取りパフォーマンスが大幅に向上しますが、注意が必要ないくつかの制限事項があります。

追加の書込みアクティビティ

索引ビューをやむを得ず保持する場合、プライマリ・レコードの保持に必要なアクティビティに加えて、追加の読取りおよび書込みアクティビティが必要です。この追加のアクティビティが書込みスループットに目に見えて影響するかどうかは、索引付けするデータセットのサイズ、およびビューのサイズによって異なります。

小さいデータセットと小さいビューの場合、この追加のアクティビティは目立ちません。ただし、索引付けされるデータのサイズが大きくなり、ビュー自体が大きくなるにつれて、スループット、特に書込みスループットの低下が見られるようになる可能性があります。このような場合は、ストア・サイズを計画するときに、索引ビューを保持するためのオーバーヘッドを考慮するようにしてください。

非アトミック更新

索引ビューはアプリケーションで管理されるため、Oracle NoSQL Databaseでは、プライマリ・レコードで実行される操作が、対応するビュー・レコードで実行される操作とアトミックであることは保証できません。これは、プライマリ・レコードの変更は可能ですが、索引ビューでの対応する操作が失敗すると、プライマリ・データと同期されなくなることを意味します。その逆も発生する可能性があります。索引ビューの更新操作は成功したものの、プライマリ・レコードに対する更新は失敗するという場合です。

一部のワークロードでは、プライマリ・レコードおよびその索引ビューに対する非アトミック更新が望ましいことに注意してください。これは、考えうる最大の読取りおよび書込みスループットを必要とするワークロードの場合にときおり言えることです。このようなタイプのアプリケーションの場合、索引ビューとプライマリ・データの間の整合性は、全体のパフォーマンスに比べると重要ではありません。

いずれにしても、コードが問題を検出した場合に補正トランザクションを実行できるように、索引がプライマリ・データに対して非同期になっていないかどうかを確認してみる必要があります。更新操作のある局面が失敗した場合、索引ビューに安全でない状態であるとしてフラグを設定する必要もあります。索引ビューを保持しているプライマリ・レコードを更新する最も安全な方法(必ずしも最も速い方法とはかぎりません)は、次のとおりです。

ビューがREADY状態かどうかを確認します。そうである場合は更新操作に進みます。そうではない場合は、一時停止して状態が変化するまで待機するか、更新を完全に中止します。
必要に応じてプライマリ・レコードを更新しますが、まだ結果をストアに書き戻さないでください。
プライマリ・レコードに対して加えた変更を反映するように索引ビューを更新します。
プライマリ・レコードをストアに書き込みます。書込みに失敗した場合は、補正トランザクションを実行して問題を修正します。更新されたレコードで書込み操作を再試行するか、または現在ストアに存在するレコードがなんらかの形で破損または変更されていないことを確認します。
プライマリ・レコードの更新が成功した場合は、索引ビューの変更をストアに書き込みます。これが成功すると、更新は完了です。
索引ビュー・レコードの更新に失敗した場合は、ただちに索引ビューを非READY状態であるとしてマークします。これを実行する方法は、索引ビューの状態フラグをどのように保存しているかによって異なりますが、メタデータ・レコードを使用している場合は、索引ビューを修正するステップを実行する前にフラグを更新する必要があります。

プライマリ・レコードの作成および削除にも同様のアルゴリズムが必要です。

もちろんこれは、索引ビューの読取りを実行する前に、ビューの状態を確認してから続行する必要があるということです。ビューの状態がREADYではない場合は、状態がREADYになるまで一時停止するか、読取りを完全に中止する必要があります。この確認以外に、索引ビューが、プライマリ・レコードと整合性がある状態であることも確認する必要があります。これについては、次の項で説明します。

整合性の分離

前述のように、索引ビューは、更新操作の包括的な障害によりプライマリ・データと同期できない可能性があります。コードは、このような問題が発生するタイミングを認識できるだけの堅牢性を備えていなければならず、かつ適切な措置を講じる必要があります(必要に応じて索引ビューの再構築まで含みます)。関連する一時的な問題として、特定のノードでは、ビューを変更してもレプリケーションの遅延によりプライマリ・レコードの変更に追い付かない可能性があります。対応するプライマリ・データの変更がまだ始まっていなくても、ローカル・ノードのビューの更新は終わっているという可能性もありますので注意してください。

また、一部のワークロードでは、ビューがプライマリ・データと同期しているかどうかはそれほど重要ではない場合があります。ただし、ワークロードでビューにプライマリ・データが正確に反映されていることが必要な場合は、Oracle NoSQL Databaseの組込みの整合性保証機能を利用する必要があります。

1つの方法としては、ビューを使用して実行する読取りには絶対整合性保証を使用することです。ただし、絶対整合性では読取り操作をマスター・ノードで実行する必要があるため、読取りおよび書込みのパフォーマンスが低下する可能性があります(詳細は、「単純な一貫性の使用」を参照してください。)このため、ビューがプライマリ・データに対して完全に最新の状態であることが重要な場合のみ、絶対整合性を使用してください。

この問題を解決する方法としては、索引ビューを使用するときにバージョンベースの整合性保証を使用する方が適しています。読取りを実行してプライマリ・データとビューが同期していることを確認する際に、プライマリ・データとビューの両方でバージョン情報を確認する必要があります。あるプロセスがストアの書込みを実行し、別のプロセスがストアの読取りを実行する場合、アプリケーションの異なるプロセス間でバージョン情報を転送する方法を作成することも必要です。バージョンベースの整合性の使用の詳細は、「バージョンベースの一貫性の使用」を参照してください。