GreenPlum数据分布机制

简介: GreenPlum数据分布机制

一、介绍


GreenPlumCoodinator/Segment架构,集群通常由一个Coodinator节点和一个standby coodinator节点以及多个segment节点组成,其中数据放置在segment节点上。Coodinator是整个数据库的入口,客户端只会连接到Coodinator上并执行相关查询操作,Standby节点为Coordinator提供高可用支持,Mirrorprimary的备。

 


数据默认使用hash分布。

二、插入时数据是如何分布分发到哪个segment?

1、插入操作时值的由来


我们看下insert语句的执行计划:

 

它没有Motion节点,仅1slice,即root sliceResult节点是将insert的值物化以构建TupleTableSlot进行插入。也就是先物化然后insert

这里主要关注物化的值从哪来。Result节点的执行堆栈为:

    ExecutorRun->standard_ExecutorRun->ExecutePlan->
    ExecProcNode->ExecProcNodeFirst->ExecProcNodeGPDB->
    ExecResult->
      ExecProject->ExecEvalExprSwitchContext->ExecInterpExprStillvalid
      ->ExecInterpExpr
    

    ExecInterpExpr计算物化值步骤:EEOP_CONST;EEOP_ASSIGN_TMP。也就是得到个常量值放到resultslot中。

    通过gdb跟踪每个segment进程,可以了解到这里的常量值就是INSERT语句中VALUES的值。

    此时就可以了解到,SQL语句中VALUES值是直接发送到对于的segment的。

    那么,具体是如何发送的呢?


    2、值的发送


    发送函数由cdbdisp_dispatchX完成。我们来跟踪这个函数,看下是如何分发到指定的segment的。

    了解GP原理的话,我们知道发送前需要先在mastersegment之间建立一个连接,然后将执行计划通过这个连接发送过去。建立连接就是创建Gang,由函数AssignGangs完成。

      AssignGangs
        AssignWriterGangFirst(ds, sliceTable, rootIdx);
          slice->primaryGang = AllocateGang(ds, slice->gangType, slice->segments);
            newGang = cdbgang_createGang(segments, segmentType);
              cdbgang_createGang_async

      最终创建Gang建立连接会调用函数cdbgang_createGang_async。下面我们看下这个函数是如何建立连接的。

      堆栈:

        size = list_length(segments);
        newGangDefinition = buildGangDefinition(segments, segmentType);
        segdbDesc = newGangDefinition->db_descriptors[i];
        ret = build_gpqeid_param(gpqeid, sizeof(gpqeid),
                   segdbDesc->isWriter,
                   segdbDesc->identifier,
                   segdbDesc->segment_database_info->hostSegs,
                   totalSegs * 2);
        cdbconn_doConnectStart(segdbDesc, gpqeid, options, diff_options);//建立连接

        cdbconn_doConnectStart连接时,SegmentDatabaseDescriptor segdbDesc中的segment_database_info::GpSegConfigEntry存有segment的端口及IP等信息,即gp_segment_configuration系统表中内容。基于此信息,可以建立连接。

        那么segdbDesc内容从何而来?

        从上述堆栈,segdbDescGang中的db_descriptors[i],也就是buildGangDefinition函数生成:

          buildGangDefinition(List *segments, SegmentType segmentType)
            foreach_with_count (lc, segments , i){
              contentId = lfirst_int(lc);
              newGangDefinition->db_descriptors[i] =
                cdbcomponent_allocateIdleQE(contentId, segmentType);
            }

          SliceTable.slices[0].segments为入参segments链表,存储着执行该slice的所有segmentcontent idsegdbDesc是根据content id从系统表gp_segment_config来获取。

          到这里可以知道,通过SliceTable中的segment链表得到该slicesegmentcontentInsert仅一个sliceinsert分发到执行该insertsegmentcontent就是该segmentcontent id。通过该content idgp_segment_configuration系统表中得到相关portIP等信息,从而据此在mastersegment之间建立连接。构建链接后,insert语句通过此链接发送到对应的segment


          那么content id又是如何与分布键联系起来呢?


          经过分析,由函数DirectDispatchUpdateContentIdsForInsert来完成映射:


          constvalue为分布键的key值,然后通过cdbhash函数通过系统hash函数将key值进行hash,最终得到hashcode,该值即为content id,放到contentIds链表中。


          三、基础知识

          1、gp_segment_configuration


          dbid

          唯一标识segmentMaster1,然后primary节点按照content递增;接着是mirror按照content递增;最后是standby master

          content

          数据库节点的标识IDsegmentprimarymirror相同。Master节点为-1,数据节点:0-N

          role

          节点当前的角色,primary或者mirrorp:表示primarym:表示mirror

          preferred_role

          节点被定义的角色,primary或者mirror

          mode

          主备同步状态。s:表示已同步;n:表示不同步

          Master总是nstandby master segment总是s,但并不表示他们之间的同步状态,使用gp_stat_replication来看他们之间是否同步

          status

          u:表示正常,d:表示节点失败

          port

          子节点的端口

          hostname

          子节点所在机器的hostname

          address

          子节点所在机器的IP

          datadir

          实例的data目录

          2、Gang、slice与QueryDesc之间关系

          目录
          相关文章
          |
          7月前
          |
          SQL 弹性计算 分布式计算
          TiDB计算层详解:分布式计算框架与查询优化机制
          【2月更文挑战第26天】本文将深入剖析TiDB的计算层,详细解析其分布式计算框架和查询优化机制。通过了解计算层的核心组件和工作原理,我们可以更好地理解TiDB如何高效处理SQL查询和计算任务。本文将从计算层的架构、任务分发、查询优化等方面展开介绍,帮助读者全面掌握TiDB计算层的关键技术和优势。
          |
          4月前
          |
          存储 运维 数据库
          ADBPG&Greenplum成本优化问题之优化Greenplum的性能和磁盘使用如何解决
          ADBPG&Greenplum成本优化问题之优化Greenplum的性能和磁盘使用如何解决
          42 1
          |
          4月前
          |
          存储 SQL 分布式计算
          ADBPG&Greenplum成本优化问题之冷热数据分层存储的定义如何解决
          ADBPG&Greenplum成本优化问题之冷热数据分层存储的定义如何解决
          46 1
          |
          4月前
          |
          SQL 存储 算法
          ADBPG&Greenplum成本优化问题之ADB PG中平衡数据压缩与访问性能如何解决
          ADBPG&Greenplum成本优化问题之ADB PG中平衡数据压缩与访问性能如何解决
          43 0
          |
          SQL 存储 druid
          分布式数据库Greenplum基本原理和使用
          Greenplum主要由Master节点、Segment节点、interconnect三大部分组成。Master 系统的入口,接受客户端连接及提交的SQL语句,将工作负载分发给其它数据库实例(segment实例),不存放任何用户数据,只是对客户端进行访问控制和存储表分布逻辑的元数据Segment节点负责数据的存储,可以对分布键进行优化以充分利用Segment节点的io性能来扩展整集群的io性能
          分布式数据库Greenplum基本原理和使用
          |
          存储 Cloud Native 关系型数据库
          最佳实践—如何分析数据分布不均衡
          本文将介绍如何分析和处理数据倾斜的问题。
          122 0
          最佳实践—如何分析数据分布不均衡
          |
          SQL 存储 NoSQL
          分布式 PostgreSQL 集群(Citus),分布式表中的分布列选择最佳实践
          分布式 PostgreSQL 集群(Citus),分布式表中的分布列选择最佳实践
          629 0
          分布式 PostgreSQL 集群(Citus),分布式表中的分布列选择最佳实践
          |
          SQL 存储 缓存
          CockroachDB之本地以及分布式查询处理
          译者注:本文详细介绍了CockroachDB的两种查询处理方式:本地及分布式,其中详细描述了设计分布式引擎的目的,为了达到分布式,还存在哪些遗留问题。以下为译文。 当CockroachDB节点接收到查询SQL时,大概会发生什么事情呢: pgwire模块负责与客户端应用通信,从客户端接收查询请求。将SQL文本分析并转换为抽象语法树(Abstract Syntax Tree,简称AST)。然后进一步分析并将其转换为逻辑查询计划,该计划是关系运算符的树,如过滤器,渲染(项目),连接。 顺便说一下,逻辑计划树是由EXPLAIN语句报告的数据。 然后将逻辑计划交给负责执行查询的back-end层
          332 0
          |
          关系型数据库 算法 数据库
          Greenplum 数据分布黄金法则 - 论分布列与分区的选择
          背景 阿里云ApsaraDB for Greenplum公测以来,已经收到好多用户的公测申请。 要使用Greenplum,登陆到数据库后第一件事当然是建表,然后倒入数据开测。 大部分用户以前是使用MySQL的,并没有接触过Greenplum,语法需要适应一下。 例如MySQL中的
          13897 0

          相关实验场景

          更多
          下一篇
          DataWorks