まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:dashdb

IBM Bluemix が提供するデータサービスの1つに "Data Connect" があります:
2017040401


このサービスは DB2, Oracle, dashDB, MySQL, cloudant, ・・・など、異なるデータベースサーバー間でのデータマイグレーションを実現するものです。マイグレーション元とマイグレーション先を定義し、相互システム間の型変換などを考慮してデータを扱い、(必要であれば)マイグレーションの実行スケジュールを指定することでデータのマイグレーション処理をその場で行ったり自動化したりする、というサービスです。更に必要に応じて Secure Gateway サービスを併用することで、クラウド上に公開されたデータベースだけでなく、オンプレミスデータベースを対象にすることも可能です。


今回は Data Connect の紹介例として、社内システムで運用中の MySQL データベースが存在していると仮定し、このデータベースの一部の内容(people テーブルの内容)を統計処理するために、クラウド上の dashDB に週に一度追加マイグレーションしたい、という要望があるものとして、この要望を実現するための設定を紹介します:
2017040402


こういった処理は JDBC などを使ってプログラミングすることも可能ですが、作成したアプリケーションを自動的に定期実行したり、同様のアプリケーションを作る際の流用性が少なかったりします。 そのような要望を一元的に管理・実現するためのサービスが Data Connect です:
2017040403


例えば上記のようなケースであれば、
(1) (マイグレーション元とマイグレーション先の2つの)データベースへの接続を定義し、
(2) データセット(マイグレーション元)を定義し、
(3) セータセットとマイグレーション先の2つの結びつきを定義し、
(4) マイグレーションの実行タイミングを定義して実行
することになります。 以下ではそれぞれの手順を実際の画面を使って紹介します。


まず IBM Bluemix で Data Connect サービスインスタンスを作成し、そのサービスインスタンスの画面を開くと、このように表示されます。画面内の "LAUNCH" ボタンをクリックすることで Data Connect サービスのダッシュボード画面に移動します:
2017040408


Data Connect のダッシュボード画面です。左上の "Data Connect" という箇所をクリックすると、いつでもこの画面に戻ってこれます:
2017040401


まずは上記 (1) の(マイグレーション元とマイグレーション先の)2つのデータベースへの接続方法を定義します。左メニューで "Connections" を選択します。現在は何も定義されていないので、画面には何も表示されないはずです。では画面右上の "Create Now" をクリックします:
2017040402


接続データベースの種類を選択する画面です。今回のケースではまずマイグレーション元となる MySQL の定義をするため、"MySQL" を選択します:
2017040403


次に MySQL の詳細情報を入力します。接続名、説明(オプション)、ホスト名、ポート番号、データベース名、Secure Gateway の利用有無、そしてユーザー名/パスワードを入力し、最後に右上の "Create Connection" をクリックします:
2017040404


(おまけ)
なお、もし対象とするデータベースサーバーがプライベートネットワーク環境内にある等、インターネットから直接参照できないような場合は、Bluemix の Secure Gateway サービスを併用します。Secure Gateway サービスがプライベートネットワーク環境とのセキュアなトンネリングを実現し、このトンネルを経由してプライベートネットワーク環境のデータベースを対象とすることができるようになります。なお Bluemix の Secure Gateway の利用手順については別途紹介したエントリがあるのでこちらを参照ください:
2017040503


Secure Gateway サービスを利用する場合の Connection 定義は以下のようにして行います。"Use a secure gateway" にチェックを入れ、設定済みの Secure Gateway 接続名を選択します。その上でデータベースサーバーのホスト名(IPアドレス)やポート番号は、プライベートネットワーク内でのものを指定します:
2017040504


なお、この Secure Gateway を使ってプライベートネットワーク内のデータベースに接続する場合ですが、データベース側はゲートウェイクライアント(または同一ネットワーク)から指定したユーザー名とパスワードで外部接続できるような設定をあらかじめ行っておく必要がある点に注意してください。例えばあるユーザーに同一ネットワーク(192.168.0.*)からの参照アクセスを許可する場合であれば以下のような MySQL コマンドを実行することになります:
> grant select on (データベース名).* to (ユーザー名)@"192.168.0.%" identified by '(パスワード)';

