日本MySQLユーザー会　2014年10月15日 - 開発の風景　〜KKZのSE日記〜

先日、日本MySQLユーザー会10月に参加してきましたので、そのレポなど。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション１　MySQL Centralで発表された内容
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

MySQLの開発人員は買収後も増加している。
昨年も5.5から5.6へのバージョンアップを果たした。
現在、5.7.5（DevelopMent Release）を出している。
一部の機能追加はEnterprise版（商用版）のみ対象となる。
　→監査ログを取るEnterprise Audit機能や
　　マルチスレッドのEnterprise Scalabilityなど。

現在でも用途はWebサーバのバックエンドが多い。

事例：Facebook
　　　Twitter
　　　Dropbox
　　　Booking.com
　　　組込の分野→Ciscoの機器内のDB
　　　Adobeソフトウェア内のリポジトリDBなど

よく聞かれるが、Oracle Databaseに近づける、という思想はなく、
現在のまま、Webサーバのバックエンドとして活躍していく流れを想定している。

- - - - -

What’s New 5.7

- - - - -

●5.7の主な改良点

・InnoDB：トランザクション処理性能、可用性、IO性能向上
・Replication：性能と可用性の工場
・fabric：
・Optimizer：より詳細なExplain,パーサの改善
・GIS：InnoDBのSpatialインデックス、Boost.Geometryとの統合

　・バージョンが進むにつれ、高負荷時の性能改善が図られている。
　　→　Sysbenchの結果の向上の図
　・Linux/UNIX環境でのSyslogサポート
　・サーバーサイドでのSQL文タイムアウト（セッション単位でも変更可能。）
　・GISとの統合
　　・独自コードの置き換え（空間図形情報の計算、分析）
　　・WorkBencheで地図情報を参照可能
　・Windows環境の強化（MySQL for Excelなど）
　・コミュニティレポジトリも用意した。GitHubへソースの掲載も実施。
　・MySQL クラスタの起動時間改善
　・MySQL Enterprise Edition
　　→　MySQL Enterprise Encryption
　　　→　MySQLの暗号化ライブラリ
　　　　　（AES256による暗号化、公開暗号鍵による暗号化など）
　　　→　Oracle Enterprise Manager for MySQL
　　　　　（OracleのEMからMySQLの監視ができる）

【KKZ感想】
　　Syslogサポートは運用面でいいかも。fluentdとかと組み合わせる？
　　MySQL for Excelとか逆に闇しか感じないが、
　　その領域がMySQLの領域ともなってる気がする。
　　Workbenchは6.2でかなりフレンドリーになってるので、
　　DB専門じゃない人にも使ってもらいたいツール。
　　SQL Developerとかよりははるかに軽く、
　　PGAdminよりはわかりやすいし見やすい。
　　性能や可用性の向上の実感は仕事で使ってみないと何とも。
　　実行計画（オプティマイザ）がだんだんマシになってるのは感じる。

●実験版(Labs)での変更点

・オプティマイザの新コストモデルにより、ストレージエンジンでの処理を改善
　→　より正確で動的なコスト見積もりができるようになる。
　　　キー参照、テーブル、レンジスキャンなど
・FusionIOを使った場合のストレージIO性能を向上させている。
　（ページレベル圧縮など）
　→　InnoDBデータ、システム表領域、UNDOログ
・グループレプリケーション
・ネイティブパーティショニング
・32K 64Kページのサポート
・TABLESPACEのサポート
　→　複数テーブルをユーザーが定義した表領域に格納可能とする
・マルチソースレプリケーション
　→　複数のデータ元からレプリケーションする）
・スキーマ内マルチスレッドスレーブ
・グループレプリケーション
　→　共有ディスクをつか合わない擬似同期レプリケーション
・各種メタデータをデータディクショナリで一元管理する流れを導入する。
・HTTPプラグイン for MySQL
　→　REST APIから直接SQLを叩いて結果を取得できる

【KKZ感想】
　　実験版の中ではネイティブパーティショニングと
　　オプティマイザの新コストモデルが面白そう。
　　Oracleのオプティマイザにもある、動的統計が組み込まれるっぽい？
　　HTTPプラグインはURLにGETパラメータでSQLを渡すと、
　　結果をJSONで返してくれる模様。
　　ちょっとしたREST API試すだけならサーバ側アプリ書かなくて
　　済むかもしれない。要調査。
　　（http://blog.ulf-wendel.de/2014/mysql-5-7-http-plugin-mysql/　…

