apache · dataroaring · Nov 5, 2024 · Nov 5, 2024 · Nov 5, 2024 · Nov 5, 2024
diff --git a/docs/table-design/data-model/unique.md b/docs/table-design/data-model/unique.md
@@ -30,8 +30,9 @@ When users have data update requirements, they can choose to use the Unique data
 
 The Unique data model provides two implementation methods:
 
+- Merge-on-write. In version 1.2, we introduced the merge-on-write implementation, which completes all data deduplication tasks during the data writing phase, thus providing excellent query performance. Since version 2.1, merge-on-write has become very mature and stable. Due to its excellent query performance, it has become the default implementation for the Unique model.
+
 - Merge-on-read. In the merge-on-read implementation, users will not trigger any data deduplication-related operations when writing data. All data deduplication operations are performed during queries or compaction. Therefore, the write performance of merge-on-read is better, the query performance is poor, and the memory consumption is also higher.
-- Merge-on-write. In version 1.2, we introduced the merge-on-write implementation, which completes all data deduplication tasks during the data writing phase, thus providing excellent query performance. Since version 2.0, merge-on-write has become very mature and stable. Due to its excellent query performance, we recommend most users to choose this implementation. Since version 2.1, merge-on-write has become the default implementation for the Unique model.
 
 The default update semantics of the Unique model is a **full-row UPSERT**, which stands for UPDATE OR INSERT. If the key of the row data exists, an update will be performed; if it does not exist, new data will be inserted. Under the full-row UPSERT semantics, even if the user uses INSERT INTO to specify partial columns for writing, Doris will fill the unprovided columns with NULL values or default values in the Planner.
 
@@ -50,9 +51,9 @@ Let's look at how to create a Unique model table with merge-on-read and merge-on
 | address       | VARCHAR (500) | No    | User address           |
 | register_time | DATETIME      | No    | User registration time |
 
-## Merge-on-Read
+## Merge-on-Write
 
-The table creation statement for Merge-on-read is as follows:
+The table creation statement for Merge-on-Write is as follows:
 
 ```
 CREATE TABLE IF NOT EXISTS example_tbl_unique
@@ -67,18 +68,18 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique
     `register_time` DATETIME COMMENT "User registration time"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1"
+"replication_allocation" = "tag.location.default: 3"
 );
 ```
 
-## Merge-on-Write
+## Merge-on-Read
 
-The table creation statement for Merge-on-write is as follows:
+The table creation statement for Merge-on-Read is as follows:
 
 ```
-CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
+CREATE TABLE IF NOT EXISTS example_tbl_unique
 (
     `user_id` LARGEINT NOT NULL COMMENT "User ID",
     `username` VARCHAR(50) NOT NULL COMMENT "Username",
@@ -90,17 +91,17 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
     `register_time` DATETIME COMMENT "User registration time"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1",
-"enable_unique_key_merge_on_write" = "true"
+"replication_allocation" = "tag.location.default: 3",
+"enable_unique_key_merge_on_write" = "false"
 );
 ```
 
-Users need to add the property with **enable_unique_key_merge_on_write" = "true"** when creating the table to enable Merge-on-write.
+Users need to add the property with **enable_unique_key_merge_on_write" = "false"** when creating the table to enable Merge-on-read.
 
 ```
-"enable_unique_key_merge_on_write" = "true"
+"enable_unique_key_merge_on_write" = "false"
 ```
 
 :::caution
@@ -119,6 +120,9 @@ For users of version 1.2:
 ## Use attention
 
 - The implementation of the Unique model can only be determined during table creation and cannot be modified through schema changes.
+
 - The Merge-on-read table cannot be seamlessly upgraded to the Merge-on-write table (due to completely different data organization methods). If you need to switch to Merge-on-write, you must manually perform an `INSERT INTO unique-mow-table SELECT * FROM source_table` to re-import the data.
+
 - **Whole-row Updates**: The default update semantics for the Unique model is a whole-row UPSERT, which stands for UPDATE OR INSERT. If the key for a row of data exists, it will be updated; if it does not exist, new data will be inserted. Under the whole-row UPSERT semantics, even if the user specifies only certain columns for insertion using `INSERT INTO`, Doris will fill in the unprovided columns with NULL values or default values during the planning phase.
+
 - **Partial Column Updates**: If the user wishes to update only certain fields, they must use Merge-on-write and enable support for partial column updates through specific parameters. Please refer to the documentation on [partial column updates](../../data-operate/update/update-of-unique-model) for relevant usage recommendations.
diff --git a/.../zh-CN/docusaurus-plugin-content-docs/current/table-design/data-model/unique.md b/.../zh-CN/docusaurus-plugin-content-docs/current/table-design/data-model/unique.md
@@ -29,12 +29,14 @@ under the License.
 
 **主键模型提供了两种实现方式：**
 
