TDVの外部キャッシュ機能の利用方法について説明します。
本手順で利用する外部キャッシュデータベースのDBエンジンは Oracle 19c です。
(追記)
DBエンジンがAurora PostgreSQL(13.6)の場合の手順を追記
DBエンジンがAurora MySQL 5.7(2.10.2)の場合の手順を追記
キャッシュターゲット
TDVではキャッシュターゲットとして大きく分けて以下の3通りを選択できます。
キャッシュターゲット | 説明 |
---|---|
デフォルトキャッシュデータベース | TDVインストール時に自動で構築されるデフォルトのキャッシュデータベースにキャッシュデータを保存する方式です。 DBエンジンはPostgreSQLです。 ただし、パフォーマンスチューニングの余地がほとんどなく、TDV ServerをActive Cluster構成にしても各TDV Serverのデフォルトキャッシュデータベースはクラスタ構成とはならず大規模ユースケースに不向きであることから、商用環境での利用は推奨されていません。 |
外部キャッシュデータベース | 利用者が用意した任意のデータベースにキャッシュデータを保存する方式です。 |
ファイル | データベースではなくファイルにキャッシュデータを保存する方式です。 主に設計・開発時の利用を想定しており、商用環境での利用は推奨されていません。 |
本記事では、「外部キャッシュデータベース」を利用する方式について説明します。
更新モード
TDVではキャッシュの更新モードとしては以下が提供されています。
キャッシュターゲット | 説明 |
---|---|
完全更新モード | 「完全更新モード」でキャッシュを利用します。 キャッシュリフレッシュのたびにキャッシュテーブル内のデータはすべて置換されます。 最も簡単なアプローチです。 |
増分更新モード | キャッシュ更新アクションが開始されると、変更されたデータのみが取得され、キャッシュで更新されます。 |
本記事では、「完全更新モード」を利用する方式について説明します。
検証環境
PostgreSQLをデータソースするビューorderDetails
にキャッシュ設定を行います。
データソース
データソースとして外部のPostgreSQLデータベースに存在する以下3種類のテーブルをdemo_postgres
としてTDVに追加します。
- orders
- products
- stores
orders
products
stores
orderDetailsビュー
キャッシュターゲットデータソース追加
キャッシュターゲットとして利用する外部データベースをデータソースとして追加します。
実際にデータがロードされるテーブルは、後続の操作の過程でTDVにより作成されるため、この「キャッシュターゲットデータソース追加」の目的は、データロード先となるテーブルを所有するスキーマをTDVとして認識することです。
したがって、キャッシュデータを外部データベースのどのスキーマに格納していきたいかは事前に決めておく必要があります。また、そのスキーマも事前に作成しておく必要があります。
以下の例では、EXTERNAL_DB_TARGET
というスキーマのメタデータを取り込んでいます。
イントロスペクト時の注意点として、取り込みたいスキーマにテーブルを1件も存在しない場合は、イントロスペクトの対象とならないため、イントロスペクト時には最低1件以上のテーブルがそのスキーマに存在している必要があります。
以下の例では、「DUMMY」というテーブルを事前に作成した状態でイントロスペクトしています。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
キャッシュのステータステーブルおよび追跡テーブルの作成
先ほど追加した、キャッシュターゲットとして利用する外部データベースをデータソースに、キャッシュのステータステーブルと追跡テーブルを以下の手順で作成します。
ステータステーブル
1. キャッシュターゲットデータソースを開き、ステータステーブル欄右の 参照… ボタンをクリックします。
2. 次のキャッシュテーブルを選択 ステータステーブルウィンドウが表示されるので、ステータステーブル作成先のスキーマを選択します。
スキーマを選択すると、テーブル名cache_status
が自動で入力されていることを確認し、作成ボタンをクリックします。
Aurora MySQLではスキーマが存在しないため、データソースを選択します。
3. 作成ボタンをクリックすると、次のDDL: ステータステーブルというウィンドウにSQLコマンドが表示されるので、実行をクリックします。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
4. ステータステーブルが正常に作成され、「DDLは正常に実行されました」と表示されることを確認します。
追跡テーブル
次に、追跡テーブルもステータステーブルと同様の手順で作成します。
1. 追跡テーブル欄右の参照…ボタンをクリックします。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
2. 次のキャッシュテーブルを選択 追跡ステーブルウィンドウが表示されるので、追跡ステーブル作成先のスキーマを選択します。
スキーマを選択すると、テーブル名cache_tracking
が自動で入力されていることを確認し、作成ボタンをクリックします。
Aurora MySQLではスキーマが存在しないため、データソースを選択します。
3. 作成ボタンをクリックすると、次のDDL: 追跡ステーブルというウィンドウにSQLコマンドが表示されるので、実行をクリックします。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
4. 追跡テーブルが正常に作成され、「DDLは正常に実行されました」と表示されることを確認します。
この時点で、TDVのリソースツリー上でも、ステータステーブルと追跡テーブルが作成されたことを確認できます。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
キャッシュの有効化
以下の手順でキャッシュを有効化します。
1. orderDetails
ビューを開き、キャッシュタブにてキャッシュの作成ボタンをクリックします。
2. 以下のとおり設定し、キャッシュテーブルの作成ボタンをクリックします。
- ステータスの有効に✓を入れる
- ストレージのデフォルトのキャッシュデータベースを使用の✓を外し、複数テーブルを選択する
- ストレージのデータソースにキャッシュターゲットとして利用するデータソースを指定する
-
複数テーブルキャッシュのテーブルの以下を入力
-
テーブルカタログ(オプション)
- カタログの仕組みを持つデータベースを利用する場合は必要となります。
- テーブルスキーマ(オプション)
- テーブルプレフィックス
- キャッシュテーブルの数
-
テーブルカタログ(オプション)
- 詳細の完全更新モードを選択する(注:下図には表示されていません)
本記事では、複数テーブルを利用します。
Aurora PostgreSQLでは以下のように設定します。
Aurora MySQLでは以下のように設定します。
3. 「キャッシュテーブルの作成」ボタンをクリックすると、DDL: キャッシュというウィンドウにSQLコマンドが表示されますので実行をクリックします。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
4. テーブルが正常に作成され、「DDLは正常に実行されました」と表示されることを確認します。
5. ビューを保存すると、ステータスが NOT LOADED となることを確認します。
これは、まだ外部キャッシュデータベースにデータがロードされていないことを意味しています。
この時点で、リソースツリー上のビューにキャッシュが有効化されたことを示すアイコンがつきます。
自動生成されたキャッシュテーブルも確認することができます。
Aurora PostgreSQLでは以下のように表示されます。
Aurora MySQLでは以下のように表示されます。
キャッシュの初回ロード
以下の手順でキャッシュテーブルに対してデータを初回ロードします。
1. 更新モードの今すぐ更新ボタンをクリックし、キャッシュをリフレッシュします。
2. ダイアログが表示されるのでOKボタンをクリックします。
3. 正常にデータがキャッシュテーブルにロードされれば、ステータスが UP になります。
4. ビューを実行し、これまでと同じようにデータが取得できることを確認します。
クエリを実行すると、外部キャッシュデータベースからデータが取得されるようになり、実際のデータソースである demo_postgres データソースに対してクエリが実行されることはありません。
demo_postgres データソースに対してクエリが実行されるのは、キャッシュをリフレッシュするときのみとなります。
また、リネージュは以下のようになります。
キャッシュのリフレッシュ - INSERT
データソースに新規レコードが追加された後に、キャッシュをリフレッシュし、デフォルトキャッシュテーブル内のデータにもレコード追加が反映されることを確認します。
データソースに新規レコードを追加する前の状態が、データソースにて示した状態であることを前提とします。
データソースのorders
テーブルに新規レコードを以下のように追加します。
しかし、この時点でorderDetails
ビューを実行しても以下のとおりレコード追加は反映されていません。
キャッシュを最新化するために、以下の手順でキャッシュテーブルに対してキャッシュをリフレッシュします。
1. 更新モードの今すぐ更新ボタンをクリックし、キャッシュをリフレッシュします。
2. ダイアログが表示されるのでOKボタンをクリックします。
3. 正常にキャッシュがリフレッシュされ、ステータスが UP となっていることを確認します。
4. 再度、orderDetails
ビューを実行し、レコード追加が反映されていることを確認します。
キャッシュのリフレッシュ - INSERT/UPDATE/DELETE
データソース(PostgreSQL)に対して、INSERT/UPDATE/DELETEが実行された後にキャッシュをリフレッシュし、デフォルトキャッシュテーブル内のデータにも変更が反映されることを確認します。
データソースに変更をかける前の状態が、データソース にて示した状態であることを前提とします。
データソースのorders
、products
、stores
テーブルに対し以下のような変更を加えます。
orders
products
stores
しかし、この時点でorderDetails
ビューを実行しても以下のとおりレコード変更は反映されていません。
キャッシュを最新化するために、以下の手順でキャッシュテーブルに対してキャッシュをリフレッシュします。
1. 更新モードの今すぐ更新ボタンをクリックし、キャッシュをリフレッシュします。
2. ダイアログが表示されるのでOKボタンをクリックします。
3. 正常にキャッシュがリフレッシュされ、ステータスが UP となっていることを確認します。
4. 再度、orderDetails
ビューを実行し、レコード追加が反映されていることを確認します。