diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 62fa93f5527e8..2d43aafb66f3c 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -9,11 +9,11 @@ This document describes best practices for handling highly-concurrent write-heav ## Target audience -This document assumes that you have a basic understanding of TiDB. It is recommended that you first read the following three blog articles that explain TiDB fundamentals, and [TiDB Best Practices](https://en.pingcap.com/blog/tidb-best-practice/): +This document assumes that you have a basic understanding of TiDB. It is recommended that you first read the following three blog articles that explain TiDB fundamentals, and [TiDB Best Practices](https://www.pingcap.com/blog/tidb-best-practice/): -+ [Data Storage](https://en.pingcap.com/blog/tidb-internal-data-storage/) -+ [Computing](https://en.pingcap.com/blog/tidb-internal-computing/) -+ [Scheduling](https://en.pingcap.com/blog/tidb-internal-scheduling/) ++ [Data Storage](https://www.pingcap.com/blog/tidb-internal-data-storage/) ++ [Computing](https://www.pingcap.com/blog/tidb-internal-computing/) ++ [Scheduling](https://www.pingcap.com/blog/tidb-internal-scheduling/) ## Highly-concurrent write-intensive scenario @@ -32,7 +32,7 @@ For a distributed database, it is important to make full use of the capacity of ## Data distribution principles in TiDB -To address the above challenges, it is necessary to start with the data segmentation and scheduling principle of TiDB. Refer to [Scheduling](https://en.pingcap.com/blog/tidb-internal-scheduling/) for more details. +To address the above challenges, it is necessary to start with the data segmentation and scheduling principle of TiDB. Refer to [Scheduling](https://www.pingcap.com/blog/tidb-internal-scheduling/) for more details. TiDB splits data into Regions, each representing a range of data with a size limit of 96M by default. Each Region has multiple replicas, and each group of replicas is called a Raft Group. In a Raft Group, the Region Leader executes the read and write tasks (TiDB supports [Follower-Read](/follower-read.md)) within the data range. The Region Leader is automatically scheduled by the Placement Driver (PD) component to different physical nodes evenly to distribute the read and write pressure. diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 963c603f94060..74f4e3b1e2860 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -9,9 +9,9 @@ This document summarizes the best practices of using TiDB, including the use of Before you read this document, it is recommended that you read three blog posts that introduce the technical principles of TiDB: -* [TiDB Internal (I) - Data Storage](https://en.pingcap.com/blog/tidb-internal-data-storage/) -* [TiDB Internal (II) - Computing](https://en.pingcap.com/blog/tidb-internal-computing/) -* [TiDB Internal (III) - Scheduling](https://en.pingcap.com/blog/tidb-internal-scheduling/) +* [TiDB Internal (I) - Data Storage](https://www.pingcap.com/blog/tidb-internal-data-storage/) +* [TiDB Internal (II) - Computing](https://www.pingcap.com/blog/tidb-internal-computing/) +* [TiDB Internal (III) - Scheduling](https://www.pingcap.com/blog/tidb-internal-scheduling/) ## Preface @@ -67,7 +67,7 @@ Placement Driver (PD) balances the load of the cluster according to the status o ### SQL on KV -TiDB automatically maps the SQL structure into Key-Value structure. For details, see [TiDB Internal (II) - Computing](https://en.pingcap.com/blog/tidb-internal-computing/). +TiDB automatically maps the SQL structure into Key-Value structure. For details, see [TiDB Internal (II) - Computing](https://www.pingcap.com/blog/tidb-internal-computing/). Simply put, TiDB performs the following operations: diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index 0ff0922d772d9..810939755a4ec 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -37,7 +37,7 @@ This section introduces the basic concepts that relate to Key Visualizer. In a TiDB cluster, the stored data is distributed among TiKV instances. Logically, TiKV is a huge and orderly key-value map. The whole key-value space is divided into many segments and each segment consists of a series of adjacent keys. Such segment is called a `Region`. -For detailed introduction of Region, refer to [TiDB Internal (I) - Data Storage](https://en.pingcap.com/blog/tidb-internal-data-storage/). +For detailed introduction of Region, refer to [TiDB Internal (I) - Data Storage](https://www.pingcap.com/blog/tidb-internal-data-storage/). ### Hotspot diff --git a/explore-htap.md b/explore-htap.md index 18f172fa93e90..a5ffeb79725c7 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -29,7 +29,7 @@ The following are the typical use cases of HTAP: When using TiDB as a data hub, TiDB can meet specific business needs by seamlessly connecting the data for the application and the data warehouse. -For more information about use cases of TiDB HTAP, see [blogs about HTAP on the PingCAP website](https://en.pingcap.com/blog/?tag=htap). +For more information about use cases of TiDB HTAP, see [blogs about HTAP on the PingCAP website](https://www.pingcap.com/blog/?tag=htap). ## Architecture diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index c0dcfc4a2e083..e51c9b0e1392e 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -170,13 +170,13 @@ Yes. But the `load data` does not support the `replace into` syntax. ### Why does the query speed getting slow after deleting data? -Deleting a large amount of data leaves a lot of useless keys, affecting the query efficiency. Currently the Region Merge feature is in development, which is expected to solve this problem. For details, see the [deleting data section in TiDB Best Practices](https://en.pingcap.com/blog/tidb-best-practice/#write). +Deleting a large amount of data leaves a lot of useless keys, affecting the query efficiency. Currently the Region Merge feature is in development, which is expected to solve this problem. For details, see the [deleting data section in TiDB Best Practices](https://www.pingcap.com/blog/tidb-best-practice/#write). ### What is the most efficient way of deleting data? When deleting a large amount of data, it is recommended to use `Delete from t where xx limit 5000;`. It deletes through the loop and uses `Affected Rows == 0` as a condition to end the loop, so as not to exceed the limit of transaction size. With the prerequisite of meeting business filtering logic, it is recommended to add a strong filter index column or directly use the primary key to select the range, such as `id >= 5000*n+m and id < 5000*(n+1)+m`. -If the amount of data that needs to be deleted at a time is very large, this loop method will get slower and slower because each deletion traverses backward. After deleting the previous data, lots of deleted flags remain for a short period (then all will be processed by Garbage Collection) and influence the following Delete statement. If possible, it is recommended to refine the Where condition. See [details in TiDB Best Practices](https://en.pingcap.com/blog/tidb-best-practice/#write). +If the amount of data that needs to be deleted at a time is very large, this loop method will get slower and slower because each deletion traverses backward. After deleting the previous data, lots of deleted flags remain for a short period (then all will be processed by Garbage Collection) and influence the following Delete statement. If possible, it is recommended to refine the Where condition. See [details in TiDB Best Practices](https://www.pingcap.com/blog/tidb-best-practice/#write). ### How to improve the data loading speed in TiDB? diff --git a/faq/sql-faq.md b/faq/sql-faq.md index ba2b32d2b3af4..184125ee9d391 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -130,7 +130,7 @@ Yes. The exception being that `LOAD DATA` does not currently support the `REPLAC ## Why does the query speed get slow after data is deleted? -Deleting a large amount of data leaves a lot of useless keys, affecting the query efficiency. Currently the [Region Merge](/best-practices/massive-regions-best-practices.md) feature is in development, which is expected to solve this problem. For details, see the [deleting data section in TiDB Best Practices](https://en.pingcap.com/blog/tidb-best-practice/#write). +Deleting a large amount of data leaves a lot of useless keys, affecting the query efficiency. Currently the [Region Merge](/best-practices/massive-regions-best-practices.md) feature is in development, which is expected to solve this problem. For details, see the [deleting data section in TiDB Best Practices](https://www.pingcap.com/blog/tidb-best-practice/#write). ## What should I do if it is slow to reclaim storage space after deleting data? diff --git a/telemetry.md b/telemetry.md index 011be2f8dc86e..a49eea9251d9b 100644 --- a/telemetry.md +++ b/telemetry.md @@ -261,4 +261,4 @@ To meet compliance requirements in different countries or regions, the usage inf - For IP addresses from the Chinese mainland, usage information is sent to and stored on cloud servers in the Chinese mainland. - For IP addresses from outside of the Chinese mainland, usage information is sent to and stored on cloud servers in the US. -See [PingCAP Privacy Policy](https://en.pingcap.com/privacy-policy/) for details. +See [PingCAP Privacy Policy](https://www.pingcap.com/privacy-policy/) for details. diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index f05f9db00530b..e2a3bab82d3e0 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -15,7 +15,7 @@ In TiFlash, the columnar replicas are asynchronously replicated according to the The above figure is the architecture of TiDB in its HTAP form, including TiFlash nodes. -TiFlash provides the columnar storage, with a layer of coprocessors efficiently implemented by ClickHouse. Similar to TiKV, TiFlash also has a Multi-Raft system, which supports replicating and distributing data in the unit of Region (see [Data Storage](https://en.pingcap.com/blog/tidb-internal-data-storage/) for details). +TiFlash provides the columnar storage, with a layer of coprocessors efficiently implemented by ClickHouse. Similar to TiKV, TiFlash also has a Multi-Raft system, which supports replicating and distributing data in the unit of Region (see [Data Storage](https://www.pingcap.com/blog/tidb-internal-data-storage/) for details). TiFlash conducts real-time replication of data in the TiKV nodes at a low cost that does not block writes in TiKV. Meanwhile, it provides the same read consistency as in TiKV and ensures that the latest data is read. The Region replica in TiFlash is logically identical to those in TiKV, and is split and merged along with the Leader replica in TiKV at the same time.