キャッシュデータベース固有の情報

ここでは、キャッシュデータの保存に使用するデータベースに応じて考慮する必要がある情報について説明します。

Amazon Athena

Athena を使用してキャッシュデータを保存する場合、以下の点を考慮してください。

  • Amazon Athena をキャッシュデータベースとして使用するには、 データ一括読み込み を有効にしてデータを S3 にアップロードする必要があります。

  • [Read & Write] タブで [Use bulk data load APIs] をチェックして、[Authentication type]、[AWS access key id]、[AWS secret access key]、[AWS IAM role ARN] (オプション)、および [S3 Location] の各フィールドに値を入力します。これを行わないと、Virtual DataPort はデータをキャッシュできません。

  • [AWS IAM role ARN] は、ユーザーが引き受ける IAM ロールの Amazon リソースネームであり、オプションのフィールドです。このロールは、AWS S3 バケットの管理に必要な権限を付与します。この値の形式は arn:aws:iam::<awsAccountId>:role/<roleName> です。

  • Athena をキャッシュデータベースとして使用する場合、ビューでは Full キャッシュモードのみを有効にすることができます。 Partial キャッシュ を有効にした場合、データはキャッシュされません。

Azure SQL Data Warehouse

Azure SQL Data Warehouse データソースをキャッシュとして使用する場合、制限事項がいくつかあります。

  • Azure SQL Data Warehouse はテーブルの一意のインデックスをサポートしません。

  • データ移動とマテリアライズドテーブルの作成をトランザクション内で行うことはできません。

  • バイナリおよび複合型の列 (配列およびレジスター) は、8,000 バイトに制限されます。キャッシュロードプロセスの実行中にこのサイズを超えた場合、プロセスは「String または binary データは切り詰められました。」というエラーで終了します。

  • 「読み取りのコミット解除」が使用可能な唯一の分離レベルです。

キャッシュの構成の [Driver class path] ボックスで [mssql-jdbc-7.x] が選択されていることを確認してください。選択されていない場合、いくつかの機能が正常に動作しない可能性があります。

Presto

Presto を使用してキャッシュデータを保存する場合、以下の点を考慮してください。

  • Presto を使用できるのは、データが Hadoop Distributed File System (HDFS) に保存されている場合のみです。

  • [Read & Write] タブで [Use bulk data load APIs] をチェックして、[HDFS URI] および [Hadoop executable location] の各フィールドに値を入力します。これを行わないと、Virtual DataPort はデータをキャッシュできません。

  • Presto を使用してキャッシュデータを保存する場合、ビューのキャッシュモードとして [Partial] を選択しないでください。これを選択した場合、データはキャッシュされません。

  • Virtual DataPort は、管理されていない (外部) Hive テーブルを使用して Presto にデータを転送します。外部テーブルを使用する場合、データファイルのアップロード用に構成された URI が、キャッシュまたはデータ移動に使用されるスキーマの場所とは異なる可能性があります。Presto の hive.non-managed-table-writes-enabled 構成プロパティが true であることを確認してください。それ以外の値の場合、Presto へのデータ保存プロセスは失敗します。旧バージョンの Denodo の動作 (つまり外部テーブルを使用しない動作) に戻すには、以下を実行します。

    SET 'com.denodo.vdb.util.tablemanagement.sql.PrestoTableManager.useExternalTables'='false';
    

    この変更を適用するために再起動は不要です。

Spark

キャッシュの無効化プロセスの実行中には、Parquet ファイルの変更中に実行された一部のクエリは失敗する可能性があります。

Yellowbrick

Yellowbrick は、そのデータベースのエンコードタイプとして LATIN9 (デフォルト) と UTF-8 の 2 つをサポートしています。Virtual DataPort で完全にサポートできるのは、 UTF-8 エンコードを使用するデータベースのみ であることに注意してください。データベースを作成する際に encoding = UTF-8 を指定することによって、データベースのエンコードを選択できます。

LATIN9 でエンコードされたデータベースをキャッシュデータベースとして使用する場合、他のデータソースからデータをキャッシュする際に、無効な文字を使用するデータが失われる可能性があります。

HDFS ストレージを使用するデータベース

HDFS ストレージを使用するデータベース (Hive、Impala、Presto、Spark、および Databricks) は、Full キャッシュモードのみをサポートします。Partial キャッシュを使用するビューは無視され、キャッシュが存在しないかのように動作します。

一時ファイルは、 snappy 圧縮方式で生成されます。Parquet ファイルの圧縮方式を変更する場合、VQL シェルから次のコマンドを実行します。

SET 'com.denodo.vdb.util.tablemanagement.sql.insertion.HdfsInsertWorker.parquet.compression'
    = '<compression mechanism>';

「<compression mechanism>」の値として、 off (圧縮なし)、 snappygzip 、または lzo を指定できます。

このプロパティを変更した後で再起動は不要です。

選択した圧縮アルゴリズムがデータベースでサポートされている必要があります。

これらのファイルを圧縮して生成することにより、ビューのキャッシュロードプロセスまたはデータ移動が高速化される可能性があります。ただし、データベースが Denodo サーバーと同じローカルエリアネットワーク内にある場合は、転送速度が高速であるため、高速化されない可能性があります。高速化されないにもかかわらず Denodo サーバーは圧縮ファイルを生成しなければならないため、CPU 使用率が増加する可能性があります。

さらに、これらのデータベースでは Full キャッシュ の無効化のみがサポートされます。