#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

MySQL USER CONFERENCE TOKYO 2015 の参加メモ #MySQLUC15

スポンサーリンク

今日は 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 システム向けのスケールアウト構成
          • アプリケション開発の省力化を支援するフレームワーク
      • アプリケーションの信頼性と拡張性を高める心機能
        • 従来型 RDBMS
          • トランザクション、セキュリティ
        • NoSQL 製品
          • 高い柔軟性、利用のしやすさ
          • JSON ドキュメント
      • RDBMS のメリットとドキュメント型データストアの柔軟性を兼ね備える
      • 運用の簡素化と開発の迅速化を支援する新機能
        • GIS 昨日の刷新
      • セキュリティの強化
        • secure by default
        • MySQL Enterprise Edition
          • Backup
          • Encryption
          • Firewall
            • ホワイトリストを用いた SQL インジェクション対策
  • 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 検証レポート
  • 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.
  • 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.
    • レプリケーションの向上
      • スレーブのスループット向上
      • 準同期
        • 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 ではコストが表示される
    • オプティマイザトレースもよろしく!
      • 選択された実行計画だけでなく、検討した実行計画も表示してくれる
        • 5.6 から
        • JSON 形式
    • コストモデルの改善 - 今日のメインディッシュ
      • MySQL のオプティマイザはコストベース
        • 各操作のコストを見積もって、最適な実行計画を探す
          • 最適なインデックス
          • 最適な JOIN の順序はどれか etc...
        • ルールベースのオプティマイザはもっていない。
          • ヒントを使ってある程度実行計画をコントロールすることは可能。
      • 5.7 におけるコストモデルの改良点
        • かなり大きなリファクタリング
        • ユーザからみえるものは以下の 3 つ
          • JOIN の順序選択の改善
            • MySQL 5.6 以前、駆動表の行数の見積もりに不具合
              • カウントされるのはアクティブメソッドによるもののみ
              • WHERE 句で絞りこまれて行数が減ることを考慮されていなかった→結果として JOIN の順序が望ましくない結果になることがあった。
            • WHERE 句による絞込についても考慮に入れる
              • PARTITION, EXTENDED by default
            • JOIN の順序がより最適なものに
          • テーブルおよびインデックスの統計情報の改善
            • ストレージエンジンからオプティマイザに渡されるひとつのキーの値あたりの行数が整数から浮動小数点に。
            • コストの見積もりがより正確に。
              • e.g. 浮動小数点数の効果: PS 初代はポリゴンの描画は整数。以降は浮動小数点数、より描画がなめらかに。
              • optimizer_trace で実行計画の検討された順序を JSON 形式で表示させる。
                • 5.7 ではコストも表示される。
          • 各種操作のコストが設定可能に
            • ハードコード→設定可能
              • 5.6 では概算コストを算出するときに使用する係数が固定だった
              • 5.7 ではシステムテーブルで設定可能に
                • mysql.server_cost : ストレージエンジンが使用するストレージエンジンによらないコスト
                • mysql.engine_cost
              • FLUSH OPTIMIZER_COSTS
      • オプティマイザヒント
        • 実行計画を細かく制御
        • クエリ単位でアルゴリズムの ON/OFF が指定できる
        • /+ ... / で囲った中にヒントを記述する
        • テーブルごと、クエリブロックごとに指定可能に
      • GROUP BY の挙動改善
        • ONLY_FULL_GROUP_BY
          • select 句に GROUP BY に出現していないカラムが出現しているとき、 ONLY_FULL_GROUP_BY が有効な場合、 GROUP BY 句に含まれるカラムに関数従属しているカラムの出現は許可され、それ以外はエラーになるようになった。
      • FROM 句のサブクエリの結果が改善
        • 不要なテンポラリテーブルよ、さらば!
          • 不要な場合にはつくらないようになった。
        • 外部クエリに FROM 句のサブクエリ内部の条件がマージされる
        • FROM 句のサブクエリの実行効率が UP!
      • IN サブクエリの改善
        • 行コンストラクタでインデックスが使用可能に
      • UNION ALL の改善
        • 5.7 では必要がないかぎりテンポラリテーブルを作らなくなった (以前は常につくっていた)
          • 効率アップ
          • ただしソートするときにはテンポラリテーブルが作られる。
      • ソートバッファの利用効率改善
        • 可変長のカラムが省スペース化
        • 5.7 では下記のデータはパックされた状態でソートバッファに格納。より多くの行がソートバッファに入るようになった。
          • CHAR
          • VARCHAR
          • NULL
      • テンポラリテーブルが InnoDB になった
        • ディスクベースのテンポラリテーブル、以前は MyISAM がこれまでは使われていたものが 5.7 からはデフォルト InnoDB に。
        • InnoDB のテンポラリテーブルの作成削除が高速化したことによる。
    • まとめ
      • MySQL 5.7 のオプティマイザは激しく進化!
      • 他にも 150 以上の新機能!
      • 5.7 を試してみてほしい。
      • スライドへのリンク

