docs: use "the number of X" instead of "X number" for counts (#24361) (#24475)

Author: ti-chi-bot

benchmark/benchmark-tidb-using-ch.md

@@ -64,7 +64,7 @@ creating view revenue1
 
 ## Create TiFlash replicas
 
-After TiFlash is deployed, TiFlash does not automatically replicate TiKV data. You need to execute the following SQL statement to create TiFlash replicas for the `tpcc` database. Once the specified TiFlash replicas are created, TiKV automatically replicates the latest data to TiFlash in real-time. In the following example, two TiFlash nodes are deployed in the cluster and the replica number is set to 2.
+After TiFlash is deployed, TiFlash does not automatically replicate TiKV data. You need to execute the following SQL statement to create TiFlash replicas for the `tpcc` database. Once the specified TiFlash replicas are created, TiKV automatically replicates the latest data to TiFlash in real-time. In the following example, two TiFlash nodes are deployed in the cluster and the number of replicas is set to 2.
 
 ```
 ALTER DATABASE tpcc SET tiflash replica 2;

best-practices/saas-best-practices.md

@@ -77,7 +77,7 @@ By adding appropriate filter conditions to the preceding SQL statements, memory
 In SaaS multi-tenant scenarios, each user usually connects to TiDB to operate data in their own tenant (database). To support a high number of connections:
 
 * Increase the TiDB configuration item [`token-limit`](/tidb-configuration-file.md#token-limit) (`1000` by default) to support more concurrent requests.
-* The memory usage of TiDB is roughly linear with the number of connections. In actual tests, 200,000 idle connections increase TiDB memory usage by about 30 GiB. It is recommended to increase TiDB memory specifications based on actual connection numbers.
+* The memory usage of TiDB is roughly linear with the number of connections. In actual tests, 200,000 idle connections increase TiDB memory usage by about 30 GiB. It is recommended to increase TiDB memory specifications based on the actual number of connections.
 * If you use `PREPARED` statements, each connection maintains a session-level Prepared Plan Cache. If the `DEALLOCATE` statement is not executed for a long time, the cache might accumulate too many plans, increasing memory usage. In actual tests, 400,000 execution plans involving `IndexRangeScan` consume approximately 5 GiB of memory. It is recommended to increase memory specifications accordingly.
 
 ## Use stale read carefully

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

@@ -70,7 +70,7 @@ In this test, the value of this parameter is set to `2`. Observe the **gRPC poll
 
 #### `storage.scheduler-worker-pool-size`
 
-When TiKV detects that the CPU core number of the machine is greater than or equal to `16`, this parameter value defaults to `8`. When the CPU core number is smaller than `16`, the parameter value defaults to `4`. This parameter is used when TiKV converts complex transaction requests to simple key-value reads or writes, but the scheduler thread pool does not perform any writes.
+When TiKV detects that the number of CPU cores of the machine is greater than or equal to `16`, this parameter value defaults to `8`. When the number of CPU cores is smaller than `16`, the parameter value defaults to `4`. This parameter is used when TiKV converts complex transaction requests to simple key-value reads or writes, but the scheduler thread pool does not perform any writes.
 
 Ideally, the usage rate of the scheduler thread pool is kept between 50% and 75%. Similar to the gRPC thread pool, the default value of `storage.scheduler-worker-pool-size` can be too large for a hybrid deployment, resulting in low Scheduler thread pool utilization. In this test, the value of this parameter is set to `2`, which is in line with the best practices, a conclusion drawn by observing the corresponding metrics in the **Scheduler worker CPU** panel.
 

br/br-pitr-guide.md

@@ -144,7 +144,7 @@ The following steps describe how to clean up backup data that exceeds the backup
 > - Log data restore speed = Total size of restored log data on all TiKV nodes in the cluster / (duration * the number of TiKV nodes)
 >
 > External storage only contains KV data of a single replica. Therefore, the data size in external storage does not represent the actual data size restored in the cluster. BR restores all replicas according to the number of replicas configured for the cluster. The more replicas there are, the more data can be actually restored.
-> The default replica number for all clusters in the test is 3.
+> The default number of replicas for all clusters in the test is 3.
 > To improve the overall restore performance, you can modify the [`import.num-threads`](/tikv-configuration-file.md#import) item in the TiKV configuration file and the [`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr) option in the BR command.
 > When the upstream cluster has **many Regions** and a **short flush interval**, PITR generates a large number of small files. This increases batching and dispatching overhead during restore. To raise the number of files processed per batch, you can **moderately** increase the values of the following parameters:
 >

br/br-snapshot-guide.md

