Evaluation of TiDB, OceanBase, PolarDB-X and CockroachDB secondary index writing performance

Related Tags：1.PolarDB-X
2. PolarDB

要旨：セカンダリインデックスは、リレーショナルデータベースと NoSQL データベースの重要な違いの一つです。セカンダリインデックスには強い整合性が必要なため、インデックスの書き込みはプライマリキーの書き込みと同じトランザクション内に配置する必要があります。トランザクションのパフォーマンスはセカンダリインデックスのパフォーマンスの基盤となります。本テストでは、各種分散データベースのインデックスパフォーマンス、特に業界におけるグローバルインデックスと MySQL のインデックスのパフォーマンス差に注目します。

このテストを実施する理由

セカンダリインデックスは、リレーショナルデータベースと NoSQL データベースの重要な違いの一つです。セカンダリインデックスには強い整合性が必要なため、インデックスの書き込みとプライマリキーの書き込みは同じトランザクション内に配置する必要があります。トランザクションのパフォーマンスは、セカンダリインデックスのパフォーマンスの基盤となります。

市場の分散データベースには、ユーザー体験の観点から主に以下の形態があります。

1：TiDB や CockroachDB に代表される完全透過型。パフォーマンス面では、このタイプのデータベースはすべてのテーブルが分散テーブルとして機能し、パーティションキーの指定は不要です。コアロジックは、分散トランザクションでグローバルインデックスを維持し、グローバルインデックスでスタンドアロンデータベースのセカンダリインデックスを完全に置き換えることにあります。

2：OceanBase に代表される完全手動型。パフォーマンス面では、このタイプのデータベースはパーティションキーを指定しない場合、単一テーブルとして存在するためスケーラビリティがありません。分散テーブルの作成にはパーティションテーブルと同様の構文が必要です。このタイプのデータベースも一般的にグローバルインデックス機能を提供しています（提供しないものは一般にミドルウェアと呼ばれ、データベースとは区別されます）。ただし、第 1 のタイプと異なり、グローバルインデックスはオプションとして扱われ、ユーザーが手動で指定して作成します。さらに、スタンドアロンデータベースベースのトランザクションによるローカルインデックスも提供されています。

3：上記 2 つの利用方法を同時に提供する PolarDB-X。パーティションキーを指定しない場合は、第 1 のタイプのデータベースと同様に、分散テーブルとグローバルインデックスで透過的な分散体験を提供します。また、パーティションキーを手動で指定し、ローカルインデックスなどの技術を活用してパフォーマンスを向上させることもできます。

前回の記事「PolarDB-X データ分散の解釈（IV）：透過 vs 手動」では、以下の見解を提示しました。

1：透過的（自動）な使いやすさは、分散データベースの利用の下限を決定するが、パフォーマンス面でより高いコストがかかる

2：手動操作は最適なパフォーマンスを提供できるが、利用のしきい値が上がる

分散データベースは、大半のシナリオに対して透過的な利用を提供するとともに、パフォーマンス要件が高い一部のシナリオに対して手動チューニングや分散トランザクションの回避手段も提供する必要があります。

この主張の重要な根拠は、純透過モードが本質的に分散トランザクション + グローバルインデックスでスタンドアロンデータベースのトランザクション + インデックスを代替しているのに対し、分散トランザクション + グローバルインデックスのパフォーマンスはスタンドアロンのトランザクション + インデックスとは顕著な差があることです。

本テストでは、各種分散データベースのインデックスパフォーマンス、特にグローバルインデックスと MySQL のインデックスのパフォーマンス差に注目します。

今回のテスト対象プロダクトは TiDB、OceanBase、PolarDB-X、CockroachDB です。選定理由は以下の通りです。

1：すべて強い整合性を持つグローバルインデックス機能を備えており、ミドルウェアではなくデータベースである。

2：オープンソース版とクラウド版の両方が存在し、長い歴史と豊富なデータがある。PPT データベースではないため、内部の原理も理解しやすい。

3：これらのデータベースは主に OLTP 向けである。

さらに、MySQL のインデックスパフォーマンスも比較対象としてテストしました。

テスト方法

各データベースのハードウェア構成（たとえば、OceanBase は 6 台構成でテナント設定によりマシン全体を占有しない、TiDB と TiKV は 5 台、PolarDB-X と MySQL はパブリッククラウドから直接購入など）、システムパラメータなどが統一されていないため、TPS の絶対値を直接比較しても意味がありません。

インデックスなしの場合に各データベースが達成できるピーク値を基準値（100%）とし、異なるインデックス数でのパフォーマンスを基準値に対する割合で比較します。

