Long Live MySQL：エコシステムの革新者たちに賞賛を

※このブログは2022年05月12日に公開された英語ブログ「Long Live MySQL: Kudos to the Ecosystem Innovators」の拙訳です。

Author: Ed Huang (Co-Founder & CTO at PingCAP)

この投稿はシリーズの後編です。前編である「Long Live MySQLー古き良きMySQLが見直されるべき理由」は、こちらでご覧いただけます。前編に引き続き、このブログはPingCAPの共同創業者兼CTOのEd Huangによって執筆されています。

私は、MySQLとそのエコシステムを強く支持しています。前回の記事で述べたように、MySQLのエコシステムは、この分野における多くのイノベーションによって今もなお繁栄しており、MySQLのアプリケーションやデベロッパーは、データベース市場の主役の1つであり続けています。問題は、よりモダンなMySQLが必要なのでしょうか？もちろん、そうです。

本稿では、よりモダンな MySQLエコシステムの主要プレイヤーを紹介することで、MySQLの堅牢性と進化について解説します。

MySQLのフォーク：MariaDBとPerconaを例として

MariaDB

MySQLの代替品といえば、オープンソースコミュニティによって推進されているエンタープライズMySQLのフォークであるMariaDBを抜きにしては語れないでしょう。オープンソースの要素はさておき、MariaDBは技術としても製品としても多くのものを提供しています。

データ量の増加に対応するため、MariaDBはMaxScaleを提供しています。これは、クエリのルーティング、読み書き分離、MySQL Binlogに基づく自動フェイルオーバーをサポートするシンプルなプロキシのようなコンポーネントです。MaxScaleを使ったスケーリングは、水平方向よりも垂直方向にデータをシャーディングすることが重要です。ユーザーのアプリケーションが大きなテーブルを扱う場合、水平方向のシャーディングのワークロードの分割をアプリケーション層で完了させる必要がありますが、これはアプリケーションに支障を来します。

現代のワークロードにおいて、リアルタイム分析とオンライントランザクションの境界が曖昧になるにつれ、MariaDBはオンライン分析処理（OLAP）のクエリを高速化するためにColumnStoreを導入しました。ColumnStoreはダイレクトリードとライトに対応しており、MySQLの新しいストレージエンジンとして導入されました。しかし、現時点ではColumnStoreのテーブルを、MySQLのデフォルトストレージエンジンであるInnoDBのテーブルと相互変換する方法はありません。私が考えるに、書き込み用の列指向のストレージの性能は、スループットとレイテンシの両方において、行指向のストレージのそれとは異なっています。ユーザーは、どのワークロードがColumnStore上で実行するのに適しているかを明確に知る必要があります。Hybrid Transactional and Analytical Processing（HTAP）を実現するためには、ColumnStoreをMaxScaleとともに使用して、オンライントランザクション処理（OLTP）およびOLAPリクエストをMaxScaleレイヤーで対応するテーブルまたはデータベースにルーティングする必要があります。ユーザーがスキーマを設計する際には、これらの要件を考慮する必要があります。MariaDBに限らず、多くの次世代データベース企業は、OLTPとOLAPの両方のワークロードを処理するこのトレンドに注目しています。

Percona

Perconaは、MySQLエコシステムの重要な長期的サポータであり、MySQLの運用およびメンテナンスのエキスパートとして知られています。Perconaは、pt-online-schema-changeや pt-query-digestなど、MySQLコミュニティに多数の評判の良いツールを提供しています。Perconaのビジネスモデルは、これらのツールをMySQLとパッケージ化し、MySQLカーネルをベースに他の実用的な機能を導入し、商用サポート付きのコミュニティ・ディストリビューションとしてリリースすることです。

Percona Server for MySQLとMySQLの違いは、Perconaの公式サイトを見れば一目瞭然です。ここでは、私が興味深いと思ったところを2点ほど取り上げます。

• 一点目はMyRocksです。MyRocksは、埋め込み型の持続的キーバリューストアであるRocksDBをベースにしたMySQLストレージエンジンです。Percona MyRocksは、Percona Server for MySQLを実装しています。RocksDBは、Log structured merge（LSM）ツリーの実装です。B-treeと比較して、LSM-treeはより最新のハードウェアに対応したデータ構造を持ち、圧縮率が高く、実装が簡単です。さらに、LSM-Treeは階層型ストレージの考え方で作られています。クラウドネイティブのストレージエンジンを実装し、クラウド上のさまざまなストレージメディアをフル活用したいのであれば、階層型ストレージは理想的な設計と言えるでしょう。MyRocksは、最新のハードウェアやクラウドインフラに対応したMySQLに最適な製品だと言えます。
• 二点目は、XtraDB Clusterです。Perconaは、ProxySQLをルーティングレイヤーとして統合し、さらにGaleraを使用して分散アーキテクチャにおけるストレージノードの高可用性を実現しました。しかし、MariaDBと同様にXtraDB Clusterに最も適したシナリオは、テーブルとデータベースの垂直シャーディング、読み書き分離、ノードレベルの自動フェイルオーバーです。XtraDB Clusterは水平スケーリングをサポートする分散データベースではありません。

