キャッシュの構成

Virtual DataPort には、データソースから取得したデータのローカルコピーを JDBC データベースに格納する キャッシュ モジュール というシステムが組み込まれています。

ここでは、サーバーのキャッシュエンジンを有効にする方法について説明します。この機能を有効にした後に、データをキャッシュするビューごとにキャッシュを構成する必要があります (この構成方法については「 ビューのキャッシュの構成 」を参照)。

キャッシュの動作の仕組みの詳細については、「 キャッシュモジュール 」を参照してください。

サーバーのキャッシュを有効にするには、メニュー [Server configuration] > [Administration] をクリックしてから [Cache] タブをクリックします。

このダイアログは、以下の 3 つのタブに分かれています。

[General Settings] タブ

  • キャッシュエンジンを有効にするには [Cache status on] を選択します。

  • Maintenance Period (seconds): Virtual DataPort サーバーで キャッシュメンテナンスタスク を実行する頻度を指定します。このタスクは、無効なエントリまたは期限切れのエントリをキャッシュデータベースから削除します。

    このパラメータと [Time to Live (seconds)] (有効時間) との違いは、エントリがキャッシュデータベースから削除されるかどうかという点にあります。キャッシュのエントリは有効時間になると期限切れになりますが、データベースからは削除されず、キャッシュからデータを取得する際に無視されるにすぎません。

    [Maintenance Period (seconds)] には、[Time to Live (seconds)] よりも大きい値を指定する必要があります。期限切れのエントリをキャッシュから削除する処理は、それを無視する処理よりも負荷が高いからです。

    キャッシュメンテナンスタスクを定期的に実行しないようにするには、[Maintenance] で [Off] を選択します。

    注釈

    本番環境では、[Maintenance] オプションを [Off] に設定して、定期的なキャッシュメンテナンスタスクを実行しないようにすることが強く推奨されます。代わりに、Denodo Scheduler を使用して、サーバーとキャッシュデータベースの負荷が高くないと予想される期間に CLEAN_CACHE_DATABASE プロシージャが実行されるように設定します。

    キャッシュメンテナンスタスクの処理内容については、「 キャッシュメンテナンスタスク 」で説明します。

  • Default Time to Live for views (seconds): キャッシュが有効なビューのデフォルトの有効時間。

    [Never expire] を選択すると、ビューのキャッシュ構成で別途指定していない限り、キャッシュのエントリは期限切れになりません。

  • 組み込みの Derby データベースにキャッシュを格納する場合、[Embedded Derby Server Configuration] をクリックすると以下のパラメータを設定できます。

    • Enable Remote Access: 外部の JDBC 対応クライアントから組み込みデータベースにアクセスできるようにします。このオプションは、監査や監視の目的で役立ちます。

    • Server port: 組み込みデータベースを実行するポートを変更できます。

  • 既存の JDBC データソースを使用してデータをキャッシュするには、[Specify an existing data source as cache] をチェックし、その下のコンボボックスを使用してデータソースを指定します。これにより、このデータソースのキャッシュデータとビューを組み合わせたクエリをすべてプッシュダウンできるようになります。

注釈

[Specify an existing data source as cache] をチェックする場合は、このデータソースに対して「パススルーセッション資格情報」を有効にすることによるセキュリティへの影響を検討する必要があります。このオプションを有効にした場合は、キャッシュデータベースに対する読み取りアクセス権限を該当のユーザーに付与する必要があります。そのアクセス権限を付与されたユーザーは、このデータベースに Denodo から接続できるだけでなく、直接接続できるようになり、Denodo で設定されている行や列に対する制限などの権限を回避できるようになります。

Cache configuration: General Settings tab

キャッシュ構成: [General Settings] タブ


