ビッグデータ＝統計の専門家まかせという考え方で、大丈夫か？

ビッグデータとＢＩの関係について、もう一言二言・・・

　ビッグデータを扱えるようになって、統計の専門家が必要だという声は大きい。
　たとえば、こんな記事もある。


人材不足で“取り合い”は必至
データサイエンティストなる職種
http://diamond.jp/articles/-/16193?page=2


には、こんなことが書いてある（以下太字は上記サイトより）

ビッグデータ関連で必要とされる人材は4種類あるという。

（1）データベースに強いＩＴ技術者。多様な非構造化データをデータベースに格納するための前処理など、データベースの整備ができる技術者だ。次に
（2）定性調査、定量調査に関する専門家。アンケートやインタビューなどの設計ができる人である。そして
（3）データアナリスト。つまり統計や人工知能の知識のある専門家だ。そして最後に
（4）プロジェクトマネジャー。コンサルティングも企画提案もでき、人の管理もできる管理者は、（1）～（3）のメンバーをまとめ上げる存在として欠かせないという。


確かに記述統計的なことや、推論が入ってくるにしても、回帰、重回帰、多変量回帰などの分野では、そうだと思う。
しかし、データマイニングでクラスタリングを扱ってきたり、
テキストマイニングをしたり、
因果関係でも、ベイジアンネットワークはまだいいけど、因子分析、共分散構造分析をするとなると、この人たちでは、無理が出てくる。

---

ＢＩの時代の延長と違った能力が、最近の社会では求められている。
ＢＩは、基本的には蓄積された過去のデータを下に、現在、将来を予測していく。
そのため、表面的な動きが中心になる。
この場合、データ解釈は、統計の知識があればよい。
しかし、過去が現在と連続性を持たないほど激変している場合、これらのデータは役に立たない。
現状は、そういう時代だ。



そういった時代には、「なぜ、この人は、こういう動きをするのだろうか？」と考える必要がある
このような因果関係を扱うには、ベイジアンネットワークもあるけど、
人間の潜在的な要素を、因子（因子分析の場合）や潜在変数（共分散構造分析の場合）として扱い、
因子分析の場合は、因子を考え、共分散構造分析の場合は、潜在変数と、その他の変数との関係なども考えて、
統計を行うことになる。
この場合、その因子や潜在変数＋構造は、自分で考えることになる。
なので、深い業務・業界知識（表面的でなく、構造的な）が必要になってくる。
これは、ドメインエキスパートが持っている知識であって、統計の人というか、上記（１）から（４）の人にはない知識である。
そもそも、これらの分析がしたいのなら、ビッグデータである必要は・・・？？

---

実は、データマイニングやテキストマイニングでも、むしろ、業務知識のほうが必要になってくる。
統計知識は勉強すれば、Wekaぐらいの内容でよければ、動かせる。
動かせるが、それだと、ごみが出てくることがある。
それらのデータクレンジングやデータのまとめ方には、業務知識が要る。
また、テキストマイニングは、類義語辞書が欠かせないが、
このような辞書をつくるにも、業務知識が要る。

---

つまり、統計とは、ユーザー側と、統計者側で、アジャイル的に行っていく
必要があるのであって、統計やさんをあつめて、それで、まわるんかい？
といった、考えをもってしまっています。

プログラミングパラダイムが変わったことによる、半構造化データへの着目

　昨日の話の続き。

　コンピューターは、昔は微細化技術を発展させて、トランジスタを集約させることによって、
処理スピードを上げてきた。ムーアの法則は、この処理スピード向上を、よく物語っているわけ
だが、この方法には限界がある。微細化を進めると、最終的には、電子１個でトランジスタの
動作が出来るか？ということになる。
　これは、不可能である。電子などの量子は、１個とかいう状態になると、値がわからない。
観測した時点で値が確定するんじゃなかったっけ。実際、電子数個という状態になると、
ＯＮ／ＯＦＦ状態に間違いが出るんだそうな（と、なにかでよんだ。雑音がはいると・・・）

　もちろん、これらの問題は、量子コンピューターによって解決されるかもしれない。
　しかし、それまで待つのは、現実的ではない。
　そこで、処理スピード向上の切り札として、並列化、スケールアウトが考えられてきた。