Perconaは、かなり長い間ClickHouseコミュニティをサポートしてきました。ある意味、このサポートがMySQLのリアルタイム分析機能を補っているとも言えます。デジタルトランスフォーメーション時代にビジネスがよりリアルタイムになるにつれ、大勢のMySQLユーザーグループは、MySQLエコシステムがリアルタイム分析機能を提供できることを望んでいます。

MySQLの上位ミドルウェア：Vitessを例として

MariaDBとPercona Serverは、膨大なデータという課題に直面したとき、垂直シャーディングとプロキシによる読み書き分離を選択します。しかし、大きな単一テーブルの場合、水平シャーディングの方がアプリケーションへの干渉が少なく、より良い選択肢となります。アプリケーションはシャーディングキーを指定するだけで、後はルーティングレイヤーがどのシャードを保存すべきかを決定します。ルーティング層はアプリケーションに対して透過的なものです。このプロキシ設計の一例として、MySQLを高速でスケーラブル、かつ可用性の高い分散データベースに変えるSQLミドルウェアであるVitessがあります。Vitessは、YouTubeで広く利用された後にオープンソース化され、MySQLシャーディングの主流のソリューションとなりました。しかし、その限界も明らかになっています。例えば、シャーディングプロキシはデータベースではなく、リクエストのルーティングレイヤーです。つまり、Vitessは複雑なクエリをサポートしておらず、これはシャード間に分散したトランザクションにとって厄介な問題です。フェイルオーバーとサービスレベルは、基盤となるMySQLのメカニズムに大きく依存しています。もちろん、既存のMySQLの運用・保守の経験はそのまま活かせます。

HTAPの初代プラクティショナー：SingleStoreを例として

SingleStoreの前身は、MemSQLです。初期の位置づけは、MPP（超並列処理）をサポートする分散型OLAPデータベースで、オールインメモリの設計でした。その後、このソリューションにディスクストレージのサポートが追加され、SingleStoreと改名されました。SingleStoreはOLTPワークロードのためのロウベースのストレージ形式をサポートしています。しかし、デフォルトのストレージエンジンはColumnstoreであり、これはOLAPワークロードに重点を置いていることを示します。SingleStoreは同じデータベースで両方のワークロードを扱うことができるため、HTAPデータベースに分類されます。その後、MySQLエコシステムの多くのデータベースでOLAP機能が強化されています。

SingleStoreアーキテクチャには、アグリゲーターノードとリーフノードの2種類のノードがあります。リーフノードにはテーブルデータのシャードが格納されます。一部のSQL演算子はリーフノードにプッシュダウンされ、演算を高速化します。SingleStoreはまた、実行プランをマシンコードにコンパイルし、ローカルにキャッシュして再利用する、codegen技術を利用する数少ないOLAPデータベースの1つです。ClickHouseやMonetDBなど他のOLAPデータベースでは、CPUキャッシュを有効活用することで高速な分析クエリエンジンを開発するためにベクトル化を導入しています。

SingleStoreはMySQLのプロトコルと互換性があるため、導入しやすく、コスト面でも優れています。総じて、市場や成長戦略が優れていると思います。

パブリッククラウド上のRDS：Amazon Auroraを例として 

Amazon Auroraは、データベースの重要な革新です。Auroraは、Spannerのようなシェアードナッシングアーキテクチャを採用していません。その代わり、スタンドアロンRDBMSをベースに最適化されているのが特徴です。Auroraは、クラウド上のロングテールユーザーの次のような特徴を敏感にとらえました。

• 弾力性に対する期待は高く、スケーラブルなストレージ容量に対する要求は比較的低い 
• データの書き込みよりも読み出しに対するスケーラビリティの要求が高い 
• MySQLと100%互換性があるため、主にRDBMSのユーザーが多い 

また、Auroraはクラウドインフラの機能をスマートに活用しています。共有ストレージのスループットは、基本的にローカルディスクと同じです。データベースの共有ストレージは、コンピューティングノードがステートレスになることで、コンピューティングとストレージの分離を実現することを意味します。これは、コンピューティングとストレージのハードウェア要件が異なるからこそ可能なのです。例えば、読み取り要求をスケールさせるために、Auroraは読み取りレプリカの新しいコンピューティングノードを追加するだけです。このプロセスでは、キャッシュのウォームアップ時間を除けば、データ移行の手間はあまりかかりません。これは、サーバーレス実装の重要な前提条件でもあります。

また、Auroraの共有ストレージは、単に分散ファイルシステム上でInnoDBを動作させるという意味ではありません。”ログこそデータベースである”という設計思想を表しています。実際、Redoログが確保されている限り、データは確保されています。ストレージはRedoログのレコードを利用して、オンデマンドでページイメージを構築します。従来のBinlogレプリケーションと比較して、ログのシリアライズ、ネットワーク伝送の負荷、Binlog適用による書き込みの増幅を低減しました。これにより、スタンドアロンデータベースと比較した場合、書き込み性能が大幅に向上しています。クラウドプロバイダーであるAWSは、Auroraのための包括的なクラウドホスティングサービスを提供しています。