+- 写时合并 (merge-on-write)。在 1.2 版本中，我们引入了写时合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。自 2.1 版本起，写时合并经过两个大版本的打磨，已经非常成熟稳定，由于其优秀的查询性能，写时合并成为 Unique 模型的默认实现。
+
 - 读时合并 (merge-on-read)。在读时合并实现中，用户在进行数据写入时不会触发任何数据去重相关的操作，所有数据去重的操作都在查询或者 compaction 时进行。因此，读时合并的写入性能较好，查询性能较差，同时内存消耗也较高。
-- 写时合并 (merge-on-write)。在 1.2 版本中，我们引入了写时合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。自 2.0 版本起，写时合并已经非常成熟稳定，由于其优秀的查询性能，我们推荐大部分用户选择该实现。自 2.1 版本，写时合并成为 Unique 模型的默认实现。
 
-**数据更新的语意**
+**数据更新的语义**
+
+- Unique 模型默认的更新语义为**整行`UPSERT`**，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行`UPSERT`语义下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充。
 
-- Unique 模型默认的更新语意为**整行`UPSERT`**，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行`UPSERT`语意下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充。
 - 部分列更新。如果用户希望更新部分字段，需要使用写时合并实现，并通过特定的参数来开启部分列更新的支持。请查阅数据操作/数据更新部分。
 
 下面以一个典型的用户基础信息表，来看看如何建立读时合并和写时合并的主键模型表。这个表数据没有聚合需求，只需保证主键唯一性。（这里的主键为 user_id + username）。
@@ -50,9 +52,10 @@ under the License.
 | address       | VARCHAR(500) | No    | 用户住址     |
 | register_time | DATETIME     | No    | 用户注册时间 |
 
-## 读时合并
 
-读时合并的建表语句如下：
+## 写时合并
+
+写时合并建表语句为：
 
 ```sql
 CREATE TABLE IF NOT EXISTS example_tbl_unique
@@ -67,18 +70,17 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique
     `register_time` DATETIME COMMENT "用户注册时间"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1"
+"replication_allocation" = "tag.location.default: 3"
 );
 ```
+## 读时合并
 
-## 写时合并
-
-写时合并建表语句为：
+读时合并的建表语句如下：
 
 ```sql
-CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
+CREATE TABLE IF NOT EXISTS example_tbl_unique
 (
     `user_id` LARGEINT NOT NULL COMMENT "用户id",
     `username` VARCHAR(50) NOT NULL COMMENT "用户昵称",
@@ -90,17 +92,17 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
     `register_time` DATETIME COMMENT "用户注册时间"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1",
-"enable_unique_key_merge_on_write" = "true"
+"replication_allocation" = "tag.location.default: 3",
+"enable_unique_key_merge_on_write" = "false"
 );
 ```
 
-用户需要在建表时添加下面的 property 来开启写时合并。
+用户需要在建表时添加下面的 property 来开启读时合并。
 
 ```Plain
-"enable_unique_key_merge_on_write" = "true"
+"enable_unique_key_merge_on_write" = "false"
 ```
 :::caution
 在 2.1 版本中，写时合并将会是主键模型的默认方式。
