外部データベースへのメタデータの保存

Virtual DataPort の カタログ は、設定と、ユーザーが作成したメタデータ (データソース、ビュー、Web サービス、ユーザー、ロールなど) で構成されます。デフォルトでは、Virtual DataPort に組み込まれている Apache Derby データベースが カタログ で使用されます。

組み込みのデータベースではなく、外部データベースを使用するようにカタログを構成できます。それには、以下のようなメリットがあります。

  1. 自動レプリケーション: クラスターの Virtual DataPort サーバーが同じ外部データベースを共有する場合、変更を実行する必要があるのは 1 つのサーバーのみです。変更は他のサーバーに自動的に伝播されます。自動レプリケーションを使用しない場合は、クラスターのサーバーごとに同じ変更を行う必要があります。

    このシナリオでは、クラスターのすべてのサーバーが「マスターノード」です。つまり、いずれかの Virtual DataPort がシャットダウンしても、他のサーバーは中断せずに引き続き機能します。

  2. バックアップ: この外部データベースの管理者が、このデータベースを定期的にバックアップしている場合、Virtual DataPort のメタデータもバックアップされます。この機能は、クラスターがない場合でも有益です。


この機能は、エレメント内の変更が制御された方法で行われない環境で使用するものです。つまり、通常は以下のような、ユーザーがビューや Web サービスなどをいつでも作成したり変更したりすることのできる環境で使用します。

  • 開発環境: 開発者がデータソース、ビュー、Web サービスなどを作成します。

  • サンドボックス環境: これらの環境には、通常、本番環境のサーバーと同じビューがありますが、ユーザー (データ科学者など) が追加のビューを作成して分析を実行します。

この機能を使用すると、同じ外部データベースを共有する Virtual DataPort サーバーのクラスターを設定することで、この種の環境のキャパシティ (つまり同時リクエスト数) を増やすことができます。

制御された方法で変更を行わなければならない環境 (つまりステージング環境と本番環境) では、この機能を有効にすることはお勧めしません。代わりに Solution Manager を使用して、変更を開発環境からステージングおよび本番環境に昇格することをお勧めします。その理由は以下のとおりです。

  1. この機能が有効になっていると、クラスターの各サーバーに変更を昇格する Solution Manager の機能をダウンタイムなしで使用できません。これは、この機能が有効になっている場合、1 つのサーバーのエレメントに対する変更が、クラスターのその他のサーバーに直ちに反映されるためです。これにより、一連のビューが他のビューに置き換えられた場合、クライアントアプリケーションがプロモーション中に本番サーバーにアクセスする可能性があります。

  2. この機能によりクエリにわずかなオーバーヘッドが追加されます。このオーバーヘッドは数分または数時間続く分析クエリには関係ありませんが、ミリ秒で完了することが期待される操作クエリでは問題になる可能性があります。


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 (デフォルトオプション) を使用します。この場合、メモリ内キャッシュを変更できるのはローカルサーバーだけであるため、メモリ内キャッシュは必ず更新されます。

カタログは外部データベースを使用する場合、このメモリ内キャッシュも使用します。ただしカタログは、このキャッシュから取得されたオブジェクトが最新であることを確認する必要があります。これは、カタログがオブジェクトをデータベースから読み取りキャッシュに保存してから、別のサーバーがそのオブジェクトを変更していた可能性があるためです。カタログは、オブジェクトが最新であることを確認するために、別のコンポーネントがオブジェクトを読み取るときに以下の手順を実行します。

  1. メモリ内キャッシュにオブジェクトが 含まれていない 場合、カタログは外部データベースからそのオブジェクトを読み取り、メモリ内キャッシュに保存します。

  2. メモリ内キャッシュにすでにオブジェクトが含まれている場合、カタログは外部データベースでクエリを実行し、このオブジェクトが、読み取られてからデータベース内で変更されていないかどうかを検証します。オブジェクトの期限が切れている場合は、カタログは再度オブジェクトを読み取り、キャッシュを更新します。

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 を構成する方法

ここでは、外部データベースを使用するように Virtual DataPort のカタログを構成する方法について説明します。

構成を変更する前に、以下について検討してください。

  • Virtual DataPort はデータベース間で (組み込みの Apache Derby からも) メタデータを転送しません。したがって、このプロセスを実行するときは、構成も含め、メタデータを再作成する必要があります。

  • SSL を再度有効にする必要があります。

