页面树结构
转至元数据结尾
转至元数据起始



概述

setFetchSize方法会提供一个数值给JDBC驱动,这个数值是当数据集对象需要读取更多行时,应该从数据库中获取的行数。使用JDBCFetch Size时需要综合考虑支持程度和具体业务系统等多种因素,但并不是所有数据库都支持FetchSize。

设置FetchSize情况

在数据量为百万级别的情况下,不同数据库设置不同的FetchSize,对时间变化百分比进行分析,如下图所示:

结论如下:

(1)设置FetchSize之后,DB2_V9、HANA、ORACLE和SHNENTONG这几个数据库在查询效率上均有较大的提高,特别是ORACLE和SHENTONG数据库,查询时间较设置前减少了百分之九十几。

(2)CLICK_HOUSE、MYSQL、DAMENG和VERTICA需要谨慎设置Fetch Size,设置后其查询效率不升反降或者无明显提升。

(3)其余数据库类型大多无明显影响。

FetchSize大小梯度情况

在数据量为百万级别的情况下,对各数据库设置的Fetch Size为1k、5k、1w、5k和10w后查询的总耗时进行分析,如下图所示:

结论如下:

(1)从整体上看,当不考虑内存占用时,对于绝大部分数据库而言,逐渐增大FetchSize的值时查询的总耗时呈逐渐下降的趋势。

(2)当FetchSize的值在1w左右,对于大部分数据库而言查询效率都有一个不错的提升,因此1w是一个比较合适的值。

(3)对于某些数据库具体而言,如:DB2_V9、HANA、MYSQL、ORACLE、SHENTONG和TERADATA_V12随FetchSize值的增大而效率提升巨大;CLICK_HOUSE、DAMENG和POSTGRESQL的查询效率也有一定幅度的提升;DAMENG_V6、INFORMIX、VERTICA、ALIYUN_MAX_COMPUTE和IMPALA的相关影响不大;GBASE、KINGBASE、MSSQL、GREENPLUM和KINGBASEANALYTICS的查询效率反而是有一定幅度的降低。

性能示例

所用测试环境tomact为:8C25G,知识库为mysql 8C32G,资源选取两个字段,每个字段拼接成40个字符长度,CPU统计平均值,内存按最大使用量统计。

当业务库为100W 17字段,来源原生SQL,4字段,字符长度为200个字符时,FetchSize对oracle影响如下:


并发数内存时间
fetchsize500018.653069496154785M102.116S
543.27322769165039M194.628S
fetchsize100011.465561866760254M157.503S
57.335727691650391M268.529S

当业务库为1W 34字段,字符长度为660个字符时,FetchSize对oracle影响如下:


并发数内存时间
fetchsize500011024.4028844833374M64.726S
55122.023144721985M73.280s
fetchsize10001128.40294456481934M70.185S
5642.0231428146362M79.966S

当业务库为100W 17字段,来源原生SQL,4字段,字符长度为200个字符时,FetchSize对vertica影响如下:


并发数内存时间
fetchsize500010.04086112976074219M96.722S
50.2041492462158203M189.305S
fetchsize100010.04081153869628906M96.521S
50.2035961151123047M195.189S

通过上述示例,FetchSize性能情况总结如下:

(1)oracle 单次查询内存大小受fetchsize大小设置影响,值越大,内存使用越多,性能越慢。

(2)vertica 单次查询内存大小不受fetchsize大小设置影响。

(3)资源字符长度越长,内存使用越大;字段越多,内存使用也越大;而内存使用不受数据行数大小影响。

(4)FetchSize的大小设置要合理,根据当前应用服务器所分配的内存大小及系统并发数等条件谨慎选择,且需考虑相关内存问题,避免出现内存溢出。

  • 无标签