顺序扫描预读

可获得性

本特性自MogDB 5.0.8版本开始引入。

特性简介

MogDB的顺序扫描预读针对较大数据量下的纯数据表顺序扫描场景（全表扫描场景）进行优化，提升扫描性能。本特性支持Astore和Ustore两种存储引擎，并且支持并行扫描下预读。

客户价值

并行化顺序扫描过程中的CPU处理和I/O操作，减少I/O对CPU的阻塞，提高CPU利用率，以提升顺序扫描性能。

特性描述

数据库中的数据是按照一个个页面进行组织管理的，CPU以页面为单位对数据进行处理，这就使得CPU处理和I/O之间形成了串行交替执行的现象。在该处理模型中，由于一个页面的I/O时延明显大于CPU处理一个页面的时间，导致CPU处理过程会被I/O操作频繁打断，使CPU利用率低下，这是导致如全表扫描等场景性能差的主要原因。

顺序扫描预读机制改变了该处理模型，将顺序扫描的CPU处理过程与I/O操作并行化，尽量避免CPU因为等待I/O而阻塞。理想状态是，当CPU将要处理下一个数据页时，刚好I/O服务例程已经将该数据页准备好放在内存中。这种模型我们定义为数据页预读机制（data prefetch）。

本特性在全表扫描类查询（如TPCH场景）中，SeqScan算子性能提升20%-60%，端到端性能提升10%-20%。

注：

并非所有SQL在任何测试场景下，都有上述性能提升。预读性能提升主要和查询语句的复杂度（CPU计算和I/O耗时）及磁盘带宽有关，其他影响因素包括是否为全缓存场景、是否为混合查询负载。

算子性能提升明显的SQL特征：CPU计算耗时重，I/O带宽未达到磁盘最大带宽。
端到端性能提升明显的SQL特征：CPU计算和I/O耗时各占50%左右，I/O带宽未达到磁盘最大带宽。

本特性默认关闭，设置GUC参数enable_ios = on，enable_heap_async_prefetch = on启用Astore顺序扫描预读。设置GUC参数 enable_ios = on，enable_uheap_async_prefetch = on启用Ustore顺序扫描预读。

性能对比

本特性在不同并行度下主节点执行TPCH测试的性能提升的结果、以及在混合负载（tpcc+tpch）的情况下性能提升的结果和对TPMC的影响如下。

注：下图中纵轴为算子或者SQL的执行时间（单位：秒），横轴为执行的SQL

Astore性能数据
- dop=1：TPCH顺序扫描算子提升为52%，端到端的提升为27%：
- dop=8：TPCH顺序扫描算子提升为28%，端到端的提升为13%：
- 混合负载（tpcc+tpch）的情况下性能提升的结果和对TPMC的影响：
  
  TPCH顺序扫描算子提升为19%，端到端的提升为10%，并且tpmc不受预读影响。
  
  注：不开启预读的 tpmc 为：410204 ，开启预读的 tpmc 为：414793
Ustore性能数据

不同并行度下主节点tpch测试的结果：
- dop=1：总体算子提升为41%，端到端的提升为19%
- dop=4：总体算子提升为43%，端到端的提升为21%
- dop=8：总体算子提升为45%，端到端的提升为23%
- dop=16：总体算子提升为37%，端到端的提升为13%
混合负载（tpcc+tpch）的情况下性能提升的结果和对TPMC的影响：
- dop=1：总体算子提升为32%，端到端的提升为19%，tpmc效果提升3%，tpmc不受预读影响
- dop=4：总体算子提升为38%，端到端的提升为22%，tpmc效果提升2%，tpmc不受预读影响

特性约束

支持串行扫描和并行扫描场景预读。
当前版本支持Astore引擎和Ustore引擎，不支持Cstore以及段页式引擎。
建议NVMe SSD开预读，磁盘不开预读。

使用指导

使用限制

如果使用普通的机械硬盘，磁盘IO带宽可能是系统瓶颈，所以不能体现出预读的优势。
顺序预读机制主要适用于数据量很大的表（至少为GB级别），对于数据量很小的表，不建议开启预读，目前默认1G触发预读，可以设置的触发预读的最小表大小为512MB，用户可以由GUC参数min_table_block_num_enable_ios和min_uheap_table_block_num_enable_ios调整触发预读的表大小。

配置步骤

配置Astore预读

enable_ios = true  // 系统级别，重启数据库生效，默认为false
enable_heap_async_prefetch=true  // 会话级别，支持在线配置，默认为false

配置Ustore预读

enable_ios = true  // 系统级别，重启数据库生效，默认为false
enable_uheap_async_prefetch=true  // 会话级别，支持在线配置，默认为false

GUC参数

注意：除了enable_ios和ios_worker_num需要重启数据库生效，其他GUC参数都支持在线配置。

序号	参数描述
1	enable_ios：控制是否启动IOS服务。
2	enable_heap_async_prefetch：控制是否对Astore全表扫描类场景启用预读功能。
3	enable_uheap_async_prefetch：控制是否对Ustore全表扫描类场景启用预读功能。
4	ios_worker_num：IOS线程池里面的ios_worker个数。
5	parallel_scan_gap：开启并行扫描时（query_dop > 1），每个工作线程单次处理的页面数量。
6	ios_batch_read_size：ios_worker每个批次下发给盘的预读页面个数。
7	max_requests_per_worker：每个ios_worker最大队列深度。
8	min_table_block_num_enable_ios：触发预读的Astore表大小阈值。只有当表的数据页总数大于等于该阈值时，才有可能触发预读。目前数据页大小为8kB。
9	min_uheap_table_block_num_enable_ios：触发预读的Ustore表大小阈值。只有当表的数据页总数大于等于该阈值时，才有可能触发预读。目前数据页大小为8kB。
10	prefetch_protect_time：预读buffer最大保护时间。
11	ios_status_update_gap：更新IOS性能状态的时间间隔。

运维监控能力

用户可以通过执行计划里的shared buff hit命中指标，直观感受开启预读的效果，可以明显看到buffer命中率极高，并且配合打开GUC参数：track_io_timing = on，观测I/O Timings: read ，即IO读时延极低。
相关性能视图：IOS_STATUS

使用方法：select * from ios_status();

用于查看最近一段时间负责预读的IO线程池的性能状态，包含IOSCtl派发请求，IO时延/带宽，队列积压等指标。当主查询线程IO时延很高或者缓存命中率低等问题出现的时候，用户或者研发人员可以通过直观查看预读线程池的性能来帮助定位。