用語集

A

酸

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

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

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

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

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

B

テーブルのバッチ作成

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

ベースラインキャプチャ

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

バケツ

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

C

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

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

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

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

D

動的剪定

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

私

インデックスマージ

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

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

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

L

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

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

O

古い値

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

オペレーター

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

演算子は、 スケジューラーで計算および生成することも、外部APIで作成することもできます。

オペレーターステップ

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

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

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

P

保留中/ダウン

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

述語列

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

Q

クォータリミッター

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

R

Raft Engine

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

地域/ピア/いかだグループ

リージョンは、TiKVの最小のデータストレージであり、それぞれがデータの範囲（デフォルトでは96 MiB）を表します。各リージョンには、デフォルトで3つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアは、Raftコンセンサスアルゴリズムを介してデータを複製するため、ピアはRaftインスタンスのメンバーでもあります。 TiKVはマルチラフトを使用してデータを管理します。つまり、リージョンごとに、対応する孤立した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によって提供されます。