TiDB 7.0をリリース：信頼性の高いパフォーマンスと運用のしやすさを実現

※このブログは2023年3月30日に公開された英語ブログ「Announcing TiDB 7.0: Reliable Performance That’s Easier to Operate」の拙訳です。

私たちは、最新のプレビューリリースであるTiDB 7.0を発表できることを大変嬉しく思います。ここでは、2023年半ばにリリースを予定している本番用長期安定版 (LTS) の最新機能と革新的な技術を初めて紹介します。このリリースでは、開発、テスト、概念実証のプロジェクトを対象としています。

TiDB 7.0は、信頼性の高いパフォーマンスと合理化されたデータベース運用により、お客様のビジネスの成長を支援することに継続的に取り組んでいます。お客様の高い期待に応え、開発者やITオペレータの生産性を加速させることができるでしょう。

TiDB 7.0でリリースされた新たな拡張機能と、まもなく本番環境での利用が可能になる機能については、このブログを続けてお読みください。より詳細な情報については、リリースノートをご覧ください。

リソースコントロールによるワークロードの安定性

TiDB 6.6で導入されたこの機能はTiDB独自のもので、安定したマルチテナンシーを実現するための土台となるものです。TiDBのお客様は、安心してマルチテナントを提供することができます。

この機能により、1つまたは複数のセッションのグループに対してリソースの上限を設定することができ、あるワークロードやアプリケーションの消費量が異常に多くなった場合でも、そのリソース消費を、使用不可のリソースから確実に分離することができます。そうすることで、他の重要なワークロードへの干渉を防ぐことができます。

この機能を活用したビジネス事例として、以下のようなものがあります。

• 複数のアプリケーションを1つのTiDBクラスタに統合することで、TCOを削減し、新しいワークロードに対応できるリソースを確保することができます。
• 営業時間中にバッチジョブを安全に実行することができます。
• ステージング環境は、リソース制限を管理した上で、1つのTiDBクラスタを共有することができます。

セッションをリソースグループにバインドするには、3つのレベルでの方法があります。

• ユーザーのセッションレベル
• アドホックのセッションレベル
• ヒントを介したSQLステートメントレベル

この機能については、ブログで詳しく紹介しますのでお楽しみに！

TiFlashのSpill to Diskによる分析ワークロード安定化

TiFlashは、TiDBのカラム型ストレージと計算エンジンで、データベースの分析ワークロード機能のバックボーンとして機能します。TiDB 7.0より前のバージョンでは、TiFlashはすべてのデータをメモリ上で処理しました。このバージョンでは、中間結果をディスクに書き出すことができるため、大規模なクエリに対してストレージをメモリの有効な拡張として利用することができます。この機能の背景にある考え方は、大規模な単一クエリの性能を、分析クエリの全体的な安定性と引き換えるというものです。分析クエリの安定性は、これらのクラスタをより予測しやすくするものです。

このディスクへの書き出しは、ユーザー自身が設定可能なパラメーターに従って行われ、個々のプッシュダウン操作に適用されます。この最適化は個々のオペレーターレベルで行われるため、このディスクへの書き出し機能を複数個所に実装する必要があります。TiDB 7.0では、まず次のようなものが実装されています。

• 等号条件でのハッシュ結合
• GROUP BYでのハッシュ集計
• Window関数におけるTopNとソート演算子

処理中に、オペレーターの使用するメモリ量が設定された上限を超えた場合にも、失敗するのではなく、データはディスクへ書き出されその後の処理が続行されます。

ターゲットワークロードへの影響を明らかにするため、意思決定支援システムをシミュレートするTPC-Hベンチマークツールをテストしました。結果は以下の表の通りです。

	実行時間	ピーク時のメモリ使用量	書き出されたパーティション数	パーティション数合計
書き出しが有効でない	9.17s	42.09 GiB	0	40
書き出しが可能だが、書き出されない	9.10s	42.08 GiB	0	40
最大結合メモリ使用量を10Gに設定	15.45s/25.50 (リストアの並行処理は無効)	30.63 GiB	21	40
最大結合メモリ使用量を5Gに設定	21.86s / 32.62s (リストアの並行処理は無効)	18.82 GiB	32	40

この機能の詳細については、ディスクへの書き出しに関するドキュメントをご覧ください。

自動プランキャッシュでクエリレイテンシーを削減

TiDB 7.0では、自動プランキャッシュが導入されました。これより前のバージョンでは、プランキャッシュはサポートされていましたが、プリペアドステートメント (PREPAREの利用) の形式でのみでした。このバージョンでは、あらゆるクエリを自動的にキャッシュするためのフレームワークを導入しています。

実験段階の本機能で重要なことは以下の通りです。

• この実装では、クエリーをグローバルではなく、セッションレベルでキャッシュします。グローバル版は今後のリリースが計画されています。セッションレベルのキャッシュは、大きなキャッシュで適切なプランを見つけるための待ち時間を減らしますが、セッション間で重複する可能性があるため、グローバルキャッシュのメモリ使用量を増やす可能性があります。
• この実装では対応クエリが制限されています。現在、この機能でキャッシュできるクエリの種類は単一テーブルのフィルタとレンジクエリで、キャッシュできないのは単一テーブルの複合クエリとJOINクエリになります。

