今日は Oracle さんの主催による MySQL :: MySQL User Conference Tokyo 2015 に参加してきました。
この形式でのカンファレンスは 5 年以上ぶりだそうですが、 Wifi および各席に電源完備、お弁当提供に、空き時間にはデモをしてくれたりと至れり尽くせり。コンテンツも充実、とても有意義な一日を過ごすことができました。
一応、今回のイベントの全てのセッションのメモをとってきましたので、公開しておこうと思います(個人的には MySQL 5.7 の JSON 対応、およびオプティマイザ改善の話をきけただけでもホックリでした)。
以下、各メモへのリンク。
State of the Dolphin
- Speaker: MySQL GBU 梶山氏
- MySQL5.7
- Web、モバイル&クラウドアプリケーション向けの進化1
- 従来より 3 倍高速
- MySQL Router
- 性能と可用性の向上 (LB, FO)
- アプリケーションの改良に注力 (アプリケーションでのアクセス経路設定不要)
- 各種開発言語から MySQL Fabric 利用可能に
- MySQL Fabric
- 自動 FO 昨日
- 大規模 Web システム向けのスケールアウト構成
- アプリケション開発の省力化を支援するフレームワーク
- MySQL Router
- アプリケーションの信頼性と拡張性を高める心機能
- 従来型 RDBMS
- トランザクション、セキュリティ
- NoSQL 製品
- 高い柔軟性、利用のしやすさ
- JSON ドキュメント
- 従来型 RDBMS
- RDBMS のメリットとドキュメント型データストアの柔軟性を兼ね備える
- 運用の簡素化と開発の迅速化を支援する新機能
- GIS 昨日の刷新
- セキュリティの強化
- secure by default
- MySQL Enterprise Edition
- Backup
- Encryption
- Firewall
- ホワイトリストを用いた SQL インジェクション対策
- 従来より 3 倍高速
- Web、モバイル&クラウドアプリケーション向けの進化1
- MySQL 5.7 is now GA.
MySQL冗長化の決定版!“Oracle Clusterware + MySQL”検証レポート
- Speaker: SCSK株式会社 廣濱 顕司氏
- 以下、それぞれリンク。
- Oracle Specialization インタビュー
- MySQL Specialized Partner
- 記事広告 - DB online の記事
- SCSK が Oracle Clusterware を実施した
- Oracle Cluserware MySQL 検証レポート
- Oracle Specialization インタビュー
- MySQL の取り組みと特色
- 高い技術力
- 日本語全文検索
- 豊富な実績
- 国内通信キャリアへの MySQL Cluster 設計・構築・保守実績
- MySQL といえば SCSK
- (ちょっと前まで)国内で唯一のオフィシャルトレーニング提供
- 高い技術力
- Oracle 社がサポートするクラスタテクノロジ
- Oracle Clusterware
- 自動 FO: ◯
- 共有ディスク: あり
- トポロジ:アクティブスタンバイ
- ストレージエンジン: InnoDB etc.
- MySQL Replication + FO
- 自動 FO: ◯
- 共有ディスク: なし
- トポロジ:マスタースレーブ
- ストレージエンジン: InnoDB etc.
- MySQL Cluster
- 自動 FO: △
- 共有ディスク: なし
- トポロジ: アクティブアクティブ
- ストレージエンジン: NDB
- DRBD
- 自動 FO: ◯
- 共有ディスク: なし
- トポロジ: アクティブスタンバイ
- ストレージエンジン: InnoDB etc.
- Oracle Clusterware
- Clusterware とは?
- Oracle RAC の実行に必要なインフラを提供するクラスタソフトウェア
- RAC 向けに多数の機能を提供
- 以下の Agent
- Sievel
- GoldenGate
- Weblogic etc...
- SW のインストール
- Grid Infrastructure Install
- MySQL Server Install
- Grid Infrastructure Standalone Agent Install
- 基本設定
- MySQL のデータディレクトリを共有ディスクに
- Clusterware 用の MYSQL ユーザ
- my.cnf に Clusterware 用のユーザ、パスワード
- ... 以降書ききれず。
- 検証結果
- 想定通りの挙動を確認
- 続きは Web で。
MySQL Cluster ユーザ事例紹介 - JR 東日本情報システムにおける導入事例
- Speaker: 日本 HP 株式会社 高橋智雄氏
- JR 東日本情報システムが構築・運用している「障害情報システム」に利用している MySQL Cluster + HPE Moonshot System が採用されている。その紹介。
- MySQL Cluster 採用の背景
- 障害情報システムの目的と位置づけ
- あるシステムで発生した問題に対して、その原因と解決方法を障害情報システムで全社共有し、同種の問題を未然に防ぐ
- ナレッジベース
- 将来的にミッションクリティカルに役立つ新しい技術の獲得
- 障害情報システムの特徴
- OSS を全面的に採用 (元は Windows Base)
- 全機能を HPE Moonshot system 1 シャーシに集約
- データベースに対する課題 -> 結果 MySQL Cluster を選んだ
- データ保持形式
- Moonshot system のシャーシ内にデータを保持する方式の検討(どうしても 1 シャーシ内に収めようとした)
- 可用性
- データ保持形式
- 障害情報システムの目的と位置づけ
- MySQL CLuster 概要
- リアルタイム - Inmemory
- 高可用性
- Shared Nothing
- 自動 FO
- スケーラブル
- 自動 Sharding
- Online で Node 追加
- Active-Active
- 構成
- 管理ノード
- ノードの管理
- 複数台で冗長化可能
- SQL ノード
- 通常の MySQL Server に相当
- 複数台でスケールアウト可能
- Data ノード
- 実データを保持
- 複数台で同期データ・レプリケーション
- 複数台で冗長性を高め、かつスケールアウトにより性能向上
- 管理ノード
- 商用版との差異
- 商用版ではサポートされるレプリカ数は 1 or 2
- 商用版にだけ付属するツール
- 検証結果 (検証は 4 例、共有されたのは以下の 2 例)
- 構成の違いによる性能比較
- node 数、レプリカ数、ストレージ (HDD/SSD)を変更
- sysbench OLTP complex mode, record 1M, ReadOnly/ReadWrite
- RO
- レプリカ数を 3 にすると約 10% 性能減
- ストレージ種別はほぼ影響なし
- 考察
- SQL ノードも CPU リソース重要
- ネットワーク帯域は 10Gbps
- レプリカ数は慎重に検討
- ノード追加によるスケーラビリティ確認
- ノードを追加するとスループット向上
- Data ノードと SQL ノードを適切な割合で追加することが重要
- Data ノード数が多い場合、 MySQL Cluster が苦手とする範囲検索の影響でスループットがのびない?
- 構成の違いによる性能比較
What's new in MySQL5.7?
- Speaker: MySQL GBU 杉山真也氏
- MySQL 最新情報セミナー 2015 秋に公開資料
- 今日はそのセミナーで問い合わせの多かった 5.6 の 3 倍パフォーマンス、 JSON 対応に関する内容にフォーカス
- MySQL - the world most popular database engine - via DB-Engine
- MySQL5.7
- パフォーマンスの改善
- オプティマイザとパーサーのリファクタリング
- 新しいコストベースオプティマイザ
- 新しいヒント
- パーティショニング - メモリの消費量が削減
- InnoDB General Table Space - Oracle でいう Table Space をつくれるように
- InnoDB Compression - OS の Compression を指定できるように
- JSON データ型
- JSON の前に参考までに Generated Column Support - from 5.7
- ネイティブ JSON データ型
- 組み込み JSON 関数
- JSON コンバーター
- Generated Column を使用して JSON 型に Index を付与できる
- この機能に関するデモ
- JSON データに対して特定のフィールドでフィルタリングを高速にできる。
- Text 型と違い JSON には Validation 機能が付いている。
- 全文検索機能
- InnoDB でも
- 日本語、韓国語も Ok
- 運用・管理面における強化
- Buffer Size/Varchar サイズ等のオンライン変更
- Undo ログの切り捨て
- mysqlpump - マルチスレッド, mysqldump の後継になるか
- SYS スキーマ
- セキュリティ向上
- proxy ユーザが default で使えるように
- 他の RDBMS でいう ROLE.
- proxy ユーザが default で使えるように
- レプリケーションの向上
- スレーブのスループット向上
- 準同期
- AFTER_SYNC の追加
- マルチマスターレプリケーション
- MySQL Router + MySQL Fabric
- 近々 Plugin として Shared Nothing 型の全マスターレプリケーションが追加になる予定。
- パフォーマンスの改善
MySQL 5.7 オプティマイザ新機能&改善項目
- Speaker: 日本オラクル株式会社 奥野 幹也氏
- なぜか有給を使って参加?!
- 赤くないプレゼン資料
- 免責、会社とは関係ないですよ
- MySQL5.7 、 150 以上もの新機能が追加されたとんでもないバージョン
- 漢が個人的にこれだ、と思ったのがオプティマイザ関連
- 何もしなくても既存のクエリが速くなる可能性(まれに逆に遅くなることもあるが)
- オプティマイザ新機能
- EXPLAIN FOR CONNECTION
- 現在実行中のクエリの実行計画をみる機能
- JSON Explain がよくなった
- EXPLAIN の情報を JSON フォーマットで出力する機能
- EXPLAIN format=json ...
- \G 表示で縦表示するのがミソ。
- MySQL Workbench と組み合わせて利用するとビジュアル EXPLAIN
- 図解してくれる - これは面白い
- 5.6 と 5.7 で表示が違い、 5.7 ではコストが表示される
- EXPLAIN の情報を JSON フォーマットで出力する機能
- オプティマイザトレースもよろしく!
- 選択された実行計画だけでなく、検討した実行計画も表示してくれる
- 5.6 から
- JSON 形式
- 選択された実行計画だけでなく、検討した実行計画も表示してくれる
- コストモデルの改善 - 今日のメインディッシュ
- MySQL のオプティマイザはコストベース
- 各操作のコストを見積もって、最適な実行計画を探す
- 最適なインデックス
- 最適な JOIN の順序はどれか etc...
- ルールベースのオプティマイザはもっていない。
- ヒントを使ってある程度実行計画をコントロールすることは可能。
- 各操作のコストを見積もって、最適な実行計画を探す
- 5.7 におけるコストモデルの改良点
- かなり大きなリファクタリング
- ユーザからみえるものは以下の 3 つ
- JOIN の順序選択の改善
- MySQL 5.6 以前、駆動表の行数の見積もりに不具合
- カウントされるのはアクティブメソッドによるもののみ
- WHERE 句で絞りこまれて行数が減ることを考慮されていなかった→結果として JOIN の順序が望ましくない結果になることがあった。
- WHERE 句による絞込についても考慮に入れる
- PARTITION, EXTENDED by default
- JOIN の順序がより最適なものに
- MySQL 5.6 以前、駆動表の行数の見積もりに不具合
- テーブルおよびインデックスの統計情報の改善
- ストレージエンジンからオプティマイザに渡されるひとつのキーの値あたりの行数が整数から浮動小数点に。
- コストの見積もりがより正確に。
- e.g. 浮動小数点数の効果: PS 初代はポリゴンの描画は整数。以降は浮動小数点数、より描画がなめらかに。
- optimizer_trace で実行計画の検討された順序を JSON 形式で表示させる。
- 5.7 ではコストも表示される。
- 各種操作のコストが設定可能に
- ハードコード→設定可能
- 5.6 では概算コストを算出するときに使用する係数が固定だった
- 5.7 ではシステムテーブルで設定可能に
- mysql.server_cost : ストレージエンジンが使用するストレージエンジンによらないコスト
- mysql.engine_cost
- FLUSH OPTIMIZER_COSTS
- ハードコード→設定可能
- JOIN の順序選択の改善
- オプティマイザヒント
- 実行計画を細かく制御
- クエリ単位でアルゴリズムの ON/OFF が指定できる
- /+ ... / で囲った中にヒントを記述する
- テーブルごと、クエリブロックごとに指定可能に
- GROUP BY の挙動改善
- ONLY_FULL_GROUP_BY
- select 句に GROUP BY に出現していないカラムが出現しているとき、 ONLY_FULL_GROUP_BY が有効な場合、 GROUP BY 句に含まれるカラムに関数従属しているカラムの出現は許可され、それ以外はエラーになるようになった。
- ONLY_FULL_GROUP_BY
- FROM 句のサブクエリの結果が改善
- 不要なテンポラリテーブルよ、さらば!
- 不要な場合にはつくらないようになった。
- 外部クエリに FROM 句のサブクエリ内部の条件がマージされる
- FROM 句のサブクエリの実行効率が UP!
- 不要なテンポラリテーブルよ、さらば!
- IN サブクエリの改善
- 行コンストラクタでインデックスが使用可能に
- UNION ALL の改善
- 5.7 では必要がないかぎりテンポラリテーブルを作らなくなった (以前は常につくっていた)
- 効率アップ
- ただしソートするときにはテンポラリテーブルが作られる。
- 5.7 では必要がないかぎりテンポラリテーブルを作らなくなった (以前は常につくっていた)
- ソートバッファの利用効率改善
- 可変長のカラムが省スペース化
- 5.7 では下記のデータはパックされた状態でソートバッファに格納。より多くの行がソートバッファに入るようになった。
- CHAR
- VARCHAR
- NULL
- テンポラリテーブルが InnoDB になった
- ディスクベースのテンポラリテーブル、以前は MyISAM がこれまでは使われていたものが 5.7 からはデフォルト InnoDB に。
- InnoDB のテンポラリテーブルの作成削除が高速化したことによる。
- MySQL のオプティマイザはコストベース
- まとめ
- MySQL 5.7 のオプティマイザは激しく進化!
- 他にも 150 以上の新機能!
- 5.7 を試してみてほしい。
- スライドへのリンク
- EXPLAIN FOR CONNECTION
Binlog Events で ストリーム処理
- Speaker: ヤフー株式会社 三谷 智史氏 (@mita2)
- レプリケーションを使わないMySQLの冗長化 を書いたりした。
- Y! Japan の MySQL 利用状況
- ほぼ全サービスで利用
- 約 550DB ほど
- オンプレ 220 台ほど。 マスタースレーブ 1:1
- 18TB
- Oracle Clusterware 使用している。
- 世間で実績の少なそうな実績
- 5.6 + GTID
- パーティション
- InnoDB 圧縮
- Y! Japan におけるストリーム処理の例
- 購入処理。 fluentd 的な MW を自社開発でもっている。
- ストリーム処理の 3 つの利点 (大規模システムで疎結合)
- スケールアウト
- 連携先の影響を受けにくい
- リアルタイム
- MySQL でストリーム処理まだ、という社内の声で今回の検証
- MySQL Binlog Events
- バイナリログを用いたストリーム処理ができる
- MySQL Labs で公開
- サンプルコード
- 3 つのサンプルがついてる (C++)
- basic-1
- basic-2
- binlog-browser
- イベント
- 1 つのトランザクションは複数イベントで構成
- EVENT_TYPE
- Binlog Events の設計思想
- Binlog Events の設定
- binlog_format=row
- binlog_image
- full が default
- minimal
- ストリーム処理には向かない
- ありそうでなかった機能
- 分散、ルーティングの仕組み
- どこまで処理をしたか記録しておく仕組み
- ライブラリ側で吸収してほしいなあ
- 3 つのサンプルがついてる (C++)
- まとめ
- なんとかストリーム処理できそう
- C++ つらい * LL ラッパーを書いてくれる同士募集
MySQLやSSDとかの話・前編
- Speaker: グリー株式会社 瀬島 貴則氏 (@ts4th)
- 後編は同日夜のグリー Tech Talk で。
- スライドを事前に公開
- Resource Monitoring とか結構がんばってやってた
- ganglia & rrdcached のヘビーユーザ
- 古いサーバを新しい性能の良いサーバに置き換えていく際に工夫して集約していっている、その取組の詳細内容
- オンプレの話。
- 今日の補足資料 (slideshare)
- 5.6 以前の InnoDB Flushing (オススメ)
- CPU に関する話
- Ehernet や CPU などの話
- 背景
- システムが古いのでサービスが頻繁にささる。それを力のかぎり sharding したりアプリケーション層でがんばってもらったり。
- sharding をどうやってやっていたか
- サービス無停止で master 切り替えする方法
- auto_increment を更新する -
- ナチュラルキーはアプリケーションに頑張ってもらう
- auto_increment を更新する -
- DB 分割
- TRIGGER で可能性が広がる
- サービス無停止で master 切り替えする方法
- 分割しまくってサービスは安定するようになった。 SSD 導入機運が高まる。
- SSD の登場により CPU とメモリがボトルネックになるケースを強く意識し始めた。
- まずは ioDrive を導入した
- 分割しまくった結果、 SSD を導入するなら 3 倍の仕事をしてくれないとペイしない(HDDのサーバとくらべて値段が 3 倍)と考えた
- 密結合の問題を解決
- バッファプールのヒット率を下げる工夫
- SSD をストレージというよりちょっと遅いメモリと考えることにした。
- その分、 max_connections を HDD サーバの 3 倍まで引き上げた。
- master では posix_fadvice(2) を叩いて古い binlog は page cache からちょっとずつ落とすようにしている。
- いまのところ ruby で IO#advise つかって :dontneed を叩いている。
- ioDrive の 1 台と HDD の 3 台を等価交換できるようになった。
- 案の定壊れた。
- 壊れたので、次の手を考えた。
- バッファプールのヒット率を下げる工夫
- NAND Flash を使うことにした (価格が下がってきたので)
- 使いたいドリブン。
- 800GB 以上のエンタープライズ仕様の SSD が普通に買えるようになってきた。
- NAND Flash のメリット
- random IO 性能
- 消費電力
- 耐熱性
- しかしすでに sharding しまくっていた結果、 800GB の SSD は容量多すぎ
- というわけで、無停止で master 統合することにした。
- 詳細は資料
- 使いたいドリブン。
- 密結合の問題を解決
- SSD の登場により CPU とメモリがボトルネックになるケースを強く意識し始めた。
- そして続きは後編。
- この話の中で使用している MySQL Version は 5.1-5.6 。
MySQL を拡張する
- Speaker: 日本MySQLユーザ会 とみたまさひろ氏
- 今日は拡張の話
- 綺麗な拡張
- UDF
- 一番簡単な拡張
- 独自の関数を MySQL に組み込む
- MySQL のソースを読まなくてもマニュアルを読めば作れる。
- e.g. mysql-mruby
- Plugin
- 5.7.9 で 40 個くらい (show plugins)
- 種類
- Storage Engine
- MySQL :: MySQL Internals Manual :: 22 Writing a Custom Storage Engine だけ読んで書くのは難しい。 MySQL そのもののソースを読むのをあわせてする必要あり。
- 全文パーサー
- ngram
- mecab
- デーモンプラグイン
- INFORMATION_SCHEMA
- 準同期レプリケーション
- 監査
- 認証
- パスワード検証
- Storage Engine
- UDF
- 綺麗じゃない拡張 (再コンパイル必要)
- Charset/Collation
- 1バイト文字セットならコンパイルいらない
- マルチバイトは必要
- ハハ=パパ=ババ問題、寿司ビール問題を解決したい人は改造してみてもいいかも。
- ネットワークプロトコル
- クエリ
- クライアントからのコマンド振り分け sql_parse.cc
- クエリ構文解析 sql_yacc.yy
- 予約語書き換えれば SQL インジェクション対策になるんじゃね?!
- Charset/Collation
- MySQL 系 Advent Calendar
ActiveRecordとMySQL 5.7
- Oracle ACE (MySQL) Ryuta Kamizono氏
- Rails の OR Mapper の MySQL 5.7 対応どうなってるのか
- 2 年前の Rails
- 1 年前の Rails
- Rails で AR 使うとつらいのでつらくならないようになおしたい
- 今年 1 年とにかくなおしまくった - 脱帽。
- この 1 年でかなり改善された自負。
- 改善された問題 - rails/rails · GitHub
- utf8_unicode_ci
- utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
- MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる
- 寿司ビール問題
- The default collation should not be change #20000
- strict_mode
- Rails は勝手に strict_mode を上書きしてるから気をつけろ
- ActiveRecordでstrict_modeを無効にする - Qiita
- Datetime rounding problem
- MySQL5.6 から Datetime は小数点以下が四捨五入されるので気をつけよう
- Format the datetime string according to the precision of the datetime field
- utf8_unicode_ci
- MySQL 5.7 への対応
- 新機能対応
- Add a native JSON data tpe support in MySQL 5.7.
- Add Generated Columns support for MySQL 5.7.
- show_compatibility_56=off
- 日々の覚書: MySQL 5.7では迂闊にperformance_schemaをOFFするとSHOW STATUSが使えない
- 5.7.9 でそもそもなおったらしい
- devided_marge=on
- ONLY_FULL_GROUP_BY
- 新機能対応
- まとめ
- Rails の MySQL 対応はこの1年でかなり改善された!
- 感想:
- ネ申。すべて自分のリンクに行き着いてる!
MySQL 5.7が 「魅」 せる新しい運用の形
- Oracle ACE (MySQL) yoku0825氏
- character_set, laten1 で幸せな人はいるか?
- ダウンロード時につくれる MySQL のアカウントで MySQL Bugs から 71659 に vote して UTF8 Default Charset にしませんか?
- 5.7 - 2015-10-21 に GA
- yoku0825 さんの三部作
- MySQL 5.7 の罠があなたを狙っている
- 光の MySQL 5.7
- MySQL 5.7 が魅せる新しい運用のカタチ - イマココ
- これからのメインストリームは 5.6, 5.7
- 今日は夢の話
- mysqlpump
- 正直まだ使えれるレベルではない 5.7.8 時点
- なにがおいしい
- --defer-table-indexes ロードの時間短縮に貢献
- 進捗出るように
- 圧縮
- --user GRANT STATEMENT に加工してダンプしてくれる
- --default-parallelism デフォルトは 2 並列
- なくなったもの
- --lock-all-tables
- -- master-data 他もろもろ
- まだまだこれから
- MyDumper でよくない?とは言わないこと。
- 遅延 Create Index はいいと思う。
- users もいいと思う。
- sys スキーマ
- 元 ps_helper
- ビューの詰め合わせ
- yoku さんのお気に入り
- sys.metrics - 監視に良さそうな詰め合わせ
- sys.schema_index_statistics
- sys.schema_unused_indexes
- sys.steatement_analysis
- sys.statement_with_errors_or_warnings
- sys.innodb_lock_waits
- 危険なヤツら
- sys.innodb_buffer_stats_*
- 迂闊に触ると氏ぬ。
- でかいバッファプールでやるとささる。
- sys.innodb_buffer_stats_*
- 名前で分かる系
- performance_schema の特徴
- テーブルアクセス時に各種情報をかき集める
- performance_schema の特徴
- sys がもたらすもの
- 後追いで検索
- SQL ダイジェスト単位で検索可能
- MySQL 5.6 performance_schema=on + sys スキーマ
- かなり良い
- sys スキーマのストアドプロシージャ
- yoku さんのお気に入り
- GTID のオンオフ
- ローリング有効化ステートメント
- 有効前にやること
- GTID で得られるもの
- MySQL Fabric とかとかとか
- GTID で失ったもの
- mysqlpump
- MySQL ネイティブの全文検索が日本語対応
- Ngram はやめておいたほうがいい
- MeCab は my.cnf ちょこっといじる必要あり
- やるメリット(外向け)
- 1つですむ
- 2相コミットしなくていい
- トランザクションによる保護
- genereated column で関数インデックス
- マルチソースレプリケーション
- MTS とは別物
- フルメッシュ型ができちゃう
- MySQL Fabric と Router
今回の資料(スライド)
関連リンク
- HP コミュニティ - JR東日本を支えるオープンソースとは?~日本HPが性能検証結果を公開~ - エンタープライズ・ビジネス・コミュニティ
- MySQL :: 資料ダウンロード
- MySQL User Conference 2015 に行ってきた - sakaikの日々雑感~(T)編
- 漢(オトコ)のコンピュータ道: MySQL User Conference Tokyo 2015で発表しました:MySQL 5.7におけるオプティマイザの改良点
今回はこんなところです。