Teiid Desinger を使わずに Teiid Server を運用する

作成日：2016.05.05
修正日：2016.06.05

このページでは Teiid Server を Teiid Designer を使わずに運用する方法を説明する。 前提としてTeiid のインストールメモとTeiid からデータソースへ接続するの内容を読んでいるものとする。

Teiid に関する他のページはTeiid Data Virtualization の覚え書きのインデックスからたどれる。

Notice

Teiid 9.2 から新しい仮想データベースの定義方法が追加され、従来の XML 形式の設定ファイル(foo-vdb.xml) 以外に DDL 形式の設定ファイル(foo-vdb.ddl) が使えるようになった。 ただしこのページでは新しい DDL 形式ファイルの説明はしない。

更新履歴
(2016.05.05) 作成。
(2016.05.16) JDBC ドライバーの配備方法として Management CLI を使う方法を記述。
(2016.06.05) JDBC ドライバーの配備方法を加筆。

目次

1. はじめに

Teiid のインストールメモ、Teiid からデータソースへ接続するでは Teiid Sever と Teiid Designer はペアで使うような説明を行っていたが、Teiid Server は Teiid Designer がなくても単体で運用することができる。 Teiid Designer が最新の Teiid Server に対応していない点や、Teiid Designer が不安定な点を考えると、むしろ Teiid Server を単体運用する方が理想的である。

Teiid Designer なしで運用する場合、Teiid Designer がやっていた処理を別の方法で実現する必要がある。

  1. データソースからモデルの抽出
  2. データソースの Teiid Server への登録
  3. VDB の作成
  4. VDB の Teiid Server への登録

1.〜4. のうち、2. を 5章と6章 で、3. と 4. を 7章 で解説する。 1. のデータソースからのモデルの抽出は手作業でやる必要がある。

2. Teiid 再考

Teiid Designer なしの Teiid Server の単体運用の手順を説明する前に、仮想データベース(Virtual Database; VDB) と データソース(Data Source) について再考する。

2.1 データソースと VDB の関係

Oracle をはじめとする RDBMS は 1 つのインスタンス内に複数のデータベースを持てるようになっている。 データベースはその中に独立したユーザー管理・アクセス管理が持てるので、1つのインスタンスで別々の顧客にデータベースを提供できる。 プログラム的にはデータベース・インスタンスは外部からは 1 つの接続ポートを公開し、クライアントもそのポートに接続するが、接続のイニシエーション時にデータベース名を指定することでデータベース・インスタンス内の特定のデータベースを選択する。 一度データベースを選択すると、原則として別のデータベースに切り替えることはできない。

上記のような理由で、Teiid Server はデータベース・インスタンスをデータソースとするのではなく、データベース・インスタンス内のデータベースをデータソースとして認識する。 Teiid Server にデータソースを登録するとは、fig-1 のように物理データーベースに対する接続情報を登録することになる。 もちろん 1 つの物理データベースに対して複数のデータソースを登録するのは自由である。

VDB は Teiid Server に登録されたデータソースをモデルとして取り込む。 VDB は複数のモデルを保持し、モデル→ データソース → 物理データベースの先にあるテーブルを VDB の仮想テーブルとして登録することができる。 物理データベースのどのテーブルを登録するかしないかは VDB ファイルの記述によって変更できる。 物理データベースのテーブル名とは別の VDB の仮想テーブル名を設定することも可能だ。

fig-1: VDB とデータソースの全体像
VDB とデータソースの全体像

fig-1 の場合、Teiid Server には仮想データベース VFOO、VBAR があることになる。 クライアントは Teiid Server の待ち受けポート番号(デフォルトで TCP: 31000)に接続した後にデータベース名を指定してコネクションを確立する。 以降は VFOO か VBAR のどちらかだけをアクセスすることになる。 VDB のモデルは SQL 的にはスキーマに見えるので、データベース VFOO の場合、テーブル名は PG.TBL1、MY.TBL5 のようにアクセスする。 もちろんテーブル名がスキーマ修飾なしで一意に決まる場合は、スキーマ修飾を省略してもよい。

2.2 VDB の実体

VDB の実体、VDB を構成するための設定ファイルには VDB ファイル と Dynamic VDB ファイル の 2 種類がある。

Teiid からデータソースへの接続 では VDB を Teiid Designer で作成し、そのまま Teiid Server へ配備した。 6章までの手順を実行すると Teiid Designer の workspace ディレクトリの下に Benchmark.vdb というファイルが生成される。 これが VDB ファイルである。