[Connection] タブ

  • Database adapter: キャッシュとして使用する DBMS (データベース管理システム) のタイプを指定します。Virtual DataPort には Apache Derby データベースが組み込まれており、[Embedded Derby Server] チェックボックスをチェックすることでキャッシュデータの格納に使用できます。この場合は、他のフィールドに値を入力する必要はありません。

    この組み込みデータベースは、[Embedded Derby server configuration] をクリックすると、リモートからアクセスできるように設定できます (詳細については以下を参照)。

    アダプターとして [Generic] を選択すると、追加の構成手順が必要になる場合があります (詳細については、「 他のデータベースの汎用サポート 」を参照)。

  • Driver classpath: アダプターとして [Generic] を選択した場合を除き、デフォルト設定のままとします。

    このダイアログのパラメータをすべて入力したら、[Test connection] をクリックします。「 The Denodo Platform does not include the JDBC driver for this adapter 」のようなメッセージが表示された場合、メニュー [File] > [Extensions management] のウィザードから、JDBC ドライバーの jar ファイルを Virtual DataPort にアップロードする必要があります。その手順については、「 JDBC ドライバーのインポート 」で説明します。

  • Driver class: アダプターとして [Generic] を選択した場合を除き、デフォルト設定のままとします。これは、JDBC ドライバーの Java クラス名です。たとえば、MySQL データベースの場合、この値は com.mysql.jdbc.Driver になります。

  • Database Uri: キャッシュとして使用するデータベースの URI。

  • Transaction isolation: キャッシュのデータベースで実行するトランザクションとクエリの分離レベル。選択可能なオプションを以下に示します。

    • Database default: データベースのデフォルトの分離レベルが使用されます。

    • Read uncommitted: コミットされていないデータをトランザクションで読み取ることができます (ダーティリード)。

      たとえば、トランザクション A で行をビューに挿入し、トランザクション B でその新しい行を読み取った後、トランザクション A で挿入をロールバックできます。

    • Read committed: トランザクションが終了するまで、データベースでは書き込みロックを維持します。したがって、トランザクションで読み取ることができるデータはコミット済みのものに制限され、ダーティリードは実行できません。

      ただし、 SELECT 操作が終了すると、データベースではただちに読み取りロックが解除されるので、同じトランザクションで同じ SELECT クエリを繰り返すたびに異なる結果が得られることがあります (ノンリピータブルリード)。

      たとえば、ある行をトランザクション A で読み取り、トランザクション B でその行を変更したとします。トランザクション A でもう一度その行を読み取ると、前と異なる値が取得されます。

    • Repeatable read: トランザクション終了までデータベースによって読み取りロックと書き込みロックが維持されます。したがって、この分離レベルでは、ダーティリードとノンリピータブルリードが回避されます。ただし、ファントムリードは回避されません。あるトランザクションで条件を使用して一定範囲の行に対してクエリを実行すると同時に、別のトランザクションで同じ範囲に行を挿入できる場合に、この問題が発生します。

    • Serializable: 最上位の分離レベル。一定範囲の行またはテーブル全体をロックすることによって、ダーティリード、ノンリピータブルリード、およびファントムリードが回避されます。

  • Authentication: 以下のオプションがあります。

    • Use login and password: ユーザーが入力したログインとパスワード情報を使用してキャッシュデータベースに接続します。

    • Use Kerberos: Kerberos 認証を使用してキャッシュデータベースに接続します。「 Kerberos 認証による JDBC ソースへの接続 」では、キャッシュの構成にも該当する情報を取り上げています。

    • Use AWS IAM Credentials: ユーザーが入力した AWS IAM 資格情報を使用してキャッシュデータベースに接続します。この認証タイプは、Amazon Athena および Amazon Redshift でのみ使用できます。「 JDBC ソースのインポート 」では、キャッシュの構成にも該当する情報を取り上げています。

    • 資格情報保管場所 (Credentials vault): この認証では 資格情報保管方法 から資格情報を取得してデータベースに接続します。また、選択した認証方法を使用します (ログイン/パスワード、Kerberos、AWS IAM 資格情報)。以下の 2 つの構成が利用できます。

      • Single secret: 使用する 資格情報保管方法 が、シングルシークレットで資格情報を保管する場合 (例: CyberArkAWS Secrets Manager)。この構成を選択する場合、資格情報保管方法に保管されている、該当するアカウントの アカウント名 を入力してください。

      • One secret per field: 使用する 資格情報保管方法 が各資格情報を異なるシークレットに保管する場合 (例: Azure Key Vault)。この構成を選択する場合、各フィールドの値が 資格情報保管方法 から取得した値かどうかを示した上で、状況に応じてシークレット名または値を指定します。

        • From vault: 資格情報保管方法 から取得するフィールドである場合はチェックします。チェックする場合、資格情報保管方法に保管されている、該当するフィールドのシークレット名を入力してください。

    このユーザーアカウントには、テーブルとインデックスを作成・削除する権限と、INSERT、UPDATE、DELETE リクエストを実行する権限が必要です。

  • キャッシュデータベースへのアクセスに使用するコネクションプールのパラメータを設定するには [Connection Pool configuration] をクリックします (「 JDBC ソースのインポート 」を参照)。

  • データベースとのコネクションを確立するときに引数として使用するプロパティを追加するには [Driver properties] をクリックします。

  • [Test Connection] をクリックして、指定した設定で Virtual DataPort サーバーからこのデータベースに接続できることを確認します。

