『Club MySQL #5 ~SQLデータベースのセキュリティ』開催しました

 久々の「Club MySQL」となる、『Club MySQL #5 ~SQLデータベースのセキュリティ』を開催しました。

mysql.connpass.com

Club MySQL は、ひとりの講演者の話をじっくりと聞こう、という趣向の、日本MySQLユーザ会のイベントシリーズです。今回は、徳丸浩先生にお引き受けいただき、Webセキュリティの視点でデータベースとして注視すべき点について語っていただきました。テーマとスピーカーのパワーで、当ユーザ会のイベントとしては「驚くほどたくさんの」参加申込みをいただき、ありがとうございました。

ライトニングトーク

 メインスピーカーにも、膨大な経験をもとに90分間たっぷりと濃厚な話を聞かせていただきましたが、ライトニングトークだってパワフルです。
 まずは「中の人」山﨑さんからMySQLセキュリティ強化の歴史について紹介していただきました。昔のMySQLは「置いたらすぐに使える」ことを目指していたこともあって、初期ユーザ、初期データベースなどに「したい放題」だったところがあるのですが、最近は少しずつ(いや急速にかも)「カタくする方向」に進んでいます。どのバージョンでどんな施策が採られてきたのか、とても整理されていて、勉強になりました。LTでというお願いだったので(それでも10分くらいお話されていましたが(笑))、ちょっと内容の濃さに対して慌ただしくなってしまったので、これにプラスしてその中から特に注目の施策についてもう少し掘り下げてお話を聞かせていただく機会を作りたいですね。
 yoku0825さんからは、過去のオラクルさんのMySQLセキュリティに関するセミナーを紹介する形で、DavidとJackの行動について語っていただきました。頭が良いのだか要領悪いのだかよくわからない David と Jack から我々はMySQLのデータを守ることができるのか。次々と悪いことを思いつく DavidとJackにドキドキしながら、話を聞かせていただきました。

徳丸先生の「ウェブセキュリティから見てデータベースってどうなのか解説する」

 このイベントの私の役割である「進行役」として、常に時間を気にしながら運営を進めているわけですが、今回徳丸先生にお願いした「90分くらいで」に対して、ほんとにきっかり 90分(プラス1分程度)でまとめてくださったことに驚きました。私も大概、何ヶ所かに伸び縮み可能な話題を入れておき、50分程度のセミナーならぴったり終わらせる自信はありますが、90分は誤差が出すぎてなかなか調整が難しいです。 徳丸先生の経験と職人技に、ちょっと感動しました。
 と、内容じゃないところの感動をまず紹介しましたが、もちろん内容にも感動しています!

 まず、Webセキュリティという観点、つまりMySQLを取り巻く実行環境全体が話題になる点が新鮮でした。MySQLユーザ会の勉強会というと、どうしてもMySQLにものすごく近い部分だけのお話--いわばMySQLの「中から」--になることが多かったので、MySQLの「外から」というのが今回のお話の視点でした。
 もう少し「データベース一般的」なお話が中心になるかと予想していたので、想像していた以上にMySQL固有のお話をたくさん入れていただいたのが嬉しかったです。私は、文字列の自動変換('ab'+'c' のような)は知っていたものの、まさかカラム値のほうまでが自動変換の対象になっているとは認識していなかったので、この話は驚きました。後ほど本件は別ブログとして書こうと思います。
 SQLインジェクションに始まり、文字エンコーディング、型変換、同時実行時の重複データ、そしてTDE。最後にそれぞれの対策によって守れるもの守れないものの整理が、特に良かったです。時々「データファイルを暗号化しておいたら最強じゃん?」と考えている感じの人に遭いますが、正しい入り口(表門(おもてもん))から来た人に対しては、いとも簡単にデータを渡してしまうので、いかに、正しい人だけ表門を通過させるかというのとセットで考える必要があるわけですね。

