ウィリアムのいたずらの開発日記

ウィリアムのいたずらが、コンピューター関係について、思ったことを好き勝手に書いているブログです。

「MySQL 5.7入門 SQLチューニング編」に行ってきた! その2

2016-05-30 19:09:34 | Weblog
5月30日

【MySQLについてきちんと勉強したい方必見!】MySQL 5.7入門 SQLチューニング編
https://www-jp.mysql.com/news-and-events/events/mysql-for-beginners-sql-tuning-edition-ja/

に行ってきた!ので、その内容をメモメモのつづき(=その1のつづき)



■MySQL5.7入門(SQLチューニング編)− つづき

オプティマイザ詳細解説
・コストベースオプティマイザー
    ・論理的な変換
    ・準備
    ・コストベース最適化
    ・最終調整

 論理的変換
  否定の除去
  展開
  定数式の評価
  不要な条件の除去

 コスト
 リソース使用量
 単一クエリ=関連性は考えない

 統計情報
  5.5以前は統計情報は永続化されていない
  analyze tableを実行

 コストの見積もり
  コスト定数も変更できる
  →最新のハードウェア

 パフォーマンススキーマから、IO速度調査できる

・アクセス方法の選択
 主キー、ユニークキー constになる
 他 複数 ref

 Rangeスキャン
  オプティマイザトレースで範囲確認できる
  後方一致はインデックス使えない。

 インデックスマージ

 Handlerステータス変数について

 インデックス・コンデション・プッシュダウン


・JOIN
 Join順番の精度上がった
 小さいものから
 Visual Explainで確認
 あとのテーブルを評価してなかったけど、5.7ではそこも

・サブクエリー
 実は細かい話があるけど、内部的に勝手にされる話

・ソート処理、集計結果
 ファイルソートを避ける→インデックス
 リミット句
 内部的にソートが何回されたか

・集計クエリ
 参考情報として確認してね

・INに複数列
 最適化される

 クエリーリライトプラグイン
  MySQLサーバー側でクエリ書き換え




■SQLチューニングにも役立つ
 MySQL Enterprise Monitorのご紹介

・前のセッションで、大変そうだけど
 スローログ
 sys.statement_analysis
 イベントヒストリで確認することもできる

・これから紹介するのは
 複数台サーバーを包括的にする方法

・ファイルソート:ファイルとメモリ両方の場合
 スローログでわかりにくいもの

・自己紹介

・5.7 10月 全文検索を高速、JSON
・DBはコミュニティ版と商用版一緒

Enterprise Edition
・Enterprise Monitor
 アドバイスしてくれる機能

・問題が発生する前に通知

・ワークベンチとEnterprise Monitor
  →ためられる

・ベストプラクティスアドバイザ
  →パラメータあってるか、トライアルで確認する手も

・クエリアナライザー
  なにで遅くなったか、解析できる
  →スローログと比べて

・問題のあるクエリ実行プランを確認

・時系列パフォーマンスグラフ

・I/O大量発生
  インデックスが最適化されていないケース
  unused index

・Lock待ちの確認、プロセスの確認 show process List

・InnoDBバッファプールの利用状況

・レプリケーションモニター
  トポロジーを見れる

(参考)Workbench
 →中期的には、Workbench以外も・・

技術サポート
・見つけた内容を、どうチューニングする?
  →楽ではない
・物理サーバーごと
  →仮想環境:パブリッククラウドについては営業に

・Oracle製品との連携
  GoldenGate使える
  EnterpriseManagerと統合できる

・セキュリティ対策

この記事をはてなブックマークに追加

「MySQL 5.7入門 SQLチューニング編」に行ってきた! その1

2016-05-30 15:49:49 | Weblog

【MySQLについてきちんと勉強したい方必見!】MySQL 5.7入門 SQLチューニング編
https://www-jp.mysql.com/news-and-events/events/mysql-for-beginners-sql-tuning-edition-ja/

に行っている(今、受講中)!ので、その内容をメモメモ




資料のダウンロードURL
http://www-jp.mysql.com/why-mysql/presentations/mysql-sqltuning-for-beginners-ja/
http://www-jp.mysql.com/why-mysql/presentations/mem-ja/

■MySQL5.7入門(SQLチューニング編)
・日本語に翻訳されたマニュアルは5.6しかない
 けど、5.7見てね(正規版は英語。翻訳は参考)

チューニングのアプローチ
 大きく2とおり
  DB全体のチューニング:パラメータ変更
  SQLのチューニング:SQL最適化
   →性能格段に向上することは珍しくない

・SQLチューニングの流れ
 1.問題となるSQLの特定
 2.実行計画やSQL実行時の稼働統計
 3.SQLチューニング実施
    index、オプティマイザ、パラメータ、スキーマ変える・・・

