poc阶段遇到的优化问题

OceanBase 技术问题
,
#1

基本信息:

背景: oceanbase 4.3.4 poc

Greenplum
	单台: 16c100g(虚拟机)  *  4
	共计: 64c,400g

Ooceanbase
	单台: 租户28c80g(虚拟机是32c128g)  *  3 
	共计: 84c,240g

省略300行的join 大数据AP SQL

第一次对比

GP=180秒
OB
	- 列存583秒
	- 行存705秒

第二次对比

修改大SQL查询资源控制
	large_query_threshold=10s
	large_query_worker_percentage= 30 to 80

查询效果一样。

第三次对比

发现Select /*+ parallel(32) */  * FROM t1; 对单条子查询从9秒变成0.5秒。
继续找全局参数: set _force_parallel_query_dop = 32;   session级别

GP=180秒
OB
	- 列存119秒
	- 行存94秒

第四次对比

    set global parallel_degree_policy='auto'  SQL继续降到27秒了。
    OB=27秒

第五次对比

    OB=15秒
    最终5-10秒左右。

    按AP模板参数优化：
    https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002012871
    https://www.oceanbase.com/docs/common-oceanbase-cloud-1000000001964068
    https://open.oceanbase.com/blog/12082655296
    隐藏参数查看(sys租户):
    select * from oceanbase.__all_virtual_sys_parameter_stat where name = '_rowsets_max_rows';

总结

1. _force_parallel_query_dop是个Session级参数, 是否有全局参数？
2. 是否有其它优化建议？
3 个赞
#3

对于这个sql建议使用outline进行绑定，这样后期跑出更好的执行计划可以动态调整，设置全局资源会跑满机器cpu
CREATE OUTLINE outline_t1 ON ‘69AE2D9E3BF106CE009F93EFAF925xxx’ USING HINT /+ parallel(32)/ ;具体使用参考下面的文档
如何创建 Outline 并验证 Outline 生效-OceanBase知识库

#4

列存比行存还要慢，这是什么样的 SQL？

#5

大数据生产拿出来的，很多with xx as

#6

执行计划能发下吗，是否执行计划存在问题

#7

执行计划，都要上翻几千页，不聊这个SQL了吧。 :sweat_smile:

#8

ob的集群架构是啥样。1-1-1还是单zone3个server
租户的primary zone是怎么设定的，目前没有设置全局并行度的参数

#9

是的1-1-1

image

#10

设置为zone1为优先，zone1；zone2；zone3这种再试试sql

#11

修改了，还需要手动驱逐leader节点到zone1吗？我等半小时后再次执行的SQL，用时10分钟左右。
效果可以忽略不计，目前最有效果的还是parallel hint。

#12

测试 AP 场景？可以试试用 AP 的参数模板。

#13

image

这个吗？集群级别的模板，默认就用了吧。

#14

应该没用到，部署集群和租户的时候设置的。

感觉应该用纯 OLAP 的模版，可以参考这个：【量体裁衣】参数模板功能推荐 。

2 个赞