Notice

VDB ファイルは Teiid Server 内では Java serialization data(.ser) の形式で格納されている。 Teiid Server 下のディレクトリを探っても Benchmark.vdb ファイルは見つからない。

VDB ファイルは ZIP 形式ファイルで、Benchmark.vdb を展開すると以下のようなディレクトリ構成になっている。

META-INF/vdb.xml が最初に読み込まれ、そこからリンクを辿り Dbt3Benchmark/MySqlDbt3.xmi と Dbt3Benchmark/PostgreSqlDbt3.xmi を読む。 中身を見てもらうと分かるが、記述内容が多過ぎてこれを手書きしろというのははっきりいって辛い。

そこで Teiid Designer で Benchmark.vdb を右クリックし、"Modeling" → "generate dynamic VDB" を選択した後に出るダイアログを最後まで進めると今度は Benchmark-vdb.xml という XML ファイルが 1 つできる。 これは Dynamic VDB ファイルであり、VDB ファイルと内容的には等価となる。 こちらはなんとか手書きができそうに見える。

やり方に少し差があるが VDB ファイル同様に Dynamic VDB ファイルも Teiid に配備可能だ。 そこで Teiid Designer なしの運用をする場合、VDB ファイルではなく Dynamic VDB ファイルを手で書いて配備する。

Important

Dynamic VDB ファイルはファイル名が必ず -vdb.xml で終わる必要がある。 foo-2-vdb.xml は OK だが、foo-vdb-2.xml は NG。 後者の XML ファイルも Teiid Server に配備できるのだが、クライアントが Teiid Server に接続して VDB を探すところでエラーになる。

3. 準備

以降、具体的な手順を示すが、準備としてTeiid のインストールメモの2.1節を参考に Teiid Server のファイルをダウンロードする。 その後、3章に従い Teiid Server をインストールする。

今回は Teiid Designer を使わないので、最新の Teiid (Server) をダウンロードしてもよい。 また同梱版をインストールする方が便利だろう。

都合上 /home/nminoru/teiid/jboss-eap-6.4 に Teiid Server がインストールされたものとして話を進める。 以降、このディレクトリを $WILDFLY_HOME で参照することにする。 Teiid Server の設定ファイルは $WILDFLY_HOME/standalone/configuration/standalone-teiid.xml にあるものとする。

準備が整ったら、以下のように Teiid Server を起動する。 

$ cd $WILDFLY_HOME/standalone/configuration
$ ../../bin/standalone.sh -c standalone-teiid.xml

説明のためにデータソースが必要だが、これは Teiid からデータソースへ接続する と 1章の構成を使う。

2 台のホスト上の 1 台で Teiid Server が、もう 1 台で MySQL サーバーと PostgreSQL サーバーが動作しており、 MySQL サーバーと PostgreSQL サーバーはすでに起動済みで、両方にサンプルとして dbt3 というデータベースが作成され、ユーザー名 nminoru、パスワード nminoru でアクセス可能とする。

 IP アドレスOS
Teiid Server 8.12.410.20.230.16CentOS 6.7
MySQL 5.7.1210.20.230.17CentOS 7.2
PostgreSQL 9.410.20.230.17CentOS 7.2

サンプルのデータベースはteiid-sample-database.tgzで作成できる。 dbt3 というデータベースを作成した後に、teiid-sample-database.tgz を /tmp 以下で展開してから、PostgreSQL は以下のコマンドを入力する。 

$ psql dbt3 -f /tmp/teiid-sample-database/create_tables.sql
$ psql dbt3 -f /tmp/teiid-sample-database/load-postgresql.sql

MySQL の場合は以下を入力する。 

$ mysql -D dbt3 -u nminoru -p < /tmp/teiid-sample-database/create_tables.sql
$ mysql -D dbt3 -u nminoru -p < /tmp/teiid-sample-database/load-mysql.sql

また MySQL サーバーと PostgreSQL サーバーとの接続用にそれぞれの JDBC ドライバー(ここでは postgresql-9.4-1204.jdbc42.jar、mysql-connector-java-5.1.38-bin.jar)を入手済みとする。

4. Jboss EAP/WildFly Management CLI

Jboss EAP/WildFly には管理(Management) CLI が存在する。 $WILDFLY_HOME/bin/jboss-cli.sh がそれである。