SQLチューニングの基本
・1.問題となるSQLの特定

 スロークエリログ
  実行時間が指定した時間以上のクエリを出力する
  デフォルトでは出力されない
   log-show-queries 秒単位で指定
   log-queries-not-using-index インデックス使っていないSQLを出す

  デフォルトはOS上のファイル
  loh-output オプションでテーブルへも出力可能 
  →出続けるので注意:運用時
   クエリの実行が終わってから出る:今時間がかかっているものには使えない
     →show full processlistを使う

  たまり続けたファイルを集計する mysqldumpslow
  →MySQL Query Analyzer

  MySQL workbenchからshow FULL PROCESSLISTを確認可能
   →コネクションの情報を見れる
   Visual explain
   コミュニティ版と商用版の両方がある

 パフォーマンス・スキーマ
  性能統計情報分析のための仕組み
  デフォルトで有効
  sysスキーマ MySQL5.7からデフォルト
   パフォーマンススキーマとインフォメーションスキーマをシンプルなビューに
   特に注目!statement_analysis,innodb_lock_waits
   トータル実行時間が長いSQL調査
  →たまり続ける
   ロックまちSQLの調査
  まとめてtrancateする方法あり

 【商用版限定】MySQL Query analyzer
   クエリーレスポンスタイムインデックス
   初回実行時間
   グラフ→傾向が見える
   CSVファイルにもまとめられる

 【商用版限定】MySQL Enterprise Monitor
   MySQL Query analyzerはMySQL Enterprise Monitorの一部
   何かあったら伝えることができる

・2.実行計画やSQL実行時の稼働統計などの確認
  実行計画:内部的処理の手順
  SQL:内部の処理手順は指定していない

  オプティマイザが実行計画を作成
  →同じSQLでも実行計画が違えば、パフォーマンスが大きく異なる

  オプティマイザー:最適化するモジュール
   最適な実行計画を作「ろう」とします
     コストベースのオプティマイザ
      →コストを内部的に考える

・統計情報
  コストベースオプティマイザのコストを見積もる時に
    ベースとなる設定
    統計情報
  テーブル内のデータが10%更新されたら再計算
   →なにもしてないのに遅くなることがあり得る

・EXPLAIN
  実行計画の確認
   SQLの前にEXPLAIN と書くだけで使える
  実行中のQUERYをコネクションIDでとれる
 →179ページ パーティショニング機能
   論理的に区分けする

 拡張で追加取得
  フィルタリング
  show warning:オプティマイザが書き換えたSQL表示

 使用例
  タイプがALLだったらチューニング候補

 select_type重要
   マテリアライズド
   union,subquery
  特に注意;dependent,uncacheable 何回も実行してしまう可能性
   →相関サブクエリ
   出てきたら、要注意!
  indexってでてきたら、あまりよくない

 Extra重要
  一時テーブルをディスクに書いているとか
  using filesort
  
 構造化されたexplain
  →JSON形式。情報量多い
 Visual Explain 色によってわかる
 オプティマイザトレース

 SHOW STATUS
  sort_marge_passes:マージソートのパス数

 ワークベンチは、まとめて見れるようになっている
  Query Statisticsから


3.SQLチューニング実施
・インデックスの活用
  →大半を使うのであれば、インデックスを使わないほうが速いことも
 UPDATEでインデックスが使えていない場合には、
  (InnoDBは行レベルになっているが)
 テーブルロックがかかってしまう→ロック待ちになる

・JOINの順番:内部的効率変わることがある
  結果セットが少量になるテーブルからJOINする  
  MySQLは、ネステッドループジョイン:
    1つの表から1件とってきて、2つめのテーブルから合うものを探す
      1つめが少量のほうが、ループ回数少なくなる
      2つめの表がインデックス使えたほうが、早く終わる
  ブロックネステッドループ→JOINバッファのチューニング

・サブクエリ
  5.6以降、かなり改善している
  JOIN書き換えしなくてもパフォーマンスいいこと多い

・インデックスの考慮事項
  つけすぎない:更新処理はオーバーヘッド
   重複するようなインデックス、
   取り得る値の種類が少ない場合
  サイズの小さいインデックス:プレフィックス
  複合インデックスを使った場合a,b
   b列に対しては、インデックス使えない(a列は使える)
  →先頭の列から順番に
  ユニークなものには、ユニークつける
   この一手間で違いがでる
  マルチカラムインデックス
  インデックスに処理をしない→関数インデックス、generated column

・インデックスマージ
  5.0以降あり、5.6で緩和

・オプティマイザ制御
  コスト調整5.7から
  最適化アルゴリズム使う・使わない
  ヒント使える

・ヒント
 インデックスヒント
   USE INDEX:使ってね,FORCE INDEX:絶対使え,IGNORE INDEX:使わないでね

 STRAIGHT_JOINヒント
   JOINの順番を指定(OUTER JOINでは使えない)

 オプティマイザヒント(5.7から)
   オプティマイザスイッチより細かい粒度で

・セミジョイン最適化 マテリアライズ

・optimizer_switch
 この前の対応をするのが基本。
 もっとのとき

・チューニングがうまくいかない時
 商用版はサポート範囲内




