VitessとTiDBの比較：クロスシャードクエリと一貫性およびAZ障害

TiDBは、シンプルさ、透明性、高い可用性に重点を置き、分散SQLワークロードのための堅牢な基盤を提供します。クロスシャードクエリやアベイラビリティゾーン (AZ) 障害に関する懸念は理解できますが、TiDBのアーキテクチャはこれらのリスクを最小化しており、信頼性と効率的なアプリケーションパフォーマンスを保証します。一方、TiDBとVitess (シャード化されたMySQLインスタンスのオーケストレーター) を比較すると、アーキテクチャの違いにより、アプローチや関連するリスクの認識に違いが生じます。

本ブログでは、両データベースプラットフォームが採用する独自のアプローチを、以下の4つの重要な観点から比較します：シャーディングの範囲と粒度、レプリケーション、クロスシャードクエリのパフォーマンス、そしてアベイラビリティゾーン (AZ) 間でのデプロイメントです。

VitessとTiDBの比較：シャーディングの範囲と粒度

Vitessでは、シャードレンジとは、1つのMySQLインスタンスに対応する、シャードに格納されたデータの値の範囲のことを指します。

シャードとは、キースペースIDやシャーディングキーに基づいてデータを論理的に分割したものです。例えば、キースペースが0-80と81-160のような範囲でシャードに分割され、各範囲が1つのMySQLサーバー全体に対応します。

粒度：Vitessはシャード単位で動作し、各シャードは指定されたキースペースID範囲に対応するデータベース、テーブル、データを含む完全なMySQLインスタンスです。

TiDBのレンジ

TiDBにおいて、レンジ (範囲) とは、単一テーブル内の順序付けられた行の集合を指します。このレンジをリージョンと呼びます。リージョンのデフォルトサイズは96MBです。単一のテーブルは多数のリージョンに分割されます。各リージョンは、Raftコンセンサスプロトコルを使用してクラスタ全体にレプリケートされます。各リージョンと、そのレプリカは、それぞれ独立したRaftグループを形成します。この粒度の細かさにより、あるリージョンでの選挙が他のリージョンに影響を与えることはありません。

粒度：TiDBは、非常に細かい粒度で動作し、リージョンはクラスタ全体に分散およびレプリケートされる小さく管理しやすいデータの塊であり、より優れたバランスとスケーラビリティを実現します。

シャーディング範囲と粒度の影響

Vitessでは、シャーディングは明示的なモデルに従い、シャーディングキーを定義するために手動での操作が必要です。この粒度の大きいアプローチでは、キースペースID範囲に基づいてテーブル全体をMySQLインスタンスに分割します。スケーリングとリシャーディングには、多くの場合、手動での調整が必要です。

TiDBでは、データベースシャーディングは自動化され、粒度が細かく、動的です。テーブルの成長に伴い、TiDBは自動的にリージョンを分割し、TiKVノード間でバランスを取り、手動でのリシャーディングやアプリケーションの変更を必要とせずに、よりスムーズなスケーラビリティと効率的なリソース利用を確実にします。クラスタの拡張時には自動的にデータを再分散をし、スケーリング中のダウンタイムを排除します。

シャーディングシステムにおける主な違い

側面	Vitess (従来のシャーディング)	TiDB (自動シャーディング)
シャーディングキー	ユーザー定義のシャーディングキーまたはキースペースID	手動でのシャーディングキーは不要でTableID + RowIDを使用
シャーディング制御	ユーザーがシャードを設計および管理する必要がある	TiDBが自動的にデータを分割およびバランス調整 (リージョン)
シャーディングの粒度	シャードはMySQLインスタンス全体に対応	リージョン (各約96MB) による細かいデータシャーディング
クロスシャードクエリ	シャードをまたがったスキャッターギャザークエリが必要でありREAD-COMMITTED分離レベルのみを使用	ユーザーに対して透過的で分散SQLエンジンが処理
スケーリング	データ増加に伴い手動でのリシャーディングが必要で新しいトポロジに対応するためのアプリケーション変更も必要になる場合がある	自動的なリージョン分割および再バランス。アプリケーションに対して透過的でノードを追加するだけ

VitessとTiDBの比較：レプリケーション戦略

このセクションでは、両データベースプラットフォームで使用されているレプリケーション戦略について詳しく説明します。それぞれの強み、トレードオフ、および分散データベースのパフォーマンスへの影響に焦点を当てます。

Vitessにおけるレプリケーション

Vitessは、シャードごとに1つのMySQLプライマリサーバーを使用し、各シャードのレプリカを維持するためにMySQLのネイティブなレプリケーションに依存します。Vitessは、レプリケーショントポロジの管理、フェイルオーバーの自動化、およびクエリルーティングの複雑さの抽象化によって、このセットアップを強化します。ただし、MySQLのネイティブなレプリケーションは通常非同期であるため、シャードまたはレプリカ間で強い一貫性を提供するわけではありません。レプリカ間でより強い一貫性保証を必要とするアプリケーションは、追加のメカニズムを実装するか、結果整合性を許容する必要があります。