Cache configuration: Connection tab

キャッシュ構成: [Connection] タブ


[Read & Write] タブ

  • Fetch size (rows): 多くの行をキャッシュデータベースからフェッチする必要がある場合に、このオプションは、その行数に関するヒントを JDBC ドライバーに示します。

  • Stream tuples (アダプターとして [MySQL] を選択している場合のみ): チェックしている場合、キャッシュデータを取得するクエリを Virtual DataPort サーバーからデータベースで実行すると、その結果が MySQL から一度に 1 行ずつストリーミングされます。チェックしていない場合は、クエリが終了するまで MySQL からクエリ結果が得られません。

    大きなデータセットが返されるクエリ結果を格納してキャッシュから取得するとき、そのデータセットが Virtual DataPort サーバーの Java 仮想マシンのヒープ領域に収まらない可能性がある場合は、このチェックボックスをチェックします。そのような状況ではない場合は、このチェックボックスのチェックをはずします。実行時間が短くなることが考えられるからです。

  • Ignore trailing spaces: このオプションをチェックすると、このデータソースのビューから返される結果のうち、 text 型の値の末尾にある空白文字が Virtual DataPort サーバーによって削除されます。

  • Use external tables for data movement (アダプターとして [Netezza] を選択している場合のみ): チェックしている場合、キャッシュエンジンで Netezza からデータを読み取り、[Use Bulk Data Load APIs] オプションが指定された別の Netezza データベースにそのデータを挿入する際に、その Netezza の「外部テーブル」機能が使用されます。データ移動の最適化の詳細については、「 データ移動 」を参照してください。

  • Batch insert size (rows): キャッシュエンジンでデータをキャッシュする場合、キャッシュに格納する行ごとにキャッシュデータベースで INSERT ステートメントが実行されます。キャッシュにデータを格納するプロセスを高速化するために、これらの INSERT ステートメントはバッチ単位で実行されます。

    この値には、1 つのバッチあたりの INSERT クエリの数を設定します。

  • UTF-8 data types: ビューのキャッシュを有効にすると、そのビューのキャッシュデータを格納するテーブルがキャッシュデータベースに作成されます。このチェックボックスをチェックしたことまたはチェックをはずしたことによる影響は、このビューにある各フィールドの型とサブタイプによって異なります。

    • サブタイプが定義されているフィールドの場合、Virtual DataPort サーバーによってキャッシュテーブルにそのフィールドが定義されるときに、そのサブタイプが使用されます。たとえば、テキストフィールドのサブタイプが VARCHAR で、そのサイズが 200 の場合、そのフィールドは VARCHAR(200) として定義されます。

    • サブタイプが定義されていないフィールドの場合、以下のようになります。

      • フィールドの型が テキストではない 場合、それらを格納するデータ型は、このチェックボックスをチェックしているかどうかに関係なく、必ず同じです。キャッシュに使用するデータベースに応じて適切な型が使用されます。

      • サブタイプが定義されていないテキスト型フィールドの場合は、以下のどちらかになります。

        1. [UTF-8 data types] を チェックしている 場合、Virtual DataPort サーバーは、キャッシュテーブルにフィールドを定義する際に、すべての UTF-8 文字を格納できるデータ型を使用します。これらのデータ型は、標準のテキストデータ型よりもデータベースで多くの領域を使用します。

        2. [UTF-8 data types] を チェックしていない 場合、フィールドは VARCHAR として定義されます。

    フィールドにサブタイプが定義されているかどうかは、ビューの [Summary] タブで [Field type] 列のヒントに表示されます。フィールド型 (int、text、date など) のみが表示される場合、サブタイプは定義されていません。ヒントに [Source type properties] ラベルも表示される場合、フィールドのサブタイプが定義されています。

    すべての UTF-8 文字を格納できるデータ型は、データベースでより多くのディスク領域を使用します。

  • Use Bulk Data Load APIs (一部のデータベースアダプターの場合のみ): このオプションをチェックすると、キャッシュデータベースがデータ移動のターゲットになる場合、Virtual DataPort では、 INSERT ステートメントを実行するのではなく、データベースのネイティブな API を使用してデータをデータベースに読み込みます。

    Virtual DataPort によるこれらの API の使用については、「 データ一括読み込み 」を参照してください。

  • Specify custom catalog and schema: デフォルトではないカタログとスキーマ (あるいはそのいずれか) にキャッシュのテーブルとインデックスを作成する場合は、このオプションをチェックします。つづいて、 image0 をクリックしてカタログとスキーマのリストをデータベースから取得し、カタログとスキーマを選択します。

    データベースによっては、カタログのみまたはスキーマのみが存在していて他方がないことがあり、その場合はそれぞれ スキーマ または カタログ のリストが無効になっています。

  • Query optimization settings (一部のデータベースアダプターの場合にのみ使用可能): 以下に示すオプションでは、Virtual DataPort サーバーで、他のデータソースから取得したデータをクエリオプティマイザーがキャッシュデータベースに挿入できるようにするかどうかを制御します。このように挿入することにより、より多くの操作を、ローカルで実行するのではなく、このデータベースにプッシュできるようになります。

    • Do not allow Denodo to create temporary tables in the data source for query optimization: クエリオプティマイザーは、クエリを実行するためにキャッシュデータベースにデータを移動しません。

    • Allow creating temporary tables, only for the data movement optimization: このオプションを選択すると、クエリオプティマイザーでは、 データ移動 先としてキャッシュデータベースを選択できます。

    • Allow creating temporary tables to allow parallel processing of any operation (一部の並列データベースの場合のみ): このオプションを選択すると、クエリオプティマイザーでは、データ移動先としてキャッシュデータベースを選択できます。また、 大規模な並列処理 をこのデータベースにプッシュダウンするために、データを格納する一時テーブルを作成できます。このオプションを選択する場合は以下の点を確認します。

      1. Virtual DataPort サーバーとデータベース間でデータを高速に転送できるよう、両システムを同じネットワークセグメントに置いていること。

      2. できる限り高速でデータがこのデータベースに挿入されるように、このデータソースに対して [Use bulk data load APIs] チェックボックスをチェックしていること。