全体総括

 徳丸さんが、その前のLTで登場した DavidとJackを積極的に取り入れてくださった機転に、大笑いしました。これから動画をご覧になる方の中には、徳丸先生目当てでそこだけを視聴するつもりの方もいるかもしれませんが、ぜひLTもご覧いただけたらと思います。セットで見ると、徳丸さんの「ワザ」がわかると思います。
 今回の発表いただいた皆さんの内容、たいへん勉強になりました。DBMSセキュリティの分野では今後、悪いことをする人は David と Jack ということで定着しそうです(するのか?)。もう少しお話いただけそうな感じでもありましたので、またお誘いさせていただきます!このたびは、どうもありがとうございました。


当日の模様(動画:日本MySQLユーザ会YouTubeチャンネル)

www.youtube.com



当日の模様(ツイート:Togetterまとめ)

togetter.com



『JPUG & MyNA合同勉強会 -PLEASE 2021/4-』参加

エイプリルフールの騒動(当社比)から12日ほどが経った頃、yoku0825さんが勉強会を企画してくれました。

connpass.com


DBMS(やそれ以外のソフトウェア)で PLEASE 句の動作を実装する試みが行われたことを受けて、せっかくだから技術的な内容を含む話を披露しあおうじゃないか、という感じで開催してくれました。形式としては、日本PostgreSQLユーザ会(JPUG)さんと、日本MySQLユーザ会(MyNA)の合同勉強会ということで、開催となりました。PostgreSQL(澤田さん)、MySQL(yokuさん)それぞれの「拡張」から話が広がっていったので、まさに合同勉強会というに相応しい会になったと思います。

 発表は、いかのように盛りだくさん。

イノレカ㌠ sakaik MySQレの新機能:PLEASE句について(仮)
🐘㌠ masahiko_sawada PostgreSQLの新機能: PLEASE句について(仮)
🐬㌠ yoku0825 MySQLの新機能: PLEASE句について(仮)
redis㌠ maruloop Redisの新機能: please getコマンドについて(仮) LT
SparkSQL㌠ miyakelp_ SparkSQLの新機能: PLEASE句について(仮) LT
Oracle㌠ nori_shinoda Oracleの新機能: PLEASE句について(失敗ver)(仮) LT
SQL Server㌠ Masayuki_Ozawa SQL Serverの新機能: PLEASE句について(仮) LT

 postgreSQL澤田さんの、ライブコーディング(その場でコードを修正し、ビルドして動かしてみせる)がとても刺激的でした。MySQLは多くのコードから参照されている部分に変更が入るため、再コンパイルが広い範囲に発生して、ちょっとこの時間でライブでサクサク見せるのは難しいということで「こちらにできあがったものが良いされてございます」メソッドで。
 日付が変わっちゃう!と急いで実装を試みてくださった方、ソースコードに手を加えることができないのに、主処理に渡る前になんとか処理してやろうと試みてくださった方々、大笑いしながら、楽しく聞かせていただきました。


 私自身も、騒ぎを起こした責任を取って冒頭、少々お話をさせていただきました。PLEASE句自体の話は、もう元ネタをご覧いただければそれがすべてなので、その周辺の話として、感謝・経緯・そしてエイプリルフールのネタに対するポリシーといった内容についてお話をしました。一応資料も公開しましたので、ご笑覧いただけましたらと思います。MySQレというのは、実は立体的なMySQLだったという説明も含んでいますので、スライドを行ったり来たりしながらご確認ください:-)

www.slideshare.net


 これにて、一連のエイプリルフール狂想曲は一旦のおひらきとなります。たぶん。
たまたまちょうど良くハマったネタと、すごい技術力が集まると、こんなに面白いことになるのだという、素敵な体験をさせていただきました。改めて、乗っかってくださった皆さんありがとうございました。

動画もMySQLユーザ会の YouTube チャンネルで公開されています。なんか私のスライド、ちっちゃく出てるなーと思ったら、そうだ。セカンドモニタを縦にして使っているので、そのせいだ!!(だいたいイベント発表の時には横置きに戻しているのですが、このときは忘れたみたい)

www.youtube.com


 また、MyNAとJPUGの共同主催の勉強会ですので、MySQLユーザ会のイベントへの登壇者数にもカウントします。(2021年は MySQLユーザ会関連イベントに 41人以上の人に登壇していただきたい、という目標を掲げております~MySQL 41 Speakers~)

