Ustore SMP并行扫描

可获得性

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

特性简介

MogDB的SMP并行技术是一种利用计算机多核CPU架构来实现多线程并行计算，以充分利用CPU资源来提高查询性能的技术。之前的SMP并行技术仅支持Astore存储引擎，MogDB 5.0.8新增了对于Ustore存储引擎的并行能力支持。

特性描述

在复杂查询场景中，单个查询的执行较长，系统并发度低，通过SMP并行执行技术实现算子级的并行，能够有效减少查询执行时间，提升查询性能及资源利用率。

本特性中，Ustore 存储引擎的 SMP 并行能力涵盖以下几种场景：

1. 并行顺序扫描（Parallel Seq Scan）

2. 并行索引扫描（Parallel Index Scan）

3. 并行仅索引扫描（Parallel Index Only Scan）

4. 并行位图扫描 （Parallel Bitmap Scan）

是否开启并行下的性能对比

• Seq Scan

  

  开启并行后，随着并行度的增加，Seq scan顺序查询的性能随着并行度的增加而提升，其中在Agg场景下表现最佳，并行度16的情况下，查询性能相比串行快了12~13倍。

• Index Scan

  

  开启并行后，在合适的场景下，Index Scan查询性能随着并行度的增加而提升，其中在Agg场景下表现最佳, 并行度16的情况下，并行比串行快了11-15倍。

• Index Only Scan

  

  开启并行后，在合适的场景下，Index Only Scan查询性能随着并行度的增加而提升，其中在Agg场景下表现最佳, 并行度16的情况下，并行比串行快了5-13倍；且ustore的Index Only Scan算子在串行与并行场景下均优于astore。

• Bitmap Scan

  位图读取针对随机读，且数据量较大的场景会有较好的表现，并行度16的情况下，BitmapScan算子性能有70%-100%的性能提升，但端到端性能提升不明显，尤其在数据量较小的情况下。

特性约束

• cursor（游标）不支持并行执行。
• 存储过程和函数内的查询不支持并行执行。
• 不支持子查询subplan和initplan的并行，以及包含子查询的算子的并行。
• 查询语句中带有median操作的查询不支持并行执行。
• 带全局临时表的查询不支持并行执行。

使用指导

使用限制

想要利用SMP提升查询性能需要考虑以下条件：

• 资源对SMP性能的影响

  系统的CPU、内存、I/O和网络带宽等资源需要充足。SMP架构是一种利用富余资源来换取时间的方案，计划并行之后必定会引起资源消耗的增加，当上述资源成为瓶颈的情况下，SMP无法提升性能，反而可能导致性能的劣化。在出现资源瓶颈的情况下，建议关闭SMP。

• 其他因素对SMP性能的影响

  当数据中存在严重数据倾斜时，并行效果较差。例如某表join列上某个值的数据量远大于其他值，开启并行后，根据join列的值对该表数据做hash重分布，使得某个并行线程的数据量远多于其他线程，造成长尾问题，导致并行后效果差。

  SMP特性会增加资源的使用，而在高并发场景下资源剩余较少。所以，如果在高并发场景下，开启SMP并行，尤其需要处理的数据量较小时，会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象，无论是CPU、I/O、内存，都会导致整体性能的下降。因此在高并发场景下，开启SMP往往不能达到性能提升的效果，甚至可能引起性能劣化。

配置步骤

1. 观察当前系统负载情况，如果系统资源充足（资源利用率小于50%），执行步骤2；否则退出。

2. 配置：通过set query_dop = ${thread_num};开启，默认为1。

3. 执行查询语句后关闭query_dop，如下图所示。

   

   在这个计划中，实现了Seq Scan算子的并行，并新增了Local Gather数据交换算子。其中Local Gather算子标有的“dop: 1/2”表明该算子的发送端线程的并行度为2 ，而接受端线程的并行度为1 ，即下层的Seq Scan算子按照2并行度执行，Streaming算子实现了实例内并行线程的数据汇总。

   资源许可的情况下，并行度越高，性能提升效果越好。并不是并行度越高越好，多到一定程度后性能提升可能不明显。

相关页面

In-place Update存储引擎Ustore、query_dop