このコマンドの後でないと(外部からの接続ができないため)上記の接続定義が作成できないはずです。設定変更後に再度接続定義を行ってください。
(おまけ終わり)


接続定義の作成に成功すると1つ前の画面に戻り、いま作成した MySQL データベースへの接続情報アイコンが追加されていることが確認できるはずです。では続けてもう1つの(マイグレーション先の)接続情報を定義するため再度 "Create New" をクリックします:
2017040405


再び接続先データベースの種類を選択する画面です。今回は IBM dashDB に接続するので、"IBM dashDB" を選択します:
2017040406


データベースの種類によって入力する詳細項目が異なります。接続先が IBM dashDB の場合は接続名、説明(オプション)、ホスト名、データベース名、Secure Gateway の利用有無、そしてユーザー名/パスワードを入力し、最後に "Create Connection" をクリックします:
2017040407


先程の画面に戻り、今度は dashDB の接続情報アイコンが追加されたことが確認できるはずです。今回はこの2つの接続情報だけで充分ですが、マイグレーションで対象とする接続先の数だけこの作業を繰り返します(または後から追加します):
2017040408


次に (2) のマイグレーション元となるデータセットを定義します。今回は MySQL データベース内の people というテーブルの情報を dashDB にマイグレーションすることが目的なので、データセットは MySQL 内の people テーブルということになります。

このテーブルをデータセットとして定義するため、Data Connect ダッシュボードの左メニューから "Data Sets" を選択します。ここでも定義済みのデータセットがまだ存在していないので何も表示されません。では画面右上の "New Data Set" をクリックします:
2017040401


定義済みの接続情報名が(下画面では2つ)表示されます。今回は MySQL データベース内のデータを取り出したいので、MySQL の接続情報名を選択します:
2017040402


次にこのデータベース接続で対象とするデータベース名を指定します。今回は1つしか定義していないので、ただ1つ表示されるデータベースを選択しますが、複数ある場合は対象のものを選択します:
2017040403


次に対象となるテーブルやビューを選択します。今回は people テーブルを対象としたいので、"people" を選択します:
2017040404


必要であれば、このテーブルから取り出す列をカスタマイズします。全ての列を取り出す場合はデフォルトのまま全てにチェックを入れてください。最後に画面右上の "Publish Data Set" をクリック:
2017040405


すると1つ前の画面に戻り、データセット一覧に今作成した people テーブルが追加されたことが確認できます。これで (2) の作業も完了しました:
2017040406


続いて (3) データの結びつきと (4) マイグレーションスケジュールを定義します。今回の例では MySQL データベースの people データセットを dashDB データベースにマイグレーションしたいので、この関係を定義します。

改めてダッシュボード画面の左メニューから "Activities" を選択します。ここに定義済みのアクティビティ一覧が表示されますが、この時点ではまだ何も表示されていません。画面右上の "Create New" で新たに1つ追加します:
2017040401


アクティビティではまずマイグレーション元を指定します。今回は最初に作成した people データセットをマイグレーション元とするので、"Data Sets" を選択します:
2017040402


Data Sets 一覧から people を選択(1つしかないけど)します。全ての列にチェックが入っていることを確認して、次にマイグレーション先を指定するため画面右上の "Copy to Target" をクリックします:
2017040403


マイグレーション先は dashDB のデータベースなので、"Connections" の dashDB の接続情報名を選択し、マイグレーション先となるデータベーススキーマを指定します:
2017040404


people テーブルをマイグレーションするのですが、このデータベースが指定したスキーマに存在していない場合はどのようにマイグレーションするかを選択します。下図では "Recreate the table"(テーブルごと作り直してマイグレーションする)を選択しています。これで定義自体は完了で、必要に応じてこのアクティビティ定義に名前を指定することもできます(画面左上から編集できます)。 そしてこの定義を保存(Save)するか、そのまま実行(Run)することもできますが、今回は更に実行スケジュールを指定します。画面右上の "Schedule Activity" をクリックします:
2017040405


