69.精读《SQL vs Flux》

1 引言

对时序数据的处理有两种方式，如图所示，右边是 SQL，左边是自定义查询语言，也称为 NoSQL，处于中间地带的称为 SQL-LIKE 语言。

本文通过对比 SQL 阵营的 TimescaleDB 与 NoSQL 阵营的 InfluxDB，试图给出一些对比。

2 概述

TimescaleDB

TimescaleDB 完全接受了 SQL 语法，因此几乎没有什么学习门槛，更通过可视化操作优化了使用方式。

InfluxDB

InfluxDB 创造了一种新的查询语言，这里是 Flux 文法.（了解更多文法相关知识，可以移步 精读《手写 SQL 编译器 - 文法介绍》）

InfluxDB 为什么创造 Flux 语法

InfluxDB 之所以创造 Flux 语法，而不使用 SQL，主要有两个原因：

1. 更强的查询功能：SQL 无法轻松完成时序查询。

2. 时间序列的查询需要基于流的函数模型，而不是 SQL 的代数模型。

所谓流模型，就类似 JS 函数式编程中类似概念：

更强的查询功能？

InfluxDB 拿下面例子举例：

Flux:

SQL:

虽然看上去 SQL 写法比 Flux 长了不少，但其实 Flux 代码的核心在于实现了自定义函数 exponentialMovingAverage，而 PostgreSQL 也有 创建函数 的能力。

通过 SQL 定义一个自定义函数：

之后可以像 Flux 函数一样的调用：

可见从函数定义上也和 Flux 打成平手，作者认为既然功能相同，而基于 SQL 的语言学习成本更低，所以不需要创造一个新的语言。

关于语法糖与 SQL 标准

作者认为，虽然有观点认为，Flux 的语法糖比 SQL 更简洁，但代码的可维护性并不是行数越少越好，而是是否容易被人类理解。

对于创造一个函数标准可能破坏 SQL 的可移植性，作者认为那也比完全创造一个新语法要强。

基于流的函数模型强于 SQL 代数模型？

诚然，从功能角度来看，当然函数模型强于代数模型，因为代数模型只是在描述事物，而不能精准控制执行的每一步。

但我们要弄清楚 SQL 的场景，是通过描述一个无顺序的查询问题，让数据库给出结果。而在查询过程中，数据库可以对 SQL 语句作出一些优化。

反观函数模型，是在用业务代码描述查询请求，这种代码是无法被自动优化的，虽然为用户提供了更底层的控制，但其代价是无法被数据库执行引擎所优化。

如果你更看中查询语言，而不是具体执行逻辑，SQLl 依然是最好的选择。

3 总结

之所以制作这一期精读，是为了探索 SQL 与其他查询语言的关系，去理解为什么 SQL 沿用至今。

SQL 与其他函数类查询语言不在一个层面上，如果用语法糖、可操纵性抨击 SQL，只能得出看似正确，实则荒谬的结论。

SQL 是一个查询语言，与普通编程语言相比，它还在上层，最终会转化为关系代数执行，但关系代数会遵循一些等价的转换规律，比如交换律、结合律、过滤条件拆分等等，通过预估每一步的时间开销，将 SQL 执行顺序重新组合，可以提高执行效率。

如果有多个 SQL 同时执行，还可以整合成一个或多个新的 SQL，合并重复的查询请求。

在数据驱动商业的今天，SQL 依然是数据查询最通用的解决方案。

4 更多讨论

讨论地址是：精读《SQL vs Flux》 · Issue #96 · dt-fe/weekly

如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。

以下是我个人微信，欢迎交流！

还没关注本公众号好的朋友们，可以扫码关注哈

平时工作繁忙，写文实在不易，欢迎大家转发推荐，大家的支持是我不断继续写下去的动力，感谢！