MySQL徹底入門4版 ここがすごい!...かもしれない

 9年ぶりの全面改定「MySQL徹底入門 第4版」がいよいよ発売日になるので、私の主観と、思い入れと、おふざけ心を駆使して、「MySQL徹底入門 第4版 ここがすごい!」・・・かもしれないところを紹介したいと思います。

ページ数が変わっていないのがすごい!

 2006年発売の第2版から、ほとんどページ数が変わっていない。機能の増加や運用ノウハウの蓄積の紹介などの状況変化を考えると、ページ数は増えるのが自然だが、MySQL徹底入門は、徹底した製作プランに則り、やみくもにページ数が増えることを自制している。 詳しい人が紹介したいことを書きまくって分厚い本を作る、というのは、時間はかかるけど、実は本の製作としては難しいものではない。MySQL徹底入門は、この書籍作りの最大の難所とも言える「むやみに膨らむ」ことを克服した本なのです。
 f:id:sakaik:20200705182330p:plain

オビの文句が変わっていないのがすごい

 9年の歳月を経ても、オビの宣伝文句が第3版とあまり変わっていないのがすごい。特に、オビの背はまったく同じ! オイコラ!手を抜... えぇとコホン、、、、えぇまぁ、その、、MySQLの進化の中においても変化する必要のない一本筋通ったキャッチコピーがつけられていたということで、すごい!

著者が新しいのがすごい

 第3版が出てから9年。たくさんの人がMySQLに興味を持ち、さまざまな情報交換や情報の公開をしてくれる「MySQL仲間」になってくれました。そんな「いま最もMySQL(のある部分)に詳しい」人たちに執筆陣に加わってもらいました。人数が増えると進行管理がどんどん大変になるのですが、そんなことをものともせず(いや、、、本当は大変だった...)まとめ上がった MySQL 徹底入門 第4版、えらい(ぺんぎん省略)。

4000円を超えちゃったのがすごい

 ・・・申し訳ございません。時代の流れということもあり、3版では据え置きにした価格を、第4版では税抜き 3,800円となりました。前版から 9.2% ほど高い値付けとなります。9.6%であれば「苦労(9.6)したので、そのお代として・・・」と洒落るところでしたが、9.2%だと、「苦肉の策としまして..」と言うしかないのかもしれません。「急に(9.2)決まりました!」とでも言っておきましょうか。 消費税5%なら、税込みギリギリ 3,990円なんですけどね。
 内容は、MySQLをお使いの方なら納得していただけるものになっているかと思います(あなたの興味の分野にも依ります)。内容に見合う価格になったのがすごい!(←やや無理矢理言ってみた感ある)

各言語から使うための情報がすごい

 初版からのMySQL徹底入門の大きな特徴であり、多くのページ数を割いてきた「各種プログラム言語から使うMySQL」にも大きく手を入れました。ページ数は減らしましたが、各言語から使うために必要な情報をきゅっと凝縮しています。紹介する言語の見直しも行い、Pythongolang が加わっています。とってもイマフウですごい!
 (小口部の写真。プログラム言語から使うMySQL の章は、写真のピンクで丸をつけた部分)
f:id:sakaik:20200705190354p:plain

運用ノウハウがすごい

 上の写真の、緑色の丸の部分。「プログラム言語から使う」章に匹敵する存在感を放っている、この部分。ここが今回第4版の第6章「MySQLの運用」の章です。ここが、徹底した製作プランに則り、やみくもにページ数が増えることを自制し、、、、きれなかった章です。オイコラ! ・・・あ、いやコホン。。。 まさに「芸術は爆発だ!」なみに、これでもかと運用ノウハウが詰め込まれている章です。実際の運用の考え方というのは、自分で苦労して場数を踏むか、詳しい人と一緒のチームで研鑽を積みながら力を付けていくしかないものですが、この章はまさに、詳しい人の生々しい実体験に基づくお話が惜しげもなく披露されている章と言って良いでしょう。すごい!
 同様のすごさは8章「レプリケーション」も。 MySQL 8.0 はレプリケーション機能も旧版の頃と比べても随分と拡張されています。MySQL8.0で知っておきたい GTID/グループレプリケーション/トラブルシュートまで満載で、すごい!

