MySQL ユーザカンファレンス 2008 に行ってきました

勉強がてら MySQLユーザカンファレンス2008 に行ってきた。結構内容は濃かったと思うが、講演時間が50分の質問タイムなし＋資料配布なしなので、ちゃんと理解するには厳しい環境だった。当日のスライドは後日webで公開されるらしい。

Sunに買収されて有償商品の紹介が多かったような。各セッションは立ち見やキャンセル待ちが出るほどの盛況ぶりで、確かに MySQL のコアで最近な情報は本も含め出回っていない感がするので、それだけ需要があるということなのだろう。実際運用されている方の話も普段表には出ないので貴重だったかと思う。

以下、バッテリーが切れるまで取れるだけ取れたメモ。
# ノートPCのバッテリーは4時間くらい持ってくれればモバイルする意欲がもっと沸くのだが、、、
# あとは開場にコンセント用意してくれると大変ありがたい。

1日目 10/30

MySQLデータベースシステムの設計で役立つソリューション

サン・マイクロシステムズ MySQLビジネス統括本部梶山

14:00-14:50

クラスタリング高可用性

可用性＝稼働性
止めていい日数が多いほど可用性が高い
止めてもいい月間4日くらいレプリケーション

レプリケーション

シンプルな設定、マスター=>スレーブ、多数webでの実績
非同期型ほとんどの場合読み込みだけ参照性能を上げる
良い構成(M:S) 1:1、1:1:N(階層的)、1:N ならOK
- US チケットマスター階層的な構成で構築した
いまいちな構成 MS:MS、△構成
ダメな構成 N:1
書き込み性能UPは DRBD、Active/Passiveクラスタで冗長するケースが多い
- スレーブサーバで障害が起きた際には別のサーバに再接続
- テーブルごとにサーバを分けることも可能
MySQL Proxy オープンソース
- クライアントとサーバ間で稼働する
- ロードバランス
- フェールオーバー

DRBD

一般的なIPネットワーク上で動作
分散ストレージ、ネットワークRAID
Linux上のみで利用可能
ハートビートを飛ばしあって確認

Actve/passive

昔ながらの構成

MySQL Cluster

シェアードナッシング型クラスタ
複数の MySQL Server にて Nodes構成、Data複数にて Nodes 構成
ネットワーク越しに RAID 構成しているような感じ
Single Point of failure がない構成
MySQL Server~DataNode 間に NDB API を設けることが出来る

トータルとして大規模構成

データセンターごとに MySQL Clustre 同士をレプリケーション
CGE ライセンスが必要 Standalone では構成できない

memcached 分散キャッシュ

mixi, LiveJournal, Yahoo!, Facebook 大規模webサイトで利用
MySQLから伽主を読み書きする
UDFが開発中
MySQL Enterprise でSUNが対応可能
HP が公開しているドキュメント HP Open Source?

DRBD Plus 商用製品

ディザスタリカバリ

セキュリティ設計

ユーザ認証ユーザ名/パスワードが同じでも接続元が異なれば別アカウント
ユーザ権限 Level5 行列ごとに適用可能
実装済みデータ暗号化、SSL、MySQL Enterprise Monitor監視、mysql_secure_installationセキュリティ強化
実装予定ロールベースのアカウント管理、外部認証との連携開発状況は http://forge.mysql.com work logにて公開

バックアップ

MySQLバックアップ方法 Warm
mysqldump Warm
OSコピーコマンド Warm
mysqlhotcopy Warm
MySQL Administrator Warm
レプリケーション Hot
スナップショット Hot
InnoDB Hot Backup(有償) Hot

NetApp

外部ストレージ
スナップショットでのバックアップ

監視方式 MySQL Enterprise Monitor

一括監視可能なダッシュボード
クエリーアナライザー統計情報の分析が可能近日リリース
- SQL文に対してリクエスト数、レスポンス時間などwebからみれる
エージェントインストールが必要
アドバイザー機能あり
他ツールと連携メール通知、SNMP対応

金融機関向けMySQLを活用したシステム事例紹介

野村総合研究所情報技術本部オープンソースソリューションセンター(OSSC) 寺田

15:00-15:50

自己紹介

2003年オープンソース OSSC 設立
Linux、Tomcatなど使う MySQLパートナー契約
40種類のオープンソース扱う OpenStandia サービスというらしい
今後もオープンソースの導入が進むだろう

事例紹介金融会社

