※このブログは2023年2月25日に公開された英語ブログ「The upcoming revolution: an early look at a supercharged power in TiDB 6.6」の拙訳です。

著者：Qi Xu

新Raft KVエンジン：ワンランク上のスケーラビリティと書き込み性能

NewSQLデータベースのTiDBは、拡張性の高い分散型HTAPデータベースであり、TiDBを構成するコンポーネントの1つであるTiKVはTiDBの行ベースストレージレイヤーとなります。TiDBの利点の1つは、OLTPのスケーラビリティです。TiDB 6.6より前のバージョンでも、TiDBクラスタに200TB以上のデータを簡単に利用することができましたので、500TB以上のデータをTiDBクラスタで利用するお客様もいます。比較対象のAurora等、従来のデータベースでは、100TB以上のデータを扱うのに苦戦します。

TiDB 6.6では、TiKVの実験的な新機能である「Partitioned Raft KV」によって、スケーラビリティをペタバイトレベルにまで高めることができます。一見すると明らかではありませんが、新しいアーキテクチャを活用することで、スケーラビリティを高めるだけでなく、TiDBの書き込みスループットやパフォーマンスの安定性を大幅に向上させることができるのです。

お客様にとってはどんな意味があるのか

以下に、改良点を簡単にまとめます。

• より効率的に。ハードウェアの能力を最大限に活用し、書き込みパイプラインのボトルネックを解消します。
• より速く。特に大規模なデータセットでの書き込み性能とQoSを向上させます。
• よりセキュアに。テーブルごとに物理的に隔離されています。

Partitioned Raft KVの主な改良点の1つは、書き込み増幅率を最大80%まで大幅に削減し、より多くのIOリソースをユーザーの実際の読み取りまたは書き込みトラフィックに使用することができることです。

もう1つの大きな改善点は、リージョンごとに専用のRocksdbインスタンスを用意することで、1つの巨大なRocksdbインスタンスの論理的なボトルネックを解消していることです。その結果、スナップショットの生成や適用時に、ユーザーのトラフィックに論理的な影響を与えることがありません。スナップショットの影響は、IO/CPUリソースの消費だけですが、読み込みの増幅がないため、旧バージョンよりもまだ小さいです。

パフォーマンス向上の結果をいくつか紹介

AWSのm5.2xlargeにSysbenchのバルクインサートを利用

ここでは、書き込みスループットが非常に高いことがわかります。IO集約であるほど改善されます。つまり、ワイドテーブル (例：行のサイズが4KB以上) の挿入パフォーマンスの向上は、スモールテーブルの向上よりも大きいということです。

また、もう一つの重要な改良点は、スケールアウトとスケールイン (TiKVノードの追加と削減) のスピードが速くなったことです。これは、TiKVがユーザーのトラフィックの急増や減少に対して、より速く反応できるようになったことを意味します。さらに、下のスクリーンショットでわかるように、gRPCのレイテンシーとスループットは、スケールアウトやスケールインの操作に影響されないのです。

CPU使用率については、書き込みスループットが高いにもかかわらず、Partitioned Raft KVのCPU使用率が著しく高くなることはありません。これは、ワークロード自体がCPU集約ではないこと、Partitioned Raft KVはコンパクション関連のCPU使用が少ないこと、また内部のメッセージエンコーディングも最適化されていることに起因しています。そのため、MBあたりのCPUスループットはずっと低くなっています。

改善されない点

• 大量の小さな読み書きの要求など、ワークロードがCPUに集中すること
• ワークロードが大量に読み込みであること

コンパクションの際にCPU使用を節約できるかもしれませんが、それによって削減されるCPUリソースは、通常1つのシングルコアよりも少ないです。つまり、ワークロードがCPU集約型の場合、「Partitioned Raft KV」は大して役には立たないでしょう。もちろん性能を劣化させることはありません。

しかし、読み込みが多いシナリオでは「Partitioned Raft KV」はリード性能の面で一桁の性能劣化がある可能性があります。これは、memtableに多くのメモリを消費するためで、レンジクエリのワークロードではあまり意味がないのですが、このメモリをページキャッシュで使用すれば、より良い読み取り性能を達成できるかもしれません。将来のバージョンでは、アイドル状態のmemtableをフラッシュすることで最適化する予定です。

次のセクションでは、なぜこのような改善が可能なのかについて詳しく説明し、実際のユーザー事例を使用して、web3シナリオにおけるその利点を実証していきます。

Web3の事例

B社は、多くのブロックチェーンのデータを同期し、顧客にクエリ/アナリティクスサービスを提供するWeb3サービスプロバイダーです。1ヶ月に約40TBのデータを取り込んでおり、クエリの読み込みはほぼ最近のデータで、古いデータはほとんどアイドル状態です。

Web3サービスの概観

現在、各TiKVノードに2TB以上のデータがある場合、読み書きの増幅によりパフォーマンスの安定性に影響が出ます。そのため、B社では、クエリトラフィックが安定しているにもかかわらず、急速に増加するデータ量に対応するために、データサイズに合わせて毎月TiKVノードを追加する必要がありました。B社がこの問題を回避するためにたどり着いたソリューションは、「コールドデータとホットデータの分離」でした。

大規模データセットのパフォーマンス安定を図るワークラウンド – コールドホットデータセパレーション

まず、処理済みデータへの影響を減らすために、生データと分離する必要がありました。これで、処理済みデータと生データの2つのクラスタを持つことになります。次に、ホットな生データの影響を減らすために、B社は配置ルールを使い、主キーに埋め込まれたタイムスタンプによってコールドデータとホットデータを分離しました。これは毎月更新される配置ルールによって行われます。この方法の問題点は、以下の通りです。

• B社では1つではなく2つのクラスタを持つことになり、管理の複雑さが増します。また、配置ルールの月次更新もミスを招きやすい作業です。
• コールド生データ、ホット生データのリソース割り当てが厄介です。共有されていないため、コールド生データのTiKVはほとんどアイドル状態で、使用するときにはリソースが足りなくなる可能性があります。

しかし、v6.6の「Partitioned Raft KV」なら、コールドデータがホットデータのクエリに影響を与える心配がないので、1つのクラスタを使い続けられます。コールドデータは、メモリやCPUを消費することなく、ただ黙ってそこに置かれています。コールドデータとホットデータを混在させることで、1台のTiKVで大容量データ (4TB以上) に対応できるようになりました。つまり、コールドデータとホットデータの両方に、まったく同じTiKVノードを使うことができるのです。ホットデータはホットリージョンバランスのおかげで異なるTiKVノードに散在し、コールドデータもリージョンバランスのおかげで各TiKVノードにかなり均等に分散されることになります。

実験的な新機能を有効にする方法

この機能は、新しいクラスタをセットアップするときにのみ有効で、それ以降はデータの互換性の問題から変更することはできません。後のバージョンでは解決される予定です。新機能を有効にするには、storage.engine = “partitioned-raft-kv”という設定に変更するだけです。その他にも、ワークロードに合うようにチューニングできる設定項目があります。詳しくは、https://docs.pingcap.com/tidb/v6.6/partitioned-raft-kvを参照してください。

次の記事では、この新機能の内部機構を探ってみましょう。こうした利点がなぜあるのかをご理解いただけると思います。