TiDBにおけるレプリケーション

TiDBは、Raftと呼ばれるコンセンサスアルゴリズムを通じて強い一貫性を実現し、障害時でもすべてのレプリカが一貫性を保つことを保証します。

TiDBにおけるRaft：

• iDBは、TiKVストレージレイヤー内のレプリケーションにRaftを使用します。デフォルトでは、各リージョンは追加の2つのTiKVノードにレプリケートされます。MySQLとは異なり、サーバー全体のレプリカはありません。すべてのTiKVノードは、自身のプライマリリージョンと他のサーバーからのレプリカリージョンの組み合わせを保持します。
• トランザクションは、レプリカの過半数 (クォーラム) が合意した後にのみコミットされ、強力な一貫性を保証します。

レプリケーション戦略の影響

VitessがMySQLの非同期バイナリログレプリケーションに依存することは、潜在的なレプリケーションラグを引き起こし、強い一貫性ではなく結果整合性につながる可能性があります。Vitessはレプリケーション管理とフェイルオーバーを自動化しますが、MySQLの一貫性保証を強化するわけではありません。厳密な一貫性を必要とするアプリケーションは、追加の安全策を実装するか、レプリカから読み取る際に古い読み取りを許容する必要があります。  

さらに、シャードレベルでのレプリケーションは、データサイロにつながり、クロスシャードの一貫性を複雑にする可能性があります。この場合、コストのかかるスキャッターギャザークエリが必要になり、クエリをシャード全体に分散し、結果を集約します。スキャッターギャザークエリは、解決策というよりも回避策であり、特にVitessのように非同期レプリケーションに依存するシステムでは、パフォーマンスのオーバーヘッドと一貫性の課題を引き起こします。

前述のように、TiDBのレプリケーションモデルは、Raftを通じて強力な一貫性を保証します。データはリージョンレベルでレプリケートされ、トランザクションは過半数の合意後にのみコミットされます。このモデルは、耐障害性を向上させ、自動での負荷分散を可能にし、手動介入なしで動的なスケーリングを可能にします。TiDBのアーキテクチャは運用を簡素化し、明示的なデータ分散管理なしにグローバルで一貫性のあるSQLインターフェースを提供します。

VitessとMySQLレプリケーション、TiDBレプリケーションの主な違い

機能	VitessとMySQLレプリケーション	TiDBレプリケーション
レプリケーションメカニズム	プルベースのバイナリログレプリケーション	プッシュベースのRaftコンセンサス
レプリケーションの一貫性	デフォルトで非同期、結果整合性	Raftコンセンサスによる強い一貫性
半同期オプション	手動設定が必要で完全な一貫性ではない	該当なし、常にRaftを使用して一貫性を確保
フェイルオーバー	外部ツールまたは手動介入が必要 (Vitessによって処理される)	自動リーダー選出とフェイルオーバー
クロスシャード一貫性	完全にはサポートされておらず原子性のための2PCはあるが分離性はない	シャード間の強い一貫性
レイテンシ	レプリケーションラグの可能性あり	Raftクォーラム要件により最小限
障害処理	フェイルオーバー中にデータ損失の可能性あり	レプリカの過半数が利用可能である限りデータ損失なし
コンセンサスアルゴリズムの使用	なし、プライマリ-レプリカモデルに依存	データレプリケーションと一貫性のためにRaftコンセンサスを使用
レプリケーションレベル	MySQLサーバー全体をレプリケート	ノード間で分割されたデータ範囲をレプリケート

VitessとTiDBの比較：シャーディング粒度とレプリケーション戦略がクロスシャードクエリ性能に与える影響

TiDBとVitessは、シャーディングとレプリケーションに関して根本的に異なるアプローチを採用しており、これがクロスシャードクエリのパフォーマンスに大きく影響します。これらの影響を理解することは、分散SQLワークロードに適切なプラットフォームを選択する上で非常に重要です。

シャーディング粒度とクロスシャードクエリのパフォーマンス

Vitessでは、粗い粒度のシャーディングは単一シャードのクエリルーティングを単純化しますが、クロスシャードクエリを複雑にします。個別のMySQLサーバーに分散されたデータは、Vitessが複数の独立したデータベース間で連携する必要があり、オーバーヘッドが発生し、クエリのレイテンシが増加します。不適切に選択されたシャーディングキーは、これらの非効率性を悪化させる可能性があります。さらに、各MySQLサーバーは受けとったクエリを個別に解析する必要があり、サーバーのワークロード、構成、またはハードウェアの違いにより、パフォーマンスの変動につながります。各MySQLインスタンスのクエリオプティマイザは、そのインスタンス内のクエリのみを最適化できます。これにより、パフォーマンスチューニングのオーバーヘッドが大幅に増加し、最適化の精度が著しく低下します。最適化レイヤー間の可視性なしに複数の最適化レイヤーを通過する必要があるクエリは、その潜在能力を最大限に最適化できません。

