重要

TiDB v6.2 (DMR) のドキュメントを表示しています。PingCap は v6.2 のバグ修正を提供していません。バグは将来のリリースで修正される予定です。

一般的な目的では、TiDBデータベースの最新の安定バージョンを使用してください。
重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

用語集

ACID

ACIDは、トランザクションの 4 つの主要なプロパティである原子性、一貫性、分離、および耐久性を指します。これらの各プロパティについて、以下で説明します。

  • 原子性とは、操作のすべての変更が実行されるか、またはまったく実行されないことを意味します。 TiDB は、トランザクションの原子性を実現するために、プライマリ キーを格納するリージョンの原子性を保証します。

  • 一貫性とは、トランザクションが常にデータベースをある一貫性のある状態から別の状態に移行することを意味します。 TiDB では、メモリにデータを書き込む前にデータの一貫性が保証されます。

  • 分離とは、処理中のトランザクションが完了するまで他のトランザクションから見えないことを意味します。これにより、同時トランザクションは一貫性を犠牲にすることなくデータの読み取りと書き込みを行うことができます。 TiDB は現在、分離レベルREPEATABLE READをサポートしています。

  • 永続性とは、トランザクションがコミットされると、システム障害が発生した場合でもコミットされたままになることを意味します。 TiKV は永続ストレージを使用して耐久性を確保します。

B

テーブルのバッチ作成

バッチ作成テーブルは、TiDB v6.0.0 で導入された機能です。この機能はデフォルトで有効になっています。 BR (バックアップと復元) を使用して多数のテーブル (約 50000) を含むデータを復元する場合、この機能はバッチでテーブルを作成することにより、復元プロセスを大幅に高速化できます。詳細については、 テーブルのバッチ作成を参照してください。

ベースラインのキャプチャ

Baseline Capture は、キャプチャ条件を満たすクエリをキャプチャし、それらのバインディングを作成します。 アップグレード中の実行計画の後退を防ぐに使用されます。

バケツ

リージョンは、バケットと呼ばれるいくつかの小さな範囲に論理的に分割されます。 TiKV はバケットごとにクエリ統計を収集し、バケットのステータスを PD に報告します。詳細はバケット設計ドキュメントを参照してください。

キャッシュされたテーブル

キャッシュ テーブル機能により、TiDB はテーブル全体のデータを TiDBサーバーのメモリにロードし、TiDB は TiKV にアクセスせずにテーブル データをメモリから直接取得するため、読み取りパフォーマンスが向上します。

継続的なプロファイリング

TiDB 5.3.0 で導入された継続的プロファイリングは、システム コール レベルでリソースのオーバーヘッドを観察する方法です。継続的プロファイリングのサポートにより、TiDB はデータベースのソース コードを直接調べるのと同じくらい明確なパフォーマンスの洞察を提供し、R&D および運用および保守担当者がフレーム グラフを使用してパフォーマンスの問題の根本原因を特定するのに役立ちます。詳細については、 TiDB ダッシュボード インスタンスのプロファイリング - 継続的なプロファイリングを参照してください。

D

動的剪定

動的プロニング モードは、TiDB が分割されたテーブルにアクセスするモードの 1 つです。動的プルーニング モードでは、各オペレーターは複数のパーティションへの直接アクセスをサポートします。そのため、TiDB は Union を使用しなくなりました。 Union 操作を省略すると、実行効率が向上し、Union 同時実行の問題を回避できます。

インデックス マージ

インデックス マージは、テーブルにアクセスするために TiDB v4.0 で導入された方法です。この方法を使用すると、TiDB オプティマイザーはテーブルごとに複数のインデックスを使用し、各インデックスから返された結果をマージできます。一部のシナリオでは、この方法を使用すると、テーブル全体のスキャンが回避されるため、クエリがより効率的になります。 v5.4 以降、Index Merge は GA 機能になりました。

インメモリ ペシミスティック ロック

インメモリ悲観的ロックは、TiDB v6.0.0 で導入された新機能です。この機能が有効になっている場合、ペシミスティック ロックは通常、リージョンリーダーのメモリにのみ保存され、ディスクに永続化されたり、 Raftを介して他のレプリカに複製されたりしません。この機能により、悲観的ロックを取得するオーバーヘッドが大幅に削減され、悲観的トランザクションのスループットが向上します。

L

リーダー/フォロワー/学習者

Leader/Follower/Learner はそれぞれRaftグループピアのロールに対応します。リーダーはすべてのクライアント リクエストに対応し、データをフォロワーにレプリケートします。グループのリーダーが失敗した場合、フォロワーの 1 人が新しいリーダーとして選出されます。学習者は投票権のないフォロワーであり、レプリカの追加のプロセスでのみ機能します。

古い値

TiCDC が出力する増分変更ログの「元の値」。 TiCDC が出力する増分変更ログに「元の値」が含まれているかどうかを指定できます。