jboss-cli.sh に --connect と --controller のオプションを付けて起動すると、Jboss EAP/WildFly と接続することができる。 Teiid Server ではなく Jboss EAP/WildFly へ接続するので、ポートは 9990 番ではなく、9999 番となる。 ただし Teiid 8.13 以降は両ポートは統一されたようで 9990 番になる。

5. JDBC ドライバーの登録

JDBC 経由でアクセスするデータソースはリレーショナル・データベース固有の JDBC ドライバーが必要になる。 PostgreSQL の場合は postgresql-9.4-1204.jdbc42.jar だったり、MySQL の場合は mysql-connector-java-5.1.38-bin.jar だったりする。 この JDBC ドライバーを登録する必要がある。

JDBC ドライバーの登録には、WildFly に対して JDBC ドライバーの JAR ファイルをモジュールとして登録し、そのモジュールを WildFly から JDBC ドライバーとして参照可能にするために JDBC ドライバー名を登録するという 2 段階で行う。

5.1 モジュールとして登録

JDBC ドライバーの登録する方法は複数ある。 ただし 5.1.1 節で述べる方法が一番確実のようだ。 それ以外の方法では依存ライブラリを適切に書けなかったりする。

5.1.1 システムモジュールとしての登録

WildFly の以下のディレクトリに JDBC ドライバーを格納するとモジュールとして登録したことになる。 この方法は JDBC ドライバーの「配備」を行っていない。

  1. $WILDFLY_HOME/modules/
  2. $WILDFLY_HOME/modules/system/layers/base/
  3. $WILDFLY_HOME/modules/system/layers/dv/

Management CLI を使う。 Management CLI で WildFly に接続後に module add コマンドでモジュールの登録を行う。 $WILDFLY_HOME/modules/ 以下にモジュールが作成される。 

$ $WILDFLY_HOME/bin/jboss-cli.sh --connect --controller=10.20.230.16:9999
[standalone@10.20.230.16:9999 /] module add --name=org.postgresql --resources=/path/postgresql-9.4-1204.jdbc42.jar --dependencies=javax.api,javax.transaction.api
[standalone@10.20.230.16:9999 /] module add --name=com.mysql --resources=/path/mysql-connector-java-5.1.38-bin.jar --dependencies=javax.api,javax.transaction.api

赤字の org.postgresql や com.mysql は他と被らなければ適当に決めてよいモジュールの名前である。 --dependencies にはこのモジュールが依存する Java のクラスを書く。 javax.api と javax.transaction.api が必須である。 これを忘れるとエラーとなる。

Management CLI で module add を実行後は $WILDFLY_HOME/modules/org/postgresql/main/ と $WILDFLY_HOME/modules/com/mysql/main/ のディレクトリが作成され、それぞれに postgresql-9.4-1204.jdbc42.jar と mysql-connector-java-5.1.38-bin.jar がコピーされ、module.xml というファイルが自動的に生成される。 作成されるディレクトリ名は --name で指定したのが xx.yy.zz なら $WILDFLY_HOME/modules/xx/yy/zz/main/ になる(最後の main ディレクトリは自動的に付加される)。

module.xml は module add で指定したパラメータが作成されている。 1.1 の部分は WildFly のバージョンによって変わってくる。 

<?xml version='1.0' encoding='UTF-8'?>
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
    <resources>
        <resource-root path="postgresql-9.4-1201.jdbc41.jar"/>
    </resources>
    <dependencies>
      <module name="javax.api"/>
      <module name="javax.transaction.api"/>
    </dependencies>
</module>

WildFly を停止させた状態で、上記と同じディレクトリ構成・module.xml を作った上で再起動してもよい。 この場合、$WILDFLY_HOME/modules/ ではなく、$WILDFLY_HOME/modules/system/layers/base/、$WILDFLY_HOME/modules/system/layers/dv/ に作成することもできる。 ただしこの順に検索される。

5.1.2 deployments ディレクトリにコピー

$WILDFLY_HOME/standalone/deployments/ の下に JAR ファイルをコピーすることである。 

$ cp postgresql-9.4-1204.jdbc42.jar $WILDFLY_HOME/standalone/deployments/
$ cp mysql-connector-java-5.1.38-bin.jar $WILDFLY_HOME/standalone/deployments/

配備が成功すると $WILDFLY_HOME/standalone/deployments/ の下に postgresql-9.4-1204.jdbc42.jar.deployed というダミーファイルができる。

この方法では、ファイル名がモジュール名となる。

5.1.3 Management CLI の deploy コマンド

Management CLI に接続後に deploy コマンドで配備を行うことも可能である。 