■2021/04/12 MyNA & JPUG合同 PLEASE
04(2). @sakaik さん: MySQレの新機能:PLEASE句について(仮)
09. @masahiko_sawada さん: PostgreSQLの新機能: PLEASE句について(仮)
10. @yoku0825 さん: MySQLの新機能: PLEASE句について(仮)
11. @maruloop さん: Redisの新機能: please getコマンドについて(仮)
12. @miyakelp_ さん: SparkSQLの新機能: PLEASE句について(仮)
13. @nori_shinoda さん: Oracleの新機能: PLEASE句について(失敗ver)(仮)
14. @Masayuki_Ozawa さん: SQL Serverの新機能: PLEASE句について(仮)

 楽しいお話をありがとうございました。

時代に即したMySQレの新機能:PLEASE句

 最近は、会社などの組織において仕事の指示をする場合に、単に上司が命令をするだけでは組織は動かないと言われています。部下に仕事をしてもらうには--そう、まさにこの「してもらう」の気持ちこそが本質なのですが--「命令」ではなく「依頼」の形を取ることで、お互いに気持ちよく仕事をすることができ、より良いチームとなるのです。


 この世の中の流れは近年、ソフトウェアの世界にも強く適用されるようになってきました。ソフトウェアに於いても、常に、より中立的な立場での対応が求められてきています。

 MySQレも例外ではなく、最近の修正ではレプリケーションの master-slave を source-replica と呼ぶように変更したり、blacklist を blocklist に変更したりなどの話題を目にした方も多いと思います。
 これら一連のポリティカリーにコレクトな対応に今回新たに加わったのが、冒頭で紹介した「依頼」の構文です。例を見てみましょう。まずシンプルなSELECT文である、

SELECT * FROM t1;

という命令。これは現代のポリティカルコレクトネス的にはアウトです。人間だからといってコンピュータに一方的に「命令」するのは、よろしくありません。MySQレの最新バージョンでは、この問題に対応しています。

SELECT * FROM t1 PLEASE;

命令ではなく、依頼。これが新しいデータベースの活用法です。

PLEASE句は、先頭に配置することもできます。

PLEASE UPDATE t2 SET c1=100 WHERE id=1;

命令ではなく、依頼。
ちょっとした気遣いで、依頼する側もされる側も気持ちよく仕事ができるのです。

 ある実験によると、PLEASEを付けて一ヶ月間運用を続けたシステムは、そうでないシステムと比べて、約6%のパフォーマンス向上が得られたとのことです(モーツァルトを聴かせて運用しているMySQレの性能が3%ほど高いという話と似ていますね)。

 コンピュータと人間とが共に気持ちよく過ごせる社会へ向けて、MySQレも進化し続けているのですね。頼もしいことです。



.


 なお、蛇足ながら本日4月1日でございますことを付記し、本アーティクルをおしまいとしたいと思います。
Please DO NOT believe this article.

[MySQL]


.

追記

 yoku0825 さんが、MySQL で実際に動くパッチを書いてくださいました。
blog.gmo.media

  • PLEASE句をエラーとせずに受け入れること
  • PLEASE句がついていないぶっきらぼうな「命令」には1秒間のサボタージュをしてから結果を返すこと
  • PLEASE句がついていないぶっきらぼうな「命令」にはwarningを出すこと。エラーコードにもこだわり
  • PLEASE句が書いていない場合にはエラーにするための SQL_MODE ("STRICT_PLEASE_MODE")の追加

の対応が為されているようです。バイナリは配布せず、ソースコードのパッチのみの公開。MySQL 5.6 をベースにしたのは、ビルドの速さ(トライ&エラーを繰り返しやすい)を重視して、かな。(MySQL 8.0 のビルドには結構時間がかかる)

 久々に、「才能の無駄遣い」と絶賛したくなるようなワザを目の当たりにしました。徐々にできあがっていく様子を yoku0825さんのtwitterで伺ったりしていくのは、面白かったです。

追記2

 あとは、結果を返してくれたことに対してお礼を言える THANK YOU 構文の実装が待ち望まれます。実装されれば、かなり MySQレとの距離を近づけるのに役に立ってくれそうです。