●性能について

・memcachedを使った場合の性能が5.7で改善されている。
　（高負荷時に6倍以上改善）
・秒間接続数による負荷も低下している。
・クエリリライトプラグイン（開発中）
・JSON形式でoptimizerの実行計画を出せる。
　Workbenchでグラフィカルに参照可能。
・5.6で強化したPERFORMANCE SCHEMAの情報を
　さらに詳細に取れるように機能追加している。
　上記スキーマの情報を整理・管理しやすくするため、
　SYSスキーマを導入。

【KKZ感想】
　　地味にWorkbenchでグラフィカルな実行計画見れるのは助かる。
　　リリースしてから放置して運用するというより、
　　できるだけDBAがきちんと性能もメンテする(拡張していく)のが
　　MySQLの使い方な気はするので、INFORMATIONスキーマや
　　PERFORMANCEスキーマ、SYSスキーマの導入はありがたくなりそう。

●MySQL Fabric 1.5

・OpenStackとの統合
　　・クラウド環境での運用効率化
　　・管理情報をOpenStackから取得してくる
・高可用性
・シャーディングによる拡張性

【KKZ感想】
　　高可用性とスケーラビリティ、クラウド対応の話。
　　現状その規模で触ったことないけど面白そう。

MySQL最新情報セミナー 2014秋にてこれらの詳細を発表する予定
（日本オラクルのページで参照）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.1　MySQL Central ユーザーレポート
　SCSK株式会社　池田さん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

写真をベースに会場の様子の報告（レポート割愛）

Facebookは３０人くらいの運用チームで数万台のサーバーを管理している。
最近、5.6にアップデートを完了した。
その他、Facebook独自の機能拡張を行っており、その発表があった。

関連としてWebscale SQLのセッションもあり。
　※　WebScale SQLは、Facebook、Google、Twitterなどの
　　　MySQL利用企業によるソースの改造をMySQL側に還元するための
　　　コラボレーション。スケーラビリティやパフォーマンスの向上が主。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.2 MySQL Cluster Casual Talk
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・InnoDB on Disk Strage with InnoDB Ruby
　→　InnoDBファイルフォーマットをパースするRuby スクリプト
　　　 MySQLっぽい変態セッション

・現在のいろいろな機能改善はInnoDBメインで開発されていってる
　（反面、他のストレージエンジンはお察しください）

・Yahooは自前でMySQLのモニタリングシステム組んだらしい。へー。

・大量のMySQLサーバを利用するような運用では、
　MySQLのユーザー管理にユーザー管理にPuppet使ったりしている。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.3 MySQL Cluster 7.4.1 DMR
　櫻田さん @tsakurada
　http://www.slideshare.net/mobile/TakeshiSakurada/my-na201410…
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

MySQL クラスターのデータノードは起動時にメモリに全部読み込むので、
起動時のパフォーマンスが問題となっていた。

すべてがインメモリだと保存性・冗長性がないので、
ファイルに保存を行うローカルチェックポイントを使っている。
このローカルチェックポイントのファイルなどを利用して、
スピーディーに起動をかけるような仕組みか？

・1100万レコード存在するテーブルをmysqldumpで取り出して投入
（E5620 ×2　8GBの環境）

・サンプルテーブルは複合インデックスを含む

・コンカレーションエグゼキューションスレッド4と8で試してみた。

・結果：7.1→7.2では遅くなっている。
　7.3→7.4.1の比較で考えるとCXT=4の場合はいまいちだが、
　CXT=8の時はかなり早くなった。
　7.1の頃と同レベルのスピード。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.4
　市井さん　@ichii386
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・MySQL FabricはOpenStackと連携できたらしい
　AWS、RackspaceもOK。
　（Openstackは一部は動くようになっている）

・Solaris 11.2がリリースされている（半年前）
　OpenStackが統合され、Solaris固有の仮想化に
　便利機能がDriverとして使えるようになった。

・SolarisとMySQL Fabric でHAにできるんじゃないか？
　→　実験中。

・ところでMyISAMどこ行ったの？（会場笑い）
　→　MyISAM is No Future - Sunny(MySQL開発者の偉い人？)

