查询转换管道

大多数数据库的工作方式相同：查询到达，引擎构建执行计划，扫描表，连接行，过滤，聚合并返回结果。每次运行查询时，工作都会从头开始重复。这种基于拉取的模型已经为关系数据库提供了数十年的服务，但它带来了固有的成本：读取延迟与查询的复杂性及其涉及的数据大小成正比。 Readyset 采用了一种根本不同的方法。 Readyset 不是根据需要重新执行查询，而是将每个查询编译成数据流图——一个运算符网络（连接、过滤器、聚合、投影），随着底层数据的变化持续维护查询的结果。当在上游数据库中插入、更新或删除行时，更改会通过图形传播，并且缓存的结果会增量更新。读取变成对预先计算的物化视图的查找，而不是完整的查询执行。这是关键的区别：传统引擎优化每次运行时执行查询的方式。 Readyset 在缓存创建时优化一次，然后永久增量地维护结果。代价是查询必须以数据流引擎可以编译的形式表示，并且该形式比 SQL 允许的形式更具限制性。 SQL 是一种声明性语言。相同的逻辑查询可以用许多等效的方式编写：相关子查询、派生表、CTE、LATERAL join、嵌套聚合。传统的优化器将它们视为可互换的表示形式，并选择最佳的执行计划，而不管语法如何。 Readyset 的数据流编译器不是传统的优化器。它将 SQL 转换为流式运算符的有向无环图，其中每个运算符接收来自其输入的更改并向其输出发出更改。这种架构施加了 SQL 语法所没有的结构约束：带有相等谓词的二元连接。数据流图中的每个连接都通过列相等谓词 ( a.id = b.id ) 精确连接两个输入。引擎使用这些等式来维护基于哈希的连接状态。不直接支持范围谓词、基于表达式的连接键或多表 ON 条件。没有关联执行。在传统引擎中，相关子查询每个外部行运行一次 - 嵌套循环模式。数据流图没有“每个外行”的概念。每个操作员都可以从其输入中看到完整的更改流。相关子查询必须重写为数据流可以增量维护的等效联接。优选平面连接结构。数据流引擎支持派生表（FROM 中的子查询），但有一定的成本：派生表编译成无法参数化的完全物化的中间节点。输入数据的每个不同组合都会生成一个存储结果，无论外部查询是否需要它。内联派生表（将其 FROM 项、WHERE 过滤器和投影吸收到外部查询中）消除了这种中间物化，并让引擎直接针对基表构建参数化查找。重写管道在语义安全的情况下积极内联派生表，为内联会改变查询含义的情况保留物化形式。支持的连接类型。该引擎支持 INNER JOIN、LEFT OUTER JOIN 和 CROSS JOIN。不支持 RIGHT JOIN 和 FULL OUTER JOIN，因为它们在流上下文中的增量维护需要跟踪双方不匹配的情况 - 这是一个非常困难的问题。聚合边界。 GROUP BY 和聚合函数（ COUNT 、 SUM 等）编译成有状态运算符来维护运行总计。该引擎要求每个聚合查询至少投影一个聚合派生表达式，并且 GROUP BY 键是显式列引用（而不是位置编号或别名）。这些约束意味着语法上有效的 SQL 查询（PostgreSQL 或 MySQL 会毫无怨言地执行的查询）可能无法由 Readyset 直接编译，或者可能编译成效率较低的数据流图。查询重写管道的存在就是为了弥补这一差距。当用户为查询发出 CREATE CACHE 时，Readyset 通过多遍重写管道运行查询，该管道将任意 SQL 转换为数据流引擎期望的规范形式。该管道分为三个块： 块 目的 示例 A — 规范化 脱糖语法、解析模式、限定列 SELECT * 变为 SELECT t.id、t.name, ... B — 深度重写 去相关子查询、展平派生表、优化 WHERE id IN (SELECT ...) 变为联接 C — 清理 删除冗余子句、参数化文字 当结果可证明是单行时删除 ORDER BY id LIMIT 10 每一次传递都是语义保留：重写的查询对于所有可能的数据返回与原始结果相同的结果。这些通道相互构建 - A 块标准化 S