TDVキャッシングの概念

データキャッシングは、データを複製したり、データが利用される場所の近くにデータを保存したりしてアプリケーションのパフォーマンスを向上させるのに役立つ重要なデータ設計オプションです。キャッシングでは、ワークロードを複数のストレージ場所に分散することで、データベーステーブルに対して実行される、大量のリソースを消費するクエリーの影響を軽減することもできます。同じクエリーを複数回実行して同じ結果セットを返す代わりに、キャッシュを使用して結果を保存し、それを再利用できます。

キャッシング構成すべき状況

データベースへの直接クエリーによってデータの取得に顕著な遅延を引き起こすパフォーマンス上の問題が発生する場合は、データキャッシングを検討するときかもしれません。

利用可能なキャッシングのタイプ

TDVでは、お客様がニーズに合ったキャッシュを作成できるように、複数のキャッシングオプションを設計しました。オプションは次のとおりです。

• 完全更新キャッシング — キャッシュ更新アクションが開始されると、キャッシュ内のすべてのデータが取得されます。

• インクリメンタル更新キャッシング-キャッシュ更新アクションが開始されると、変更されたデータのみが取得され、キャッシュで更新されます。

— プルベースのインクリメンタルキャッシュ — インクリメンタルキャッシュの更新アクションは、データを利用するクライアントアプリケーションからの要求によって開始されます。この方法は、オンデマンドと見なすことができます。

— プッシュベースのインクリメンタルキャッシュ — インクリメンタルキャッシュの更新アクションは、オプションの構成時の定義に従って自動的に開始されます。キャッシュ内のデータは、これとは関係なしに更新されます。

キャッシングを使用するときに考慮する価値がある、データベースベンダーから提供される追加の拡張機能は次のとおりです。

• FastLoadなどのネイティブロード機能

• キャッシュデータを分割し、並列プロセスを実行してデータをキャッシュターゲットにロードする並列キャッシング機能

完全更新とインクリメンタル更新の違い

キャッシュデータの更新をインクリメンタルに、または完全に行うこともできます。完全な更新では、前回のキャッシュ更新以降に変更されたデータと変更されていないデータを含むキャッシュ内のデータ全体が取得されます。インクリメンタルなキャッシュ更新では、更新アクションの実行時に、変更されたデータ(新しく追加されたデータ、変更されたデータ、削除されたデータ)のみがキャッシュで更新されます。

[Caching(キャッシュ作成)]タブの[Advanced(詳細)]オプションで、いずれかをキャッシュ用に選択できます。プッシュベースのインクリメンタル更新が必要な場合は、「プッシュベースのインクリメンタルキャッシング」で説明されているいくつかの特別な構成手順が必要です。

インクリメンタルキャッシングオプションとは

TDVには、2つのインクリメンタルキャッシング方法があります。キャッシュへの更新は、次の2つのいずれかのモードで伝達できます。

• プルベースのインクリメンタルキャッシング

プルベースのインクリメンタルキャッシングは、TDVキャッシングメカニズムと2つのスクリプトを使用して設定できます。プルベースのインクリメンタルキャッシングでは、ユーザーまたはクライアントアプリケーションは、キャッシュのコピーを集中管理されるキャッシュコピーと同期するように要求する必要があります。この非同期方式のキャッシュデータ更新を使用すると、キャッシュのロード時間を短縮できます。初期データがキャッシュにロードされた後、それ以降の各ロードでは、小さなデータ変更でキャッシュを更新するだけでよいからです。プルベースのインクリメンタルキャッシュの詳細については、「プルベースのインクリメンタルキャッシュの設定」を参照してください。

• プッシュベースのインクリメンタルキャッシング

ネイティブのTDVキャッシングメカニズムとTDV変更管理サービス(CMS)を組み合わせて使用すると、プッシュベースのインクリメンタルキャッシングを設定し、セントラルイベントサーバーを構成できます。この同期方式のキャッシュデータ更新では、キャッシュデータのすべてのコピーにわたってキャッシュの一貫性が強制されます。インクリメンタルキャッシュ内のデータを保護するため、プライマリーセントラルイベントサーバーをバックアップするようにTDVサーバーを構成できます。トランザクションのセマンティクスがソースとキャッシュの間で異なるものになるのを防ぐため、ソースの変更がキャプチャされ、影響を受けるすべてのビューに適用されます。プッシュベースのインクリメンタルキャッシュの詳細については、「Oracle用のプッシュベースのインクリメンタルキャッシングの設定」を参照してください。

キャッシュ可能なTDVリソース

キャッシングを使用すると、さまざまなデータソースのビュー、テーブル、またはプロシージャから生成されたデータを保存できます。テーブルオブジェクトには、テーブル、データソースからのビュー、およびTDVビューが含まれます。プロシージャオブジェクトには、SQLスクリプト、パラメーター化されたクエリー、およびXML変換が含まれます。

利用可能なキャッシュストレージオプション

ストレージオプションは、キャッシュに関連する場所と一部の動作を決定します。キャッシュは次の形式で保存できます。

