能力说明

Domino 流计算引擎是从 YMatrix 6.0 版本推出的流计算功能模块，通过增量的维护计算结果，从而实现数据分析及查询的效率提升。

快速开始

当前数据库版本中默认为 Domino v1 。若需使用 Domino v2 可通过以下过程配置。

Domino v2 在 YMatrix 6.3.X 版本中以实验性组件出现，需要额外创建插件和设置 GUC。

-- 6.3版本需要手动开启domino v2支持，重启生效
gpconfig -c domino.enabled -v on
gpstop -ar

-- 创建插件
CREATE EXTENSION domino;

-- 1. 在会话级别设置创建流的版本，该会话创建的流即v2
SET mx_stream_default_version TO 2;

-- 确认版本
SELECT version FROM mx_stream WHERE streamrelid = 'your_stream_name'::regclass::oid;

-- 2. 也可以全局打开
gpconfig -c mx_stream_default_version -v 2
gpstop -u

更多 GUC 使用可参考技术参数。

架构与核心模块

Domino 总体架构分为 执行框架 和 计算引擎 两部分。

执行框架负责流的调度和元数据管理
计算引擎负责解码、查询改写和执行

主要差异

Domino v2 的核心目标是在保证查询延迟不变的情况下，支持更多流计算任务，解决 v1 版本在流数量增加时资源争抢、负载过高的问题。
核心差异主要体现在资源管理和执行方式上，v2 通过优化设计实现更高的流支持能力与稳定性：

资源管理

1.共享解码工具（Decoder）

v1 中每个流单独解码，流越多解码的工作量越大。
v2 中每个数据库共用一个解码器，解码结果存到 TLog 文件，解码工作量只和数据变更量有关，不会因流数量增加而变多。

2.共享工作进程（Worker）

v1 每个流会占用固定的工作进程，流越多占用的进程越多。
v2 通过设置全局工作进程数量，所有流轮流使用这些进程，控制总资源消耗，避免因流多而资源争抢。

3.小步执行：

v1 一次处理较大范围（从上次结束位置至最新位置）的 XLog，可能导致日志堆积。
v2 增加 Ticker 模块，用 Ticker 控制每次只处理小范围（默认每次向前扫描一个 Tick，比如多少 MB 或时间）的XLog，推进更快，减少堆积。

4.功能方面：功能上两者无显著差异。

5.兼容性：v1 和v2 可同时存在，但如果数据库降级，V2的流会不可用，V1不受影响。

执行方式

Domino v2 重点优化了执行框架，核心模块如下：

1.Ticker
用于切分 XLog。控制单次流计算的范围（最小为一个Tick），避免流计算产生大事务导致系统变慢；但创建 WITH DATA 流时处理历史数据的大事务不受此限制。

2.Scheduler
负责流的调度。通过复用 Worker 进程，限制总体 CPU 用量，同时提高单个 Worker 的 CPU 使用率。

3.Decoder
用于解析 XLog。生成供流计算消费的 Tuple 和快照（ TLog ）。

4.TLog
存储解码后的变更记录。作为 Decoder 与流计算之间的中间存储，供流计算读取和处理。

能力概述

能力项	支持状态	说明
上游表存储引擎	HEAP / MARS3
上游表分布类型	Hash 分布/随机分布/segment set 模式	不支持 master-only 表和 replicated 表作为上游表
上游表分区	支持
流表存储引擎	HEAP / MARS3 / AO
流表的分布键	支持自由选择分布键，可以和上游表不同	最优解决方案是保持一致。尤其是对于聚集流，相同的分布键可以讲流计算本地化
流表的存储特征	流表可以进行独立的引擎、分区、分布键选择
上游表多字段支持	支持	可支持上游表字段 ≥ 300
一表多流	支持	同级多个数据流的上游表可以是同一个。“一表”指的是同一上游表
扩维计算	支持	支持关联 ≥ 10 的维度表
聚集计算	支持	支持分组字段 ≥32；内部会合并自动多个字段的类型为一个类型，然后产生一个组合类型的字段，进行后续的聚集计算
上游表 DDL 支持	不支持	上游表创建索引，不会对下游流表的发挥作用。上游表删除索引，可能导致下游流无法执行
流表 DDL 支持	不支持	流表上暂不支持字段类的 DDL 变更，如需变更，需要重建流。后续会支持部分DDL功能。注:如果流表的上游表也发生DDL，同样建议进行流的重建
流表索引	支持	流表可以独立进行索引创建和维护
维度过滤	支持	扩维关联计算时，支持进行维表的过滤条件添加
故障转移	支持	segment节点发生主备切换后，流可以继续稳定工作；但有一定概率丢失切换时间点的少量事务
性能损耗	上游表的写入几乎无影响，流表的计算结果秒级以内延迟
大事务能力	支持	内部优化了分批处理机制和以及事务日志解码的内存使用，对于大事务的处理更加稳定。但是相对来说，存在大事务变更的表还是慎用流处理
上游表历史数据处理	支持	创建流的时候，可以通过WITH DATA选项指定处理上游表的历史数据。若上游表的数据量巨大，会产生一个非常大事务，在事务结束前，会阻塞其他流的创建
双流 JOIN	支持	支持非等值连接，上游表之间不同分布键，上游表与流可以是不同分布键

其他说明

1.流表对象不能被 JDBC 元数据获取，需要通过独立的语句进行查询。
2.流对象的创建，只能是管理员用户。
3.定义流的 SELETE 部分需保证不存在重名字段。尤其是聚集流定义使用聚集函数后，最好是给字段起个不同的别名，如select avg(col1) as avg_col1,avg(col2) as avg_col2。也可通过CREATE STREAM 部分进行字段投影。
4.尽量限制直接对流表上的数据进行 DML 操作（GUC mx_stream_internal_modify）。
5.不能在流定义中使用 WITH 子句。
6.聚集流使用限制：

流定义中，FROM STREAMING 只能出现一个。
GROUP BY 分组键必须包含对应流表的所有分布键
不允许不带 GROUP BY 的全局聚集计算
不允许试用 HAVING 子句。或者以嵌套子查询，外层 WHERE 过滤的类 HAVING 功能
聚集表达式，不能再次参与其他表达式计算。如 avg(col1)+1，但支持 avg(col+1) 这种写法。

7.双流 JOIN 使用限制

不能在双流 JOIN 的计算中试用 GROUP BY
目前只能实现两个上游表的等值 INNER JOIN 计算，不能使用双流做 UNION 计算和 LEFT JOIN 计算，以及和其他非流式订阅的表关联计算
不能在双流 JOIN 的计算中使用 DISINTCT、SUM、MAX 等聚集函数
不能再双流 JOIN 的计算中使用窗口函数
不支持 ORDER BY 子句

8.多级流中，中间环节的流不能是聚集流。