69.精读《SQL vs Flux》

1引言对时序数据的处理有两种方式,如图所示,右边是SQL,左边是自定义查询语言,也称为NoSQL,处于中间地带的称为SQL-LIKE语言。本文通过对比SQL阵营的TimescaleDB与NoSQL阵营的InfluxDB,试图给出一些对比。2概述TimescaleDBTimescaleDB完全接受了SQL语法,因此几乎没有什么学习门槛,更通过可视化操作优化了使用方式。InfluxDBInfluxDB...

69.精读《SQL vs Flux》
1 引言

640?wx_fmt=png

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

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

2 概述TimescaleDB

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

InfluxDB

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

InfluxDB 为什么创造 Flux 语法

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

  • 更强的查询功能:SQL 无法轻松完成时序查询。

  • 时间序列的查询需要基于流的函数模型,而不是 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

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


    640?wx_fmt=gif

    以下是我个人微信,欢迎交流!

    640?wx_fmt=jpeg

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

    640?wx_fmt=jpeg


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




    源文地址:https://www.guoxiongfei.cn/csdn/7677.html
    0