• Default(デフォルト) — キャッシュデータは、TDVによって決定されたデータベースの場所に保存されます。

• Automatic(自動) — キャッシュデータは、TDVによって決定された構造化ファイルの場所に保存されます。

• Single Table(単一テーブル) — キャッシュデータは、ユーザーが決定した構造化データベースの場所に保存されます。

• Multi-Table(複数テーブル) — キャッシュデータは、ユーザーが決定したデータベースの場所のユーザーが決定した数のキャッシュテーブルに保存されます。

単一テーブルキャッシングの場合、データの複数のスナップショット(ある時点で撮影されたデータの写真)が同じ物理テーブルに保存されます。複数のスナップショットが同じテーブルに保存されるため、キャッシュされたデータのインデックスはあまり効果的ではありません。複数テーブルキャッシュオプションでは、TDVはキャッシュされたリソースごとに複数の物理テーブルを使用するため、各スナップショットは独自のテーブルに保存されます。この機能により、古いキャッシュデータを削除する速度と新しくキャッシュされたデータにインデックスを作成する速度が向上します。複数テーブルキャッシングオプションの主な対象は、長期間保持される大量のデータを含むキャッシュです。このタイプのキャッシュの設定方法については、「データベースターゲットでの複数テーブルキャッシュの作成」を参照してください。

キャッシュターゲットとは

キャッシュターゲットは、データを指定された期間保存するために使用されるファイル、データベーステーブル、または複数のデータベーステーブルです。

データソースをキャッシュターゲットにするには、そのデータソースが「キャッシュの要件と制限」で指定されている前提条件に準拠している必要があります。同じキャッシュリソースをソースとターゲットの両方として機能させることは可能ですが、ソースとターゲットに異なるリソースを使用するのが一般的です。複数のリソースからのデータは、キャッシュターゲットテーブルを共有できません。

キャッシュするデータのタイプに最適なキャッシュターゲットとその操作方法を検討してください。たとえば、あるキャッシュターゲットは、ソースの重要なデータタイプをサポートしていない場合があります。「キャッシュの要件と制限」を確認してください。また、『TDV Reference Guide(TDVリファレンスガイド)』の「Cache Data Type Mapping(キャッシュのデータタイプマッピング)」も確認してください。

キャッシュで利用可能な更新オプション

TDVのキャッシュデータの更新は高度に構成可能です。TDV Studio UIから利用できる標準のスケジューリングツールを使用するか、カスタムの更新動作を定義できます。次の標準の更新オプションを使用できます。

• According to a policy(ポリシーに従う) — 再利用可能なキャッシュポリシーを使用して、キャッシュの更新スケジュールを定義できます。ポリシーを使用すると、テーブル、ビュー、およびプロシージャの更新オプションを定義できます。

• Immediately(即時) — TDVユーザーが[Caching(キャッシュ作成)]タブを開き、[Refresh Now(今すぐ更新)]をクリックすると、キャッシュが即座に更新されます。

• One Time Only(1回限り) — キャッシュを1回だけ更新する特定の日時をスケジュールできます。

• Periodic(定期的) — 定期的に繰り返されるキャッシュ更新アクションを定義できます。

• Custom(カスタム) — キャッシュの更新動作を制御および定義するSQLスクリプト、Javaプログラム、またはWebサービスを定義することもできます。たとえば、適切にフォーマットされた件名の電子メールが特定の電子メールアドレスに送信された場合にキャッシュの更新を開始するカスタムJavaプログラムを作成できます。カスタム更新動作の定義の詳細については、「プログラムによるキャッシュの更新とクリア」を参照してください。

キャッシングが定義されているビュー(またはテーブル)のクエリーを変更した場合、キャッシュは自動的に更新されません。正しい結果セットを取得するには、更新を実行するか、次回のスケジュールされた更新サイクルまで待つ必要があります。

キャッシュポリシーとは

キャッシュポリシーでは、キャッシュの更新と有効期限のスケジュールを定義します。キャッシュポリシーを定義した後、そのキャッシュポリシーを使用して、キャッシュするStudioリソースの更新と有効期限のスケジュールを制御できます。

キャッシュ内のリソースに同じ更新スケジュールと有効期限スケジュールを設定できるため、キャッシュデータにアクセスするアプリケーションのデータの整合性と精度を向上させることができます。たとえば、ORDERSテーブルとORDERDETAILSテーブルのキャッシュデータに依存するアプリケーションがある場合、キャッシュポリシーを使用して、それらのキャッシュが同時に更新されるようにすることができます。

キャッシュポリシーを使用すると、キャッシュのパフォーマンスも向上します。キャッシュポリシーが設定されている場合、特定のポリシーのキャッシュ更新アクションの一部であるリソースのリストが既知であるため、TDVはパフォーマンスに最適なキャッシュロード戦略を計算できます。

キャッシュポリシーが設定されている場合、キャッシュデータの整合性は完全に維持されるか、まったく維持されないかのいずれかです。キャッシュポリシーに含まれるリソースの1つが更新アクション時に失敗した場合、すべてのキャッシュが以前に成功したデータのスナップショットにロールバックされます。このため、キャッシュポリシーとインクリメンタルキャッシングの併用はサポートされていません。

