著者:徐琦
TiKV は、「partitioned-raft-kv」と呼ばれる新しい実験機能を開始しました。これは、TiDB のスケーラビリティを大幅に向上させるだけでなく、TiDB の書き込みスループットとパフォーマンスの安定性も向上させることができる新しいアーキテクチャを採用しています。
前回の投稿では、Partitioned Raft KV のこの新しい実験的機能によってもたらされる大幅なパフォーマンスとスケーラビリティの向上について説明しました。この記事では、なぜこれほど大きなメリットがあるのかを紹介します。
建築
TiKV のアーキテクチャは次のとおりです。
図 1 TiKV アーキテクチャ - 論理データ パーティショニング
TiKV クラスターは、多くのデータ パーティション (リージョンとも呼ばれます) で構成されます。各リージョンは、開始キー範囲と終了キー範囲によって決定される特定のデータを担当します。異なる TiKV ノード上に 3 つ以上のレプリカがあり、raft プロトコルを通じてそれらを同期します。古い Raft エンジンでは、すべてのリージョンのデータを保存するための RocksDB インスタンスが各 TiKV に 1 つだけ存在します。Partitioned-Raft-KV 機能により、新しい物理データ レイアウトが導入されます。各リージョンには独自の RocksDB インスタンスがあります。
図 2: 物理データのレイアウトの比較
旧型 Raft KV エンジンの課題
「リージョン」は、TiKV における論理スケール単位です。負荷分散、スケールアップおよびスケールダウンなどのすべてのデータ アクセスおよび管理操作は、リージョンごとに分割されます。ただし、現在のアーキテクチャでは、これは純粋に論理的な概念であり、物理的に明確な領域境界はありません。これの意味は：
- リージョンのデータをある TiKV から別の TiKV に移動する必要がある場合 (ロード バランシングとも呼ばれます)、TiKV は巨大な RocksDB インスタンスをスキャンしてリージョンのデータを取得する必要があります。これにより、リードワイドニングが発生します。
- 複数のリージョンに大量の書き込みトラフィックがあり、それらのキー範囲が分散している場合、他のアイドル状態のリージョンからのデータを含む RocksDB で大規模な圧縮がトリガーされる可能性があります。これにより、読み取りおよび書き込みのスケーリングが導入されます。たとえば、SST11 は、region1 のデータのみを含む 1MB サイズの SST ですが、かなり大きなキー範囲が含まれています。L2 にマージするように選択した場合、SST21、SST22、および SST23 はすべて圧縮に参加し、領域 2、3、4 のデータが含まれます。TiKV の規模が大きくなるほど、読み取りと書き込みの拡張も大きくなります。
図 3: 異なるリージョン間の圧縮データ
- リージョンの分離がないため、いくつかの人気のあるリージョンがすべてのリージョンのパフォーマンスを低下させる可能性があります。
したがって、古いラフト KV エンジンでは、次の問題が発生する可能性があります。
- 複数のデータスキャンが必要となるため、容量拡張の速度は非常に遅くなります。
- RocksDB の書き込みグループはシングルスレッドであるため、書き込みスループットは制限されています。
- データ圧縮が時々行われるため、RocksDB 内のデータ量が多い場合、ユーザー トラフィックのレイテンシーが不安定になります。
分割された Raft KV エンジンの改良
- 各リージョンのデータは専用の RocksDB インスタンスであるため、リージョン間の負荷分散のために RocksDB の x-copy を実行するだけで済み、読み取り増幅の発生を回避できます。
- ホットスポット リージョンの書き込みトラフィックは、そのリージョン自体の RocksDB の圧縮のみをトリガーし、他のリージョンのデータは関与しません。したがって、読み取りおよび書き込みの増幅が効果的に低減されます。
- RocksDB にデータを書き込む場合、各スレッドは異なる RocksDB インスタンスに書き込むため、書き込みスレッド間でデータの同期やロックの競合は発生しません。これにより、書き込みのボトルネックが解消されます。WAL ログがないため、RocksDB への書き込みはメモリ内操作です。
- RocksDB のパフォーマンスが低下しても、他のリージョンには影響しません。したがって、リージョンのパフォーマンスはストレージ レベルで分離されます。
- 各リージョンは、より大きな容量 (デフォルトで 15 GB) をサポートするようになりました。以前のリージョン サイズ制限の 96 MB と比較して、ハートビートやメモリ使用量などのリージョンのオーバーヘッドが 99% も削減されました。
したがって、パーティション化された raft KV を使用すると、TiDB はデータの拡張または縮小が約 5 倍速くなり、圧縮の影響がはるかに小さいため、一般にパフォーマンスがより安定します。
適用範囲
すべてがうまく見えます。しかし、もう一つ問題があります。現在、RocksDB インスタンスの数が増えているため、memtable のメモリ消費量が大幅に増加しています。つまり、メモリ消費量とパフォーマンスのバランスをとるために、さらに 5GB ～ 10GB のメモリ オーバーヘッドが必要になる可能性があります。したがって、メモリ リソースがすでに非常に不足しているときにこの機能をオンにすることは一般的に推奨されません。ただし、TiKV に追加のメモリがあり、スケーラビリティと書き込みパフォーマンスを重視する場合には、この機能が役立つ場合があります。
最後に書きます
一部の顧客は、TiDB の現在のバージョンで十分であると言うかもしれません。したがって、新機能は彼らにとってあまり重要ではないようです。しかし、それらをクラスター内の複数のワークロードに使用でき、それぞれが適切な分離と QoS 保証を備えているとしたらどうなるでしょうか? これはバージョン 7.0 の「リソース ガバナンス」機能です。「パーティションraft KV」機能はハードウェアのパフォーマンスを最大化するように設計されており、「リソースガバナンス」と併用することで、お客様は複数のワークロードを1つのクラスターに統合することでハードウェアリソースを最大限に活用し、コストを削減することができます。