14章がすごい

 ページをめくっていくと突然現れる別世界。それが14章。現実世界でも「この人にこの話題で質問するんじゃなかった...」と後悔する経験は誰もが持っていると思うが、まさにそれ。「軽い気持ちで訊いちゃったけど...」と後悔する間もなく、1を訊いて10を聞く、という世界が待っています。この章はテンションがおかしくてすごいので、すごくすごい!

ほかにもすごいがいっぱいですごい

 全部の章の内容は紹介しきれなかったけど、あなたが興味を持った章。その章はすごい! たとえば私が書いた7章は、MySQLを初めて触る人がとりあえず覚えておきたい「MySQLの中の状態やオブジェクトなどを見る方法」を紹介したものだが、共著者の厳しいチェックを通っている。ずっと私が勘違いしていたことをいくつも指摘してもらったりして(たとえば mysqlクライアントコマンドの命令なのか MySQLサーバの命令なのかの区別)、書籍全体を通して、誤解されやすい部分や勘違いして書いてしまった部分は、結構つぶされている。すごい!

売れすぎてすごい

 未来のことは分からないものだが、きっとこのエントリを読んだみなさんが現実のものにしてくれると信じて書いておく。 この本はデータベースの本としては異例なほどに、とにかく売れすぎて、すごい!(未来予測)


 「MySQLを使うために各自お手元にまずは一冊」の書籍としてお役に立てることを願います。買ったら、読んだら、本書をぜひSNSやブログなどで紹介してみてください!

MySQLのレプリケーションで「master」と「slave」が廃止へ!(用語の話)

 本件、いろいろ思うところや意見はあるのだけど、それはtwitterで書いたので、ここでは淡々と紹介します。

 本日、MySQL High Availability ブログにて、MySQL内での用語の変更について、以下の発表がありました。

https://mysqlhighavailability.com/mysql-terminology-updates/

ざっと、内容を紹介すると(箇条書きの下に変更内容):

  • レプリケーションで使っている master/slave という言葉はネガティブな言葉だ。それはクリア(明らか)だ。
  • 既に我々はブログとかプレゼンで、これらの言葉を色々言い換えてきた。
  • なので、そろそろソースコードとドキュメントの変更にも手を付けようかなと。
  • 旧master を、primary ではなく source にしたのは、いろんなレプリケーション構成がある中で必ずしも「primary」なわけではないから。
  • コマンドや出力内容から、これらの言葉を除去するのは、ちょー(huge)大変。時間かかる。段階的に。
  • 例えば SHOW SLAVE SATUS。これを deplicated にして、今後は SHOW REPLICA STATUS にする、みたいな。
  • 今週はじめに ドキュメンテーションチームが、本件最初の変更を公開したよ。

ということです。

変更用語:

master source
slave replica
blacklist blocklist
whitelist allowlist

 
 
f:id:sakaik:20200702095600p:plain

『MySQL徹底入門第4版』が 本当に 出ます!(MySQL 8.0 対応)

 MySQL を知りたい人向けの定番入門書として名高い『MySQL徹底入門』という本があります。2020年6月現在、第3版が出ていて、その発行は2011年、対応バージョンがMySQL 5.5でした。
