MySQL性能回復活動(MySQL RP)を独自に始めます

ようやく、MySQL性能向上開発に専念する体制が整いました。やっと開発作業に戻れます。

実質無所属なのは人生初なので、各種社会保障関係の手続きとか、どのサイトを使って組み合わせるか、どういう設定でアカウントをつくるかなどなど、開発環境も含めて全部自分で決めなければならず、結構時間を要してしまいました。すみません。

結果、本家在籍時と同様の使い勝手で自由に開発できるようになりました。

名前は、『MySQL RP (Restore Performance)』 としました。 ソースコードはMySQLのオープンソースライセンス(GPLv2ベース)で提供します。最初は劣化がもう増えない、劣化が少ないと思われる 8.0 からforkして直していきます。まだ空っぽですが、数日中に更新が増えていきます。
バイナリ提供は余裕が出てから考えます。まだ無理です。既存の互換バイナリ提供者がpullしてくれるようになれば、それもいいかなと思います。

フルタイムで独自活動を続けていくために、支援者も募集します。
buildup-db と言う名前で Patreon に登録しました。(※)
MySQL RP の性能改善修正毎に、ベンチマーク結果、問題解析、ソース変更点の説明を有料会員向けに行っていきます。内容に興味のある方、最新コードで性能向上を体験できた方は、ご支援ください。

長年、影に隠れてきましたが遂に一人で細々と矢面に立つ羽目になりました。
ご期待に応えられるよう善処します。
よろしくおねがいします。

 

※6月4日現在、Patreonのアカウントにトラブルがあったようです。問い合わせ中です。Patreon側がアカウントの内容をレビュー中なのかも知れません。しばらくお待ちください。 

※6月17日現在、Patreonのアカウントが復活しました。github側で進んだ分の解説をしていきます。

今日から『自由』にMySQLの性能改善始めます。（MySQL開発チームを退職しました）

前回の在籍も含めると、累計9年半、本家MySQLチームでInnoDBの性能改善をターゲットに開発の仕事してきました。5.7でのb-tree index scaleや、8.0の初期の新機能で入ってしまった性能問題の修正など貢献できましたが、ここ数年は開発が進む度に導入される性能劣化に追いつけなくなってしまいました。悪いコードを見つけて直そうとしても抵抗が大きいのも大きな要因です。（遅くしたいのでしょうか？遅いことが認識できないのでしょうか？）

この度、体制変更で退職を勧められたのを機に、別の営みでMySQL/InnoDBの性能を改善していくことにしました。どうせ、性能劣化に(私よりも)無頓着な現体制では私が性能を改善することは困難なので、成果は出ないでしょう。（直しても、同時に導入される新機能・修正による劣化に改善分を喰いつぶされることもしばしばあった、と考えています。キリがありません。そもそも、性能に悪い新機能を通すための性能改善回復ではないのに…）
8.0以降の性能に最も満足していないのは私自身です。このままでは終われません。

というわけで、
これは「終わり」ではなく「始まり」です。

これからは、8.0の性能回復を個人で、できればフルタイムでコツコツやっていきます。支援が生活持続上十分に集まるようなら、そのままセキュリティ問題修正なども続けて、延長サポート終了後も8.0性能修正版を使えるようにメンテ・性能改善していきます。(8.0の修正が終了して且つ8.4も相当性能に直せたら8.4への移行も検討します)

会社やチームに気を遣って表現・説明を抑えることも、
理解できない人に際限なく説明して許可を求める必要も、
悪いコードを認めたくない作者に邪魔されることも、
公開の別ブランチならばもうないのです！(あったとは明言はしない。一応。)
なので、本家在籍中よりもスムーズに直していけると思います。（思えば、会社には性能改善に役立つものは何もなく、もう障害・妨害しかないと感じていました。）

体制（各種アカウント開設等）は近日中に整えます。本編は日本語英語併記でやろうと思ってます。
当面は、
github上にブランチを作成して公開。(GPL MySQLなので GPL)
支援者のみに、
ベンチマーク解析内容・修正内容解説を随時公開（これが本編に当たる）
していきます。

改善点がある程度落ち着いてきてから（当初は何も受け付けられませんが）、
いずれ個別ベンチマークの処理改善要望も募っていこうと思います。

乞うご期待です。

* なんで8.0かというと、「性能改善」が多く「汚染」はまだ少なく、EOL間際なので今後も「汚染」は増えづらいから、です。まずは、ここから直して、徐々に進んでいきます。

* 量子コンピュータとか技術革新で暗号通信が安全でなくなったら基幹はオンプレ回帰するはずで、そのときにクラウドでしかまともに動かないというのは不味いと思います。

* そもそも既存の古いオンプレでスケールしなくなったら、クラウドでもスケールしなくなると思うのですが、何を見て開発してるのか。。。