以下の手順では、これらの状況を考慮します。

  1. メタデータを保存する外部データベースにカタログ/スキーマを作成します。

  2. すでにオブジェクト (ユーザー、データソース、ビューなど) を作成している場合は、すべてのメタデータをエクスポートします。つまり [File] メニュー > [Export] をクリックします。このダイアログで [Replace existing elements] を選択し、このオプションの下のすべてのチェックボックスをチェックします。

  3. [Administration] メニュー > [Metadata database configuration] をクリックします。

  4. [Database adapter] で、使用するデータベースを選択し、[Driver class] でドライバーを選択します。

    [Driver class] が空の場合、ドライバーが Virtual DataPort に含まれておらず、このサーバーにアップロードされていないことが原因です。ドライバーをこのサーバーにアップロードするには、このウィンドウを閉じて、以下の手順に従います。

    1. [File] メニュー > [Extension management] をクリックします。

    2. このダイアログで、[Libraries]、[Import] の順にクリックします。

    3. 新しいダイアログの [Resource type] で、[jdbc] を選択します。

    4. [Version] で、アップロードするドライバーを選択します。たとえば、IBM DB2 11 のドライバーをアップロードする場合は [db2-11] を選択します。

    5. [Add] をクリックして、ファイルを 1 つまたは複数選択します。複数のファイルを選択するには、Ctrl キーを押しながら各ファイルを選択します。

    6. [OK] をクリックして、ファイルを Virtual DataPort にアップロードします。

    7. [Metadata database configuration] ダイアログに戻ります。

  1. [Database URI]、[Login]、[Password] を入力します。

  2. [Specify custom catalog and schema] を選択します。

  3. 重要: [Test configuration] をクリックして、接続の詳細、ユーザーの名前とパスワードが正しいこと、このアカウントがこのデータベースにテーブルを作成する権限を持っていることを確認します。

  4. [OK] をクリックして保存します。

    [OK] をクリックするとすぐに、Virtual DataPort は、カタログを保存する外部データベースにテーブルを作成しますが、再起動されるまで、これらのテーブルを使用しません。

    テーブルがすでに存在している場合、テーブルは再作成 されません 。これは外部データベースを使用するように複数の Virtual DataPort を構成する場合は、この変更を加える最初のサーバーのみがそのテーブルを作成する必要があるからです。

  5. Virtual DataPort を再起動します。

    この時点で、Virtual DataPort は新しいデータベースからのすべてのメタデータの読み取りを開始します。

  6. デフォルトのユーザーアカウントを使用して Virtual DataPort にログインします。つまりユーザー名は admin 、パスワードは admin です。これは、カタログのデータベースを切り替えたときに、メタデータは新しいデータベースに転送されず、ユーザーが作成されないためです。

  7. 手順 2 でメタデータをエクスポートした場合、VQL ファイルをインポートします。

  8. これまでにユーザー「admin」を削除したことがある場合は、「admin」も削除します。ユーザー「admin」を削除したかどうかを確認するには、VQL ファイルに「CREATE OR REPLACE USER admin」ステートメントがあるかどうかを確認します。

  9. サーバーで TLS を有効にした場合は、プロセスを繰り返します。つまり、スクリプト <DENODO_HOME>/bin/denodo_tls_configurator を実行します。詳細については、『インストールガイド』の「 Denodo SSL/TLS 構成スクリプト 」のセクションを参照してください。

  10. 同じデータベースを共有する Virtual DataPort サーバーのクラスターを構築する場合、上記のすべての手順を 1 つを除き 繰り返す必要があります。つまり、外部データベースを構成する最初のサーバーにのみ VQL ファイルをエクスポートおよびインポートする必要があります。外部データベースを使用するように Virtual DataPort サーバーを構成すると、メタデータは自動的に他のサーバーに伝播されるようになります。

この機能に関する考慮事項

  • この機能を使用するには、カタログのデータベースを Virtual DataPort サーバーの「可能な限り近くに」配置する必要があります。つまりデータベースが同じネットワーク内に配置されているか、少なくとも、サーバーと同じデータセンターに配置されている必要があります。この条件が満たされていると、カタログの外部データベースを使用する際のオーバーヘッドが最小限に抑えられます。それ以外の場合は、クエリの実行に多少の遅延が発生する可能性があります。

  • Virtual DataPort から外部データベースへの通信は安定している必要があります。ネットワークの問題などが原因で外部データベースとの通信が不可能になることがあった場合、外部エンジンは通信が再確立されるまでクエリの処理を開始できません。

  • 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 を使用してプロパティを変更してください。これにより、コマンドを実行するサーバーの構成プロパティが変更され、同じデータベースを共有する他のサーバーに変更が伝播されます。

サポート対象のデータベース

Virtual DataPort では、以下のデータベースにカタログを保存できます。

  • IBM DB2 10 および 11

  • Microsoft SQL Server 2012、2014、2016、2017

  • MySQL 5

  • Oracle 11g、Oracle 12c、Oracle 18c、Oracle 19c

  • PostgreSQL 9 および 10

MySQL を使用するには、パラメーター --max-allowed-packet=500M を指定して MySQL サーバーを起動し、Virtual DataPort に保存されたリソースを MySQL が受信して転送できることを確認します。このパラメーターの設定方法については、「 documentation of MySQL 」を参照してください。