カレンダーが表示されます。このマイグレーションアクティビティを実行する日付を指定します:
2017040406


次に実行時刻(指定日の何時に実行するのか)を指定します。1回だけ実行するのであればこのまま "APPLY" をクリックしてもいいのですが、定期的に繰り返して実行する場合は "Schedule this activity to repeat" を選択します:
2017040407


引き続いて繰り返しの条件を指定します。下図の例では毎日(Daily & Every 1 day)実行して、終了日を指定せず(Never)に定義しています。繰り返し条件が確定したら "APPLY" をクリックします:
2017040408


指定した実行スケジュール(の直近のもの)が画面右側に表示されます。内容を確認して画面右上の "Done" をクリックします:
2017040401


1つ前の画面に戻り、いま定義したアクティビティが追加されたことが確認できます。このアクティビティの内容を確認したり、内容を変更する場合はこのアクティビティを選択します:
2017040402


この画面からアクティビティそのものを編集したり、スケジュールを変更したり、或いはスケジュールに関係なく一度実行したりすることができます:
2017040403


このアクティビティが実行されると、元の(MySQL の)データが dashDB へマイグレーションされます。ちなみにこちらが両者のテーブル内をプレビューした様子です(前者が MySQL 、後者が dashDB):
2017040400
  ↑MySQL


2017040401
  ↑dashDB


マイグレーションの定義とスケジューリングができ、正しく動いていることが確認できました。今回のケースであれば、いわゆるトランザクション用途で使っていた MySQL のデータを、統計処理目的で dashDB に移したかったわけですが、それが簡単に実現できたことになります。

このような異なるデータベース間のデータマイグレーションは、まあパターンが1つ程度であればプログラミングで可能になるかもしれませんが、何種類ものデータベースを対象としたり、順序などが複雑に絡み合っていたり、その実行スケジュールを考慮したりすると、システマチックに済ませたくなります。そんなケースで手軽にマイグレーションが行える Data Connect はかなり便利だと感じました。


リレーショナルデータベースにデータを格納する場合、まずテーブルの定義を行って、その後にテーブル定義に沿ったデータを挿入(insert)していくことになります。

例えば、以下のようなデータをリレーショナルデータベースに格納することを考えてみます:
2016112101


(主キーとか制約とか)深く考えずにこのデータ格納用テーブルを定義すると、その SQL はこんな感じになると思います:
create table users( id long, name varchar(100), height float, weight float );

いわゆる「普通の」リレーショナルデータベースの場合、テーブルは行指向になります。1つのレコードを1行のデータと見なして格納します(直感的に理解しやすいと思います):
2016112102


これに対して、列指向と呼ばれるテーブル定義の場合、データは列ごとにまとまった形で持つことになります。そのため1つのレコードを格納する場合も、複数の列のデータに各値を追加することになります(こちらは直感的には理解しにくいと思います):
2016112103


なぜこんな直感的にわかりにくいテーブル定義が存在しているのか、というと、この方が便利になるケースがあるからです。例えば「身長の平均値」を取り出そうとすると、SQL では AVG 関数を使って以下のような処理を実行することになります:
select avg(height) from users;

SQL ではシンプルに見えますが、行指向データベースでこの時に内部で実行される処理は比較的重いものになります。各レコードを取り出し、各レコードの身長(height)の値を取り出しては合計して平均値を取り出し・・・という処理を行います。レコード数が増えるほど「各レコードを取り出す」回数が増え、全体負荷が大きなものになります。Oracle や SQL Server だと一発で標準偏差を求める STDDEV 関数とかもありますが、これも処理はかなり重いものです。

一方これが列指向データベースの場合、身長列のデータをひとまとめに取り出せるので、そこから平均値を計算するのが比較的楽になります。