追記3

 澤田さんが PostgreSQL に実装してくれました! PLEASE句がないとインデックスを使ってくれないというのが特に新奇性! みんな、DBMSにちゃんと感謝してるんですね!

 さらに、THANK YOU 文まで実装!

 

追記4

 MySQレ について、「マイエスキューレ」という声がありますが(それはそれでイタリアではきっとそう呼ばれているのだろうと信じることにして)、実はMySQLだったというタネアカシ:-)



追記5

 オープンソースじゃないので Oracle database では無理だろうと思っていたら、中家さんが PL/SQL を使って遊んでくれました。pleaseをつけないと、ちゃんと遅くなってくれます!(・・・って、やりたいの、それだったっけ(笑)。付けると速くしたいんじゃなかったっけw)

 そしてソースコード



追記6

 なんと、Spark SQL にも PLEASE句が! PLEASEつけないと DISTINCT しちゃうとか、極悪(笑)。
そうか、PLEASEつけないと 100件までしか出力しない、みたいな抗議行動も考えられるのか、とヒントをもらいました。

miyakelp.hatenablog.jp

追記7

 SQL Serverでのトライ! RDBMS本体側を書き換えることはできないので、TDSのProxy を噛まして、そのProxyで変換(PLEASE句の除去)やウェイトの挿入などを行っているようです。

blog.engineer-memo.com

追記8

 Redis にまで!!
RDBMSに、プログラムに、コンピュータに対して、単に命令するばかりでなく、感謝を込めて「お願い」する文化が少しずつ広がっていて、嬉しいです!




追記9

 「4/1に間に合わなかったけど」と、SQLite3 への実装(パッチ)も公開されました。大丈夫です、まだエイプリルフール5日目です!




追記10

 みなさんのTwitterでのやりとりが面白かったので、これは後生まで記録に残しておくべき!と、Togetterにまとめました。
togetter.com

たくさんの人に見ていただけて、トゥギャッター編集部さんの「本日のイチオシ」に選んでいただきました。みんなの開発パワー、すごい!



追記11

 それぞれの方が今回試みた技術的知見をそのままにしておくのは勿体ないということで、勉強会(発表会)が開催されることになりました。いや、べつにそんな大層な話じゃなくて「おもしろいからやろーぜー」というノリです。私も皆様の時間を奪った責任を取って1枠目で少しだけお話をさせていただきます。
connpass.com

Oracle社が公開しているMySQL動画情報まとめ

 MySQL の情報が欲しいとき、なるべく一次情報に近いところから探すことは大切なことです。
Oracle社はMySQLに関する様々な情報を公開していて、特に日本チームの皆さんはMySQLについての系統立てたセミナーを開催し、その動画を公開してくれています。これを学習や情報収集に活用しない手はありません!

・・・・なーんて偉そうに書いていますが、実は私も「そういえば動画を公開してるって言っていたっけ」と、つい最近思い出して、見てみようと思い立った次第でして。

 実際に動画を見ようとした時に、目的の動画にたどり着くのが少しだけ不便に感じたので、日本語動画についてこのページにまとめてみました。皆さんのお役にも立ちましたら。

■インストール編(Windows/Linux

videohub.oracle.com
videohub.oracle.com


■チューニング

videohub.oracle.com


■バージョンアップ

videohub.oracle.com

videohub.oracle.com


■最新情報(MySQL 8.0/ 8.0.23)

videohub.oracle.com

videohub.oracle.com


■その他

 いろいろ考えすぎてアタマが固くなってしまったアナタに。普段あまり聞かない言語を聞くとノーミソが柔らかくなるかもしれませんよ:-)

videohub.oracle.com
videohub.oracle.com

MySQLユーザ会会(MyNA会)2021年3月 開催しました

