diff --git a/ai/ti/reference/ti-configuration-and-credentials.md b/ai/ti/reference/ti-configuration-and-credentials.md
index 4f2170a708a41..796f296fccd1c 100644
--- a/ai/ti/reference/ti-configuration-and-credentials.md
+++ b/ai/ti/reference/ti-configuration-and-credentials.md
@@ -222,7 +222,7 @@ TI_TELEMETRY=off ti db list-db-clusters --db-cluster-type starter
TiDB Cloud CLI は、最初の対象イベントに対して `~/.ti/.telemetry-installation-id` を遅延作成し、POSIX 権限が利用可能な場合は現在のユーザーのみに制限します。仮名化された ID をリセットするには、このファイルを削除してください。テレメトリーの配信は損失を伴う可能性があり、コマンド出力、エラー、または終了ステータスを変更することはありません。
-統合は、プロファイルやコマンドを変更せずに、明示的なプロセススコープのメタデータを付加できます。`TI_TELEMETRY_TAG` は最大 128 バイトの UTF-8 文字列を受け付けます。`TI_TELEMETRY_EXTRA` は、圧縮後 2 KiB までの完全な JSON 値 1 つを受け付けます。無効なメタデータ、禁止されたメタデータ、深くネストされたメタデータ、またはサイズ超過のメタデータは、コマンドに影響を与えることなく省略されます。どちらの値にも、認証情報、トークン、SQL、パス、個人データ、プロファイル名、またはクラウドリソース ID を含めないでください。
+統合は、プロファイルやコマンドを変更せずに、明示的なプロセススコープのメタデータを付加できます。`TI_TELEMETRY_TAG` は最大 128 バイトの UTF-8 文字列を受け付けます。`TI_TELEMETRY_EXTRA` は、JSON をコンパクト化した後のサイズが 2 KiB 以下の完全な JSON 値 1 つを受け付けます。無効なメタデータ、禁止されたメタデータ、深くネストされたメタデータ、またはサイズ超過のメタデータは、コマンドに影響を与えることなく省略されます。どちらの値にも、認証情報、トークン、SQL、パス、個人データ、プロファイル名、またはクラウドリソース ID を含めないでください。
```bash
TI_TELEMETRY_TAG="e2b-preview" \
diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
index b8653cf468744..b4518d4401fa4 100644
--- a/best-practices/best-practices-on-public-cloud.md
+++ b/best-practices/best-practices-on-public-cloud.md
@@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/best-practices-on-public-cloud/']
このドキュメントでは、KV RocksDB におけるコンパクション I/O フローの削減、 Raft Engine専用ディスクの使用、AZ 間トラフィックのコスト最適化、Google Cloud ライブマイグレーションイベントの軽減、大規模クラスタにおける PDサーバーの微調整など、パブリッククラウドへの TiDB の導入に関する様々な重要なベストプラクティスを解説します。これらのベストプラクティスに従うことで、パブリッククラウドにおける TiDB 導入のパフォーマンス、コスト効率、信頼性、スケーラビリティを最大限に高めることができます。
-## KV RocksDB の圧縮 I/O フローを削減 {#reduce-compaction-i-o-flow-in-kv-rocksdb}
+## KV RocksDB のコンパクション I/O フローを削減 {#reduce-compaction-i-o-flow-in-kv-rocksdb}
TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/)は、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。
@@ -20,7 +20,7 @@ TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/)は、
[Titan](/storage-engine/titan-overview.md)は、キーと値の分離のための高性能な[RocksDB](https://github.com/facebook/rocksdb)プラグインであり、大きな値が使用されるときに RocksDB での書き込み増幅を減らすことができます。
-平均行サイズが 512 バイトより大きい場合は、次のように`min-blob-size`を`"512B"`または`"1KB"`に設定し、 `blob-file-compression`を`"zstd"`に設定して、Titan による圧縮 I/O フローの削減を有効にすることができます。
+平均行サイズが 512 バイトより大きい場合は、次のように`min-blob-size`を`"512B"`または`"1KB"`に設定し、 `blob-file-compression`を`"zstd"`に設定して、Titan によるコンパクション I/O フローの削減を有効にすることができます。
```toml
[rocksdb.titan]
diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md
index 4679f90977f90..70a8044c33a5a 100644
--- a/best-practices/three-nodes-hybrid-deployment.md
+++ b/best-practices/three-nodes-hybrid-deployment.md
@@ -84,7 +84,7 @@ TiKVはフォアグラウンドタスクに加えて、バックグラウンド
RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。 `rocksdb.max-background-jobs`のデフォルト値は`8`であり、明らかに必要なリソースを超えています。したがって、リソース使用量を制限するために値を調整する必要があります。
-`rocksdb.max-sub-compactions`は、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。
+`rocksdb.max-sub-compactions`は、単一のコンパクションジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。
このテストでは、 `rocksdb.max-background-jobs`の値は`3`に、 `rocksdb.max-sub-compactions`の値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。
@@ -93,7 +93,7 @@ RocksDBスレッドプールは、コンパクションジョブとフラッシ
#### `rocksdb.rate-bytes-per-sec` {#rocksdb-rate-bytes-per-sec}
-このパラメータは、バックグラウンド圧縮ジョブのディスクトラフィックを制限するために使用されます。デフォルト設定では、このパラメータに制限はありません。圧縮ジョブがフォアグラウンドサービスのリソースを占有する状況を回避するには、ディスクのシーケンシャル読み取りおよび書き込み速度に応じてこのパラメータ値を調整し、フォアグラウンドサービスに十分なディスク帯域幅を確保します。
+このパラメータは、バックグラウンドコンパクションジョブのディスクトラフィックを制限するために使用されます。デフォルト設定では、このパラメータに制限はありません。コンパクションジョブがフォアグラウンドサービスのリソースを占有する状況を回避するには、ディスクのシーケンシャル読み取りおよび書き込み速度に応じてこのパラメータ値を調整し、フォアグラウンドサービスに十分なディスク帯域幅を確保します。
RocksDBスレッドプールの最適化方法は、コンパクションスレッドプールの最適化方法と似ています。調整した値が適切かどうかは、書き込みストールが発生するかどうかで判断できます。
diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md
index e465d67525164..e08be119761e4 100644
--- a/br/br-compact-log-backup.md
+++ b/br/br-compact-log-backup.md
@@ -1,42 +1,42 @@
---
title: Compact Log Backup
-summary: ログバックアップを SST 形式に圧縮することで、ポイントインタイムリカバリ (PITR) の効率を向上させる方法を学習します。
+summary: ログバックアップを SST 形式にコンパクションすることで、ポイントインタイムリカバリ (PITR) の効率を向上させる方法を学習します。
---
# コンパクトログバックアップ {#compact-log-backup}
-このドキュメントでは、ログバックアップを[SST](/glossary.md#static-sorted-table--sorted-string-table-sst)形式に圧縮することで、ポイントインタイムリカバリ ( [PITR](/glossary.md#point-in-time-recovery-pitr) ) の効率を向上させる方法について説明します。
+このドキュメントでは、ログバックアップを[SST](/glossary.md#static-sorted-table--sorted-string-table-sst)形式にコンパクションすることで、ポイントインタイムリカバリ ( [PITR](/glossary.md#point-in-time-recovery-pitr) ) の効率を向上させる方法について説明します。
## 概要 {#overview}
従来のログバックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。
- **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1つずつ書き込む必要があります。
-- **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。
+- **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとにコンパクションする必要があります。
- **完全バックアップへの依存**: リカバリ データの量を制御するには、頻繁な完全バックアップが必要であり、アプリケーションの操作に影響を及ぼす可能性があります。
バージョン8.5.5以降、コンパクトログバックアップ機能にオフラインコンパクション機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善がもたらされます。
- SST ファイルをクラスターに迅速にインポートできるため、**リカバリ パフォーマンスが向上します**。
-- 圧縮中に冗長データが削除され、**ストレージスペースの消費量が削減されます**。
+- コンパクション中に冗長データが削除され、**ストレージスペースの消費量が削減されます**。
- リカバリ時間目標 (RTO) を確保しながら、より長い完全バックアップ間隔を設定できるため、**アプリケーションへの影響を軽減できます**。
## 制限事項 {#limitations}
-- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、ストレージ使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。
-- 現在、ローカル暗号化を有効にしたバックアップの圧縮はサポートされていません。
+- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、コンパクションプロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、ストレージ使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。
+- 現在、ローカル暗号化を有効にしたバックアップのコンパクションはサポートされていません。
## コンパクトログバックアップを使用する {#use-compact-log-backup}
-現在、ログバックアップの圧縮は手動でのみサポートされており、プロセスは複雑です。**本番環境でのログバックアップの圧縮には、今後リリースされるTiDB Operatorソリューションのご利用をお勧めします。**
+現在、ログバックアップのコンパクションは手動でのみサポートされており、プロセスは複雑です。**本番環境でのログバックアップのコンパクションには、今後リリースされるTiDB Operatorソリューションのご利用をお勧めします。**
-### 手作業による圧縮 {#manual-compaction}
+### 手作業によるコンパクション {#manual-compaction}
-このセクションでは、ログバックアップを手動で圧縮する手順について説明します。
+このセクションでは、ログバックアップを手動でコンパクションする手順について説明します。
#### 前提条件 {#prerequisites}
-ログバックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2つのツールが必要です。
+ログバックアップを手動でコンパクションするには、 `tikv-ctl`と`br` 2つのツールが必要です。
#### ステップ1:ストレージをBase64でエンコードする {#step-1-encode-storage-to-base64}
@@ -51,9 +51,9 @@ br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds
> - 上記のコマンドを実行する際にオプション`--load-creds`を指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。
> - `--storage`の値は、ログバックアップタスクの`log status`コマンドの出力と一致させることを推奨します。
-#### ステップ2: ログ圧縮を実行する {#step-2-execute-log-compaction}
+#### ステップ2: ログコンパクションを実行する {#step-2-execute-log-compaction}
-前の手順でBase64エンコードされた文字列を取得したら、`tikv-ctl`を使用して圧縮を開始できます。デフォルトでは、`tikv-ctl`のログレベルは`warning`です。より詳細な情報を取得するには、`--log-level info`を使用してください。
+前の手順でBase64エンコードされた文字列を取得したら、`tikv-ctl`を使用してコンパクションを開始できます。デフォルトでは、`tikv-ctl`のログレベルは`warning`です。より詳細な情報を取得するには、`--log-level info`を使用してください。
```shell
tikv-ctl --log-level info compact-log-backup \
@@ -64,11 +64,11 @@ tikv-ctl --log-level info compact-log-backup \
パラメータの説明:
- `-s` : 前の手順で取得したBase64エンコード文字列。
-- `-N` : 同時ログ圧縮タスクの最大数。
-- `--from` : 圧縮の開始タイムスタンプ。
-- `--until` : 圧縮の終了タイムスタンプ。
+- `-N` : 同時ログコンパクションタスクの最大数。
+- `--from` : コンパクションの開始タイムスタンプ。
+- `--until` : コンパクションの終了タイムスタンプ。
-パラメータ`--from`と`--until`は、圧縮操作の時間範囲を定義します。圧縮操作では、指定された時間範囲内の書き込み操作を含むすべてのログファイルが処理されるため、生成されるSSTファイルにはこの範囲外のデータが含まれる場合があります。
+パラメータ`--from`と`--until`は、コンパクション操作の時間範囲を定義します。コンパクション操作では、指定された時間範囲内の書き込み操作を含むすべてのログファイルが処理されるため、生成されるSSTファイルにはこの範囲外のデータが含まれる場合があります。
特定の時点のタイムスタンプを取得するには、次のコマンドを実行します。
diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md
index 901288f534814..eaf230c230aff 100644
--- a/dashboard/dashboard-monitoring.md
+++ b/dashboard/dashboard-monitoring.md
@@ -114,7 +114,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤
- `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度
- `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度
- `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ
-- `RocksDB Compaction` : RocksDBの圧縮操作によって生成された合計読み取りおよび書き込みI/Oフロー
+- `RocksDB Compaction` : RocksDBのコンパクション操作によって生成された合計読み取りおよび書き込みI/Oフロー
### Duration {#duration}
diff --git a/dynamic-config.md b/dynamic-config.md
index a9e6451b2ab52..c4d58dc90af67 100644
--- a/dynamic-config.md
+++ b/dynamic-config.md
@@ -129,8 +129,8 @@ show warnings;
| `raftstore.pd-store-heartbeat-tick-interval` | ストアのPDへのハートビートがトリガーされる時間間隔 |
| `raftstore.snap-mgr-gc-tick-interval` | 期限切れのスナップショットファイルのリサイクルがトリガーされる時間間隔 |
| `raftstore.snap-gc-timeout` | スナップショットファイルが保存される最長時間 |
-| `raftstore.lock-cf-compact-interval` | TiKVがロックカラムファミリーの手動圧縮をトリガーする時間間隔 |
-| `raftstore.lock-cf-compact-bytes-threshold` | TiKVがロックカラムファミリーの手動圧縮をトリガーするサイズ |
+| `raftstore.lock-cf-compact-interval` | TiKVがロックカラムファミリーの手動コンパクションをトリガーする時間間隔 |
+| `raftstore.lock-cf-compact-bytes-threshold` | TiKVがロックカラムファミリーの手動コンパクションをトリガーするサイズ |
| `raftstore.messages-per-tick` | バッチごとに処理されるメッセージの最大数 |
| `raftstore.max-peer-down-duration` | ピアに許可される最長の非アクティブ期間 |
| `raftstore.max-leader-missing-duration` | ピアがリーダーなしでいられる最長時間。この値を超えると、ピアはPDを使用して、自身が削除されたかどうかを確認します。 |
@@ -148,7 +148,7 @@ show warnings;
| `raftstore.apply-max-batch-size` | Raftステートマシンは、BatchSystemによってデータ書き込みリクエストをバッチ処理します。この設定項目は、1バッチでリクエストを実行できるRaftステートマシンの最大数を指定します。 |
| `raftstore.store-max-batch-size` | Raftステートマシンは、BatchSystemによってログをディスクにフラッシュするリクエストをバッチ処理します。この設定項目は、1回のバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 |
| `raftstore.store-io-pool-size` | Raft I/Oタスクを処理するスレッドの数。これは StoreWriter スレッドプールのサイズでもあります (この値を 0 以外の値から 0 に、または 0 から 0 以外の値に変更**しないでください**) |
-| `raftstore.periodic-full-compact-start-max-cpu` | 完全圧縮が有効な場合に TiKV が定期的に完全圧縮を実行する CPU 使用率のしきい値 |
+| `raftstore.periodic-full-compact-start-max-cpu` | 完全コンパクションが有効な場合に TiKV が定期的に完全コンパクションを実行する CPU 使用率のしきい値 |
| `readpool.unified.max-thread-count` | 読み取りリクエストを均一に処理するスレッドプール内のスレッドの最大数。これは UnifyReadPool スレッドプールのサイズです。 |
| `readpool.unified.max-tasks-per-worker` | 統合読み取りプール内の 1つのスレッドに許可されるタスクの最大数。値を超えると`Server Is Busy`エラーが返されます。 |
| `readpool.unified.auto-adjust-pool-size` | UnifyReadPool スレッドプールのサイズを自動的に調整するかどうかを決定します |
@@ -176,19 +176,19 @@ show warnings;
| `gc.ratio-threshold` | リージョンGCをスキップするしきい値（GCのバージョン数/キーの数） |
| `gc.batch-keys` | 1バッチで処理されるキーの数 |
| `gc.max-write-bytes-per-sec` | RocksDBに1秒あたり書き込める最大バイト数 |
-| `gc.enable-compaction-filter` | 圧縮フィルタを有効にするかどうか |
-| `gc.compaction-filter-skip-version-check` | 圧縮フィルタのクラスタバージョンチェックをスキップするかどうか（未リリース） |
-| `gc.auto-compaction.check-interval` | TiKVが自動（RocksDB）圧縮をトリガーするかどうかを確認する間隔 |
-| `gc.auto-compaction.tombstone-num-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要なRocksDBのtombstoneの数 |
-| `gc.auto-compaction.tombstone-percent-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要なRocksDBのtombstoneの割合 |
-| `gc.auto-compaction.redundant-rows-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要な冗長MVCC行の数 |
-| `gc.auto-compaction.redundant-rows-percent-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要な冗長MVCC行の割合 |
-| `gc.auto-compaction.bottommost-level-force` | RocksDBの最下層ファイルの圧縮を強制するかどうか |
+| `gc.enable-compaction-filter` | コンパクションフィルタを有効にするかどうか |
+| `gc.compaction-filter-skip-version-check` | コンパクションフィルタのクラスタバージョンチェックをスキップするかどうか（未リリース） |
+| `gc.auto-compaction.check-interval` | TiKVが自動（RocksDB）コンパクションをトリガーするかどうかを確認する間隔 |
+| `gc.auto-compaction.tombstone-num-threshold` | TiKV自動（RocksDB）コンパクションをトリガーするために必要なRocksDBのtombstoneの数 |
+| `gc.auto-compaction.tombstone-percent-threshold` | TiKV自動（RocksDB）コンパクションをトリガーするために必要なRocksDBのtombstoneの割合 |
+| `gc.auto-compaction.redundant-rows-threshold` | TiKV自動（RocksDB）コンパクションをトリガーするために必要な冗長MVCC行の数 |
+| `gc.auto-compaction.redundant-rows-percent-threshold` | TiKV自動（RocksDB）コンパクションをトリガーするために必要な冗長MVCC行の割合 |
+| `gc.auto-compaction.bottommost-level-force` | RocksDBの最下層ファイルのコンパクションを強制するかどうか |
| `{db-name}.max-total-wal-size` | 合計WALの最大サイズ |
| `{db-name}.max-background-jobs` | RocksDBのバックグラウンドスレッドの数 |
| `{db-name}.max-background-flushes` | RocksDBのフラッシュスレッドの最大数 |
| `{db-name}.max-open-files` | RocksDBが開くことができるファイルの総数 |
-| `{db-name}.compaction-readahead-size` | 圧縮時のサイズ`readahead` |
+| `{db-name}.compaction-readahead-size` | コンパクション時のサイズ`readahead` |
| `{db-name}.bytes-per-sync` | ファイルが非同期的に書き込まれている間に、OSがファイルをディスクに増分的に同期する速度 |
| `{db-name}.wal-bytes-per-sync` | WAL ファイルが書き込まれている間に OS が WAL ファイルをディスクに増分的に同期する速度 |
| `{db-name}.writable-file-max-buffer-size` | WritableFileWriteで使用される最大バッファサイズ |
@@ -197,14 +197,14 @@ show warnings;
| `{db-name}.{cf-name}.max-write-buffer-number` | メンバーテーブルの最大数 |
| `{db-name}.{cf-name}.max-bytes-for-level-base` | ベースレベル（L1）の最大バイト数 |
| `{db-name}.{cf-name}.target-file-size-base` | ベースレベルのターゲットファイルのサイズ |
-| `{db-name}.{cf-name}.level0-file-num-compaction-trigger` | 圧縮をトリガーするL0のファイルの最大数 |
+| `{db-name}.{cf-name}.level0-file-num-compaction-trigger` | コンパクションをトリガーするL0のファイルの最大数 |
| `{db-name}.{cf-name}.level0-slowdown-writes-trigger` | 書き込み停止を引き起こすL0のファイルの最大数 |
| `{db-name}.{cf-name}.level0-stop-writes-trigger` | 書き込みを完全にブロックするL0のファイルの最大数 |
-| `{db-name}.{cf-name}.max-compaction-bytes` | 圧縮ごとにディスクに書き込まれる最大バイト数 |
+| `{db-name}.{cf-name}.max-compaction-bytes` | コンパクションごとにディスクに書き込まれる最大バイト数 |
| `{db-name}.{cf-name}.max-bytes-for-level-multiplier` | 各レイヤーのデフォルトの増幅倍数 |
-| `{db-name}.{cf-name}.disable-auto-compactions` | 自動圧縮を有効または無効にする |
-| `{db-name}.{cf-name}.soft-pending-compaction-bytes-limit` | 保留中の圧縮バイトのソフト制限 |
-| `{db-name}.{cf-name}.hard-pending-compaction-bytes-limit` | 保留中の圧縮バイトのハード制限 |
+| `{db-name}.{cf-name}.disable-auto-compactions` | 自動コンパクションを有効または無効にする |
+| `{db-name}.{cf-name}.soft-pending-compaction-bytes-limit` | 保留中のコンパクションバイトのソフト制限 |
+| `{db-name}.{cf-name}.hard-pending-compaction-bytes-limit` | 保留中のコンパクションバイトのハード制限 |
| `{db-name}.{cf-name}.titan.blob-run-mode` | BLOBファイルの処理モード |
| `{db-name}.{cf-name}.titan.min-blob-size` | Titan にデータを保存するしきい値。このしきい値に達すると、データは Titan BLOB ファイルに保存されます。 |
| `{db-name}.{cf-name}.titan.blob-file-compression` | Titan BLOBファイルで使用される圧縮アルゴリズム |
@@ -220,8 +220,8 @@ show warnings;
| storage.flow-control.enable | フロー制御メカニズムを有効にするかどうかを決定します |
| storage.flow-control.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 |
| storage.flow-control.l0-files-threshold | フロー制御をトリガーするkvDB L0ファイルの最大数 |
-| storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込みリクエストを拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 |
-| storage.flow-control.hard-pending-compaction-bytes-limit | フロー制御メカニズムがすべての書き込みリクエストを拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 |
+| storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込みリクエストを拒否するトリガーとなる、kvDB保留コンパクションバイトのしきい値 |
+| storage.flow-control.hard-pending-compaction-bytes-limit | フロー制御メカニズムがすべての書き込みリクエストを拒否するトリガーとなる、kvDB保留コンパクションバイトのしきい値 |
| `storage.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 |
| `import.num-threads` | 復元またはインポート RPC リクエストを処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) |
| `backup.num-threads` | バックアップ スレッドの数 (v4.0.3 以降でサポート) |
diff --git a/encryption-at-rest.md b/encryption-at-rest.md
index 644d91def7f32..f90c3ec9ab48b 100644
--- a/encryption-at-rest.md
+++ b/encryption-at-rest.md
@@ -62,7 +62,7 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー
あるいは、カスタムキーを使用したい場合は、ファイル経由でマスターキーを提供することもできます。ファイルには、16進文字列としてエンコードされた256ビット（32バイト）のキーが含まれ、改行文字（つまり`\n` ）で終了し、他に何も含まれていない必要があります。ただし、キーをディスクに保存するとキーが漏洩するため、キーファイルはRAMの`tempfs`に保存するのに適しています。
-データキーは、基盤となるストレージエンジン（RocksDB）に渡されます。SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーで暗号化されます。TiKVが使用するその他の一時ファイル（ユーザーデータが含まれる場合がある）も、同じデータキーを使用して暗号化されます。データキーは、デフォルトではTiKVによって毎週自動的にローテーションされますが、期間は設定可能です。キーのローテーションでは、TiKVは既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、RocksDBの圧縮機能によって、最新のデータキーを使用して古いデータが新しいデータファイルに書き換えられることが期待されます。TiKVは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。
+データキーは、基盤となるストレージエンジン（RocksDB）に渡されます。SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーで暗号化されます。TiKVが使用するその他の一時ファイル（ユーザーデータが含まれる場合がある）も、同じデータキーを使用して暗号化されます。データキーは、デフォルトではTiKVによって毎週自動的にローテーションされますが、期間は設定可能です。キーのローテーションでは、TiKVは既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、RocksDBのコンパクション機能によって、最新のデータキーを使用して古いデータが新しいデータファイルに書き換えられることが期待されます。TiKVは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。
データ暗号化方式に関わらず、データキーはGCMモードでAES256を使用して暗号化され、追加の認証を行います。そのため、KMSではなくファイルから渡す場合、マスターキーは256ビット（32バイト）である必要があります。
@@ -298,7 +298,7 @@ TiFlashが現在サポートしている暗号化アルゴリズムは、TiKVが
同じマスターキーを複数のTiFlashインスタンスで共有できるほか、 TiFlashと TiKV 間で共有することもできます。本番でマスターキーを提供する場合は、AWS KMS を使用することをお勧めします。また、カスタムキーを使用したい場合は、ファイル経由でマスターキーを提供することも可能です。マスターキーの生成方法とフォーマットは TiKV と同じです。
-TiFlash は、データファイル、スキーマファイル、計算中に生成される一時データファイルなど、ディスク上に配置されるすべてのデータを、現在のデータキーを使用して暗号化します。データキーは、 TiFlashによってデフォルトで毎週自動的にローテーションされます。ローテーションの周期は設定可能です。キーローテーションでは、 TiFlash は既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、バックグラウンドの圧縮タスクによって古いデータが最新のデータキーを使用して新しいデータファイルに書き換えられることが想定されます。TiFlashは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。
+TiFlash は、データファイル、スキーマファイル、計算中に生成される一時データファイルなど、ディスク上に配置されるすべてのデータを、現在のデータキーを使用して暗号化します。データキーは、 TiFlashによってデフォルトで毎週自動的にローテーションされます。ローテーションの周期は設定可能です。キーローテーションでは、 TiFlash は既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、バックグラウンドのコンパクションタスクによって古いデータが最新のデータキーを使用して新しいデータファイルに書き換えられることが想定されます。TiFlashは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。
### キーの作成 {#key-creation}
diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md
index 26170a51d8e35..7299cdd010ff0 100644
--- a/faq/manage-cluster-faq.md
+++ b/faq/manage-cluster-faq.md
@@ -353,7 +353,7 @@ TiKVで大量のデータを書き込んだり読み込んだりすると、I/O
### TiKVはSAS/SATAディスク、またはSSD/SASディスクの混在構成をサポートしていますか？ {#does-tikv-support-sas-sata-disks-or-mixed-deployment-of-ssd-sas-disks}
-いいえ。OLTPシナリオでは、TiDBはデータアクセスと操作に高I/Oディスクを必要とします。TiDBは強力な一貫性を備えた分散データベースであり、レプリカレプリケーションやボトムレイヤーストレージの圧縮など、書き込み増幅機能を備えています。そのため、TiDBのベストプラクティスでは、ストレージディスクとしてNVMe SSDの使用を推奨しています。TiKVとPDの混在デプロイはサポートされていません。
+いいえ。OLTPシナリオでは、TiDBはデータアクセスと操作に高I/Oディスクを必要とします。TiDBは強力な一貫性を備えた分散データベースであり、レプリカレプリケーションやボトムレイヤーストレージのコンパクションなど、書き込み増幅機能を備えています。そのため、TiDBのベストプラクティスでは、ストレージディスクとしてNVMe SSDの使用を推奨しています。TiKVとPDの混在デプロイはサポートされていません。
### キーデータテーブルの範囲は、データアクセス前に分割されますか？ {#is-the-range-of-the-key-data-table-divided-before-data-access}
diff --git a/faq/sql-faq.md b/faq/sql-faq.md
index 7f552c0848511..1114ac4818878 100644
--- a/faq/sql-faq.md
+++ b/faq/sql-faq.md
@@ -180,7 +180,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意
## TiDB はデータを削除した直後にスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data}
-`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。
+`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、コンパクションが実行されるまで領域は即時に解放されません。
## データを削除するとクエリ速度が遅くなるのはなぜですか? {#why-does-the-query-speed-get-slow-after-data-is-deleted}
diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md
index 1feb63b722a45..4aef2641d49d1 100644
--- a/garbage-collection-configuration.md
+++ b/garbage-collection-configuration.md
@@ -50,7 +50,7 @@ TiDB v6.1.0より前のバージョンでは、TiDBのトランザクション
TiDB v6.1.0では、アクティブなトランザクションがGCセーフポイントをブロックする最大時間を制御するためのシステム変数[`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610)が導入されました。この値を超えると、GCセーフポイントは強制的に転送されます。
-### 圧縮フィルターのGC {#gc-in-compaction-filter}
+### コンパクションフィルターのGC {#gc-in-compaction-filter}
`DISTRIBUTED` GCモードをベースに、Compaction FilterのGCメカニズムは、独立したGCワーカースレッドではなく、RocksDBのコンパクションプロセスを利用してGCを実行します。この新しいGCメカニズムは、GCによる余分なディスク読み取りを回避するのに役立ちます。また、古いデータをクリアした後、シーケンシャルスキャンのパフォーマンスを低下させる大量のtombstoneマークが残るのを防ぎます。
@@ -104,7 +104,7 @@ show config where type = 'tikv' and name like '%enable-compaction-filter%';
> **Note:**
>
-> 圧縮フィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、[**TiKV-Details > Coprocessor Detail**](/grafana-tikv-dashboard.md#coprocessor-detail)パネルで**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。
+> コンパクションフィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、[**TiKV-Details > Coprocessor Detail**](/grafana-tikv-dashboard.md#coprocessor-detail)パネルで**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。
>
> - v7.1.3 より前の TiDB バージョンでは、GC を高速化するために Compaction Filter を無効にすることをお勧めします。
> - TiDBバージョンv7.1.3からv7.5.6およびv7.6.0からv8.5.3では、TiDBは各リージョン[`region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710)の冗長バージョンの数と冗長バージョン[`region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710)の割合に基づいて自動的にコンパクションをトリガーし、コンパクションフィルタGCのパフォーマンスを向上させます。この場合、コンパクションフィルタを無効にするのではなく、これらの設定項目を調整してください。
diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md
index 5479f537a66dc..f48c7956d34e6 100644
--- a/grafana-tikv-dashboard.md
+++ b/grafana-tikv-dashboard.md
@@ -191,7 +191,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示
- Throttle duration：L0ファイルが多すぎるためにフロー制御がトリガーされた場合に、スケジューラリクエストの実行がブロックされる期間。このメトリックに値がある場合、フロー制御が存在していることを示します。
- Scheduler throttled CF：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするCF。
- Flow controller actions：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするアクション。
-- Flush/L0 flow：各TiKVインスタンス上のRocksDBの異なるCFにおけるフラッシュとL0圧縮のトラフィック。
+- Flush/L0 flow：各TiKVインスタンス上のRocksDBの異なるCFにおけるフラッシュとL0コンパクションのトラフィック。
- Flow control factors：RocksDBのスロットリングをトリガーする要因。
- Compaction pending bytes：各TiKVインスタンスでリアルタイムにコンパクション待ち状態にあるRocksDBデータのサイズ。
- Txn command throttled duration：スロットリングによりトランザクションに関連するコマンドがブロックされた期間。通常、このメトリックは0です。
@@ -329,10 +329,10 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示
- WAL sync operations：1秒あたりのWAL同期操作の回数
- Write WAL duration：WALの書き込みに要した時間
- WAL sync duration：WAL同期操作の実行に要する時間
-- Compaction operations：1秒あたりの圧縮および洗浄作業の回数
-- Compaction duration：圧縮および洗浄作業の実行に要する時間
+- Compaction operations：1秒あたりのコンパクションおよびフラッシュ作業の回数
+- Compaction duration：コンパクションおよびフラッシュ作業の実行に要する時間
- SST read duration：SSTファイルの読み込みに要する時間
-- Write stall duration: 停止時間を書き込む。通常の場合は`0`となるはずです。
+- Write stall duration: 書き込みストールの時間。通常の場合は`0`となるはずです。
- Memtable size：各カラムファミリーのmemtableサイズ
- Memtable hit：memtableのヒット率
- Block cache size：ブロックキャッシュのサイズ。共有ブロックキャッシュが無効になっている場合は、カラムファミリーごとに内訳が表示されます。
@@ -345,9 +345,9 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示
- Bytes / Read：読み取り操作1回あたりのバイト数
- Write flow：タイプごとの書き込み操作のフローレート
- Bytes / Write: 書き込み操作あたりのバイト数
-- Compaction flow：タイプ別の圧縮作業のフローレート
-- Compaction pending bytes：圧縮対象となる保留バイト数
-- Compaction Job Size(files)：単一の圧縮ジョブに関係するSSTファイルの数
+- Compaction flow：タイプ別のコンパクション作業のフローレート
+- Compaction pending bytes：コンパクション対象となる保留バイト数
+- Compaction Job Size(files)：単一のコンパクションジョブに関係するSSTファイルの数
- Read amplification: TiKVインスタンスごとのリード増幅率
- Compression ratio：各レベルの圧縮率
- Number of snapshots：TiKVインスタンスごとのスナップショット数
@@ -375,7 +375,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示
- WAL Duration Breakdown (P99%): Raft Engine WAL 作成の各段階に要した時間
- File Count
- append: Raft Engineがデータ追加に使用するファイルの数
- - rewrite: Raft Engineによるデータ書き換えに使用されるファイルの数（rewriteはRocksDBの圧縮に類似しています）
+ - rewrite: Raft Engineによるデータ書き換えに使用されるファイルの数（rewriteはRocksDBのコンパクションに類似しています）
- Entry Count
- rewrite: Raft Engineによって書き換えられたエントリの数
- append: Raft Engineによって追加されたエントリの数
diff --git a/pd-configuration-file.md b/pd-configuration-file.md
index 1daba21dd9fb2..358ce7024d21c 100644
--- a/pd-configuration-file.md
+++ b/pd-configuration-file.md
@@ -87,13 +87,13 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの
### `auto-compaction-mod` {#auto-compaction-mod}
-- メタ情報データベースの自動圧縮モード
+- メタ情報データベースの自動コンパクションモード
- 使用可能なオプション: `periodic` (サイクル別) および`revision` (バージョン番号別)。
- デフォルト値: `periodic`
### `auto-compaction-retention` {#auto-compaction-retention}
-- `auto-compaction-retention`が`periodic`の場合、メタ情報データベースの自動圧縮の間隔。圧縮モードが`revision`に設定されている場合、このパラメータは自動圧縮のバージョン番号を示します。
+- `auto-compaction-retention`が`periodic`の場合、メタ情報データベースの自動コンパクションの間隔。コンパクションモードが`revision`に設定されている場合、このパラメータは自動コンパクションのバージョン番号を示します。
- デフォルト値: 1時間
### `tick-interval` {#tick-interval}
diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md
index 2c2fb557dff64..fab924754dc4d 100644
--- a/performance-tuning-methods.md
+++ b/performance-tuning-methods.md
@@ -251,7 +251,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル
- `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度
- `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度
- `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ
- - `RocksDB Compaction` : RocksDBの圧縮操作によって生成される読み取りおよび書き込みI/Oフローの合計。`RocksDB Compaction`が`TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、Titanによる圧縮I/Oフローを削減できます。
+ - `RocksDB Compaction` : RocksDBのコンパクション操作によって生成される読み取りおよび書き込みI/Oフローの合計。`RocksDB Compaction`が`TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、TitanによるコンパクションI/Oフローを削減できます。
```toml
[rocksdb.titan]
diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md
index ba3f7264dccaa..be397d939f7eb 100644
--- a/sql-statements/sql-statement-alter-table-compact.md
+++ b/sql-statements/sql-statement-alter-table-compact.md
@@ -5,13 +5,13 @@ summary: TiDB データベースの ALTER TABLE ... COMPACT の使用法の概
# ALTER TABLE ... COMPACT {#alter-table--compact}
-読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。 `ALTER TABLE ... COMPACT`文を使用すると、バックグラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。
+読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータコンパクションを自動的にスケジュールします。コンパクション中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。 `ALTER TABLE ... COMPACT`文を使用すると、バックグラウンドでコンパクションがトリガーされるまで待たずに、特定のテーブルのコンパクションを即座に開始できます。
この文を実行しても、既存のSQL文はブロックされず、トランザクション、DDL、GCといったTiDBの機能にも影響はありません。SQL文で選択可能なデータも変更されません。この文の実行は、IOリソースとCPUリソースを消費します。業務への悪影響を避けるため、リソースに余裕があるタイミングなど、適切なタイミングで実行するようご注意ください。
-テーブルのすべてのレプリカが圧縮されると、圧縮ステートメントは終了し、結果が返されます。実行プロセス中に、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを実行することで、圧縮を安全に中断できます。圧縮を中断しても、データの整合性が損なわれたり、データが失われたりすることはありません。また、後続の手動圧縮やバックグラウンド圧縮にも影響はありません。
+テーブルのすべてのレプリカがコンパクションされると、コンパクションステートメントは終了し、結果が返されます。実行プロセス中に、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを実行することで、コンパクションを安全に中断できます。コンパクションを中断しても、データの整合性が損なわれたり、データが失われたりすることはありません。また、後続の手動コンパクションやバックグラウンドコンパクションにも影響はありません。
-このデータ圧縮ステートメントは現在、 TiFlashレプリカに対してのみサポートされており、TiKV レプリカに対してはサポートされていません。
+このデータコンパクションステートメントは現在、 TiFlashレプリカに対してのみサポートされており、TiKV レプリカに対してはサポートされていません。
## 概要 {#synopsis}
@@ -43,7 +43,7 @@ PARTITION BY LIST (store_id) (
ALTER TABLE employees SET TIFLASH REPLICA 2;
```
-次のステートメントを実行すると、 `employees`テーブル内のすべてのパーティションの 2つのTiFlashレプリカの圧縮を直ちに開始できます。
+次のステートメントを実行すると、 `employees`テーブル内のすべてのパーティションの 2つのTiFlashレプリカのコンパクションを直ちに開始できます。
```sql
ALTER TABLE employees COMPACT TIFLASH REPLICA;
@@ -69,7 +69,7 @@ PARTITION BY LIST (store_id) (
ALTER TABLE employees SET TIFLASH REPLICA 2;
```
-次のステートメントを実行すると、テーブル`employees`のパーティション`pNorth`と`pEast`の 2つのTiFlashレプリカの圧縮を直ちに開始できます。
+次のステートメントを実行すると、テーブル`employees`のパーティション`pNorth`と`pEast`の 2つのTiFlashレプリカのコンパクションを直ちに開始できます。
```sql
ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA;
@@ -77,9 +77,9 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA;
## 同時実行性 {#concurrency}
-`ALTER TABLE ... COMPACT`文は、テーブル内のすべてのレプリカを同時に圧縮します。
+`ALTER TABLE ... COMPACT`文は、テーブル内のすべてのレプリカを同時にコンパクションします。
-オンラインビジネスへの重大な影響を避けるため、各TiFlashインスタンスは、デフォルトで一度に1つのテーブルのみのデータを圧縮します（バックグラウンドでトリガーされる圧縮を除く）。つまり、 `ALTER TABLE ... COMPACT`文を複数のテーブルに対して同時に実行した場合、それらの実行は同時に実行されるのではなく、同じTiFlashインスタンス上でキューに入れられます。
+オンラインビジネスへの重大な影響を避けるため、各TiFlashインスタンスは、デフォルトで一度に1つのテーブルのみのデータをコンパクションします（バックグラウンドでトリガーされるコンパクションを除く）。つまり、 `ALTER TABLE ... COMPACT`文を複数のテーブルに対して同時に実行した場合、それらの実行は同時に実行されるのではなく、同じTiFlashインスタンス上でキューに入れられます。
@@ -87,11 +87,11 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA;
-## データ圧縮の進行状況を観察する {#observe-data-compaction-progress}
+## データコンパクションの進行状況を観察する {#observe-data-compaction-progress}
-`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データ圧縮の進行状況を確認したり、テーブルの圧縮を開始するかどうかを判断したりできます。 `TOTAL_DELTA_ROWS`の値が大きいほど、圧縮できるデータ量が多くなります。 `TOTAL_DELTA_ROWS`が`0`の場合、テーブル内のすべてのデータは最適な状態であり、圧縮する必要はありません。
+`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データコンパクションの進行状況を確認したり、テーブルのコンパクションを開始するかどうかを判断したりできます。 `TOTAL_DELTA_ROWS`の値が大きいほど、コンパクションできるデータ量が多くなります。 `TOTAL_DELTA_ROWS`が`0`の場合、テーブル内のすべてのデータは最適な状態であり、コンパクションする必要はありません。
-例:非パーティションテーブルの圧縮状態を確認する
+例:非パーティションテーブルのコンパクション状態を確認する
```sql
USE test;
@@ -136,7 +136,7 @@ SELECT TOTAL_DELTA_ROWS, TOTAL_STABLE_ROWS FROM INFORMATION_SCHEMA.TIFLASH_TABLE
例:パーティションテーブルの圧縮状態を確認する
+例:パーティションテーブルのコンパクション状態を確認する
```sql
USE test;
@@ -189,7 +189,7 @@ SELECT PARTITION_NAME, TOTAL_DELTA_ROWS, TOTAL_STABLE_ROWS
> **Note:**
>
-> - 圧縮中にデータが更新された場合、圧縮完了後も`TOTAL_DELTA_ROWS`が0以外の値のままになることがあります。これは正常な動作であり、これらの更新が圧縮されていないことを示しています。これらの更新を圧縮するには、 `ALTER TABLE ... COMPACT`文を再度実行してください。
+> - コンパクション中にデータが更新された場合、コンパクション完了後も`TOTAL_DELTA_ROWS`が0以外の値のままになることがあります。これは正常な動作であり、これらの更新がコンパクションされていないことを示しています。これらの更新をコンパクションするには、 `ALTER TABLE ... COMPACT`文を再度実行してください。
>
> - `TOTAL_DELTA_ROWS`は行数ではなくデータバージョンを示します。例えば、行を挿入してから削除した場合、 `TOTAL_DELTA_ROWS`は2増加します。
diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md
index 7a799bb2cdf9c..f92251b2a2d1a 100644
--- a/tidb-lightning/data-import-best-practices.md
+++ b/tidb-lightning/data-import-best-practices.md
@@ -86,7 +86,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni
- 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。
- データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。
-なお、圧縮やスナップショットのレプリケーションなどのバックグラウンドタスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。
+なお、コンパクションやスナップショットのレプリケーションなどのバックグラウンドタスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。
## 設定パラメータを変更する {#change-configuration-parameters}
diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md
index 499fb5be39305..3a7f85ff874ea 100644
--- a/tidb-lightning/import-into-vs-tidb-lightning.md
+++ b/tidb-lightning/import-into-vs-tidb-lightning.md
@@ -69,13 +69,13 @@ SQL文を直接記述してインポートタスクを送信でき、呼び出
TiDB Global Sort を使用すると、 `IMPORT INTO`は十 TiB のソースデータを複数の TiDB ノードに送信し、データ KV ペアとインデックス KV ペアをエンコードしてから、これらのペアを Amazon S3 に転送してグローバルソートしてから、TiKV に書き込むことができます。
-これらのKVペアはグローバルにソートされているため、複数のTiDBノードからTiKVにインポートされたデータは重複せず、RocksDBに直接書き込むことができます。これにより、TiKVによる圧縮操作が不要になり、TiKVの書き込みパフォーマンスと安定性が大幅に向上します。
+これらのKVペアはグローバルにソートされているため、複数のTiDBノードからTiKVにインポートされたデータは重複せず、RocksDBに直接書き込むことができます。これにより、TiKVによるコンパクション操作が不要になり、TiKVの書き込みパフォーマンスと安定性が大幅に向上します。
インポートが完了すると、Amazon S3 上のグローバルソートに使用されたデータは自動的に削除され、ストレージコストを節約できます。
#### TiDB Lightning {#tidb-lightning}
-TiDB Lightningはローカルソートのみをサポートします。例えば、数十TiB規模のソースデータの場合、 TiDB Lightningに大容量のローカルディスクが設定されていない場合、または複数のTiDB Lightningインスタンスを並列インポートに使用している場合、各TiDB Lightningインスタンスはローカルディスクを使用してのみインポートデータをソートできます。グローバルソートを実行できないため、複数のTiDB LightningインスタンスからTiKVにインポートされたデータに重複が生じ、特にインデックスデータが多いシナリオでは、TiKVは圧縮操作を実行します。圧縮操作はリソースを大量に消費するため、TiKVの書き込みパフォーマンスと安定性が低下します。
+TiDB Lightningはローカルソートのみをサポートします。例えば、数十TiB規模のソースデータの場合、 TiDB Lightningに大容量のローカルディスクが設定されていない場合、または複数のTiDB Lightningインスタンスを並列インポートに使用している場合、各TiDB Lightningインスタンスはローカルディスクを使用してのみインポートデータをソートできます。グローバルソートを実行できないため、複数のTiDB LightningインスタンスからTiKVにインポートされたデータに重複が生じ、特にインデックスデータが多いシナリオでは、TiKVはコンパクション操作を実行します。コンパクション操作はリソースを大量に消費するため、TiKVの書き込みパフォーマンスと安定性が低下します。
後日データのインポートを継続する場合は、次回のインポートのためにTiDB Lightningサーバーとサーバー上のディスクを保持しておく必要があります。事前割り当てディスクを使用する場合のコストは、Amazon S3を従量課金制で使用した`IMPORT INTO`と比較して比較的高くなります。
@@ -108,7 +108,7 @@ Global Sortを使用しているため、TiKVにインポートされるデー
#### TiDB Lightning {#tidb-lightning}
-ローカルソートのみをサポートしているため、新しいTiDB Lightningインスタンスが追加されたときに TiKV にインポートされたデータが重複する可能性があり、その結果 TiKV の圧縮操作が増え、 `IMPORT INTO`に対するスケーラビリティが制限されます。
+ローカルソートのみをサポートしているため、新しいTiDB Lightningインスタンスが追加されたときに TiKV にインポートされたデータが重複する可能性があり、その結果 TiKV のコンパクション操作が増え、 `IMPORT INTO`に対するスケーラビリティが制限されます。
## `IMPORT INTO`でサポートされていない機能 {#functionalities-not-supported-by-import-into}
diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md
index bb958368ed89e..4d882357638c2 100644
--- a/tidb-lightning/tidb-lightning-command-line-full.md
+++ b/tidb-lightning/tidb-lightning-command-line-full.md
@@ -46,7 +46,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設
| パラメータ | 説明 |
| :---------------------------------------- | :----------------------------------------------- |
-| `--compact` | 完全な圧縮を実行します。 |
+| `--compact` | 完全なコンパクションを実行します。 |
| `--switch-mode ` | すべての TiKV ストアを指定されたモード (通常またはインポート) に切り替えます。 |
| `--fetch-mode` | 各 TiKV ストアの現在のモードを出力します。 |
| `--import-engine ` | 閉じたエンジンファイルを TiKV インポーターから TiKV クラスターにインポートします。 |
diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md
index b2a47d2891745..f55884b0702f4 100644
--- a/tidb-lightning/tidb-lightning-glossary.md
+++ b/tidb-lightning/tidb-lightning-glossary.md
@@ -61,15 +61,15 @@ TiDB Lightning [インポートされたデータを検証する](/tidb-lightnin
ファイルが大きすぎる場合、 TiDB Lightning はファイルを複数のチャンクに分割することがあります。
-### 圧縮 {#compaction}
+### コンパクション {#compaction}
-複数の小さなSSTファイルを1つの大きなSSTファイルに結合し、削除されたエントリをクリーンアップする操作です。TiKVは、 TiDB Lightningによるインポート中にバックグラウンドで自動的にデータを圧縮します。
+複数の小さなSSTファイルを1つの大きなSSTファイルに結合し、削除されたエントリをクリーンアップする操作です。TiKVは、 TiDB Lightningによるインポート中にバックグラウンドで自動的にデータをコンパクションします。
> **Note:**
>
> レガシーシステムへの対応のため、 TiDB Lightning、テーブルのインポートごとに明示的にコンパクションを実行するように設定できます。ただし、これは推奨されず、対応する設定はデフォルトで無効になっています。
-技術的な詳細については[RocksDBの圧縮に関するWikiページ](https://github.com/facebook/rocksdb/wiki/Compaction)を参照してください。
+技術的な詳細については[RocksDBのコンパクションに関するWikiページ](https://github.com/facebook/rocksdb/wiki/Compaction)を参照してください。
diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md
index 800197040755c..c45e6f85ad037 100644
--- a/tidb-performance-tuning-config.md
+++ b/tidb-performance-tuning-config.md
@@ -29,7 +29,7 @@ TiDBのパフォーマンスを最適化するために、一般的に以下の
- [SQLプリペアド実行プランキャッシュ](/sql-prepared-plan-cache.md)、[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)、[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)など、実行プランキャッシュを強化します。
- [オプティマイザ修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。
- ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。
-- 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。
+- 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVのコンパクションおよびフロー制御の設定を微調整します。
これらの設定は、多くのワークロードのパフォーマンスを大幅に向上させることができます。ただし、他の最適化と同様に、本番にデプロイする前に、必ずご自身の環境で十分にテストしてください。
@@ -120,13 +120,13 @@ soft-pending-compaction-bytes-limit = "192GiB"
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライントランザクションパフォーマンスのトレードオフに影響します。 |
| [`rocksdb.max-manifest-file-size`](/tikv-configuration-file.md#max-manifest-file-size) | RocksDB マニフェストファイルの最大サイズを設定します。このファイルには、SST ファイルとデータベースの状態変更に関するメタデータが記録されます。このサイズを大きくすると、マニフェストファイルの書き換え頻度が減り、フォアグラウンド書き込みパフォーマンスへの影響を最小限に抑えることができます。 | デフォルト値は`128MiB`です。SSTファイルが多数存在する環境（例えば、数十万個）では、マニフェストファイルの書き換えが頻繁に行われると、書き込みパフォーマンスが低下する可能性があります。このパラメータを`256MiB`以上の値に調整することで、最適なパフォーマンスを維持できます。 |
-| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。- 主キー範囲スキャンにおけるパフォーマンスへの影響の可能性。
- 空間増幅率の向上（最悪の場合、最大2倍）。
- ブロブキャッシュのための追加メモリ使用量。
|
+| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBのコンパクション処理が書き込みワークロードに追いつかず、コンパクション待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。- 主キー範囲スキャンにおけるパフォーマンスへの影響の可能性。
- 空間増幅率の向上（最悪の場合、最大2倍）。
- ブロブキャッシュのための追加メモリ使用量。
|
| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込みリクエストに対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 |
-| [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 |
-| [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 |
-| [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)を参照してください。 |
+| [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的なコンパクション処理が行われる可能性があります。 |
+| [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中のコンパクションバイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、コンパクション処理が追いつかない場合、保留中のコンパクションバイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 |
+| [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じコンパクション効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)を参照してください。 |
-前述の表に示されている圧縮およびフロー制御構成の調整は、以下の仕様を持つインスタンスへの TiKV デプロイメントに合わせて調整されていることに注意してください。
+前述の表に示されているコンパクションおよびフロー制御構成の調整は、以下の仕様を持つインスタンスへの TiKV デプロイメントに合わせて調整されていることに注意してください。
- CPU: 32コア
- メモリ: 128 GiB
@@ -135,17 +135,17 @@ soft-pending-compaction-bytes-limit = "192GiB"
#### 書き込み負荷の高いワークロードに対する推奨構成調整 {#recommended-configuration-adjustments-for-write-intensive-workloads}
-書き込み負荷の高いワークロードにおける TiKV のパフォーマンスと安定性を最適化するには、インスタンスのハードウェア仕様に基づいて、特定の圧縮およびフロー制御パラメータを調整することをお勧めします。例:
+書き込み負荷の高いワークロードにおける TiKV のパフォーマンスと安定性を最適化するには、インスタンスのハードウェア仕様に基づいて、特定のコンパクションおよびフロー制御パラメータを調整することをお勧めします。例:
-- [`rocksdb.rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec) : 通常はデフォルト値を使用します。圧縮 I/O がディスク帯域幅のかなりの割合を消費していることに気づいた場合は、レートをディスクの最大スループットの約 60% に制限することを検討してください。これにより、圧縮作業のバランスが取れ、ディスクが飽和状態にならないようになります。たとえば、 **1 GiB/s**の定格のディスクでは、これを約`600MiB`に設定します。
+- [`rocksdb.rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec) : 通常はデフォルト値を使用します。コンパクション I/O がディスク帯域幅のかなりの割合を消費していることに気づいた場合は、レートをディスクの最大スループットの約 60% に制限することを検討してください。これにより、コンパクション作業のバランスが取れ、ディスクが飽和状態にならないようになります。たとえば、 **1 GiB/s**の定格のディスクでは、これを約`600MiB`に設定します。
-- [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、圧縮処理のためのバッファが増えます。
+- [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、コンパクション処理のためのバッファが増えます。
これらの設定は、リソースの効率的な利用を確保し、書き込み負荷がピークに達した際の潜在的なボトルネックを最小限に抑えるのに役立ちます。
> **Note:**
>
-> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込みリクエストを拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。
+> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中のコンパクションバイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込みリクエストを拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドのコンパクションプロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、コンパクションパラメータおよびストレージ設定の適切な構成が不可欠です。
### TiFlash -ラーナー向け設定 {#tiflash-learner-configurations}
@@ -274,12 +274,12 @@ sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user
バージョン7.6.0以降、Titanはデフォルトで有効になっています。TiDB v8.4.0では、Titanの`min-blob-size`のデフォルト値は`32KiB`です。ベースライン構成では、レコードサイズを`31KiB`に設定することで、データがRocksDBに保存されるようにしています。一方、キー設定構成では、 `min-blob-size`を`1KiB`に設定すると、データがTitanに保存されます。
-主要設定で確認されたパフォーマンスの向上は、主にTitanがRocksDBの圧縮を削減する能力によるものです。以下の図に示すように、
+主要設定で確認されたパフォーマンスの向上は、主にTitanがRocksDBのコンパクションを削減する能力によるものです。以下の図に示すように、
-- ベースライン：RocksDBの圧縮処理の総スループットは1 GiB/sを超え、ピーク時には3 GiB/sを超える。
-- 主な設定：RocksDBの圧縮処理のピークスループットは100 MiB/sを下回っています。
+- ベースライン：RocksDBのコンパクション処理の総スループットは1 GiB/sを超え、ピーク時には3 GiB/sを超える。
+- 主な設定：RocksDBのコンパクション処理のピークスループットは100 MiB/sを下回っています。
-この圧縮処理オーバーヘッドの大幅な削減は、主要設定構成で見られる全体的なスループットの向上に貢献しています。
+このコンパクション処理オーバーヘッドの大幅な削減は、主要設定構成で見られる全体的なスループットの向上に貢献しています。
@@ -493,7 +493,7 @@ SET GLOBAL tidb_opt_distinct_agg_push_down = ON;
### インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する {#mitigate-mvcc-version-accumulation-using-in-memory-engine}
-MVCC のバージョンが多すぎると、特に読み書き頻度の高い領域や、ガベージコレクションと圧縮の問題により、パフォーマンスのボトルネックが発生する可能性があります。この問題を軽減するには、v8.5.0 で導入されたバージョン[TiKV MVCC インメモリエンジン (IME)](/tikv-in-memory-engine.md)を使用できます。これを有効にするには、TiKV 設定ファイルに次の設定を追加してください。
+MVCC のバージョンが多すぎると、特に読み書き頻度の高い領域や、ガベージコレクションとコンパクションの問題により、パフォーマンスのボトルネックが発生する可能性があります。この問題を軽減するには、v8.5.0 で導入されたバージョン[TiKV MVCC インメモリエンジン (IME)](/tikv-in-memory-engine.md)を使用できます。これを有効にするには、TiKV 設定ファイルに次の設定を追加してください。
> **Note:**
>
diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
index 60beadf0e4303..59401f76c3f1e 100644
--- a/tidb-troubleshooting-map.md
+++ b/tidb-troubleshooting-map.md
@@ -241,15 +241,15 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND
TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込みリクエストをブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込みリクエストを動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。
- - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。
+ - `server is busy`エラーが、保留中のコンパクションバイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。
- - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。
+ - 保留中のコンパクションバイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。
- - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。
+ - 保留中のコンパクションバイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。
- ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。
- - デフォルトのCF圧縮で高圧が検出された場合は、 `[rocksdb.defaultcf] compression-per-level`パラメータを`["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]`から`["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`に変更します。
+ - デフォルトのCFコンパクションで高圧が検出された場合は、 `[rocksdb.defaultcf] compression-per-level`パラメータを`["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]`から`["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`に変更します。
- memtable が多すぎると、処理が停止します。これは通常、インスタント書き込みの量が多く、memtable がディスクにフラッシュされるのが遅い場合に発生します。ディスク書き込み速度を改善できない場合、またこの問題が業務のピーク時にのみ発生する場合は、対応する CF の`max-write-buffer-number`を増やすことで軽減できます。
diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md
index 812f3154294ce..a499d9b8e4259 100644
--- a/tiflash-upgrade-guide.md
+++ b/tiflash-upgrade-guide.md
@@ -125,13 +125,13 @@ TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version
## v6.x または v7.x から`storage.format_version = 5`が設定された v7.3 へ {#from-v6-x-or-v7-x-to-v7-3-with-storage-format-version-5-configured}
-TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash設定パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。
+TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash設定パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータコンパクション時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。
TiFlashをv7.3にアップグレードし、V3 DTFilesを使用するように設定した後、 TiFlashを以前のバージョンに戻す必要がある場合は、DTToolをオフラインで使用してV3 DTFilesをV2 DTFilesに書き換えることができます。詳細については、 [DTTool 移行ツール](/tiflash/tiflash-command-line-flags.md#dttool-migrate)を参照してください。
## v6.x または v7.x から v7.4 以降のバージョンへ {#from-v6-x-or-v7-x-to-v7-4-or-a-later-version}
-v7.4以降、データ圧縮中に発生する読み取りおよび書き込みの増幅を軽減するため、 TiFlashはPageStorage V3のデータ圧縮ロジックを最適化します。これにより、基盤となるストレージファイル名の一部が変更されます。そのため、 TiFlashをv7.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。
+v7.4以降、データコンパクション中に発生する読み取りおよび書き込みの増幅を軽減するため、 TiFlashはPageStorage V3のデータコンパクションロジックを最適化します。これにより、基盤となるストレージファイル名の一部が変更されます。そのため、 TiFlashをv7.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。
## v7.x から v8.4 以降のバージョンへ {#from-v7-x-to-v8-4-or-a-later-version}
diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md
index 0dc44b20db824..b4e9de93eb2cf 100644
--- a/tiflash/monitor-tiflash.md
+++ b/tiflash/monitor-tiflash.md
@@ -87,11 +87,11 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas
## Storage Write Stall {#storage-write-stall}
-- Write & Delta Management Throughput: すべてのインスタンスの書き込みとデータ圧縮のスループット。
+- Write & Delta Management Throughput: すべてのインスタンスの書き込みとデータコンパクションのスループット。
- `throughput_write` Raftを介したデータ同期のスループットを意味します。
- - `throughput_delta-management`データ圧縮のスループットを意味します。
+ - `throughput_delta-management`データコンパクションのスループットを意味します。
- `total_write` 、前回の開始以降に書き込まれた合計バイト数を意味します。
- - `total_delta-management` 、前回の開始以降に圧縮されたデータの合計バイト数を意味します。
+ - `total_delta-management` 、前回の開始以降にコンパクションされたデータの合計バイト数を意味します。
- Write Stall Duration: インスタンスごとの書き込みおよびリージョンデータの削除 (範囲の削除) の停止期間。
- Write Throughput By Instance：インスタンスごとの書き込みスループット。Raft書き込みコマンドとRaftスナップショットを適用した場合のスループットも含まれます。
- Write Command OPS By Instance: インスタンスによって受信されたさまざまな種類のコマンドの合計数。
diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md
index 9be39e40e59bb..e91dcf8a3e879 100644
--- a/tiflash/tiflash-configuration.md
+++ b/tiflash/tiflash-configuration.md
@@ -418,7 +418,7 @@ I/O トラフィック制限設定を構成します。
##### `dt_page_gc_threshold` v6.2.0 の新機能 {#dt_page_gc_threshold-new-in-v620}
-- PageStorageデータファイル内の有効データの最小比率を指定します。PageStorageデータファイル内の有効データの比率がこの設定値を下回ると、GCがトリガーされ、ファイル内のデータが圧縮されます。
+- PageStorageデータファイル内の有効データの最小比率を指定します。PageStorageデータファイル内の有効データの比率がこの設定値を下回ると、GCがトリガーされ、ファイル内のデータがコンパクションされます。
- デフォルト値: `0.5`
##### `max_bytes_before_external_group_by` v7.0.0 の新機能 {#max_bytes_before_external_group_by-new-in-v700}
diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md
index 02b42a7f42332..cf2e6a146a557 100644
--- a/tiflash/tune-tiflash-performance.md
+++ b/tiflash/tune-tiflash-performance.md
@@ -18,7 +18,7 @@ summary: マシン リソースを計画し、TiDB パラメータを調整す
- [MPPモードを強制的に有効にする](#forcibly-enable-the-mpp-mode)
- [集計関数を`Join`または`Union`前の位置へプッシュダウンします](#push-down-aggregate-functions-to-a-position-before-join-or-union)
- [`Distinct`最適化を有効にする](#enable-distinct-optimization)
-- [`ALTER TABLE ... COMPACT`文を使用してデータを圧縮する](#compact-data-using-the-alter-table--compact-statement)
+- [`ALTER TABLE ... COMPACT`文を使用してデータをコンパクションする](#compact-data-using-the-alter-table--compact-statement)
- [シャッフルハッシュ結合をブロードキャストハッシュ結合に置き換える](#replace-shuffled-hash-join-with-broadcast-hash-join)
- [実行同時実行性を高める](#set-a-greater-execution-concurrency)
- [`tiflash_fine_grained_shuffle_stream_count`を設定する](#configure-tiflash_fine_grained_shuffle_stream_count)
@@ -215,7 +215,7 @@ mysql> explain analyze select count(distinct a) from test.t;
5 rows in set, 2 warnings (0.24 sec)
```
-### `ALTER TABLE ... COMPACT`文を使用してデータを圧縮する {#compact-data-using-the-alter-table--compact-statement}
+### `ALTER TABLE ... COMPACT`文を使用してデータをコンパクションする {#compact-data-using-the-alter-table--compact-statement}
[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)文を実行すると、 TiFlashノード上の特定のテーブルまたはパーティションのコンパクションが開始されます。コンパクション中は、ノード上の物理データが書き換えられ、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。これにより、アクセスパフォーマンスが向上し、ディスク使用量が削減されます。以下に例を示します。
diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md
index 6a9dbf2c2073b..04734b36960a2 100644
--- a/tiflash/use-fastscan.md
+++ b/tiflash/use-fastscan.md
@@ -44,7 +44,7 @@ SELECT * FROM t1;
+------+------+
```
-TiFlash は古いデータの圧縮をバックグラウンドで自動的に開始できますが、古いデータは圧縮が完了し、データバージョンが GC セーフポイントより古くなるまで物理的にクリーンアップされません。物理的クリーンアップ後、クリーンアップされた古いデータは FastScan モードでは返されなくなります。データ圧縮のタイミングは、様々な要因によって自動的にトリガーされます。また、 [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)ステートメントを使用して手動でデータ圧縮を開始することもできます。
+TiFlash は古いデータのコンパクションをバックグラウンドで自動的に開始できますが、古いデータはコンパクションが完了し、データバージョンが GC セーフポイントより古くなるまで物理的にクリーンアップされません。物理的クリーンアップ後、クリーンアップされた古いデータは FastScan モードでは返されなくなります。データコンパクションのタイミングは、様々な要因によって自動的にトリガーされます。また、 [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)ステートメントを使用して手動でデータコンパクションを開始することもできます。
## FastScanを有効または無効にする {#enable-and-disable-fastscan}
diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md
index d0e13e3102382..9dfa8f2a8b500 100644
--- a/tikv-configuration-file.md
+++ b/tikv-configuration-file.md
@@ -617,7 +617,7 @@ TiKVにおけるフロー制御メカニズムに関連する設定項目。こ
### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit-1}
-- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始め、 `ServerIsBusy`エラーを報告します。
+- KvDB の保留中のコンパクションバイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始め、 `ServerIsBusy`エラーを報告します。
> **Note:**
>
@@ -627,7 +627,7 @@ TiKVにおけるフロー制御メカニズムに関連する設定項目。こ
### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit-1}
-- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。
+- KvDB の保留中のコンパクションバイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。
- デフォルト値: `"1024GiB"`
## storage.io-rate-limit {#storageio-rate-limit}
@@ -798,7 +798,7 @@ Raftstoreに関連する設定項目。
### `raft-log-compact-sync-interval` v5.3で追加 {#raft-log-compact-sync-interval-new-in-v53}
-- 不要なRaftログを圧縮する時間間隔
+- 不要なRaftログをコンパクションする時間間隔
- デフォルト値: `"2s"`
- 最小値: `"0s"`
@@ -877,7 +877,7 @@ Raftstoreに関連する設定項目。
>
> v7.5.7およびv8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.check-interval`](#check-interval-new-in-v757-and-v854)に置き換えられました。
-- RocksDB の圧縮を手動でトリガーする必要があるかどうかを確認する時間間隔。 `0`はこの機能が無効になっていることを意味します。
+- RocksDB のコンパクションを手動でトリガーする必要があるかどうかを確認する時間間隔。 `0`はこの機能が無効になっていることを意味します。
- デフォルト値: `"5m"`
- 最小値: `0`
@@ -887,7 +887,7 @@ Raftstoreに関連する設定項目。
>
> バージョン7.5.7および8.5.4以降、この設定項目は非推奨となりました。
-- 手動圧縮の各ラウンドで一度にチェックされるリージョンの数
+- 手動コンパクションの各ラウンドで一度にチェックされるリージョンの数
- デフォルト値:
- `storage.engine="raft-kv"`の場合、デフォルト値は`100`です。
@@ -900,7 +900,7 @@ Raftstoreに関連する設定項目。
>
> バージョン7.5.7および8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に置き換えられました。
-- RocksDBの圧縮をトリガーするために必要なtombstoneの数
+- RocksDBのコンパクションをトリガーするために必要なtombstoneの数
- デフォルト値: `10000`
- 最小値: `0`
@@ -910,7 +910,7 @@ Raftstoreに関連する設定項目。
>
> バージョン7.5.7および8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に置き換えられました。
-- RocksDBの圧縮をトリガーするために必要なtombstoneの割合
+- RocksDBのコンパクションをトリガーするために必要なtombstoneの割合
- デフォルト値: `30`
- 最小値: `1`
- 最大値: `100`
@@ -989,13 +989,13 @@ Raftstoreに関連する設定項目。
### `lock-cf-compact-interval` {#lock-cf-compact-interval}
-- TiKVがロックカラムファミリーの手動圧縮をトリガーする時間間隔
+- TiKVがロックカラムファミリーの手動コンパクションをトリガーする時間間隔
- デフォルト値: `"10m"`
- 最小値: `0`
### `lock-cf-compact-bytes-threshold` {#lock-cf-compact-bytes-threshold}
-- TiKVがロックカラムファミリーの手動圧縮をトリガーするサイズ
+- TiKVがロックカラムファミリーの手動コンパクションをトリガーするサイズ
- デフォルト値: `"256MiB"`
- 最小値: `0`
- 単位: MiB
@@ -1179,18 +1179,18 @@ Raftstoreに関連する設定項目。
> **Warning:**
>
-> 定期的な完全圧縮は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。
+> 定期的な完全コンパクションは実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。
-- TiKVが定期的な完全圧縮を開始する具体的な時刻を設定します。配列で複数の時刻スケジュールを指定できます。例：
- - `periodic-full-compact-start-times = ["03:00", "23:00"]`は、TiKVノードの現地時間に基づいて、TiKVが毎日午前3時と午後11時に完全な圧縮を実行することを示しています。
- - `periodic-full-compact-start-times = ["03:00 +0000", "23:00 +0000"]`は、TiKVがUTCタイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。
- - `periodic-full-compact-start-times = ["03:00 +0800", "23:00 +0800"]`は、TiKVがUTC+08:00タイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。
-- デフォルト値: `[]`は、定期的な完全圧縮がデフォルトで無効になっていることを意味します。
+- TiKVが定期的な完全コンパクションを開始する具体的な時刻を設定します。配列で複数の時刻スケジュールを指定できます。例：
+ - `periodic-full-compact-start-times = ["03:00", "23:00"]`は、TiKVノードの現地時間に基づいて、TiKVが毎日午前3時と午後11時に完全なコンパクションを実行することを示しています。
+ - `periodic-full-compact-start-times = ["03:00 +0000", "23:00 +0000"]`は、TiKVがUTCタイムゾーンで毎日午前3時と午後11時に完全なコンパクションを実行することを示しています。
+ - `periodic-full-compact-start-times = ["03:00 +0800", "23:00 +0800"]`は、TiKVがUTC+08:00タイムゾーンで毎日午前3時と午後11時に完全なコンパクションを実行することを示しています。
+- デフォルト値: `[]`は、定期的な完全コンパクションがデフォルトで無効になっていることを意味します。
### `periodic-full-compact-start-max-cpu` v7.6.0で追加 {#periodic-full-compact-start-max-cpu-new-in-v760}
-- TiKVの定期的な完全圧縮におけるCPU使用率の上限を制限します。
-- デフォルト値: `0.1` 、定期的な圧縮処理の最大 CPU 使用率が 10% であることを意味します。
+- TiKVの定期的な完全コンパクションにおけるCPU使用率の上限を制限します。
+- デフォルト値: `0.1` 、定期的なコンパクション処理の最大 CPU 使用率が 10% であることを意味します。
### `follower-read-max-log-gap` v7.4.0の新機能 {#follower-read-max-log-gap-new-in-v740}
@@ -1392,7 +1392,7 @@ RocksDBに関連する設定項目
### `compaction-readahead-size` {#compaction-readahead-size-1}
-- RocksDBの圧縮処理中に先読み機能を有効にし、先読みデータのサイズを指定します。機械式ディスクを使用している場合は、少なくとも2MiBに設定することをお勧めします。
+- RocksDBのコンパクション処理中に先読み機能を有効にし、先読みデータのサイズを指定します。機械式ディスクを使用している場合は、少なくとも2MiBに設定することをお勧めします。
- デフォルト値: `2MiB` (v8.5.7 より前のデフォルト値は `0`)
- 最小値: `0`
- 単位: B|KiB|MiB|GiB
@@ -1406,12 +1406,12 @@ RocksDBに関連する設定項目
### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction-1}
-- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。
+- バックグラウンドのフラッシュとコンパクションにおける読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。
- デフォルト値: `false`
### `rate-bytes-per-sec` {#rate-bytes-per-sec}
-- Titanが無効になっている場合、この設定項目はRocksDB圧縮のI/Oレートを制限し、トラフィックのピーク時にRocksDB圧縮がフォアグラウンドの読み取りおよび書き込みパフォーマンスに与える影響を軽減します。Titanが有効になっている場合、この設定項目はRocksDB圧縮とTitan GCの合計I/Oレートを制限します。RocksDB圧縮とTitan GCのI/OまたはCPU消費量が大きすぎる場合は、ディスクI/O帯域幅と実際の書き込みトラフィックに応じて、この設定項目を適切な値に設定してください。
+- Titanが無効になっている場合、この設定項目はRocksDBコンパクションのI/Oレートを制限し、トラフィックのピーク時にRocksDBコンパクションがフォアグラウンドの読み取りおよび書き込みパフォーマンスに与える影響を軽減します。Titanが有効になっている場合、この設定項目はRocksDBコンパクションとTitan GCの合計I/Oレートを制限します。RocksDBコンパクションとTitan GCのI/OまたはCPU消費量が大きすぎる場合は、ディスクI/O帯域幅と実際の書き込みトラフィックに応じて、この設定項目を適切な値に設定してください。
- デフォルト値: `10GiB`
- 最小値: `0`
- 単位: B|KiB|MiB|GiB
@@ -1423,13 +1423,13 @@ RocksDBに関連する設定項目
### `rate-limiter-mode` {#rate-limiter-mode}
-- RocksDBの圧縮速度制限モード
+- RocksDBのコンパクション速度制限モード
- オプション値: `"read-only"` 、 `"write-only"` 、 `"all-io"`
- デフォルト値: `"write-only"`
### `rate-limiter-auto-tuned` v5.0の新機能 {#rate-limiter-auto-tuned-new-in-v50}
-- 最近のワークロードに基づいて、RocksDBの圧縮レート制限設定を自動的に最適化するかどうかを決定します。この設定を有効にすると、圧縮待ちバイト数が通常よりも若干多くなります。
+- 最近のワークロードに基づいて、RocksDBのコンパクションレート制限設定を自動的に最適化するかどうかを決定します。この設定を有効にすると、コンパクション待ちバイト数が通常よりも若干多くなります。
- デフォルト値: `true`
### `enable-pipelined-write` {#enable-pipelined-write-1}
@@ -1692,12 +1692,12 @@ Titanに関連する設定項目。
### `max-bytes-for-level-base` {#max-bytes-for-level-base}
-- ベースレベル（レベル1）における最大バイト数。一般的には、memtableのサイズの4倍に設定されます。レベル1のデータサイズ`max-bytes-for-level-base`の制限値に達すると、レベル1のSSTファイルと、それと重複するレベル2のSSTファイルが圧縮されます。
+- ベースレベル（レベル1）における最大バイト数。一般的には、memtableのサイズの4倍に設定されます。レベル1のデータサイズ`max-bytes-for-level-base`の制限値に達すると、レベル1のSSTファイルと、それと重複するレベル2のSSTファイルがコンパクションされます。
- `defaultcf`および`writecf`のデフォルト値: `"512MiB"`
- `lockcf`のデフォルト値: `"128MiB"`
- 最小値: `0`
- 単位：KiB｜MiB｜GiB
-- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にすることを推奨します。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。
+- 不要なコンパクションを減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 のコンパクションのトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にすることを推奨します。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。
### `target-file-size-base` {#target-file-size-base}
@@ -1708,7 +1708,7 @@ Titanに関連する設定項目。
### `level0-file-num-compaction-trigger` {#level0-file-num-compaction-trigger}
-- L0 で圧縮をトリガーするファイルの最大数
+- L0 でコンパクションをトリガーするファイルの最大数
- `defaultcf`および`writecf`のデフォルト値: `4`
- `lockcf`のデフォルト値: `1`
- 最小値: `0`
@@ -1717,7 +1717,7 @@ Titanに関連する設定項目。
- L0 で書き込み停止を引き起こすファイルの最大数。
- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目の値は[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。
-- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。
+- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB のコンパクション高速化メカニズムが弱まるのを防ぎます。
- デフォルト値: `20`
- 最小値: `0`
@@ -1729,19 +1729,19 @@ Titanに関連する設定項目。
### `max-compaction-bytes` {#max-compaction-bytes}
-- 圧縮ごとにディスクに書き込まれる最大バイト数
+- コンパクションごとにディスクに書き込まれる最大バイト数
- デフォルト値: `"2GiB"`
- 最小値: `0`
- 単位：KiB｜MiB｜GiB
### `compaction-pri` {#compaction-pri}
-- 優先される圧縮の種類
+- 優先されるコンパクションの種類
- オプション値:
- - `"by-compensated-size"` : ファイルサイズ順にファイルを圧縮し、大きなファイルはより高い優先度で圧縮されます。
- - `"oldest-largest-seq-first"` : 更新日時が最も古いファイルの圧縮を優先します。この値は、ホットキーを狭い範囲で更新する場合に**のみ**使用してください。
- - `"oldest-smallest-seq-first"` : 長期間次のレベルに圧縮されていない範囲を持つファイルの圧縮を優先します。キー空間全体でホットキーをランダムに更新する場合、この値は書き込み増幅をわずかに低減できます。
- - `"min-overlapping-ratio"` : 重複率の高いファイルの圧縮を優先します。ファイルの各レベルが小さい場合（ `the file size in the next level` ÷ `the file size in this level`の結果が小さい場合）、TiKV はこのファイルを最初に圧縮します。多くの場合、この値によって書き込み増幅を効果的に削減できます。
+ - `"by-compensated-size"` : ファイルサイズ順にファイルをコンパクションし、大きなファイルはより高い優先度でコンパクションされます。
+ - `"oldest-largest-seq-first"` : 更新日時が最も古いファイルのコンパクションを優先します。この値は、ホットキーを狭い範囲で更新する場合に**のみ**使用してください。
+ - `"oldest-smallest-seq-first"` : 長期間次のレベルにコンパクションされていない範囲を持つファイルのコンパクションを優先します。キー空間全体でホットキーをランダムに更新する場合、この値は書き込み増幅をわずかに低減できます。
+ - `"min-overlapping-ratio"` : 重複率の高いファイルのコンパクションを優先します。ファイルの各レベルが小さい場合（ `the file size in the next level` ÷ `the file size in this level`の結果が小さい場合）、TiKV はこのファイルを最初にコンパクションします。多くの場合、この値によって書き込み増幅を効果的に削減できます。
- `defaultcf`および`writecf`のデフォルト値: `"min-overlapping-ratio"`
- `lockcf`のデフォルト値: `"by-compensated-size"`
@@ -1762,38 +1762,38 @@ Titanに関連する設定項目。
### `compaction-style` {#compaction-style}
-- 圧縮方法
+- コンパクション方法
- オプション値: `"level"` 、 `"universal"` 、 `"fifo"`
- デフォルト値: `"level"`
### `disable-auto-compactions` {#disable-auto-compactions}
-- 自動圧縮を無効にするかどうかを決定します。
+- 自動コンパクションを無効にするかどうかを決定します。
- デフォルト値: `false`
### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit}
-- 保留中の圧縮バイト数のソフトリミット。
+- 保留中のコンパクションバイト数のソフトリミット。
- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は[`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって直接上書きされます。
-- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、その値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ、 [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。
+- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、その値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ、 [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB のコンパクション高速化メカニズムが弱まるのを防ぎます。
- デフォルト値: `"192GiB"`
- 単位：KiB｜MiB｜GiB
### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit}
-- 保留中の圧縮バイト数の上限値。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.hard-pending-compaction-bytes-limit`がこの設定項目を上書きします。
+- 保留中のコンパクションバイト数の上限値。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.hard-pending-compaction-bytes-limit`がこの設定項目を上書きします。
- デフォルト値: `"256GiB"`
- 単位：KiB｜MiB｜GiB
### `enable-compaction-guard` {#enable-compaction-guard}
-- TiKVリージョン境界でSSTファイルを分割する最適化機能である圧縮ガードを有効または無効にします。この最適化により、圧縮I/Oを削減し、TiKVがより大きなSSTファイルサイズ（つまり、SSTファイルの総数）を使用できるようにすると同時に、リージョン移行時に古いデータを効率的にクリーンアップできます。
+- TiKVリージョン境界でSSTファイルを分割する最適化機能であるコンパクションガードを有効または無効にします。この最適化により、コンパクションI/Oを削減し、TiKVがより大きなSSTファイルサイズ（つまり、SSTファイルの総数）を使用できるようにすると同時に、リージョン移行時に古いデータを効率的にクリーンアップできます。
- `defaultcf`および`writecf`のデフォルト値: `true`
- `lockcf`のデフォルト値: None。これは、デフォルトで無効になっていることを意味します。
### `compaction-guard-min-output-file-size` {#compaction-guard-min-output-file-size}
-- 圧縮ガードが有効になっている場合の、SSTファイルの最小サイズ。この設定により、圧縮ガードが有効になっている場合にSSTファイルが小さくなりすぎるのを防ぎます。
+- コンパクションガードが有効になっている場合の、SSTファイルの最小サイズ。この設定により、コンパクションガードが有効になっている場合にSSTファイルが小さくなりすぎるのを防ぎます。
- デフォルト値: `"8MiB"`
- 単位：KiB｜MiB｜GiB
@@ -1820,19 +1820,19 @@ Titanに関連する設定項目。
### `ttl` v7.2.0の新機能 {#ttl-new-in-v720}
-- TTLよりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。これらのSSTファイルは、最下位レベルまたは最下位ファイルまで圧縮されるように、段階的に圧縮処理が行われます。
+- TTLよりも古い更新情報を持つSSTファイルは、自動的にコンパクション対象として選択されます。これらのSSTファイルは、最下位レベルまたは最下位ファイルまでコンパクションされるように、段階的にコンパクション処理が行われます。
- デフォルト値：なし。これは、デフォルトではSSTファイルが選択されていないことを意味します。
- 単位：s（秒）｜h（時間）｜d（日）
### `periodic-compaction-seconds` v7.2.0 の新機能 {#periodic-compaction-seconds-new-in-v720}
-- 定期的な圧縮の間隔。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。
-- デフォルト値：None。これは、定期的な圧縮がデフォルトで無効になっていることを意味します。
+- 定期的なコンパクションの間隔。この値よりも古い更新履歴を持つSSTファイルがコンパクション対象として選択され、元のSSTファイルと同じ階層に書き換えられます。
+- デフォルト値：None。これは、定期的なコンパクションがデフォルトで無効になっていることを意味します。
- 単位：s（秒）｜h（時間）｜d（日）
### `max-compactions` （v6.6.0の新機能） {#max-compactions-new-in-v660}
-- 同時実行可能な圧縮タスクの最大数。値`0`は制限なしを意味します。
+- 同時実行可能なコンパクションタスクの最大数。値`0`は制限なしを意味します。
- デフォルト値: `0`
## rocksdb.defaultcf.titan {#rocksdbdefaultcftitan}
@@ -2013,7 +2013,7 @@ Titanに関連する設定項目。
### `compaction-readahead-size` {#compaction-readahead-size}
-- RocksDBの圧縮中に先読み機能を有効にするかどうか、および先読みデータのサイズを指定するかどうかを制御します。
+- RocksDBのコンパクション中に先読み機能を有効にするかどうか、および先読みデータのサイズを指定するかどうかを制御します。
- 機械式ディスクを使用する場合は、値を少なくとも`2MiB`に設定することをお勧めします。
- デフォルト値: `2MiB` (v8.5.7 より前のデフォルト値は `0`)
- 最小値: `0`
@@ -2028,7 +2028,7 @@ Titanに関連する設定項目。
### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction}
-- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。
+- バックグラウンドのフラッシュとコンパクションにおける読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。
- デフォルト値: `false`
### `enable-pipelined-write` {#enable-pipelined-write}
@@ -2344,62 +2344,62 @@ TiDB LightningのインポートおよびBR復元に関連する設定項目。
## gc.auto-compaction {#gcauto-compaction}
-TiKVの自動圧縮の動作を設定します。
+TiKVの自動コンパクションの動作を設定します。
### `check-interval` v7.5.7 および v8.5.4 で追加 {#check-interval-new-in-v757-and-v854}
-- TiKVが自動圧縮をトリガーするかどうかを確認する間隔。この間隔内では、自動圧縮条件を満たすリージョンが優先度に基づいて処理されます。間隔が経過すると、TiKVはリージョン情報を再スキャンし、優先度を再計算します。
+- TiKVが自動コンパクションをトリガーするかどうかを確認する間隔。この間隔内では、自動コンパクション条件を満たすリージョンが優先度に基づいて処理されます。間隔が経過すると、TiKVはリージョン情報を再スキャンし、優先度を再計算します。
- デフォルト値: `"300s"`
### `tombstone-num-threshold` v7.5.7 および v8.5.4 で追加 {#tombstone-num-threshold-new-in-v757-and-v854}
-- TiKVの自動圧縮をトリガーするために必要なRocksDBのtombstoneの数。tombstoneの数がこのしきい値に達するか、tombstoneの割合が[`tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。
-- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。
+- TiKVの自動コンパクションをトリガーするために必要なRocksDBのtombstoneの数。tombstoneの数がこのしきい値に達するか、tombstoneの割合が[`tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動コンパクションをトリガーします。
+- この設定項目は[コンパクションフィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。
- デフォルト値: `10000`
- 最小値: `0`
### `tombstone-percent-threshold` v7.5.7 および v8.5.4 で追加 {#tombstone-percent-threshold-new-in-v757-and-v854}
-- TiKVによる自動圧縮をトリガーするために必要なRocksDBのtombstoneの割合。tombstoneの割合がこのしきい値に達するか、tombstoneの数が[`tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。
-- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。
+- TiKVによる自動コンパクションをトリガーするために必要なRocksDBのtombstoneの割合。tombstoneの割合がこのしきい値に達するか、tombstoneの数が[`tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に達すると、TiKVは自動コンパクションをトリガーします。
+- この設定項目は[コンパクションフィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。
- デフォルト値: `30`
- 最小値: `0`
- 最大値: `100`
### `redundant-rows-threshold` v7.5.7 および v8.5.4 で追加 {#redundant-rows-threshold-new-in-v757-and-v854}
-- TiKVの自動圧縮をトリガーするために必要な冗長MVCC行の数。冗長行には、RocksDBのtombstone、TiKVの古いバージョン、およびTiKVの削除tombstoneが含まれます。冗長MVCC行の数がこのしきい値に達するか、これらの行の割合が[`redundant-rows-percent-threshold`](#redundant-rows-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。
-- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。
+- TiKVの自動コンパクションをトリガーするために必要な冗長MVCC行の数。冗長行には、RocksDBのtombstone、TiKVの古いバージョン、およびTiKVの削除を示すtombstoneが含まれます。冗長MVCC行の数がこのしきい値に達するか、これらの行の割合が[`redundant-rows-percent-threshold`](#redundant-rows-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動コンパクションをトリガーします。
+- この設定項目は[コンパクションフィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。
- デフォルト値: `50000`
- 最小値: `0`
### `redundant-rows-percent-threshold` （v7.5.7およびv8.5.4で追加） {#redundant-rows-percent-threshold-new-in-v757-and-v854}
-- TiKV の自動圧縮をトリガーするために必要な冗長 MVCC 行の割合。冗長行には、RocksDB のtombstone、TiKV の古いバージョン、および TiKV の削除tombstoneが含まれます。冗長 MVCC 行の数が[`redundant-rows-threshold`](#redundant-rows-threshold-new-in-v757-and-v854)に達するか、これらの行の割合が`redundant-rows-percent-threshold`に達すると、TiKV は自動圧縮をトリガーします。
-- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。
+- TiKV の自動コンパクションをトリガーするために必要な冗長 MVCC 行の割合。冗長行には、RocksDB のtombstone、TiKV の古いバージョン、および TiKV の削除を示すtombstoneが含まれます。冗長 MVCC 行の数が[`redundant-rows-threshold`](#redundant-rows-threshold-new-in-v757-and-v854)に達するか、これらの行の割合が`redundant-rows-percent-threshold`に達すると、TiKV は自動コンパクションをトリガーします。
+- この設定項目は[コンパクションフィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。
- デフォルト値: `20`
- 最小値: `0`
- 最大値: `100`
### `bottommost-level-force` v7.5.7 および v8.5.4 で追加 {#bottommost-level-force-new-in-v757-and-v854}
-- RocksDBの最下位ファイルに対して強制的に圧縮を実行するかどうかを制御します。
+- RocksDBの最下位ファイルに対して強制的にコンパクションを実行するかどうかを制御します。
- デフォルト値: `true`
### `mvcc-read-aware-enabled` v8.5.6の新機能 {#mvcc-read-aware-enabled-new-in-v856}
-- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取りリクエスト中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。
+- MVCC読み取り対応のコンパクションを有効にするかどうかを制御します。有効にすると、TiKVは読み取りリクエスト中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対してコンパクションを優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。
- デフォルト値: `false`
### `mvcc-scan-threshold` v8.5.6で追加 {#mvcc-scan-threshold-new-in-v856}
-- リージョンを圧縮候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。
+- リージョンをコンパクション候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。
- デフォルト値: `1000`
- 最小値: `0`
### `mvcc-read-weight` v8.5.6で追加 {#mvcc-read-weight-new-in-v856}
-- リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。値が大きいほど、tombstone密度などの他の圧縮トリガーと比較して、MVCC 読み取り増幅に重みが高くなります。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。
+- リージョンのコンパクション優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。値が大きいほど、tombstone密度などの他のコンパクショントリガーと比較して、MVCC 読み取り増幅に重みが高くなります。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。
- デフォルト値: `3.0`
- 最小値: `0.0`
diff --git a/tikv-control.md b/tikv-control.md
index 478d983353fc3..eb7df4862a240 100644
--- a/tikv-control.md
+++ b/tikv-control.md
@@ -293,40 +293,40 @@ middle_key_by_approximate_size:
これらのプロパティは、 リージョンが正常かどうかをチェックするために使用できます。正常でない場合は、これらのプロパティを使用してリージョン を修正できます。例えば、 リージョン を手動で`middle_key_approximate_size`ずつ分割するなどです。
-### 各TiKVのデータを手動で圧縮する {#compact-data-of-each-tikv-manually}
+### 各TiKVのデータを手動でコンパクションする {#compact-data-of-each-tikv-manually}
-`compact`コマンドを使用して、各 TiKV のデータを手動で圧縮します。
+`compact`コマンドを使用して、各 TiKV のデータを手動でコンパクションします。
-- `--from`と`--to`オプションを使用して、エスケープされた生のキーの形式で圧縮範囲を指定します。指定しない場合は、範囲全体が圧縮されます。
+- `--from`と`--to`オプションを使用して、エスケープされた生のキーの形式でコンパクション範囲を指定します。指定しない場合は、範囲全体がコンパクションされます。
-- 特定のリージョンの範囲を圧縮するには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`が無視されます。
+- 特定のリージョンの範囲をコンパクションするには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`が無視されます。
- カラムファミリー名を指定するには、 `-c`オプションを使用します。デフォルト値は`default`です。オプションの値は`default` 、 `lock` 、 `write`です。
-- 圧縮を実行するRocksDBを指定するには、 `-d`オプションを使用します。デフォルト値は`kv`です。オプション値は`kv`と`raft`です。
+- コンパクションを実行するRocksDBを指定するには、 `-d`オプションを使用します。デフォルト値は`kv`です。オプション値は`kv`と`raft`です。
-- `--threads`オプションを使用すると、TiKV 圧縮の同時実行数を指定できます。デフォルト値は`8`です。一般的に、同時実行数が多いほど圧縮速度は速くなりますが、サービスに影響を与える可能性があります。シナリオに応じて適切な同時実行数を選択する必要があります。
+- `--threads`オプションを使用すると、TiKV コンパクションの同時実行数を指定できます。デフォルト値は`8`です。一般的に、同時実行数が多いほどコンパクション速度は速くなりますが、サービスに影響を与える可能性があります。シナリオに応じて適切な同時実行数を選択する必要があります。
-- `--bottommost`オプションを使用すると、TiKV が圧縮を実行する際に最下位のファイルを含めるか除外するかを指定できます。値のオプションは`default` 、 `skip` 、 `force`です。デフォルト値は`default`です。
- - `default` 、圧縮フィルター機能が有効な場合にのみ最下位のファイルが含まれることを意味します。
- - `skip` 、TiKV が圧縮を実行するときに最下部のファイルが除外されることを意味します。
- - `force` 、TiKV が圧縮を実行するときに、最下層のファイルが常に含まれることを意味します。
+- `--bottommost`オプションを使用すると、TiKV がコンパクションを実行する際に最下位のファイルを含めるか除外するかを指定できます。値のオプションは`default` 、 `skip` 、 `force`です。デフォルト値は`default`です。
+ - `default` 、コンパクションフィルター機能が有効な場合にのみ最下位のファイルが含まれることを意味します。
+ - `skip` 、TiKV がコンパクションを実行するときに最下部のファイルが除外されることを意味します。
+ - `force` 、TiKV がコンパクションを実行するときに、最下層のファイルが常に含まれることを意味します。
-- ローカルモードでデータを圧縮するには、次のコマンドを使用します。
+- ローカルモードでデータをコンパクションするには、次のコマンドを使用します。
```shell
tikv-ctl --data-dir /path/to/tikv compact -d kv
```
-- リモートモードでデータを圧縮するには、次のコマンドを使用します。
+- リモートモードでデータをコンパクションするには、次のコマンドを使用します。
```shell
tikv-ctl --host ip:port compact -d kv
```
-### TiKVクラスタ全体のデータを手動で圧縮する {#compact-data-of-the-whole-tikv-cluster-manually}
+### TiKVクラスタ全体のデータを手動でコンパクションする {#compact-data-of-the-whole-tikv-cluster-manually}
-`compact-cluster`コマンドを使用して、TiKV クラスタ全体のデータを手動で圧縮します。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。
+`compact-cluster`コマンドを使用して、TiKV クラスタ全体のデータを手動でコンパクションします。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。
- `compact-cluster`コマンドでは、 `--pd`を使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。
- `compact`コマンドでは、 `--data-dir`または`--host`を使用して、単一の TiKV をコンパクト ターゲットとして指定します。
@@ -452,7 +452,7 @@ tikv-ctl --host ip:port modify-tikv-config -n raftdb.defaultcf.disable-auto-comp
success
```
-圧縮レート制限によって圧縮保留バイトが蓄積される場合は、 `rate-limiter-auto-tuned`モードを無効にするか、圧縮フローの制限を高く設定します。
+コンパクションレート制限によってコンパクション保留バイトが蓄積される場合は、 `rate-limiter-auto-tuned`モードを無効にするか、コンパクションフローの制限を高く設定します。
```shell
tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-limiter-auto-tuned -v false
diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md
index db74f3b240f6c..d93639100fd26 100644
--- a/troubleshoot-high-disk-io.md
+++ b/troubleshoot-high-disk-io.md
@@ -71,7 +71,7 @@ TiDBクラスターのメインストレージコンポーネントはTiKVです
- TiKV RocksDB ログに`Write stall`が表示されます。
- レベル0のSSTファイルが多すぎると書き込みストールが発生している可能性があります。この問題に対処するには、パラメータ`[rocksdb] max-sub-compactions = 2 (or 3)`を追加してレベル0のSSTファイルの圧縮を高速化できます。このパラメータは、レベル0からレベル1への圧縮タスクを`max-sub-compactions`サブタスクに分割し、マルチスレッドで同時実行できるようにすることを意味します。
+ レベル0のSSTファイルが多すぎると書き込みストールが発生している可能性があります。この問題に対処するには、パラメータ`[rocksdb] max-sub-compactions = 2 (or 3)`を追加してレベル0のSSTファイルのコンパクションを高速化できます。このパラメータは、レベル0からレベル1へのコンパクションタスクを`max-sub-compactions`サブタスクに分割し、マルチスレッドで同時実行できるようにすることを意味します。
ディスクのI/O性能が書き込みに追いつかない場合は、ディスクのスケールアップをお勧めします。ディスクのスループットが上限に達し（例えば、SATA SSDのスループットがNVMe SSDよりも大幅に低い場合）、書き込みが停止する可能性があるものの、CPUリソースが比較的十分な場合は、より高い圧縮率の圧縮アルゴリズムを使用してディスクの負荷を軽減し、CPUリソースでディスクリソースを補う方法を検討してください。
diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md
index a1c89feeb2608..b8555de39cc68 100644
--- a/tune-tikv-thread-performance.md
+++ b/tune-tikv-thread-performance.md
@@ -25,7 +25,7 @@ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftsto
- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキー値リクエストとして解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込みリクエストが完了したことを通知し、結果をクライアントに返します。
-- RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。
+- RocksDBスレッドプール：RocksDBがタスクをコンパクションおよびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。
- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取りリクエストはこのスレッドプールで実行されます。
@@ -87,12 +87,12 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで
- RocksDB スレッドプール。
- RocksDBスレッドプールは、RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。通常は設定する必要はありません。
+ RocksDBスレッドプールは、RocksDBがタスクをコンパクションおよびフラッシュするためのスレッドプールです。通常は設定する必要はありません。
- マシンの CPU コア数が少ない場合は、 `rocksdb.max-background-jobs`と`raftdb.max-background-jobs`両方を`4`に設定します。
- 書き込みストールが発生した場合は、Grafana の**RocksDB-kv**の Write Stall Reason に移動し、 `0`以外のメトリックを確認します。
- - 保留中の圧縮バイトに関連する理由によって発生した場合は、 `rocksdb.max-sub-compactions`を`2`または`3`に設定してください。この設定項目は、単一の圧縮ジョブで許可されるサブスレッドの数を示します。デフォルト値は、TiKV 4.0 では`3` 、TiKV 3.0 では`1`です。
+ - 保留中のコンパクションバイトに関連する理由によって発生した場合は、 `rocksdb.max-sub-compactions`を`2`または`3`に設定してください。この設定項目は、単一のコンパクションジョブで許可されるサブスレッドの数を示します。デフォルト値は、TiKV 4.0 では`3` 、TiKV 3.0 では`1`です。
- 理由が memtable 数に関連している場合は、すべての列の`max-write-buffer-number` (デフォルトでは`5` ) を増やすことをお勧めします。
- 理由がレベル 0 のファイル制限に関連している場合は、次のパラメータの値を`64`以上に増やすことをお勧めします。