オープンソースの分散型ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング（HTAP）データベースの最新版であるTiDB 6.0を発表します。本リリースでは、エンタープライズ製品としてのTiDBの管理性を大幅に向上させ、クラウドネイティブデータベースに必要な多くの必須機能を搭載しています。TiDB 6.0では、以下の主要な機能強化が行われています。
- SQLによるの配置ルールを導入
- エンタープライズクラスタ用の管理コンポーネント「TiDB Enterprise Manager」を追加
- インテリジェント診断サービス「PingCAPクリニック」のプレビューを提供
- エコシステム・ツールの保守性を大幅に強化
- ホットスポットの問題に対するより多くの解決策を提供
これらの新機能により、クラウド、オンプレミスを問わず、TiDBをよりスムーズに利用できるようになり、TiDBは成熟したエンタープライズレベルのクラウドデータベースへの道を進んでいます。
管理性の向上
良いデータベースは管理が簡単です。TiDB 6.0を開発するにあたり、ユーザーや市場からのフィードバックを検証し、複雑で直感的でない日々の管理業務、データの保存場所のコントロール不足、使いにくいエコシステムツール、ホットスポットに対する解決策の欠如など、TiDBの管理性の問題をまとめました。TiDB 6.0では、カーネルの強化、エコシステムツールの改善、管理コンポーネントの導入により、これらの問題に対処しています。
自律的なデータスケジューリングフレームワーク
TiDB 6.0はSQLによる配置ルールを導入し、データスケジューリングのフレームワークをSQLで記述できるようにしています。従来、TiDBはデータブロックのノードへの格納方法を、データセンターの物理的な境界やデータセンター間のハードウェアの違いに関係なく決定していました。そのため、複数のデータセンター、コールドデータとホットデータの分離、バッファ分離による大量の書き込みが必要なアプリケーションでは、TiDBが柔軟なソリューションを提供することができませんでした。
次の2つのシナリオをご覧ください。
- シナリオ1：ニューヨーク、シカゴ、ロサンゼルスのデータセンターで、複数の都市にまたがるアプリケーション。北東部、中西部、西部のユーザーグループをカバーするために、3つのデータセンターにわたってTiDBを展開したいとします。初期のバージョンのTiDBクラスタでは、このような展開が可能でした。しかし、異なるユーザーグループのデータは、ホットスポットとデータ量に基づいて、異なるセンターに均等に散らばっています。そのため、地域をまたいだ集中的なデータアクセスは、高いレイテンシーに悩まされる可能性があります。
- シナリオ2：ターゲット作業ノードに直接データをインポートすることで発生するパフォーマンスのジッターを分離するために、データのインポート専用のノードセットを配置し、インポートしたデータをターゲット作業ノードに移動させたい場合です。代替案として、性能の低い構成のノードセットを使用して、アクセス頻度の低いコールドデータを保存することもできます。
6.0以前は、このようなユースケースをサポートするための特別なソリューションはありませんでした。
TiDB 6.0では、公開されたデータスケジューリングフレームワークが、パーティション、テーブル、データベースレベルのデータを、任意のラベル付きノードに配置するためのインターフェースを提供します。このインターフェースを使えば、パーティションやテーブルのターゲットノードを必要に応じて指定することができます。TIDB 6.0では、ノードの集合にラベルを追加し、ラベルの配置制約を定義することができます。たとえば、ニューヨークのデータセンターにあるすべてのTiDBストレージノードに対して配置ポリシーを定義することができます。
CREATE PLACEMENT POLICY 'newyork' CONSTRAINTS = "[+region=nyc]";そして、nyc_accountという名前のテーブルに配置ポリシーを適用することができます。
CREATE TABLE nyc_account (ID INT) PLACEMENT POLICY = 'newyork';同様に、コスト削減のために、低速なハードディスクを利用するノードにラベルを付けてアクセス頻度の低いデータを保存し、古いデータパーティションは低コストのノードに置くことができます。この方法では、nyc_accountテーブルのすべてのデータがニューヨークのデータセンターに保存され、このテーブルへのデータアクセス要求がそこにルーティングされることになります。
CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";
ALTER TABLE orders PARTITION p0 PLACEMENT POLICY = 'storeonhdd'；また、SQLによる配置ルール機能は、マルチテナントの分離にも有効です。例えば、ユーザーは異なるテナントのデータをプレースメントルールに基づいて同一クラスタ内の異なるノードに割り当てることができ、異なるテナントの負荷は対応するノードで自動的に処理されます。このように、TiDBはテナントを分離しつつ、合理的な権限設定の下でテナント間のデータアクセスを許可することができます。この機能の詳細については、TIDBドキュメントのPlacement Rules in SQLをご覧ください。
ホットスポットシナリオのキャッチアップ
ホットスポットデータへのアクセスやロックの競合は、分散型データベースにおけるアプリケーションの安定性や操作性を損なう可能性があります。ホットスポットの扱いは、これまで煩わしく、困難なものでした。ホットスポットの痛みを軽減するために、TiDB 6.0は多くの解決策を展開します。
小さなテーブルのキャッシュ
ユーザーアプリケーションは、大きなテーブル（例えば、注文テーブル）と多くの小さなテーブル（例えば、為替レートテーブル）を同時に操作することがあります。TiDBは大きなテーブルの負荷を容易に分散できますが、小さなテーブルはトランザクションごとにデータもアクセスされるため、パフォーマンスのボトルネックになることがよくあります。この問題に対処するため、TiDB 6.0ではスモールテーブルキャッシュを導入し、小さなホットスポットテーブルをメモリに明示的にキャッシュするようにしました。この機能により、特に頻繁にアクセスされるがほとんど更新されない小さなテーブルのアクセススループットが大幅に改善され、読み込みレイテンシが短縮されます。この機能の詳細については、TiDBのドキュメントのCached Tablesをご覧ください。
インメモリの悲観的なロック
TiDB 6.0は、悲観的ロックトランザクションをキャッシュすることで、悲観的トランザクションを使用するシナリオにおけるリソースのオーバーヘッドを大幅に削減します。この機能を有効にすると、CPUとI/Oのオーバーヘッドを20%近く削減し、パフォーマンスを5%から10%向上させることができます。この機能の詳細については、TiDBのドキュメントのIn-memory Pessimistic Lockingをご覧ください。
TiDBエコシステムツールにおける管理性の向上
TIDBエコシステムのツールで大量のタスク操作を扱う場合、コマンドラインでの操作は非効率でエラーが発生しやすいものです。管理が難しくなってしまいます。データ移行環境全体を管理するために、TiDB 6.0のデータ移行（DM）機能は、以下の機能を持つWebベースのGUI管理プラットフォームを展開します。
- DMの主な監視情報と移行タスクのステータス情報を表示するダッシュボードを更新。ユーザーは移行タスクのステータスを素早く知ることができ、主要なレイテンシーやパフォーマンス指標を確認することが可能。
- タスクの監視、作成、削除、設定、複製を支援するマイグレーション管理。
- データ移行環境において、上流構成の作成・削除、上流構成に対応するタスク状況の監視、上流構成の変更など、上流構成の管理を支援するソース管理。
- 上流と下流の構成情報、上流と下流のデータベース名やテーブル名など、指定したフィルターに基づく詳細な構成やタスクの状況を確認できるレプリケーション管理。
- 現在のDMクラスタの構成情報や各ワーカーのステータス情報を閲覧できるクラスタ管理。
この機能の詳細については、「DM Web GUIガイド」をご覧ください。
新しいマネジメントプラットフォームとインテリジェントな診断ツールキット
TiEMマネジメントプラットフォーム
TiDB 6.0以前は、日々の運用・保守にコマンドラインを使用する必要がありました。 アプリケーションごとに異なる構成の複数のクラスタを管理・監視するなどの日常的な操作は、非常に困難なものであったでしょう。運用を簡素化し、ヒューマンエラーの可能性を低減するため、TiDB 6.0では、リソース管理、マルチクラスタ管理、パラメータグループ管理、データのインポートとエクスポート、システム監視などのさまざまなコンポーネントを統合したグラフィカル管理プラットフォーム「TiDB Enterprise Manager（TiEM）」を導入しています。
TiEMを通じて、ユーザーは日常的な操作を1つのインターフェースで行うことができます。また、TiEMはモニタリングやログ管理機能を提供し、クラスタの点検を容易にします。ユーザーは、複数のツールキットとモニターページを切り替える必要がなくなります。TiEMの詳細については、TiDBドキュメントの「Customize Configurations of Monitoring Servers（監視サーバーの設定のカスタマイズ）」をご覧ください。
PingCAPクリニックインテリジェントツールキット
分散システムは複雑であり、TiDBの問題を診断し解決するのは困難な場合があります。サービスプロバイダーがさまざまな事情を抱えたユーザーを扱うクラウド環境のTiDBクラスタでは、その課題はさらに大きくなります。
このような背景から、TiBD 6.0はセルフサービス型データベースへ向けて大きな一歩を踏み出しました。TiDB 6.0では、インテリジェントなデータベース診断サービスであるPingCAPクリニックのプレビュー版を導入しています。TiDBクリニックを利用することで、TiDBクラスタのライフサイクル全般にわたる安定した運用、潜在的な問題の予測、問題の発生確率の低減、クラスタ問題の迅速なトラブルシューティング、クラスタ問題の修正が可能になります。ユーザーは、リモートでクラスタの問題をトラブルシューティングしたり、ローカルでクラスタの状態をすばやくチェックしたりすることができます。この機能の詳細については、TiDBドキュメントのPingCAP Clinic Overviewをご覧ください。
初心者向けの観測のしやすさ
TiDBは、ユーザーが自分のアプリケーションがTiDB上でどのように動作しているかをより理解し、より正確にトラブルシューティングやチューニングができるように、常に観測性の強化に努めています。これまでのリリースでは、Key Visualizer、SQL統計、Continuous Profilingなどの観測機能を紹介してきました。しかし、これらは専門家向けの機能であり、ユーザーはシステムをある程度技術的に深く理解する必要があります。
TiDB 6.0は、TiDBのエキスパートでなくても、DBAやアプリケーション開発者がデータベースのパフォーマンスを観察し、簡単に診断できる初心者向けの観測機能であるTop SQLによって、この状況を変えました。インデックスの使い方、ロック競合、実行計画などの基本的なデータベース概念に精通していれば、Top SQLを使用してデータベース負荷を迅速に分析し、アプリケーションのパフォーマンスを向上させることができます。
TiDB Dashboardでは、追加の設定なしにTop SQLを使用することができます。Top SQLの詳細については、TiDBドキュメントのTOP SQLをご覧ください。
より堅牢になったHTAP機能
TiDB 5.0では、解析エンジンTiFlashの初期バージョンに超並列処理（MPP）実行モードを搭載し、より幅広いアプリケーションシナリオに対応できるようになりました。最新版のTiFlashでは、以下の機能をサポートしています。
- 演算子・関数の増加： TiDB 6.0解析エンジンは、110以上の組み込み関数と、いくつかのテーブル関連演算子を追加しました。TiDB解析エンジンの性能は大幅に向上し、演算処理に有利になります。
- 最適化されたスレッドモデル：以前のバージョンのTiDBでは、MPPモードでのスレッドリソースの使用はほとんど制限されていませんでした。そのため、並列性の高いショートクエリを処理する際に、大量のリソースを浪費してしまうことがありました。また、複雑な計算を行う場合、MPPエンジンが多くのスレッドを占有し、パフォーマンスと安定性の問題につながっていました。この問題に対処するため、TiDB 6.0では柔軟なスレッドプールを導入し、処理がスレッドを保持する方法を再構築しました。これにより、MPPモードでのリソース利用が最適化され、短いクエリでは同じ計算資源で性能を倍増させ、長いクエリでは信頼性を向上させることができました。
- より効率的なカラムエンジン：ストレージエンジンのファイル構造とI/Oモデルを調整することにより、TiDB 6.0は異なるノード上のレプリカとファイルブロックへのアクセス計画を最適化するだけでなく、書き込み増幅への対応とコード全体の効率性を向上させました。ユーザーによるテスト結果によると、CPUとメモリリソースの使用量が劇的に減少し、高い読み取りと書き込みのハイブリッドワークロードにおいて、並行処理能力が50%から100%以上改善されたとのことです。
TiDB 5.0と比較すると、TPC-Cのパフォーマンスは76.32%向上しています。
ディザスターリカバリー機能の強化
TiDB 6.0では、TiDB change data capture framework（TiCDC）が強化され、ディザスターリカバリー（DR）機能が向上しています。TiCDCはDRの中核コンポーネントとして、インクリメンタルデータ処理の最適化やトランザクションログの取得速度のチューニングにより、災害時の巨大なクラスタデータの復旧を大きく進化させます。
また、本リリースでは、インクリメンタルデータの抽出、ソート、ロード、配信など、いくつかのTiCDC処理を最適化しました。この最適化により、大規模クラスタにおいて、データレプリケーションの安定性の向上、リソース消費の削減、データレイテンシーの短縮を実現します。ユーザーからのテストデータによると、TiCDCは以下の性能を発揮することができます。
– Latency: < 10 seconds for 99.9% data
– RTO: < 5 minutes
– RPO: < 10 minutes
なお、この性能は、1万個の上流テーブルで、1秒間に変更される行数が2万行未満で、データ量の変更が1秒間に20MB未満である場合に基づいています。
全体として、上流のTiDBクラスタのノードを計画通りにアップグレードまたは停止しても、レイテンシを1分以内に抑えることができます。
また、データレプリケーションが上流クラスタの性能に与える影響を軽減し、ビジネスに影響を与えないデータレプリケーションを実現するために、TiCDCはプライマリークラスタにおけるトランザクションログのスキャンにおけるストリーム制限をサポートしています。ほとんどの場合、TiCDCが上流クラスタで実行されるQPSおよびSQL文の平均応答時間に与える影響は5%未満です。
今後の展望
TiDB 6.0は、TiDBをエンタープライズレベルのHTAPデータベースへと近づけます。しかし、このリリースはTiDBの新たな出発点でもあり、クラウドデータベースとしての方向性も示しています。管理性、SQLによる配置ルール、PingCAP クリニックの自動診断などの機能はオンプレミスのデプロイメントにも適用されますが、実際にはクラウドでより大きな可能性を持つことになるでしょう。
これらはTiDB 6.0に含まれるハイライトのほんの一例です。機能、改善点、バグフィックス、安定性向上の全リストは、リリースノートをご覧ください。
現在、TiDBをご利用されていない方は、TiDB 6.0をダウンロードしてお試しください。
旧バージョンのTiDBを使用していて、6.0を試したい場合は、Upgrade TiDB Using TiUPで詳細をご覧ください。
そして、ぜひSlackやTiDBInternalsのコミュニティに参加して、我々にご意見をお寄せください。
PingCAPについて
PingCAPは、エンタープライズ向けのソフトウェアサービスプロバイダーとして2015年に設立され、オープンソースでクラウドネイティブなワンストップのデータベースソリューションを提供することにコミットしています。PingCAPの社名は、ネットワークの疎通を確認するために使用されるコマンド「Ping」とCAP定理の「CAP」の2つの単語を組み合わせています。3つのうち2つを選ばなければならないとされるCAP定理のC (Consistency – 一貫性)、A (Availability – 可用性)、P (Partition Tolerance – ネットワーク分断への耐性) ですが、この3つの全てに接続したい (Ping) という思いが込められています。PingCAPの詳細については https://pingcap.co.jp をご覧ください。
本件に関するお問合わせ先
PingCAP株式会社 広報部
Email：pingcapjp@pingcap.com