This is an automated email from the ASF dual-hosted git repository.
dataroaring 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 72862c747a7 [doc](unique key) fix the description of default settings
of MoW (#1288)
72862c747a7 is described below
commit 72862c747a7435e4b7b509fa0e68b85e51bee1ac
Author: zhannngchen <48427519+zhannngc...@users.noreply.github.com>
AuthorDate: Tue Nov 5 22:33:27 2024 +0800
[doc](unique key) fix the description of default settings of MoW (#1288)
# Versions
- [x] dev
- [x] 3.0
- [x] 2.1
- [x] 2.0
# Languages
- [x] Chinese
- [x] English
https://github.com/apache/doris/pull/43290
---
docs/table-design/data-model/unique.md | 30 ++++++++++--------
.../current/table-design/data-model/unique.md | 36 ++++++++++++----------
.../version-2.0/table-design/data-model/unique.md | 2 +-
.../version-2.1/table-design/data-model/unique.md | 34 ++++++++++----------
.../version-3.0/table-design/data-model/unique.md | 34 ++++++++++----------
.../version-2.0/table-design/data-model/unique.md | 4 +++
.../version-2.1/table-design/data-model/unique.md | 30 ++++++++++--------
.../version-3.0/table-design/data-model/unique.md | 30 ++++++++++--------
8 files changed, 111 insertions(+), 89 deletions(-)
diff --git a/docs/table-design/data-model/unique.md
b/docs/table-design/data-model/unique.md
index 6839922f5c3..1ee9737e01f 100644
--- 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.
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/table-design/data-model/unique.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/table-design/data-model/unique.md
index 233b45c0aa6..045a89fa25c 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/table-design/data-model/unique.md
+++
b/i18n/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)获取相关使用建议。
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/table-design/data-model/unique.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/table-design/data-model/unique.md
index bf4f50d8f96..549a9dab639 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/table-design/data-model/unique.md
+++
b/i18n/zh-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)获取相关使用建议。
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/table-design/data-model/unique.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/table-design/data-model/unique.md
index 233b45c0aa6..a15d4c7463b 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/table-design/data-model/unique.md
+++
b/i18n/zh-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)获取相关使用建议。
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/table-design/data-model/unique.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/table-design/data-model/unique.md
index 233b45c0aa6..a15d4c7463b 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/table-design/data-model/unique.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/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)获取相关使用建议。
\ No newline at end of file
diff --git a/versioned_docs/version-2.0/table-design/data-model/unique.md
b/versioned_docs/version-2.0/table-design/data-model/unique.md
index c29eeda517f..54dc680fe6f 100644
--- a/versioned_docs/version-2.0/table-design/data-model/unique.md
+++ b/versioned_docs/version-2.0/table-design/data-model/unique.md
@@ -31,6 +31,7 @@ When users have data update requirements, they can choose to
use the Unique data
The Unique data model provides two implementation methods:
- 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. Starting from version 1.2, Doris has introduced the
merge-on-write implementation, which completes all data deduplication work
during the data write phase, thus providing excellent query performance. On a
Unique table with the merge-on-write option enabled, data that will be
overwritten and updated during the import phase will be marked for deletion,
and new data will be written to a new file. During a query, all marked data
will be filtered out at the file level, and t [...]
Let's look at how to create a Unique model table with merge-on-read and
merge-on-write using a typical user basic information table as an example. This
table does not have aggregation requirements and only needs to ensure the
uniqueness of the primary key (The primary key is user_id + username).
@@ -104,6 +105,9 @@ In version 2.1, Merge-on-Write will be the default behavior
for the unique key m
## 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.
\ No newline at end of file
diff --git a/versioned_docs/version-2.1/table-design/data-model/unique.md
b/versioned_docs/version-2.1/table-design/data-model/unique.md
index 6839922f5c3..1ee9737e01f 100644
--- a/versioned_docs/version-2.1/table-design/data-model/unique.md
+++ b/versioned_docs/version-2.1/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.
\ No newline at end of file
diff --git a/versioned_docs/version-3.0/table-design/data-model/unique.md
b/versioned_docs/version-3.0/table-design/data-model/unique.md
index 6839922f5c3..1ee9737e01f 100644
--- a/versioned_docs/version-3.0/table-design/data-model/unique.md
+++ b/versioned_docs/version-3.0/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.
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