日本MySQLユーザ会として、「MySQLユーザ会会(MyNA会)2021年3月」を開催しました。
mysql.connpass.com


 通常、毎回4~5人くらい発表してくれるといいなぁと思っているMyNA会、今回登壇くださったのは3名とやや少なめではありましたが、そのぶん、普段聞けない立場からのお話、残念(自称)な感じながらも楽しんでいるお話(いやむしろ楽しんでいるのは周りの人かw)、MySQLの内部動作に関する深いお話など、濃厚なお話を聞かせていただける時間となりました。発表くださったみなさん、質問等で盛り上げてくださった皆さん、ありがとうございました。


 つたない進行のせいか、参加者の皆さんの声(意見や質問など)をうまく拾い上げられなかったことは少し残念でした。たぶん、皆さん、聞きたいことがもっとあったと思うんですよ。そういう皆さんの思いをイベントに拾い上げたいと考えていますので「こういうふうにしてくれたら、俺は質問をした/発言をした」というアイデアや思いがある方は、教えてください。せっかくリアルタイムで参加してくださっているのですから、後から単に動画を見るだけでは得られないことを体験できる場にしたいのです。



今回発表してくださったみなさま(数字は「MySQL 41 Speakers」の通番)。
お三方とも(たぶん)MySQLユーザ会会 には初登壇。ありがとうございます!

■2021/03/19 MyNA会
06. @kisaichi さん: 中の人が語る、MySQLマーケティング
07. @lrf141(けんつ)さん: 残念ポートフォリオ
08. @NayutaYanagisaw さん: Dive into InnoDB MVCC


当日動画:
www.youtube.com

MySQL 8.0.23で実装されたフレシェ距離関数(ST_FrechetDistance())を試す

MySQL 8.0.23で、Spatial(GIS)関連機能として、フレシェ距離を求める関数 ST_GrechetDistance() と、ハウスドルフ距離を求める関数 ST_HausdorffDistance() が追加されました。どちらも、2つのジオメトリどうしの類似度を求める関数のようですが、今ひとつよく分からないので、今日は主にフレシェ距離を中心に色々と動作を試してみて、「こういうことかな?」の理解を試みました。
 想像して、試して、結果に納得する、という作業ですので、正しくない理解を書いているかもしれません。お気づきの方は、やさしくお教えいただければ幸いです。

フレシェ距離とは

 ざっくり言うと、2つのジオメトリ(MySQL 8.0.23 ではLineStringのみ対応)がどれくらい似ているかを示す数値。2つの線があった時、片方の線上の任意の点から相手方の線の最も近いところまで、最悪でもどれくらいの距離を行けば良いかを示す数字、というざっくりとした理解をしています(この理解は、正確ではないことは実験していて分かりましたが)。
 なお、線上の任意の点と書きましたが、MySQLに実装されているのは「離散」のフレシェ距離、つまり、LineString を構成するために明示された各点のみを対象とするものです。

はじめてのFrechetDistance

 とりあえず、2つのLineStringを作って、ST_FrechetDistance()を試してみます。シンプルにこんな2つの平行線( ポイント数3)で。
f:id:sakaik:20210227171227p:plain

SET @g1=ST_GeomFromText('LINESTRING(1 1, 2 1, 4 1)');
SET @g2=ST_GeomFromText('LINESTRING(1 2, 2 2, 4 2)');
mysql> SELECT ST_FrechetDistance(@g1, @g2) d;
+------+
| d    |
+------+
|    1 |
+------+

 どの点から見ても、相手方の一番近い点は距離1のところにあるので、その中で一番大きなもの(遠いもの)も 1 となります。予想と結果は一致。

点をひとつ遠くにしてみる

青いほうの点(@g2)の真ん中の点を少しだけ遠ざけて見ます。赤い線(@g1)はそのままで。
f:id:sakaik:20210227172121p:plain

mysql> SET @g2_1=ST_GeomFromText('LINESTRING(1 2, 2 2.1, 4 2)');
mysql> SELECT ST_FrechetDistance(@g1, @g2_1) d;
+------+
| d    |
+------+
|  1.1 |
+------+

 @g1 と @g2_1 それぞれの点を比べて、真ん中の点の距離どうしが少し遠くなって 1.1 になったので、そのような結果が返ってきます。予想通り。

試しに横方向にも動かしてみる

 先ほどは真ん中の点をy軸方向にずらしてみましたが、今度は横方向に動かしてみます。
f:id:sakaik:20210227172416p:plain

