分散キャッシュ・アプリケーションの開発

帯域幅を増やすためにアプリケーション・サーバとデータ・サーバとの間に複数の重複した ECP チャネルを確立しないでください。1 つの論理トランザクションに対するロックや更新がデータ・サーバ上で非同期になり、データが不整合になるリスクがあります。

ECP 経由で提供されるブロックをバッファリングする処理に加え、データ・サーバでは、さまざまな ECP 制御構造を格納するのにグローバル・バッファを使用します。この構造に必要なメモリ量を決定する要素はいくつかありますが、最も重要なものは、クライアントのキャッシュの集約サイズの関数です。要求サイズを概算するために、必要に応じてデータ・サーバのデータベース・キャッシュを調整できます。以下のガイドラインを使用してください。

例えば、既定の 8 KB のブロック・サイズに加えて 16 KB のブロック・サイズが有効になっていて、6 つのアプリケーション・サーバがあり、それぞれに 2 GB の 8 KB データベース・キャッシュおよび 4 GB の 16 KB データベース・キャッシュがある場合、データ・サーバの 8 KB データベース・キャッシュを調整して制御構造用に 52 MB (50MB + [12 GB * .01]) を使用できるようにし、16 KB キャッシュを調整して制御構造用に 2 MB (24 GB * .005) を使用できるようにする必要があります (どちらの場合も小数点以下は切り上げます)。

データベース・キャッシュの割り当てに関する詳細は、"メモリと開始設定" を参照してください。

ラウンドロビンまたは負荷分散方式でユーザをアプリケーション・サーバに接続すると、アプリケーション・サーバ上でキャッシュから得られる利点が減る可能性があります。ユーザが機能グループに属しており、機能グループで同一のデータを読み取る必要がある場合は、特にこれに該当します。これらのユーザは、複数のアプリケーション・サーバに分散しているため、各アプリケーション・サーバが、データ・サーバに同一のデータを要求する可能性があり、それによって、同じデータに対して複数のキャッシュを使用して分散キャッシュの効率を低下させるだけでなく、ブロックの無効化が増加する可能性もあります。ブロックは、1 つのアプリケーション・サーバで変更されると、他のアプリケーション・サーバでも更新されるためです。これはいくらか主観的ですが、アプリケーションの特性に詳しい人がこの可能性について検討する必要があります。ロード・バランサを構成する場合は、"負荷分散、フェイルオーバー、ミラー構成" を参照して、複数のアプリケーション・サーバにわたってアプリケーション接続を分散する Web サーバ層の負荷分散に関する重要な説明を確認してください。

単一トランザクション内の更新を、単一のリモート・データ・サーバまたはローカル・サーバに制限します。トランザクションに複数のサーバ (ローカル・サーバを含む) に対する更新が含まれており、TCommit が正常に完了できないと、トランザクションに含まれるサーバによっては、更新をコミットしたものと、ロールバックしたものがある場合があります。詳細は、"コミットの保証" を参照してください。

一時 (スクラッチ) グローバルは、グローバルに共有する必要があるデータを含まない場合、アプリケーション・サーバのローカルに配置する必要があります。多くの場合、一時グローバルは、とてもアクティブで、書き込みが集中します。一時グローバルがデータ・サーバ上に配置されていると、これによって ECP 接続を共有する他のアプリケーション・サーバに不利となります。

未定義のグローバル (例えば、^x が未定義の $Data(^x(1)) など) が繰り返し参照される場合、グローバルがデータ・サーバで定義されているかどうかをテストするネットワーク処理が常に起こります。

それとは対照的に、定義されたグローバル内の未定義のノード (例えば、^x の他のノードが定義済みの $Data(^x(1)) など) が繰り返し参照される場合、グローバル (^x) がアプリケーション・サーバ・キャッシュに格納されると、ネットワーク処理は要求されません。