・仕事ではログ分析とかでMyISAMを使っている。
　InnoDBとはワークロードのかかり方が異なる。
　・MyISAMのメリット
　　・自分でBuffer管理するよりOSに任せたほうがよくね？
　　　→　innoDBでも性能向上の取り組みは大きな要素。
　　　　　今後のバージョンアップでどんどん変わっていく。
　　　・ibdのファイルサイズ大きい
　　・トランザクションとか別にいらないシステムもある。
　　　(ロックとかの)オーバーヘッドがない方がいい。
　　　→　innoDBでもRead Onlyトランザクション使えばよくね？
　　・MRG_MyISAMとかもある
　　　→　パーティショニングとか今後はNativeになっていくよ〜

・結論：MyISAM、ちょっと不安になってきた。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.4 InnoDB Adaptive Flushing
　瀬島貴則さん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Oldest Pageについて
MySQLではバッファプールをページという単位で管理している。
そのページがダーティになった最初のイベントが
oldest_modificationというページの管理領域に書込まれている。
ダーティページをフラッシュしてディスクに同期させると、
そのページのoldest_modificationが0になる。

バッファプール上のページは2種類のリストで管理されている。
　・flush listは更新された順に管理
　・LRU listはすべてのページを対象に、参照された順に管理

ログ上に出力されるLast checkpoint atの進み方と
ディスクIOのワークロードは必ずしも同期しない。

Redoログの進み具合を管理するいくつかのパラメータ
　・innodb_adaptive_flushing_lwm
　・innodb_io_capacitiy
　・innodb_io_capacitiy_max

io_capacityは5.5と比較して意味合いが変わったと思う
dirty page のflushはこの値だけで決まってくるわけではない。

InnoDBでマスタースレッドと呼ばれるスレッドはこなすタスクが多かった
（ダーティページのフラッシュ、バッファの変更、パージ）
5.6ではそのへんの処理を複数のスレッドに分割した。

5.6からはinnodb_lru_scan_depthで指定されただけ、
フリーページを残すようになった。
Page Cleaner Threadがflush listを見て
dirtypageをフラッシュするときの挙動が5.6から賢くなった。
innodb_adaptive_flushing_lwmを超えない限りは
積極的には書かない（write combiningを狙う）。

transaction logの残量を見て、
1秒間にフラッシュするページの数をコントロールするようになった。
　→　SSDに書き込むときにこまめに書きすぎると性能に影響が出るため、
　　　ある程度まとめて書き込む挙動を狙っている。

　→　パラレルフラッシング：ダーティブロックの数が
　　　進んでいく数とかを見て可能ならまとめて書くように按分する。
　　　上記のような挙動に加え、
　　　5.7ではIOスループットが安定するように修正する方針。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション３　InnoDB Rubyの紹介
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

InnoDBのデータファイルを解析して、
情報を出力するRuby GEMパッケージ。

インストールはGEMで一発。
$ gem install innodb_ruby

$innodb_space -s ibdata1 space-page-type-summary
　→　テーブルスペースファイルを取得して情報表示するコマンド。
　　　UNDO_LOGやINDEX領域の使用率などが出力される。

$innodb_space -s ibdata data-dictionary-tables
　→　データディクショナリのファイル情報が出力される。

$innodb_space space-page-type-summary

$innodb_space -f d1/t1.ibd space-page-type-regions

$innodb_space page-illustlate
　→　ファイルの中身が一覧で色分けして見れる。
　　　(旧Windowsのデフラグみたいな出力。)

$innodb_space index-recurse
　→　インデックスの構造が直接見れる。（リーフの状態など）

$innodb_space record-dump
　→　レコードの中身を直接見る

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション４　MySQL Security(Enterprise Encryption)
　　　　杉山真也　@RDBMS
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・本題に入る前にHTTPプラグインのお試し
　　Curlから直接HTTPのURIにSQL文を入れてアクセスして、
　　JSONで値が返却される様子のデモ

Enterprise版ではない機能として、共通鍵暗号化の紹介。
　→　AES暗号化（AES_ENCRYPT、AES_DECRYPT）
　　　session.block_encryption_modeで
　　　AESの暗号化強度を変更可能。

Enterprise版独自機能として非対称暗号がある。
　create_asynmetric_priv_keyファンクションでPrivate鍵の発行
　create_asynmetric_pub_keyファンクションでPulic鍵の発行
　ASYNMETRIC_ENCRYPTファンクションと
　DECRYPTファンクションで非対称で暗号化
　より強度の高いRSA1024の暗号化なども可能