そして来月 2020年7月。待望の第4版が出版されます。
 第4版は、過去3つの版のコンセプトを引き継ぎつつ、全体にわたって1から書き起こした本です。当然 最新の MySQL 8.0 に対応。9年に1度の最高のできあがりであり、MySQL 8.0 を知りたい人には絶対にお勧めの一冊と言ってよいかと思います。
 なお、今更ですが一応表明しておくと、このエントリーは、私の主観に基づいたものであり、著者としてのポジション的なトークも含まれています。平たく言うと、ちょっと盛ってます。その真偽は、実際の書籍を手に取ってレジでお金を払って、皆さん自身の目でご判断ください。
 
 
 Amazonさんに、「2020年7月6日発売」と出た時には、まだまだ校正作業の真っ最中。作業には結構時間がかかっていて、いや、これ7月6日発売とか冗談でしょ?言ってみてるだけだよね?しれっとそのうち7月二十何日かに書き換わるよね、って、結構本気で思っていました。
 しかしその後の著者陣、編集者ともに、頑張りが素晴らしかった! あれこれとどんどん片付いていき、そのせいで私はお詫びを出す羽目に。

 
 
 もちろん、日程のために適当に辻褄合わせをしたなんてことはなく、むしろ徹底的に内容にこだわりました。なるほど、というところから、少しくすっとするところまで、幅広く笑える一冊になっています。真偽は皆さん自身の目で(以下略)。
 
 そして昨日。印刷を終えた見本誌が私の手元に届きました。
f:id:sakaik:20200628143143j:plain

 ほんとに7月6日には出るみたいです。ころころ変わる MySQL 8.0 を相手に、色々なこともあって、企画から足かけ3年。非常に難産だったとも言える本書。こうして手元に来たことが、感無量です。 あとはこの本が次々に皆さんのお手元に届いて、「絶賛大人気!発売即100万部突破!」の報を待つばかりです。

 なお、データベース管理システム(RDBMS)自体がまったく初めてという方には、本書とは別に「SQL」の入門書を用意されることをお勧めします。本書は、「MySQLの」特徴や機能、使い方などを紹介することに重心を置いている「MySQLの入門書」のため、標準的な(一般的な)SQLそのものの学習用途には向いていません。 逆に「SQLの入門書」には、RDBMS(ソフト)の細かい使い方はあまり書かれていないので、本書と併用していただくのが良いかと思います。



 それでは、快適なMySQLの旅をおたのしみください。
 
 
 
(ポーン)

OSC2020-Online Hokkaido 参画

オープンソースカンファレンス(OSC)2020 Online Hokkaido に参加してきました。
event.ospn.jp

 もともと、「普通」に札幌現地で開催される予定だったイベントですが、「新しい普通」にオンラインで開催へと変更されました。飛行機等を早めに取っていたので、キャンセル代が心配でしたが、最終的にキャンセル代なしで取りやめることができました。JALさん、ありがとう!!(余談ですが、北海道入りする日に、気持ちがなんとも納得できず「今頃このへんを飛んでいるハズだった」と確認したら、乗る予定の便は「欠航」となっていました。とりあえず決行するぞと思っても欠航だったので、まぁこれで結構だったのではないかとほっとして血行もよくなりました)


 気持ちだけでも北海道気分を味わいたくて、お昼は、すみれ、おやつにはマルセイバターサンドを食べました。北海道最高!
f:id:sakaik:20200627124112j:plain:w400f:id:sakaik:20200627165524j:plain:w400


 春先から何度か開催されている OSC-Online。いままで私は見る側でしか参加していなかったのですが、やっぱり北海道だし、そろそろ見ていて勝手も分かってきたので、はじめてユーザ会としてもセミナー参加をしてみました。
 @yoku0825 さんと一緒に、