$ $WILDFLY_HOME/bin/jboss-cli.sh --connect --controller=10.20.230.16:9999
[standalone@10.20.230.16:9999 /] deploy /path/postgresql-9.4-1204.jdbc42.jar
[standalone@10.20.230.16:9999 /] deploy /path/mysql-connector-java-5.1.38-bin.jar

上記のコマンドを実行すると $WILDFLY_HOME/standalone/configuration/standalone-teiid.xml には以下が追加される。 

<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.7">
  <deployments>
    <!-- ここから -->

    <deployment name="postgresql-9.4-1204.jdbc42.jar" runtime-name="postgresql-9.4-1204.jdbc42.jar">
      <content sha1="aae989d89b2f9b10900044d85881e3a65137b1a7"/>
    </deployment>
    <deployment name="mysql-connector-java-5.1.38-bin.jar" runtime-name="mysql-connector-java-5.1.38-bin.jar">
      <content sha1="471bcc236d5d85690046eb69914c271411029ffe"/>
    </deployment>

    <!-- ここまでが追加される -->
  </deployments>
</server>

この場合、runtime-name がモジュール名となる。

Notice

runtime-name を決めたい場合には、--runtime-name をつける。 --name は別に付けてもよいが、以降の設定では利用しない。 

[standalone@10.20.230.16:9999 /] deploy --name=postgresql --runtime-name=postgresql /path/postgresql-9.4-1204.jdbc42.jar

5.2 JDBC ドライバー名の登録

次にモジュールとして登録したものを、WildFly から参照可能な JDBC ドライバーとして名前を付けて登録する。 ドライバー名は自由に付けてよい。 ドライバーモジュール(driver-module-name)は、さきほど登録したモジュールの名前をつける。

driver-class-name と driver-xa-datasource-class-name は、それぞれの JDBC ドライバー内のクラスを指定すること。 

$ $WILDFLY_HOME/bin/jboss-cli.sh --connect --controller=10.20.230.16:9999
/subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=org.postgresql,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.jdbc.Driver,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

上記のコマンドを実行すると $WILDFLY_HOME/standalone/configuration/standalone-teiid.xml には以下が追加される。 

<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.7">
  <profile>
    <subsystem xmlns="urn:jboss:domain:datasources:1.2">
      <datasources>
        <drivers>

          <!-- ここから -->

          <driver name="postgresql" module="org.postgresql">
            <driver-class>org.postgresql.Driver</driver-class>
            <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
          </driver>

          <driver name="mysql" module="com.mysql">
            <driver-class>com.mysql.jdbc.Driver</driver-class>
            <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
          </driver>

          <!-- ここまでが追加される -->

        </drivers>
      </datasources>
    </subsystem>
  </profile>

</server>

これも WildFly を停止させた状態で、$WILDFLY_HOME/standalone/configuration/standalone-teiid.xml に手で書いてもよい。

5.3 JDBC ドライバーの確認

登録した JDBC ドライバーを確認したい場合、Management CLI から jdbc-driver-info コマンドを使うとよい。 

$ $WILDFLY_HOME/bin/jboss-cli.sh --connect --controller=10.20.230.16:9999
[standalone@10.20.230.16:9999 /] jdbc-driver-info
NAME        SOURCE
h2          com.h2database.h2/main
mysql       com.mysql/main
postgresql  org.postgresql/main
teiid       org.jboss.teiid.client/main
teiid-local org.jboss.teiid/main

6. データソースの登録

Teiid Server に VDB を登録する前に、データソースを登録する必要がある。

次にデータソースの登録(設定)を行う。 データソースの登録には以下の 4 種類が存在する。

(A) Teiid Web Console を使う
Web ブラウザから Teiid Server の TCP/9990 にアクセスし、"Configuration" タブの "Connector" - "Datasources" の下でデータソースを登録する方法がある。
(B) Teiid AdminShell を使う
Teiid Server に SQL クエリーを投げるの2章で紹介した Teiid AdminShell を使ってデータソースを登録する方法がある。
おそらく一番正規に近いやり方だと思われる。
だが (後述する) no-XA datasource は登録できるが、XA datasource の登録がうまくいかない。
Teiid AdminShell には Java 用の AdminAPI がありプログラム的にデータソースを登録することもできる。 ただし XA datasource の登録はうまくいかない。
(C) Management CLI を使う
Teiid ではなく WildFly または JBoss EAP 側の Management CLI を使ってデータソースを登録する方法がある。
(D) standalone-teiid.xml を書き換える
Teiid Server をいったん止めて standalone-teiid.xml を直接書き換える方法がある。 実際はこれが一番確実だ。

