MySQLストレージエンジンの検証 【 OpenSource協議会 – IBM i 】

i to Open分科会

2010/02/17

MySQLストレージエンジンの検証

1.ストレージエンジン(ＭｙＳＱＬ on ＩＢＭ i、ＤＢ２ for i)とは?

2.パフォーマンス測定方法

3.測定結果

4.考察

5.ストレージエンジンをどう使うべきか

6.残された課題

© 2008 IBM Corporation

®

2

MySQL on IBM i

•Step 1: MySQL データベースをi5/OSでサポート

– 2007年8月より利用可能 – MySQLベースのアプリケーションをi5/OS上で稼働させることを可能にした

•Step 2: MySQLとDB2 for iを統合

– MySQLベースのアプリケーションがIBM iのDB2にデータを格納できる

– 2009年前半に利用可能

System iのお客様は使い慣れたDB2 for iのデータストアを使用しながら、数千もの新しいオープン・ソース・アプリケーションを使用することができる

© 2008 IBM Corporation

®

3

MySQLストレージエンジンのアーキテクチャー

• ２階層構造のデータベース・サーバー

–上位階層はSQLの構文解釈と最適化機能を含む

–下位階層は複数のストレージエンジンで構成される • SQL階層はストレージエンジンがテーブルの管理を行う部分からは独立

• クライアントはSQLステートメントの実行にどのエンジンが使用されるかを関知する必要はない

• DB2 for i はIBMDB2Iという名称でサポート

構文解釈 最適化 データへの

アクセス

MyISAM InnoDB Memory MySQL

Cluster Other*

IBMDB2I

(DB2 for i)

Pluggable ストレージエンジン

MySQL データベース・エンジン

CREATE TABLE

ALTER TABLE で選択

© 2008 IBM Corporation

®

4

なぜIBMDB2Iか?

DB2 for i

既存のRPG

アプリケーション

PHPによる

パッケージ etc.

MySQL

IFS on IBM i

新規

アプリケーション

Java/JDBC/ODBC

DB2 for i

既存のRPG

アプリケーション

新規のPHP

アプリケーション

DB2 Driver

新規のRPG/DB2

アプリケーション

DB2 for i

PHPによる

パッケージ etc.

MySQL

IBMDB2I

PHPのサポート

MySQLのサポート

IBMDB2Iの

サポート

© 2008 IBM Corporation

®

5

IBM i

MySQL on IBM i PASE

DB2 for i

テーブル

MySQL

テーブル

IBM i (DB2) インターフェース

IBMDB2I

MySQLインターフェース

MySQL IBMDB2Iの概要

• IBMDB2IをストレージエンジンとしてMySQLでテーブルを作成すると、実体はDB2 for iのテーブル（物理ファイル）がIBM iネイティブ環境に作成される

• 作成されたDB2 for iのテーブルにはIBM iネイティブ・インターフェース(CLコマンド、RPG、DB2のSQL)からアクセスが可能

RPG/COBOL

/CLP

PHP

© 2008 IBM Corporation

®

6

IBMDB2Iの主な特徴と考慮点

MySQLインターフェースで作成されたテーブルおよび索引のみがIBMDB2Iで認識される – DB2のCREATE TABLEステートメントやCLコマンドのCRTPFで作成した表/物理ファイル、索引/

論理ファイルはMySQLから認識されない – 第二段階でこの機能の実装を予定

テーブルに関連づけられるストレージエンジンはいつでも変更することが可能 – ‘ALTER TABLE myisamtable ENGINE=ibmdb2i;’ のように容易に変更が可能 – 変更操作の間すべてのデータがコピーされる – 既存のMySQLによるWebアプリケーションのデータをDB2のデータに移行することが可能

MySQLインターフェースによる操作にはIBM iのユーザーは不要 – MySQLのユーザー認証および権限管理のしくみが使用される – MySQLインターフェースで作成された表や索引をIBM iのインターフェースでアクセスする場合は

IBM iのユーザー認証/権限が必要

