版本历史
寻求帮助

关于 YMatrix

立即体验

部署数据库

使用数据库

管理集群

安全配置

最佳实践

技术原理

高级功能

管理手册

SQL 参考

概述

Interconnect（简称IC）是 YMatrix 数据库分布式查询中用于数据节点间数据交换的核心设施, YMatrix 支持三种 IC 类型.

类型

  • 传统 IC 类型包括：
    • ic-tcp ：基于 TCP 协议实现
    • ic-udpifc ：基于 UDP 协议实现，提供类似 TCP 的可靠性
  • 全新IC类型：
    • ic-tunnel ：YMatrix 6.7.1 版本推出的 IC 实现，旨在克服传统 IC 的局限性，提供更好的环境兼容性和性能表现。

      详细对比

      IC类型 核心特点 适用场景 配置方法 版本支持
      ic-tcp - 基于 TCP 协议，理论性能最好；
      - 存在查询卡死问题；
      - 受限于系统 TCP 端口数量，对大规模集群或大规模并行场景支持较弱。      		 - 网络环境良好、节点数量较少的小规模集群；
      - 需要极致性能的场景。      		 - 设置 GUC gp_interconnect_type=tcp。
      - 通过 gpconfig 进行全局设置。
      - 通过 PGOPTIONS="-c gp_interconnect_type=tcp" psql 在会话中设置，只在当前会话生效。      		 所有版本
      ic-udpifc - 对网络环境要求较高，网络延迟高或 MTU 较小时性能会大幅下降； - OLAP 类查询；
      - 网络延迟低、MTU 较大的环境；
      - 数据量较大的常规场景 ：在数据量较大的情况下可优先使用，不过要注意在数据迁移这类数据传输量极大的场景中，ic-udpifc 的性能会大幅下降      		 - 设置GUC gp_interconnect_type=udpifc。
      - 通过 gpconfig 进行全局设置。
      - 通过 PGOPTIONS="-c gp_interconnect_type=udpifc" psql 在会话中设置，只在当前会话生效。      		 所有版本
      ic-tunnel - 全新设计的 IC 类型，定位于提供最大的环境兼容性
      - 无需手工配置
      - 可自动感知集群拓扑结构，在扩缩容或主从切换时自动适应      		 - 大规模集群，因节点数太多易导致 ic-tcp 等卡死或假死；
      - 数据迁移，ic-udpifc 的性能大幅下降时；
      - 明细查询场景，查询涉及大量字段，导致向量化 motion 性能表现不佳；      		 - 网络环境较差或存在连接流限制的环境。- 设置GUC gp_interconnect_type=tunnel。
      - 通过 gpconfig 进行全局设置。
      - 通过 PGOPTIONS="-c gp_interconnect_type=tunnel" psql 在会话中设置，只在当前会话生效。      		 6.7.1 及以上版本

注意！
ic-tunnel 在大多数场景下都具备良好的性能表现，但若想在下列特定场景中发挥极致性能，仍然可以通过尝试传统的 ic-tcp 或 ic-udpifc。

  • 单机部署环境
  • OLTP 点查场景

ic-tunnel 使用

控制参数

ic-tunnel 支持以下相关的 GUC：

  • mx_interconnect_compress 用来控制是否启用数据压缩。
    • 当设置为 on 时会启用 ic-tunnel 中的数据压缩，这可以显著减少节点间传输的网络数据量，但会增加 QE 进程的 CPU 使用量。适合用于数据迁移等海量数据传输场景， 或者是网络带宽较小的环境。
  • matrix.ic_tunnel_port_delta 用来控制 ic-tunnel 的监听端口，默认为 200。
    • 一个 postmaster 的监听端口加上此值即得到 ic-tunnel 的监听端口。 用户必须自行确保通过它计算出的 ic-tunnel 监听端口未被占用。

      原理说明

      server 进程

      ic-tunnel 采用了代理模型，在每个 segment postmaster 上存在一个 ic-tunnel server 进程，所有的 QE 间的网络通信都是由 server 进程进行中转，而每两个 segment 之间只需要一条长期存在的 tcp 连接。 可以在 shell 中使用 ps 命令列出 ic-tunnel server 进程:

      $ ps -ef | grep ic-tunnel
u        2769149 2769130  0 03:33 ?        00:00:03 postgres:  4004, ic-tunnel server
u        2769150 2769129  0 03:33 ?        00:00:03 postgres:  4003, ic-tunnel server
u        2769164 2769128  0 03:33 ?        00:00:03 postgres:  4002, ic-tunnel server
u        2769195 2769170  0 03:33 ?        00:00:02 postgres:  4000, ic-tunnel server

      当 hot_standby 为真时， hot standby 功能被启用。 这时 standby 与 mirror 节点上也会出现 ic-tunnel server 进程。

监听端口

每一个 ic-tunnel server 进程需要一个 tcp 监听端口，同一台机器上不同的 server 进程的监听端口必须是不同的。server 端口是通过如下方法决定的:

ic-tunnel-server-port := postmaster-port + delta

每个 postmaster 的监听端口加上一个预先指定的常量后即可得到 ic-tunnel server 的监听端口，不需要用户进行额外的手工配置，但用户必须确保以此计算得到的端口是唯一的且未被占用的。 这个常量通过 GUC matrix.ic_tunnel_port_delta 来控制, 可以是正整数或负整数, 默认为 200。

动态加载

ic-tunnel 采用了全新的热插拔机制，基于 YMatrix 数据库中全新引入的 IC 插件机制。 ic-tunnel 由 matrixts.so 提供, 为此:

  • 为了使用 ic-tunnel, GUC shared_preload_libraries 中必须包含 matrixts，但是并不需要创建 matrixts 扩展;

注意！
如果 gp_interconnect_type 已经指定成 tunnel, 而 shared_preload_libraries 中未包含 matrixts, 集群仍然可以正常启动, 会话也可正常建立, 因为 IC 插件会自动回退成采用 ic-tcp, 并且在数据库日志中留下类似 WARNING: ic: unknown interconnect type "tunnel", fallback to "tcp" temporarily 的消息, 这是为了保证在错误配置的情况下集群仍然可以使用, 但管理员应该尽快对配置进行修正.

下一篇 →
版本历史