では列指向データベースの方がパフォーマンスに優れているのか、というとそうとも限りません。データを1つ(1レコード)挿入する場合の内部処理を考えると、行指向では1つのレコードを追加するだけですが、列指向では各列に値を1つずつ追加することになります。データの追加や更新といった処理におけるパフォーマンスは、一般的には行指向データベースの方が優れていることになります。

要するに利用用途に応じて行指向データベースと列指向データベースを使い分けるのが理想ということになります。ただ「普段は行指向データベースを使って、統計処理を行う時のために列指向データベースに定期的に同期する」といったように、行指向データベースと列指向データベースを連携させる必要が出てきた場合など、データや形式の互換性などをあらかじめ考慮した上で製品やサービスを選ぶ必要がでてきます。


さて、そこで dashDB です。IBM Bluemix 上のサービスの1つとして提供されている DBaaS のデータベースですが、その特徴の1つに「テーブル定義の際に行指向か列指向かを指定できる」ことがあります。

例えば上記のテーブルを dashDB 上に行指向テーブルとして作成する場合は以下のような SQL コマンドを実行します:
create table users( id long, name varchar(100), height float, weight float ) organized by row;

一方、同じテーブルを列指向テーブルで作成する場合はこちらの SQL コマンドを実行します(ちなみに dashDB ではこちらがデフォルト):
create table users( id long, name varchar(100), height float, weight float ) organized by column;

つまり dashDB を使えばデータベース間の互換性を意識する必要もなく、1つのデータベースサービスインスタンスの中でテーブル毎に行指向か列指向かを指定して定義することができるのでした。トランザクション用途であれば行指向、分析用途であれば列指向といった具合にテーブルを定義することで、データベースサーバーの使い分けを意識することなく両方の用途で利用できるクラウドの DBaaS であることが最大の特徴だと思っています。

ちなみにこれが IBM Bluemix での dashDB のアイコンです。左が(普通の)dashDB で、右がトランザクションモードの dashDB Transaction 。パッと見て列指向か行指向かがわかるようになっている(らしい)です:
2016112201


加えて dashDB は Bluemix 上のフルマネージドな RDB クラウドサービスなので、データベースサーバーとしての管理は不要です。しかもデータ量が無料枠である1GB 未満であれば課金されることもないため、データベースとして本格的に利用する前の検証用途として安心して使ってくださいませ。


以前からずっと悩んでいたのが、PHP と IBM DB2 の相性の悪さ(苦笑)でした。

知らない方が多いと思うので補足すると、PHP からデータベースにアクセスする場合には PDO(PHP Data Object) の拡張モジュールが必要になります。更に PDO に加えてデータベースの種類毎(例えば MySQL とか PostgreSQL とか)に接続するための拡張モジュールをシステムに導入しておく必要があります。

CentOS での例を書いておくと、例えば MySQL や PostgreSQL を使う場合はそれぞれ以下のようにして、これらのモジュールをインストールすることができます(PDO 拡張モジュールごとインストールできます):
(MySQL の場合)
# yum install php-mysql
(PostgreSQL の場合)
# yum install php-postgresql

さて IBM DB2 のケースです。普通に "yum install php-db2" などと入力しても「何それ?」みたいな扱いになります(苦笑)。
# yum install php-db2
  :
  :
パッケージ php-db2 は利用できません。
エラー: 何もしません

ではどこから拡張モジュールをインストールするのか・・・ と思って調べてみたのですが、かなりハードル高そうです:
http://php.net/manual/ja/ibm-db2.installation.php


↑リンク先を読んでいただくとわかりますが、自分でヘッダファイルやライブラリファイルを用意して、ビルドしろ、ということになっています。ということは DB2 のインストールモジュールが必要になるわけで・・・ 普通に PHP から使いたいだけなのですが、クラウドの DBaaS として使うにはかなりハードルが高めに設定されているように見えますね。。