mysql> SET @g2_2=ST_GeomFromText('LINESTRING(1 2, 2.1 2, 4 2)');
mysql> SELECT ST_FrechetDistance(@g1, @g2_2) d;
+-------------------+
| d                 |
+-------------------+
| 1.004987562112089 |
+-------------------+
1 row in set (0.00 sec)

 真ん中の点どうしの距離が、1よりも少し遠くなったのだということは分かりますが、この数字が合っているかどうか、もう少し確認してみないと。この数字は、直角を挟んだ辺の長さがそれぞれ 1 と 0.1 の直角三角形の斜辺の長さですから、これもMySQLを使って計算してみます。

mysql> SELECT SQRT(1*1 + 0.1*0.1);
+---------------------+
| SQRT(1*1 + 0.1*0.1) |
+---------------------+
|   1.004987562112089 |
+---------------------+

 一致しました。想定通りのフレシェ距離が得られたことが確認できました。

少し刻んでみると・・・・

 赤いほうの線(@g1)は固定のままで、青いほうの線を少し刻んでみましょう。(3,2)と(4,2)の間に (3,2) という点を追加してみます。言うまでもなく刻もうが刻むまいが線としては同じ線をあらわしているはずですが・・・・
f:id:sakaik:20210227173511p:plain

mysql> SET @g3=ST_GeomFromText('LINESTRING(1 2, 2 2, 3 2, 4 2)');
mysql> SELECT ST_FrechetDistance(@g1, @g3) d;
+--------------------+
| d                  |
+--------------------+
| 1.4142135623730951 |
+--------------------+

 おや。この数字はルート2。追加した点から相手方の一番近い点を探した結果、x方向に1、y方向に-1行ったところにある点が一番近いと見つけたということですね、これは。 
 つまり、MySQLの(離散)フレシェ距離では、結果として同じ線をあらわしているようなLineStringどうしでも、粒度(刻み方)が異なると数字が大きくなってしまうと考えてよさそうです。

フレシェ距離は順序が大切

 ここで改めて一番最初の事例に戻ってみます。
f:id:sakaik:20210227174627p:plain
 ただしここでは、赤いほうの線を右から左へ向かって定義してみます。

SET @g2r=ST_GeomFromText('LINESTRING(4 2, 2 2, 1 2)');

 2つの線を構成するPOINT自体に何ら変更はないので、同じ結果となることを予想していたのですが・・・・

mysql> SELECT ST_FrechetDistance(@g1, @g2r) d;
+--------------------+
| d                  |
+--------------------+
| 3.1622776601683795 |
+--------------------+

 これはどうも、例えば左上の点と右下の点の距離がフレシェ距離として表示されていますね。x方向に3、y方向に1だけ隔たっていますから、

mysql> SELECT SQRT(3*3 + 1*1);
+--------------------+
| SQRT(3*3 + 1*1)    |
+--------------------+
| 3.1622776601683795 |
+--------------------+

 うん。その点どうしの距離です。
つまり、フレシェ距離は、2つのLineStringを構成する点の集合どうしを比べるものではなく、LineString を構成する点を順に比較していくものと考えられます。いや、ほんとはよくわからないので、ご存じの方、教えてください。

一方、ハウスドルフ距離は

 ハウスドルフ距離のほうは、LineString内の順序ではなく、構成する点の集合のみに着目しているように見えます。
 先ほどの2本の平行線を逆順にしたもの(@g1 と @g2r)で試すと、距離1のままとなります。

mysql> SELECT ST_HausdorffDistance(@g1, @g2r) d;
+------+
| d    |
+------+
|    1 |
+------+

 また、ST_HausdorffDistance()は引数の順序が大切(どちらのジオメトリを基準に相手方との最小距離を求めるのか)であるようです。先ほどの「刻んだ」線である @g3を例に。

mysql> SELECT ST_HausdorffDistance(@g1, @g3) d;
+------+
| d    |
+------+
|    1 |
+------+

 相手方(@g3)が幾ら刻もうが、@g1側から見て一番近い点は 距離1のところにあるので、その値が結果として返ってきます。
 一方で、@g3側から見ると、刻んだ点(3,2)から見た相手方の一番近い点、というのが最長の最短距離になるので、ルート2の値が返ってくることになります。