ダブルバイト文字は物理ファイル上ではユニコード(UTF-16）で格納される – MySQLインターフェースで指定する日本語可能のコードページはIBM iの物理ファイルではUTF-

16(CCSID1200)として定義される

MySQLストレージエンジンパフォーマンス測定

目的 １．ストレージエンジン ＩＢＭＤＢ２ｉとＩｎｎｏＤＢで テーブルアクセスのパフォーマンス性能の差を検証する ２．ストレージエンジン経由とＮａｔｉｖｅ経由 （ＲＰＧ、ＳＱＬＲＰＧ）でのパフォーマンス性能の差を 検証する

測定方法

７種類のプログラム/データベース/ストレージエンジンを使い

４種類のデータ操作で処理速度を測定する

MySQLストレージエンジンパフォーマンス測定

データ操作内容INDEX/LF SELECT INSERT UPDATE DELETE

PHP(SQL) MySQL/IBMDB2i あり

PHP(SQL) MySQL/InnnoDB あり

PHP(SQL) DB2/400直ｱｸｾｽ あり

RPG DB2/400直ｱｸｾｽ あり

SQLRPG DB2/400直ｱｸｾｽ あり

PHP(SQL) DB2/400直ｱｸｾｽ なし(JOINﾌｧｲﾙ)

RPG DB2/400直ｱｸｾｽ なし(JOINﾌｧｲﾙ)

1万件中100件を抽出

1万件ﾚｺｰﾄﾞ作成

1万件中100件を更新

1万件中100件を削除

なし

データベース/ストレージエンジンプログラム

データ操作はそれぞれ５回行い平均値を測定する

スペック OS:6.1 プロセッサ:#8327(3800CPW) メモリ:2G ディスク:420G

ＳＥＬＥＣＴ測定結果

MySQLストレージエンジンパフォーマンス測定

0

0 .01

0 .02

0 .03

0 .04

0 .05

0 .06

0 .07

0 .08

0 .09

0 .1

処理時間

(

秒

)

PHP/IBMDB2i PHP/InnoDB PHP/DB2 400 RPG/DB2 400 SQLRPG/DB2 400

ＳＥＬＥＣＴ測定結果（ＪＯＩＮファイル）

MySQLストレージエンジンパフォーマンス測定

0

2

4

6

8

10

12

処理時間

(

秒

)

RPG/DB2 400 PHP/DB2 400

0

0 .02

0 .04

0 .06

0 .08

0 .1

0 .12

0 .14

0 .16

0 .18

0 .2

処理時間

(

秒

)

ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ 測定結果

MySQLストレージエンジンパフォーマンス測定

INSERT UPDATE DELETE

※INSERTのみ処理時間結果の100分の1で記載してあります。

PHP(MySQL /IBMDB2i)

PHP(MySQL /InnoDB)

PHP(DB2/400直アクセス)

RPG(DB2/400直アクセス)

SQLRPG(DB2/400直アクセス)

MySQLストレージエンジンパフォーマンス測定

考察 １. MySQLのテーブルに直接アクセスするInnoDBの方が IBMDB2i経由でNative DBにアクセスするより パフォーマンスが良い ２. INSERTを除けばInnoDBはRPGと遜色のない パフォーマンスとなった ３. １テーブルへのSELECTではPHPがRPGより約8倍処理時間が かかっていた。JOINテーブルへのSELECTでは約36倍となった (注)今回SQLのチューニングは行わなかった。 実施した場合、パフォーマンスは大きく変わってくる可能性がある

ストレージエンジンをどう使うべきか

分科会のレコメンデーション

1. ストレージエンジンに向いた用途を考えて利用する

2. 既存のアプリで作成したDBを直接ストレージエンジンからアクセスできないことに留意する

3. SQLでのアクセスする場合バッチ処理は避けた方が良い。( SQLのチューニング方法に十分精通している場合は別)

4. MySQLとNative DB の違いをよく理解したうえでマッピングを行う。

メンバーの概念がない

ダブルバイトはUTF-16 (CCSID1200) 、項目属性は’G’となる

5. セキュリティ対策は万全に

IFSへのウィルス感染

SQLを利用したデータ改ざん(アプリの脆弱性をついた攻撃)

ストレージエンジンをどう使うべきか - 用途を考えて利用する

IBMDB2iは既存のIBM iのDB資産を活かしながら、これと連動した

Webアプリケーションを構築していくうえでの有力な手段である。

但しRPGでNative DBをアクセスするのと同じにPHPからのアクセスが

できるわけではない。

想定される主な用途

1.MySQLのデータを既存アプリに取り込む

2.既存アプリのデータをMySQLに複製して使用する

3.情報系アプリケーションからのMySQLデータの利用

4.MySQLのデータをレコードレベルでレプリケーションする

ストレージエンジンをどう使うべきか - 用途を考えて利用する

1.MySQLのデータを既存アプリに取り込む

例:

ECサイトのPHPパッケージを導入し、発注のトランザクションデータを既存の受注システムに取り込む

© 2008 IBM Corporation

®

16

IBM i ネイティブ

既存アプリケーション

既存アプリケーションへの新規アプリケーション・データの取り込み

MySQL IBMDB2Iの活用例

MySQL

新規アプリケーション

IBM i(DB2 for i)

MySQL on IBM i

IBMDB2I

MySQLを使用するPHPのパッケージなどで構築したアプリケーションから既存アプリケーションに必要なデータを取り込む処理をDB2インターフェースで作成することができる

ジャーナル

管理

既存アプリ・データ

バッチ処理

バックアップ

MySQL

新規アプリ・データ

データ取り込み

処理

ストレージエンジンをどう使うべきか - 用途を考えて利用する

2.既存アプリのデータをMySQLに複製して使用する

例:

ECサイトのPHPパッケージを導入し、既存システムでの入出庫処理後の在庫マスターをパッケージのマスターにコピーする

© 2008 IBM Corporation

®

18

IBM i ネイティブ

既存アプリケーション

既存データを利用する新規MySQLアプリケーションの構築

MySQL IBMDB2Iの活用例

MySQL

新規アプリケーション

IBM i(DB2 for i)

MySQL on IBM i

IBMDB2I

MySQLを使用するPHPのパッケージなどで新規アプリケーションを構築する際に、マスター・データなどの既存データの取り込みを容易に行うことができる

ジャーナル

管理

MySQL

新規アプリ・データ

既存アプリ・データ

バッチ処理

バックアップ 既存アプリ

複製データ

複製機能

IBMDB2I

ストレージエンジンをどう使うべきか - 用途を考えて利用する

3.情報系アプリケーションからのMySQLデータの利用

例:

日次の売り上げ情報をWebのポータルからアクセスするPHPのアプリケーションを作成し、全社員が共有する。PHP/MySQLのプログラミングスキルが社内に無い場合でも、参照されるDBさえ社内で用意すれば表示するプログラムを外注するのは比較的容易。

© 2008 IBM Corporation

®

20

IBM i ネイティブ

既存アプリケーション

情報系アプリケーションからのMySQLデータの利用

MySQL IBMDB2Iの活用例

MySQL

新規アプリケーション

IBM i(DB2 for i)

MySQL on IBM i

IBMDB2I

既存または新規の情報系アプリケーションに既存データと同様にMySQLアプリケーションのデータを加えることができる

MySQL

新規アプリ・データ

既存アプリ・データ

情報系アプリケーション

データの

抽出・蓄積

データの

参照・分析

データの加工

ストレージエンジンをどう使うべきか - 用途を考えて利用する

4.MySQLのデータをレコードレベルでレプリケーションする

MySQLのデータがIFSにある場合は、レコードレベルの変更をOSで検知できない。 既存のアプリケーションとは独立したWebアプリケーションでもストレージエンジンによってDB2に書き込んだ場合は、レコードレベルでのリプリケーションが可能になる。

例:

PHPパッケージでMySQLに書き込まれた発注トランザクションデータをリプリケーションしてディスク障害や災害に備える。

© 2008 IBM Corporation

®

22

IBM i ネイティブ

既存アプリケーション

HAソリューションへのMySQLデータの組み込み

MySQL IBMDB2Iの活用例

MySQL

新規アプリケーション

IBM i(DB2 for i)

MySQL on IBM i

IBMDB2I

既存のHAのしくみにMySQLアプリケーション・データを容易に加えることができる

MySQL

新規アプリ・データ

既存アプリ・データ

HABPソリューション(ORION,MIMIX.Data

Mirror)

クロスサイト・ ミラーリング

切り替え可能

IASP

残された課題

今期の分科会活動でできなかった以下の点を今後検証していきたい。 1. ストレージエンジンを変更したときにデータはコピーされる？ ⇒InnodeからIBMDB2i、の変更をALTER TABLEで試してみる。逆も行う。 2. ＭｙＳＱＬインターフェースによる操作にはＩＢＭ iのユーザーは不要？ ⇒ジャーナルから実行ユーザーやジョブを確認して、ユーザーの認証をどのように行う

べきかを検証する。 3. 既存アプリケーションとのダブルバイトのデータ交換をどのように行うべきか? ⇒ＣＣＳＩＤ＝５０３５、5026など多くのユーザーで使われている文字コード間のコ

ピーは可能か試してみる。 ⇒項目属性は’G’をRPGでアクセスする場合の留意点 (SO/SIの処理をどうするか)

を明らかにする。 4. ＳＱＬでアクセスする場合のパフォーマンスチューニングを試してみる。