This is an automated email from the ASF dual-hosted git repository.
kassiez pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new fa45f8c987 [doc](update) update concurrent control (#1487)
fa45f8c987 is described below
commit fa45f8c987017a6ebe0719a12a3f2fcaa8d5c036
Author: zhannngchen <zhangc...@selectdb.com>
AuthorDate: Mon Dec 16 11:23:41 2024 +0800
[doc](update) update concurrent control (#1487)
1. add overview for `UPDATE` concurrent control
2. change the title and doc name from `update transaction` to `update
concurrent control`
3. update sidebars
4. fix some typos
## Versions
- [x] dev
- [x] 3.0
- [x] 2.1
- [x] 2.0
## Languages
- [x] Chinese
- [x] English
## Docs Checklist
- [x] Checked by AI
- [ ] Test Cases Built
---
.../update/unique-update-concurrent-control.md | 20 ++++++++++++++++----
docs/data-operate/update/update-overview.md | 2 +-
...action.md => unique-update-concurrent-control.md} | 20 ++++++++++++++------
.../current/data-operate/update/update-overview.md | 2 +-
.../update/unique-update-concurrent-control.md} | 20 ++++++++++++++------
.../data-operate/update/update-overview.md | 2 +-
.../update/unique-update-concurrent-control.md} | 20 ++++++++++++++------
.../data-operate/update/update-overview.md | 2 +-
.../update/unique-update-concurrent-control.md} | 20 ++++++++++++++------
.../data-operate/update/update-overview.md | 2 +-
sidebars.json | 2 +-
.../update/unique-update-concurrent-control.md | 18 +++++++++++++++---
.../data-operate/update/update-overview.md | 2 +-
.../update/unique-update-concurrent-control.md} | 18 +++++++++++++++---
.../data-operate/update/update-overview.md | 2 +-
.../update/unique-update-concurrent-control.md} | 18 +++++++++++++++---
.../data-operate/update/update-overview.md | 2 +-
versioned_sidebars/version-2.0-sidebars.json | 2 +-
versioned_sidebars/version-2.1-sidebars.json | 2 +-
versioned_sidebars/version-3.0-sidebars.json | 2 +-
20 files changed, 129 insertions(+), 49 deletions(-)
diff --git
a/versioned_docs/version-3.0/data-operate/update/unique-update-transaction.md
b/docs/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
versioned_docs/version-3.0/data-operate/update/unique-update-transaction.md
rename to docs/data-operate/update/unique-update-concurrent-control.md
index 93b58db8fc..68561a2022 100644
---
a/versioned_docs/version-3.0/data-operate/update/unique-update-transaction.md
+++ b/docs/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "Updating Transaction",
+ "title": "Concurrency Control for Updates in the Primary Key Model",
"language": "en"
}
---
@@ -24,16 +24,28 @@ specific language governing permissions and limitations
under the License.
-->
-## Update Concurrency Control
+## Overview
-By default, concurrent updates on the same table are not allowed in Doris.
+Doris adopts a Multi-Version Concurrency Control (MVCC) mechanism to manage
concurrent updates. Each data load operation is assigned a transaction, which
ensures atomicity (i.e., the operation either fully succeeds or completely
fails). Upon transaction commit, the system assigns a version number. When
using the Unique Key model and loading multiple batches of data with duplicate
primary keys, Doris determines the overwrite order based on the version number:
data with a higher version nu [...]
+
+In certain scenarios, users may need to specify a sequence column in the table
creation statement to customize the order in which data takes effect. For
example, when synchronizing data into Doris using multiple concurrent
processes, the data may arrive out of order. This could lead to older data
overwriting newer data due to its delayed arrival. To address this, users can
assign a lower sequence value to the older data and a higher sequence value to
the newer data, enabling Doris to det [...]
+
+Additionally, `UPDATE` statements differ significantly from updates performed
via data loads at the implementation level. An `UPDATE` operation involves two
steps: reading the data to be updated from the database and writing the updated
data back. By default, `UPDATE` statements use table-level locks to provide
transaction capabilities with Serializable isolation, meaning multiple `UPDATE`
statements must be executed serially. However, users can bypass this
restriction by modifying the c [...]
+
+## UPDATE Concurrency Control
+
+By default, concurrent `UPDATE`s on the same table are not allowed in Doris.
The main reason is that Doris currently supports row-level updates, which
means that even if the user specifies to update only a specific column (e.g.,
`SET v2 = 1`), all other value columns will be overwritten as well (even though
their values remain unchanged).
-This poses a problem when multiple update operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
+This poses a problem when multiple `UPDATE` operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
However, in practical applications, if the user can ensure that concurrent
updates will not affect the same row simultaneously, they can manually enable
the concurrent update restriction. This can be done by modifying the FE
(Frontend) configuration `enable_concurrent_update`. When this configuration is
set to `true`, the update command will not have transaction guarantees.
+:::caution Caution:
+Enabling the `enable_concurrent_update` configuration may introduce certain
performance risks.
+:::
+
## Sequence Column
The Unique model primarily caters to scenarios that require unique primary
keys, ensuring the uniqueness constraint. When loading data in the same batch
or different batches, the replacement order is not guaranteed. The uncertainty
in the replacement order results in ambiguity in the specific data loaded into
the table.
diff --git a/docs/data-operate/update/update-overview.md
b/docs/data-operate/update/update-overview.md
index 1515852091..1ae9103191 100644
--- a/docs/data-operate/update/update-overview.md
+++ b/docs/data-operate/update/update-overview.md
@@ -113,7 +113,7 @@ For concurrent load updates, Doris determines the order of
concurrent updates us
Since the commit order of multiple concurrent load updates may be
unpredictable, if these concurrent load jobs involve updates to the same
primary key, the order in which they take effect is also uncertain. As a
result, the final visible outcome may be indeterminate. To address this issue,
Doris provides a `sequence` column mechanism, allowing users to specify a
version for each row in concurrent load updates, thus ensuring determinism in
the outcome of concurrent updates.
-For more detailed information on transaction mechanisms, refer to the
documentation on [Transactional Updates in the Primary Key
Model](../update/unique-update-transaction.md).
+For more detailed information on concurrency control, refer to the
documentation on [Concurrency Control for Updates in the Primary Key
Model](../update/unique-update-concurrent-control.md).
## Update in Aggregate Model
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-transaction.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-transaction.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-concurrent-control.md
index 9280c1f338..dbd8545d29 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-transaction.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "主键模型的更新事务",
+ "title": "主键模型的更新并发控制",
"language": "zh-CN"
}
---
@@ -24,18 +24,26 @@ specific language governing permissions and limitations
under the License.
-->
-## Update 并发控制
+## 概览
-默认情况下，并不允许同一时间对同一张表并发进行多个 Update 操作。
+Doris 采用多版本并发控制机制（MVCC - Multi-Version Concurrency
Control）来管理并发更新。每次数据写入操作均会分配一个写入事务，该事务确保数据写入的原子性（即写入操作要么完全成功，要么完全失败）。在写入事务提交时，系统会为其分配一个版本号。当用户使用
Unique Key 模型并多次导入数据时，如果存在重复主键，Doris 会根据版本号确定覆盖顺序：版本号较高的数据会覆盖版本号较低的数据。
+
+在某些场景中，用户可能需要通过在建表语句中指定 sequence 列来灵活调整数据的生效顺序。例如，当通过多线程并发同步数据到 Doris
时，不同线程的数据可能会乱序到达。这种情况下，可能出现旧数据因较晚到达而错误覆盖新数据的情况。为解决这一问题，用户可以为旧数据指定较低的 sequence
值，为新数据指定较高的 sequence 值，从而让 Doris 根据用户提供的 sequence值来正确确定数据的更新顺序。
+
+此外，`UPDATE` 语句与通过导入实现更新在底层机制上存在较大差异。`UPDATE`
操作涉及两个步骤：从数据库中读取待更新的数据，以及写入更新后的数据。默认情况下，`UPDATE` 语句通过表级锁提供了 Serializable
隔离级别的事务能力，即多个 `UPDATE` 操作只能串行执行。用户也可以通过调整配置绕过这一限制，具体方法请参阅以下章节的详细说明。
+
+## UPDATE 并发控制
+
+默认情况下，并不允许同一时间对同一张表并发进行多个 `UPDATE` 操作。
主要原因是，Doris 目前支持的是行更新，这意味着，即使用户声明的是 `SET v2 = 1`，实际上，其他所有的 Value
列也会被覆盖一遍（尽管值没有变化）。
-这就会存在一个问题，如果同时有两个 Update 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
+这就会存在一个问题，如果同时有两个 `UPDATE` 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
但在实际应用中，如果用户自己可以保证即使并发更新，也不会同时对同一行进行操作的话，就可以手动打开并发限制。通过修改 FE 配置
`enable_concurrent_update`，当该配置值设置为 `true` 时，更新命令将不再提供事务保证。
-:::caution
-注意：开启 `enable_concurrent_update` 配置后，会有一定的性能风险
+:::caution 注意:
+开启 `enable_concurrent_update` 配置后，会有一定的性能风险
:::
## Sequence 列
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
index fb4adc265b..eec0acac95 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ Doris 对所有导入更新操作提供原子性保障，即每次导入数据
由于多个并发导入更新的提交顺序可能无法预期，若这些并发导入涉及相同主键的更新，则其生效顺序也无法预知，最终的可见结果会因此存在不确定性。为解决此问题，Doris
提供了 sequence 列机制，允许用户在并发导入更新时为每一行数据指定版本，以便明确控制并发更新的结果顺序，实现确定性。
-我们将在文档 [主键模型的更新事务](../update/unique-update-transaction.md) 中对事务机制进行详细介绍。
+我们将在文档 [主键模型的更新并发控制](../update/unique-update-concurrent-control.md)
中对更新的并发控制机制进行详细介绍。
## 聚合（Aggregate）模型的更新
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-transaction.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-transaction.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
index 00564a2694..7fb631fc89 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-transaction.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "主键模型的更新事务",
+ "title": "主键模型的更新并发控制",
"language": "zh-CN"
}
---
@@ -24,18 +24,26 @@ specific language governing permissions and limitations
under the License.
-->
-## Update 并发控制
+## 概览
-默认情况下，并不允许同一时间对同一张表并发进行多个 Update 操作。
+Doris 采用多版本并发控制机制（MVCC - Multi-Version Concurrency
Control）来管理并发更新。每次数据写入操作均会分配一个写入事务，该事务确保数据写入的原子性（即写入操作要么完全成功，要么完全失败）。在写入事务提交时，系统会为其分配一个版本号。当用户使用
Unique Key 模型并多次导入数据时，如果存在重复主键，Doris 会根据版本号确定覆盖顺序：版本号较高的数据会覆盖版本号较低的数据。
+
+在某些场景中，用户可能需要通过在建表语句中指定 sequence 列来灵活调整数据的生效顺序。例如，当通过多线程并发同步数据到 Doris
时，不同线程的数据可能会乱序到达。这种情况下，可能出现旧数据因较晚到达而错误覆盖新数据的情况。为解决这一问题，用户可以为旧数据指定较低的 sequence
值，为新数据指定较高的 sequence 值，从而让 Doris 根据用户提供的 sequence值来正确确定数据的更新顺序。
+
+此外，`UPDATE` 语句与通过导入实现更新在底层机制上存在较大差异。`UPDATE`
操作涉及两个步骤：从数据库中读取待更新的数据，以及写入更新后的数据。默认情况下，`UPDATE` 语句通过表级锁提供了 Serializable
隔离级别的事务能力，即多个 `UPDATE` 操作只能串行执行。用户也可以通过调整配置绕过这一限制，具体方法请参阅以下章节的详细说明。
+
+## UPDATE 并发控制
+
+默认情况下，并不允许同一时间对同一张表并发进行多个 `UPDATE` 操作。
主要原因是，Doris 目前支持的是行更新，这意味着，即使用户声明的是 `SET v2 = 1`，实际上，其他所有的 Value
列也会被覆盖一遍（尽管值没有变化）。
-这就会存在一个问题，如果同时有两个 Update 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
+这就会存在一个问题，如果同时有两个 `UPDATE` 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
但在实际应用中，如果用户自己可以保证即使并发更新，也不会同时对同一行进行操作的话，就可以手动打开并发限制。通过修改 FE 配置
`enable_concurrent_update`，当该配置值设置为 `true` 时，更新命令将不再提供事务保证。
-:::caution
-注意：开启 `enable_concurrent_update` 配置后，会有一定的性能风险
+:::caution 注意：
+开启 `enable_concurrent_update` 配置后，会有一定的性能风险
:::
## Sequence 列
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/update-overview.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/update-overview.md
index c097f4c34a..d1a7104978 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/update-overview.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ Doris 对所有导入更新操作提供原子性保障，即每次导入数据
由于多个并发导入更新的提交顺序可能无法预期，若这些并发导入涉及相同主键的更新，则其生效顺序也无法预知，最终的可见结果会因此存在不确定性。为解决此问题，Doris
提供了 sequence 列机制，允许用户在并发导入更新时为每一行数据指定版本，以便明确控制并发更新的结果顺序，实现确定性。
-我们将在文档 [主键模型的更新事务](../update/unique-update-transaction.md) 中对事务机制进行详细介绍。
+我们将在文档 [主键模型的更新并发控制](../update/unique-update-concurrent-control.md)
中对事务机制进行详细介绍。
## 聚合（Aggregate）模型的更新
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-transaction.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-transaction.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
index 00564a2694..7fb631fc89 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/data-operate/update/unique-update-transaction.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "主键模型的更新事务",
+ "title": "主键模型的更新并发控制",
"language": "zh-CN"
}
---
@@ -24,18 +24,26 @@ specific language governing permissions and limitations
under the License.
-->
-## Update 并发控制
+## 概览
-默认情况下，并不允许同一时间对同一张表并发进行多个 Update 操作。
+Doris 采用多版本并发控制机制（MVCC - Multi-Version Concurrency
Control）来管理并发更新。每次数据写入操作均会分配一个写入事务，该事务确保数据写入的原子性（即写入操作要么完全成功，要么完全失败）。在写入事务提交时，系统会为其分配一个版本号。当用户使用
Unique Key 模型并多次导入数据时，如果存在重复主键，Doris 会根据版本号确定覆盖顺序：版本号较高的数据会覆盖版本号较低的数据。
+
+在某些场景中，用户可能需要通过在建表语句中指定 sequence 列来灵活调整数据的生效顺序。例如，当通过多线程并发同步数据到 Doris
时，不同线程的数据可能会乱序到达。这种情况下，可能出现旧数据因较晚到达而错误覆盖新数据的情况。为解决这一问题，用户可以为旧数据指定较低的 sequence
值，为新数据指定较高的 sequence 值，从而让 Doris 根据用户提供的 sequence值来正确确定数据的更新顺序。
+
+此外，`UPDATE` 语句与通过导入实现更新在底层机制上存在较大差异。`UPDATE`
操作涉及两个步骤：从数据库中读取待更新的数据，以及写入更新后的数据。默认情况下，`UPDATE` 语句通过表级锁提供了 Serializable
隔离级别的事务能力，即多个 `UPDATE` 操作只能串行执行。用户也可以通过调整配置绕过这一限制，具体方法请参阅以下章节的详细说明。
+
+## UPDATE 并发控制
+
+默认情况下，并不允许同一时间对同一张表并发进行多个 `UPDATE` 操作。
主要原因是，Doris 目前支持的是行更新，这意味着，即使用户声明的是 `SET v2 = 1`，实际上，其他所有的 Value
列也会被覆盖一遍（尽管值没有变化）。
-这就会存在一个问题，如果同时有两个 Update 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
+这就会存在一个问题，如果同时有两个 `UPDATE` 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
但在实际应用中，如果用户自己可以保证即使并发更新，也不会同时对同一行进行操作的话，就可以手动打开并发限制。通过修改 FE 配置
`enable_concurrent_update`，当该配置值设置为 `true` 时，更新命令将不再提供事务保证。
-:::caution
-注意：开启 `enable_concurrent_update` 配置后，会有一定的性能风险
+:::caution 注意：
+开启 `enable_concurrent_update` 配置后，会有一定的性能风险
:::
## Sequence 列
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/update-overview.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/update-overview.md
index a57ec68fb7..768a6a7847 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/update-overview.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ Doris 对所有导入更新操作提供原子性保障，即每次导入数据
由于多个并发导入更新的提交顺序可能无法预期，若这些并发导入涉及相同主键的更新，则其生效顺序也无法预知，最终的可见结果会因此存在不确定性。为解决此问题，Doris
提供了 sequence 列机制，允许用户在并发导入更新时为每一行数据指定版本，以便明确控制并发更新的结果顺序，实现确定性。
-我们将在文档 [主键模型的更新事务](../update/unique-update-transaction.md) 中对事务机制进行详细介绍。
+我们将在文档 [主键模型的更新并发控制](../update/unique-update-concurrent-control.md)
中对事务机制进行详细介绍。
## 聚合（Aggregate）模型的更新
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-transaction.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-transaction.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
index 00564a2694..7fb631fc89 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/data-operate/update/unique-update-transaction.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "主键模型的更新事务",
+ "title": "主键模型的更新并发控制",
"language": "zh-CN"
}
---
@@ -24,18 +24,26 @@ specific language governing permissions and limitations
under the License.
-->
-## Update 并发控制
+## 概览
-默认情况下，并不允许同一时间对同一张表并发进行多个 Update 操作。
+Doris 采用多版本并发控制机制（MVCC - Multi-Version Concurrency
Control）来管理并发更新。每次数据写入操作均会分配一个写入事务，该事务确保数据写入的原子性（即写入操作要么完全成功，要么完全失败）。在写入事务提交时，系统会为其分配一个版本号。当用户使用
Unique Key 模型并多次导入数据时，如果存在重复主键，Doris 会根据版本号确定覆盖顺序：版本号较高的数据会覆盖版本号较低的数据。
+
+在某些场景中，用户可能需要通过在建表语句中指定 sequence 列来灵活调整数据的生效顺序。例如，当通过多线程并发同步数据到 Doris
时，不同线程的数据可能会乱序到达。这种情况下，可能出现旧数据因较晚到达而错误覆盖新数据的情况。为解决这一问题，用户可以为旧数据指定较低的 sequence
值，为新数据指定较高的 sequence 值，从而让 Doris 根据用户提供的 sequence值来正确确定数据的更新顺序。
+
+此外，`UPDATE` 语句与通过导入实现更新在底层机制上存在较大差异。`UPDATE`
操作涉及两个步骤：从数据库中读取待更新的数据，以及写入更新后的数据。默认情况下，`UPDATE` 语句通过表级锁提供了 Serializable
隔离级别的事务能力，即多个 `UPDATE` 操作只能串行执行。用户也可以通过调整配置绕过这一限制，具体方法请参阅以下章节的详细说明。
+
+## UPDATE 并发控制
+
+默认情况下，并不允许同一时间对同一张表并发进行多个 `UPDATE` 操作。
主要原因是，Doris 目前支持的是行更新，这意味着，即使用户声明的是 `SET v2 = 1`，实际上，其他所有的 Value
列也会被覆盖一遍（尽管值没有变化）。
-这就会存在一个问题，如果同时有两个 Update 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
+这就会存在一个问题，如果同时有两个 `UPDATE` 操作对同一行进行更新，那么其行为可能是不确定的，也就是可能存在脏数据。
但在实际应用中，如果用户自己可以保证即使并发更新，也不会同时对同一行进行操作的话，就可以手动打开并发限制。通过修改 FE 配置
`enable_concurrent_update`，当该配置值设置为 `true` 时，更新命令将不再提供事务保证。
-:::caution
-注意：开启 `enable_concurrent_update` 配置后，会有一定的性能风险
+:::caution 注意：
+开启 `enable_concurrent_update` 配置后，会有一定的性能风险
:::
## Sequence 列
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/update-overview.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/update-overview.md
index e802020216..0f01e1771d 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/update-overview.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ Doris 对所有导入更新操作提供原子性保障，即每次导入数据
由于多个并发导入更新的提交顺序可能无法预期，若这些并发导入涉及相同主键的更新，则其生效顺序也无法预知，最终的可见结果会因此存在不确定性。为解决此问题，Doris
提供了 sequence 列机制，允许用户在并发导入更新时为每一行数据指定版本，以便明确控制并发更新的结果顺序，实现确定性。
-我们将在文档[主键模型的更新事务](../update/unique-update-transaction.md) 中对事务机制进行详细介绍。
+我们将在文档[主键模型的更新并发控制](../update/unique-update-concurrent-control.md)
中对更新的并发控制机制进行详细介绍。
## 聚合（Aggregate）模型的更新
diff --git a/sidebars.json b/sidebars.json
index 9b9e44a4fc..ac7567e0e3 100644
--- a/sidebars.json
+++ b/sidebars.json
@@ -184,7 +184,7 @@
"data-operate/update/unique-update",
"data-operate/update/update-of-unique-model",
"data-operate/update/update-of-aggregate-model",
- "data-operate/update/unique-update-transaction"
+
"data-operate/update/unique-update-concurrent-control"
]
},
{
diff --git a/docs/data-operate/update/unique-update-transaction.md
b/versioned_docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from docs/data-operate/update/unique-update-transaction.md
rename to
versioned_docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
index 93b58db8fc..943d7e08bd 100644
--- a/docs/data-operate/update/unique-update-transaction.md
+++
b/versioned_docs/version-2.0/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "Updating Transaction",
+ "title": "Concurrency Control for Updates in the Primary Key Model",
"language": "en"
}
---
@@ -24,16 +24,28 @@ specific language governing permissions and limitations
under the License.
-->
+## Overview
+
+Doris adopts a Multi-Version Concurrency Control (MVCC) mechanism to manage
concurrent updates. Each data load operation is assigned a transaction, which
ensures atomicity (i.e., the operation either fully succeeds or completely
fails). Upon transaction commit, the system assigns a version number. When
using the Unique Key model and loading multiple batches of data with duplicate
primary keys, Doris determines the overwrite order based on the version number:
data with a higher version nu [...]
+
+In certain scenarios, users may need to specify a sequence column in the table
creation statement to customize the order in which data takes effect. For
example, when synchronizing data into Doris using multiple concurrent
processes, the data may arrive out of order. This could lead to older data
overwriting newer data due to its delayed arrival. To address this, users can
assign a lower sequence value to the older data and a higher sequence value to
the newer data, enabling Doris to det [...]
+
+Additionally, `UPDATE` statements differ significantly from updates performed
via data loads at the implementation level. An `UPDATE` operation involves two
steps: reading the data to be updated from the database and writing the updated
data back. By default, `UPDATE` statements use table-level locks to provide
transaction capabilities with Serializable isolation, meaning multiple `UPDATE`
statements must be executed serially. However, users can bypass this
restriction by modifying the c [...]
+
## Update Concurrency Control
-By default, concurrent updates on the same table are not allowed in Doris.
+By default, concurrent `UPDATE`s on the same table are not allowed in Doris.
The main reason is that Doris currently supports row-level updates, which
means that even if the user specifies to update only a specific column (e.g.,
`SET v2 = 1`), all other value columns will be overwritten as well (even though
their values remain unchanged).
-This poses a problem when multiple update operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
+This poses a problem when multiple `UPDATE` operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
However, in practical applications, if the user can ensure that concurrent
updates will not affect the same row simultaneously, they can manually enable
the concurrent update restriction. This can be done by modifying the FE
(Frontend) configuration `enable_concurrent_update`. When this configuration is
set to `true`, the update command will not have transaction guarantees.
+:::caution Caution:
+Enabling the `enable_concurrent_update` configuration may introduce certain
performance risks.
+:::
+
## Sequence Column
The Unique model primarily caters to scenarios that require unique primary
keys, ensuring the uniqueness constraint. When loading data in the same batch
or different batches, the replacement order is not guaranteed. The uncertainty
in the replacement order results in ambiguity in the specific data loaded into
the table.
diff --git a/versioned_docs/version-2.0/data-operate/update/update-overview.md
b/versioned_docs/version-2.0/data-operate/update/update-overview.md
index 9c82424d66..7d9e98b3e3 100644
--- a/versioned_docs/version-2.0/data-operate/update/update-overview.md
+++ b/versioned_docs/version-2.0/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ For concurrent load updates, Doris determines the order of
concurrent updates us
Since the commit order of multiple concurrent load updates may be
unpredictable, if these concurrent load jobs involve updates to the same
primary key, the order in which they take effect is also uncertain. As a
result, the final visible outcome may be indeterminate. To address this issue,
Doris provides a `sequence` column mechanism, allowing users to specify a
version for each row in concurrent load updates, thus ensuring determinism in
the outcome of concurrent updates.
-For more detailed information on transaction mechanisms, refer to the
documentation on [Transactional Updates in the Primary Key
Model](../update/unique-update-transaction.md).
+For more detailed information on concurrency control, refer to the
documentation on [Concurrency Control for Updates in the Primary Key
Model](../update/unique-update-concurrent-control.md).
## Update in Aggregate Model
diff --git
a/versioned_docs/version-2.0/data-operate/update/unique-update-transaction.md
b/versioned_docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
versioned_docs/version-2.0/data-operate/update/unique-update-transaction.md
rename to
versioned_docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
index 93b58db8fc..943d7e08bd 100644
---
a/versioned_docs/version-2.0/data-operate/update/unique-update-transaction.md
+++
b/versioned_docs/version-2.1/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "Updating Transaction",
+ "title": "Concurrency Control for Updates in the Primary Key Model",
"language": "en"
}
---
@@ -24,16 +24,28 @@ specific language governing permissions and limitations
under the License.
-->
+## Overview
+
+Doris adopts a Multi-Version Concurrency Control (MVCC) mechanism to manage
concurrent updates. Each data load operation is assigned a transaction, which
ensures atomicity (i.e., the operation either fully succeeds or completely
fails). Upon transaction commit, the system assigns a version number. When
using the Unique Key model and loading multiple batches of data with duplicate
primary keys, Doris determines the overwrite order based on the version number:
data with a higher version nu [...]
+
+In certain scenarios, users may need to specify a sequence column in the table
creation statement to customize the order in which data takes effect. For
example, when synchronizing data into Doris using multiple concurrent
processes, the data may arrive out of order. This could lead to older data
overwriting newer data due to its delayed arrival. To address this, users can
assign a lower sequence value to the older data and a higher sequence value to
the newer data, enabling Doris to det [...]
+
+Additionally, `UPDATE` statements differ significantly from updates performed
via data loads at the implementation level. An `UPDATE` operation involves two
steps: reading the data to be updated from the database and writing the updated
data back. By default, `UPDATE` statements use table-level locks to provide
transaction capabilities with Serializable isolation, meaning multiple `UPDATE`
statements must be executed serially. However, users can bypass this
restriction by modifying the c [...]
+
## Update Concurrency Control
-By default, concurrent updates on the same table are not allowed in Doris.
+By default, concurrent `UPDATE`s on the same table are not allowed in Doris.
The main reason is that Doris currently supports row-level updates, which
means that even if the user specifies to update only a specific column (e.g.,
`SET v2 = 1`), all other value columns will be overwritten as well (even though
their values remain unchanged).
-This poses a problem when multiple update operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
+This poses a problem when multiple `UPDATE` operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
However, in practical applications, if the user can ensure that concurrent
updates will not affect the same row simultaneously, they can manually enable
the concurrent update restriction. This can be done by modifying the FE
(Frontend) configuration `enable_concurrent_update`. When this configuration is
set to `true`, the update command will not have transaction guarantees.
+:::caution Caution:
+Enabling the `enable_concurrent_update` configuration may introduce certain
performance risks.
+:::
+
## Sequence Column
The Unique model primarily caters to scenarios that require unique primary
keys, ensuring the uniqueness constraint. When loading data in the same batch
or different batches, the replacement order is not guaranteed. The uncertainty
in the replacement order results in ambiguity in the specific data loaded into
the table.
diff --git a/versioned_docs/version-2.1/data-operate/update/update-overview.md
b/versioned_docs/version-2.1/data-operate/update/update-overview.md
index f2a861bed5..0d6579c83e 100644
--- a/versioned_docs/version-2.1/data-operate/update/update-overview.md
+++ b/versioned_docs/version-2.1/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ For concurrent load updates, Doris determines the order of
concurrent updates us
Since the commit order of multiple concurrent load updates may be
unpredictable, if these concurrent load jobs involve updates to the same
primary key, the order in which they take effect is also uncertain. As a
result, the final visible outcome may be indeterminate. To address this issue,
Doris provides a `sequence` column mechanism, allowing users to specify a
version for each row in concurrent load updates, thus ensuring determinism in
the outcome of concurrent updates.
-For more detailed information on transaction mechanisms, refer to the
documentation on [Transactional Updates in the Primary Key
Model](../update/unique-update-transaction.md).
+For more detailed information on concurrency control, refer to the
documentation on [Concurrency Control for Updates in the Primary Key
Model](../update/unique-update-concurrent-control.md).
## Update in Aggregate Model
diff --git
a/versioned_docs/version-2.1/data-operate/update/unique-update-transaction.md
b/versioned_docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
similarity index 84%
rename from
versioned_docs/version-2.1/data-operate/update/unique-update-transaction.md
rename to
versioned_docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
index 93b58db8fc..943d7e08bd 100644
---
a/versioned_docs/version-2.1/data-operate/update/unique-update-transaction.md
+++
b/versioned_docs/version-3.0/data-operate/update/unique-update-concurrent-control.md
@@ -1,6 +1,6 @@
---
{
- "title": "Updating Transaction",
+ "title": "Concurrency Control for Updates in the Primary Key Model",
"language": "en"
}
---
@@ -24,16 +24,28 @@ specific language governing permissions and limitations
under the License.
-->
+## Overview
+
+Doris adopts a Multi-Version Concurrency Control (MVCC) mechanism to manage
concurrent updates. Each data load operation is assigned a transaction, which
ensures atomicity (i.e., the operation either fully succeeds or completely
fails). Upon transaction commit, the system assigns a version number. When
using the Unique Key model and loading multiple batches of data with duplicate
primary keys, Doris determines the overwrite order based on the version number:
data with a higher version nu [...]
+
+In certain scenarios, users may need to specify a sequence column in the table
creation statement to customize the order in which data takes effect. For
example, when synchronizing data into Doris using multiple concurrent
processes, the data may arrive out of order. This could lead to older data
overwriting newer data due to its delayed arrival. To address this, users can
assign a lower sequence value to the older data and a higher sequence value to
the newer data, enabling Doris to det [...]
+
+Additionally, `UPDATE` statements differ significantly from updates performed
via data loads at the implementation level. An `UPDATE` operation involves two
steps: reading the data to be updated from the database and writing the updated
data back. By default, `UPDATE` statements use table-level locks to provide
transaction capabilities with Serializable isolation, meaning multiple `UPDATE`
statements must be executed serially. However, users can bypass this
restriction by modifying the c [...]
+
## Update Concurrency Control
-By default, concurrent updates on the same table are not allowed in Doris.
+By default, concurrent `UPDATE`s on the same table are not allowed in Doris.
The main reason is that Doris currently supports row-level updates, which
means that even if the user specifies to update only a specific column (e.g.,
`SET v2 = 1`), all other value columns will be overwritten as well (even though
their values remain unchanged).
-This poses a problem when multiple update operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
+This poses a problem when multiple `UPDATE` operations are performed
concurrently on the same row. The behavior becomes unpredictable, and it may
lead to inconsistent or "dirty" data.
However, in practical applications, if the user can ensure that concurrent
updates will not affect the same row simultaneously, they can manually enable
the concurrent update restriction. This can be done by modifying the FE
(Frontend) configuration `enable_concurrent_update`. When this configuration is
set to `true`, the update command will not have transaction guarantees.
+:::caution Caution:
+Enabling the `enable_concurrent_update` configuration may introduce certain
performance risks.
+:::
+
## Sequence Column
The Unique model primarily caters to scenarios that require unique primary
keys, ensuring the uniqueness constraint. When loading data in the same batch
or different batches, the replacement order is not guaranteed. The uncertainty
in the replacement order results in ambiguity in the specific data loaded into
the table.
diff --git a/versioned_docs/version-3.0/data-operate/update/update-overview.md
b/versioned_docs/version-3.0/data-operate/update/update-overview.md
index 77a2d7f738..2096efcedb 100644
--- a/versioned_docs/version-3.0/data-operate/update/update-overview.md
+++ b/versioned_docs/version-3.0/data-operate/update/update-overview.md
@@ -114,7 +114,7 @@ For concurrent load updates, Doris determines the order of
concurrent updates us
Since the commit order of multiple concurrent load updates may be
unpredictable, if these concurrent load jobs involve updates to the same
primary key, the order in which they take effect is also uncertain. As a
result, the final visible outcome may be indeterminate. To address this issue,
Doris provides a `sequence` column mechanism, allowing users to specify a
version for each row in concurrent load updates, thus ensuring determinism in
the outcome of concurrent updates.
-For more detailed information on transaction mechanisms, refer to the
documentation on [Transactional Updates in the Primary Key
Model](../update/unique-update-transaction.md).
+For more detailed information on concurrency control, refer to the
documentation on [Concurrency Control for Updates in the Primary Key
Model](../update/unique-update-concurrent-control.md).
## Update in Aggregate Model
diff --git a/versioned_sidebars/version-2.0-sidebars.json
b/versioned_sidebars/version-2.0-sidebars.json
index b3a0955581..5cbb64379b 100644
--- a/versioned_sidebars/version-2.0-sidebars.json
+++ b/versioned_sidebars/version-2.0-sidebars.json
@@ -154,7 +154,7 @@
"data-operate/update/unique-update",
"data-operate/update/update-of-unique-model",
"data-operate/update/update-of-aggregate-model",
- "data-operate/update/unique-update-transaction"
+
"data-operate/update/unique-update-concurrent-control"
]
},
{
diff --git a/versioned_sidebars/version-2.1-sidebars.json
b/versioned_sidebars/version-2.1-sidebars.json
index 677e34aec2..dcfaf18d84 100644
--- a/versioned_sidebars/version-2.1-sidebars.json
+++ b/versioned_sidebars/version-2.1-sidebars.json
@@ -168,7 +168,7 @@
"data-operate/update/unique-update",
"data-operate/update/update-of-unique-model",
"data-operate/update/update-of-aggregate-model",
- "data-operate/update/unique-update-transaction"
+
"data-operate/update/unique-update-concurrent-control"
]
},
{
diff --git a/versioned_sidebars/version-3.0-sidebars.json
b/versioned_sidebars/version-3.0-sidebars.json
index 7e306b47be..ee130607f5 100644
--- a/versioned_sidebars/version-3.0-sidebars.json
+++ b/versioned_sidebars/version-3.0-sidebars.json
@@ -185,7 +185,7 @@
"data-operate/update/unique-update",
"data-operate/update/update-of-unique-model",
"data-operate/update/update-of-aggregate-model",
- "data-operate/update/unique-update-transaction"
+
"data-operate/update/unique-update-concurrent-control"
]
},
{
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
