MySQL ユーザコンファレンス 2008 1日目のメモ

アメーバブログ-DBチーム

    • パフォーマンス改善
    • OS,サービスにあわせたMySQL.mMeasureのRPM
    • MySQLサーバーの運用方針、監視
    • データセンターの移設
    • 新技術の検証導入検討
Server構成
  • 2006
  • Oracle10g RAC
    • Active3台,Standby1
  • MySQL
    • Master1:Slave41台
    • 記事、コメント、トラックバック Oracleから移行
    • Replicationのtrafficでは問題ない
    • Replicationのtrafficを圧縮することも検証済み
    • Masterはアクティブスタンバイでfailoverは手作業
    • Replication_to_tableで負荷分散
  • ストレージ
  • スペック
    • 4億PV/month->50億PV/month
  • キャッシュ
  • App
Oracle->MySQL移行について
  • Orale ->憩うようバッチ -> MySQL
    • 時間がかかりすぎる
  • Oracle dump -> scp -> LOAD DATA IN FILE
    • 4時間で終了
PostgreSQL->MySQL移行について
  • PG Clusterを使っていたが動作が不安定だったのでMySQLに移行
  • \copy テーブル -> scp -> LOAD DATA IN FILE
    • 45分で終了
DB2->MySQL移行について
  • 外注システムを内製に移行したときの遺産
  • \export テーブル -> scp -> LOAD DATA IN FILE
    • 2時間で終了
    • 1.5GB
まとめ
  • 複雑な分散がないのであれば各DBが持ってるツールを作る
  • LOAD DATA IN FILEが早いよ
MySQLに適した画面構成
  • 年月毎に記事をリスト

SELECT COUNT(*) FROM blogs WHER blog_id
SELECT : FROM blogs LIMIT ...

  • リンクを表示するしないかに関して3種類のquery
  • Oracle2qury -> MySQL 16query
  • Engine MyISAM
  • User毎の水平分散
  • サーバ増設だけではスケールアウト不可能
  • Disk I/Oが一番の犯人
  • [最初へ](一番古い記事へリンク)が重い
I/O軽減の方法
  • INDEXを見直す
    • explainの結果をUsing Indexを使う
    • WHERE ORDER BY で使っているカラムをすべてIndexに追加
    • Using filesortは一番だめ
  • SQLを見直す
    • SELECT句を記事IDのみに変更
    • Using where;Using Index
    • Where句はプライマリーIDのみ
    • Indexを追加したくない カラム追加で対応できないか
    • INDEX = Disk I/O増加
結果
  • Disk I/Oは 1/3になった
  • SQLの発行は一分間に35,000-45,000
  • SQLの発行を増やしても検索範囲を小さくする
  • Using indexでDisk I/Oは軽減できる
  • MySQLは INDEXを 的確に利用することでOracleにも勝る

ストレージエンジンとファイルシステムの検証

  • 環境
    • CentOS4
    • ext3
    • MySQL 4.1.21
      • 性能を含め安定している
      • Blogはすべてこのバージョン
    • MySQL 5系
      • 積極的には使ってないよ
    • MyISAM
      • 扱いやすい
      • パフォーマンス
      • table lock -> テーブル分割
    • InnoDB
      • 扱いにくい
      • amebaでは嫌われ者
  • GNU/Linux ext3 + MyISAMは黄金解か?
  • ファイルシステム
    • ext3
      • CentOS4.6/2.6.9
    • xfs
      • CentOS4.6/2.6.9
    • zfs
    • zfs
    • 5.1のα
    • ブログの本番データをReplication
    • 2億件150テーブル分割
    • Insert 300/m
    • 30,000 query/m
検証結果
考察
  • xfs
    • 思っていたよりもよい結果
    • 遅延名路ケーsyんが利いている
  • zfs
    • 書き込みはext3よりよい
    • RAID等組みやすい
結果
  • xfs + MySQLがよい結果
なぜ自作サーバ?
  • コストパフォーマンス
  • スモールスタート
  • スキルアップ
  • CPU Dual Core x 4G
  • \24,360
  • 値段は6割り程度で組める
  • SSD->raw device
  • SW-RAID0
  • ext3
  • journal -> ordered -> write
  • HW-RAID
    • DB でもOK
  • SW-RAID
    • 構成に時間がかかる
  • SSD
    • 読み込みは抜群

データベースのインフラ設計

