This is an automated email from the ASF dual-hosted git repository.
luzhijing pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/master by this push:
new 0de7f9787b [doc](typo) Fix a few character errors (#17911)
0de7f9787b is described below
commit 0de7f9787ba25b6147b5df1cce49e8d30a1231eb
Author: Jiwen liu <61498169+liujiwen...@users.noreply.github.com>
AuthorDate: Sun Mar 19 09:09:02 2023 +0800
[doc](typo) Fix a few character errors (#17911)
---
.../docs/advanced/join-optimization/doris-join-optimization.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/docs/zh-CN/docs/advanced/join-optimization/doris-join-optimization.md
b/docs/zh-CN/docs/advanced/join-optimization/doris-join-optimization.md
index b90e3bc4d0..98ad05f5ce 100644
--- a/docs/zh-CN/docs/advanced/join-optimization/doris-join-optimization.md
+++ b/docs/zh-CN/docs/advanced/join-optimization/doris-join-optimization.md
@@ -121,7 +121,7 @@ Runtime Filter 适用的场景有两个要求：
Doris 提供了三种不同的 Runtime Filter 类型：
-- **IN** 的优点就是效果过滤效果明显，且快速。它的缺点首先第一个它只适用于 BroadCast，第二，它右表超过一定数据量的时候就失效了，当前
Doris 目前配置的是1024，即右表如果大于 1024，IN 的 Runtime Filter 就直接失效了。
+- **IN** 的优点是过滤效果明显，且快速。它的缺点首先第一个它只适用于 BroadCast，第二，它右表超过一定数据量的时候就失效了，当前 Doris
目前配置的是1024，即右表如果大于 1024，IN 的 Runtime Filter 就直接失效了。
- **MinMax** 的优点是开销比较小。它的缺点就是对数值列还有比较好的效果，但对于非数值列，基本上就没什么效果。
- **Bloom Filter** 的特点就是通用，适用于各种类型、效果也比较好。缺点就是它的配置比较复杂并且计算较高。
@@ -145,7 +145,7 @@ Doris 目前支持基于规则的 Join Reorder 算法。它的逻辑是：
Doris Join 调优的方法：
-- 利用 Doris 本身提供的 Profile，去定位查询的瓶颈。Profile 会记录 Doris 整个查询当中各种信息，这是进行性能调优的一手资料。。
+- 利用 Doris 本身提供的 Profile，去定位查询的瓶颈。Profile 会记录 Doris 整个查询当中各种信息，这是进行性能调优的一手资料。
- 了解 Doris 的 Join 机制，这也是第二部分跟大家分享的内容。知其然知其所以然、了解它的机制，才能分析它为什么比较慢。
- 利用 Session 变量去改变 Join 的一些行为，从而实现 Join 的调优。
- 查看 Query Plan 去分析这个调优是否生效。
@@ -221,6 +221,6 @@ where
- 第一点：在做 Join 的时候，要尽量选择同类型或者简单类型的列，同类型的话就减少它的数据 Cast，简单类型本身 Join 计算就很快。
- 第二点：尽量选择 Key 列进行 Join， 原因前面在 Runtime Filter 的时候也介绍了，Key 列在延迟物化上能起到一个比较好的效果。
-- 第三点：大表之间的 Join ，尽量让它 Co-location ，因为大表之间的网络开销是很大的，如果需要去做 Shuffle 的话，代价是很高的。
+- 第三点：大表之间的 Join ，尽量让它 Colocation ，因为大表之间的网络开销是很大的，如果需要去做 Shuffle 的话，代价是很高的。
- 第四点：合理的使用 Runtime Filter，它在 Join
过滤率高的场景下效果是非常显著的。但是它并不是万灵药，而是有一定副作用的，所以需要根据具体的 SQL 的粒度做开关。
- 最后：要涉及到多表 Join 的时候，需要去判断 Join 的合理性。尽量保证左表为大表，右表为小表，然后 Hash Join 会优于 Nest
Loop Join。必要的时可以通过 SQL Rewrite，利用 Hint 去调整 Join 的顺序。
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
