[doc](unique key) update description for unique key in data model doc

docs/zh-CN/docs/data-table/data-model.md

@@ -414,11 +414,21 @@ mysql> select sum_merge(k2) , group_concat_merge(k3)from aggstate where k1 != 2;
 
 ## Unique 模型
 
-在某些多维分析场景下，用户更关注的是如何保证 Key 的唯一性，即如何获得 Primary Key 唯一性约束。
-因此，我们引入了 Unique 数据模型。在1.2版本之前，该模型本质上是聚合模型的一个特例，也是一种简化的表结构表示方式。
-由于聚合模型的实现方式是读时合并(merge on read)，因此在一些聚合查询上性能不佳（参考后续章节[聚合模型的局限性](#聚合模型的局限性)的描述），
-在1.2版本我们引入了Unique模型新的实现方式，写时合并（merge on write），通过在写入时做一些额外的工作，实现了最优的查询性能。
-写时合并将在未来替换读时合并成为Unique模型的默认实现方式，两者将会短暂的共存一段时间。下面将对两种实现方式分别举例进行说明。
+当用户有数据更新需求时，可以选择使用Unique数据模型。Unique模型能够保证Key的唯一性，当用户更新一条数据时，新写入的数据会覆盖具有相同key的旧数据。
+
+**两种实现方式**
+
+Unique模型提供了两种实现方式：
+
+- 读时合并(merge-on-read)。在读时合并实现中，用户在进行数据写入时不会触发任何数据去重相关的操作，所有数据去重的操作都在查询或者compaction时进行。因此，读时合并的写入性能较好，查询性能较差，同时内存消耗也较高。
+- 写时合并(merge-on-write)。在1.2版本中，我们引入了写实合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。
+
+自2.1版本起，写实合并已经非常成熟稳定，也成为了Unique模型的默认实现。关于两种实现方式的详细区别，用户可以本章节后续内容的介绍。关于两种实现方式的性能差异，参考后续章节[聚合模型的局限性](#聚合模型的局限性)的描述。
+
+**数据更新的语意**
+
+- Unique模型默认的更新语意为**整行`UPSERT`**，即UPDATE OR INSERT，该行数据的key如果存在，则进行更新，如果不存在，则进行新数据插入。在整行`UPSERT`语意下，即使用户使用insert into指定部分列进行写入，Doris也会在Planner中将未提供的列使用NULL值或者默认值进行填充
+- 部分列更新。如果用户希望更新部分字段，需要使用写实合并实现，并通过特定的参数来开启部分列更新的支持。请查阅文档[部分列更新](../data-operate/update-delete/partial-update.md)获取相关使用建议
 
 ### 读时合并（与聚合模型相同的实现方式）
 
@@ -494,7 +504,7 @@ PROPERTIES (
 
 ### 写时合并
 
-Unique模型的写时合并实现，与聚合模型就是完全不同的两种模型了，查询性能更接近于duplicate模型，在有主键约束需求的场景上相比聚合模型有较大的查询性能优势，尤其是在聚合查询以及需要用索引过滤大量数据的查询中。
+Unique模型的写时合并实现，查询性能更接近于duplicate模型，在有主键约束需求的场景上相比聚合模型有较大的查询性能优势，尤其是在聚合查询以及需要用索引过滤大量数据的查询中。
 
 在 1.2.0 版本中，作为一个新的feature，写时合并默认关闭(2.1 版本之前)，用户可以通过添加下面的property来开启
 
@@ -505,8 +515,10 @@ Unique模型的写时合并实现，与聚合模型就是完全不同的两种
 从 2.1 版本开始，写时合并默认开启。
 
 > 注意：
-> 1. 建议使用1.2.4及以上版本，该版本修复了一些bug和稳定性问题
-> 2. 在be.conf中添加配置项：disable_storage_page_cache=false。不添加该配置项可能会对数据导入性能产生较大影响
+> 1. 对于1.2的用户
+>    1. 建议使用1.2.4及以上版本，该版本修复了一些bug和稳定性问题。
+>    2. 在be.conf中添加配置项：disable_storage_page_cache=false。不添加该配置项可能会对数据导入性能产生较大影响
+> 1. 对于新用户，强烈推荐使用2.0版本。在2.0版本中，写实合并的性能和稳定性都有大幅的提升和优化
 
 仍然以上面的表为例，建表语句为
 
@@ -547,9 +559,8 @@ PROPERTIES (
 所有被标记删除的数据都会在文件级别被过滤掉，读取出来的数据就都是最新的数据，消除掉了读时合并中的数据聚合过程，并且能够在很多情况下支持多种谓词的下推。因此在许多场景都能带来比较大的性能提升，尤其是在有聚合查询的情况下。
 
 【注意】
-1. 要使用Merge-on-write实现的unique表，只能在建表时通过指定property的方式打开。在2.1版本之前该属性默认关闭，从2.1版本开始，该属性默认打开。
+1. Unique表的实现方式只能在建表时确定，无法通过schema change进行修改。
 2. 旧的Merge-on-read的实现无法无缝升级到Merge-on-write的实现（数据组织方式完全不同），如果需要改为使用写时合并的实现版本，需要手动执行`insert into unique-mow-table select * from source table`.
-3. 在Unique模型上独有的delete sign 和 sequence col，在写时合并的新版实现中仍可以正常使用，用法没有变化。
 
 </version>