高可用性設計
  • 99.999%の可用性
  • MySQL Replication
  • MySQL Replication
    • Master -> Slabe
    • Webで多数実績
    • 用途
      • 参照性能を向上
      • Webアプリケーションでは参照95%更新5%(http://digg.com)
      • バックアップ用途
      • 基本はデータ一方向でのコピー
      • bin-logを利用
  • 方法
  • master1対slaveたくさん
  • master > slave
    • OK
  • master > multi slave
    • OK
  • multi master > slave
    • NG
  • master > slave > multi slave
    • OK
    • USのチケットサービスで実績あり
    • 分散する人と更新を受ける人を分ける
  • master > master
  • 循環型master > master
    • 更新の順序が入れ替わっちゃうかも制約があるよ
  • DRBD
    • 一般的なIPネットワーク上で動作
    • 分散ストレージ
    • いわゆるnetwork RAID
    • 用途
      • Linux上のみ
      • 特殊なネットワークコンポーネント不要
      • 高いパフォーマンス
      • 障害発生時の自動修復
  • Active/Passive構成
  • Replication master の冗長か
    • masterが一台に集中
      • DRBDをつかった高可用性
      • SlaveにはReplicate_to_tableで一部だけコピー
      • Slaveをmemory strageに
  • MySQL Proxy
  • MySQL Cluster
    • shared nothing型
    • 特別なハード不要
    • In memory DB
    • 通信事業者の加入者DB用
    • NDB APIというSQLを介さなくても直接アクセス可能なAPIあり
  • 分散キャッシュシステム(memcached)
  • mixi ,livejournal,Yahoo!
  • MySQLからキャッシュを読み書きするUDFが開発中
  • MySQL Enterpriseにて技術サポート中
拡張方式設計(性能/ストレージ)
セキュリティ設計
  • 以下のレベルで制御可能
    • Level 1 - User
    • Level 2 - db
    • Level 3 - tables
    • Level 4 - columns
    • Level 5 - procs(ストアド/ファンクション)
    • user/client host or ip /passの組み合わせで認証情報を構成
  • 実装済みの対策
    • データ暗号化
    • 経路暗号化SSL
    • Level 5のユーザ管理
    • MySQL Enterprise MonitorのセキュリティAdvisorによる監視
  • 未実装の対策
    • role
    • カラムに暗号化指定でかってに暗号化とか
    • データ監査機能
    • OSレベル等外部認証との連携
バックアップ設計
  • InnoDB HotBackup(有償)
    • 稼動中のサーバからバックアップ取れるよ
  • zmanda recoverry manager for mysql
    • GUIのバックアップツール
監視方式設計,メンテナンス方式設計
  • MySQL Enterprise Monitor w/Query Analyzer
    • Query解析機能
    • Index追加やチューニングの提案も自動的に行う
    • 自動的パラメータチューニング機能があるDBがあるが
      • 勝手にやるところが怖いよね
      • Advisorはあくまでも提案

MySQL Enterprise の紹介

  • MySQL Workbench
    • MySQL Query Browser
      • グラフィカル化
    • MySQL Administrator
      • GUIの管理ツール
    • MySQL Migration Toolkit
    • MySQL Workbench
      • DBを文章化するだけではなく
      • リバース、フォワードエンジニアリングも可能
      • Win OK Linux Macは今後でますよ
  • Database Design
    • 関係可視化したほうが実際すごくやりやすい
    • DBを直感的にデザイン
    • DBが複雑化すればするほど存在価値が高い
    • 特徴
      • 複数のモデルを同時に扱える
      • zoom in/outができる
  • Forward Engineering
  • Reverse Engineering
    • 既存のDBがすでに実装されているけど修正が加わってどうなってるかを可視化したい
    • 開発環境、本番環境で作ったDBと可視化して比較、同期させる
    • 根本のモデルを可視化して理解する
    • Designがそもそもの遅い原因かを突き止める
  • Documenttation
    • 設計時のテキストベース/HTMLのoutput
  • MySQL Enterprise
  • MySQL Enterprise monitor
  • MySQL Query Analyzer

プロトコル解説

  • endian
  • 固定長の場合
    • 16進数表記
  • 可変長の場合
    • 先頭1-9バイトで値を表現

0-250:その値が実際の値
251:NULL
252:後続の2byte
253:後続の4byte
254:後続の8byte

  • 固定長文字列
    • そのまま
  • 可変長:NULL終端
    • 文字列の終端を0x00で埋める
  • 可変長
    • 文字列長を1-9byteで表現
  • 認証時のPacket Flow

client server
|--->tcp connect------------>|
| |
|<--handshake initialization-|
| |
|-client authentication----->|
| |
|<-OK Packet/Error Packet ---|

MySQL/Ruby

  • MySQL/ruby
    • libmysqlclient wraper
  • Ruby/MySQL
  • Drizzle計画
    • Full Duplex(全二重通信)
      • クライアントから巨大パケットを送っている最中にサーバからすぐにエラーを返せる
    • 連続通信
      • 複数のコマンドを、クライアント->サーバに対して一度に送信
    • 読み取り専用フラグ
      • MySQl Proxyなどに、書き込みをマスターに、読み込みをスレーブに
      • 現状MySQl Proxyは文字列解析で実現 SELECTがあったらスレーブ
      • SELECTでも最新情報が欲しい場合がある そういうフラグがあったらいいよね
  • server のmy.cnfでautocommit 0のモードがあり clientにパケットでautocommit 0を返す
  • connection poolingの実装だと常にSET AUTO COMMIT 0 を投げてからはじめる
  • bench markがMySQLだけその分遅くなる