対照的に、TiDBは細かい粒度の動的なシャーディングを採用し、データをTiKVノード全体に動的に分散された小さなリージョンに分割します。クロスリージョンクエリは透過的に処理され、TiDBはクエリを一度解析し、関連するノードに分散される実行計画を生成します。これは、TiDBがクエリの解析と最適化を行うTiDBサーバーに、クエリの最適化に必要なすべてのメタデータを提供するため可能です。この集中型解析は、処理オーバーヘッドを削減し、クラスタ全体で一貫したクエリパフォーマンスを保証します。TiDBの動的シャーディングは、リアルタイムのデータ再分散を可能にし、ホットスポットを軽減し、ワークロードの進化に合わせて一貫したクエリパフォーマンスを維持します。

レプリケーション戦略とクロスシャードクエリのパフォーマンス

VitessがMySQLの非同期バイナリログレプリケーションに依存することは、レプリケーションラグを引き起こし、特にクエリが複数のシャードからの最新データを必要とする場合に、クロスシャードクエリのパフォーマンスに影響を与えます。シャード間の一貫性を確保することは困難であり、クロスシャードトランザクションのパフォーマンスを低下させる可能性があります。

Raftコンセンサスアルゴリズムに基づくTiDBのレプリケーション戦略は、レプリケーションラグの問題を解消し、アプリケーションレベルの一貫性メカニズムを必要とせずに最新のデータを保証します。リージョンレベルでデータをレプリケートすることで、クエリワークロードの均等な分散が可能になり、クロスシャードクエリのパフォーマンスが向上します。

VitessとTiDBの比較：アベイラビリティゾーンを跨いだデプロイメント

Vitessでは、単一障害点を回避するために、シャードは異なるAZ (アベイラビリティゾーン) に分散されます。たとえば、3つのシャードと3つのAZがある場合、各シャードのプライマリは異なるAZに存在し、フェイルオーバー機能のためにレプリカは別のAZに存在します。

TiDBは、Raftを通じて高可用性と耐障害性を確保するために、TiKVノードを複数のAZに分散します。データは本質的にAZ全体にレプリケートされ、AZが利用できなくなった場合に強力な一貫性と自動フェイルオーバーを維持します。TiDBのステートレスSQLレイヤーとPlacement Driverノードも、AZ障害時の継続的なクエリ処理とクラスタ管理を保証するために、AZ全体にデプロイされます。

AZ障害時の生存性と考慮事項

VitessとTiDBはどちらもAZ障害に耐えられるように設計されていますが、そのアーキテクチャはダウンタイムとリカバリに異なる影響を与えます。Vitessでは、AZ障害が発生すると、影響を受けたシャードのプライマリが別のAZのレプリカにフェイルオーバーします。VitessはMySQLの非同期レプリケーションに依存しているため、レプリカがプライマリより遅れている場合、短いダウンタイムと潜在的なデータ損失が発生する可能性があります。

一方、TiDBのRaftの使用は、AZ全体で強力な一貫性を保証します。AZがダウンした場合、TiDBはレプリカの過半数 (クォーラム) が利用可能な限り、ダウンタイムなしで動作を継続できます。この回復力は、データ損失のリスクを最小限に抑え、AZ障害時の迅速なリカバリを可能にします。

結論

TiDBとVitessは、分散SQLデータベース設計において、二つの異なる哲学を表しています。Vitessは、よりレガシーなシャーディングアプローチを提供し、スケーラビリティと一貫性のために手動での介入と慎重な計画を必要とします。これは、クロスシャードクエリのパフォーマンスにおける複雑さと、高可用性シナリオにおける潜在的なリスクにつながる可能性があります。

TiDBのモデルは、完全に自動化された細かい粒度のシャーディング、強い一貫性、およびホットスポットの解決を提供します。これは、分散SQLワークロードに対してシームレスで回復力のある体験を提供できることを意味します。そのアーキテクチャは、信頼性の高いパフォーマンス、最小限の手動介入、および堅牢な耐障害性を保証します。これにより、クラウド環境全体で一貫性、スケーラビリティ、および高可用性を要求するアプリケーションにとって理想的な選択肢となります。

TiDBと従来のMySQLの比較について詳しく知りたいですか？ダウンタイムなしで成長するアプリケーションワークロードをスケールするために必要な知識を得るために、人気の比較ホワイトペーパーをダウンロードしてください。