关于postgresql:PostgreSQL-技术内幕五GreenplumInterconnect模块

Greenplum是在开源PostgreSQL的根底上，采纳MPP架构的关系型分布式数据库。Greenplum被业界认为是最快最具性价比的数据库，具备弱小的大规模数据分析工作解决能力。
Greenplum采纳Shared-Nothing架构，整个集群由多个数据节点（Segment sever）和管制节点（Master Server）组成，其中的每个数据节点上能够运行多个数据库。
简略来说，Shared-Nothing是一个分布式的架构，每个节点绝对独立。在典型的Shared-Nothing中，每一个节点上所有的资源（CPU、内存、磁盘）都是独立的，每个节点都只有全副数据的一部分，也只能应用本节点的资源。
因为采纳分布式架构，Greenplum 可能将查问并行化，以充分发挥集群的劣势。Segment外部依照规定将数据组织在一起，有助于进步数据查问性能，利于数据仓库的保护工作。
如下图所示，Greenplum数据库是由Master Server、Segment Server和Interconnect三局部组成，Master Server和Segment Server的互联通过Interconnect实现。

图1：Greenplum数据库架构示意
同时，为了最大限度地实现并行化解决，当节点间须要挪动数据时，查问打算将被宰割，而不同Segment间的数据挪动就由Interconnect模块来执行。
在上次的直播中，咱们为大家介绍了Greenplum-Interconnect模块技术个性和实现流程剖析，以下内容依据直播文字整顿而成。
Interconnect概要介绍
Interconnect是Greenplum数据库中负责不同节点进行外部数据传输的组件。Greenplum数据库有一种特有的执行算子Motion，负责查询处理在执行器节点之间替换数据，底层网络通信协定通过Interconnect实现。
Greenplum数据库架构中有一些重要的概念，包含查问调度器（Query Dispatcher，简称QD）、查问执行器（Query Executor，简称QE）、执行算子Motion等。

图2：Master-Segment查问执行调度架构示意

QD：是指Master节点上负责解决用户查问申请的过程。

QE：是指Segment上负责执行 QD 散发来的查问工作的过程。

通常，QD和QE之间有两种类型的网络连接：