MySQL BoF ~ 聞こう・語ろう MySQL ~ - セミナープログラム - オープンソースカンファレンス2020 Online/Hokkaido
 という枠を担当させていただきました。BoF と名打ってはいますが、やはり会場と一緒になって話題を進めるのは(リアルの場でもなかなか難しいのに、最初の第一声を上げるハードルがより高いオンラインでは)なかなかうまく行かず、基本的には yoku さんと坂井とで「みんなの前で雑談」するスタイルとなりました。でも、とみたまさひろさんがマイクオンで、文字コードの話題を中心に色々入ってくださったのが、とても助かりました。
 この「みんなの前で雑談」なスタイルとは、基本的にはスライドを使わずに、その分野(今回だとMySQL)の情報に普段から多めに触れている人が、ただ雑談するだけ、というスタイルで、数年前から色々試しているものです。リアルな会場では、ある話題の時に一斉にメモを走らせている様子がわかったり、「は?」という表情で顔を上げる人がいたりして、そういった会場の反応を見ながら話題を膨らませたり掘り下げたり、あるいは逆の反応なら適当に概略だけ話してその話題をやめたりといったライブ感のある方法です。準備が要らなくてラクなようにも見えますが、使わない話題まで用意をしておいたり、現場での舵取りが要求されたりなど、実はセミナー資料を用意してその順にお話するだけのほうが、ずっとラクだったりもする面もあります。本当に好き勝手なことを話していると、(普段からMySQLに深く接している人は)自然と「これは知ってるよね。その上で・・・・」と前提条件を上げてしまいがちなので、そのへんも結構気をつかいます。
 時間効率的な面や、プロジェクタでの投影では小さい文字は見えないことから、あんまりこの場で、実際に画面を使って動きを見せるのは、あまり私は気が進まなかったのですが、今回 yoku さんが、文字コード(ソート順)の例をさくっと見せてくださり、オンライン開催なら結構よく見える(閲覧環境に依るけどPCなら問題ない)ので、これもアリだなと思いました。
 今回は、Zoom での開催ながらもYouTubeへの流し込みも行っていたので、そちらでご覧いただいた方も多かったようです。(開始前はYouTubeには流れていないと思い込んでバカ話をしていたら、全部流れていたそうで、お耳汚し失礼しました。五十肩は結構つらいです)

 今回登壇して感じたこと。とくに2人での掛け合いだったので、「時間なのでおわりにしまーす」「「ありがとうございましたー」」と言ったあとで、そのままおしまいになる点は、まだまだ改善可能だなぁと思いました。講演終わって、そのまま別々のドアから出て電車に乗ってそれぞれ帰っちゃう感覚。聞いてくれた人がブースに来てくれて、興味ある話題を一緒にやる、という余韻がないんですよね。 技術的には単に、Zoomの別部屋を立ててそちらに移動ということなのでしょうが、それがOSCのブースとしてなのか、MyNAで独自に立てるのかなど、立て付けは色々考えることがありそうです(イメージとしては、OSCでのセミナー枠の1時間くらい前に開けて、終了後1時間くらいまで開けておく感じ)。次回の大きめの開催への課題となりそうです。

 セミナーを聞く側としては、唯一、登さんのセッションを聞かせてもらいました。濃厚な内容を順序立てて分かりやすく話す進行に、胸を打たれました。これは45分枠1回(実際は55分くらいだった)ではなく、5回シリーズくらいにわけて聞きたいくらいでした。

 懇親会は、OSC-Hokkaido恒例の会場からのバスには乗らず(←イメージ)、おうちで夜ごはんを食べたあとで少し遅れて参加しました。まぁOSC北海道の懇親会は帰れない。なぜか帰るタイミングを失い、(翌朝早くに出る用事がなければ)結構良い時間まで参加してしまう。今回はオンラインで家からの参加だから大丈夫だろうと思っていたのに、楽しい話題で盛り上がり、結局抜けたのは3時30分過ぎ。なんだ、現地に行っても行かなくてもだいたい同じ結果になるんじゃないか。OSC-Hokkaidoの安定感、恐るべし(笑)。

 断片的ながらも、実際に現地に行っているような気分をたくさん味わえた OSC北海道(online)でした。運営されたみなさま、セミナー聞いてくださったみなさん、懇親会で遊んでくれたみなさん、どうもありがとうございました! いつかまた北海道に実際に伺える日を楽しみにしています!



 

MySQL道普請123回のUPDATE前にロッキングリードの話を読んでの感想と実験(追試)の結果

 gihyo.jpの連載「MySQL道普請便り」の最新回(第123回)は、ロッキングリード(SELECT ~ FOR UPDATE)のつかいどころのお話が興味深かったです。

