©2020-2024 ioDraw All rights reserved,
Privacy Policy
1、Doris 是否支持mysql 客户端直接连接
支持，建议使用mysql 5.x.x 版本客户端
mysql 8 会存在默认认证不通过问题
2、Doris支持UPDATE语句么
Doris是OLAP数据库，可以通过REPLACE模型支持UPDATE语义，但不支持UPDATE语句。
可以执行INSERT/DELETE语句，高频执行点更新（低于10秒/次）会极大影响查询性能。
3、Doris支持多大的数据量
从经验的测试结果看，Doris百万级扫描量的查询能够做到秒级延迟。如果利用好索引和ROLLUP，简单的过滤（可以有效过滤掉大部分数据）聚合最多可以支撑到亿级别数据量的查询，但查询时延不能保证。
4、Doris如何使用索引
Olap场景下的查询优化通常是在优化建模，因此如果想要取得较好的查询性能，就需要对Rollup和索引的特点和适用场景有所了解。
如官方文档描述，Rollup使用前36位字节作为前缀索引（到VARCHAR截断）。能用前缀索引的列上的条件需要是
=、<、>、<=、>=、in、between，并且这些条件是并列的且关系使用 and 连接，对于or、!= 等这些不能命中。
Doris会选择命中前缀索引最多的Rollup，匹配时首先根据等式条件（=,
in），然后只匹配一列不等式条件（<、>、<=、>=、between）。所以要将使用等式条件的维度列尽可能放在ROLLUP前面。
分区列会占用前缀索引，一般查询都会根据分区进行等式过滤，所以分区列一般放在ROLLUP第一列。
放在后面的过滤条件无法命中前缀索引，只能扫描后进行过滤。
最佳实践
如果查询的谓词比较固定，且大部分时候可以满足前缀匹配，那么可以只用Base表，如果性能较差，可以再考虑添加Rollup
如果是灵活多维过滤场景，过滤性较好，可以选择只建索引，然后验证查询性能。如果不能满足需求，可以再尝试建立一些Rollup
5、Doris是否支持UDF
不支持。Doris BE由C++实现，不支持Java UDF（可类比MySQL）。
6、更改表结构/添加Rollup显示成功，实际没有变更
Doris修改表结构是异步操作，参考 官方文档 Schema Change
可以执行以下SQL查看变更操作执行情况，该记录不会永久保存。
SHOW ALTER TABLE COLUMN; -- 变更列操作
SHOW ALTER TABLE ROLLUP; -- 变更ROLLUP操作
7、更改表结构报错
Can not alter table when there are temp partitions in table
表中有临时分区存在将临时分区删除即可（注意，临时分区删除不可恢复）
8、新增一个rollup会阻塞查询吗？
不会
9、新增rollup的时间会有多长时间，是和数据量大小有关吗？
不确定，和数据量大小有关，有的可能执行几个小时
10、如何确认是否为大查询
扫描时间范围过大（例如扫一个月以上），请确保分区过滤条件中的过滤值和分区列相同，例如分区列类型是int，则使用dt=20201111，如果分区列类型是char，则使用dt='20201111'；
扫描数据量过大，bitmap列较多；
过滤性较好的谓词较少，存在大量的数据scan；
如果通过减少时间范围，减少去重列，添加过滤性较好的谓词发现查询时间有所降低，那么基本可以判定是当前查询为大查询。
优化思路如下
优化sql，比如缩小时间范围，减少bitmap列，添加必要的谓词；
添加rollup，降低查询时的计算量。不过rollup也并非越多越好，增加rollup的负面影响是，增加存储空间以及导入时的性能开销；
11、如何保障集群效率和稳定性
每个查询在生成分布式查询计划后，每个PlanFragment都有一系列Instance，即查询实例。这些查询实例将分发到具体的BE执行。大致可以认为查询实例越多，查询占用的资源越多。
同一时间查询使用资源过多会导致集群效率大幅度下降，故采取限流策略，同DB下配置查询实例限制，超过时报错。当查询结束时释放查询实例。
出现此报错通常是出现不合理查询（大范围扫描，大量现场计算），一个大查询会占用几百个小查询的资源，请先检查是否有不合理大查询出现。
常见不合理查询原因：
分区过滤条件失效 partition_dt = null，请在程序中进行防守
天分区表三个月-年级跨分区查询，且ROLLUP设置不合理导致单分区扫描上G数据量，再进行大量现场计算。建议配置合理的ROLLUP和过滤条件。
大量BITMAP/HLL现场计算，上万的聚合计算会导致查询出现秒级延迟。建议合理预聚合。
注意，优化不合理查询不一定能减少查询实例数，但是可以大幅度优化查询时间，快速释放查询资源。
12、Reach limit of connections
Doris不支持超高并发查询，单集群支持QPS为千级。所以不要配置大连接池！！！单机连接Doris连接池大小为3-5条即可。
当建立一条连接时，Doris会首先检查单台FE的连接数，超过会报错。默认值1024
13、表结构问题
Error : The size of a row (132128) exceed the maximal row size: 100000
这个报错的意思是，建表或者修改schema时每个字段类型的长度加起来超过阈值。
Doris不建议使用大宽表，过多的key列会使聚合计算性能降低，而过多的null值会时导入时倾斜严重。
14、BE报错日志
Plain Textschema_change.cpp:517] fail to allocate memory.
schema_change.cpp:1058] failed to sort row block.schema_change.cpp:1741] failed
to process the version. version=xxxxx
此时调大BE配置memory_limitation_per_thread_for_schema_change，注意创建完后及时调回。
该参数一般最大设为32(G)，再大可能使BE节点OOM导致宕机，如需该大需要用户知晓风险。
15、Create replicas failed. Error: Error replicas:
报错信息
Plain Text
errCode = 2, detailMessage = Create replicas failed. Error: Error
replicas:XXX=XXX, XXX=XXX, XXX=XXX
其中XXX=XXX 前面是BE的id，后面是replica id。去对应BE 机器搜replica id。
16、Failed to create partition. Timeout. Unfinished mark:
报错信息
Plain Text
Failed to create partition[pxxxxxxxx]. Timeout. xxxxxxxx Unfinished mark:
xxx=xxx, xxx=xxx, xxx=xxx
官方解释
临时调整tablet创建的超时时间 max_create_table_timeout_second
17、tablet xxx has few replicas: 1
导致这个报错的因素会有很多，以下分情况讨论
导入时失败报错
导入时负载过高导致be使用内存过大被操作系统杀死，因此看起来像是缺副本，但根因在于导入负载，需要确定以下信息：
1 是稳定复现还是偶尔复现，如果是稳定复现，那么大概率是任务本身导入并发过大；如果是偶尔复现，那么有可能是整个集群导入并发很高，也可能是受其他任务影响
2 出问题的时间点，精确到一个时间段，管理员需要看下对应时间段be的内存使用情况，如果出现空闲内存只剩百分之几且be有重启，那么基本可以断定是导入导致的
解决方案：集群扩容或者业务调低导入并发