Auroraの課題は、基本的にスタンドアロンなデータベースであることです。最新の設計であっても、Auroraが大量のデータや書き込みのスケーラビリティの問題に直面した場合、VitessのようなシャーディングミドルウェアやTiDBのような分散SQLデータベースで補完する必要があるかもしれません。また、Auroraはリードレプリカで一部のタイプの計算を行うためのパラレルスキャンをサポートしているものの、その主な対象は依然として従来のOLTPワークロードのようです。

次世代分散型SQL：TiDBを例として

TiDBは、近年活躍している次世代分散型SQLデータベースの1つです。当初はGoogle SpannerやF1にインスパイアされたものでした。現在、コミュニティではいくつかの分散SQLプロジェクトが活発に活動しています。CockroachDB（CRDB）、YugabytesDB、そしてTiDBです。CRDBとYugabytesDBは、PostgreSQLと互換性がありますが、3つのうちTiDBは、MySQLと互換性がある唯一のプロジェクトです。

TiDBは、MySQLのコードのフォークを変更したものではありません。その代わり、よりモダンな設計でゼロから開発されました。TiDBは、典型的なシェアードナッシングデザインを採用しており、これによって弾力的なスケーラビリティが保証されています。TiDBのアーキテクチャは2層構造になっており、一番上はステートレスSQL層で、接続管理、SQLの解析と最適化、分散実行プランの生成などを担当します。一番下の層は、分散Key-Valueストレージ層であるTiKVです。TiKVはACIDトランザクションをサポートし、データを保存します。SQL層は、テーブル、ロウ、インデックスといったリレーショナルモデルのデータをKey-Valueペアに変換し、TiKVに格納します。この設計のメリットは、リレーショナルモデルよりもKey-Valueモデルの方が弾力的な分散を実現しやすいことです。なぜなら、リレーショナルモデルでは、テーブルがあり、データベースがあり、1行あたりのカラム数が多く、数え切れないほどの種類のシャーディング戦略が存在するため、概念が多すぎるからです。しかし、Key-Valueモデルでは、キーの範囲（またはキーのハッシュ）に従うことは明らかです。詳しくはブログ記事「Raftをベースにした大規模分散ストレージの構築」で説明しました。TiDBでは、最新のコンセンサスアルゴリズムであるRaftを採用し、分散アーキテクチャ上での高可用性と水平スケーラビリティを実現しています。また、SQL層はストレージに依存しないステートレスなので、接続層と演算層が独立してスケールするのが便利です。

SingleStoreとは異なり、初期のTiDBの位置づけはどちらかというとOLTPデータベースであり、高頻度のトランザクションを低レイテンシーかつ高同期で処理できるように設計されていました。MySQLユーザーがスケーラビリティの課題に直面したとき、シャーディングに対応し、エラスティックなスケーリングをサポートする、よりシンプルで干渉の少ない分散型データベースを探しているなら、TiDBは良い選択肢になるかもしれません。

この2年間、OLTPとOLAPの境界が曖昧になる一方で、よりシンプルなデータベースを求めるユーザが増えました。既存の分散フレームワークをベースに、TiDBを真のHTAPデータベースとするために、分散カラムナストレージエンジンであるTiFlashを実装しました。TiDBの分離設計により、SQLコンピューティング層はOLAPリクエストをTiFlash上のカラムナレプリカに転送します。ユーザーは列指向ストレージと行指向ストレージ間のデータレプリカの同期を気にする必要がなく、OLTPとOLAPのワークロードが同じアーキテクチャ内で解決されます。ここでは技術的な説明は省きますが、TiFlashの設計についてより詳しく知りたい方は、TiDBチームの論文「TiDB: A Raft-based HTAP Database」をご覧ください。

複雑な分散システムを実運用環境で維持することは、ユーザーにとって容易なことではありませんし、最新のデータベースに組み込まれている様々なツールを使えば、さらに複雑なものとなります。前述の通り、より多くのユーザーがクラウドに移行しており、マネージドサービスはこうした複雑さを遮蔽することができます。TiDBのフルマネージドサービスは、AWSや CCP上でも利用できるのが重要な違いです。

しかし、MySQLには多くのレガシーコードがあり、20年以上の歴史があり、ほとんどが非トランザクションストレージエンジンであるMyISAMを中心に設計されていました。このような特殊性は、完全な分散データベースアーキテクチャにはうまく適用されません。分散アーキテクチャの機能を完全に活用するために、TiDBのSQLオプティマイザとエグゼキュータは分散環境のコンピューティングエンジンとして設計されています。そのため、いくつかの動作はスタンドアロンMySQLのそれとは異なる場合があります。

結論

MySQLユーザーは、よりスケーラブルで革新的な分散アーキテクチャを選択することができるようになりました。MySQLのエコシステムでは革新的な技術に事欠きませんし、これらのプロジェクトの中には、技術的進歩の面でデータベース業界をリードしているものもあります。まさにエキサイティングな時代であり、未来は明るいと言えるでしょう。

Long live MySQL.

---

This post is the second part in our series. You can find the first part here: Long Live MySQL: Good Old MySQL Should Be Rejuvenated.