※このブログは2022年5月12日に公開された英語ブログ「Long Live MySQL: Good Old MySQL Should Be Rejuvenated」の拙訳です。
このブログはシリーズの前編です。後編は「Long Live MySQL：エコシステムの革新者たちに賞賛を」からご覧いただけます。このブログは、PingCAPの共同創業者兼CTOのEd Huangによって執筆されています。
あなたがアプリケーション開発者だと想像してみてください。上司から1週間以内に新しいアプリケーションのプロトタイプを作るように言われたとします。あなたはデータベースで何を選びますか？おそらくMySQLでしょう。
MySQLはユビキタス
多くのエンジニアがMySQLを愛用しています。データベース情報サイトのDB-Enginesによると、MySQLは2番目に人気のあるデータベースですが、SQLiteやIBM Db2など、人気が下がっているデータベースもあります。
Stack Overflowが実施した2021開発者アンケートの73,317件の回答より、最も人気のあるデータベースとしてMySQLが選ばれました。
Stack Overflowの 2021年開発者アンケートによるデータベース人気ランキング
採用に関しても、MySQLは人気があります。Indeedで上位に使われるデータベースをキーワードに求人を検索してみたところ、”mysql”で31,245件の求人がヒットしました。「mysql」のスキルセットを必要とする求人は、データベースの中で2番目に多いです。
MySQLは広く使われています。実際にPingCAPでは、MySQLは多くのエンジニアがPingCAP入社する前に使い方を知っていた数少ないデータベースの1つでした。私もその1人です。
MySQLと歩んだ20年
私が初めてMySQLを使ったのは、2003年の高校生の時でした。当時は、プログラミングコンテストを趣味でやっている人たちのために、PHPでWebアプリケーション (Online Judge) を開発し、彼らが書いたコードを実行し、それが正しいかどうかをチェックする手助けをしたかったのです。ユーザーが提出したデータを保存するために、データベースが必要でした。MySQL は、非常にシンプルで使いやすかったため、私のベストチョイスでした。MySQLクライアントを使ってSQLを書き、PHPで直接データベースを操作し、Apacheで動的なページの結果をレンダリングすることができました。
2012年、私はMySQLをインフラとするスタートアップ企業に入社しました。私は数少ないインフラエンジニアの1人でした。会社のビジネスは急成長し、そのデータ量は1台のMySQLサーバー容量をすぐに超えてしまいました。そこで、私は解決策を模索し始めたのです。例えば、MySQLのbinlogを使ってプライマリ層とセカンダリ層に分割して可用性を高めたり、水平シャーディングを適用したりしました。私がその会社を辞めたとき、そのデータベースクラスタは30以上のシャードを持ち、数十テラバイトを管理することができました。私にとって、これらの課題を解決できたことは、非常に有意義な経験でした。
こうしたMySQLにまつわる経験があったからこそ、MySQLに携わった同じような思い出のある多くの優秀なエンジニアと出会う機会に恵まれました。2015年、私が独立し、全く新しいデータベースを構築することを決意したとき、最初に頭に浮かんだエコシステムがMySQLでした。
多くの人がMySQLを愛用する理由
MySQLの初期バージョンは現在ほど高度なものでは無かったものの、その人気は疑う余地がありません。その人気の秘密は、MySQLがシンプルで使いやすいからです。Binlogのような多くのユーザーフレンドリーな機能も早くからMySQLに導入されました。その結果、その後の30年間でMySQLのユーザー数は劇的に増加しました。さらに、多くのユーザーがMySQLの使用方法に関するフィードバックを提供したり、MySQLに直接貢献したことで、MySQLのエコシステムがより繁栄しました。全盛期には、MySQLは多くのビジネスにとって当然の選択肢となりました。その理由は以下の通りです：
- 多くのエンジニアが利用しており、データベース企業にとって大きな人材プールとなっている。
- オープンソースであるため、入手や利用が容易である。
- インターネット上で、ほとんどすべてのMySQLに関する質問の答えを見つけることができる。
- MySQLには活気のあるエコシステムがある。WordPressやphpMyAdminなどの多数のオープンソースプロジェクトがMySQLに大きく依存し、MySQLをさらに普及させた。
時代の変化
この20年間、世界は急速に変化し、モバイルインターネットの爆発的な普及や今日のデジタルトランスフォーメーションなど、私たちは多くの大きな技術革新を目の当たりにしてきました。私たちのアプリケーションのシナリオも、非常に大きな変化を遂げています。これらの変化はどのようなものなのでしょうか？データの観点から探ってみましょう。
データ量は飛躍的に増加し、分散技術はほとんどすべての最新のデータベースにとって必須となりました。NoSQLデータベースは、分散アーキテクチャの構築に非常に適しており、一貫した使用方法を維持しながら透過的なスケーラビリティを提供するため、開発者はアプリケーションの変更を心配することなくスケールインとスケールアウトを行うことができます。しかし、NoSQLデータベースは、SQLデータベースよりもさらに限定された機能セットをユーザーに提供します。Web 2.0の初期には、データ量は増えてもビジネスモデルが比較的単純だったため、この点は大きな問題にはなりませんでした。例えば、Twitterが挙げられます。初期のバージョンでは、140文字という制限の中で膨大な共有メモサービスを提供していたに過ぎません。
企業が複雑なアプリケーションを構築する場合、特に強力な一貫性とJOINやGROUP BYのような複雑な関連性分析を必要とする場合、SQLは依然として最良の選択肢だと言えます。残念ながら、MySQLやPostgreSQLなど従来のリレーショナルデータベースは、分散技術を採用しながらも、長い間ほとんど革新的な技術を開発することができませんでした。そのため、分散要件に対応する主流なソリューションはシャーディングだけだったのです。しかし最近では、本当の分散型SQLデータベースと呼べるような新しいデータベースプロジェクトがいくつか見られるようになりました。
データモデルは最初は複雑なものからシンプルなものへと変化し、その後さらに複雑なものになっていきました。モバイルインターネットの爆発的な普及のようなテクノロジーの大きな変化に伴って、このような進化を遂げました。当時主流だったNoSQLやシャード型データベースによって、データモデリングは限られた機能の中で行われました。しばらくの間、データアプリケーションのモデリングは、キーと値のペア、ドキュメント、その他の柔軟でシンプルなモデルに簡略化する必要がありました。
しかし、比較的簡単な問題を解決すると、本当に難しい問題はより厄介になります。金融サービスやeコマースなど、オンラインビジネスを加速させるためにデジタル変革を始める業界が増えるにつれ、データベースの適用シーンはより複雑になってきています。そのため、リレーショナルモデルとSQLの組み合わせは、ほぼ常に私たちのベストなデータベースソリューションとなっています。この10年、GraphQLのような新しいDSL (domain-specific language) を使ってデータをモデル化する試みが数多く行われましたが、いずれもリレーショナルモデルとSQLの組み合わせの支配的な地位を揺るがすものではないと私は考えています。Googleは研究論文「F1: A Distributed SQL Database That Scales (スケーラブルな分散型SQLデータベース)」で、この状況を以下のように簡潔に説明しています。
「AdWordsに対応するGoogleのMySQLデータストアの代わりを探したとき、そのオプションは単に実現不可能でした。ビジネスロジックのあらゆる部分で非ACIDデータストアを扱うことの複雑さはあまりにも大きく、SQLクエリなしでビジネスが機能することは単にあり得ませんでした。」
より強力な一貫性とリアルタイムのトランザクション処理および分析への要求が高まっています。初期の頃、MySQLのデフォルトのストレージエンジンはMyISAMでしたが、最終的にはInnoDBにその座を明け渡しました。大きな違いの1つは、InnoDBがより強力な一貫性のあるトランザクションをサポートしていることだと思います。データベース層が一貫したセマンティクスを提供すればするほど、アプリケーション層が負担しなければならない複雑さは軽減されます。これは、フェイルオーバーを扱う場合に特に言えることです。データベースが強力な一貫性をサポートしていない場合、ディザスタリカバリを実行する際にデータの整合性を保証することは困難です。これは、ほとんどの金融シナリオで受け入れられません。
この10年間で、データベース管理技術には数多くの革新がありました。しかし、明らかなトレードオフとして、オンライントランザクション処理 (OLTP) とオンライン分析処理 (OLAP) の分離が挙げられます。Apache Kafka、Apache Storm、Apache Sparkなどのストリーミング技術が登場し、いわゆる「ラムダ・アーキテクチャ」を形成して、2つのシステムを統合し、抽出、変換、ロード (ETL) のレイテンシを排除しています。このアプローチは多くの場面で有効ですが、導入されたアーキテクチャの複雑さには手こずったものでした。また、この複雑な技術スタックでは、データの一貫性を保つことも困難です。このため、分単位、さらにはミリ秒単位でのリアルタイムの洞察を必要とする多くの企業にとって、大きな課題となっています。技術的な障壁により、企業はビジネスニーズを優先できず、より従来の、しかし扱いやすいソリューションに目を向けなければならないかもしれません。近年、データ量とリアルタイム分析の要求が高まるにつれ、OLTPとOLAPは統合の道を歩んでいます。
データの生成と利用の方法は、多面的になってきています。かつては、データベースへの書き込みは、クライアントがSQL文を使ってDBに直接接続するというシンプルなものでした。ところが現在、データがどのようにDBに入るかを詳しく見てみると、その上流はもっと多様化していて、メッセージ・キューであったり、ETLジョブからのバッチ書き込みであったりすることが分かります。バッチ処理の課題として、ユーザーは通常ACID分離の要件が満たされているかどうかよりも、スループット性能の方を重視することが挙げられます。このようなシナリオでは、ロックのような従来のトランザクションメカニズムは不要になります。一方、リアルタイム要件が飛躍的に高まったことで、データ変更を下流のメッセージ・キューに同期して利用する必要性が生じています。最近のデータベースでは、Change Data Capture (CDC) の実装が主流になってきています。例えば、MySQLにはBinlog、OracleにはGoldenGate、PostgreSQLにはPostgreSQLレプリケーションがあります。
データ品質への要求はますます高まり、観測可能な範囲は実行パネルからデータパネルに広がっています。20年前は、QPS (Queries per Second) 、TPS (Transactions per Second) 、レイテンシ、クエリプランレベルといった単純なデータベースシステムメトリクスに焦点が当てられていました。しかし、データ量の激増と分散型データベースの出現により、私たちは基本的なシステム情報に満足することなく、データがどのようにアクセスされているかを調べ、そこからビジネス上の洞察を得たいと思うようになりました。例えば、TiDBのKeyVisualizerを例にとってみましょう。データアクセスの分布をリアルタイムに反映し、どのデータがよくアクセスされ、どのような特徴を持っているのかが一目でわかるようになっています。
TiDBのKeyVisualizer
しかし、これらの観測可能性の次元は、まだデータベースシステム自体に限定されたものです。最近、新しいトレンドとして、データの品質を測ろうとする「データ観測性」が出てきています。Anomaloはその良い例で、データベース製品にとって非常に有望な方向を示していると思います。
また、ハードウェアのインフラが大きく変化しています。クラウドの普及に伴い、マネージドサービスが主流になりつつあります。MySQLがリリースされた当時は、SSDも20GのNICもありませんでした。ハードウェアの進歩により、多くの問題が解消されました。例えば、B+Treeは従来のハードディスクの読み書きの遅さ問題を解決しましたが、最新のNVMe SSDではこれは問題にはならないのです。最新のクラウド環境が広く採用されるようになり、AWS EBSのようなクラウド上の共有ストレージソリューションは、ローカルディスクと同等かそれ以上のパフォーマンスを発揮するようになりました。これは、データベースのストレージエンジンの設計を大きく変えることになるでしょう。一方、データベースベンダーやクラウドプロバイダーは、クラウド上でフルマネージドな体験を提供できるため、ユーザーは運用や保守を気にすることなく、ビジネス展開に集中することが可能になります。これは、クラウド上でデータベースサービスを提供するベンダーにとっても、リーズナブルなビジネスモデルだと言えます。
古き良きMySQLもう時代遅れ？
テクノロジーの世界で起きているこれらすべての変化を目の当たりにして、私は「MySQL は時代遅れなのか」と考えずにはいられませんでした。データベースカーネルの開発者として、OracleからMySQLへの貢献が減少していることを、より強く懸念しています。
Oracleの内部で何が起こっているのかはわかりませんが、彼らからコミュニティに対して説明があれば素晴らしいことだと思います。
それでも、私はMySQLとそのエコシステムが大好きです。MySQLのエコシステムがなくなることはないでしょう。MySQLのアプリケーションとデベロッパーは、今でもデータベース市場の基盤となっています。しかし、よりモダンなMySQLが必要なのでしょうか？もちろん、そうです。次回は、最新のMySQLエコシステムの主要プレイヤーを紹介します。お楽しみに。
This post is the first part in our series. You can see the second part here: Long Live MySQL: Kudos to the Ecosystem Innovators.
TiDB Cloud Dedicated
TiDB Cloudのエンタープライズ版。
専用VPC上に構築された専有DBaaSでAWSとGoogle Cloudで利用可能。
TiDB Cloud Serverless
TiDB Cloudのライト版。
TiDBの機能をフルマネージド環境で使用でき無料かつお客様の裁量で利用開始。