mysql> SELECT ST_HausdorffDistance(@g3, @g1) d;
+--------------------+
| d                  |
+--------------------+
| 1.4142135623730951 |
+--------------------+

おわりに

 と、フレシェ距離、ハウスドルフ距離を試してみたのですが、今に至ってもこれらの関数がどのようなシーンで便利になるのか、今ひとつ分かっていません。。どなたか現実世界での使いどころをご存じでしたら、教えてください。
 また、冒頭でもお断りしたとおり、このエントリーは「よくわからない中で、とりあえずどんな動きをするのかを試してみた」というものですので、不正確な点、勘違いしている点等あるかと思います。ご承知おきください。
 なお、今回はデカルト座標で試してみましたが、これらの関数はもちろん各測地系にも対応しています。

MySQL Cafe #11「MySQL 8.0日本語ドキュメント」登壇しました

ラクルさん主催の MySQL Technology Cafe #11 にて、登壇させていただきました。今回のテーマは「MySQL 8.0 日本語ドキュメント」。お声がけをいただいたときに、ちょうど、ドキュメントについて語りたい内容を持っていたため、発表枠のお時間を頂戴してお話をさせていただきました。

oracle-code-tokyo-dev.connpass.com


今回の私の発表は、内容三本立て
(1)MySQL 8.0 の日本語マニュアル嬉しいよ嬉しいよ超嬉しいよ!!!!
(2)過去バージョンの日本語マニュアルのおもいで
(3)最近のマニュアルの更新差分を眺めてるけど、面白いよ!
発表資料(スライド)は、本エントリ末尾にあります。

「スライド」って書いて思いだしたんだけど(関係ない話)、最近は、発表の時に「次のスライドおねがいします」って台詞を吐いたことのない人も、たぶん増えてきていますよね。

MySQL 8.0 日本語マニュアル嬉しい!!!

 
 英語圏で開発され、公用語が「下手な英語」であるMySQL界において、英語以外の言語でマニュアルが公式に用意されるというのは、極めて異例のことです。恵まれているんです。世界中見回しても、英語以外は日本語だけなんです。 オラクル社社内でものすごいネゴシエーションをして、日本語マニュアルを作るプロジェクトを通して、完成させてくれている人がいることに感謝するとともに、我々一般技術者も、「日本語マニュアル、作るのはコストかかるけど、それに見合うリターンもあるな」と開発元に思ってもらえるよう、経済的な力はもちろん、日本でのMySQLを盛り上げていくために、みんなで少しずつ力を出し合えたらいいなと思っています。

 さて、そのMySQL。ご存じの通りOSSオープンソースソフト)です。オープンソースですが、かなり複雑化、巨大化して、少なくとも私のようなレベルの人では、もはや「オープンソースの開発に、ソースコードで貢献」というのは、かなり難しくなってきました。そんな中で、私たちでも貢献できるのが「翻訳内容の修正」です。今回、現時点で公開されているMySQL8.0日本語マニュアルは暫定版なので、みなさんからの修正提案を募集しているとのことです。提案して採用されるかどうかはオラクル社次第ですが、普通に意味がおかしい部分を報告してリジェクトされることはたぶんないでしょう。MySQLというオープンソースの(ドキュメントはGPLではありませんが)活動に貢献できるチャンスです。あなたの提案がMySQLの公式マニュアルに残るのです。なんか嬉しいじゃないですか。
 個人的には、1つずつ報告するのもナニなので、幾つかまとめて報告してみていたのですが、どうも、ひとつずつポロポロ報告している人もいるようなので、それでいいみたいです(笑)。ぜひみなさんも、MySQL日本語マニュアルに記念パピコをしてみてはいかがでしょうか。なお、報告された修正提案は3月中下旬にまとめて反映するとのことです。


 報告されている修正レポートの一覧(bugs.mysql.com):
https://bugs.mysql.com/search.php?search_for=&status=Active&severity=&limit=50&order_by=id&cmd=display&direction=DESC&bug_type%5B%5D=Server%3A+Docs+JP&os=0&phpver=8.0&bug_age=0