このあと、「オプティマイザ詳細解説」だけど、
ここまでで、十分長いので、いったん切る。


この記事をはてなブックマークに追加

ついに明かされる「りんな」の“脳内”-MS 「女子高生AI」のアルゴリズム公開

2016-05-30 12:12:05 | Weblog

ついに明かされる「りんな」の“脳内” マイクロソフト、「女子高生AI」の自然言語処理アルゴリズムを公開
http://www.itmedia.co.jp/news/articles/1605/27/news110.html

(以下太字は上記サイトより引用)
あ〜専門的にみると、突っ込みたくなる人もあるかとは思いますが、
我らが?太田智美さんが書いているので、温かい目でみてあげよう!


Microsoftが開発しているAIとして「Cortana」がよく引き合いに出されるが、Cortanaのコンセプトが「Productivity」(生産性向上)であるのに対し、りんなのコンセプトは「Emotional」(感情的)。例えば、「明日晴れるかなぁ?」という問い掛けに対し、Cortanaは「明日の天気は晴れです」と返すが、りんなは「どこか出かける予定でもあるの?」と、会話が進むための返事をする。


答えなくてもいい・・・この発想はなかったな・・・

この記事をはてなブックマークに追加

IoTの開発手順−従来開発との違い

2016-05-30 08:50:58 | ネットワーク
IoTが絡む案件は、以下のように開発していくのではないだろうか?

(1)目的の確認
・まず、何がしたいか、何を見たいかを確認する
・それを得るために
  何を入力とし−入力データ
  どう処理して−データ解析等
  何を表現するか−アクチュエーター/可視化
 を決める

・ここで、
   ・入力データを何らかの処理を行えば、出力データが得られる
     =モデル化がされているのであれば。
    そのモデルを明確にする

   ・入力データと、出力データの関係が分からない場合は
     機械学習を行い、数理モデルを作成する

(2)入力、出力の具体化

   ・入力データは、
        いつ(9:00〜17;00とか。24時間とか)
        どこで(日本の農場とか、世界の山の上とか)
        どれくらいの頻度で(30分おきとか)
        どれくらいの広がりで(1mおきに40か所とか)
        どんなセンサー等により(温度センサーとか)
    収集し、
   ・出力データは、
        いつ(処理結果後すぐとか)
        どこに(会社のオフィスで)
        どのようなデバイスで(ディスプレイに
    出力(表現)するか

  を具体的に決める

(3)処理の具体化
   入力と出力、数理モデルから、
   どのくらいの計算が必要かを割り出し、
   どこで処理させるか(エッジかオンプレサーバーか、クラウドか、ハイブリッド?)
   を決める


(4)入出力インターフェースの決定(有線、無線?)

  (2)の入出力から(3)の処理までの間、データをどう送るか、インターフェースを決める。

  まず、有線で送るか、無線で送るか決める

   有線の場合は、伝送距離、伝送路(イーサネットケーブルなど)、伝送プロトコルなど
   無線の場合は、周波数、プロトコル等を決める

(5)システム構成を決定
  (2)、(3)、(4)により、システムが描けるので、システム構成(ハード)を描く
  無理はないか(センサーが電圧の割には、線が長すぎる、頻度の割にその周波数帯&プロトコルは・・など)

(6)ユースケースごとのシナリオ
  ・初期設定時
  ・通常動作
  ・故障時
 (・点検時)
 について、それぞれのシナリオを(5)のシステム構成に基づき、具体的なストーリーにする

※ここまでできると、通用開発と変わらなく実施できる。
つまり、IoTの開発は、上記手順を必要とするところが従来開発と違う。
((1)(2)は従来開発でも要求定義で似たところがあるので、具体的には
  (3)〜(6)が違う。)

とくに、(3)(4)(5)は従来設計とされていたところである。
だが、設計過程でこれを考えると、実際には遅く、手戻りが発生してしまう。
理由は(6)ユースケースが作れないから・・・


この記事をはてなブックマークに追加

マスコミは、公平に報道しないと-沖縄女性殺害事件を悼むアメリカ人たちが謝罪の行列

2016-05-30 01:05:23 | ネットワーク
放送法1条

第一条  この法律は、次に掲げる原則に従つて、放送を公共の福祉に適合するように規律し、その健全な発達を図ることを目的とする。
一  放送が国民に最大限に普及されて、その効用をもたらすことを保障すること。
二  放送の不偏不党、真実及び自律を保障することによつて、放送による表現の自由を確保すること。
三  放送に携わる者の職責を明らかにすることによつて、放送が健全な民主主義の発達に資するようにすること。


偏った報道をしてはいけません。ですから、沖縄に関しても

沖縄女性殺害事件を悼むアメリカ人たちが謝罪の行列を形成 →マスコミ・基地反対派は当然のようにスル―
http://blog.esuteru.com/archives/8594594.html

とか

沖縄の路上、炎天下の中で見られた光景に考えさせられる 6枚
http://buzzmag.jp/archives/62493

も報道しないと・・・

この記事をはてなブックマークに追加