コスト削減でオープンソースを活用したい OSもDBまわりも
NRI DBエンジニアが商用製品の良いと思っているところ
- 採用実績、安定度、多くの技術者、ノウハウの展開、大規模システムでの事例
MySQLのメリット
- シンプルなアーキテクチャ
- 理解しやすい、設計が容易
- 圧倒的なコスト削減効果
導入前の実現可能性検証したダメだったら Oracle にする予定
- 性能面評価 Select(Index Scan/Full Scan),Insert
- 機能面の評価バックアップ、リカバリー、クラスター(冗長化)
- 結果耐えうると判断導入へ
構成 RedHat Enterprise + MySQL、JBoss AS、Apache httpd
- MySQL は2台構成
5年間コスト(初期費＋5年間保守費)で1/7へ短期間で完了
顧客より
- コスト削減はOK、性能信頼性も満たしている、より大規模システムに向けた機能には不満
 - パーテション機能ない 5.1で対応予定検証してから入れましょうにしている

冗長構成

非同期シングルマスタレプリケーション
同期シングルマスタ共有ディスク、商用クラスタ DRBD # 今回は商用クラスタを使った
同期マルチクラスタ MySQL Cluster 最近出てきた

事例紹介サービス業L社

プロジェクト管理システム
負荷分散(ロードバランサー)、DBもすべてオープンソースに出来ないか
- CentOS, Apache, mod_jk, JBoss AS, MySQL
 - JAVAを使った場合は mod_jk の高負荷時のパフォーマンスが良い
コスト削減効果 5年間コスト 1/5になった

事例紹介メディア企業 O社

インターネットサイト Tomcat、MySQLを採用
冗長には MySQL Cluster を採用
MySQL ServerとDataNodeのセット 2つ障害時にはフェイルオーバして、たすき状にデータが流れる
MySQL Cluster まだでたばかり 5.0.40以降は比較的安定している、くせがある、スケールアウトしやすい

事例紹介金融機関 D社

証券のオンライントレードシステム高い信頼性、高いピーク性
商用アプリケーションのサポートレベルが不満サポート期間短い3年バージョンアップが頻繁
1次切り分けは顧客実施、サポート1次窓口の質が悪かった、サポート履歴管理していない
オープンソースでサポートの質を上げたいソースが見れる
- JBOSS AS、OpenStandiaで7年間サポート
基幹DBは Oracle、参照用で MySQL
顧客側からハードのコストは下がっているがソフトのコストが負担になる
- 台数が増えてもコストが増えないスケールメリットでやすい

2日目 10/31

ストレージエンジンまとめて概要説明

サン・マイクロシステムズ MySQL ビジネス統括本部梶山

10:00-10:50

ストレージエンジンのメリット

例)メモリーストレージエンジン処理能力を向上、Archiveストレージエンジンディスク容量を削減
MyISAM オーバーヘッドを配して応答性能を向上
すべてのエンジンには外部からのアクセス方法は共通

ストレージエンジンの役割

データレイアウトどこに格納するか
インデックス実装アルゴリズム
メモリ利用データキャッシュ、バッファリング
トランザクション
同時実行ロックの単位、排他制御

MySQL ストレージエンジン SUNがつくっているもの

MyISAM : 標準、トランザクション対応していない、ファイルシステムの置き換え
Falcon(Alpha) : トランザクション
Memory : 高速ルックアップ、参照頻度が高いアプリ向け
Archive : SELECT/INSERT のみ、ロギングや監査向け
Merge : MySQL5.1より前のパーテショニング的機能
Federated : 分散配置したデータに透過的にアクセス
Custom : エンジンを開発するためのベース
Blackhole : 書き込んだデータをすべて飲み込む dev/null 的なエンジン

サードパーティ製ストレージエンジン

InnoDB : 標準的なトランザクションアプリケーション向け Oracleが作っている
InfoBright : GB-TB 級データウエアハウス向け
DB2 : IBM用

何を使っているか

2006年調査エンジン名一般ユーザ、Enterprise、OEM 割合
MyISAM 69%, 83%, 65%
InnoDB 60%, 79%, 54%
Memory 10%, 18%, 9%
Archive 5%, 6%, 1%
Merge 3%, 12%, 3%

次 5.1

プラグインとしてエンジンを追加できるようになる
出力先がログファイルではなくログテーブルにためるようになる(csvストレージエンジンで作られた) slow.log
SQLもしくはCSV形式で出力できるようになる