この機能のアーキテクチャ図と詳細については、ノンプリペアド実行プランキャッシュのドキュメントを参照してください。

TiFlash Re-Architectureによる弾力性の向上

TiFlashの主要な特性は2つあります。

• TiFlashはTiKVのデータのカラム型コピーを保持
• ストレージとクエリ処理は各ノードで結合 (TiDB/TiKVとは別物)

TiFlashの新しいアーキテクチャは、2つの形態で提供されます。

• ストレージと計算は分離
• ストレージはオブジェクトストレージ (このバージョンではS3) にオフロード

1つ目は、ストレージと計算機能が互いに独立してスケーラブルになることです。つまり、クエリを拡張する際にストレージノードを追加したり、書き込みスループットを向上させる際に計算ノードを追加したりする必要がないのです。加えて、書き込みとデータ管理が読み込みの邪魔になることもありません (その逆もまた然り) 。

この実験的な機能により、分析ワークロードをサポートするためにTiFlashを使用する際の追加費用が大幅に軽減されます。また、クラスタのこの領域の費用対効果も大幅に向上します。さらに、ワークロードを分離することで安定性を向上させることができるのです。

今や独立したコンポーネントとなったTiUPとK8sオペレーターは、すでにその導入と拡張の機能をサポートしています。

本機能の詳細については、TiFlash Disaggregated Storage and Compute Architecture and S3 Supportをご参照ください。

TTLテーブルによるデータの自動期限切れと削除

TiDB 6.5では、非常に熱烈な要望があった「Time to live」(TTL) が導入されました。TiDB 7.0のGAでリリースされたTTLは、テーブル内の行にSQLで有効期限を設定する仕組みです。これにより、オペレーターは何らかの理由で古すぎると判断したデータの自動削除を設定することができます。

データベースのオペレーターやユーザーは、コスト、パフォーマンス、セキュリティなどの理由で、テーブルの行を自動的に期限切れにして削除したいことがあります。具体的には以下の通り。

• テーブルが大きくなることで、クエリが長くかかる場合
• テーブルが大きくなると、ストレージコストがかかるため
• TiDBでは、テーブルが大きくなるほどキーの範囲 (リージョン) が増えるため、テーブルサイズを制限することでシステムの頭脳 (PD) への負荷を軽減
• 様々なコンプライアンス遵守のために、データの有効期限が必要な場合

TTLが導入される前は、TiDBユーザーはテーブルを無限に成長させるか、手動で行を削除するか、独自の削除自動化を構築・維持するかのいずれかを選択しなければなりませんでした。TTLがTiDBに組み込まれたことで、その選択した手段の実行だけでなく、パフォーマンス向上のために必要なすべての作業の負担を軽減することになりました。

この機能の利用方法については、TTL (Time to Live) のドキュメントをご覧ください。

KEYパーティショニングでスケーラビリティを向上

7.0より前のTiDBでは、HASH、RANGE、LISTのパーティショニングをサポートしていました。このバージョンでは、KEYパーティショニングを採用しています。HASHパーティショニングと同様に、KEYパーティショニングを使用して、クラスタ内のノードにキーを分散させ、ホットスポットを防止することができます。しかし、HASHパーティショニングとは異なり、KEYパーティショニングは整数式やカラムに限定されず、非整数カラムやカラムのリストに基づくデータも含めての分散をサポートします。

KEYパーティショニングは、クラスタのスケーラビリティを向上させるために、データセットをより柔軟に分散させる方法です。

REORGANIZEパーティションで変化する要件に対応

TiDBは長い間、パーティショニングをサポートしてきました。しかし今日まで、テーブルのパーティショニングを変更する方法は、パーティションの追加や削除、LIST/RANGEパーティションの切り捨てだけでした。

TiDB 7.0ではREORGANIZEパーティションが汎用化され、LIST/RANGEのパーティションをオンラインで結合、分割したり、その他の変更をすることができるようになりました。

この機能により、操作性が向上し、変化する要件に柔軟に対応できるようになりました。

LOAD DATAでリモートストアからのデータ取り込み

LOAD DATAはすでにTiDBにデータをインポートするためのSQLベースのインタフェイスとしてサポートされていましたが、TiDB 7.0はそれに多くの機能を導入しています。LOAD DATAインターフェイスは、リモートストアからのデータのインポートをサポートするようになりました。さらに、インポート前に修正する必要がある下流の潜在的な問題の検出、バックグラウンドでの「切り離し」実行、インポートジョブのステータスの照会が可能になるなど、多くのオペレーション上の利便性が追加されています。

スタートアップと詳細

TiDBの最新プレビューバージョンであるTiDB 7.0では、これらの革新的なエンタープライズグレードの機能をご提供します。ぜひ、TiDBをお試しください。

• TiDB 7.0をダウンロード – インストールは数分で完了します。
• TiDB Slackコミュニティに参加すると、活発なTiDBコミュニティとの交流や、エンジニアチームとのリアルタイムのディスカッションができます。

TiDBを体験するには、無料サインアップよりTiDB Serverlessをお試しください。日本語ドキュメントのTiDBクイックスタートガイド、または無料オンライントレーニングのご利用をお勧めします。ご不明な点などございましたら、お問い合わせフォームよりご連絡ください。 また、GitHubにて問題を報告することもできます。