Snova架构篇（二）：Greenplum核心组件

本节主要从GP核心组件入手，进一步认识gp分布式数据库的基本框架；

目录：

1. 解析器
2. 查询优化器
3. 调度器
4. 执行器
5. interconnect
6. 系统表
7. 分布式事务

1.解析器

• 词法语法分析和并生成解析树

当PostgreSQL的后台进程Postgres接收到查询语句后，首先将其传递给查询分析模块，进行词法、语法和语义分析。若是功能性命令（例如建表、创建用户、备份等）则将其分配到功能性命令处理模块；对于查询命（SELECT/INSERT/DELETE/UPDATE）则要为其构建查询树（Query结构体），然后交给查询重写模块。

2.查询优化器

• 查询优化器的解耦需要建立一个沟通机制与数据库系统通信来处理查询。Orca体系包括一个框架，用于数据库系统和优化器之间的数据交换，这个框架叫做Data eXchange Language （DXL）。
• 模块化
• 可扩展性
• 多核心支持

３.调度器

• 分配查询需求所需要的资源
• 发送查询计划到segment hosts

4.执行器

• 对于Executor模块，它根据输入的查询计划树按部就班地处理数据表中元组的增删改查(DML)操作，它的执行逻辑是统一的(所有的增删改查最后都归结为SELECT，只是分别在SELECT的基础上进行一些额外的操作)。其主要代码放在src/backend/executor下。

5.interconnect

• Interconect是Greenplum数据库架构中的网络层。
• Interconnect指的是Segment之间的进程间通信以及这种通信所依赖的网络基础设施。Greenplum的Interconnect采用了一种标准的以太交换网络。出于性能原因，推荐使用万兆网或者更快的系统。
• 默认情况下，Interconnect使用带流控制的用户数据包协议（UDPIFC）在网络上发送消息。Greenplum软件在UDP之上执行包验证。这意味着其可靠性等效于传输控制协议（TCP）且性能和可扩展性要超过TCP。如果Interconnect被改为TCP，Greenplum数据库会有1000个Segment实例的可扩展性限制。对于Interconnect的默认协议UDPIFC则不存在这种限制。

6.系统表

https://gp-docs-cn.github.io/docs/ref_guide/system_catalogs/catalog_ref-tables.html
//系统表详细介绍

1.数据库内部对象的元数据，如：pg_database、pg_namespace、pg_class、pg_attribute、pg_type、pg_exttable等。

这类系统表既涵盖了全局的对象定义，也涵盖了每个数据库内的各种对象定义。这类系统表的元数据不是分布式的存储，而是每一个数据库实例（不论是master实例还是segment实例）中都各有一份完整的元数据。但也有例外，如：gp_distribution_policy（分布键定义）表则只在master上才有元数据。

对于这类系统表，各个实例之间元数据保持一致十分重要。

2. 维护Greenplum集群状态的元数据，如：gp_segment_configuration、gp_configuration_history、pg_stat_replication等。

这类系统表主要由master实例负责维护，就如segment实例状态管理的两张表gp_segment_configuration和gp_configuration_history的数据是由master的专用进程fts负责维护的。

3. Persistent table，如：gp_persistent_database_node、gp_persistent_filespace_node、gp_persistent_relation_node、gp_persistent_tablespace_node。

这类系统表同样是存在于每一个数据库实例中。在每个实例内，persistenttable与pg_class/pg_relation_node/pg_database等系统表有着严格的主外键关系。这类系统表也是primary实例与mirror实例之间实现同步的重要参考数据。

7.分布式事务

Greenplum 使用两阶段提交（2PC）协议实现分布式事务。2PC 是数据库经典算法， 分布式事务的实现细节：

• 分布式事务快照：实现 master和不同segment间一致性
• 共享本地快照：实现 segment 内不同 QEs 间的一致性

事务快照

共享本地快照

• Greenplum 使用分布式快照和本地映射实现跨节点的数据一致性。Greenplum QD 进程承担分布式事务管理器的角色，在QD开始一个新的事务（StartTransaction）时，它会创建一个新的分布式事务id、设置时间戳及相应的状态信息；
• 执行查询时，QD 将分布式事务和快照等信息序列化，通过libpq协议发送给 QE。QE 反序列化后，获得 QD 的分布式事务和快照信息。这些信息被用于确定元组的可见性（HeapTupleSatisfiesMVCC）。所有参与查询的 QEs 都使用QD 发送的同一份分布式事务和快照信息判断元组的可见性，因而保证了整个集群数据的一致性，避免前面例子中出现的不一致现象。

未完待续；