オペレーター

オペレーターは、スケジュール目的でリージョンに適用されるアクションのコレクションです。オペレーターは、「リージョン2 のリーダーをストア 5 に移行する」や「リージョン2 のレプリカをストア 1、4、5 に移行する」などのスケジューリング タスクを実行します。

演算子は、 スケジューラーによって計算および生成されるか、外部 API によって作成されます。

オペレータステップ

オペレーター・ステップは、オペレーターの実行におけるステップです。通常、オペレーターには複数のオペレーター・ステップが含まれます。

現在、PD によって生成された使用可能なステップは次のとおりです。

  • TransferLeader : 指定されたメンバーにリーダーシップを譲渡します
  • AddPeer : 指定されたストアにピアを追加します
  • RemovePeer :リージョンのピアを削除します
  • AddLearner : 学習者を指定されたストアに追加します
  • PromoteLearner : 指定された学習者を投票メンバーに昇格させます
  • SplitRegion : 指定したリージョンを 2 つに分割します

P

保留中/ダウン

「保留中」と「ダウン」は、ピアの 2 つの特別な状態です。 Pending は、フォロワーまたは学習者のRaftログがリーダーのものと大きく異なることを示します。保留中のフォロワーはリーダーとして選出できません。 「ダウン」とは、ピアが長時間リーダーに応答しなくなった状態を指します。これは通常、対応するノードがダウンしているか、ネットワークから分離されていることを意味します。

述語列

ほとんどの場合、SQL ステートメントを実行するとき、オプティマイザーは一部の列 ( WHEREJOINORDER BY 、およびGROUP BYステートメントの列など) の統計のみを使用します。これらの使用される列は、述語列と呼ばれます。詳細については、 一部の列で統計を収集するを参照してください。

Q

クォータリミッター

Quota Limiter は、TiDB v6.0.0 で導入された実験的機能です。 TiKV が展開されているマシンのリソースが限られている場合 (たとえば、4v CPU と 16 G メモリのみ)、TiKV のフォアグラウンドで処理される読み取りおよび書き込み要求が多すぎると、バックグラウンドで使用される CPU リソースがそのような処理を支援するために占有されます。これは、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、 クォータ関連の構成アイテムを設定して、フォアグラウンドで使用される CPU リソースを制限します。

R

Raft Engine

Raft Engineは、ログ構造設計の組み込み永続ストレージ エンジンです。 TiKV がマルチ Raft ログを保存するために構築されています。 v5.4 以降、TiDB はRaft Engineをログ ストレージ エンジンとして使用することをサポートしています。詳細については、 Raft Engineを参照してください。

リージョン・ピア・Raftグループ

リージョンは、TiKV のデータ ストレージの最小部分であり、それぞれがデータの範囲を表します (デフォルトでは 96 MiB)。各リージョンには、デフォルトで 3 つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアがRaftコンセンサス アルゴリズムを介してデータをレプリケートするため、ピアはRaftインスタンスのメンバーでもあります。 TiKV は Multi-Raft を使用してデータを管理します。つまり、各リージョンには、対応する分離されたRaftグループがあります。

リージョン分割

データの書き込みが増えるとリージョンが生成されます。分割のプロセスは、リージョン分割と呼ばれます。

リージョン分割のメカニズムは、1 つの初期リージョンを使用してキー スペース全体をカバーし、リージョンのサイズまたはキーの数がしきい値に達するたびに、既存のリージョンを分割して新しいリージョンを生成することです。

戻す

復元は、バックアップ操作の逆です。これは、準備されたバックアップからデータを取得することによって、システムを以前の状態に戻すプロセスです。

S

スケジューラー

スケジューラは、スケジューリング タスクを生成する PD のコンポーネントです。 PD の各スケジューラは独立して実行され、さまざまな目的を果たします。一般的に使用されるスケジューラは次のとおりです。

  • balance-leader-scheduler : 引出線の分布のバランスをとる
  • balance-region-scheduler : ピアの分散のバランスをとる
  • hot-region-scheduler : ホット リージョンの分散のバランスをとる
  • evict-leader-{store-id} : ノードのすべてのリーダーを削除します (ローリング アップグレードによく使用されます)。

ストアとは、TiKV クラスター ( tikv-serverのインスタンス) 内のストレージ ノードを指します。各ストアには、対応する TiKV インスタンスがあります。

T

Top SQL

Top SQLは、指定された時間範囲で TiDB または TiKV ノードの高負荷に寄与する SQL クエリを見つけるのに役立ちます。詳細については、 Top SQLユーザー ドキュメントを参照してください。

TSO

TiKV は分散ストレージ システムであるため、単調に増加するタイムスタンプを割り当てるには、グローバル タイミング サービスである Timestamp Oracle (TSO) が必要です。 TiKV ではそのような機能は PD によって提供され、Google スパナではこの機能は複数の原子時計と GPS によって提供されます。