i18n(ja): unify the Japanese term for 'request' (part A of 2)

alert-rules.md

@@ -711,7 +711,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
 - 説明：
 
-    コプロセッサーのキューイング要求。
+    コプロセッサーのキューイングリクエスト。
 
 - 解決：
 

auto-increment.md

@@ -284,7 +284,7 @@ mysql> SELECT * FROM t ORDER BY b;
 11 rows in set (0.00 sec)
 ```
 
-値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーがデプロイされている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
+値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーがデプロイされている場合、キャッシュリクエストがインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
 
 ### キャッシュサイズの制御 {#cache-size-control}
 

best-practices/best-practices-on-public-cloud.md

@@ -53,7 +53,7 @@ sdb           1649.00 209030.67   1293.33 304644.00    13.33    5.09  48.37
 sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00
 ```
 
-デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュ要求完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。
+デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。
 
 クラウドプロバイダーによって、IOPSやMBPSなどのパフォーマンス特性が異なる様々なディスクタイプが提供されています。そのため、ワークロードに応じて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。
 

best-practices/ddl-introduction.md

@@ -105,7 +105,7 @@ DDL実行のユーザーエクスペリエンスを向上させるため、TiDB
 
 v6.2.0 より前では、 TiDB SQLレイヤーで非同期スキーマ変更を処理するプロセスは次のとおりです。
 
-1. MySQL クライアントは TiDBサーバーに DDL 要求を送信します。
+1. MySQL クライアントは TiDBサーバーに DDL リクエストを送信します。
 
 2. リクエストを受信すると、TiDBサーバーはMySQL プロトコルレイヤーでリクエストを解析および最適化し、実行のためにTiDB SQLレイヤーに送信します。
 

best-practices/high-concurrency-best-practices.md

@@ -18,7 +18,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 ## 同時書き込みの多いシナリオ {#highly-concurrent-write-intensive-scenario}
 
-高度な同時書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。
+同時実行性の高い書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。
 
 - 膨大な量のデータ
 - 履歴データを短時間でデータベースにインポートする必要性
@@ -98,7 +98,7 @@ FROM
 
 ![QPS3](/media/best-practices/QPS3.png)
 
-[RaftストアCPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`フォロワーです。他のノードの負荷はほぼ空です。
+[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。
 
 PD の監視メトリックでも、ホットスポットが発生したことが確認されます。
 

best-practices/index-management-best-practices.md

@@ -51,7 +51,7 @@ TiDB は、次のツールを導入することでインデックスの最適化
 
 - 未使用のインデックスの検出: クエリによってアクセスされていないインデックスを識別し、安全に削除できるインデックスを判断するのに役立ちます。
 - インデックスの効率を分析する: インデックスが使用される頻度と、効率的なクエリ実行に貢献しているかどうかを追跡します。
-- クエリパターンを評価する: インデックスが読み取り操作、データスキャン、キーバリュー (KV) 要求にどのように影響するかを理解します。
+- クエリパターンを評価する: インデックスが読み取り操作、データスキャン、キー値 (KV) リクエストにどのように影響するかを理解します。
 
 [TiDB v8.4.0](/releases/release-8.4.0.md)から始まる`TIDB_INDEX_USAGE`システムテーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。
 
@@ -308,7 +308,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE;
 
 4. **DML パフォーマンスへの影響に注意してください。**
 
-    - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`UPDATE` `INSERT` `DELETE`のオーバーヘッドが増加します。
+    - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`INSERT`、`UPDATE`、`DELETE`操作のオーバーヘッドが増加します。
     - 書き込みが多いワークロードのメンテナンス コストを最小限に抑えるために、クエリに必要なものだけをインデックスします。
 
 5. **定期的にテストと調整を行ってください。**

best-practices/pd-scheduling-best-practices.md

@@ -90,7 +90,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/
 
 クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。
 
-リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker` `location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。
+リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。
 
 ### スケールインと障害回復 {#scale-in-and-failure-recovery}
 
@@ -215,7 +215,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
     - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。
     - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`を設定して一時的に無効にすることができます。
-    - スケジューリングプロセスが遅すぎます。原因を確認するには**Operator step duration**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` 、 `RemovePeer` 、 `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。
+    - スケジューリングプロセスが遅すぎます。原因を確認するには**Operator step duration**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` 、 `RemovePeer` 、 `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner`と`AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。
 
 - PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。
 
@@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ
 
 > **Note:**
 >
-> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。
+> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**Leaderの排除**リクエストを処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。

best-practices/three-dc-local-read.md

@@ -25,6 +25,6 @@ zone=dc-1
 
 [ステイル読み取り](/stale-read.md)は、TiDBがユーザーに履歴データ読み取りのために提供するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータ複製によって生じるレイテンシーを削減できます。地理的に分散されたデプロイメントの一部のシナリオでステイル読み取りを使用する場合、TiDBはリアルタイムパフォーマンスを犠牲にして現在のデータセンター内のレプリカにアクセスし、対応するデータを読み取ります。これにより、センター間接続によって生じるネットワークレイテンシーを回避し、クエリプロセス全体のアクセスレイテンシーを削減します。
 
-TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードに要求を送信します。
+TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードにリクエストを送信します。
 
 ステイル読み取り の実行方法については、 [`AS OF TIMESTAMP`句を使用してステイル読み取りを実行する](/as-of-timestamp.md)を参照してください。

best-practices/three-nodes-hybrid-deployment.md

@@ -68,7 +68,7 @@ tikv:
 
 #### `storage.scheduler-worker-pool-size` {#storage-scheduler-worker-pool-size}
 
-TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクション要求を単純なキーバリューの読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。
+TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクションリクエストを単純なキー値の読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。
 
 理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。
 

br/backup-and-restore-use-cases.md

@@ -7,10 +7,10 @@ summary: TiDBは、タイムリーなデータリカバリやビジネス監査
 
 [TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md)と[TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md) 、TiDBが提供するバックアップとリストアのソリューション、すなわちスナップショット（フル）バックアップとリストア、ログバックアップ、そしてポイントインタイムリカバリ（PITR）について紹介します。このドキュメントは、特定のユースケースにおいてTiDBのバックアップとリストアのソリューションを迅速に導入するのに役立ちます。
 
-AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件を要求しているとします。
+AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件をリクエストしているとします。
 
 - データの変更はタイムリーにバックアップしてください。データベースに災害が発生した場合でも、最小限のデータ損失（許容できるのは数分間のデータ損失のみ）でアプリケーションを迅速に復旧できます。
-- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、要求に応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。
+- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、リクエストに応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。
 
 PITR を使用すると、前述の要件を満たすことができます。