クラウドでのスケーリングにおけるMySQLとTiDBの5つの主な違い

※このブログは2018年12月11日に公開された英語ブログ「5 Key Differences Between MySQL and TiDB for Scaling in the Cloud」の拙訳です。

企業がクラウドネイティブのアーキテクチャを採用するにつれて、データベースを水平方向にスケーラブルにするために何ができるかという話に自然となるでしょう。その答えはおそらく、TiDBについて詳細に確認することになるでしょう。

TiDBはApache 2.0ライセンスでリリースされたオープンソースのNewSQLデータベースです。MySQLプロトコルを使用するため、既存のアプリケーションはMySQLコネクタを使用して接続することができ、ほとんどのSQL機能 (テーブル結合、サブクエリ、トランザクションなど) は同じです。

しかし、内部に一歩足を踏み入れると、違いがあります。もしあなたのアーキテクチャがリードレプリカを使ったMySQLをベースにしているのであれば、TiDBでは少し違うことがわかるでしょう。この記事では、私が見つけたTiDBとMySQLの違いのトップ5を紹介します。

1. TiDBはクエリの実行とストレージをネイティブに分散する

MySQLでは、レプリケーションによってスケールアウトするのが一般的です。通常、1つのMySQLプライマリと多数のセカンダリがあり、それぞれがデータの完全なコピーを持ちます。アプリケーションのロジックや、ProxySQLのような技術を使用して、クエリは適切なサーバにルーティングされます (安全に実行できる場合はプライマリからセカンダリにクエリをオフロードします) 。

スケールアウト・レプリケーションは、クエリの実行をレプリケーション・セカンダリ間で分割できるため、読み込みの多いワークロードでは非常にうまく機能します。しかし、書き込みの多いワークロードでは、各レプリカがデータの完全なコピーを持つ必要があるため、ボトルネックになります。別の見方をすると、MySQLレプリケーションはSQL処理をスケールアウトしますが、ストレージをスケールアウトするわけではありません。(ちなみに、これは従来のレプリケーションにも、Galera ClusterやGroup Replicationのような新しいソリューションにも当てはまります)。

TiDBの仕組みは少し異なります：

• クエリの実行は、TiDBサーバーのレイヤーを介して処理されます。SQL処理のスケールアウトは、新しいTiDBサーバーを追加することで可能で、これはKubernetes ReplicaSetsを使って非常に簡単にできます。これは、TiDBサーバーがステートレスであるためで、TiKVストレージレイヤーがすべてのデータ永続化を担っています。
• テーブルのデータは自動的に小さな塊にシャーディングされ、TiKVサーバ間で分散されます。各Region (シャードのTiKVでの名称) の3つのコピーがTiKVクラスタに保持されますが、どのTiKVサーバもデータの完全なコピーを必要としません。MySQLの用語で説明しますと：各TiKVサーバはプライマリであると同時にセカンダリでもあります。あるデータRegionに対してはプライマリコピーが格納され、他のデータRegionに対してはセカンダリコピーが格納されるからです。
• TiDBはRegionをまたがるクエリをサポートしており、MySQLではクロスシャードクエリと呼ばれることもあります。異なるRegionの位置に関するメタデータは、TiDB Clusterの管理サーバーコンポーネントであるPlacement Driverによって管理されます。すべての操作はACIDに完全に準拠しており、2つのRegionにまたがってデータを変更する操作は2フェーズコミットを使用します。

TiDBを学んでいるMySQLユーザーのために簡単に説明すると、TiDBサーバーはSQLを複数のキーバリュー型のリクエストに変換するインテリジェントなプロキシのようなものです。TiKVサーバーは、範囲ベースのパーティショニングでテーブルを保存します。範囲は各パーティションが96MB (デフォルト値、変更可能) になるように自動的にバランスをとり 、各範囲を異なるTiKVサーバーに保存できます。Placement Driverサーバーは、どの範囲がどこにあるかを追跡し、範囲が大きくなりすぎたり、ホットスポットになったりすると、自動的にバランスを調整します。

この設計には、スケールアウト・レプリケーションのいくつかの利点があります：

• SQL処理層とデータストレージ層を独立してスケールします。多くのワークロードでは、どちらかが先にボトルネックにぶつかります。
• ノードを追加することで段階的に拡張します (SQLとデータストレージの両方で) 。
• ハードウェアをより有効に活用できます。MySQLを1つのプライマリと4つのレプリカにスケールアウトするには、データのコピーを5つ持つことになります。TiDBは3つのレプリカしか使わず、ホットスポットはPlacement Driverによって自動的にリバランスされます。

2. TiDBのストレージエンジンはRocksDB

MySQLのデフォルトのストレージエンジンは、2010年以来InnoDBです。内部的には、InnoDBはB-treeデータ構造を使用しており、これは従来の商用データベースが使用しているものと似ています。

対照的に、TiDBはTiKVを搭載したストレージエンジンとしてRocksDBを使用しています。RocksDBは、より効率的にデータを圧縮でき、インデックスがメモリに収まらなくなってもインサート性能が低下しないため、大規模データセットに有利です。

MySQLもTiDBも、新しいストレージエンジンを利用できるAPIをサポートしています。例えば、Percona ServerとMariaDBはどちらもオプションとしてRocksDBをサポートしています。

3. TiDBはPrometheus/Grafanaでメトリクスを収集する

主要なメトリクスを追跡することは、データベースの健全性を維持するための重要な要素です。MySQLでは、これらの変化の速いメトリクスをパフォーマンススキーマに集約しています。パフォーマンススキーマは、通常のSQLクエリで照会できるインメモリテーブルの集まりです。

TiDBでは、サーバー内にメトリクスを保持するのではなく、戦略的な選択として、ベストオブブブリードのサービスに情報を送信しました。Prometheus+Grafanaは、現在の運用チームの間では一般的な技術スタックであり、付属のグラフを使えば、独自のグラフを作成したり、アラーム用のしきい値を設定したりすることが簡単にできます。

4. TiDBはDDLの処理が格段に優れている

MySQLのすべてのデータ定義言語 (DDL) 変更がオンラインではないことを少し無視すると、分散MySQLシステムを実行する際の大きな課題は、すべてのノードで同時にスキーマ変更を外部化することです。

10個のシャードがあり、カラムを追加する場合に、各シャードが変更を完了するのに異なる時間がかかるというシナリオを考えてみましょう。レプリカはプライマリの後にDDLを処理するので、この課題はシャーディングなしでも存在します。

5.  TiDBはHTAPワークロード用に設計されている

MySQL チームは従来、オンライントランザクション処理 (OLTP) クエリのパフォーマンス最適化に重点を置いてきました。つまり、MySQLチームは、すべてのクエリや複雑なクエリのパフォーマンスを向上させるのではなく、単純なクエリのパフォーマンスを向上させることに多くの時間を費やしてきました。多くのアプリケーションは単純なクエリしか使用しないため、このアプローチに問題はありません。

TiDBは、ハイブリッドトランザクション / 分析処理 (HTAP) クエリに対して優れたパフォーマンスを発揮するように設計されています。これは、MySQLデータベースと分析データベース間のバッチでのデータロードが不要になるため、データのリアルタイム分析を望む人にとって大きなセールスポイントとなります。

結論

以上は、MySQLの世界に15年いて、TiDBにたどり着いた私のトップ5の見解になります。これらの多くは内部的な違いについて言及していますが、MySQLの互換性に関するTiDBのドキュメントをぜひチェックしてしてみてください。このドキュメントには、アプリケーションに影響を与える可能性のある違いについて、より細かい点が記載されています。

注：この記事の原文はopensource.comに掲載されました。