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、性能信頼性も満たしている、より大規模システムに向けた機能には不満</p>
      • パーテション機能ない 5.1で対応予定 検証してから入れましょうにしている
冗長構成
  • 非同期シングルマスタ レプリケーション
  • 同期シングルマスタ 共有ディスク、商用クラスタ DRBD # 今回は商用クラスタを使った
  • 同期マルチクラスタ MySQL Cluster 最近出てきた
事例紹介 サービス業L社
  • プロジェクト管理システム
  • 負荷分散(ロードバランサー)、DBもすべてオープンソースに出来ないか
    • CentOS, Apache, mod_jk, JBoss AS, MySQL</p>
      • 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
  • 表領域ファイルにテーブルデータとインデックスを格納</p>
    • テーブルごとにデータファイルの作成も可能
    • 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クエリを大量に発行するアプリケーション
  • 高い可用性が要求される
制限
  • 設計見積よりもデータ容量が大きくなってしまったら</p>
    • MySQL Cluster だけでは難しい 止めなくてはいけない
  • オンラインでマイグレーションできる 住商の製品であるらしい
まとめ
  • MySQL Cluter 6.2 は使える</p>
    • 海外での事例は多数
    • 日本でも増えてきている
  • 住商情報のwebで資料配布する MySQL でもwebにのせる予定

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

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

15:00-15:50

用語の定義
  • Instance MySQLの1つのプロセス
  • レプリケーションとは
    • 同じデータをもうひとつにコピーされる、自動的に non-blocking
  • user applicatin – MySQL instance(binlog) – MySQL Slave Instance(Relay binlog)
    • スレーブはより長いログを持つ 迅速さではなく保持するように働く
  • 5.0 Architecture
    • マスター スレーブにつなげる、マスターへつなげる
  • Clustering はレプリケーションとは違う
    • レプリケーションはリアルタイムではない
    • レプリケーション自身の障害を tolerant できない
    • 2つのフェーズをコミットできない
  • Cluster はMySQL Instance が Cluster とやり取りを行う
  • MySQL CLuster は同時にトランザクションを行う
    • memory 上で処理する
  • Read Replication Cluster
    • 非同期、書き込み
    • フェールオーバーしやすい
  • Application Cluster
    • User Application — MySQL InnoDB — MySQL MYISAM が応答
  • full text and Innodb
  • Replicate Data to separate host
  • blackhole binlog だけに残したい I/O は

以下はバッテリー切れのため手書きメモ程度。。。

</div>