$WILDFLY_HOME/docs/teiid/datasources/ の下にデータソース毎に (C) と (D) を使って登録する方法が記載されている。 ここでは (D) の standalone-teiid.xml を書き換える方法を説明する。

データソースには通常の non-XA データソースと、2 相コミットをサポートする XA データソースがある。 Teiid Server のデータソースの登録ではそれぞれ別に登録する必要がある。 XA データソースに対応しているリレーショナル・データベースは大概 JDBC ドライバーが両方に対応しており、ドライバー自身は一つでよい。

standalone-teiid.xml の書き換えは以下のようにして行う。

  1. 5章で登録した JDBC ドライバーのモジュール名と JDBC ドライバー名を覚えておく。
  2. <server><profile><subsystem ...><datasources> を探し、データソースを書く。デフォルトで ExampleDS が登録されている箇所である。
    • データソースは non-XA データソースが <datasource/> で、XA データソースは <xa-datasource/> で記述する。 赤字 の JNDI 名は他とかぶらないように命名する。 この名前を dynamic VDB から参照する。
    • <driver/> には、JDBC のファイル名ではなく、1. の <deployment/> の name を記述する。
    • 青字 のデータベースへの接続用のパラメータを記載する。
  3. <datasources/> と同じレベルにある <drivers/> の下にドライバーの情報を書く。 <drivers/> の名前以外はほぼ固定の書き方である。 
<?xml version='1.0' encoding='UTF-8'?>

<server xmlns="urn:jboss:domain:1.7">
  <profile>
    <subsystem xmlns="urn:jboss:domain:datasources:1.2">
      <datasources>

        <datasource jndi-name="java:/PostgreSqlDbt3_DS" pool-name="PostgreSqlDbt3_DS" enabled="true">
          <connection-url>jdbc:postgresql://10.20.230.17:5432/dbt3</connection-url>
          <driver>postgresql</driver>
          <security>
            <user-name>nminoru</user-name>
            <password>nminoru</password>
          </security>
        </datasource>

        <xa-datasource jndi-name="java:/XAPostgreSqlDbt3_DS" pool-name="XAPostgreSqlDbt3_DS" enabled="true" use-java-context="true" use-ccm="true">
          <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
          <xa-datasource-property name="DatabaseName">dbt3</xa-datasource-property>
          <xa-datasource-property name="ServerName">10.20.230.17</xa-datasource-property>
          <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
          <driver>postgresql</driver>
          <security>
            <user-name>nminoru</user-name>
            <password>nminoru</password>
          </security>
        </xa-datasource>

        <datasource jndi-name="java:/MySqlDbt3_DS" pool-name="MySqlDbt3_DS" enabled="true">
          <connection-url>jdbc:mysql://10.20.230.17:3306/dbt3</connection-url>
          <driver>mysql</driver>
          <security>
            <user-name>nminoru</user-name>
            <password>nminoru</password>
          </security>
        </datasource>

        <xa-datasource jndi-name="java:/XAMySqlDbt3_DS" pool-name="XAMySqlDbt3_DS" enabled="true" use-java-context="true" use-ccm="true">
          <xa-datasource-property name="PortNumber">3306</xa-datasource-property>
          <xa-datasource-property name="DatabaseName">dbt3</xa-datasource-property>
          <xa-datasource-property name="ServerName">10.20.230.17</xa-datasource-property>
          <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
          <driver>mysql</driver>
          <security>
            <user-name>nminoru</user-name>
            <password>nminoru</password>
          </security>
        </xa-datasource>

      </datasources>
    </subsystem>
  </profile>

</server>

これでデータソースの登録は終わった。

Notice

<driver/> に <xa-datasource-class/> が定義されている場合、<xa-datasource/> に <xa-datasource-class/> に書くとエラーになることがある。

この場合、<driver/> の <xa-datasource-class/> か、<xa-datasource/> の <xa-datasource-class/> のどちらかを削除すること。

7. Dynamic VDB の書き方と配備

次に Dynamic VDB の書き方を説明する。 詳細は Teiid のドキュメントの Reference Guide > VDBs > の下にある、VDB Definition、DDL Metadata と、Teiid Designer で作った Benchmark-vdb.xml を参考のこと。

7.1 Dynamic VDB の骨格

まず Dynamic VDB ファイルの骨格は以下のようになる。 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vdb name="vdbname" version="1">
<description/>

