使用gp_segment_id并行查询Greenplum数据的可行性及相关问题咨询

1. 能否通过多个带gp_segment_id条件的并行查询拉取数据？ #

可以，这是Greenplum生态中非常经典的无重叠并行拉取方案。
Greenplum作为MPP数据库，每一行业务数据会根据分布键的哈希值固定存储在对应segment节点上，gp_segment_id是数据库内置的系统隐藏列，用于标识该行数据所在的segment节点编号。你只需要为每个并行查询的WHERE条件指定不同的gp_segment_id取值，每个查询仅会拉取对应segment节点的本地数据，不会产生跨节点数据交互，拉取效率远高于普通全表查询。

2. 该方案的常见弊端 #

• 适用场景受限：仅支持普通堆表、AO/CO表这类物理存储的业务表，不支持外部表、带数据重分布逻辑的视图、多级分区表的子分区裁剪场景，查询对象不符合要求时gp_segment_id过滤会失效甚至抛出异常。
• 易影响集群整体性能：如果并行查询数等于或超过集群segment总数，会瞬间打满所有segment节点的CPU、IO资源，抢占集群上其他正常业务的计算资源。
• 不适用频繁变更的表：如果拉取过程中表存在分布键更新操作，会触发数据跨segment迁移，容易出现漏读、重复读的问题。
• 扩展性差：集群扩容新增segment节点后，gp_segment_id的取值范围会同步更新，你需要同步调整并行查询的编号覆盖范围，否则会漏拉新增segment上的数据。

3. 是否会引发查询结果一致性问题？ #

正常场景下不会出现一致性问题，仅在特殊操作场景下会出现数据异常：

一致性保证的前提：所有并行查询基于同一个事务快照发起，且拉取过程中目标表无DDL变更、无分布键更新操作。

• 满足上述前提时，所有并行查询拉取的数据没有重叠、没有遗漏，最终合并后的结果和单SQL全表查询的结果完全一致。
• 如果多个并行查询是独立发起的不同事务，且拉取过程中存在数据写入、更新操作，不同事务拿到的快照不一致，可能出现数据重复或者遗漏。
• 如果拉取过程中存在分布键更新操作，数据会在不同segment之间迁移，此时并行查询可能漏读迁移中的行，或者重复读取两个segment上的临时过渡数据。

内容的提问来源于stack exchange，提问作者Alexander Koptyaev