暫定公開の MySQL 8.0 日本語マニュアルは以下(4月以降は本公開となりURLが変わります):
https://dev.mysql.com/doc/translation-refman/8.0/ja/

マニュアルの思い出

 詳細は発表資料をご覧ください。
MySQLでは、すべてのメジャーバージョンについて日本語マニュアルがあるわけではなく、結果としてひとつおきくらいに作られていました。 MySQL 5.1 の日本語化の時には、海外の翻訳会社に依頼した結果を、コミュニティの有志(希望者)で、svnのファイルをゴリゴリ更新していったという思い出があります。翻訳会社も章ごとに担当者がいたようで、特に意味の通じないひどい章があったりしたのも、楽しかったなぁ(笑)。
 あと、発表資料中では MySQL 4.1 には日本語マニュアルがない、と書いてしまったのですが、その後、手元のPCのフォルダを漁ってみたら、謎の「refman-4.1-ja.a4.pdf」というファイル(MySQL 4.1 日本語マニュアル)が出てきました。日本語マニュアル、あったみたいです。

マニュアルの差分を見てみて

 どれくらいの頻度で、どんな内容が更新されているのだろうと興味を持って、昨年末(2020年12月)から、簡単な仕組みを作って、差分を眺めています。diffを取って、目視で面白そうなものがないかを眺めているという程度ですが、いち早く最新情報をキャッチアップできたり(でも、その新機能を試せるのは半年後だったりするのですが)、言い回しの変更を見ながらドキュメントチームのこだわりに接して楽しんでいます。
 html化されたマニュアル(MySQLマニュアルは、XML形式の原簿から PDFやHTML形式へと変換されています)には、変換時につけられるIDのようなものがHTMLタグ中に多く含まれているため、そのまま、昨日のマニュアルと今日のマニュアルのdiffを取ってしまうと、実際には内容の変更ではない部分で、大量の差分が出てしまいます。また、HTMLファイルでは、1行が長くなる事も多く、差分を確認するには、ちょっと見にくい面もあり、そのあたりに対する工夫なども紹介しました(詳細は発表資料を参照ください)。

 現時点では、公開するための仕組みを作っていないので、自分でニマニマしながら眺めているだけですが、差分に興味を持ってくださった方もいるようなので、とりあえず手元にある差分ファイル群をお見せできる形にしてサンプルページを作ってみました(雑に手作業で作ったものなので、更新はしません)。ちょっと apache の設定がうまくいっていないみたいで、ブラウザによっては charset を正しく認識できずに文字化けしているところがあるかもしれません。そのときは UTF-8 にして見てみてください。

MySQL refman diff sample.

その他

 発表の機会のドサクサに紛れてちょっぴり営業活動しちゃおうかな、なんて少し思ったのですが、発表内容の分量も結構あったので、そんなことよりも1分でも内容の話に時間を割きたくなり、あんまりちゃんと語りませんでしたので、改めてここで。
 コロナの影響で、私のお仕事面、実は結構時間にアキがある状態になっています。「坂井がいるとなんかよくなる」という仕事をしているので、仕事内容を説明するのにいつも苦労するのですが、、、データベースそのものの技術だけではなく「データの流れ」を全体俯瞰することで、お客さんが本当は何をやりたいのか(要件)、それはどのように格納・出し入れしたらいいのか(RDBMS設計)、発生しうるリスクにはどのようなものがあり、どの程度対応しておくべきなのか(リスク管理)的な事について助言したり、必要に応じて実際に手を動かしたりなどを提供しています。チームに入り込んで一緒に考えたり助言したりというやり方ですので、貴チームでこのあたりのノウハウにお困り・お悩みでしたら、ぜひ一度ご相談ください。 

 というお話を、あの場でやるのは時間勿体ないですもんねー(笑)。(そもそもたぶん怒られるw)



最後に

 あらためて、MySQLのドキュメントチームに感謝! 日本語版作成に尽力くださった皆さんに感謝! そして、きっとこのマニュアルの修正提案をしてよりよいものにしてくれるみんなにも感謝!!!





発表資料:

www.slideshare.net