@@ -229,7 +229,7 @@ You can use the following methods to manually control the impact of backup tasks
 > - [Scale out a cluster](/tiup/tiup-cluster.md#scale-out-a-cluster) to increase available resources.
 > - Enable [`Log Backup`](/br/br-log-architecture.md) to offload backup pressure and minimize disruption to online workloads.
 
-The impact of backup on cluster performance can be reduced by limiting the backup threads number, but this affects the backup performance. The preceding tests show that the backup speed is proportional to the number of backup threads. When the number of threads is small, the backup speed is about 20 MiB/thread. For example, 5 backup threads on a single TiKV node can reach a backup speed of 100 MiB/s.
+The impact of backup on cluster performance can be reduced by limiting the number of backup threads, but this affects the backup performance. The preceding tests show that the backup speed is proportional to the number of backup threads. When the number of threads is small, the backup speed is about 20 MiB/thread. For example, 5 backup threads on a single TiKV node can reach a backup speed of 100 MiB/s.
 
 ### Performance and impact of snapshot restore
 

dm/dm-best-practices.md

@@ -20,10 +20,10 @@ This document introduces how to use DM in an elegant and efficient way, and how
 | Performance item  | Limitation |
 | ----------------- | :--------: |
 |  Max work nodes              |  1000           |
-|  Max task number             |  600            |
+|  Max number of tasks         |  600            |
 |  Max QPS                     |  30k QPS/worker |
 |  Max Binlog throughput       |  20 MB/s/worker |
-|  Table number limit per task |  Unlimited      |
+|  Max number of tables per task |  Unlimited      |
 
 - DM supports managing 1000 work nodes simultaneously, and the maximum number of tasks is 600. To ensure the high availability of work nodes, you should reserve some work nodes as standby nodes. The recommended number of standby nodes is 20% to 50% of the number of the work nodes that have running migration tasks.
 - A single work node can theoretically support replication QPS of up to 30K QPS/worker. It varies for different schemas and workloads. The ability to handle upstream binlogs is up to 20 MB/s/worker.

information-schema/information-schema-cluster-hardware.md

@@ -42,8 +42,8 @@ Field description:
     * `memory`: The hardware name is memory.
     * `disk`: The disk name.
     * `net`: The network card name.
-* `NAME`: The different information names of the hardware. For example, cpu has two information names: `cpu-logical-cores` and `cpu-physical-cores`, which respectively mean logical core numbers and physical core numbers.
-* `VALUE`: The value of the corresponding hardware information, such as the disk volume and CPU core numbers.
+* `NAME`: The different information names of the hardware. For example, cpu has two information names: `cpu-logical-cores` and `cpu-physical-cores`, which respectively mean the number of logical cores and the number of physical cores.
+* `VALUE`: The value of the corresponding hardware information, such as the disk volume and the number of CPU cores.
 
 The following example shows how to query the CPU information using the `CLUSTER_HARDWARE` table:
 

migrate-with-more-columns-downstream.md

@@ -14,7 +14,7 @@ This document provides the additional steps to be taken when you migrate data to
 
 ## Use DM to migrate data to a downstream TiDB table with more columns
 
-When replicating the upstream binlog, DM tries to use the current table schema of the downstream to parse the binlog and generate the corresponding DML statements. If the column number of the table in the upstream binlog does not match the column number in the downstream table schema, the following error occurs:
+When replicating the upstream binlog, DM tries to use the current table schema of the downstream to parse the binlog and generate the corresponding DML statements. If the number of columns of the table in the upstream binlog does not match the number of columns in the downstream table schema, the following error occurs:
 
 ```json
 "errors": [

multi-data-centers-in-one-city-deployment.md

@@ -103,7 +103,7 @@ The following example assumes that three AZs (AZ1, AZ2, and AZ3) are located in
 
 #### TiKV labels
 
-TiKV is a Multi-Raft system where data is divided into Regions and the size of each Region is 96 MB by default. Three replicas of each Region form a Raft group. For a TiDB cluster of three replicas, because the number of Region replicas is independent of the TiKV instance numbers, three replicas of a Region are only scheduled to three TiKV instances. This means that even if the cluster is scaled out to have N TiKV instances, it is still a cluster of three replicas.
+TiKV is a Multi-Raft system where data is divided into Regions and the size of each Region is 96 MB by default. Three replicas of each Region form a Raft group. For a TiDB cluster of three replicas, because the number of Region replicas is independent of the number of TiKV instances, three replicas of a Region are only scheduled to three TiKV instances. This means that even if the cluster is scaled out to have N TiKV instances, it is still a cluster of three replicas.
 
 Because a Raft group of three replicas tolerates only one replica failure, even if the cluster is scaled out to have N TiKV instances, this cluster still tolerates only one replica failure. Two failed TiKV instances might cause some Regions to lose replicas and the data in this cluster is no longer complete. SQL requests that access data from these Regions will fail. The probability of two simultaneous failures among N TiKV instances is much higher than the probability of two simultaneous failures among three TiKV instances. This means that the more TiKV instances the Multi-Raft system is scaled out to have, the less the availability of the system.
 

ticdc/ticdc-open-api.md

@@ -125,7 +125,7 @@ Compared to the optional parameters for creating a replication task using the `c
 | `ignore_ineligible_table` | `BOOLEAN` type. Determines whether to ignore the tables that cannot be replicated. (Optional) |
 | `filter_rules` | `STRING` type array. The rules for table schema filtering. (Optional) |
 | `ignore_txn_start_ts` | `UINT64` type array. Ignores the transaction of a specified start_ts. (Optional) |
-| `mounter_worker_num` | `INT` type. The mounter thread number. (Optional) |
+| `mounter_worker_num` | `INT` type. The number of mounter threads. (Optional) |
 | `sink_config` | The configuration parameters of sink. (Optional) |
 
 The meaning and format of `changefeed_id`, `start_ts`, `target_ts`, and `sink_uri` are the same as those described in the [Use `cdc cli` to create a replication task](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task) document. For the detailed description of these parameters, see this document. Note that when you specify the certificate path in `sink_uri`, make sure you have uploaded the corresponding certificate to the corresponding TiCDC server.
@@ -233,7 +233,7 @@ Currently, only the following configuration can be modified via the API.
 | `sink_uri` | `STRING` type. The downstream address of the replication task. (Optional) |
 | `filter_rules` | `STRING` type array. The rules for table schema filtering. (Optional) |
 | `ignore_txn_start_ts` | `UINT64` type array. Ignores the transaction of a specified start_ts. (Optional) |
-| `mounter_worker_num` | `INT` type. The mounter thread number. (Optional) |
+| `mounter_worker_num` | `INT` type. The number of mounter threads. (Optional) |
 | `sink_config` | The configuration parameters of sink. (Optional) |
 
 The meanings of the above parameters are the same as those in the [Create a replication task](#create-a-replication-task) section. See that section for details.