　今後のコンピューター処理は、そこで、並列処理、非同期処理を多用する方向に発展するものと思われる。
　Ajax,JQueryしかり、Hadoopしかり。

　ここで、並列処理プログラミングを考えると、
　　　・小さい単位にプログラムを小分けして
　　　・それを同時並行で走らせる
　ということになる。

　そうすると、
　　　・小分けされた何本ものプログラム１つ１つにおいて、初期化しないといけない
　　　　　　→共通部分続出
　　　・小さなトランザクションがいっぱい出てくる
　　　　　　→ＲＤＢだと大変
　ということになる。

　前者の、共通部分続出に関しては、共通部分の結果をキャッシュに入れておき、それを利用すればよい。
　例えばmemcachedを使うとか。

　こうなった場合、ＲＤＢでＪＯＩＮして、毎回結果を求めるより、
　オブジェクト単位でキャッシュして、データを取ってきたほうが、ＪＯＩＮ時間を短縮できる。
　その際、このオブジェクト構造こそ、半構造データということになる。

---

　このような、並列処理にプログラミングパラダイムが変わったことによる
　オブジェクトキャッシュとしての半構造化データへの着目という話も
　実務的には、あると思う。

ビッグデータと半構造化、非構造化データの話は、わけたほうがいい

第６回　要求シンポジウム　その２
http://blog.goo.ne.jp/xmldtp/e/b05b8434e99681ddd9f5cdcf633d26a9


の内容に関して、私の意見と沿わないところがあるので、そこについて、いくつか書いてみる。

まず、ビッグデータの話（この話、何回か続くかもしれない）

ＢＩの延長のビッグデータというのは、同意見。
ただ、ビッグデータによる分析は、ＢＩの延長だけでなく、多変量解析、特に因果関係の話も
出てくると思うけど、それについては、次回以降に書く。

問題は、よく、そこから、Ｔｗｉｔｔｅｒやfacebookを分析し、半構造化、非構造化データから、
有用なデータを取り出し・・・とか行ってしまうこと。

半構造化、非構造化データは、そういう分析よりも、むしろ、違う使い方がある。
Ajaxなどに向いているのだが、それについても・・・今日書きかたっ書けど、時間がないので
次回以降に書く。

また、構造化データによるビッグデータを扱ったほうが、統計的には載りやすい。
なので、ビッグデータと半構造化、非構造化データの話は、わけて考えたほうがいい。

・・・時間がないので、具体的な話がかけなくてごめん。
次回以降、もう少し具体的に説明する。

第６回 要求シンポジウム その２

月曜日、「第６回　要求シンポジウム」に行ってきた。
そのときのメモメモ（後半）
なお、ここに書かれているのは、発言者の言葉であって、
私の意見ではない
私は、かなり反対意見を持っているが、それについては、
おいおいブログで書いていく

---

---

■ユーザーから見たＩＴ産業と上流対策

【共倒れが心配される日本のＩＴ】
・リスクをとらない発注者
　　　経営者の無関心（見えないコスト、プロセス、投資効果）
　　　システム部門のステイタスが低い：サポートから始まったから？
　　　　　　情報子会社：戦略的アウトソーシングによるロックイン
　　　　　　　　　→情報機能子会社は親会社に吸収
　　　わがままな事業部門：業務改革しないでツールをほしがる
　　　ベンダー依存・丸投げ・過剰依存
　　　　　→情報システム・ソフトウェア取引トラブル事例集

・リスクから逃げる受注者
　　　３つの不明朗
　　　　　　品質
　　　　　　価格
　　　　　　納期
　　　契約で逃げようとする
　　　　　　多段階契約・委任
　　　　　　先進企業は全部内製
　　　エンジニアリング力が足りない
　　　　　　天才プログラマが育たない？

・ＩＴに関心のない政府と行政
　　　進まない電子政府、電子行政
　　　医療健康分野：ＥＨＲとか進まない

【建設業と比べられるＩＴ産業】
・ＩＴゼネコンの誤解
　　　納期に収める
　　　たしかに似ている。でも、実際は違う
　　　業法があるかないか？
　　　　だれがプログラムを書いてもＯＫ！

