系统与数据库2019arxiv.org
One SQL to Rule Them All：流与表的管理
One SQL to Rule Them All: Management of Streams and Tables
进阶 · 约 55 分钟读完前置知识：关系代数与 SQL、流处理基础、事件时间与 watermark
导读
论文提出用统一 SQL 来管理流（streams）和表（tables），核心是把二者统一为“随时间变化的关系”（time-varying relations），在 SQL 语义上支持持续变化的数据，并用 watermark 区分事件时间与处理时间、控制结果物化时机。作者来自 Apache Beam/Flink/Calcite 等项目，主张现有 SQL 操作符可继续用于流式场景。
HN 关注点：流处理与数据库/SQL 的统一，以及 SQL 是否真能胜任流式查询；讨论集中在概念新意、表达复杂度和与已有实践/CEP 的关系。
后来怎么样
论文提出的流表统一与时间语义被 Apache Calcite、Flink 等流式 SQL 实现吸收，成为后续流式 SQL 设计的重要参考。
HN 评论精选
这几条评论里：质疑 3 亲历 1
质疑肯定统一流表与时间语义的推进，但质疑 SQL 表达复杂性和跨场景可迁移性。
一个非常有趣的提案：统一流处理和关系查询，并扩展 SQL 使其具有随时间变化关系的语义。作者（来自 Apache Beam/Flink/Calcite 项目）特别强调需要：用单一的随时间变化关系概念来模糊流与表的边界；明确事件时间与处理时间的区别，用单调 watermark 连接两者；控制这些持续变化关系何时物化，避免不必要的工作并只产生及时结果。这些想法本身并不新，但在这里被推进并结合得很好。不过，我怀疑 SQL 是否是合适的工具。例如 Listing 2 与用平实英语表达的查询相比显得复杂。尤其我不同意“任何在非流式场景中懂足够 SQL 解决问题的人，也具备在流式场景中解决问题的知识”。对流处理、Spark、Flink、Beam、Kafka Stream 感兴趣的人必读。
dwenzek查看英文原文
A really interesting proposal to unify stream processing and relational querying and to extend SQL with a semantics over time-varying relations. In particular, the authors (from the Apache Beam/Flink/Calcite projects) stress on the need to: * smooth the frontier between streams and tables by using a single concept of time-varying relations; * make explicit the difference between the event and processing times, using monotonic watermarks to tie the two; * control when these continuously varying relations are materialized, avoiding unnecessary work and producing only timely outcomes. These ideas are not new per se, but there are here pushed further and nicely combined. However, I'm wondering if SQL is the right tool for the task. For instance, the listing 2 seems complex when compared to the query expressed in plain English. In particular, I disagree that "anyone who understands enough SQL to solve a problem in a non-streaming context still has the knowledge required to solve the problem in a streaming context as well. A must read paper by who is keen on stream processing, Spark, Flink, Beam, Kafka Stream ...
质疑质疑“time-varying relation”概念多余，且未说明与 EPL/CEP 的关系。
> 随时间变化的关系就是字面意思：一个随时间变化的关系……关键是，现有全套 SQL 操作符对随时间变化的关系仍然有效。任何关系按定义本来就应随时间变化。那为什么需要引入一种特殊的关系？作者本质上确认了经典关系与“随时间变化”关系没有区别。另外，不清楚它与 CEP 中同样基于 SQL 的 EPL 有何关系。
d__k查看英文原文
> A time-varying relation is just what it says: a relation that changes over time ... Critically, the full suite of existing SQL operators remain valid on time-varying relations Any relation by definition is supposed to change in time. So why do we need to introduce a special kind of relations? The authors essentially confirm that there is no difference between classical relations and "time-varying" relations. Also, it is not clear how does it relate to EPL (in CEP) which is also based on SQL.
亲历亲历：用 PostgreSQL 扩展栈实现类似流/表管理，认为 SQL 被低估。
好文章。SQL 是最被低估的语言。我现在就在项目里用 PipelineDB 扩展做论文提到的大部分事情。PostgreSQL 11 + CitusDB 扩展（水平扩展和分片）+ cstore_fdw 扩展（列式存储）+ file_fdw（把文件当表）+ PipelineDB 扩展（流计算和物化视图）+ TimescaleDB 扩展（时序数据存储）。另外 PG 12 发布会有很多表分区、查询规划和并行执行的优化。
truth_seeker查看英文原文
Great write-up. SQL is the most underrated language. I am doing most of the stuff mentioned in that paper right now in my project with PipelineDB extension. PostgreSQL 11 + CitusDB extension (horizontal scaling and sharding) + cstore_fdw extnesion (columnar data storage) + file_fdw (to treat file as table) + PipelineDB extension (Streaming computations and MV) + TimescaleDB extension (timeseries data storage) Also, PG 12 release will have many optimizations for table partitioning, query planning and its parallel execution
质疑质疑论文主张是否只是已有实践。
这篇论文的重点是 SQL 应该用于流式数据管道吗？人们不是已经在这么做了吗？
iblaine查看英文原文
Is the point of this paper that SQL should be used to in streaming data pipelines? Aren’t people doing this already?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖260 分 · 35 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选