diff --git a/glossary.md b/glossary.md index 64bd21d66b48f..aff5cae1df4c6 100644 --- a/glossary.md +++ b/glossary.md @@ -37,25 +37,25 @@ BRは TiDB のバックアップおよび復元ツールです。詳細につい TiDBでは、 `br`はバックアップまたはリストアに使用される[br コマンドラインツール](/br/use-br-command-line-tool.md)です。 -### ベースラインキャプチャ {#baseline-capturing} +### ベースラインキャプチャ（Baseline Capturing） {#baseline-capturing} ベースラインキャプチャは、キャプチャ条件を満たすクエリをキャプチャし、それらのバインディングを作成します。これは、 [アップグレード中に実行プランの退行を防ぐ](/sql-plan-management.md#prevent-regression-of-execution-plans-during-an-upgrade)に使用されます。 -### バッチテーブル作成 {#batch-create-table} +### バッチテーブル作成（Batch Create Table） {#batch-create-table} バッチテーブル作成機能は、テーブルをバッチで作成することで、一度に複数のテーブルを作成する処理を大幅に高速化します。たとえば、 [Backup & Restore (BR)](/br/backup-and-restore-overview.md)ツールを使用して数千のテーブルを復元する場合、この機能は全体のリカバリ時間を短縮するのに役立ちます。詳細については、 [バッチテーブル作成](/br/br-batch-create-table.md)を参照してください。 -### バケット {#bucket} +### バケット（Bucket） {#bucket} [リージョン](#regionpeerraft-group)は論理的にバケットと呼ばれるいくつかの小さな範囲に分割されます。TiKV はバケットごとにクエリ統計を収集し、バケットの状態を PD に報告します。詳細については、 [バケット設計ドキュメント](https://github.com/tikv/rfcs/blob/master/text/0082-dynamic-size-region.md#bucket)を参照してください。 ## C {#c} -### キャッシュされたテーブル {#cached-table} +### キャッシュされたテーブル（Cached Table） {#cached-table} キャッシュテーブル機能を使用すると、TiDBはテーブル全体のデータをTiDBサーバーのメモリにロードし、TiKVにアクセスすることなくメモリから直接テーブルデータを取得するため、読み取りパフォーマンスが向上します。 -### クラスタ {#cluster} +### クラスタ（Cluster） {#cluster} クラスターとは、サービスを提供するために連携して動作するノードのグループです。分散システムにおいてクラスターを使用することで、TiDBは単一ノード構成と比較して、より高い可用性と優れた拡張性を実現します。 @@ -67,7 +67,7 @@ TiDBデータベースの分散アーキテクチャでは： 詳細については、 [TiDBアーキテクチャ](/tidb-architecture.md)を参照してください。 -### パーティションの結合 {#coalesce-partition} +### パーティションの結合（Coalesce Partition） {#coalesce-partition} パーティションの結合は、ハッシュまたはキーでパーティションテーブルのパーティション数を減らす方法です。詳細については、 [ハッシュとキーのパーティションを管理する](/partitioned-table.md#manage-hash-and-key-partitions)を参照してください。 @@ -79,11 +79,11 @@ RocksDBとTiKVでは、カラムファミリー（CF）は、データベース 共通テーブル式 (CTE) を使用すると、 [`WITH`](/sql-statements/sql-statement-with.md)句を使用して SQL ステートメント内で複数回参照できる一時的な結果セットを定義できます。これにより、ステートメントの可読性と実行効率が向上します。詳細については、 [共通テーブル式](/develop/dev-guide-use-common-table-expression.md)を参照してください。 -### 継続的なプロファイリング {#continuous-profiling} +### 継続的なプロファイリング（Continuous Profiling） {#continuous-profiling} 継続的プロファイリングは、システムコールレベルでのリソースオーバーヘッドを監視する方法です。継続的プロファイリングを使用すると、TiDB はパフォーマンスの問題をきめ細かく監視し、フレームグラフを使用して運用チームが根本原因を特定するのに役立ちます。詳細については、 [TiDB Dashboardインスタンスプロファイリング - 継続的プロファイリング](/dashboard/continuous-profiling.md)を参照してください。 -### コプロセッサー {#coprocessor} +### コプロセッサー（Coprocessor） {#coprocessor} コプロセッサーは、TiDBと計算ワークロードを共有するコプロセッシングメカニズムです。ストレージレイヤー（TiKVまたはTiFlash）に配置され、TiDBから[プッシュダウンされる](/functions-and-operators/expressions-pushed-down.md)計算をリージョンごとに共同で処理します。 @@ -119,7 +119,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ 分散実行フレームワーク (DXF) は、TiDB が特定のタスク (インデックスの作成やデータのインポートなど) を一元的にスケジュールし、分散的に実行するために使用するフレームワークです。DXF は、リソースの使用を制御し、コア業務トランザクションへの影響を軽減しながら、クラスタ リソースを効率的に使用するように設計されています。詳細については、 [DXFの概要](/tidb-distributed-execution-framework.md)を参照してください。 -### 動的プルーニング {#dynamic-pruning} +### 動的プルーニング（Dynamic Pruning） {#dynamic-pruning} 動的プルーニングモードは、TiDBがパーティションテーブルにアクセスするモードの1つです。動的プルーニングモードでは、各演算子が複数のパーティションへの直接アクセスをサポートします。そのため、TiDBはUnionを使用しなくなります。Union操作を省略することで、実行効率が向上し、Unionの同時実行による問題を回避できます。 @@ -147,7 +147,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ## H {#h} -### ホットスポット {#hotspot} +### ホットスポット（Hotspot） {#hotspot} ホットスポットとは、TiKV の読み取りおよび書き込みワークロードが 1 つまたは少数のリージョンまたはノードに集中している状況を指します。これによりパフォーマンスのボトルネックが発生し、最適なシステムパフォーマンスが妨げられる可能性があります。ホットスポットの問題を解決するには、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)を参照してください。 @@ -157,11 +157,11 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ## I {#i} -### インメモリ悲観的ロック {#in-memory-pessimistic-lock} +### インメモリ悲観的ロック（In-Memory Pessimistic Lock） {#in-memory-pessimistic-lock} インメモリ悲観的ロックは、TiDB v6.0.0 で導入された新機能です。この機能が有効になっている場合、悲観的ロックは通常、リージョンリーダーのメモリにのみ保存され、ディスクに永続化されたり、 Raftを介して他のレプリカに複製されたりすることはありません。この機能により、悲観的ロックの取得にかかるオーバーヘッドを大幅に削減し、悲観的トランザクションのスループットを向上させることができます。 -### インデックスマージ {#index-merge} +### インデックスマージ（Index Merge） {#index-merge} インデックスマージは、TiDB v4.0で導入されたテーブルアクセス方法です。この方法を使用すると、TiDBオプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返される結果をマージできます。場合によっては、この方法によってフルテーブルスキャンが回避され、クエリの効率が向上します。インデックスマージは、v5.4以降、一般提供（GA）機能となっています。 @@ -185,7 +185,7 @@ Raftグループ（ [仲間](#regionpeerraft-group)構成）では、Leader、Fo 軽量ディレクトリアクセスプロトコル (LDAP) は、情報を含むディレクトリにアクセスするための標準化された方法です。アカウントおよびユーザーデータの管理によく使用されます。TiDB は[LDAP認証プラグイン](/security-compatibility-with-mysql.md#authentication-plugin-status)を介して LDAP をサポートしています。 -### ロックビュー {#lock-view} +### ロックビュー（Lock View） {#lock-view} ロックビュー機能は、悲観的ロックにおけるロックの競合とロック待機に関する詳細情報を提供するため、DBAはトランザクションのロック状況を把握し、デッドロックの問題をトラブルシューティングするのに便利です。 @@ -207,7 +207,7 @@ TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP） ## O {#o} -### 元の値 {#old-value} +### 元の値（Old value） {#old-value} TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出力する増分変更ログに「元の値」を含めるかどうかを指定できます。 @@ -223,13 +223,13 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 メモリ不足 (OOM) は、メモリ不足によりシステムが故障する状況です。詳細については、 [TiDBのメモリ不足問題​​のトラブルシューティング](/troubleshoot-tidb-oom.md)を参照してください。 -### オペレーター {#operator} +### オペレーター（Operator） {#operator} オペレーターとは、スケジューリングの目的でリージョンに適用される一連のアクションのことです。オペレーターは、「リージョン2のリーダーをストア5に移行する」や「リージョン2のレプリカをストア1、4、5に移行する」といったスケジューリングタスクを実行します。 オペレーターは、 [スケジューラ](#scheduler)によって計算および生成されるか、外部 API によって作成されます。 -### オペレーターステップ {#operator-step} +### オペレーターステップ（Operator step） {#operator-step} オペレーターステップとは、オペレーターの実行における手順のことです。通常、1つのオペレーターは複数のオペレーターステップで構成されます。 @@ -242,7 +242,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 - `PromoteLearner` ：指定されたラーナーを投票権を持つメンバーに昇格させる - `SplitRegion` ：指定されたリージョンを2つに分割します -### 楽観的トランザクション {#optimistic-transaction} +### 楽観的トランザクション（Optimistic transaction） {#optimistic-transaction} 楽観的トランザクションとは、楽観的並行性制御を使用するトランザクションであり、一般的に並行環境で競合を引き起こしません。楽観的トランザクションを有効にすると、TiDB はトランザクションが最終的にコミットされたときにのみ競合チェックを行います。楽観的トランザクションモードは、読み取りが多く書き込みが少ない並行シナリオに適しており、TiDB のパフォーマンスを向上させることができます。 @@ -250,7 +250,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 ## P {#p} -### パーティショニング {#partitioning} +### パーティショニング（Partitioning） {#partitioning} [パーティショニング](/partitioned-table.md) 、テーブルを物理的に小さなテーブルパーティションに分割することを指し、これはRANGE、LIST、HASH、KEYパーティショニングなどのパーティション方式によって実行できます。 @@ -258,7 +258,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対話するために使用されるコマンドライン ツールです。これを使用して、クラスタの状態情報を取得したり、クラスタ構成を変更したりできます。詳細については、 [PD Controlユーザーガイド](/pd-control.md)を参照してください。 -### 保留中／ダウン中 {#pendingdown} +### 保留中／ダウン中（Pending/Down） {#pendingdown} 「保留中」と「ダウン」は、ピアの2つの特別な状態です。「保留中」とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。「ダウン」とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 @@ -266,7 +266,7 @@ PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対 Placement Driver(PD) は、メタデータの保存、トランザクション タイムスタンプの[タイムスタンプオラクル（TSO）](/tso.md) 、TiKV 上でのデータ配置の調整、および[TiDB Dashboard](/dashboard/dashboard-overview.md)実行を担当する[TiDBアーキテクチャ](/tidb-architecture.md#placement-driver-pd-server)の中核コンポーネントです。詳細については、 [TiDBスケジューリング](/tidb-scheduling.md)を参照してください。 -### 配置ルール {#placement-rules} +### 配置ルール（Placement Rules） {#placement-rules} 配置ルールは、TiKVクラスタにおけるデータの配置を設定するために使用されます。この機能を使用すると、テーブルとパーティションを異なるリージョン、データセンター、キャビネット、またはホストに展開するように指定できます。使用例としては、低コストでデータ可用性戦略を最適化すること、ローカルの古いデータの読み取りのためにローカルデータレプリカが利用可能であることを保証すること、およびローカルのデータコンプライアンス要件に準拠することなどが挙げられます。 @@ -280,7 +280,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ 特定時点復旧（PITR）を使用すると、データを特定の時点（たとえば、意図しない`DELETE`の直前）に復元できます。詳細については、 [TiDBログバックアップとPITRアーキテクチャ](/br/br-log-architecture.md)を参照してください。 -### 述語列 {#predicate-columns} +### 述語列（Predicate columns） {#predicate-columns} ほとんどの場合、SQL ステートメントを実行する際、オプティマイザは一部の列（ `WHERE` 、 `JOIN` 、 `ORDER BY` 、 `GROUP BY` ステートメントの列など）の統計情報のみを使用します。これらの使用される列は述語列と呼ばれます。詳細については、 [いくつかの列の統計情報を収集する](/statistics.md#collect-statistics-on-some-columns)を参照してください。 @@ -290,7 +290,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ 1秒あたりのクエリ数（QPS）とは、データベースサービスが1秒間に処理するクエリの数であり、データベースのスループットを示す重要なパフォーマンス指標です。 -### クォータリミッター {#quota-limiter} +### クォータリミッター（Quota Limiter） {#quota-limiter} クォータリミッターは、TiDB v6.0.0 で導入された実験的機能です。TiKV がデプロイされているマシンにリソース制限がある場合（例えば、CPU が 4V、メモリが 16GB しかない場合）、TiKV のフォアグラウンドが読み書き要求を過剰に処理すると、バックグラウンドで使用される CPU リソースがこれらの要求の処理に使用され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するために、クォータリミッターを[クォータ関連の設定項目](/tikv-configuration-file.md#quota)に設定して、フォアグラウンドで使用される CPU リソースを制限できます。 @@ -300,7 +300,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ Raft Engine は、ログ構造設計の組み込み型永続ストレージエンジンです。TiKV 用に構築されており、複数の Raft ログを保存します。v5.4 以降、TiDB はRaft Engine をログストレージエンジンとして使用することをサポートしています。詳細については、 [Raft Engine](/tikv-configuration-file.md#raft-engine)を参照してください。 -### リージョン分割 {#region-split} +### リージョン分割（Region Split） {#region-split} TiKVクラスタ内のリージョンは、最初は分割されておらず、データが書き込まれるにつれて徐々に分割されていきます。このプロセスはリージョン分割と呼ばれます。 @@ -318,7 +318,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ リクエストユニット（RU）は、TiDBにおけるリソース使用状況を統一的に抽象化した単位です。リソース使用状況を管理するために、 [リソース制御](/tidb-resource-control-ru-groups.md)と組み合わせて使用​​されます。 -### リストア {#restore} +### リストア（Restore） {#restore} リストアはバックアップ操作の逆の操作です。これは、事前に準備されたバックアップからデータを取得することで、システムを以前の状態に戻すプロセスです。 @@ -328,7 +328,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ## S {#s} -### スケジューラ {#scheduler} +### スケジューラ（Scheduler） {#scheduler} スケジューラはPDのコンポーネントであり、スケジューリングタスクを生成します。PDの各スケジューラは独立して動作し、それぞれ異なる目的を果たします。一般的に使用されるスケジューラは以下のとおりです。 @@ -343,7 +343,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ 詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)を参照してください。 -### ステイル読み取り {#stale-read} +### ステイル読み取り（Stale Read） {#stale-read} ステイル読み取りは、TiDBに保存されているデータの履歴バージョンを読み取るためにTiDBが適用するメカニズムです。このメカニズムを使用すると、特定の時点または指定された期間内の対応する履歴データを読み取ることができ、ストレージノード間のデータ複製によって発生するレイテンシーを削減できます。ステイル読み取りを使用する場合、TiDBはデータ読み取り用にレプリカをランダムに選択するため、すべてのレプリカがデータ読み取りに使用可能になります。 @@ -353,13 +353,13 @@ TiKV におけるデータストレージの最小単位はリージョンであ 静的ソートテーブルまたはソート文字列テーブルは、RocksDB（ [TiKV](/storage-engine/rocksdb-overview.md)で使用されているストレージエンジン）で使用されるファイルストレージ形式です。 -### ストア {#store} +### ストア（Store） {#store} ストアとは、TiKV クラスタ内のストレージノード (インスタンス`tikv-server` ) を指します。各ストアには、対応する TiKV インスタンスがあります。 ## T {#t} -### 一時テーブル {#temporary-table} +### 一時テーブル（Temporary table） {#temporary-table} 一時テーブルを使用すると、中間計算結果を一時的に保存できるため、テーブルの作成と削除を繰り返す必要がなくなります。データが不要になると、TiDB は一時テーブルを自動的にクリーンアップして再利用します。この機能により、アプリケーションロジックが簡素化され、テーブル管理のオーバーヘッドが削減され、パフォーマンスが向上します。 @@ -411,6 +411,6 @@ UUID（Universally Unique Identifier）は、データベース内のレコー ## V {#v} -### ベクトル検索 {#vector-search} +### ベクトル検索（Vector search） {#vector-search} [ベクトル検索](/ai/concepts/vector-search-overview.md)は、データの意味を優先して関連性の高い検索結果を提供する検索方法です。キーワードの完全一致や単語の出現頻度に依存する従来の全文検索とは異なり、ベクトル検索はテキスト、画像、音声などの様々なデータタイプを高次元ベクトルに変換し、これらのベクトルの類似性に基づいてクエリを実行します。この検索方法は、データの意味と文脈情報を捉え、ユーザーの意図をより正確に理解することを可能にします。検索語がデータベース内のコンテンツと完全に一致しない場合でも、ベクトル検索はデータの意味を分析することで、ユーザーの意図に沿った結果を提供できます。