libpq是基于TCP的控制流协定。QD通过libpq与各个QE间传输管制信息，包含发送查问打算、收集错误信息、解决勾销操作等。libpq是PostgreSQL的标准协议，Greenplum对该协定进行了加强，譬如新增了‘M’音讯类型 (QD 应用该音讯发送查问打算给QE）等。

Interconnect数据流协定：QD和QE、QE和QE之间的表元组数据传输通过Interconnect实现，Greenplum有三种Interconnect实现形式，一种基于TCP协定，一种基于UDP协定，还有一种是Proxy协定。缺省形式为 UDP Interconnect连贯形式。

Motion：PostgreSQL生成的查问打算只能在单节点上执行，Greenplum须要将查问打算并行化，以充分发挥集群的劣势。为此，Greenplum引入Motion算子实现查问打算的并行化。Motion算子实现数据在不同节点间的传输，在Gang之间通过Interconnect进行数据重散布。

同时，Motion为其余算子暗藏了MPP架构和单机的不同，使得其余大多数算子都能够在集群或者单机上执行。每个Motion 算子都有发送方和接管方。

此外，Greenplum还对某些算子进行了分布式优化，譬如汇集。Motion算子对数据的重散布有gather、broadcast和redistribute三种操作，底层传输协定通过Interconnect实现。Interconnect是一个network abstraction layer，负责各节点之间的数据传输。

Greenplum是采纳Shared-Nothing架构来存储数据的，依照某个字段哈希计算后打散到不同Segment节点上。当用到连贯字段之类的操作时，因为这一字段的某一个值可能在不同Segment下面，所以须要在不同节点上对这一字段所有的值从新哈希，而后Segment间通过UDP的形式把这些数据相互发送到对应地位，汇集到各自哈希出的Segment下来造成一个长期的数据块以便后续的聚合操作。

Slice：为了在查问执行期间实现最大的并行度，Greenplum将查问打算的工作划分为slices。Slice是打算中能够独立进行解决的局部。查问打算会为motion生成slice，motion的每一侧都有一个slice。正是因为motion算子将查问打算宰割为一个个slice，上一层slice对应的过程会读取下一层各个slice过程播送或重散布操作，而后进行计算。

Gang：属于同一个slice然而运行在不同的segment上的过程，称为Gang。如上图2所示，图中有两个QE节点，一个QD节点，QD节点被划分为三个slice。依照雷同的slice在不同QE下面运行称一个组件的Gang，所以上图共有三个Gang。

Interconnect初始化流程
在做好根底筹备工作之后，会有一系列处理函数，将某个节点或所有节点的数据收集上来。在数据传输的过程中，会有buffer治理的机制，在肯定的机会，将buffer内的数据刷出，这种机制能够无效地升高存储和网络的开销。以下是初始化一些重要的数据结构阐明。

Interconnect初始化外围构造

Go
typedef enum GpVars_Interconnect_Type
{
Interconnect_TYPE_TCP = 0,
Interconnect_TYPE_UDPIFC,
Interconnect_TYPE_PROXY,
} GpVars_Interconnect_Type;

typedef struct ChunkTransportState 
{ 
/* array of per-motion-node chunk transport state */ 
int size;//来自宏定义CTS_INITIAL_SIZE 
ChunkTransportStateEntry *states;//上一个成员变量定义的size个数 
ChunkTransportStateEntry 
/* keeps track of if we've "activated" connections via SetupInterconnect(). 
*/ 
bool activated; 
bool aggressiveRetry; 
/* whether we've logged when network timeout happens */ 
bool networkTimeoutIsLogged;//缺省false，在ic_udp中才用到 
bool teardownActive; 
List *incompleteConns; 
/* slice table stuff. */ 
struct SliceTable *sliceTable; 
int sliceId;//以后执行slice的索引号 
/* Estate pointer for this statement */ 
struct EState *estate; 
/* Function pointers to our send/receive functions */ 
bool (*SendChunk)(struct ChunkTransportState *transportStates, 
ChunkTransportStateEntry *pEntry, MotionConn *conn, TupleChunkListItem tcItem, 
int16 motionId); 
TupleChunkListItem (*RecvTupleChunkFrom)(struct ChunkTransportState 
*transportStates, int16 motNodeID, int16 srcRoute); 
TupleChunkListItem (*RecvTupleChunkFromAny)(struct ChunkTransportState 
*transportStates, int16 motNodeID, int16 *srcRoute); 
void (*doSendStopMessage)(struct ChunkTransportState *transportStates, int16 
motNodeID); 
void (*SendEos)(struct ChunkTransportState *transportStates, int motNodeID, 
TupleChunkListItem tcItem); 
/* ic_proxy backend context */ 
struct ICProxyBackendContext *proxyContext; 
} ChunkTransportState;

Interconnect初始化逻辑接口
初始化的流程会调用setup in Interconnect，而后依据数据类型抉择连贯协定。默认会抉择UDP，用户也能够配置成TCP。在TCP的流程外面，会通过GUC宏来判断走纯TCP协定还是走proxy协定。

Go
void
SetupInterconnect(EState *estate)
{
        Interconnect_handle_t *h;
        h = allocate_Interconnect_handle();

        Assert(InterconnectContext != NULL);
        oldContext = MemoryContextSwitchTo(InterconnectContext);

        if (Gp_Interconnect_type == Interconnect_TYPE_UDPIFC)
                SetupUDPIFCInterconnect(estate);    #here udp初始化流程
        else if (Gp_Interconnect_type == Interconnect_TYPE_TCP ||
                         Gp_Interconnect_type == Interconnect_TYPE_PROXY)
                SetupTCPInterconnect(estate);#here tcp & proxy
        else
                elog(ERROR, "unsupported expected Interconnect type");

        MemoryContextSwitchTo(oldContext);

        h->Interconnect_context = estate->Interconnect_context;
}
SetupUDPIFCInterconnect_Internal初始化一些列相干构造,包含Interconnect_context初始化、以及transportStates->states成员createChunkTransportState的初始化，以及rx_buffer_queue相干成员的初始化。
/* rx_buffer_queue */
//缓冲区相干初始化重要参数
conn->pkt_q_capacity = Gp_Interconnect_queue_depth;
conn->pkt_q_size = 0;
conn->pkt_q_head = 0;
conn->pkt_q_tail = 0;
conn->pkt_q = (uint8 **) palloc0(conn->pkt_q_capacity * sizeof(uint8 *));

/* update the max buffer count of our rx buffer pool.  */
rx_buffer_pool.maxCount += conn->pkt_q_capacity;

3. Interconnect 初始化回调接口
当初始化的时候，接口回调函数都是对立的。当真正初始化执行时，会给上对应的函数撑持。

通过回调来对应处理函数，在PG外面是一种常见形式。比方，对于TCP的流程对应RecvTupleChunkFromTCP。

对于UDP的流程，对应TupleChunkFromUDP。相应函数的尾缀法则与TCP或是UDP对应。

Go
TCP & proxy :
    Interconnect_context->RecvTupleChunkFrom = RecvTupleChunkFromTCP;
        Interconnect_context->RecvTupleChunkFromAny = RecvTupleChunkFromAnyTCP;
        Interconnect_context->SendEos = SendEosTCP;
        Interconnect_context->SendChunk = SendChunkTCP;
        Interconnect_context->doSendStopMessage = doSendStopMessageTCP;

UDP:        
        Interconnect_context->RecvTupleChunkFrom = RecvTupleChunkFromUDPIFC;
        Interconnect_context->RecvTupleChunkFromAny = RecvTupleChunkFromAnyUDPIFC;
        Interconnect_context->SendEos = SendEosUDPIFC;
        Interconnect_context->SendChunk = SendChunkUDPIFC;
        Interconnect_context->doSendStopMessage = doSendStopMessageUDPIFC;

Ic_udp流程剖析
1. Ic_udp流程剖析之缓冲区外围构造

Go
MotionConn：
核心成员变量剖析：
/* send side queue for packets to be sent */
ICBufferList sndQueue;
//buff来自conn->curBuff，间接来自snd_buffer_pool
ICBuffer *curBuff;

//snd_buffer_pool在motionconn初始化的时候，别离获取buffer，放在curBuff

uint8           *pBuff;
//pBuff初始化后指向其curBuff->pkt

/*
依赖aSlice->primaryProcesses获取过程proc构造进行初始化结构，过程id、IP、端口等信息
*/
struct icpkthdr                conn_info;
//全局&ic_control_info.connHtab
        
  struct CdbProcess  *cdbProc;//来自aSlice->primaryProcesses        

uint8                **pkt_q;
/*pkt_q是数组充当环形缓冲区，其中容量求模计算下标操作，Rx线程接管的数据包pkt搁置在conn->pkt_q[pos] = (uint8 *) pkt中。而IcBuffer中的pkt赋值给motioncon中的pBuff，而pBuff又会在调用prepareRxConnForRead时，被赋值pkt_q对应指针指向的数据区,conn->pBuff = conn->pkt_q[conn->pkt_q_head];从而造成数据链路关系。
*/

motion：
        ICBufferList sndQueue、
        ICBuffer *curBuff、
        ICBufferList unackQueue、
        uint8         *pBuff、
        uint8                **pkt_q;
ICBuffer
        pkt
static SendBufferPool snd_buffer_pool;

第一层：snd_buffer_pool在motionconn初始化的时候，别离获取buffer，放在curBuff，并初始化pBuff。
第二层：了解sndQueue逻辑
中转站，buff来自conn->curBuff，间接来自snd_buffer_pool  
第三层：了解data buffer和 pkt_q
启用数据缓冲区：pkt_q是数组充当环形缓冲区，其中容量求模计算下标操作，Rx线程接管的数据包pkt搁置在conn->pkt_q[pos] = (uint8 *) pkt中。
而IcBuffer中的pkt赋值给motioncon中的pBuff，而pBuff又会在调用prepareRxConnForRead时，被赋值pkt_q对应指针指向的数据区， conn->pBuff = conn->pkt_q[conn->pkt_q_head];从而造成数据链路关系。

2. Ic_udp流程剖析之缓冲区流程剖析

Go
Ic_udp流程剖析缓冲区初始化：
SetupUDPIFCInterconnect_Internal调用initSndBufferPool(&snd_buffer_pool)进行初始化。

Ic_udp流程剖析缓冲获取：
调用接口getSndBuffer获取缓冲区buffer，在初始化流程SetupUDPIFCInterconnect_Internal->startOutgoingUDPConnections,为每个con获取一个buffer，并且填充MotionConn中的curBuff
static ICBuffer * getSndBuffer(MotionConn *conn)

Ic_udp流程剖析缓冲开释：
通过调用icBufferListReturn接口，开释buffer进去snd_buffer_pool.freeList
static void
icBufferListReturn(ICBufferList *list, bool inExpirationQueue)    
{
icBufferListAppend(&snd_buffer_pool.freeList, buf);# here 0
}
清理：cleanSndBufferPool(&snd_buffer_pool);下面开释回去后接着清理buff。
handleAckedPacket逻辑对于unackQueue也会登程开释。

Ic_Proxy流程剖析

简要介绍
TCP流程buf设计较为简单，在这里不做具体赘述。Proxy代理服务是基于TCP革新而来，次要用来应答在大规模集群外面网络连接数微小的状况。

Ic_Proxy只须要一个网络连接在每两个网端之间，相比拟于IC-Tcp 模式，它耗费的连贯总量和端口更少。同时，与 IC-Udp模式相比，在高提早网络具备更好的体现。

TCP是一种点对点的有连贯传输协定，一个有N个QE节点的Motion的连接数是N^2，一个有k个Motion的查问将产生k*N^2个连贯。

举例来讲，如果一个蕴含500个Segment的集群，运行一个蕴含10个Motion的查问，那么这个查问就须要建设10*500^2 = 2,500,000个TCP连贯。即便不思考最大连接数限度，建设如此多的TCP连贯也是十分低效的。

Ic_Proxy是用LIBUV开发的，默认状况下禁用IC代理，咱们能够应用./configure –enable-ic-proxy。

装置实现后，咱们还须要设置ic代理网络，它实现了通过设置GUC。例如，如果集群具备一个主节点、一个备用主节点、一个主分段和一个镜像分段，咱们能够像上面这样设置它：

Go
gp_Interconnect_proxy_addresses 
gpconfig --skipvalidation -c gp_Interconnect_proxy_addresses -v "'1:-1:localhost:2000,2:0:localhost:2002,3:0:localhost:2003,4:-1:localhost:2001'"

它蕴含所有主服务器、备用服务器、以及主服务器和镜像服务器的信息段，语法如下：dbid:segid:hostname:port[,dbid:segid:ip:port]。这里要留神，将值指定为单引号字符串很重要，否则将被解析为格局有效的中间体。
2. Ic_proxy逻辑连贯

Go
在 Ic-Tcp 模式下，QE 之间存在 TCP 连贯（包含 QD）,以一个收集动作举例：
┌    ┐
│    │  <=====  [ QE1 ]
│ QD │
│    │  <=====  [ QE2 ]
└    ┘
在 Ic-Udp 模式下，没有 TCP 连贯，但仍有逻辑连贯：如果两个QE互相通信，则存在逻辑连贯：
┌    ┐
│    │  <-----  [ QE1 ]
│ QD │
│    │  <-----  [ QE2 ]
└    ┘
在 Ic_Proxy 模式下，咱们依然应用逻辑连贯的概念：
┌    ┐          ┌       ┐
│    │          │       │  <====>  [ proxy ]  <~~~~>  [ QE1 ]
│ QD │  <~~~~>  │ proxy │
│    │          │       │  <====>  [ proxy ]  <~~~~>  [ QE2 ]
└    ┘          └       ┘
在 N：1 汇合静止中，有 N 个逻辑连贯;
在N：N重新分配/播送静止中存在逻辑连接数N*N

3. Ic_Proxy逻辑连贯标识符
为了辨认逻辑连贯，咱们须要晓得谁是发送者，谁是接收者。在 Ic_Proxy 中，咱们不辨别逻辑的方向连贯，咱们应用名称本地和近程作为端点。起点至多由segindex和PID标识，因而逻辑连贯能够通过以下形式标识：seg1，p1->seg2，p2

然而，这还不足以辨别不同查问中的子打算。咱们还必须将发送方和接管方切片索引放入思考：slice[a->b] seg1，p1->seg2，p2

此外，思考到后端过程可用于不同的查问会话及其生命周期不是严格同步的，咱们还必须将命令 ID 放入标识符中：cmd1,slice[a->b] seg1，p1->seg2，p2

出于调试目标，咱们还将会话ID放在标识符中。在思考镜像或备用时，咱们必须意识到与 SEG1 主节点的连贯和与 SEG1 镜像的连贯不同，所以咱们还须要将 dbid 放入标识符中：cmd1,slice[a->b] seg1,dbid3,p1->seg2,dbid5,p2Ic_Proxy

数据转发流程介绍
数据转发是Ic_Proxy流程最简单的局部，依照不同的流程，会产生三种转发类型：
第一种是Loopback，即循环本地；
第二种是proxy client，通过代理去client；
第三种是proxy to proxy，从一个代理发到另一个代理。
而后，依照上述的三种类型再调用对应的route，把数据转发进来，这样就造成了一个残缺的数据转发流程。

图3：Ic_proxy数据包转发解决流程图

图4：Ic_Proxy流程时序图

明天咱们为大家带来Greenplum-Interconnect模块的解析，心愿可能帮忙大家更好地了解模块的技术个性和实现解决流程。

关于postgresql:PostgreSQL-技术内幕五GreenplumInterconnect模块

评论

发表回复取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

关于postgresql:PostgreSQL-技术内幕五GreenplumInterconnect模块

评论

发表回复 取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

发表回复取消回复