この動作は、ネットワークに接続されていないアプリケーションの場合と大きく異なります。ローカル・データでは、未定義のグローバルに対する参照の繰り返しは、最適化され、不要な作業は排除されます。アプリケーションをネットワーク環境に移植する設計者の場合、グローバルの使用が定義されていたり、定義されていなかったりするため、確認が必要になる場合があります。通常は、グローバルの他の特定のノードが常に定義されていることを確認するだけで十分です。

ストリーム・フィールドがクエリにあると読み込みロックが発生し、データ・サーバへの接続が必要になります。このことから、このようなクエリではデータベース・キャッシュの利点が得られず、2 回目以降の実行でもパフォーマンスが向上しません。

オンライン・トランザクション処理システムの共通の動作は、レコード番号などに使用する一意の値を生成することです。これは、一般的なリレーショナル・アプリケーションで、“次に使用可能な” カウンタ値を含むテーブルを定義して行います。アプリケーションに新規の識別子が必要な場合、カウンタを含む列をロックし、カウンタ値をインクリメントし、ロックを解放します。これは、シングル・サーバ・システムであっても並行処理障害を引き起こします。つまり、アプリケーション・プロセスは、共通カウンタ上のロックが解放されるのを、より長時間待機するようになります。ネットワーク環境では、これはある時点でさらに障害となります。

InterSystems IRIS は、アプリケーション・レベルのロックを一切必要とせずに、(グローバルに格納される) カウンタ値を自動的にインクリメントする $Increment 関数を提供することでこれに対処します。$Increment の並行処理は、InterSystems IRIS データベース・エンジンと ECP の両方に組み込まれており、シングル・サーバや分散アプリケーションで使用した場合に非常に高い効率性が実現されます。

InterSystems IRIS オブジェクト (あるいは SQL) から提供される既定構造を使用して構築されたアプリケーションは、$Increment を自動的に使用して、オブジェクト識別子の値を割り当てます。$Increment は、ECP 上で実行された場合のジャーナル同期に関わる同期処理です。このため、ECP 上での $Increment は比較的低速の処理となり、とりわけ他の比較対象が (アプリケーション・サーバ・データベース・キャッシュまたはデータ・サーバ・データベース・キャッシュのいずれかに) キャッシュ済みのデータを持っているかどうかにより違いが出ます。この影響は、フェイルオーバー・メンバ間のネットワーク遅延により、ミラーリング環境においてさらに大きくなります。このため、アプリケーションを再設計して $Increment を $Sequence 関数に置き換えると便利な場合があります。こうすると、新しい値のバッチは各アプリケーション・サーバ上で各プロセスに自動的に割り当てられ、データ・サーバは新規に値のバッチが必要になった場合にのみ処理に参加します (ただし、連続したアプリケーション・カウンタ値が必要な場合、この手法は使用できません)。$Sequence は $Increment と組み合わせて使用することもできます。

<NETWORK> エラーは、通常の ECP リカバリ・メカニズムで処理できなかったエラーを示します。

アプリケーション内で <NETWORK> エラーを受け取った場合は常に、プロセスの停止や未実行処理のロールバックが可能です。<NETWORK> エラーの中には、本質的に致命的なエラー状態になるものもあります。すぐに解決する一時的な状態を示すものもあります。しかし、理想的なプログラミング手法とは、<NETWORK> エラーの発生時、未実行処理をロールバックし、現在のトランザクションを最初から開始することです。

$Data や $Order など get 型要求の <NETWORK> エラーは、即座にトランザクションをロールバックするのではなく、手動で再試行できます。ECP は、データを損失する <NETWORK> エラーの発生を避けようとしますが、読み取り専用の要求に多くのエラーを生じます。

アプリケーション側の rollback-only 条件は、アプリケーション・サーバによって開始されたトランザクション中にデータ・サーバがネットワーク障害を検出したときに発生し、トランザクションがロールバックされるまですべてのネットワーク要求でエラーが発生した状態になります。