すべての発表資料もすでに公開されていますので、Summit に参加できなかった方でも議論の内容を確認することができます。
提案された機能は4つのワークストリームに分類され、現在は GitHub 上の MySQL Community Roadmap プロジェクトボード でそれぞれ確認できます。
- AI and Cloud (AIとクラウド)
- Performance and Observability (性能と可観測性)
- Dev and DBA Experience (開発/運用性の向上)
- Extensibility and Tooling (拡張性とツール拡充)
なぜこれが重要なのか
活発なコントリビューターコミュニティを育てることは、MySQL オープンソースプロジェクトの成功にとって重要な要素です。MySQL に貢献する方法や理由は数多くあります。
- MySQL で遭遇した問題を修正するためのパッチを、自分で継続的にメンテナンスする必要をなくすため
- 自身のキャリアにおける市場価値を高め、専門的なスキルを向上させるため
- MySQL が最も広く普及しているオープンソースデータベースであることを活かし、自分のアイデアやプロジェクトについてフィードバックを得たり、ユーザーを増やしたりするため
理由が何であれ、MySQL は皆さんの貢献によって支えられています。皆さんの貢献によって、以下のようなことが可能になります。
- バグをより迅速かつ効率的に修正できる
- ユーザーから要望されたカスタム機能のうち、OracleのMySQLエンジニアリングチームによる開発を待つだけでは実現しなかったような機能も、ユーザーが利用できるようになる
- MySQLを、自分自身や自分のアイデアをより大きなユーザーコミュニティにつなげ、直接コラボレーションできるプラットフォームにできる
- 開発者の裾野を広げ、その中から将来的にシニアなMySQL開発者やデータベース開発者へと成長する人材を増やすことができる
どこから参加するのか
現在の動きを追いかけたい方、さらに一歩進んで次期MySQLバージョンの企画や開発に参加したい方にとって、最適な出発点は MySQL Community GitHub Discussions です。このGitHub Discussionsは、実際にMySQL Serverに取り込まれるコードの開発に関する議論の中心となっています。ただし、議論はコードだけに限りません。技術的なトピック、提案、ロードマップへのフィードバック、コントリビューションプロセスに関する質問なども扱われています。
MySQL Community Slack は、一般的なコミュニティでの議論や交流の場として広く利用されており、MySQLをデータベースとして利用することに関する一般的な話題を議論するのに適した場所です。
参加の度合いに応じて、Oracleの統合ユーザーアカウントにも登録しておくことをお勧めします。これにより、フォーラム、MySQLバグデータベース、その他のMySQLサービスを利用できます。従来からあるバグデータベースについても引き続き維持していきますが、新機能の開発についてはGitHub Issuesを使用していきます。
そして、より静的な情報については、MySQL CommunityプロジェクトのWikiにまとめられています。ここでは、新しいMySQL Governance ModelやDeveloper Guideを確認できます。Developer Guideでは、Feature Requestやプロポーザルの提出からプルリクエストに至るまで、開発プロセス全体について説明しています。
MySQL コミュニティへの貢献に関するその他のリソースは、mysql.com の Developer Zone でも公開されています。
Early Accessリリースと毎月のコード公開
6月25日にお伝えしたように、現在は文書化されたガバナンスプロセスが用意されています。このプロセスでは、さまざまな企業に所属するコントリビューター、コミッター、プロジェクトリードに加え、個人として参加する人々もいることが前提とされています。
これまでに、9.7.0 Early Accessと26.7.0 Early Accessという2つのEarly Accessリリースを提供しました。これらのリリースに対応するコード公開の準備もすでに進んでいます。コードのコントリビューションに取り組む人にとって、比較的新しいMySQLソースコードのスナップショットを入手できることは当然ながら非常に重要です。また、mysql-server GitHubリポジトリに各種ワークフローの自動化を導入する作業も進めています。
これらの準備がすべて完了し、ある程度安定して運用できるようになった段階で、公開された mysql-server リポジトリ上でMySQLの開発作業をリアルタイムに進めるオープン開発へ移行します。これはCommunity Engagement Planのフェーズ 3として、今年後半に予定されています。ただし現時点でもフェーズ 2の一環として、MySQLコミュニティからのプルリクエストを受け入れるための準備はかなり整っています。
議論から実行へ！
では、見るべき場所が分かったところで、実際の開発最前線では何が起きているのでしょうか？ 現時点で各ワークストリームがどのような状況にあるのか、簡単に紹介します。
その前に……MySQL 26.7がリリースされました。そしてうれしいことに、5月のContributor Summitから生まれた最初の改善（Bug #119222）がすでにマージされ、26.7リリースに含まれています。このパッチは、mysqlsh util.dumpInstance() の呼び出し後にMySQLからmysqlshへデータを返す処理のパフォーマンスを改善するものです。複合主キーの場合、すべての主キー列を使用して結果セットを分割することで、より滑らかで均等に分散されたチャンクを生成するようになりました。
リリースに取り込まれた最初のパッチを作成したのは、PerconaのSveta Smirnova氏とKamil Holubicki氏です！
多くの読者がご存じのとおり、Perconaは長年にわたってMySQL Serverに数多くのバグ修正や機能をコントリビュートしてきました。そのため、コミュニティコントリビューションの新しい時代においても、いち早く貢献いただいたことは驚くことではないかもしれません。
Percona の皆さんに感謝します。今後もMySQLの新しいバージョンをオープンに、そして共に開発していく中で、大小を問わず、さらに多くのコントリビューションが生まれることを期待しています。
AI and Cloud
ここで最も重点が置かれているのは、本格的なベクトルインデックス、距離関数、検索機能をMySQLに導入することです。ここ数か月にわたり複数の選択肢が提示され、議論が重ねられてきました。現時点では、SQL構文やパーサーの拡張、クエリオプティマイザの両面で第一級の機能として扱われる、組み込みのインデックスタイプとしてネイティブに実装する方向で合意が形成されつつあります。
設計フェーズは現在も進行中で、さまざまなベクトルインデックス構造やアルゴリズムを検討しています。広く利用されているHNSW（Hierarchical Navigable Small World）アルゴリズムに加え、Googleで開発された ScaNN（Scalable Nearest Neighbor） と呼ばれるアルゴリズムにも大きな関心が寄せられています。構文設計に関する議論を見ると、複数の異なるインデックスタイプをサポートする方向も検討されているようです。
また、Alkin Tezuysal氏による MyVector というプロジェクトもあります。これはMySQL PluginとUser Defined Functionとして実装されています。次回のブログ記事では、これらのベクトルインデックスアルゴリズムと実装について詳しく紹介します。
ベクトル対応が明確に優先度の高い項目となっている一方、このカテゴリーにはもう一つ、Official MCP Server for MySQLというプロジェクトがあります。
これにより、さまざまなLLMベースのアシスタントやコーディングエージェントが、標準的な方法でMySQLにアクセスして情報を取得できるようになります。最初のバージョンは「read-only」で、オブザーバビリティのためのメトリクス公開に加え、AIエージェントがスキーマを検出し、データをクエリできるようにすることに重点を置きます。
Performance and Observability
パフォーマンス改善は、MySQLユーザーコミュニティで常に高い関心を集めるテーマです。Contributor Summitをはじめとするイベントや個別のミーティングで多くの皆さんとお話しする中でも、さまざまなパフォーマンス改善が主要な話題になることがよくあります。
現在GitHubのバックログには、InnoDB B+TreeのパフォーマンスからReplicationまで、MySQL Serverのさまざまなサブコンポーネントに対するパフォーマンス改善案が寄せられています。その中から、特に興味深いテーマをいくつか紹介します。
元セールスエンジニアとして、AWSからの提案でパフォーマンス上の問題を、「実際の問題」と「認識上の問題」に分けているのは興味深いところです。「実際の問題」とは本番環境で実際に発生して問題を引き起こすもの、「認識上の問題」とは本番環境ではそれほど大きな問題ではないものの、ベンチマークではデータベースの性能を悪く見せてしまうものです（この場合はHammerDB）。
こう聞くと、本番環境を遅くする問題を優先すべきだという提案だと思うかもしれません。しかしポイントはそこではありません。ユーザーはベンチマークを使ってデータベースを評価します。少なくとも、誰かが実施したベンチマーク結果を目にします。そのため、「認識上」の問題も非常に現実的な問題になります。それが原因でユーザーが別のデータベースを選択すれば、そもそもMySQLを本番環境で使ってもらえなくなるからです。
では、HammerDBの結果を一気に2倍、さらには4倍改善する可能性があるものとは何でしょうか。それが RETURNING句 です。より具体的には、DELETEとUPDATEへの拡張です。DMLコマンドにRETURNING句を追加すると、呼び出し元へ値を返す列を選択できるようになります。実際には、1つのUPDATEまたはDELETE文の中で結果を取得できるため、別途SELECTを実行する必要がなくなります。つまり、何度も往復する代わりに、1回のラウンドトリップで済むようになります。
#24 InnoDB-based binary log では、ReadySetのVinicius Grippa氏が、binary log全体をInnoDB内部へ移す提案を行いました。この変更の主な狙いは、一般的なMySQLトランザクションにおいて、テーブルとbinlogの両方をInnoDB内部で管理することで、2つの別々のサブシステム間でXAトランザクションを調整する必要をなくすことです。特に、それぞれのサブシステムが個別にディスクへ fsync する必要をなくせる点が重要です。このチケットは特に活発に議論されているものの一つで、Oracle、Google、Alibabaのエンジニアがさまざまなアプローチについて議論しています。
Hypergraph Optimizerにも引き続き多くの注目が集まっています。EXPLAIN出力の改善をはじめ、オブザーバビリティに関するさまざまな改善が進められています。最終的な目標は、考え得るすべてのユースケースにおいて、このオプティマイザを従来のMySQLオプティマイザより確実に高速にすることです。
Issue #34では、システムイベントも監視するサービスについて説明されています。たとえば、ディスクやメモリの使用率などです。一見すると、OSを監視できるツールはすでに多数存在するため、不要な機能に思えるかもしれません。しかし実際には、a) 本番環境でデータベースを診断する際、普段使っているツールがサーバーにインストールされておらず、簡単に追加することもできない場合がある、b) データベースのパフォーマンスメトリクスと同じ経路でシステムレベルのパフォーマンスメトリクスも取得できれば非常に便利、というメリットがあります。すべてのダッシュボードやパフォーマンス比較に利用できる、単一の情報源を実現できます。
Developer and DBA Experience
MySQL Workbenchに関するタスクはDeveloper and DBA Experienceカテゴリーに含まれ、Issue #10では、この広く利用されているGUIツールに必要なさまざまなアップデートが扱われています。
Issue #12では、Contributor Summitでも取り上げられた長年のテーマを扱っています。MySQLでは、BOOL と BOOLEAN は実際には TINYINT(1) の別名にすぎません。また、ARRAY と UUID をネイティブデータ型として追加することも提案されています。
この議論には、ある種のジレンマがあります。一般的には、新しいデータ型はComponentとして開発することを推奨しているからです。しかし、BooleanやArrayのような非常に基本的な型については、常に利用できるべきであり、ネイティブのデータ型として含めるべきだという考え方もあります。
このカテゴリーでもう一つ非常に興味深い機能が、System-versioned tables をMySQLに追加するという提案です。これはテーブルの特定時点のスナップショットを定義し、過去の時点のテーブルをクエリできるようにするものです。SQL:2011標準に定義された仕様に基づいて実装することが提案されています。
Extensibility and Tooling
適切に設計されたモジュール型アーキテクチャは、あらゆるソフトウェアプロジェクトにとって重要ですが、広く利用されるオープンソースプロジェクトではなおさら重要です。MySQLコンポーネント・フレームワークにより、コントリビューターは新しいデータ型や関数、さらにはストレージエンジン全体まで、比較的独立した形で作成できます。MySQLをオープンソースプロジェクトとしてスケールさせていくためには、MySQLコンポーネント・フレームワークを今後も進化させていく必要があります。
MySQL はもともとモジュール型だった
30年にわたる歴史の中で、MySQLは新しい機能をモジュール方式で開発できる複数のフレームワークを導入してきました。その中でも最も有名なのが、プラガブルストレージエンジン の概念です。これにより、さまざまなデータベースエンジンの開発者は、MySQLが提供する標準的なSQLユーザーインターフェースと機能を活用できるようになりました。一方、MySQLとそのユーザーは、使い慣れたユーザーエクスペリエンスの中で豊富なデータベースエンジンを利用し、用途ごとに最適なものを選択できるというメリットを得ました。
もう一つ、長年利用されている拡張フレームワークがユーザー定義関数を追加するためのAPIです。UDFにより、ユーザーやオープンソースのコントリビューターは、デフォルトの組み込み関数セットにスカラー関数や集約関数を追加できます。
MySQL 5.1ではプラグインAPIが導入され、MySQL Server本体とは別に機能を配布・インストールできるようになりました。
MySQLコンポーネント・フレームワーク
そして MySQL 8.0 以降、MySQLコンポーネント・フレームワークが導入されました。それ以降、各メジャーバージョンで、コンポーネントによって拡張できるMySQL Serverのさまざまな機能にAPIが追加されています。たとえば、パスワード検証、ロギング、監査のさまざまな仕組みがコンポーネントとして実装されています。
コンポーネントがもたらす最大の改善点は、明確に定義され、適用されるAPIです。
たとえばストレージエンジンAPIは、ストレージエンジンが実装・提供すべきものが定義されているという意味では明確です。しかし、ストレージエンジンプラグイン やUDF プラグイン は、mysql-serverの他の部分と同じアドレス空間にロードされて動作します。原理上、プラグインが任意の関数を呼び出したり、任意のデータへアクセスしたりすることを妨げるものはありません。
一方、コンポーネントはAPIを介して動作し、クライアントコンポーネントはそのAPIを通じて公開されているメソッドのみを利用できます。もちろん、こうしたAPI（サービス と呼ばれます）は数百種類存在するため、コンポーネントは必要に応じて複数のAPIを呼び出すことができます。
MySQLコンポーネント・フレームワークをさらに強化
Contributor Summit以降、MySQL Serverコアを拡張する仕組みとして、MySQLコンポーネント・フレームワークをさらに強化することに重点を置いています。MySQL Serverには、まだMCF APIを通じて利用できない領域があります。その大きな一つがクエリオプティマイザ（#22）です。
しかし、これまでコントリビューターが特に力を入れてきたのは、より基本的かつ根本的でありながら、非常に広範囲に影響する機能、User Defined Types（#674）です。
ここでの目標は、単にエンドユーザーがユースケースに合わせたカスタム型を定義できるようにすることではありません。APIを十分に完全かつ実用的なものにすることで、組み込み（「ネイティブ」）データ型でさえ、機能を損なうことなくコンポーネントとして実装できるようにすることです。
たとえばVectorデータ型がその例として挙げられています。Vector対応の開発では、非常に重要で要望の多い機能であるため、現在はネイティブまたは組み込み型として実装されています。しかし、本来これは二者択一である必要はありません。将来的には、MySQLコンポーネント・フレームワークを介してデータ型を追加しても、不利益が生じないようにすることを目指しています。
MySQL の拡張性に関するビジョン
現在の作業は主に MySQLコンポーネント・フレームワークがカバーできる「範囲」を広げることに重点を置いていますが、今後数年間に構築すべきものの全体像から見れば、これはまだ一部にすぎないことも認識しています。
MySQLコンポーネント・フレームワークの真の力は、優れたモジュール型ソフトウェアアーキテクチャを実践する健全な方法というだけではありません。本当の目標は、新しいコードや機能の大部分をMySQL Serverコアそのものにコントリビュートしなくても、MySQL Serverに貢献できるようなモデルを実現することです。
将来的に、一般的なMySQLへの「コントリビューション」は次のようになることを目指しています。
- Oracleの従業員と調整したり「許可」を得たりする必要なく、独立して作成・開発できる
- （さらに言えば）2人のコントリビューターが同じ機能を少し異なる方法でそれぞれ実装し、どちらを使うかをユーザーが選択できてもまったく問題ない
- 拡張機能が、どのコンポーネントAPIを使用するのか、どのAPIを実装するのか、どのバージョンと互換性があるのかを明確に宣言できる
- あるコンポーネントが別のコンポーネントを必要としていること、つまり依存関係を表現する仕組みも、おそらく必要になる
- 最終的には、独立したサードパーティ開発者がMySQLの拡張機能を公開し、エンドユーザーがMySQL本体をインストールするのとほぼ同じくらい簡単に、その拡張機能を見つけてインストールできるようにする
その方向性を示す良い例が、Alkin Tezuysal氏によるMyVectorです。Alkin氏は、MySQLコンポーネント・フレームワークを使用してMySQLにHNSWベースのベクトルインデックスを実装した経験について講演しています。
ユーティリティも拡張機能
しかし、それだけではありません。MySQL Serverは、MySQL Server本体とは完全に独立したソフトウェアによっても拡張できます。その例が、さまざまな *SQL Proxy 製品です。これらはスレッドプールから暗号化まで、多くの強力な機能を提供してきました。
オブザーバビリティ、スキーマ設計、クエリ、レポーティング、ダッシュボードなどのためのツール、さまざまなshellやclientなど、これらもすべて、MySQLエコシステムを拡張し、価値を加える「コンポーネント」と捉えることができます。
そしてストレージエンジンも！
拡張性の開発ではMySQLコンポーネント・フレームワークの拡張に多くの重点が置かれていますが、MySQLにはすでに、何十年にもわたって多くの優れたデータベースイノベーションを生み出してきた、実績あるフレームワークがあります。それが ストレージエンジンAPI です。
MySQLの開発をコミュニティコントリビューションに開放していく中で、新しいストレージエンジンを追加する提案がなければ完全とは言えないでしょう。そしてここ数週間で、1つではなく2つの非常に強力で最先端のエンジンがロードマップのダッシュボードに追加されたことを、とてもうれしく思っています。
DuckDB（Alibabaによる提案）は、analytics / OLAP市場で急速に注目を集めているデータベースです。そしてTidesDBは、新しい最先端のLSMエンジンです。LSMアーキテクチャは一般的に、書き込み最適化されたMVCC型のOLTPワークロードで使用されます。
どちらも次回のContributor Summitで発表される予定です。
今後のContributor Summits
ここまで読んで、筆者と同じくらい期待を感じているなら、こう思われるかもしれません。「Contributor Summit はいつ、どこで開催されるのか？ チケットはどこで購入できるのか？」
答えは、参加には招待のリクエストが必要ということです。参加を希望する場合はCommunity Teamにお問い合わせください。これらのイベントは、すでに新しいMySQL機能に取り組んでいる開発者、あるいは提案を行い、その内容を発表してフィードバックを得ようとしている開発者のためのイベントです。
次回のSummitは間もなく開催されます。
- 8月5-6日、コロラド および オンライン
- 11月は 100% オンラインで開催
- 2月は ヨーロッパで、FOSDEM と MySQL Belgium Days に合わせて開催予定
- その後は、おそらく5月に開催予定、開催地は未定
MySQLへのコントリビューションに取り組んでいる、または提案を予定しており、Contributor Summitで発表または参加したい場合は、HENRIK.INGO@ORACLE.COM または LENKA.KASPAROVA@ORACLE.COM までメールでお問い合わせください。
参加してみよう
とにかくIssues やプルリクエストを提出し始めたいという方も、もちろん大歓迎です。事前にスライドを作って発表しなければならない、といった厳格な要件はありません。
mysql/mysql-community リポジトリでプロポーザル(提案)を作成できます。そして最初のプルリクエスト を送る準備ができたら、通常は mysql/mysql-server リポジトリ のブランチに対して送ることになります。
また、開発をオープンにしていく中で展開しやすくするために、4つの戦略的なロードマップカテゴリーを設定しています。プロポーザルを提出する際には、ご自身のコントリビューションがどのカテゴリーに最も近いかを意識してみてください。
- AI and Cloud (AIとクラウド)
- Performance and Observability (性能と可観測性)
- Dev and DBA Experience (開発/運用性の向上)
- Extensibility and Tooling (拡張性とツール拡充)
今後のブログ記事では、これら4つのカテゴリー をさらに掘り下げ、各チケットのディスカッションを追いかける際に役立つ技術的背景や内容をお伝えしていきます。進行中のMySQL開発における次のエピソードにもご期待ください。