Binlog Events で ストリーム処理

  • Speaker: ヤフー株式会社 三谷 智史氏 (@mita2)
  • レプリケーションを使わないMySQLの冗長化 を書いたりした。
  • Y! Japan の MySQL 利用状況
    • ほぼ全サービスで利用
    • 約 550DB ほど
    • 世間で実績の少なそうな実績
      • 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
          • ストリーム処理には向かない
    • ありそうでなかった機能
      • 分散、ルーティングの仕組み
      • どこまで処理をしたか記録しておく仕組み
        • ライブラリ側で吸収してほしいなあ
  • まとめ
    • なんとかストリーム処理できそう
    • C++ つらい * LL ラッパーを書いてくれる同士募集

MySQLやSSDとかの話・前編

  • Speaker: グリー株式会社 瀬島 貴則氏 (@ts4th)
  • 後編は同日夜のグリー Tech Talk で。
  • スライドを事前に公開
  • Resource Monitoring とか結構がんばってやってた
    • ganglia & rrdcached のヘビーユーザ
  • 古いサーバを新しい性能の良いサーバに置き換えていく際に工夫して集約していっている、その取組の詳細内容
    • オンプレの話。
  • 今日の補足資料 (slideshare)
  • 背景
    • システムが古いのでサービスが頻繁にささる。それを力のかぎり sharding したりアプリケーション層でがんばってもらったり。
  • sharding をどうやってやっていたか
    • サービス無停止で master 切り替えする方法
      • auto_increment を更新する -
        • ナチュラルキーはアプリケーションに頑張ってもらう
    • DB 分割
    • TRIGGER で可能性が広がる
  • 分割しまくってサービスは安定するようになった。 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 統合することにした。
            • 詳細は資料
  • そして続きは後編。
  • この話の中で使用している MySQL Version は 5.1-5.6 。

MySQL を拡張する

ActiveRecordとMySQL 5.7

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_*
            • 迂闊に触ると氏ぬ。
            • でかいバッファプールでやるとささる。
        • 名前で分かる系
          • performance_schema の特徴
            • テーブルアクセス時に各種情報をかき集める
        • sys がもたらすもの
          • 後追いで検索
          • SQL ダイジェスト単位で検索可能
        • MySQL 5.6 performance_schema=on + sys スキーマ
          • かなり良い
        • sys スキーマのストアドプロシージャ
      • GTID のオンオフ
        • ローリング有効化ステートメント
        • 有効前にやること
        • GTID で得られるもの
          • MySQL Fabric とかとかとか
        • GTID で失ったもの
  • MySQL ネイティブの全文検索が日本語対応
    • Ngram はやめておいたほうがいい
    • MeCab は my.cnf ちょこっといじる必要あり
    • やるメリット(外向け)
      • 1つですむ
      • 2相コミットしなくていい
      • トランザクションによる保護
  • genereated column で関数インデックス
  • マルチソースレプリケーション
    • MTS とは別物
    • フルメッシュ型ができちゃう
  • MySQL Fabric と Router

今回の資料(スライド)

関連リンク

今回はこんなところです。

あわせて読まれたい