・設計図があるかないか
　　　　プロセスモデリング＋データモデリング

【上流問題が解決しないいくつかの理由】
・ユーザーの堕落
・ウォーターフォールに依存している
・崩れてしまったパートナーシップ
　　・メインフレーム時代の蜜月
　　・きっかけはオープン化の流れ
　　・クラウド
　　　　　ハイブリッド型が普通の利用形態

【改善の兆しと期待】
・システムイニシアチブを取り戻す
　　・内製を始めたユーザー企業
　　　　　・外注で構築していたらビジネススピードに間に合わない
　　　　　　　　→システム内製を極める

・データマネジメントへの関心
　　・ＭＤＭ（マスタデータ管理）
　　・レスポンシブ・ウェブ・デザイン

・ビッグデータに臭うＢＩの失敗
　　・目的あいまいのデータ管理
　　・構造化データ管理もできないのに、非構造化データ

・日本データマネジメント・コンソーシアム（ＪＤＭＣ）の発足

・プロセス可視化：可視経営協会

・ソフトウェア信頼性向上への期待
　　　・形式手法への期待

---

■形式手法活用ガイドの適用
　ＮＥＣ　橋本先生

【ＤＳＦについて】
・背景
　　・ソフトウェアの複雑化
　　・システムにおけるソフトウェアの割合上昇
　　・要求定義や外部設計などの上流工程における問題
　　　　　→３０％以上の企業が「要件定義不十分」「システム設計不十分」

・ＤＳＦ：障害を起こさないソフトウェア
　　　　企業＋（アドバイザ）ＮＩＩの中島先生
　　　　不具合の除去→形式手法

　・外部設計でのもれ、矛盾チェック
　　　→合意形成ガイド

　・採用した形式手法
　　　実績＋無償利用＋上流

　　形式仕様記述：ＶＤＭ＋＋，Ｂメソッド、Ｅｖｅｎｔ－Ｂ
　　　　→データの制約を守っているか

　　形式検証（モデル検査）：ＳＰＩＮ
　　　　→状態遷移の突合せ

　図書館システム
　　まだ、バグが出る：形式手法の作業手順、イディオム集

・形式仕様活用ガイド
　３部からなる
　　　１．ガイドの紹介
　　　２．手順集
　　　３．設計書から形式仕様への直し方
　　　　　　→作業説明例

・形式手法適用実証実験
　東京証券取引所とＤＳＦ
　ＩＰＡ／ＳＥＣ　形式手法適用実証ＷＧで
　　　　山本先生、（九大）荒木先生、中島先生

・今後の活動
　ガイド改定

・形式手法でできること

形式手法
　　形式仕様記述
　　　正しい仕様をつくり、残す
　　　　　ＶＤＭ＋＋など
　　形式検証
　　　モデル検査：
　　　定理証明：人間必要

レビューとの違い
　　・構文チェック、型チェック、ツールを使って検査

　わかること
　　・記述の矛盾がわかる
　　・暗黙値の発見
　　・あいまいさの発見

---

このあとのパネルディスカッションには出なかった。

第６回 要求シンポジウム その１

昨日、「第６回　要求シンポジウム」に行ってきた。
そのときのメモメモ（前半）

---