ストレージエンジンごとの性能の違い

Archive の INSERT処理能力はMyISAMの1.5倍くらい早い
Archiveの処理能力は商用DBのテーブルの1.6倍

その他こんなことも出来ます

CSVストレージエンジン : CSV形式で扱う、高速データローディング、インデックス利用不可
Bloackhole : 利用例 binログをレプリケーション多段間で受け渡すときに間に使う

コマンド

確認 show engines/G
CREATE TABLE 文で指定できる ENGINE = InnoDB;
変更可能 ALTER TABLE t ENGINE = MEMORY;
テーブルに設定したエンジンの確認 SHOW CREATE TABLE temp/G

MyISAM

1つのテーブルが3つのファイルで構成されている .frm, .MYD, .MYI
可搬性の高いストレージエンジン
トランザクション非対応、テーブルレベルロック
テーブルを圧縮可能圧縮後は読み取り専用になる myisampack コマンド実行(基本的にMySQLを停止して実行)
Fulltext, GISインデックスをサポート
Concurrent Insert をサポート

InnoDB

表領域ファイルにテーブルデータとインデックスを格納
- テーブルごとにデータファイルの作成も可能
- RAW デバイスを表領域として利用可能

Memory

データおよびインデックスはメインメモリ上に配置
ディスク上にはテーブル定義ファイルのみ存在

Federated

別のサーバ上のテーブルに接続するしているように見える

開発途上のエンジンもあり

MySQL Web の wiki?に開発中のものが試せるようだ

MySQL Clusterで高性能システムを構築する際のポイント

住商情報システム廣濱

11:00-11:50

MySQL Cluster とは

非共有ディスク型特別なHWいらない
アクティブ/アクティブ型
概要図より
- アプリ~SQL Node~DataNode
- 直接 DataNode に触れる NDB API がある
- MySQL 上位層 NDB(NDB API)~DataNode
- DataNode でデータの管理をしている

MySQL Clusterが利用するアプリケーション

SQL Node経由
NDB アプリケーション(JAVA/C++ アプリ)
- SQLクエリを発行することは出来ないが高速

MySQL Cluster 配布形態

MySQL Cluster 6.2.15 CGE/SE
エディションの違い Standard Edision/Carrier Grade Edition
- NDB Bindings なし/あり

ベンチマーク

CGE にて 25%UP 以前のものより性能向上

ディスクテーブル

メモリベース、ディスクベース、ディスクベース(チューニングなし) の順に
バッファーをチューニングする場合はメモリとあまり変わらない
DiskPageBufferMemory デフォルト64MB 可能な限り多く割り当てる

SQL Node

1台あたり50同時接続で最大性能等傾向は変わらない
CPU利用率はSQLNode 4台で初めて90%近くまで上昇
- シングルスレッドなので

InnoDBとMySQL Clusterの処理比較

スループット MySQL Cluster CGE6.2.13 > 5.12 > InnoDB
MySQL Cluster のほうが性能がいい
ただしバイナリログを出すと InnoDBは倍近い性能になった

ベンチマークまとめ

ディスクテーブルの全面的な採用はまだ早い
DataNodeはすくなく、SQLNodeはおおく、レプリカ数は少なく、同時接続数は50くらい
- MySQL Cluster 5.0 と同じ考え
DataNodeはシングルスレッドなので CPUコア数を増やしても性能はのびない
- 6.4 で改善される予定

システム構成例

非同期レプリケーションを SQLNode/DataNode/アプリケーションの2セット間でおこなう
ディザスタリカバリを防ぐ東京が落ちても大阪で提供し続ける

MySQL Clusterに適したアプリケーション

データの見積が設計時になる程度可能なシステム
JOINやSUB QUERYをほとんど利用しないアプリケーション
検索するカラムにはインデックスが張られているメモリ上に保持するので上限あり
単純なSQLクエリを大量に発行するアプリケーション
高い可用性が要求される

制限

設計見積よりもデータ容量が大きくなってしまったら
- MySQL Cluster だけでは難しい止めなくてはいけない
オンラインでマイグレーションできる住商の製品であるらしい

まとめ

MySQL Cluter 6.2 は使える
- 海外での事例は多数
- 日本でも増えてきている

住商情報のwebで資料配布する MySQL でもwebにのせる予定

MySQLデータベースレプリケーションを理解する

Sun Microsystems Inc. ブライアン・エーカー