Cache configuration: Read & Write tab

キャッシュ構成: [Read & Write] タブ

Virtual DataPort で初めて外部 DBMS を使用してキャッシュデータを格納するとき、必要なテーブルとインデックスが自動的に生成されます。

Virtual DataPort サーバーの再起動が必要になるキャッシュ DBMS の変更を除き、どのような構成変更もただちに有効になります。

デフォルトでは、ビューのデータはキャッシュに格納されません。したがって、キャッシュモジュールを有効にした後、キャッシュを必要とするビューでキャッシュオプションを有効にする必要もあります。この設定方法については、「 ビューのキャッシュの構成 」を参照してください。

注釈

外部データベースを使用してキャッシュデータを格納する場合は、Virtual DataPort サーバーを起動する前に、その外部データベースを起動しておく必要があります。

デフォルトでは、すべての Virtual DataPort データベースでキャッシュ構成は同じになっています。ただし、特定のデータベースのキャッシュ構成を個別に変更することはできます。この変更は、そのデータベース内部で作成したエレメントに反映されます。特定のデータベースのキャッシュを構成する方法については、「 データベースの構成および削除 」を参照してください。

キャッシュのエントリは「有効時間」が経過すると無効になりますが、特定のビューのキャッシュを手動で無効にすること (「 ビューのキャッシュの構成 」を参照) や、複数のビューのキャッシュを手動で無効にすること (「 キャッシュの無効化 」を参照) もできます。