なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

詳解MySQL5.7出版記念イベント参加してきた

久しぶりのイベント参加

この手のイベント参加、久々だなー。
この手のイベント参加レポ書くの、久々だなー。


イベント、勉強会の類は、勉強会ブームを経て、毎日色々な所で開催されるようになっているわけだけど、自分も参加してなかったし、観測範囲で見ても、あまりレポ記事見る機会がなかったので、ちょっと新鮮。


それこそ「tsudaる」という言葉が生まれた当時を知るものとしては、色々感じるものがある。



で、本題。

今回は、こちらのイベントに参加してきたので、あっさりレポ。

eventdots.jp



1部の奥野さんのプレゼン、2部のパネルディスカッションの後に、その会場で懇親会があったのですが、諸事情により不参加。
懇親会は次のチャンスをうかがいます。


概要

id:nippondanji漢(オトコ)のコンピュータ道でおなじみOracleの奥野さんの最新著「詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド (NEXT ONE)」の出版記念イベントとして、奥野さんのプレゼンと、パネルディスカッションの2部構成で開催。


会場は五反田にある株式会社ネクストビートさん。



保育士向けサイトや、保育施設・保護者向け子育て支援のサイトやアプリ開発を行っているベンチャー企業です。
dotsに上がっている写真と同じ会場で、とてもきれいな会場でした。

開始前の様子

あいにくの台風直撃、開場の頃が非常に激しい雨に見舞われたこともあって、集まりがやや鈍め。
dots上でキャンセル待ちが出るほどの予約状態だったのに、直前にキャンセルが出たようで、dots上でも定員割れになってました。


前の方に座っていたのではっきりとはわかりませんが、最終的には8割強は埋まっていたようです。


第1部は、奥野さんの独演会。

「詳解MySQL 5.7 ~進化したMySQLをよく知るためのテクニカルガイド~ の解説」と題されていた第1部は「なぜこの本を書くに至ったか」というお話。


チャリで世界最高速度記録が出た話とか、某社ではなく翔泳社から出版となった経緯とか。


マーケティング的な「新機能たくさんあるよ」じゃなく、「どんな課題があって、どう解決をしようとしたか。本質を理解して、使いこなして欲しい。」という強い思いが伝わってくるプレゼンでした。




技術的な内容については「本読んでね」ということで。(メモ取るの忘れた&ガチで本の内容についてのお話なので)



ページ数を減らすことにかなり気を使ったようですが、ページ数を気にせずにガッツリ詳解する書籍も必要だと思うんですよね。


Oracleも最近は全然書籍が出てきませんが、Oracle8、8i、9iくらいの頃は、OraclePressと称してテーマごとに1冊5000円以上くらいの本が出てましたよね、翔泳社さんっ。


鍵本(奥野さんの前著エキスパートのためのMySQL[運用+管理]トラブルシューティングガイドと同じくらいの厚さで、チューニングで1冊、DBA業務で1冊とか、そんなノリで。


当時、全冊集める勢いで、めっちゃ読みましたもん、Oracle Press。


MySQLにも、それくらいの本があってもいいと思うんです。(今のご時世だと、売れないって判断されてボツ企画になってしまうのかな)





第2部パネルディスカッション

参加登録のときに事前に集めていた質問をベースに奥野さん、ネクストビートCTOの衣笠さん、モデレータとしてChatWorkの加藤さん、ちょいちょい参加でOracleの横道さんによるパネルディスカッション。


正直、レプリケーションをRDS任せにしている似非MySQLerな自分にはついていけない部分もありました。だって便利なんだもん。


個人的に印象深かったのは以下の5点。

シャーディングはプログラマの負担が増える。MySQL Cluster使うことも考えて。

確かに、PK、UKやら、JOINやら、本来RDBMSの中で完結する機能を、シャーディングすることでプログラム側でなんとかしなきゃいけないのは良くない、って考え方、わかります。


DB屋から見ると、シャーディングって「必要悪」だと思います。


一方、MySQL Cluster、まったく勉強できてない自分。


MySQL自体、書籍が少なくて困っているのに、Clusterになると更に少ない。ネット上の情報も多くない。


ブログ等でMySQL Cluster方面にも触れてほしいですね。


それこそ、MySQL5.7がどんな課題をどう解決しようとしているかを語るように、MySQLで抱える課題を、MySQL Clusterではどう解決できるのか、そんな語りがあると、導入検討する人が増えるんじゃないかと思います。



パーティショニングは刈り込みできないと非パーティショニングより遅くなるから、使うな!それよりもIndexしっかり使え。

詳解MySQL5.7の中でも7章「パーティショニング」の冒頭でかなりネガティブな話をしていますが、かなり語調強めでした。
設計した人がOracleのノリでパーティション切りまくってる現場にこの話を言えないっす。。。

InnoDBのCompress使うな!(特に5.6以前)

「データはおよそ1/2に圧縮できるが、性能も1/2になる。バッファプールを圧縮用、非圧縮用に別々に確保しなきゃいけないから、ハードウェアのメモリを実質半分しか使えない。
どうしても圧縮使うならMySQL 5.7。ただし、デメリットも理解した上で(本に記載あり)。」
とのことでした。


使ってなくてよかった。。。。



まだSlowQueryで疲弊してるの?PerformanceSchema使いなよ!

Performance Schema使い込んでる人、会場でも挙手ゼロ。
まだまだ知られてない、使い込まれてない、そんな感じでした。


かくいう自分も、全然使い込めてない。


これも、ブログ方面でもっと情報が出てくるといいと思うところです。
ちょっと古くからMySQLを使っている人は、ptツール使い込んでいる人が多い用で、ソッチ方面はボチボチ見つかりますが、Performance Schemaの記事ってホント少ない。
こんなときはこんな感じのSQLで、ってサンプル付きで解説あると、かなり嬉しい。


特にRDSのように、OS層にアクセスできない、プラグインやら3rdツールをインストールできない環境では、Performance SchemaやSysスキーマに頼らざるを得ないので、重要度がますます上がってくると思います。


論理削除?論理削除という言葉自体がおかしい!

削除扱いにしたいけどデータは保管しておきたい、そんなときは、別テーブルに移して、本体のテーブルからはレコードをDeleteしろ、と。
MySQLのDeleteが遅い?それは5.1までの話。5.5以降で遅くなる原因は解消されてる、って。


論理削除の問題はMySQLにかぎらず議論になるところだけど、テーブルの役割と肥大化による性能低下のことを考えたら、相当な頻度で論理削除扱いのレコードを参照する必要がない限り、テーブルを分けるのが妥当だよね。




その他、Replace構文とINSERT文 ON Duplicate key update構文のパフォーマンスの問題とか出ましたが、はっきりとした答えはなかったので、あとで検証してみたいと思います。



というわけで、ガチおすすめです。

atsuizo.hatenadiary.jp
に続き、2度目のPushとなりますが、ガチでおすすめです。