一方で IBM Bluemix 環境であれば、このハードルはぐっと下がります。なにしろ「用意されたビルドパックを使うだけ」です。

前提として、IBM Bluemix 上に dashDB のインスタンスを1つ作成し、以下のようなテーブル(names)を定義しておきます:
2016111401
↑ID(int) と NAME(varchar(20)) だけのテーブル定義

2016111402
↑3つのレコードを入力済み


この dashDB インスタンスを、IBM Bluemix 上に作成した PHP ランタイムからバインドしてアクセスする、というアプリケーションを作ります:
2016111401



ビルドパックはこちらにあるものをそのまま利用します:
https://github.com/ibmdb/db2heroku-buildpack-php

ソースコード(index.php)はこんな感じで用意します(ホスト名やユーザー名、パスワードなどは Bluemix の接続情報を参照して取得します):
<html>
<head>
<title>DB2</title>
</head>
<body>
<table border="1">
<tr><th>ID</th><th>NAME</th></tr>
<?php
$host = "xxxxx.services.dal.bluemix.net"; # DB2(dashDB) のホスト名
$port = 50000; # ポート番号
$db = "BLUDB"; # データベース名
$username = "(username)"; # ユーザー名
$password = "(password)"; # パスワード

$conn_str = "DRIVER={IBM DB2 ODBC DRIVER};DATABASE=" . $db . ";HOSTNAME=" . $host . ";PORT=" . $port . ";PROTOCOL=TCPIP;UID=" . $username . ";PWD=" . $password . ";";
$conn = db2_connect( $conn_str, $username, $password );
if( $conn ){
  $sql = "SELECT * FROM \"names\"";
  $stmt = db2_prepare( $conn, $sql );
  $result = db2_execute( $stmt );
  if( $result ){
    while( $row = db2_fetch_array( $stmt )){
?>
<tr><td><?php print_r($row[0]); ?></td><td><?php print_r($row[1]); ?></td></tr>
<?php
    }
  }else{
    $error = db2_stmt_error( $stmt );
    $errormsg = db2_stmt_errormsg( $stmt );
?>
<tr><td><?php print_r($error); ?></td><td><?php print_r($errormsg); ?></td></tr>
<?php } } ?> </table> </body> </html>

PHP 内で dashDB のインスタンスに接続して SQL を実行し、全レコードを取り出して表示する、という内容になっています。PHP としては非常にシンプルですが、"db2_" で始まる拡張関数が数か所使われており、DB2 用のコードになっていることがわかると思います。

こいつを cf コマンドでプッシュします。その際に -b オプションで上記のビルドパックを指定します:
# cf push (アプリ名) -b https://github.com/ibmdb/db2heroku-buildpack-php

この方法で作成したアプリケーションにアクセスすると、PHP の IBM DB2 拡張が読み込まれて実行され、期待通りの結果が表示されます:
2016111403


PHPer の皆さん、IBM Bluemix と dashDB であれば面倒な手続きなく PHP からも使えます。是非アプリを作ってみましょう!


なお、PHP の IBM DB2 拡張機能については公式ドキュメントが存在しているので、関数リファレンスも含めて詳しくはこちらを参照ください:
http://php.net/manual/ja/book.ibm-db2.php


IBM Bluemix から提供されている解析用 DBaaS の dashDB には R Studio 環境が付属しています(オープンソース製品としての R Studio 環境がセットアップ済みの状態から使えます)。個人的にもよく使ってます。



特に今回のように R Studio 環境を紹介するようなブログを書いていると、R Studio のスクリーンショットを撮りたくなることも珍しくないのですが、色々使った後の R Studio コンソール画面(下図の画面左半分)はごちゃごちゃしていたり、そもそも見せたくない内容が含まれていたりします。このコンソール部分をクリアする方法が分かっていなかったのですが、キーボードの Ctrl + L でクリアできることを知りました:
2016110201


色々操作した後に Ctrl + L すると、コンソールがクリアされます:
2016110202


