From 35c28c3169d8c9d59aaa0e145585a6caa8c04766 Mon Sep 17 00:00:00 2001 From: Docsite Preview Bot <> Date: Fri, 10 Jan 2025 05:24:20 +0000 Subject: [PATCH] Preview PR https://github.com/pingcap/docs/pull/19717 and this preview is triggered from commit https://github.com/pingcap/docs/pull/19717/commits/8272325c7792d592204e19148d44fe5cf7e13fb0 --- markdown-pages/en/tidbcloud/master/TOC.md | 2 +- .../tidb-cloud/backup-and-restore-concepts.md | 2 +- .../master/tidb-cloud/data-service-concepts.md | 2 ++ .../master/tidb-cloud/data-streaming-concepts.md | 2 +- .../master/tidb-cloud/database-schema-concepts.md | 12 ++++++++---- .../tidb-cloud/high-availability-with-multi-az.md | 14 +++++++------- .../master/tidb-cloud/monitoring-concepts.md | 5 +++-- .../master/tidb-cloud/scalability-concepts.md | 12 ++++-------- .../master/tidb-cloud/security-concepts.md | 3 +-- .../en/tidbcloud/master/tidb-cloud/sql-concepts.md | 12 ++++++------ .../master/tidb-cloud/transaction-concepts.md | 11 ++++++----- 11 files changed, 40 insertions(+), 37 deletions(-) diff --git a/markdown-pages/en/tidbcloud/master/TOC.md b/markdown-pages/en/tidbcloud/master/TOC.md index e9f3c78..97ad034 100644 --- a/markdown-pages/en/tidbcloud/master/TOC.md +++ b/markdown-pages/en/tidbcloud/master/TOC.md @@ -24,7 +24,7 @@ - [Data Service](/tidb-cloud/data-service-concepts.md) ![BETA](/media/tidb-cloud/blank_transparent_placeholder.png) - [Scalability](/tidb-cloud/scalability-concepts.md) - High Availability - - [Multi-AZ Deployments](/tidb-cloud/high-availability-with-multi-az.md) + - [High Availability in TiDB Cloud Dedicated](/tidb-cloud/high-availability-with-multi-az.md) - [High Availability in TiDB Cloud Serverless](/tidb-cloud/serverless-high-availability.md) - [Monitoring](/tidb-cloud/monitoring-concepts.md) - [Data Streaming](/tidb-cloud/data-streaming-concepts.md) diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/backup-and-restore-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/backup-and-restore-concepts.md index 5ce29b6..4a91f2c 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/backup-and-restore-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/backup-and-restore-concepts.md @@ -26,7 +26,7 @@ If you want to choose the restore point as required, that is, to perform point-i ## Manual backup -Dual region backup is a feature of TiDB Cloud Dedicated that enables you to back up your data to a known state as needed, and then restore to that state at any time. +Manual backup is a feature of TiDB Cloud Dedicated that enables you to back up your data to a known state as needed, and then restore to that state at any time. For more information, see [Perform a manual backup](/tidb-cloud/backup-and-restore.md#perform-a-manual-backup). diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/data-service-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/data-service-concepts.md index 677376f..264fde8 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/data-service-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/data-service-concepts.md @@ -34,6 +34,7 @@ For more information, see [Get Started with Chat2Query API](/tidb-cloud/use-chat Integrating third-party tools with your Data App enhances your applications with advanced natural language processing and artificial intelligence (AI) capabilities provided by third-party tools. This integration enables your applications to perform more complex tasks and deliver intelligent solutions. Currently, you can integrate third-party tools, such as GPTs and Dify, in the TiDB Cloud console. + For more information, see [Integrate a Data App with Third-Party Tools](/tidb-cloud/data-service-integrations.md). ## Configuration as Code @@ -41,6 +42,7 @@ For more information, see [Integrate a Data App with Third-Party Tools](/tidb-cl TiDB Cloud provides a Configuration as Code (CaC) approach to represent your entire Data App configurations as code using the JSON syntax. By connecting your Data App to GitHub, TiDB Cloud can use the CaC approach and push your Data App configurations as [configuration files](/tidb-cloud/data-service-app-config-files.md) to your preferred GitHub repository and branch. + If Auto Sync & Deployment is enabled for your GitHub connection, you can also modify your Data App by updating its configuration files on GitHub. After you push the configuration file changes to GitHub, the new configurations will be deployed in TiDB Cloud automatically. For more information, see [Deploy Data App Automatically with GitHub](/tidb-cloud/data-service-manage-github-connection.md). \ No newline at end of file diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/data-streaming-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/data-streaming-concepts.md index 665057f..4a9d533 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/data-streaming-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/data-streaming-concepts.md @@ -7,7 +7,7 @@ summary: Learn about data streaming concepts for TiDB Cloud. TiDB Cloud lets you stream data changes from your TiDB Cluster to other systems like Kafka, MySQL, and object storage. -Currently, TiDB Cloud supports streaming data to Apache Kafka, MySQL, TiDB Cloud and cloud storage. +Currently, TiDB Cloud supports streaming data to Apache Kafka, MySQL, TiDB Cloud, and cloud storage. ## Changefeed diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/database-schema-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/database-schema-concepts.md index 162e2be..fbf3bcc 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/database-schema-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/database-schema-concepts.md @@ -37,7 +37,7 @@ Each table consists of rows and columns. Each value in a row belongs to a specif ### System table -- The `mysql` schema contains TiDB system tables. The design is similar to the `mysql` schema in MySQL, where tables such as `mysql.user` can be edited directly. It also contains a number of tables which are extensions to MySQL. +- The `mysql` schema contains TiDB system tables. The design is similar to the `mysql` schema in MySQL, where tables such as `mysql.user` can be edited directly. It also contains a number of tables that are extensions to MySQL. - Information Schema provides an ANSI-standard way of viewing system metadata. TiDB also provides a number of custom `INFORMATION_SCHEMA` tables, in addition to the tables included for MySQL compatibility. Many `INFORMATION_SCHEMA` tables have a corresponding `SHOW` command. The benefit of querying `INFORMATION_SCHEMA` is that it is possible to join between tables. @@ -76,6 +76,7 @@ TiDB supports all the data types in MySQL except the `SPATIAL` type. This includ ## Indexes An index is a copy of selected columns in a table. You can create an index using one or more columns of a [table](/develop/dev-guide-schema-design-overview.md#table). With indexes, TiDB can quickly locate data without having to search every row in a table every time, which greatly improves your query performance. + There are two common types of indexes: - Primary Key: indexes on the primary key column. @@ -98,7 +99,7 @@ A composite index is an index built on two or more columns of a table, which is Invisible indexes are indexes that exist in the database but are hidden from the query optimizer, meaning they are ignored in query plans. In TiDB, invisible indexes are useful for testing and debugging, allowing you to assess the impact of an index on performance without fully dropping it. -Starting from TiDB v8.0.0, you can make the optimizer select invisible indexes by modifying the system variable[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800). +Starting from TiDB v8.0.0, you can make the optimizer select invisible indexes by modifying the [`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800) system variable. ### Clustered indexes @@ -124,7 +125,8 @@ For the following TiDB deployment options, TiDB supports vector data types and v - TiDB Self-Managed v8.4.0 or later versions -In TiDB, a *vector index* is a specialized index designed for efficient approximate nearest neighbor (ANN) searches over columns containing vector data. Vector indexes, particularly the HNSW (Hierarchical Navigable Small World) algorithm, allow K-nearest neighbors (KNN) searches to identify the closest data points in a vector space quickly. This significantly speeds up query performance, enabling results in milliseconds compared to brute-force methods. +In TiDB, a vector index is a specialized index designed for efficient approximate nearest neighbor (ANN) searches over columns containing vector data. Vector indexes, particularly the HNSW (Hierarchical Navigable Small World) algorithm, allow K-nearest neighbors (KNN) searches to identify the closest data points in a vector space quickly. This significantly speeds up query performance, enabling results in milliseconds compared to brute-force methods. + Vector indexes rely on TiFlash replicas for data storage and search functionality. Before creating and using vector indexes, make sure that TiFlash nodes are available in your cluster. ## Constraints @@ -134,6 +136,7 @@ TiDB supports almost the same constraints as MySQL. ### NOT NULL constraints A `NOT NULL` constraint ensures that a column cannot contain `NULL` values. + When a column is defined with the `NOT NULL` constraint, TiDB ensures that any attempt to insert or update a row with a `NULL` value in that column will result in an error. This behavior is consistent with MySQL's implementation of `NOT NULL` constraints. ### CHECK constraints @@ -153,13 +156,14 @@ Unique constraints mean that all non-null values in a unique index and a primary A FOREIGN KEY is a database constraint that enforces referential integrity between two tables by linking a column in one table (the child table) to a column in another table (the parent table). This ensures that the values in the foreign key column of the child table match values in the primary or unique key column of the parent table. For example, a record in an `orders` table might have a foreign key linking to a customer in a `customers` table, which ensures that each order is associated with a valid customer. Starting from v6.6.0, TiDB supports foreign key constraints as an experimental feature. This feature allows cross-table referencing of related data and helps maintain data consistency by enforcing referential integrity. However, it is important to note that this feature is experimental and not recommended for production environments due to potential performance issues, especially with large data volumes. + For more information, see [FOREIGN KEY constraints](/foreign-key.md). ## Views A view acts as a virtual table, whose schema is defined by the `SELECT` statement that creates the view. Using views has the following benefits: -- Exposing only safe fields and data to users to ensure security of sensitive fields and data stored in the underlying table. +- Exposing only safe fields and data to users to ensure the security of sensitive fields and data stored in the underlying table. - Defining complex queries that frequently appear as views to make complex queries easier and more convenient. diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/high-availability-with-multi-az.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/high-availability-with-multi-az.md index 1741634..a8e958c 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/high-availability-with-multi-az.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/high-availability-with-multi-az.md @@ -1,22 +1,22 @@ --- -title: High Availability with Multi-AZ Deployments -summary: TiDB Cloud supports high availability with Multi-AZ deployments. +title: High Availability in TiDB Cloud Dedicated +summary: TiDB Cloud Dedicated supports high availability with Multi-AZ deployments. --- -# High Availability with Multi-AZ Deployments +# High Availability in TiDB Cloud Dedicated TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. Data is redundantly copied between storage nodes and placed in different availability zones to protect against machine or data center failures. With automatic failover, TiDB ensures that your service is always on. -TiDB Cloud clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component for TiDB Cloud Dedicated is as follows: +TiDB Cloud Dedicated clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component for TiDB Cloud Dedicated is as follows: * **TiDB node** - TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud deploys TiDB nodes evenly to different availability zones in a region. When a user executes a SQL request, the request first passes through a load balancer deployed across availability zones, and then the load balancer distributes the request to different TiDB nodes for execution. It is recommended that each TiDB Cloud cluster has at least two TiDB nodes for high availability. + TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud Dedicated deploys TiDB nodes evenly to different availability zones in a region. When a user executes a SQL request, the request first passes through a load balancer deployed across availability zones, and then the load balancer distributes the request to different TiDB nodes for execution. It is recommended that each TiDB Cloud Dedicated cluster has at least two TiDB nodes for high availability. * **TiKV node** - [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) is the row-based storage layer of TiDB Cloud cluster with horizontal scalability. On TiDB Cloud, the minimum number of TiKV nodes for a cluster is 3. TiDB Cloud deploys TiKV nodes evenly to all availability zones (at least 3) in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node. + [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) is the row-based storage layer of TiDB Cloud Dedicated cluster with horizontal scalability. The minimum number of TiKV nodes for a TiDB Cloud Dedicated cluster is 3. TiDB Cloud Dedicated deploys TiKV nodes evenly to all availability zones (at least 3) in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node. * **TiFlash node** - [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview), as a columnar storage extension of TiKV, is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlash, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. TiDB Cloud deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud cluster and create at least two replicas of the data for high availability in your production environment. + [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview), as a columnar storage extension of TiKV, is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlash, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. TiDB Cloud Dedicated deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud Dedicated cluster and create at least two replicas of the data for high availability in your production environment. diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/monitoring-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/monitoring-concepts.md index 9bdb9d9..bd242bb 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/monitoring-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/monitoring-concepts.md @@ -9,7 +9,7 @@ Monitoring in TiDB Cloud provides tools and integrations that enable you to over ## Built-in metrics -Built-in Metrics refer to a full set of standard metrics of your cluster that TiDB Cloud collects and presents on the Metrics page. With these metrics, you can easily identify performance issues and determine whether your current database deployment meets your requirements. +Built-in metrics refer to a full set of standard metrics of your cluster that TiDB Cloud collects and presents on the Metrics page. With these metrics, you can easily identify performance issues and determine whether your current database deployment meets your requirements. For more information, see [TiDB Cloud Built-in Metrics](/tidb-cloud/built-in-monitoring.md). @@ -29,7 +29,7 @@ For more information, see [TiDB Cloud Built-in Alerting](/tidb-cloud/monitor-bui ## Cluster events -In TiDB Cloud, an *event* indicates a change in your TiDB Cloud cluster. TiDB Cloud logs the historical events at the cluster level to help you track cluster activities. You can view the logged events on the **Events** page, including the event type, status, message, trigger time, and trigger user. +In TiDB Cloud, an event indicates a change in your TiDB Cloud cluster. TiDB Cloud logs the historical events at the cluster level to help you track cluster activities. You can view the logged events on the **Events** page, including the event type, status, message, trigger time, and trigger user. For more information, see [TiDB Cloud Cluster Event](/tidb-cloud/tidb-cloud-events.md). @@ -44,4 +44,5 @@ TiDB Cloud lets you integrate any of the following third-party metrics services - New Relic integration Currently, these third-party metrics integrations are in beta. + For more information, see [Third-Party Metrics Integration (Beta)](/tidb-cloud/third-party-monitoring-integrations.md). \ No newline at end of file diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/scalability-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/scalability-concepts.md index e2cc960..8a2dd30 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/scalability-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/scalability-concepts.md @@ -9,7 +9,7 @@ TiDB Cloud Dedicated lets you adjust its compute and storage resources separatel > **Note:** > -> [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) scales automatically based on your application's workload changes. However, you cannot manually scale a TiDB Cloud Serverless cluster. +> [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) scales automatically based on your application's workload changes. However, you cannot manually scale a TiDB Cloud Serverless cluster. > **Tip:** > @@ -26,22 +26,18 @@ A combination of both vertical and horizontal scaling is also supported in TiDB ## TiDB scalability -TiDB is for computing only and does not store data. You can configure node number, vCPU, and RAM for TiDB. +TiDB is for computing only and does not store data. You can configure the node number, vCPU, and RAM for TiDB. In general, TiDB performance increases linearly with the number of TiDB nodes. -## Storage scalability - -In TiDB Cloud, you can scale both row-based and columnar data storage on-demand to meet changing workloads and performance requirements - ## TiKV scalability -TiKV is responsible for storing row-based data. You can configure node number, vCPU and RAM, and storage for TiKV. The number of TiKV nodes should be at least 1 set (3 nodes in 3 different Available Zones) and increase by 3 nodes. +TiKV is responsible for storing row-based data. You can configure the node number, vCPU and RAM, and storage for TiKV. The number of TiKV nodes should be at least 1 set (3 nodes in 3 different available zones) and increase by 3 nodes. TiDB Cloud deploys TiKV nodes evenly to 3 available zones in the region you select to achieve durability and high availability. In a typical 3-replica setup, your data is distributed evenly among the TiKV nodes across all availability zones and is persisted to the disk of each TiKV node. Although TiKV is mainly used for data storage, the performance of the TiKV node also varies depending on different workloads. ## TiFlash scalability -TiFlash is responsible for storing columnar data. TiFlash synchronizes data from TiKV in real time and supports real-time analytics workloads right out of the box. You can configure node number, vCPU and RAM, and storage for TiFlash. +TiFlash is responsible for storing columnar data. TiFlash synchronizes data from TiKV in real time and supports real-time analytics workloads right out of the box. You can configure the node number, vCPU and RAM, and storage for TiFlash. TiDB Cloud deploys TiFlash nodes evenly to different availability zones in a region. It is recommended that you configure at least two TiFlash nodes in each TiDB Cloud cluster and create at least two replicas of the data for high availability in your production environment. \ No newline at end of file diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/security-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/security-concepts.md index 9bc598d..f677319 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/security-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/security-concepts.md @@ -138,7 +138,6 @@ TiDB Cloud manages users and resources with a hierarchical structure: organizati - Project 3 - Cluster 5 - Cluster 6 - ``` ### Key features @@ -201,7 +200,7 @@ TiDB Cloud safeguards static data with advanced encryption capabilities, ensurin **Customer-Managed Encryption Key (CMEK)** -- Provides organizations full control over encryption for Dedicated clusters. +- Provides organizations full control over encryption for TiDB Cloud Dedicated clusters. - Encrypts static data and backups with CMEK keys when enabled. diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/sql-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/sql-concepts.md index 1a6a2d8..3be8502 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/sql-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/sql-concepts.md @@ -19,7 +19,7 @@ SQL is divided into the following 4 types according to their functions: - DDL (Data Definition Language): It is used to define database objects, including databases, tables, views, and indexes. For DDL statements in TiDB, see [Schema management / Data definition statements (DDL)](/sql-statements/sql-statement-overview.md#schema-management--data-definition-statements-ddl). -- DML (Data Manipulation Language): It is used to manipulate application related records. For DML statements in TiDB, see [Data manipulation statements (DML)](/sql-statements/sql-statement-overview.md#data-manipulation-statements-dml). +- DML (Data Manipulation Language): It is used to manipulate application-related records. For DML statements in TiDB, see [Data manipulation statements (DML)](/sql-statements/sql-statement-overview.md#data-manipulation-statements-dml). - DQL (Data Query Language): It is used to query the records after conditional filtering. @@ -35,7 +35,7 @@ For more information, see [SQL Mode](/sql-mode.md). ## Row ID generation attributes -TiDB provides three SQL attributes to optimize row ID generation and data distribution to address performance and scalability challenges. +TiDB provides three SQL attributes to optimize row ID generation and data distribution. - AUTO_INCREMENT @@ -55,9 +55,9 @@ For more information, see [AUTO_INCREMENT](/auto-increment.md). ### AUTO_RANDOM -`AUTO_RANDOM` is a column attribute that is used to automatically assign values to a `BIGINT` column. Values assigned automatically are random and unique. Since the value of `AUTO_RANDOM` is random and unique, `AUTO_RANDOM` is often used in place of [`AUTO_INCREMENT`](/auto-increment.md) to avoid write hotspot in a single storage node caused by TiDB assigning consecutive IDs. +`AUTO_RANDOM` is a column attribute that is used to automatically assign values to a `BIGINT` column. Values assigned automatically are random and unique. Since the value of `AUTO_RANDOM` is random and unique, `AUTO_RANDOM` is often used in place of [`AUTO_INCREMENT`](/auto-increment.md) to avoid write hotspots in a single storage node caused by TiDB assigning consecutive IDs. -Since the value of `AUTO_RANDOM` is random and unique, `AUTO_RANDOM` is often used in place of [`AUTO_INCREMENT`](/auto-increment.md)to avoid write hotspot in a single storage node caused by TiDB assigning consecutive IDs. If the current `AUTO_INCREMENT` column is a primary key and the type is `BIGINT`, you can execute the `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);` statement to switch from `AUTO_INCREMENT` to `AUTO_RANDOM`. +Since the value of `AUTO_RANDOM` is random and unique, `AUTO_RANDOM` is often used in place of [`AUTO_INCREMENT`](/auto-increment.md) to avoid write hotspots in a single storage node caused by TiDB assigning consecutive IDs. If the current `AUTO_INCREMENT` column is a primary key and the type is `BIGINT`, you can execute the `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);` statement to switch from `AUTO_INCREMENT` to `AUTO_RANDOM`. For more information, see [AUTO_RANDOM](/auto-random.md). @@ -65,7 +65,7 @@ For more information, see [AUTO_RANDOM](/auto-random.md). For the tables with a non-clustered primary key or no primary key, TiDB uses an implicit auto-increment row ID. When a large number of `INSERT` operations are performed, the data is written into a single Region, causing a write hot spot. -To mitigate the hot spot issue, you can configure [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md). The row IDs are scattered and the data are written into multiple different Regions. +To mitigate the hot spot issue, you can configure [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md). The row IDs are scattered, and the data are written into multiple different Regions. ## Keywords @@ -75,7 +75,7 @@ Keywords are words that have special meanings in SQL statements, such as `SELECT - Some of them require special treatment before being used as identifiers, which are called reserved keywords. -However, there are special non-reserved keywords that might still require special treatment. It is recommended that you treat them as reserved keywords. +However, some non-reserved keywords might still require special treatment. It is recommended that you treat them as reserved keywords. For more information, see [Keywords](/keywords.md). diff --git a/markdown-pages/en/tidbcloud/master/tidb-cloud/transaction-concepts.md b/markdown-pages/en/tidbcloud/master/tidb-cloud/transaction-concepts.md index e5e04a7..d5ec363 100644 --- a/markdown-pages/en/tidbcloud/master/tidb-cloud/transaction-concepts.md +++ b/markdown-pages/en/tidbcloud/master/tidb-cloud/transaction-concepts.md @@ -1,17 +1,17 @@ --- title: Transactions -summary: Learn about transactions concepts for TiDB Cloud. +summary: Learn about transaction concepts for TiDB Cloud. --- # Transactions -TiDB provides complete distributed transactions and the model has some optimizations on the basis of [Google Percolator](https://research.google.com/pubs/pub36726.html). +TiDB provides complete distributed transactions, and the model has some optimizations on the basis of [Google Percolator](https://research.google.com/pubs/pub36726.html). ## Optimistic transaction mode -TiDB's optimistic transaction model does not detect conflicts until the commit phase. If there are conflicts, the transaction needs retry. But this model is inefficient if the conflict is severe, because operations before retry are invalid and need to repeat. +TiDB's optimistic transaction model does not detect conflicts until the commit phase. If there are conflicts, the transaction needs a retry. But this model is inefficient if the conflict is severe, because operations before the retry are invalid and need to repeat. -Assume that the database is used as a counter. High access concurrency might lead to severe conflicts, resulting in multiple retries or even timeouts. Therefore, in the scenario of severe conflicts, it is recommended to use the pessimistic transaction mode or to solve problems at the system architecture level, such as placing counter in Redis. Nonetheless, the optimistic transaction model is efficient if the access conflict is not very severe. +Assume that the database is used as a counter. High access concurrency might lead to severe conflicts, resulting in multiple retries or even timeouts. Therefore, in the scenario of severe conflicts, it is recommended to use the pessimistic transaction mode or to solve problems at the system architecture level, such as placing a counter in Redis. Nonetheless, the optimistic transaction model is efficient if the access conflict is not very severe. For more information, see [TiDB Optimistic Transaction Model](/optimistic-transaction.md). @@ -20,11 +20,12 @@ For more information, see [TiDB Optimistic Transaction Model](/optimistic-transa In TiDB, the pessimistic transaction mode has almost the same behavior as in MySQL. The transaction applies a lock during the execution phase, which avoids retries in conflict situations and ensures a higher success rate. By applying the pessimistic locking, you can also lock data in advance using `SELECT FOR UPDATE`. However, if the application scenario has fewer conflicts, the optimistic transaction model has better performance. + For more information, see [TiDB Pessimistic Transaction Mode](/pessimistic-transaction.md). ## Transaction isolation levels -Transaction isolation is one of the foundations of database transaction processing. Isolation is one of the four key properties of a transaction (commonly referred as [ACID](/tidb-cloud/tidb-cloud-glossary.md#acid)). +Transaction isolation is one of the foundations of database transaction processing. Isolation is one of the four key properties of a transaction (commonly referred to as [ACID](/tidb-cloud/tidb-cloud-glossary.md#acid)). TiDB implements Snapshot Isolation (SI) consistency, which it advertises as `REPEATABLE-READ` for compatibility with MySQL. This differs from the [ANSI Repeatable Read isolation level](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read) and the [MySQL Repeatable Read level](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read).