外部データベースへのメタデータの保存¶
Virtual DataPort の カタログ は、設定と、ユーザーが作成したメタデータ (データソース、ビュー、Web サービス、ユーザー、ロールなど) で構成されます。デフォルトでは、Virtual DataPort に組み込まれている Apache Derby データベースが カタログ で使用されます。
注釈
この機能をすべての環境で利用することはお勧めしません。 後述の考慮事項 を確認してください。
組み込みのデータベースではなく、外部データベースを使用するようにカタログを構成できます。それには、以下のようなメリットがあります。
自動レプリケーション: クラスタの Virtual DataPort サーバーが同じ外部データベースを共有する場合、変更を実行する必要があるのは 1 つのサーバーのみです。変更は他のサーバーに自動的に伝播されます。自動レプリケーションを使用しない場合は、クラスタのサーバーごとに同じ変更を行う必要があります。
このシナリオでは、クラスタのすべてのサーバーが「マスターノード」です。つまり、いずれかの Virtual DataPort がシャットダウンしても、他のサーバーは中断せずに引き続き機能します。
バックアップ: この外部データベースの管理者が、このデータベースを定期的にバックアップしている場合、Virtual DataPort のメタデータもバックアップされます。この機能は、クラスタがない場合でも有益です。
この機能は、エレメント内の変更が制御された方法で行われない環境で使用するものです。つまり、通常は以下のような、ユーザーがビューや Web サービスなどをいつでも作成したり変更したりすることのできる環境で使用します。
開発環境: 開発者がデータソース、ビュー、Web サービスなどを作成します。
サンドボックス環境: これらの環境には、通常、本番環境のサーバーと同じビューがありますが、ユーザー (データ科学者など) が追加のビューを作成して分析を実行します。
この機能を使用すると、同じ外部データベースを共有する Virtual DataPort サーバーのクラスタを設定することで、この種の環境のキャパシティ (つまり同時リクエスト数) を増やすことができます。
制御された方法で変更を行わなければならない環境 (つまりステージング環境と本番環境) では、この機能を有効にすることはお勧めしません。代わりに Solution Manager を使用して、変更を開発環境からステージングおよび本番環境に昇格することをお勧めします。その理由は以下のとおりです。
この機能が有効になっていると、クラスタの各サーバーに変更を昇格する Solution Manager の機能をダウンタイムなしで使用できません。これは、この機能が有効になっている場合、1 つのサーバーのエレメントに対する変更が、クラスタのその他のサーバーに直ちに反映されるためです。これにより、一連のビューが他のビューに置き換えられた場合、クライアントアプリケーションがプロモーション中に本番サーバーにアクセスする可能性があります。
この機能によりクエリにわずかなオーバーヘッドが追加されます。このオーバーヘッドは数分または数時間続く分析クエリには関係ありませんが、ミリ秒で完了することが期待される操作クエリでは問題になる可能性があります。
Virtual DataPort は以下のオブジェクトを複製します。
Administration Tool または Design Studio から作成できるすべてのオブジェクト: データソース、ビュー、サマリ、リモートテーブル、アソシエーション、Web サービス、JMS リスナー、ストアドプロシージャ、データベース
ユーザー、ロール、付与された権限、列権限、行の制限、カスタムポリシー (jar 拡張機能を含む)。
リソース: つまりダイアログ [Extension management] からアップロードされたか、コマンド
CREATE JAR
またはCREATE RESOURCE
で作成された、すべてのエレメント。Administration Tool、Design Studio、コマンド「 SET 」のいずれかを使用して変更できるすべての設定。ただし、Virtual DataPort での SSL の有効化に関する設定は除きます。
レプリケーションプロセス¶
このセクションでは、サーバーでカタログの変更 (ユーザーによるビューの作成など) がいつどのように行われるか、同じデータベースを共有する他のサーバーがこの変更をいつどのように認識するかについて説明します。
Virtual DataPort のカタログには、オブジェクトが一時的に保存されるメモリ内キャッシュ (データソースから取得したビューのデータを保存する キャッシュモジュール では ない) があります。このメモリ内キャッシュの目的は、毎回オブジェクト (データソース、ビューなど) をデータベースから読み込むよりも迅速にオブジェクトにアクセスできるようにすることです。Virtual DataPort が開始されるとき、このキャッシュは空であり、オブジェクトが初めてアクセスされたときに (つまり、クエリで使用されたり、Administration Tool から開かれたりしたときなど)、カタログがこのオブジェクトをメモリ内キャッシュに保存します。後からオブジェクトが変更されると (データソースの構成が変更されるなど)、カタログがこのキャッシュを更新します。
カタログは、デフォルトで、ローカルデータベース Apache Derby (デフォルトオプション) を使用します。この場合、メモリ内キャッシュを変更できるのはローカルサーバーだけであるため、メモリ内キャッシュは必ず更新されます。
カタログは外部データベースを使用する場合、このメモリ内キャッシュも使用します。ただしカタログは、このキャッシュから取得されたオブジェクトが最新であることを確認する必要があります。これは、カタログがオブジェクトをデータベースから読み取りキャッシュに保存してから、別のサーバーがそのオブジェクトを変更していた可能性があるためです。カタログは、オブジェクトが最新であることを確認するために、別のコンポーネントがオブジェクトを読み取るときに以下の手順を実行します。
メモリ内キャッシュにオブジェクトが 含まれていない 場合、カタログは外部データベースからそのオブジェクトを読み取り、メモリ内キャッシュに保存します。
メモリ内キャッシュにすでにオブジェクトが含まれている場合、カタログは外部データベースでクエリを実行し、このオブジェクトが、読み取られてからデータベース内で変更されていないかどうかを検証します。オブジェクトの期限が切れている場合は、カタログは再度オブジェクトを読み取り、キャッシュを更新します。
Web サービスについては、その Web サービスがデプロイされているかどうかに関わらず、Web サービスの構成とステータスが外部データベースに保存されます。Virtual DataPort は、外部データベースを使用するように構成されている場合、各 Web サービスがデータベースでデプロイ済み/アンデプロイのいずれにマークされているかを毎分確認します。サーバー内で Web サービスのステータスが異なる場合、サーバーは Web サービスを、それぞれデプロイまたはアンデプロイします。たとえば、サーバー #1 が Web サービス「customer」をデプロイする場合、サーバーは Web サービスのステータスがデプロイ済みであるデータベースに Web サービスを保存します。サーバー #2 が Web サービスのステータスをチェックしたときに、その Web サービスがまだデプロイされていないと、サーバーは「customer」をデプロイします。
同じことが JMS リスナーにも適用されます。1 つのサーバー上で JMS リスナーを 1 分間で開始または停止すると、他の Virtual DataPort サーバーがその JMS リスナーをそれぞれ開始または停止します。
競合の回避¶
Virtual DataPort は、外部データベース内でオブジェクトを保存、変更、または削除するとき、変更するテーブルの行をロックします。これにより、異なる Virtual DataPort サーバーに接続している 2 人のユーザーが同じオブジェクト (同じビューなど) を同時に作成、変更、または削除するときに、競合状態が発生するのを回避できます。
2 人のユーザーが同じ名前の同じタイプのエレメントを作成しようとすると、どちらかのユーザーに、同じ名前のエレメントがすでに存在することを示すエラーが表示されます。
2 人のユーザーが同じエレメントを同時に変更しようとすると、2 番目の変更によって最初の変更が上書きされます。
2 人のユーザーが同じエレメントを同時に削除しようとすると、どちらかのユーザーに、エレメントが存在しないことを示すエラーが表示されます。
サポート対象のデータベース¶
Virtual DataPort では、以下のデータベースにカタログを保存できます。
Amazon Aurora MySQL
Amazon Aurora PostgreSQL
IBM DB2 10 および 11
Microsoft SQL Server 2012、2014、2016、2017、および Azure SQL
MySQL 5
Oracle 11g、Oracle 12c、Oracle 18c、Oracle 19c
PostgreSQL 9、10、11、12
MySQL を使用するには、パラメータ --max-allowed-packet=500M
を指定して MySQL サーバーを起動し、Virtual DataPort に保存されたリソースを MySQL が受信して転送できることを確認します。このパラメータの設定方法については、「 documentation of MySQL 」を参照してください。
この機能に関する考慮事項¶
この機能を有効にする前に、次のことを考慮してください。
この機能を使用するには、カタログのデータベースを Virtual DataPort サーバーの「可能な限り近くに」配置する必要があります。つまりデータベースが同じネットワーク内に配置されているか、少なくとも、サーバーと同じデータセンターに配置されている必要があります。この条件が満たされていると、カタログの外部データベースを使用する際のオーバーヘッドが最小限に抑えられます。それ以外の場合は、クエリの実行に多少の遅延が発生する可能性があります。
同じ外部データベースを共有する Virtual DataPort サーバーには、Denodo Platform の同じ更新がインストールされている必要があります。これは、ある Virtual DataPort サーバーで保存したメタデータを、それよりも古い更新がインストールされている Virtual DataPort で読み取れない場合があるためです。そのため、異なる更新がインストールされている Virtual DataPort サーバー間で同じデータベースを共有している場合、その構成はサポートされません。
Virtual DataPort から外部データベースへの通信は安定している必要があります。ネットワークの問題などが原因で外部データベースとの通信が不可能になることがあった場合、外部エンジンは通信が再確立されるまでクエリの処理を開始できません。
制御された方法で変更を行わなければならない環境 (つまりステージング環境と本番環境) では、この機能を有効にすることはお勧めしません。代わりに Solution Manager を使用して、変更を開発環境からステージングおよび本番環境に昇格することをお勧めします。
Virtual DataPort が開始され、カタログの構成が変更されたことが検出された場合 (管理者がカタログを保存するためにデータベースを変更したなど)、ファイル
<DENODO_HOME>/conf/vdp/VDBConfiguration.properties
が<DENODO_HOME>/setup/vdp/templates/conf/VDBConfiguration.template
に置き換えられます。このファイルは、Virtual DataPort が再起動するたびにではなく、この構成の変更後に Virtual DataPort が開始されたときにのみ置き換えられます。外部データベースを使用するようにカタログを構成する場合、このデータベースに接続するために必要な JDBC ドライバーを除き、メタデータは転送されません。このドライバーが Denodo に含まれて いない 場合、[Metadata database configuration] ダイアログで [OK] をクリックすると、Virtual DataPort では以下を実行します。
ドライバーがすでに新しいデータベースに保存されている場合、ドライバーは現在のデータベース (ローカルの Derby など) に保存されているドライバーと新しいデータベースに保存されているドライバーの MD5 ハッシュ値を計算します。MD5 値が異なる場合、Virtual DataPort は、新しいデータベース内のドライバーを現在のデータベース内のドライバーに置き換えます。
新しいデータベースにドライバーが保存されていない場合は、ドライバーを保存します。
外部データベースを使用する場合、構成プロパティを変更するために、ファイル
<DENODO_HOME>/conf/vdp/VDBConfiguration.properties
を変更 しない でください。代わりにコマンド SET を使用してプロパティを変更してください。これにより、コマンドを実行するサーバーの構成プロパティが変更され、同じデータベースを共有する他のサーバーに変更が伝播されます。Denodo サーバーのクラスタが存在する状況で、アプリケーションが ENTER SINGLE USER MODE コマンドを実行すると、このコマンドを受信した Denodo サーバーだけがシングルユーザーモードに切り替わります。それ以外のサーバーはそのまま稼働を続けます。この動作は、Virtual DataPort が外部データベースにメタデータを保存しているかどうかに関係なく発生します。
外部データベースを使用する場合、Denodo Platform に組み込んだ Apache Derby データベースを、キャッシュデータベースとして使用することはできません。
外部データベースにメタデータを保存するように Virtual DataPort を構成する方法¶
ここでは、外部データベースを使用するように Virtual DataPort のカタログを構成する方法について説明します。
構成を変更する前に、以下について検討してください。
Virtual DataPort はデータベース間で (組み込みの Apache Derby からも) メタデータを転送しません。したがって、このプロセスを実行するときは、構成も含め、メタデータを再作成する必要があります。
SSL を再度有効にする必要があります。
データベースの管理者は、以下の権限を持つ、この外部データベースのユーザーアカウントを作成する必要があります。
CREATE/DROP/ALTER TABLE、およびそれらのテーブルの INDEXES を作成する権限
自身のテーブルに対する INSERT/DELETE/UPDATE 権限
LOCK TABLE (DB2 および Oracle の場合のみ)
CREATE/DROP SEQUENCE (Oracle の場合のみ)
CREATE/DROP/REPLACE TRIGGER (Oracle の場合のみ)
その後、以下の手順に従って実施してください。
メタデータを保存する外部データベースにカタログ/スキーマを作成します。
すでにオブジェクト (ユーザー、データソース、ビューなど) を作成している場合は、すべてのメタデータをエクスポートします。つまり [File] メニュー > [Export] をクリックします。このダイアログで [Replace existing elements] を選択し、このオプションの下のすべてのチェックボックスをチェックします。
[Administration] メニュー > [Metadata database configuration] をクリックします。