• キャッシュデータが期限切れになるタイミングとキャッシュから削除されるタイミング

キャッシュの更新は、キャッシュの内容を作成または更新するために使用されます。キャッシュの構成方法に応じて、以前の更新からのデータがどのように期限切れになり、キャッシュから削除される可能性があるかが決まります。

期限切れのキャッシュバージョンは、そのバージョンを使用するすべてのトランザクションホールドが完了するか、ロールバックされるまで削除されません。

一般的な有効期限のスケジュールは次のとおりです。

• Never(無期限) — 現在および以前のすべてのデータスナップショットをキャッシュに保持します。

• Periodic(定期的) — 定期的に繰り返されるキャッシュ有効期限を定義できます。たとえば、指定した週数または年数が経過した後などです。

• According to Custom Criteria(カスタム基準に従う) — カスタムSQLスクリプト、Javaプログラム、またはWebサービスを定義することで、キャッシュデータの更新とクリアを制御できます。

キャッシュデータをクリアするかどうかを制御することもできます。

• Immediately(即時) — [Clear Now(今すぐクリア)]ボタンを使用してキャッシュをクリアします。これにより、古いバージョンのキャッシュデータが「期限切れ」とマークされ、新しい要求で使用できなくなります。その後、システムによってバックグラウンドタスクが開始され、期限切れのキャッシュバージョンが解放されたときにそのバージョンがクリアされます。

• On Failure(失敗時) — このオプションを選択すると、更新が失敗した場合にキャッシュがクリアされます。このオプションを使用すると、更新中に以前にキャッシュされたデータにアクセスできます。

• Before the Refresh(更新前) — このオプションを選択すると、更新を開始する前にキャッシュが自動的にクリアされます。キャッシュされたデータから読み取ろうとするクライアントは、新しいデータを待つ必要があります。すべての新しい要求で新しいキャッシュバージョンを使用するように強制し、古いキャッシュバージョンを「期限切れ」とマークします。ただし、古いキャッシュバージョンは実際にはクリアされません。キャッシュリソースに対する新しい要求では、キャッシュの更新によって提供される最新のデータを使用する必要があります。

• Periodically At Expiration Time(有効期限時に定期的) — 画面の[Expiration Schedule(有効期限のスケジュール)]部分で時間が定義されている場合は、キャッシュの有効期限時に古いキャッシュデータがクリアされます。

キャッシュのバージョン管理とトランザクションの整合性、および古いキャッシュの内容がクリアされるタイミング

TDVのキャッシュのバージョン管理では、既存のトランザクションが完了するまで古いキャッシュバージョンを保持することにより、トランザクションの整合性を維持します。期限切れのキャッシュバージョンは、そのバージョンを使用するすべてのトランザクションホールドが完了するか、ロールバックされるまで削除されません。キャッシュのクリアを手動で開始した場合も、古いキャッシュバージョンは「期限切れ」とマークされ、新しい要求で使用できなくなるだけです。その後、システムによってバックグラウンドタスクが開始され、期限切れのキャッシュバージョンが解放されたときにそのバージョンがクリアされます。

TDVは、以前のすべてのキャッシュデータスナップショットを保持することで、長時間実行されているキャッシュの更新を適切に処理するように構成できます。これにより、キャッシュがバックグラウンドでアクティブに更新されている間、データの使用可能性が維持されます。

読み取りの一貫性を維持するため、キャッシュされたビューのデータを使用する実行時間の長いクエリーでは、キャッシュの更新の開始時に使用していた元のキャッシュされたビューを使用して計算を完了できます。

キャッシュのエクスポートとインポート

TDV内で定義したすべてのキャッシュ情報は、エクスポートしてTDVに再インポートできます。TDVエクスポート機能を使用すると、TDV開発作業を効率的に管理できます。定期的にエクスポートすると、作業内容の有用なロールバックスナップショットが得られます。

キャッシュポリシーを使用するリソースに対するエラー処理の動作

キャッシュの更新がキャッシュポリシーによって開始され、完了前の任意の時点で失敗した場合、すべてのキャッシュが最後に成功したスナップショットにロールバックされます。

キャッシュの更新と有効期限のスケジュールが個別に定義されているリソースに対するエラー処理の動作

更新中に、キャッシュされるデータを提供するデータソースまたはキャッシュされたデータを保存するために使用されるデータソースに障害が発生した場合、キャッシュは、以前のスナップショットが使用可能かどうかに応じて、「失敗」または「失効」とマークされます。

更新中にTDVサーバーに障害が発生した場合、サーバーの再起動時にキャッシュは「失敗」または「失効」とマークされます。

完全更新を実行するキャッシュの場合、サーバーが更新の途中で停止すると、サーバーの再起動時に更新の試行が「失敗」とマークされます。部分的なデータは、最終的にガベージコレクターによって処理されます。

インクリメンタル更新を実行するキャッシュの場合、サーバーが更新の途中で停止すると、サーバーの再起動時にキャッシュステータスが「ダウン」とマークされます。