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

2010/02/17
MySQLストレージエンジンの検証
【 OpenSource協議会 – IBM i 】
i to Open分科会
MySQLストレージエンジンの検証
1. ストレージエンジン(ＭｙＳＱＬ on ＩＢＭ i、
ＤＢ２ for i)とは?
2. パフォーマンス測定方法
3. 測定結果
4. 考察
5. ストレージエンジンをどう使うべきか
6. 残された課題
®
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のデータストアを使用しながら、数千もの新しい
オープン・ソース・アプリケーションを使用することができる
2
© 2008 IBM Corporation
®
MySQLストレージエンジンのアーキテクチャー
• ２階層構造のデータベース・サーバー
– 上位階層はSQLの構文解釈と最適化機能を含む
– 下位階層は複数のストレージエンジンで構成される
• SQL階層はストレージエンジンがテーブルの管理を行う部分からは独立
• クライアントはSQLステートメントの実行にどのエンジンが使用されるかを関
知する必要はない
• DB2 for i はIBMDB2Iという名称でサポート
MySQL データベース・エンジン
構文解釈
最適化
データへの
アクセス
CREATE TABLE
ALTER TABLE
で選択
Pluggable ストレージエンジン
MyISAM
InnoDB
Memory
MySQL
Cluster
Other*
IBMDB2I
(DB2 for i)
3
© 2008 IBM Corporation
®
なぜIBMDB2Iか?
既存のRPG
アプリケーション
既存のRPG
アプリケーション
新規
アプリケーション
Java/JDBC/ODBC
DB2 Driver
PHPのサポート
DB2 for i
DB2 for i
PHPによる
パッケージ etc.
PHPによる
パッケージ etc.
MySQLのサポート
新規のRPG/DB2
アプリケーション
MySQL
MySQL
IBMDB2Iの
サポート
IFS on IBM i
新規のPHP
アプリケーション
IBMDB2I
DB2 for i
4
© 2008 IBM Corporation
®
MySQL IBMDB2Iの概要
IBM i
RPG/COBOL
/CLP
DB2 for i
テーブル
IBM i (DB2) インターフェース
IBMDB2I
PHP
MySQL
テーブル
MySQLインターフェース
MySQL on IBM i PASE
•
•
IBMDB2IをストレージエンジンとしてMySQLでテーブルを作成すると、実体は
DB2 for iのテーブル（物理ファイル）がIBM iネイティブ環境に作成される
作成されたDB2 for iのテーブルにはIBM iネイティブ・インターフェース(CLコマン
ド、RPG、DB2のSQL)からアクセスが可能
5
© 2008 IBM Corporation
®
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の物理ファイルではUTF16(CCSID1200)として定義される
6
© 2008 IBM Corporation
MySQLストレージエンジンパフォーマンス測定
目的
１．ストレージエンジンＩＢＭＤＢ２ｉとＩｎｎｏＤＢで
テーブルアクセスのパフォーマンス性能の差を検証する
２．ストレージエンジン経由とＮａｔｉｖｅ経由
（ＲＰＧ、ＳＱＬＲＰＧ）でのパフォーマンス性能の差を
検証する
MySQLストレージエンジンパフォーマンス測定
測定方法
７種類のプログラム/データベース/ストレージエンジンを使い
４種類のデータ操作で処理速度を測定する
データベース/
プログラムストレージエンジン
PHP(SQL)
MySQL/IBMDB2i
PHP(SQL)
MySQL/InnnoDB
PHP(SQL)
DB2/400直ｱｸｾｽ
RPG
DB2/400直ｱｸｾｽ
SQLRPG
DB2/400直ｱｸｾｽ
PHP(SQL)
DB2/400直ｱｸｾｽ
RPG
DB2/400直ｱｸｾｽ
INDEX/LF
あり
あり
あり
あり
あり
なし(JOINﾌｧｲﾙ)
なし(JOINﾌｧｲﾙ)
データ操作内容
INSERT UPDATE
SELECT
1万件中
100件を抽出
1万件
ﾚｺｰﾄﾞ
作成
スペック
OS:6.1 プロセッサ:#8327(3800CPW)
メモリ:2G
1万件中 1万件中
100件を 100件を
更新
削除
なし
データ操作はそれぞれ５回行い平均値を測定する
ディスク:420G
DELETE
MySQLストレージエンジンパフォーマンス測定
ＳＥＬＥＣＴ測定結果
0.1
0.09
0.08
0.07
処
理
時
間
0.06
0.05
(
秒
0.04
)
0.03
0.02
0.01
0
PHP/IBMDB2i
PHP/InnoDB
PHP/DB2 400
RPG/DB2 400
SQLRPG/DB2 400
MySQLストレージエンジンパフォーマンス測定
ＳＥＬＥＣＴ測定結果（ＪＯＩＮファイル）
12
10
処
理
時
間
8
6
(
秒
)
4
2
0
PHP/DB2 400
RPG/DB2 400
MySQLストレージエンジンパフォーマンス測定
ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ測定結果
0.2
0.18
0.16
0.14
処
理
時
間
0.12
0.1
(
秒
0.08
)
0.06
0.04
0.02
0
PHP(MySQL /IBMDB2i)
INSERT
UPDATE
DELETE
PHP(MySQL /InnoDB)
PHP(DB2/400直アクセス)
RPG(DB2/400直アクセス)
※INSERTのみ処理時間結果の100分の1で記載してあります。
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パッケージを導入し、発注のトランザクションデー
タを既存の受注システムに取り込む
®
MySQL IBMDB2Iの活用例
既存アプリケーションへの新規アプリケーション・データの取り込み
IBM i(DB2 for i)
IBM i ネイティブ
既存アプリケーション
既存アプ
リ・データ
バッチ処理
データ取り込み
処理
バックアップ
MySQL
新規アプ
リ・データ
MySQL on IBM i
MySQL
新規アプリケーション
ジャーナル
管理
IBMDB2I
MySQLを使用するPHPのパッケージなどで構築したアプリケーションから既存アプリケーショ
ンに必要なデータを取り込む処理をDB2インターフェースで作成することができる
16
© 2008 IBM Corporation
ストレージエンジンをどう使うべきか
- 用途を考えて利用する
2.既存アプリのデータをMySQLに複製して使用する
例:
ECサイトのPHPパッケージを導入し、既存システムでの入出庫処理
後の在庫マスターをパッケージのマスターにコピーする
®
MySQL IBMDB2Iの活用例
既存データを利用する新規MySQLアプリケーションの構築
IBM i(DB2 for i)
既存アプ
リ・データ
IBM i ネイティブ
既存アプリケーション
バッチ処理
複製機能
既存アプリ
複製データ
MySQL on IBM i
ジャーナル
管理
IBMDB2I
MySQL
新規アプリケーション
バックアップ
IBMDB2I
MySQL
新規アプ
リ・データ
MySQLを使用するPHPのパッケージなどで新規アプリケーションを構築する際に、マスター・
データなどの既存データの取り込みを容易に行うことができる
18
© 2008 IBM Corporation
ストレージエンジンをどう使うべきか
- 用途を考えて利用する
3.情報系アプリケーションからのMySQLデータの利用
例:
日次の売り上げ情報をWebのポータルからアクセスするPHPのアプ
リケーションを作成し、全社員が共有する。PHP/MySQLのプログ
ラミングスキルが社内に無い場合でも、参照されるDBさえ社内で用
意すれば表示するプログラムを外注するのは比較的容易。
®
MySQL IBMDB2Iの活用例
情報系アプリケーションからのMySQLデータの利用
IBM i(DB2 for i)
情報系アプリケーション
IBM i ネイティブ
既存アプリケーション
既存アプ
リ・データ
データの加工
MySQL on IBM i
MySQL
新規アプリケーション
データの
抽出・蓄積
IBMDB2I
MySQL
新規アプ
リ・データ
データの
参照・分析
既存または新規の情報系アプリケーションに既存データと同様にMySQLアプリケーションの
データを加えることができる
20
© 2008 IBM Corporation
ストレージエンジンをどう使うべきか
- 用途を考えて利用する
4.MySQLのデータをレコードレベルでレプリケーションする
MySQLのデータがIFSにある場合は、レコードレベルの変更をOSで
検知できない。
既存のアプリケーションとは独立したWebアプリケーションでもス
トレージエンジンによってDB2に書き込んだ場合は、レコードレベ
ルでのリプリケーションが可能になる。
例:
PHPパッケージでMySQLに書き込まれた発注トランザクションデー
タをリプリケーションしてディスク障害や災害に備える。
®
MySQL IBMDB2Iの活用例
HAソリューションへのMySQLデータの組み込み
IBM i(DB2 for i)
IBM i ネイティブ
既存アプリケーション
既存アプ
リ・データ
クロスサイト・
ミラーリング
MySQL on IBM i
MySQL
新規アプリケーション
HABPソリューション
(ORION,MIMIX.Data
Mirror)
IBMDB2I
MySQL
新規アプ
リ・データ
切り替え可能
IASP
既存のHAのしくみにMySQLアプリケーション・データを容易に加えることができる
22
© 2008 IBM Corporation
残された課題
今期の分科会活動でできなかった以下の点を今後検証していきたい。
1. ストレージエンジンを変更したときにデータはコピーされる？
⇒InnodeからIBMDB2i、の変更をALTER TABLEで試してみる。逆も行う。
2. ＭｙＳＱＬインターフェースによる操作にはＩＢＭ iのユーザーは不要？
⇒ジャーナルから実行ユーザーやジョブを確認して、ユーザーの認証をどのように行う
べきかを検証する。
3. 既存アプリケーションとのダブルバイトのデータ交換をどのように行うべきか?
⇒ＣＣＳＩＤ＝５０３５、5026など多くのユーザーで使われている文字コード間のコ
ピーは可能か試してみる。
⇒項目属性は’G’をRPGでアクセスする場合の留意点 (SO/SIの処理をどうするか)
を明らかにする。
4. ＳＱＬでアクセスする場合のパフォーマンスチューニングを試してみる。

Download Report