Oracle NoSQL Databaseアプリケーションの索引ビューの作成

前述のように、特に索引付け要件が単純な場合、索引名は単純なテキスト・ラベルにできます。ただし、索引名でビュー・レコードに関する詳細情報を伝達することもできます。次のものを識別できるように索引名を作成できます。

この情報を伝達する索引名を作成するには、索引名に必要なすべての情報を保持するリスト・オブジェクトを作成した後、java.security.MessageDigestを使用して情報の一方向ハッシュを作成するという方法があります。リストのバイト配列への変換は、Key.createKey()メソッドを使用して実行できます。次に例を示します。

    /**
     * Construct and return an index name representing an index type.
     */
    private String getIndexName(String schemaName,
                                List<String> indexFieldNames) {

        MessageDigest md = null;
        try {
            /* 
             * The implementation for digestCache is omitted 
             * for brevity.
             */
            md = digestCache.get();
            List<String> minorPath = new ArrayList<String>();
            minorPath.add(schemaName);
            minorPath.addAll(indexFieldNames);
            byte[] bytes = 
                Key.createKey("", minorPath).toString().getBytes();
            md.update(bytes);
            return new String(md.digest());
        } finally {
            digestCache.free(md);
        }
    } 

これは、索引名で伝達する情報は一方向ハッシュでロックされることを意味します。その情報をハッシュから取得する方法はないため、ある場所に保存する必要があります。索引ビュー・メタデータを記録するには、個別のレコード・セットが必要です。

索引ビュー・メタデータは、各索引タイプについて記録する情報です。通常、これは索引名の作成に使用する情報です(複雑な索引名を使用する場合)。索引の状態をメタデータの一部として記録することもできます。

索引ビュー・メタデータを一連のキーのみのレコードとして収集できます。この場合、キーは次のように作成されます。

/PREFIX/INDEX_NAME/-/SCHEMA_NAME/FNAME1/FNAME2/.../STATE

それぞれの意味は次のとおりです。

すべてをまとめて複雑な索引名を使用する索引ビューを作成するには、次の手順を実行します。

索引ビューを使用する(読み取る)には、次の手順を実行します。

既存のレコードを更新するには、次の手順を実行します。

これらの操作をすべて実行する例は、Oracle NoSQL Databaseディストリビューションに含まれています。詳細は、「例」を参照してください。

キーが長くなるほど、ノードで使用するメモリーが増えます。したがって、キャッシュ内に十分なレコードを保持できないため、キーはシステムの読取り/書込みスループット全体に損害を与えるほど大きくなる可能性があります。

ここで説明するキーのみの設計パターンでは、キーが非常に長くなる可能性が高いです。キー・サイズが非常に大きいためにパフォーマンスの問題が発生するかどうかは、キーが実際に存在する期間、管理する必要があるキーの数、およびノードで使用可能なメモリーの量に依存します。

キーが非常に大きいためにI/Oスループットの問題が発生する場合は、他の設計方法を実装する必要があります。

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

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

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

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

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

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

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

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

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

1つの方法としては、ビューを使用して実行する読取りには絶対整合性保証を使用することです。ただし、絶対整合性では読取り操作をマスター・ノードで実行する必要があるため、読取りおよび書込みのパフォーマンスが低下する可能性があります(詳細は、『Oracle NoSQL Database Key/Value APIスタート・ガイド』の事前定義済の整合性の使用に関する項を参照してください)。このため、ビューがプライマリ・データに対して完全に最新の状態であることが重要な場合のみ、絶対整合性を使用してください。

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