それ以外にもこの辺りのショートカットが便利そうです:
- Ctrl + 1 : ソースエディタに移動
- Ctrl + 2 : コンソールに移動





 

Bluemix 上のデータストレージサービスである Cloudant と dashDB はデータを連携することができます。以前には Cloudant から dashDB へのレプリケーションによって実現できる、という記事を紹介しました:
Cloudant => dashDB の単方向レプリケーション

簡単に紹介すると dashDB 側から Cloudant のデータをプルする形で複製を作ることで実現する、という内容だったのですが、2016/Jan/28 時点ではこの方法は使えなくなっています。代わりに Cloudant 側から dashDB 上にデータウェアハウス用DBを作る、という(逆の)データエクスポート機能によって実現できるようになりました。 というわけで、その手順を紹介します。


まずは Cloudant 側にエクスポートするデータが格納されている必要があります。既に Cloudant でデータが溜まっているのであればそのデータを使ってください。これからデータを集める場合は Bluemix の Node-RED スターターで集めるのが簡単だと思います:
2016012801


"Node-RED Starter" ボイラープレートを使って、アプリケーション環境を作成します:
2016012802


Bluemix 上に Node.js アプリケーションサーバーと Cloudant データベースサーバーが作られ、Node-RED アプリケーションが稼働している状態が作れました。ここから Node-RED 画面に移動します:
2016012803


ここで Node-RED を使ってセンサーのデータを集めます。この辺りの詳しい手順はこちらを参照してください:
Bluemix の Node-RED サービスで IoT アプリを作る(1/2)
Bluemix の Node-RED サービスで IoT アプリを作る(2/2)
2016012805


この例では Cloudant 上の "iotdata" データベースにデータを集めました。このデータベースを dashDB にエクスポートしてみます:
2016012804


左メニューの "Warehousing" を選び、サブメニューの "Warehouses" を選択すると、現在作成されたウェアハウスの一覧が表示されます。初回は一覧に何もないので "Create a warehouse" ボタンがあるだけだと思います。今からウェアハウスを作るのでこのボタンをクリックします(またはメニューから "Warehousing" - "Create  a Warehouse" を選択します):
2016012807


「ウェアハウス」の実体が Bluemix 上の dashDB になります。というわけで、ここで Bluemix の ID とパスワードを入力してログインします:
2016012801


ログイン後、作成するウェアハウスの情報を入力します。ウェアハウスの名前を指定し、そして(今回は)ウェアハウスの dashDB を新規に作成するので "Create new dashDB instance" を選択します:
2016012802


そしてウェアハウス化する Cloudant のデータベースを指定します。今回は "iotdata" というデータベースを対象にします。途中まで入力すると候補が出てくるのでそこから選びます:
2016012803


対象データベースに "iotdata" が追加されました。必要に応じてここで複数のデータベースを追加指定することも可能です。最後に "Create Warehouse" をクリックします:
2016012804


しばらく待ちます・・・・
2016012805


Cloudant 上の "iotdata" データベースが指定した名前でウェアハウス化されました。"Open in dashDB" をクリックすると dashDB 上のデータとして開くことができます:
2016012806


dashDB で開いた時の画面です:
2016012807


メニューから Tables を選び、データベース名(IOTDATA)を選択すると、Cloudant から複製されたデータベースが確認できます。下図は Table Definition タブが選択された状態で、テーブル定義を確認できます:
2016012808


隣の Browse Data タブを選ぶと、実際のデータレコードが確認できます。Cloudant のデータが RDB である dashDB 内に格納されていることが確認できました:
2016012809


ちなみに、この時 Bluemix のダッシュボードを確認すると、未バインドの dashDB インスタンスが米国南部データセンター内に作られていました(元の Cloudant が米国南部以外で作られていても、dashDB は米国南部に作られるようです):
2016012808


また、ウェアハウスを作成した段階では Cloudant にも "_warehouser" というデータベースが作成されていました。2ドキュメントなので、おそらく管理用データベースかな:
2016012801


 

このページのトップヘ