たとえば、あるプロダクトがインデックスなしで 10 万 TPS を達成し、インデックスありで 5 万 TPS になった場合、基準値の 50% と見なします。この割合を TPS 比率と呼ぶことがあります。

製品間の比較では、TPS の絶対値ではなく、同じインデックス数での TPS 比率を比較します。

TPS 比率のテストでは、同時実行数を調整して最大 TPS を達成する同時実行数を求め、その最大 TPS で TPS 比率を算出します。

TPS 比率に加え、異なるインデックス数での各プロダクトのシングル書き込み時のレスポンスタイムもテストします。レスポンスタイムテストではシングルスレッドで書き込みを行います。

これらの分散データベースが実装するグローバルインデックスでは、インデックスが 1 つの場合でもパフォーマンスが 30% 以下に低下することがわかります。8 つのインデックスの場合、パフォーマンスはほぼ 10% 以下まで低下します。



MySQL のようなスタンドアロンデータベースでは、8 つのインデックスでも 85% 以上のパフォーマンスを維持しています。

これは、PolarDB-X データ分散の解釈（IV）「透過 vs 手動」で述べた論点「スタンドアロンデータベースのトランザクションと比較して、分散トランザクションにはコスト（またはパフォーマンス）面で超えられない差があり、少なくとも 3 倍以上の開きがある」を裏付けるものです。

グローバルインデックスによるスタンドアロンデータベースのインデックス置き換えには高いコストがかかります。コスト重視のシナリオでは、ローカルインデックスを適切に活用してコストを削減する必要があります。

ローカルインデックスを提供するデータベースでは：

・PolarDB-X と OceanBase のローカルインデックスとプライマリキーには Locality アフィニティがあり、スタンドアロンデータベースのトランザクションでインデックスを書き込めます。グローバルインデックスと比較して、PolarDB-X と OceanBase は非常に高いパフォーマンスを維持しています。

・TiDB もローカルインデックスを提供していますが、インデックスとプライマリキー間に Locality アフィニティがなく、同じノードにバインドできません。そのため、ローカルインデックスの維持にも分散トランザクションが必要で、グローバルインデックスとの間に顕著なパフォーマンス差はなく、コストは高いままです。

・CockroachDB のローカルインデックスは理論上 TiDB と同様の動作ですが、CockroachDB のパーティション機能は商用版のみで提供されているため、今回のテストでは検証していません。

TiDB と CockroachDB にとって厳しい状況です。提供するすべてのインデックスのコストがスタンドアロン MySQL よりもはるかに高いからです。ユーザーとしては、セカンダリインデックスを使わない限り、このコストを回避する方法がありません。

レスポンスタイムの観点：

1：スタンドアロンデータベースのトランザクションはネットワークインタラクションが最少のため、レスポンスタイムのパフォーマンスが最も優れており、インデックス数との関連はほとんどありません。

2：分散データベースのトランザクションはより多くのノード間インタラクションを必要とするため、レスポンスタイムはスタンドアロンデータベースより明らかに大きくなります。ただし、分散データベースは一般的にマルチ分岐トランザクションで並列書き込み戦略を採用しているため、パフォーマンスの良いデータベースではインデックス数に比例してレスポンスタイムが増加することはなく、全体的に許容範囲内に収まります。

3：CockroachDB のグローバルインデックスのレスポンスタイムが最も遅く、これは HLC ベースのトランザクション戦略を使用していることが原因と考えられます。他のデータベースは TSO スキームを使用しています。

4：TiDB のグローバルインデックスのレスポンスタイムが最も優れています。0〜8 個のインデックスでレスポンスタイムはほぼ変わらず、並列最適化が非常に優れていることを示しています。

5：PolarDB-X のグローバルインデックスのレスポンスタイムには最適化の余地があるようです。増加幅は限定的ですが、完全な並列処理にはなっていません。今後のバージョンで最適化する予定です。ローカルインデックスのレスポンスタイムは非常に安定しており低レイテンシです。

6：OceanBase のグローバルインデックスとローカルインデックスのパフォーマンスは PolarDB-X と同様の傾向です。並列最適化には改善の余地があり、ローカルインデックスは良好なパフォーマンスを示しています。

テスト過程での追加発見として、TiDB、OceanBase、CockroachDB の auto_increment / serial には深刻なパフォーマンス問題があり、ランダムな代替手段を使用すべきです。TiDB と CockroachDB は時系列によるホットレンジが原因で、OceanBase は内部ロックが原因と考えられます。互換性には機能互換性とパフォーマンス互換性があり、パフォーマンス互換性の実現にはまだ道のりがあります。