gihyo.jp


 乱暴に要約すると、例えば 5000枚のチケットを捌くUPDATEは、いきなり UPDATE するのではなくて、SELECT ~ FOR UPDATE でロックを取ってからUPADTEすると、同時実行数が大きくなっても遅くならないぞ、という内容です。人気のあるチケットの販売って、瞬時に大量の更新が走りますからね。 まさにチケットを捌くと、あっという間に砂漠みたいに何もなくなります。ひと仕事終えた人たちはデザートでもどうぞ。砂漠だけに。

 想像ですが、これは、いきなりUPDATEをするとロック競合が発生してしまって、待ちがどんどん大きくなっていくところを、敢えて、より「軽い」SELECTでロックだけ取って(取れない場合は待たずにすぐにやめる)、その後にロックが取れた人だけ悠然とUPDATEをすることで、ロック待ちが発生しなくなる、とか、そんな感じなのですかねぇ。

試してみた

 ということで、自分のところでも試してみました。8.0.20 on linux

テーブル作成。

DROP TABLE IF EXISTS reserve_ticket;
CREATE TABLE `reserve_ticket` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `ticket_type` int NOT NULL,
  `user_id` bigint DEFAULT NULL,
  `update_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `tickettype_userid` (`ticket_type`,`user_id`)
) ENGINE=InnoDB;

 データ作成の前に、cte_max_recursion_depth の最大値が1000では足りないので、上げておきます。

mysql> SELECT  @@cte_max_recursion_depth;
+---------------------------+
| @@cte_max_recursion_depth |
+---------------------------+
|                      1000 |
+---------------------------+
1 row in set (0.00 sec)
mysql> SET @@cte_max_recursion_depth = 10000;     


 データ挿入(まだ売れていないチケット5000枚)と確認。

INSERT INTO reserve_ticket (ticket_type, update_at)
  WITH RECURSIVE t AS (SELECT 1 as i UNION ALL SELECT i+1 FROM t WHERE i<5000 )
  SELECT 1200, null FROM t;

COMMIT;

SELECT * FROM reserve_ticket;

 bash のほうで、以下の2つのSQLを、mysqlslap を使って実行。
SQL1が単純にUPDATEをするもの、SQL2がロッキングリードをしてからUPDATEするもの。

SQL1=`cat << EOS
BEGIN;
UPDATE reserve_ticket SET user_id=1 WHERE ticket_type=1200 AND user_id IS NULL;
COMMIT;
EOS`;

mysqlslap --host=localhost  -p --port=3306 --user=root  --query="$(echo $SQL1)" --concurrency=50 --number-of-queries=5000 --create-schema=test
SQL2=`cat << EOS
BEGIN;
SELECT @id := id FROM reserve_ticket WHERE ticket_type=1200 AND user_id IS NULL LIMIT 1 FOR UPDATE;
UPDATE reserve_ticket SET user_id=1 WHERE id = @id;
COMMIT;
EOS`;

mysqlslap --host=localhost  -p --port=3306 --user=root  --query="$(echo $SQL2)" --concurrency=50 --number-of-queries=5000 --create-schema=test


実行は、毎回、テーブルを DROP/CREATE して発売前チケット5000枚をINSERTしてから行いました。
 結果は、、、、、、

 
 
SQL1(単純UPDATE) (2回やりました):

Benchmark
        Average number of seconds to run all queries: 5.894 seconds
        Minimum number of seconds to run all queries: 5.894 seconds
        Maximum number of seconds to run all queries: 5.894 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

Benchmark
        Average number of seconds to run all queries: 7.749 seconds
        Minimum number of seconds to run all queries: 7.749 seconds
        Maximum number of seconds to run all queries: 7.749 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

 
 SQL2(SELECTでロック取ってからUPDATE) (2回やりました):

Benchmark
        Average number of seconds to run all queries: 23.950 seconds
        Minimum number of seconds to run all queries: 23.950 seconds
        Maximum number of seconds to run all queries: 23.950 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

Benchmark
        Average number of seconds to run all queries: 24.234 seconds
        Minimum number of seconds to run all queries: 24.234 seconds
        Maximum number of seconds to run all queries: 24.234 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100


 あれっ!? あれれっ????


ということで、今日は「ちょっとそのまま動かしてみるくらいなら時間取れるかな」という感じで始めたものなので、これを追求する時間は取れず。 必要なコマンド類は上に全部揃っていますので、どなたか続きをお願いします(笑)。
 少し考えてみた程度では、何が道普請の実験結果との相違に寄与しているのか、まったく見当もつかず。
バージョン? サーバのパラメタ? 他に動いているプロセス? メモリに入っちゃうとかそういうやつ? 操作した人の思いやりの心? ストレージ(HDD/SSD)? うーむ。

 ということで、煮え切らないまま、今日の日記はおしまいです。

追記

 という日記を公開したら、道普請著者の北川さんから速攻でコメントいただきました。

 ぱっと見て「あ、ここおかしいわ」って分かるの、(自分の記事とはいえ)すごいです。ちょっと感動しました。 
 そんなわけで、「遅くなってほしかったクエリ」は、最初の一発で5000件すべてupdateして、残りは(nullの行がひとつもないので)何もしていないという実験を行っていたのでした。そりゃ速い(笑)。
 
 
 LIMIT 1 を追加しての再実験です。

SQL1b=`cat << EOS
BEGIN;
UPDATE reserve_ticket SET user_id=1 WHERE ticket_type=1200 AND user_id IS NULL LIMIT 1;
COMMIT;
EOS`;

mysqlslap --host=localhost  -p --port=3306 --user=root  --query="$(echo $SQL1b)" --concurrency=50 --number-of-queries=5000 --create-schema=test

 
 
 結果は(これも2回実行):

Benchmark
        Average number of seconds to run all queries: 23.837 seconds
        Minimum number of seconds to run all queries: 23.837 seconds
        Maximum number of seconds to run all queries: 23.837 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

Benchmark
        Average number of seconds to run all queries: 24.036 seconds
        Minimum number of seconds to run all queries: 24.036 seconds
        Maximum number of seconds to run all queries: 24.036 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

 おお!!! 「SELECT~FOR UPDATE」と同じくらいの時間になりました!!!
・・・って、これじゃぁまだ足りないんですよね。もっと競合起こして遅くなりまくる状況を再現したいので、たぶん私の実験では、遅くなれてない(変な言い方ですが)ような気がします。この状況での律速って何なんだろう。 メモリでもストレージでもないような気がしていますが。。

追追記

 という追記を終えて公開した途端、twitterで更なる情報をいただきました。

 おいこら!!! いや、、、もう、北川さんに言っているというよりも、記事の内容を理解して、自分で気づけよ!!というツッコミです。 ここがキモじゃないですか!読んで、内容理解してないってことじゃないですか(自分に対して)。

 ということで、気を取り直して、SELECTでロック取得できなかった時にはスキップしちゃう(その結果、UPDATEのWHEREにマッチするものがないのでUPDATEはすぐ終わる)という、本来やりたかった実験です。

SQL2b=`cat << EOS
BEGIN;
SELECT @id := id FROM reserve_ticket WHERE ticket_type=1200 AND user_id IS NULL LIMIT 1 FOR UPDATE SKIP LOCKED;
UPDATE reserve_ticket SET user_id=1 WHERE id = @id;
COMMIT;
EOS`;

mysqlslap --host=localhost  -p --port=3306 --user=root  --query="$(echo $SQL2b)" --concurrency=50 --number-of-queries=5000 --create-schema=test

 
 
 結果(これもテーブル作り直して2回実行): 

Benchmark
        Average number of seconds to run all queries: 3.544 seconds
        Minimum number of seconds to run all queries: 3.544 seconds
        Maximum number of seconds to run all queries: 3.544 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100

Benchmark
        Average number of seconds to run all queries: 3.714 seconds
        Minimum number of seconds to run all queries: 3.714 seconds
        Maximum number of seconds to run all queries: 3.714 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100


 やったね!たったの4秒弱で完了するようになりました。
著者じきじきのtwitterサポートをいただき、ありがとうございます!

おまわりさんに挨拶された話

 今日の夕方のこと。私は駅で電車を降りてから道路脇の歩道を西向きに歩いていた。往復二車線の、よくある街なかの道路である。縁石で区切られた歩道がある道である。
  向こう側からバイクに乗ってやってきた人が、ふと、こちらにむかって会釈をしたような気がした。よく見ると、パトロール中のおまわりさんだった。言っておくが、私は地元のおまわりさんに知り合いは、いない。酒飲みながらバカ話できるおまわりさんの知り合いが1人や2人いたら面白いだろうとは思うが、残念ながら、いない。 挨拶なんてされるわけがないのである。寧ろ、何か目をつけられたのではないかと、ドキッとしたほうである。
 
 
 気のせいだったのかもしれないと、あまり気に留めていなかったのだが、家に帰ってから、全く別の調べ物をしているときに、こんなブログに出会った。今をときめく登さんであることにも驚いたし、このタイミングでこの情報に遭遇できたセレンディピティにも驚きである。


softether.hatenadiary.org



 曰く、おまわりさんは敬礼を受けたら返礼しなくてはならないらしい。
そう。今日の帰り道のちょうどそのとき、西日の余りのまぶしさに私は、スマホを握りしめたままの右手をおでこに当てて、光が目に入らないようにした。そこに通りかかったのが、パトロール中のおまわりさんだったのだ。

 嗚呼、おまわりさん。私はただ、まぶしかっただけなのです。あれは敬礼ではないのです。なんか、申し訳ありませんでした。
といいつつ、これを知ってから、げらげらと笑い転げている私でした。
これからは、おまわりさんを見かけたら「ごくろうさまです!」の感謝を込めて、敬礼しちゃいそうです。

f:id:sakaik:20200616202906p:plain:w200
ごくろうさまです!

MySQLリリースノートを読む会を開催してみました(8.0.20)

 リリースノートというのは、最新情報の宝庫でもあり、自分が知らなかった機能に関する情報に触れる機会でもあります。MySQLのリリースノートは、各バージョンがリリースされるごとに比較的しっかりと記述されているという印象があるので、これを見ながらそれぞれの興味関心を持ち寄ってわいわいとやったら面白いんじゃないかな、と以前より思っていました。
 オフラインで、わざわざ特定の場所に足を運んでまで参加するか、というと多少惹きの弱いテーマであることは否めず、なかなか開催できずにいた中で、昨今のオンライン会合のズーム、、、じゃなくてブーム。Twitterで反響伺いをしたところ「これはいける!」との確証を得られたので、まずは1回開催してみました。
mysql.connpass.com

企画運営者として

 非常に豪華な方々に参加表明をしていただいて、開催の1週間前からとても楽しみでした。ありがとうございます。各自が普段注目しているポイントがなんとなくわかったり、リリースノートを見るポイント(というかコツ)が少し得られたり、実り多い開催だったと思います。

 今回は初回だったこともあって、8.0.20のリリースノートというだけでなく、リリースノート全般の話にも広がりました。回数を重ねていくと、そのへんのネタが出尽くして、そのバージョンの話題に収束していくのかなと考えています。そういった変化を楽しめるのも、新企画の魅力かもしれません。

 企画運営者として、場がうまく回るように色々と考えたつもりでしたが、実際にやってみると(参加メンバーにもよりますが今回のような「濃い」メンツだった場合は)進行役として余計な口出しはしないで、場の流れに任せた方が盛り上がるなぁという感触を得ました。たとえがおかしいかもしれませんが「馬なり」でも余裕で勝てる感覚。
 なので、次回以降は場の流れに気は配りつつも、進行役としての介入はなるべく減らそうと思った次第。終了時間のコントロールと、あまりに同じ話題が長く続いた時の交通整理くらいかな。

 そんな運営上の諸々の知見を次回に向けて整理すると、次回はこんな感じでやろうと考えています。

■次回開催案(今後改善点とか)

  • 進行方法は、発表用意がある人がいればそれ(ひとり3分程度まで)+ディスカッション その後フリーディスカッション(今回と同じ)
  • フリーディスカッションは、リリースノートの項目を挙げて、それについて語るのが原則(今回は、少し「どれ」かがわかりにくいところもあった)
  • 参加していた人は手元のリリースノートを検索しながら見ているのでまだ良いのですが、動画を見てみると、どの項目かわかりにくかったので、誰かが画面共有でその項目の部分を出しておくといいなと思いました(その話題を出す人でもいいし、誰か担当決めてやるのでもいい。誰も出してないなと思ったら率先して画面共有持って行ってもらう形式でもいいし、いろいろ方法はありそう。)

 あと、私が開催に関わるオンラインイベントは、単なる情報の伝達ではなく、参加者どうしの交流という面も強く意識しています。オフラインのイベントでも、会が終わった後に、会場が許せばその場や廊下で、あるいは道路に出てからやどこかのお店に移動しての「その他のこまごました話」とかをするのがとても楽しいと思っていて、オンラインイベントでもそんなことができたらと考えています。ほら、オンラインイベントって「じゃぁ終了します。ルームクローズするね、ぶちっ」というのが多いですよね。なんか寂しいじゃないですか。
 オンラインイベントでの実現方法はいくつかありますが、私は、本体の会が終わった後にもしばらくルームをあけておいて「放課後モード」とか「二次会」とか呼んで雑談の場にするようにしています。(そのほかのやり方としては、誰か別の人が別のルームをあけて、参加したい人はそちらに移動する方法。イベントのホストの負担が減るのと、そっちのほうが「二次会」に移動する感じがでて面白そうですね)
 今回も、当然「放課後モード」も盛り上がりました。

いち参加者として

 非常に面白かったです。色々教えてもらえました。
冒頭でひとつ発表させてもらいました。、リリースノートの先頭に「○○に関するノート」のような項目が並んでいますが、あれの、バージョンごとの傾向について。

www.slideshare.net

 当初、直近3バージョンくらいの傾向を整理できたらいいな、と手作業で整理を始めてしまったのですが、もう少し見たくなって、結局 8.0 GA になった 8.0.11 からのすべてを(結局最後まで)手作業でまとめてしまいました。 最初から全バージョンやるつもりなら、もっと別の方法を使ったのに、少しアホなことをしてしまった気分ではあります。
 資料の中の表を見ると、どのタイミングでどういう機能に力を入れているかが少し見えてくる気がしませんか。


 その他、今回得た知見

  • リリースノートはどこから読む?→とりあえず deplicated 的なものから。removedも重要
  • deplicated に分類されていないところに、deplicated なものが書かれていることもあるので注意
  • Functionally added という項目が必ずあるが、そもそもそれを疑問に感じないところが MySQLer (マイナーバージョンですよね、普通機能追加ってないですよね、という話)
  • リリースノートの記述は前向き指向。MySQLサーバがクラッシュするようなバグの場合には crash と検索しても見つからない。exit で検索すべし、とか。
  • spatial index が効かない(効かなくなった)不具合の修正。8.0.19で作ったインデックスは、8.0.20で作り直さないと、結果が正しく得られないっぽい、というhmatsuさんの実験結果。
  • とみたさんの "MySQL Parameters" は、バージョン間の比較にとても便利。

https://mysql-params.tmtms.net/

  • MySQL 8.0。機能が増える=常にワナが発生し続ける ということでもあり、マイナーバージョンアップ、つらい

動画公開

 この会のイベント動画を公開しました。基本的に、参加している人同士でリアルタイムにわいわいやることを主旨としているので、後から動画だけ見てどれくらい面白いものなのか、正直なところよくわかりませんが、これも一つの実験として、公開してみます。
 興味を持たれた方は、ぜひリアルタイムで参加してみてください。


www.youtube.com

f:id:sakaik:20200613180325p:plain:w10