■ＩＰＡの挨拶
民事の争いが多くなっている
　　・医療事故
　　・知的財産
　　・建築
　　・ＩＴ(システム開発）
→情報の非対称性がある
　　→でも、最低限、双方理解しないといけないものがある
　　　　→前半：はっきり伝える、受ける、フィードバックして確認

司会：名古屋大学の山本先生
　裁判
　　　・運用がする前、してから問題が起こる
　　　　　　→過去に引き戻される

---

■ビジネスアナリシス　最前線
　ＩＩＢＡ日本支部　研究担当理事　宋　氏
（山本先生のコメント：アメリカと日本では開発のコンテクストが違う）

【ＩＩＢＡとは？】
　２００３年１０月創設
　ビジネスアナリシスの実践と資格のスタンダード開発・維持

【ＢＡＢＯＫ】
２００９年１２月　ＢＡＢＯＫ日本語版　７つの知識エリア
　　　タスクとテクニックの組み合わせ、知識の体系
２０１１年５月　　ＢＡＢＯＫ　Ｖｅｒ３　開発開始

・かなり抽象的に書いてあるので、直接的な問題解決マニュアルではない

【今日のお話】
北米：企業の組織の活動としてビジネスアナリシス
　→技術トレンドとしてある
　→ビジネスアナリシスの活動の傾向

【問題の起点】
・システムが複雑で、みな困っている
　　→システムは現場を写す鏡
・企業組織を４つに単純化
　　ビジネスシステムの世界
　　　　１．経営層が責任を持つ：経営のスコープ
　　　　　　　↓
　　　　２．業務組織が責任をもつ：ビジネスモデル
　　情報システムの世界
　　　　３．ＩＳマネージメント層が責任を持つ
　　　　　　　↓
　　　　４．情報システム開発・運用
　→様々な組織の壁、コミュニケーションギャップ

　　　現実の世界　　－（写像）→　　仮想の世界

【典型的な課題：その１　要求が複雑】
・要求の盛れ、ダブり
・要求の対立（複雑になると）→干渉していることを見つけるのが難しい
・要求が複雑→企画・要求定義を強化する→チェックしきれない
●解決策：いったん業務のシンプル化
　　　　　　商品のシンプル化
　　　　　　プロセスのシンプル化

【課題：その２】
・ビジネスを取り巻く環境変化
　　→経営目標・戦略が俊敏に適応
　　→情報システムもアジャイルに適用できないと・・
　　　　→実装段階でコードを凍結
　　　　→このギャップは？

・北米では
　ビジネスアナリシスマネジメント
　　　　＝ビジネスプロセスマネジメント
　　　　　　＋ビジネスルールマネジメント

　ファクトモデルで業務の基本構造をあらわす
　　・名詞を取り出す→四角い箱にいれる
　　・動詞を取り出す

　ファクトモデルという舞台の上で
　　ビジネスルールでコントロールされた業務のシナリオ（手続き）を語る

　・ビジネスイベント
　　　・業務処理
　　　・評価ポイント
　　　・処理

　アプリケーション本体に、ビジネスルールの評価と処理の部分は混在していないか？
　　　処理はシンプル：変わらない
　　　ビジネスルールの評価と処理が変わる

　北米：業務(ビジネスプロセス）とビジネスルールを分離する

---

■ＲＥＢＯＫ　南山大学　青山先生

　顧客要求からソフトウェア要求までをカバーする知識体系が欠如している
　　　要求工学方法論をいろいろ出しているのは、日本しかない
　ビジネス・プロダクト要求
　システム要求
　ソフトウェア要求
　（ソフトウェア開発）
　　→ＩＳＯ２９１４８に対応

４つのプロセス：特別なものではない
　　　　　→ＳＷＥＢＯＫ第二章と基本的には同じ枠組み

　・要求獲得
　・要求分析
　・要求仕様化
　・要求の検証・妥当性確認・評価

要求獲得：要求の原泉Ｘ獲得方法
　・ステークホルダー分析
　・ゴール分析
　　　　ソフトゴール・ハードゴール・タスク
　・シナリオ分析

文書化
　・ビジネス要求の文書化　IEEE Std.１３６２
　・システム要求の文書化　IEEE Std.１２３３
　・ソフトウエア要求の文書化　IEEE Std.８３０

要求管理
　・ＰＭＢＯＫといかに組み合わせるか

現在、人材育成とモデルカリキュラム→報告書が作成できそう

３つの提言
・要求の価値を生かそう
・要求工学の本格的な実践を図ろう
・要求工学の人材を育成しよう

---

■ディスカッション

　宗さん、青山先生、山本先生

【要求のＢＯＫ】：下流から上流に上がってきた。
　他の知識体系との融合は？

・宗さん
　ＢＡＢＯＫはどのように利用する？：目的指向
　　→どのくらい、整理統合されている？
　　　どういう目的に対して、Change of Change
　　　　ビジネスケイパビリティの実現

・青山先生
　スコープ：ＲＥＢＯＫのミッション
　ＲＥＢＯＫ：知識とタスクの組み合わせ

・ＥＡとの親和性、ファクトモデル（＝ＤＯＡ）
　ＳＢＶＲ（Semantics of Business Vocabulary and Rule)
　　　：ファクトモデルのノーテーションツールでもある

【リスク分析は？】
　ＲＡＣＩが役立った。
　ＰＭＢＯＫのリスク（リスク・ブレークダウン・ストラクチャー）
　
・青山先生

・宗さん
　現状の問題解決方法では解決しない。
　有効な解決策の導出→リスクが出てくる

【クラウド】
・つくるだけじゃなくって、すでにあるんじゃないの？

・宗さん
・ビジネスシステムと情報アーキテクチャーに整合しているか？
　　ノンコアならＯＫ
・わが社のビジネスアーキテクチャは？

・青山先生
・アジャイル、クラウドでも
　　→ＳＬＡ

【複雑なものに対して】
・保証ケース（アシュアランスケース）
　　→エビデンスがあるから、保証される：ゴール指向で
・要求発展型開発ワーキング
　　→ＩＴ技術の発展

・青山先生
　　複雑さを低減しようとしている：要求工学

・宗さん
　　そういう問題を意識している（ＢＰＯとかも）
　　物売りビジネス→サービスに変化

【ＥＡ】
・ザックマンのフレーム：基盤
　　→チェンジフレームワーク
・ＥＡ：フレームワークと、ユーザーの視点（シナリオ・ユースケース）


【運用】
・オペーレーション要求に対する分析が必要なのでは

・宗さん
　例外：ビジネスルールから仕様化

・青山先生
　チェックとアクション

---

ここで、休憩になって、後半戦へ

なので、このエントリもここでいったん、きります。

マッシュアップって、ＳＯＡだよね！って、言っちゃだめなの？

昨日、ＮＨＫのＩＴホワイトボックスみてて思った
（半年前にも見てたはずなんだけど・・）
マッシュアップって、ＳＯＡだよね。

ＲＥＳＴ　ＳＯＡ　でググルと
約 17,700,000 件


マッシュアップ　ＳＯＡ　でググルと
約 2,820,000 件

だから、ＲＥＳＴほど、そう思われてないかもしれない・・
でも、そうだよね・・

と思ったら、

SOA陣営とマッシュアップ陣営の間に緊張高まる
http://builder.japan.zdnet.com/etc/20374394/

を発見。緊張してるんですか・・

「マッシュアップって、ＳＯＡだよね！」って、言っちゃだめなの？

ビッグデータって、儲かるための統計処理は「まだまだ」って気がする・・

Cloud Days Tokyo 2012に2/29に言ってきた感想。

スマートフォン、big dataの展示も同時開催だったため、
スマートフォンのセキュリティとかも多かった。
クラウドは、ＤＣより、開発環境とかの出展のほうが、多かった気がする。

どっちかというと、売れる商品というよりか、売りたい商品を展示している気がしたのは、
・・・気のせい？

ビッグデータは、このデータ分析をすれば儲かりまっせ！みたいなのは、
まだまだだと思う。
結局、バスケット分析や協調フィルタリングみたいなものどまりで、

これを買っている人は、なぜ、買っているのか？

という因果関係を知るような、因子分析、ベイジアンネットワークとかを
やさしくやるっていうのは、まだまだなんですかね。
この辺について、統計用語を使わないで、やさしく見せれば、儲かる
統計処理になりそうな気がする。

---

さて、その展示で、ちょっと気になったこと
CouchBaseっていうのがでてたんだけど、
あれって、CouchDBとどういう関係なのかしら？？

と思ったら、

NoSQL データベース『CouchDB』を Couchbase が大幅強化
http://japan.internet.com/webtech/20110618/1.html

ってことなのね。なっとく

そこに、キレイなまとめがあったので、ここに貼っとく

MySQLのクエリーキャッシュが効かない場合

ＭｙＳＱＬで、同じSELECT文を発行する場合、クエリーキャッシュを使うと早くなることがある。
クエリーキャッシュは、my.cnf(my.ini)でも設定できるし、mysqlのコマンドとしても設定できる。

---

■ 設定
今回は、mysqlのコマンドで、以下のように行う。

SET GLOBAL query_cache_size = 100000;


■ 確認
これで、

SHOW VARIABLES LIKE 'have_query_cache';

でYES

SHOW VARIABLES LIKE 'query_cache%';

で
query_cache_sizeにいくつかの値が設定されている
（100000と設定しても100000にはならない）


SHOW STATUS LIKE 'Qcache%';

で

Qcache_hits　　　　　　　（ヒットした件数）
Qcache_not_cached 　　　（ヒットしなかった件数）
Qcache_queries_in_cache 　（キャッシュ内のクエリ数）

等が表示される（他にも表示される）。

---

■効かない条件

　しかし、このクエリーキャッシュは、いくつかの効かない条件がある。

http://dev.mysql.com/doc/refman/5.1/ja/query-cache-how.html

には、以下のようなものがあげられている。

・準備されたステートメント (準備文)
・クエリが外部クエリのサブクエリである場合
・Stored プロシージャ、Stored 関数、トリガ、イベントなどのボディ内で実行したクエリ

Zendの古いバージョンなどだと、クエリーキャッシュが効かないとかいうのは、
「準備されたステートメント」＝PreparedStatementの問題。

で、ここから本題。
これ以外のケースではまったので・・・

データベース名に-を含むもの、たとえば、te-st1とかは、単純には作れない。
ところが、`te-st1`とかして、名前を指定すると作れる。
この場合、データベースの中に、テーブルは作れ、そのデータベース内に
入れば、SELECTはできるけど・・・

クエリーキャッシュは効かない。

---

■例
（以下、＞は、本当は半角）
いま、test2とte-st1というＤＢに、
test1というまったく同じテーブルがあったとき、

mysql＞ reset query cache;
Query OK, 0 rows affected (0.00 sec)

でキャッシュをリセット後

mysql＞ SHOW STATUS LIKE 'Qcache%';

+-------------------------+-------+

| Variable_name           | Value |

+-------------------------+-------+

| Qcache_free_blocks      | 1     |

| Qcache_free_memory      | 90736 |

| Qcache_hits             | 2176  |

| Qcache_inserts          | 792   |

| Qcache_lowmem_prunes    | 599   |

| Qcache_not_cached       | 1184  |

| Qcache_queries_in_cache | 0     |

| Qcache_total_blocks     | 1     |

+-------------------------+-------+

8 rows in set (0.00 sec)



mysql＞ use test2;

Database changed

mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ SHOW STATUS LIKE 'Qcache%';

+-------------------------+-------+

| Variable_name           | Value |

+-------------------------+-------+

| Qcache_free_blocks      | 1     |

| Qcache_free_memory      | 89200 |

| Qcache_hits             | 2178  |

| Qcache_inserts          | 793   |

| Qcache_lowmem_prunes    | 599   |

| Qcache_not_cached       | 1185  |

| Qcache_queries_in_cache | 1     |

| Qcache_total_blocks     | 4     |

+-------------------------+-------+

8 rows in set (0.00 sec)

というように、test2のデータベースを使って、
test1を３回検索すると、
Qcache_queries_in_cacheと、 Qcache_hits の数があがる
（その前に何回もテストしているので、０ではないけど）

ところが、この直後、te-st1のＤＢに対して、同じことをやっても、

mysql＞ use `te-st1`;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A



Database changed

mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ select * from test1;

+------+--------+

| id   | mydata |

+------+--------+

|    1 | abc    |

+------+--------+

1 row in set (0.00 sec)



mysql＞ SHOW STATUS LIKE 'Qcache%';

+-------------------------+-------+

| Variable_name           | Value |

+-------------------------+-------+

| Qcache_free_blocks      | 1     |

| Qcache_free_memory      | 89200 |

| Qcache_hits             | 2178  |

| Qcache_inserts          | 793   |

| Qcache_lowmem_prunes    | 599   |

| Qcache_not_cached       | 1189  |

| Qcache_queries_in_cache | 1     |

| Qcache_total_blocks     | 4     |

+-------------------------+-------+

8 rows in set (0.00 sec)

というように、 Qcache_hits は上がらず、 Qcache_not_cachedがあがる。
つまり、キャッシュされてない。