(一) 并行查询的概述
1. 并行查询操作的概述
- 通过大的数据查询分成许多小的并行任务，每个任务由一个线索进行完成，每个线索运行在不同的物理CPU上，通过多个CPU共同完成一个任务，达到真正的并行
- gbase8s数据库的并行查询功能称为PDQ（Parallel Data Query)，其充分利用了多CPU的能力，并行操作如下
-
- 并行扫描
- 并行连接
- 并行排序
- 并行分组
- 并行汇总
- 有些操作可能会导致PDQ不生效，不生效的场景如下
-
- 使用了cursor stability事务隔离级别
- 定义为for update或者with hold的游标
- 相关子查询
- 查询中包含了SPL调用：select col from tab where clo2=proc();
2. 并行排序的场景
- 以下场景中，如果有必要，会进行并行排序，如果数据量大，会利用磁盘空间，如果数据量小，则全部在内存中进行排序
-
- select语句中具有oracle或group by子句，但不能通过索引去排序
- select语句通过unique和distinct排除重复的记录
- 创建索引时需要对键值排序
3. 并行功能的开启
- 并行参数：
-
- PSORT_NPROCS：设置了一个用户连接可以使用的排序线索的数目
-
-
- 大于1表示多个一个用户可以多线索执行
- 不论是否设置，索引创建的排序部分都会以并行方式进行，这个参数决定了为每个btree appender线索初始化多少个排序线索，没有设置默认为2
-
-
- PDQPRIORITY：
-
-
- 并行度，小于和等于0都会设置为0，表示关闭并行；
- 1表示并行级别为low
- 100和100以上都会设置为100，表示high，高并行度
- 决定排序的内存和扫描的线索，设置大于0，可以提高创建索引的速度
-
- 排序和并行数据库查询（PDQ）：
-
- 当PSORT_NPROCS大于1，不管是否设置了PDQPRIORITY环境变量，排序都将以并行的方式运行
- 当PSORT_NPROCS大于1，将PDQPRIORITY大于0时，会申请额外的排序线索，并行排序将极大受益
- 建议：当执行并行数据库查询时，一般将建议初始PSORT_NPROCS设置为2，然后监控磁盘读写和CPU的活动
4. 并行查询的参数配置
- MAX_PDQPRIORITY：用来限制任何一个PDQ拆线呢可以获得的资源
-
- 当使用PDQ时，需要在应用中通过set PDQPRIORITY来设置一个并行的值，这个值*MAX_PDQPRIORITY*DS_MAX_SCANS/10000是一个实际的查询在运行时的并行度
- 0：表示不能使用并行
- 通过PDQPRIORITY的值可以平衡OLAP和OLTP的资源，
-
-
- 如白天OLTP较多时，可以设置小点
- 晚上OLTP较少时，设置大点，允许OLAP获取更多的资源
-
- DS_MAX_QUERIES：同时可以并行运行的查询数量
- DS_TOTAL_MEMORY：定义了并行数据查询可以使用的共享内存上限，这部分内存是从虚拟段中申请的，可以根据需求进行申请
- DS_MAX_SCANS：限制了服务器可以运行的扫描线索，一般针对一个分片会启动一个扫描线索
- DATASKIP：查询时，服务器可以跳过离线的chunk
- DS_NONPDQ_QUERY_MEM：不使用PDQ并行查询时可以使用的内存大小
(二) 并行创建索引的描述
1. 并行创建索引的过程设计和产生索引的操作
- 前提：如果表的数据页小于100个，服务器将不使用并i选哪个创建索引的技术
- 产生索引的操作
-
- 增加唯一性约束
- 创建主键
- 添加约束
- 使约束生效
- 上述操作都会出现产生索引的操作
2. 并行创建索引的步骤
- 并行创建索引过程
-
- 先在表中进行取样，取出1000条记录，根据其中的分布决定如何分桶，每个桶的值范围是多少
- 服务器扫描表中的记录并使用排序的机制对取出来的键值做排序
- 将并行排序后的值根据各个桶的区域范围，将抽取出来的数据放入到各个桶内
- 各个线索将各自桶内的数据取出根据规则生成或增补到其中一个子树
- 由于这些键值事分开进行排序的，所以各个b+子树拆创建好后，可以很快合成完整的子树
3. 并行创建索引期间各种线索的操作
- 扫描线索读取数据
-
- 从共享内存中读取数据，抽取键值，如果不在共享内存中，则扫描线索发送一个请求到AIO VP去读磁盘上的页面
- 排序线索拿到扫描线索读出的值进行排序，排序键值
- 扫描线索从共享内存中读取数据，抽取键值，决定放到哪个桶内
-
- 决定后，将数据传递给排序线索，排序线索负责对桶中的数据进行排序
- appender线索创建子树
- sqlexec线索负责把所有子树合成一个树
- b-tree appender线索开始生成索引子树之前，扫描和排序线索必须完成他们的工作
4. 并行创建索引申请线索数量的影响因素
- 表所在的每个dbspace的每个chunk都会申请一个扫描线索
- 如果PSORT_NPROCS设置为x，排序的线索为（appender thread * x），如果不设置则为2
- 依赖于索引页面的数目，b-tree appender的配置值事1~6
| 线索数目 | 索引页数目 |
| 1 | <400 |
| 2 | 400~!4000 |
| 3 | 4000~40000 |
| 4 | 40000~200000 |
| 5 | 200000~1000000 |
| 6 | >1000000 |
- 假设在4字节的一个字段上创建一个索引，索引的页面为4KB，由于每个页面最多存储255个数据，255*400=10.2万，由此推断出，低于10.2万键值时，会使用一个appender线索，其他依次类推
-
- 4字节*255=1020字节，加上其他信息可以算一个页面
- 只有filefactor的值为100时，才会存放到255条数据，上述计算都是假设filefactor为100的时候进行计算的
- 影响因素是服务器上的CPU数量，服务器不允许b-tree appender线索的数目超过CPU Vps的数目
(三) 并行的监控
1. onstat -g mgm
[gbasedbt@iZ2ze4p3q6wy4hzagubdmbZ ~]$ onstat -g mgm
Your evaluation license will expire on 2025-06-24 00:00:00
On-Line -- Up 1 days 09:21:15 -- 4275148 Kbytes
Memory Grant Manager (MGM)
--------------------------
--当前各个参数设置的值
--限制PDQ查询可以获得的资源数量
MAX_PDQPRIORITY: 100
--同时运行的并行查询数量
DS_MAX_QUERIES: 4
--服务器可以运行的扫描线索
DS_MAX_SCANS: 1048576
--非PDQ查询时可以使用的内存大小
DS_NONPDQ_QUERY_MEM: 20480 KB
--并行查询使用的内存上限
DS_TOTAL_MEMORY: 4096000 KB
-----------正在运行的PDQ数 准备运行但是由于负载或者其他原因推迟的PDQ数量 允许活动的最大数量
Queries: Active Ready Maximum
0 0 4
---------PDQ全部可用内存 未使用的内存 正在使用的内存
Memory: Total Free Quantum
(KB) 4096000 4096000 1024000
----指定的扫描线程总数 空闲或者可用的线程数量 扫描中的扫描线程数，最后一个是MGM监控使用的
Scans: Total Free Quantum
1048576 1048576 1
----------------------------
-- 等待内存的查询数 等待扫描的查询数 具有高优先级的PDQ查询数 正在等待查询的数量
Load Control: (Memory) (Scans) (Priority) (Max Queries) (Reinit)
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5
(Queue Length) 0 0 0 0 0
Active Queries: None
Ready Queries: None
-------------------平均内存量和扫描线程数 最小的使用内存量和扫描线程数
Free Resource Average # Minimum #
-------------- --------------- ---------
Memory 0.0 +- 0.0 512000
Scans 0.0 +- 0.0 1048576
-------------------平均活动和就绪队列长度 最大活动和就绪队列长度 活动和就绪的总长度
Queries Average # Maximum # Total #
-------------- --------------- --------- -------
Active 0.0 +- 0.0 0 0
Ready 0.0 +- 0.0 0 0
Resource/Lock Cycle Prevention count: 0
217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