@@ -120,6 +122,6 @@ PROPERTIES (
 
 -   旧的 Merge-on-Read 的实现无法无缝升级到 Merge-on-Write 的实现（数据组织方式完全不同），如果需要改为使用写时合并的实现版本，需要手动执行 `insert into unique-mow-table select * from source table` 来重新导入。
 
--   整行更新：Unique 模型默认的更新语意为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语意下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
+-   整行更新：Unique 模型默认的更新语义为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语义下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
 
 -   部分列更新。如果用户希望更新部分字段，需要使用写时合并实现，并通过特定的参数来开启部分列更新的支持。请查阅文档[部分列更新](../../data-operate/update/update-of-unique-model)获取相关使用建议。
diff --git a/...CN/docusaurus-plugin-content-docs/version-2.0/table-design/data-model/unique.md b/...CN/docusaurus-plugin-content-docs/version-2.0/table-design/data-model/unique.md
@@ -108,6 +108,6 @@ PROPERTIES (
 
 -   旧的 Merge-on-Read 的实现无法无缝升级到 Merge-on-Write 的实现（数据组织方式完全不同），如果需要改为使用写时合并的实现版本，需要手动执行 `insert into unique-mow-table select * from source table` 来重新导入。
 
--   整行更新：Unique 模型默认的更新语意为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语意下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
+-   整行更新：Unique 模型默认的更新语义为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语义下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
 
 -   部分列更新。如果用户希望更新部分字段，需要使用写时合并实现，并通过特定的参数来开启部分列更新的支持。请查阅文档[部分列更新](../../data-operate/update/update-of-unique-model)获取相关使用建议。
diff --git a/...CN/docusaurus-plugin-content-docs/version-2.1/table-design/data-model/unique.md b/...CN/docusaurus-plugin-content-docs/version-2.1/table-design/data-model/unique.md
@@ -29,12 +29,14 @@ under the License.
 
 **主键模型提供了两种实现方式：**
 
+- 写时合并 (merge-on-write)。在 1.2 版本中，我们引入了写时合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。自 2.1 版本起，写时合并经过两个大版本的打磨，已经非常成熟稳定，由于其优秀的查询性能，写时合并成为 Unique 模型的默认实现。
+
 - 读时合并 (merge-on-read)。在读时合并实现中，用户在进行数据写入时不会触发任何数据去重相关的操作，所有数据去重的操作都在查询或者 compaction 时进行。因此，读时合并的写入性能较好，查询性能较差，同时内存消耗也较高。
-- 写时合并 (merge-on-write)。在 1.2 版本中，我们引入了写时合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。自 2.0 版本起，写时合并已经非常成熟稳定，由于其优秀的查询性能，我们推荐大部分用户选择该实现。自 2.1 版本，写时合并成为 Unique 模型的默认实现。
 
-**数据更新的语意**
+**数据更新的语义**
+
+- Unique 模型默认的更新语义为**整行`UPSERT`**，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行`UPSERT`语义下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充。
 
-- Unique 模型默认的更新语意为**整行`UPSERT`**，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行`UPSERT`语意下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充。
 - 部分列更新。如果用户希望更新部分字段，需要使用写时合并实现，并通过特定的参数来开启部分列更新的支持。请查阅数据操作/数据更新部分。
 
 下面以一个典型的用户基础信息表，来看看如何建立读时合并和写时合并的主键模型表。这个表数据没有聚合需求，只需保证主键唯一性。（这里的主键为 user_id + username）。
@@ -50,9 +52,9 @@ under the License.
 | address       | VARCHAR(500) | No    | 用户住址     |
 | register_time | DATETIME     | No    | 用户注册时间 |
 
-## 读时合并
+## 写时合并
 
-读时合并的建表语句如下：
+写时合并建表语句为：
 
 ```sql
 CREATE TABLE IF NOT EXISTS example_tbl_unique
@@ -67,18 +69,18 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique
     `register_time` DATETIME COMMENT "用户注册时间"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1"
+"replication_allocation" = "tag.location.default: 3"
 );
 ```
 
-## 写时合并
+## 读时合并
 
-写时合并建表语句为：
+读时合并的建表语句如下：
 
 ```sql
-CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
+CREATE TABLE IF NOT EXISTS example_tbl_unique
 (
     `user_id` LARGEINT NOT NULL COMMENT "用户id",
     `username` VARCHAR(50) NOT NULL COMMENT "用户昵称",
@@ -90,17 +92,17 @@ CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
     `register_time` DATETIME COMMENT "用户注册时间"
 )
 UNIQUE KEY(`user_id`, `username`)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
+DISTRIBUTED BY HASH(`user_id`) BUCKETS 10
 PROPERTIES (
-"replication_allocation" = "tag.location.default: 1",
-"enable_unique_key_merge_on_write" = "true"
+"replication_allocation" = "tag.location.default: 3",
+"enable_unique_key_merge_on_write" = "false"
 );
 ```
 
-用户需要在建表时添加下面的 property 来开启写时合并。
+用户需要在建表时添加下面的 property 来开启读时合并。
 
 ```Plain
-"enable_unique_key_merge_on_write" = "true"
+"enable_unique_key_merge_on_write" = "false"
 ```
 :::caution
 在 2.1 版本中，写时合并将会是主键模型的默认方式。
@@ -120,6 +122,6 @@ PROPERTIES (
 
 -   旧的 Merge-on-Read 的实现无法无缝升级到 Merge-on-Write 的实现（数据组织方式完全不同），如果需要改为使用写时合并的实现版本，需要手动执行 `insert into unique-mow-table select * from source table` 来重新导入。
 
--   整行更新：Unique 模型默认的更新语意为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语意下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
+-   整行更新：Unique 模型默认的更新语义为整行 `UPSERT`，即 UPDATE OR INSERT，该行数据的 key 如果存在，则进行更新，如果不存在，则进行新数据插入。在整行 `UPSERT` 语义下，即使用户使用 insert into 指定部分列进行写入，Doris 也会在 Planner 中将未提供的列使用 NULL 值或者默认值进行填充
 
 -   部分列更新。如果用户希望更新部分字段，需要使用写时合并实现，并通过特定的参数来开启部分列更新的支持。请查阅文档[部分列更新](../../data-operate/update/update-of-unique-model)获取相关使用建议。