外部データベースの構成¶
[Database adapter] で、使用するデータベースを選択します。[Driver class] は、デフォルト値が適切です。
[Driver class] が空の場合、ドライバーが Virtual DataPort に含まれておらず、このサーバーにアップロードされていないことが原因です。ドライバーをこのサーバーにアップロードするには、このウィンドウを閉じて、以下の手順に従います。
[File] メニュー > [Extension management] をクリックします。
このダイアログで、[Libraries]、[Import] の順にクリックします。
新しいダイアログの [Resource type] で、[jdbc] を選択します。
[Version] で、アップロードするドライバーを選択します。たとえば、IBM DB2 11 のドライバーをアップロードする場合は [db2-11] を選択します。
[Add] をクリックして、ファイルを 1 つまたは複数選択します。複数のファイルを選択するには、Ctrl キーを押しながら各ファイルを選択します。
[OK] をクリックして、ファイルを Virtual DataPort にアップロードします。
[Metadata database configuration] ダイアログに戻ります。
[Database URI]、[Login]、[Password] を入力します。
[Specify custom catalog and schema] を選択します。
重要: [Test configuration] をクリックして、接続の詳細、ユーザーの名前とパスワードが正しいこと、このアカウントがこのデータベースにテーブルを作成する権限を持っていることを確認します。
[OK] をクリックして保存します。
[OK] をクリックするとすぐに、Virtual DataPort は、カタログを保存する外部データベースにテーブルを作成しますが、再起動されるまで、これらのテーブルを使用しません。
テーブルがすでに存在している場合、テーブルは再作成 されません 。これは外部データベースを使用するように複数の Virtual DataPort を構成する場合は、この変更を加える最初のサーバーのみがそのテーブルを作成する必要があるからです。
Virtual DataPort を再起動します。
この時点で、Virtual DataPort は新しいデータベースからのすべてのメタデータの読み取りを開始します。
デフォルトのユーザーアカウントを使用して Virtual DataPort にログインします。つまりユーザー名は
admin
、パスワードはadmin
です。これは、カタログのデータベースを切り替えたときに、メタデータは新しいデータベースに転送されず、ユーザーが作成されないためです。手順 2 でメタデータをエクスポートした場合、VQL ファイルをインポートします。
これまでにユーザー「admin」を削除したことがある場合は、「admin」も削除します。ユーザー「admin」を削除したかどうかを確認するには、VQL ファイルに「CREATE OR REPLACE USER admin」ステートメントがあるかどうかを確認します。
サーバーで TLS を有効にした場合は、プロセスを繰り返します。つまり、スクリプト
<DENODO_HOME>/bin/denodo_tls_configurator
を実行します。詳細については、『インストールガイド』の「 Denodo SSL/TLS Configurator Script 」のセクションを参照してください。同じデータベースを共有する Virtual DataPort サーバーのクラスタを構築する場合は、次の手順に沿って操作します。
最初のインストールの場合、[Administration] メニュー > [Metadata database configuration] をクリックします。
このダイアログで、[Export settings] をクリックして、「metadata_database_configuration.properties」と入力します。これにより、このダイアログの設定が入ったファイルが生成されます。
クラスタを構成するすべてのコンピュータに、このファイルをコピーします。
これらのコンピュータのすべてで、Virtual DataPort サーバーを停止します。
クラスタの各コンピュータで、コマンドラインを開いて、次のコマンドを実行します。
Linux の場合¶cd <DENODO_HOME> ./bin/regenerateMetadata.sh "metadata_database_configuration.properties"
Windows の場合¶cd <DENODO_HOME> .\bin\regenerateMetadata.bat "metadata_database_configuration.properties"
スクリプトを使用してこの機能を有効にする¶
この機能は、Administration Tool ではなく、スクリプト「regenerateMetadata」を使用して有効にすることができます。このスクリプトは、ディレクトリ <DENODO_HOME>/bin
にあります。
このスクリプトには次の 2 つのモードがあります。
「properties」ファイルを引数として渡します。このファイルには、適用される構成が入っています。
このインストール環境の Virtual DataPort でこの機能を構成するための必要なパラメータをすべて渡します。
regenerateMetadata -f <input-file> [--externalDriver <path-to-external-driver>] [-reset] [-y]
regenerateMetadata --adapter <adapter-name>
--version <adapter-version>
--driver <driver-classname>
[--driverProperties <driver-properties>]
--classPath <driver-classpath>
[--externalDriver <path-to-external-driver>]
--databaseUri <uri>
--user <user>
--password <password>
[--catalog <catalog>]
[--schema <schema>]
[--initialSize <pool-initial-size>]
[--maxActive <pool-max-active>]
[--testConnections]
[--pingQuery <pool-validation-query>]
[--reset]
[--yes]
パラメータ名 |
説明 |
---|---|
-f --file <input-file> |
外部データベース構成の入った入力ファイルです。[Metadata database configuration] ダイアログの [Export settings] オプションで、この入力ファイルを生成します。 |
-a --adapter <adapter-name> |
アダプター名 (サポートされているエンジンのいずれか) です。この値は、VQL プロパティ 例: |
-v --version <adapter-version> |
アダプターのバージョン (サポートされているエンジンのいずれか) です。この値は、VQL プロパティ 例: |
-d --driver <driver-classname> |
ドライバークラスの名前です。 例: |
-dp --driverProperties <path-to-external-driver> |
JSON 形式のドライバープロパティです。 例: |
-cp --classPath <driver-classpath> |
ドライバークラスのパスです。この値は、VQL プロパティ 例: |
-e --externalDriver <driver-classpath> |
外部のドライバーファイル (1 つまたは複数) の場所です。値として、ファイルまたはディレクトリのパスを指定します。 例: |
-uri --databaseUri <uri> |
データベースの URI です。 例: |
-u --user <user> |
データベースのユーザー名です。 例: |
-p --password <password> |
データベースのユーザーパスワードです。スクリプト「encrypt_password」を使用して、暗号化された値を取得することができます。 例: |
-c --catalog <catalog> |
データベースのカスタムカタログです。 例: |
-s --schema <schema> |
データベースのカスタムスキーマです。 例: |
-pi --initialSize <pool-initial-size> |
プールの初期サイズです。 例: |
-pma --maxActive <pool-max-active> |
プールの最大アクティブ数です。 例: |
-pt --testConnections |
プールのテスト接続です。検証クエリ値が必要です (--pingQuery)。 例: |
-pq --pingQuery <pool-validation-query> |
接続のプール検証クエリです。 例: |
--reset |
メタデータが存在する場合に、そのメタデータをリセットします (デフォルトでは無効です。存在する場合はメタデータを再利用します)。 |
-y --yes |
変更を自動的に確定します (デフォルトでは無効です)。 |
例
例 1:
[Metadata database configuration] ダイアログの [Export settings] オプションで生成した構成ファイルを使用して、メタデータを外部データベースに保存するようにカタログを構成します。
regenerateMetadata --file configuration-file.properties
このスクリプトでは、変更を適用する前に確認が求められます。
例 2:
構成ファイルを使用して、メタデータを外部データベースに保存するようにカタログを構成します。パラメータ --reset
があるので、メタデータを保存するテーブルがデータベースにすでに存在する場合には、そのテーブルは削除され、再度作成されます。
regenerateMetadata --file configuration-file.properties --reset
例 3:
スキーマ「denodo_metadata」で、メタデータを PostgreSQL データベースに保存するようにカタログを構成します。
regenerateMetadata --adapter postgresql
--version 12
--classPath "postgresql-12"
--databaseUri "jdbc:postgresql://psql-db:5432/vdpcatalog"
--driver "org.postgresql.Driver"
--user "denodo_user"
--password "encrypted:passwordEncrypted"
--schema "denodo_metadata"
--testConnections
--pingQuery "SELECT 1"
--driverProperties "{\"prop1\":\"value1\", \"prop2\":\"value2\"}"
この例では、パスワード (パラメータ --password
) が暗号化されています。このパスワードを暗号化するために、スクリプト <DENODO_HOME>/bin/encrypt_password
を実行して、PostgreSQL でのこのユーザーアカウントのパスワードを入力します。 --password
の引数は、 encrypted:
の後ろに、このスクリプトの結果を追加したものです。
なお、Virtual DataPort は、このスクリプトに渡されたパスワードが暗号化されているかどうかにかかわらず、暗号化された状態で保存します。
例 4:
スキーマ「denodo_metadata」で、メタデータを PostgreSQL データベースに保存するようにカタログを構成します。
regenerateMetadata --adapter mysql
--version 5
--classPath "mysql-5"
--externalDriver "/my-drivers/mysql5"
--databaseUri "jdbc:mysql://mysql-db:3306/vdpcatalog"
--driver "com.mysql.jdbc.Driver"
--user "denodo_user"
--password "encrypted:passwordEncrypted"
--schema "denodo_metadata"
--testConnections
--pingQuery "SELECT 1"
--driverProperties "{\"prop1\":\"value1\", \"prop2\":\"value2\"}"
この例では、パラメータ --externalDriver
を使用して、MySQL ドライバーが存在する Denodo 外部の場所を指定しています。スクリプトは指定された場所からドライバーを読み込み、コネクションを開きます。さらに、パラメータ --classPath
で指定された内部の Denodo クラスパスが示す場所にドライバーがコピーされ、Virtual DataPort の起動時にサーバーがドライバーを読み込めるようになります。なお、 --externalDriver
パラメータの値はファイルでもディレクトリでも構いません。ディレクトリの場合、そのディレクトリに存在するすべてのファイルがドライバーの読み込みに使用されます。
加えて、パスワード (パラメータ --password
) が暗号化されています。このパスワードを暗号化するために、スクリプト <DENODO_HOME>/bin/encrypt_password
を実行して、MySQL におけるこのユーザーアカウントのパスワードを入力します。 --password
の引数は、 encrypted:
の後ろに、このスクリプトの結果を追加したものです。
なお、Virtual DataPort は、このスクリプトに渡されたパスワードが暗号化されているかどうかにかかわらず、暗号化された状態で保存します。
ユーザーパスワードの変更
次のコマンドを実行して、外部データベースへのアクセスに使用するパスワードを更新します。
regenerateMetadata --password "encrypted:aqlgsesdkloqwepiouimzzkd=="
この例でも、パスワードは暗号化されています。
パスワードは、Administration Tool の [Metadata database configuration] ダイアログで変更することもできます。
重要
このパスワードを直接変更したり、この機能の構成パラメータを Virtual DataPort の構成ファイルで変更したりしないでください。