モノノフ日記

普通の日記です

DeNA Technology Seminar #2 に参加してきました。

DeNA Technology Seminar #2 を開催します - Technology of DeNA
MySQL特集、ということだったので参加してきました。トピックは下の3つでした。

  1. Spider
  2. handlersocket plugin
  3. MySQL 5.4/5.5の新機能

Spider

感想

Spiderは発表資料と発表者の斯波さんのお話が上手だったのもあり、完全無欠のストレージエンジンのように見えてしまっていたけど用途により向き不向きはあるだろうからそのあたりをちゃんと見極めて使いたいと思いました。実際の導入事例が3件(Sagool.tv, KADOKAWord.jp, マイクロアド)紹介されましたが、いずれもレコード数の増加によるバッチ処理の負荷分散に利用されていたようです。
メモでまとめましたが今後の展開がいろいろ凄いことになってたのでSpiderが特定用途のエンジンからからスタンダードなストレージエンジンへ進化していくのかもしれないなぁと感じた次第です。

メモ
  • 複数のデータベースサーバにあるテーブルを束ねて1テーブルとして利用することを可能にするプラグイン
  • ローカルDBからリモートDBにテーブルリンクを生成
  • SpiderのDB shadingはアプリエンジニアが実装する必要がない
    • データの同期
    • データのマネジメント
  • チームラボの導入事例
    • 3000万レコードを超えたあたりでバッチ処理が24時間で終わらない
    • MySQL Clusterの導入も考えたが断念
    • Spider導入後、パフォーマンスが10倍改善、バッチ処理は5倍改善(8時間で終了するように)
    • 既存のアプリケーションの変更が不要だった
  • KADOKAWord.jpの導入事例
    • SpiderとBlackholeの組み合わせ
  • マイクロアドの導入事例
    • マスターDBをshading
    • 2000万レコードから1億レコードの更新が可能に
  • まとめ
  • MariaDB対応
    • バンドルしてもらえる話が進行中
  • BKA対応
    • 35倍性能向上
  • レプリケーションリトライパッチ
  • 可用性対応
    • テーブル・パーティション単位でのバックアップ
    • ラウンドロビンの重み付け
  • Q&A
    • Spiderの全文検索対応は余裕ができたらやりたい
    • re-shading
      • Vertical Partitioningというエンジンと組み合わせることで可能
      • 導入事例だとフェイルオーバーはアプリ対応、reshadingはやってない

handlersocket plugin

感想

DeNAの樋口さんの発表で、MySQLSQLパース処理をすっ飛ばして単純なクエリを高速化する、というプラグインのお話でした。
原理はわかるんですが、実際にMySQLの中身にかなり突っ込んだ内容になっていったのであまりついていけず。お話されてる内容を聞いて追っかけるので必死でメモもまともに取れず。。しかし、命題を掲げて、現状の問題点を確認して、何がどのように改善されるか性能測定して、将来の展望を述べて、という学会で論文発表聞く感じの発表はひさびさだったので興味深く拝聴できました。あまり内容理解できないところもあったので、できれば資料公開していただきたいです!

メモ
  • 樋口さん
  • 単純ならCRUD処理を高速処理したい
    • SQL処理を省略
    • 単純処理に適用可能な最適化
  • 同じデータMySQLでも処理したい
    • SQLに置き換えていきたい
  • 概要
    • ストレージエンジンへの非SQLインタフェース
    • TCP/IPでリクエストを受けて直接叩く
    • 独自プロトコル
    • C++, Perlのクライアントライブラリ
    • 後日公開予定
  • 性能比較
    • 単純な参照クエリで数倍〜10倍程度
    • 取得列数が多い場合に特に有効
  • 実行例
    • ほぼテキストプロトコル
  • oprofile - libmysql/mysqldとhandlersocketのプロセスを比較
  • Q&A
    • 本番環境でテスト運用中

MySQL UPDATE

感想

漢(オトコ)のコンピュータ道で有名な奥野さんの発表でした。ブログで度々書かれていたMySQL 5.4/5.5の新機能についてまとめた発表でわかりやすかったです。5.5がGAになるのが待ち遠しいです。会場出て帰宅しながら疑問に思ったことを書き留めておきます。

  • 既存の utf8 から、4バイトUTF8である utf8mb4 への移行って簡単なのか?
  • Semi-Synchronous Replicationで更新時にバイナリログがslaveに送られて、masterにackが返ってくるまでのオーバーヘッドは?
メモ
  • Innodb
    • 5.1
      • Innodb Plugin 1.0が利用可能
      • ビルトインInnodbがデフォ
    • 5.4
      • ビルトインinnodbをベースに性能改善
      • 改善内容はinnodb pluginに移植
    • 5.5
      • デフォで Innodb Plugin 1.1
  • Innodb Plugin 1.0
    • 既存のデータファイルは互換性あり
    • Fast Index Creation
      • セカンダリインデックスの作成が高速化
      • プライマリキーには影響なし
      • 書き込む量が減ってる分速い
      • 8倍くらい高速化した例もある
    • データ圧縮
      • データサイズ縮小・I/O減少
    • DYNAMIC
      • 新フォーマット
      • TEXTが完全にぺージ外に
    • グループコミット
      • クラッシュリカバリ時間の短縮
      • ログファイルサイズを気にしなくてよい
  • Innodb Plugin 1.1
    • Expoのスライドが公開されてる
      • Mikael Ronstrom氏のスライドが必見
    • 4バイトUTF-8
    • Semi-Synchronous Replication
      • マスターがクラッシュするとマスターにしか存在しないデータが存在
      • slaveの1つが完全同期することを保証する
    • COLUMNS PARTIONING
      • カラムの値をそのまま評価
      • 複数の値を利用可
    • DTrace
    • PERFORMANCE SCHEMA
      • DTraceに似た情報収集と表示の仕組み
      • プロファイリングにも利用可能
      • 内容は相当マニアック
    • SIGNAL / RESIGNAL
  • トラブルシューティング
    • 仕様を理解する
    • 自分でやってみる
    • ソースコードを読む
    • OSに詳しくなる
  • Q&A
    • sync_binlog=1にすると、グループコミットが遅い
      • 現在はそういう仕様。改善できるかどうかは未定。

*1:重かったのでリンクに変更しました