<model name="PG">
<source connection-jndi-name="java:/XAPostgreSqlDbt3_DS" name="PostgreSqlDbt3" translator-name="postgresql"/>
<metadata type="DDL">...</a>
<metadata type="DDL">...</a>
...
</model>

<model name="MY">
<source connection-jndi-name="java:/XAMySqlDbt3_DS" name="MySqlDbt3" translator-name="mysql5"/>
<metadata type="DDL">...</a>
<metadata type="DDL">...</a>
...
</model>

<data-role name="data-role-name1">
...
</permission>

<data-role name="data-role-name2">
...
</permission>

</vdb>

7.2 Metadata の書き方

次に metadata の書き方だが、<metadata type="DDL"><![CDATA[ 〜 ]]></metadata> の中に SQL の DDL 風に記述する。 まず PostgreSQL 側のモデルを見る。 

<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE lineitem (
        l_orderkey integer OPTIONS(NAMEINSOURCE '"l_orderkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_partkey integer OPTIONS(NAMEINSOURCE '"l_partkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_suppkey integer OPTIONS(NAMEINSOURCE '"l_suppkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_linenumber integer OPTIONS(NAMEINSOURCE '"l_linenumber"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_quantity double OPTIONS(NAMEINSOURCE '"l_quantity"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_extendedprice double OPTIONS(NAMEINSOURCE '"l_extendedprice"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_discount double OPTIONS(NAMEINSOURCE '"l_discount"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_tax double OPTIONS(NAMEINSOURCE '"l_tax"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_returnflag string(1) OPTIONS(NAMEINSOURCE '"l_returnflag"', NATIVE_TYPE 'bpchar', FIXED_LENGTH 'TRUE'),
        l_linestatus string(1) OPTIONS(NAMEINSOURCE '"l_linestatus"', NATIVE_TYPE 'bpchar', FIXED_LENGTH 'TRUE'),
        l_shipdate date OPTIONS(NAMEINSOURCE '"l_shipdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_commitdate date OPTIONS(NAMEINSOURCE '"l_commitdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_receiptdate date OPTIONS(NAMEINSOURCE '"l_receiptdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_shipinstruct string(25) OPTIONS(NAMEINSOURCE '"l_shipinstruct"', NATIVE_TYPE 'bpchar'),
        l_shipmode string(10) OPTIONS(NAMEINSOURCE '"l_shipmode"', NATIVE_TYPE 'bpchar'),
        l_comment string(200) OPTIONS(NAMEINSOURCE '"l_comment"', NATIVE_TYPE 'varchar'),
) OPTIONS(NAMEINSOURCE '"public"."lineitem"')
]]></metadata>

この OPTIONS 以降の書き方はデータベースによって異なる。 同じテーブルが MySQL では以下のようになる。 

<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE lineitem (
    l_orderkey integer OPTIONS(NAMEINSOURCE '`l_orderkey`', NATIVE_TYPE 'INT', FIXED_LENGTH 'TRUE'),
    l_partkey integer OPTIONS(NAMEINSOURCE '`l_partkey`', NATIVE_TYPE 'INT', FIXED_LENGTH 'TRUE'),
    l_suppkey integer OPTIONS(NAMEINSOURCE '`l_suppkey`', NATIVE_TYPE 'INT', FIXED_LENGTH 'TRUE'),
    l_linenumber integer OPTIONS(NAMEINSOURCE '`l_linenumber`', NATIVE_TYPE 'INT', FIXED_LENGTH 'TRUE'),
    l_quantity double OPTIONS(NAMEINSOURCE '`l_quantity`', NATIVE_TYPE 'DOUBLE', FIXED_LENGTH 'TRUE'),
    l_extendedprice double OPTIONS(NAMEINSOURCE '`l_extendedprice`', NATIVE_TYPE 'DOUBLE', FIXED_LENGTH 'TRUE'),
    l_discount double OPTIONS(NAMEINSOURCE '`l_discount`', NATIVE_TYPE 'DOUBLE', FIXED_LENGTH 'TRUE'),
    l_tax double OPTIONS(NAMEINSOURCE '`l_tax`', NATIVE_TYPE 'DOUBLE', FIXED_LENGTH 'TRUE'),
    l_returnflag char(1) OPTIONS(NAMEINSOURCE '`l_returnflag`', NATIVE_TYPE 'CHAR', FIXED_LENGTH 'TRUE'),
    l_linestatus char(1) OPTIONS(NAMEINSOURCE '`l_linestatus`', NATIVE_TYPE 'CHAR', FIXED_LENGTH 'TRUE'),
    l_shipDATE date OPTIONS(NAMEINSOURCE '`l_shipDATE`', NATIVE_TYPE 'DATE', FIXED_LENGTH 'TRUE'),
    l_commitDATE date OPTIONS(NAMEINSOURCE '`l_commitDATE`', NATIVE_TYPE 'DATE', FIXED_LENGTH 'TRUE'),
    l_receiptDATE date OPTIONS(NAMEINSOURCE '`l_receiptDATE`', NATIVE_TYPE 'DATE', FIXED_LENGTH 'TRUE'),
    l_shipinstruct string(25) OPTIONS(NAMEINSOURCE '`l_shipinstruct`', NATIVE_TYPE 'CHAR', FIXED_LENGTH 'TRUE'),
    l_shipmode string(10) OPTIONS(NAMEINSOURCE '`l_shipmode`', NATIVE_TYPE 'CHAR', FIXED_LENGTH 'TRUE'),
    l_comment string(200) OPTIONS(NAMEINSOURCE '`l_comment`', NATIVE_TYPE 'VARCHAR')
) OPTIONS(NAMEINSOURCE '`dbt3`.`lineitem`')
]]></metadata>

仮想テーブル MY.lineitem とマッピングする物理テーブルが `dbt3`.`lineitem` になっている。 また列のデータ型も PostgreSQL のものとは異なる。

Notice

ここまで見てきたら分かるように dynamic VDB も手で書くのは結構面倒なので、dynamic VDB の作成だけに Teiid Desinger を使って、できた dynamic VDB を手で修正するというやり方の方が作業効率があがる。 Teiid Designer は default server を登録しないまま使えば、Teiid Server との連携をとらずに VDB を作成することは可能。

7.2.1 制約やインデックスの追加

物理テーブルに制約やインデックスが張ってある場合、それを仮想テーブル側に反映できる。 

<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE lineitem (
        l_orderkey integer NOT NULL INDEX OPTIONS(NAMEINSOURCE '"l_orderkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_partkey integer INDEX OPTIONS(NAMEINSOURCE '"l_partkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_suppkey integer INDEX OPTIONS(NAMEINSOURCE '"l_suppkey"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_linenumber integer NOT NULL OPTIONS(NAMEINSOURCE '"l_linenumber"', NATIVE_TYPE 'int4', FIXED_LENGTH 'TRUE'),
        l_quantity double INDEX OPTIONS(NAMEINSOURCE '"l_quantity"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_extendedprice double OPTIONS(NAMEINSOURCE '"l_extendedprice"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_discount double OPTIONS(NAMEINSOURCE '"l_discount"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_tax double OPTIONS(NAMEINSOURCE '"l_tax"', NATIVE_TYPE 'float8', FIXED_LENGTH 'TRUE'),
        l_returnflag string(1) OPTIONS(NAMEINSOURCE '"l_returnflag"', NATIVE_TYPE 'bpchar', FIXED_LENGTH 'TRUE'),
        l_linestatus string(1) OPTIONS(NAMEINSOURCE '"l_linestatus"', NATIVE_TYPE 'bpchar', FIXED_LENGTH 'TRUE'),
        l_shipdate date INDEX OPTIONS(NAMEINSOURCE '"l_shipdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_commitdate date INDEX OPTIONS(NAMEINSOURCE '"l_commitdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_receiptdate date INDEX OPTIONS(NAMEINSOURCE '"l_receiptdate"', NATIVE_TYPE 'date', FIXED_LENGTH 'TRUE'),
        l_shipinstruct string(25) OPTIONS(NAMEINSOURCE '"l_shipinstruct"', NATIVE_TYPE 'bpchar'),
        l_shipmode string(10) OPTIONS(NAMEINSOURCE '"l_shipmode"', NATIVE_TYPE 'bpchar'),
        l_comment string(200) OPTIONS(NAMEINSOURCE '"l_comment"', NATIVE_TYPE 'varchar'),
        CONSTRAINT i_l_suppkey_partkey INDEX(l_partkey, l_suppkey),
        CONSTRAINT i_l_orderkey_quantity INDEX(l_orderkey, l_quantity),
        CONSTRAINT pk_lineitem PRIMARY KEY(l_orderkey, l_linenumber)
) OPTIONS(NAMEINSOURCE '"public"."lineitem"', CARDINALITY '59986052')
]]></metadata>

どのような制限が付けられるかはDDL Metadataを参照のこと。

7.3 Dynamic VDB の配備

完成した dynamic VDB を配備するには、$WILDFLY_HOME/standalone/deployments/ の下にコピーすることである。 foo-vdb.xml が dynamic VDB なら、$WILDFLY_HOME/standalone/deployments/foo-vdb.xml にコピーをして Teiid Server が発見すると配備が開始される。 配備が成功した場合は、0 バイトの $WILDFLY_HOME/standalone/deployments/foo-vdb.xml.deployed が生成される。

1 度配備した (dynamic) VDB を変更したい場合は、foo-vdb.xml の version を加算してから再度 $WILDFLY_HOME/standalone/deployments/foo-vdb.xml にコピーすればよい。

Dynamic VDB を撤去(undeploy)したい場合は $WILDFLY_HOME/standalone/deployments/foo-vdb.xml を削除する。

8. セキュリティ設定

Teiid に対して INSERT/UPDATE/DELETE を発行し、仮想テーブルを介して物理テーブルを変更する場合、アプリケーション・ユーザーへのロールの付加と dynamic VDB へのデータ・ロール(Data Role)の要素の記述が必要になる。

データ・ロールは、Teiid Data Virtualization とはの2章で紹介した Teiid のセキュリティ機能を制御するための要素である。 ここでは基本となるクエリー実行権限の設定だけを説明する。

8.1 グループの付加

Teiid のロールは、JBoss EAP/WildFly のグループという形をとる。 Teiid のインストールメモ の 3.2 節 では、アプリケーションユーザーとして user を定義した。 ここに benchmark というグループを追加し、user を benchmark グループに所属させる。 

$ cd $WILDFLY_HOME/bin/
$ ./add-user.sh

どのようなユーザータイプを追加しますか？
 a) 管理ユーザー (mgmt-users.properties)
 b) アプリケーションユーザー (application-users.properties)
(a): b

追加する新規ユーザーの詳細を入力します。
レルム 'ApplicationRealm' を既存のプロパティーファイルで見つかったとおりに使用しています。
ユーザ名 : user
ユーザー 'user' はすでに存在します。既存ユーザーのパスワードとロールを更新しますか？
正しいですか yes/no? yes
パスワード : パスワードを入力
パスワードを再度入力してください。 : パスワードを入力
このユーザーが所属するグループはどれですか？ (カンマ区切りリストを入力してください。所属グループがない場合は空白のままにしてください。)[  ]: benchmark

benchmark がロールとなる。

8.2 Foreign Table への Updatable プロパティの追加

Metadata 内の foreign table の定義に UPDATABLE プロパティを TRUE に設定する(デフォルトは FALSE)。 

<metadata type="DDL"><![CDATA[
CREATE FOREIGN TABLE tablename (
 ...
) OPTIONS(NAMEINSOURCE 'originaltablename',  UPDATABLE 'TRUE')
]]></metadata>

列に対する UPDATABLE プロパティを設定することができる。 テーブル全体は UPDATABLE プロパティが TRUE だが、特定の列だけ UPDATABLE プロパティが FALSE という設定も可能。

8.3 データ・ロール(Data Role)の追加

最後に Dynamic VDB ファイル内のモデルに対して INSERT/DELTE/UPDATE を許可するデータ・ロールの記述を追加する。

データロールでは CREATE, READ, UPDATE, DELETE(CRUD) で、リソースへのアクセス許可を与える。 これは SQL の INSERT/DELTE/UPDATE と少しずれているが、以下のような対応関係がある。

これ以外の SQL コマンドは Teiid の Reference Guid > Data Roles > Permission を参照のこと。 

<data-role name="foo">

<permission>
<resource-name>PG</resource-name>
<allow-create>true</allow-create>
<allow-read>true</allow-read>
<allow-update>true</allow-update>
<allow-delete>true</allow-delete>
</permission>

<permission>
<resource-name>MY</resource-name>
<allow-create>true</allow-create>
<allow-read>true</allow-read>
<allow-update>true</allow-update>
<allow-delete>true</allow-delete>
</permission>

<mapped-role-name>benchmark</mapped-role-name>
</data-role>

データ・ロールの記述が終わったら、7.3 節 の手順で dynmaic VDB をデプロイする。 デプロイが成功した後は、Teiid Server へクエリーを投げるで説明したようにクライアントを Teiid Server に接続すれば INSERT/UPDATE/DELETE コマンドを実行することができる。

コメント

コメントを書き込む
TOP    掲示板    戻る
Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp