作者:Carlota Soto
当用户想要从 InfluxDB 迁移到 TimescaleDB 时,他们经常会问关于查询语言的问题。为了帮助他们,本文将概述 InfluxDB 和 TimescaleDB/PostgreSQL 的查询语言,并提供一张速查表,指导用户将代码从 InfluxQL 迁移到 SQL。
SQL(结构化查询语言)是一种通用的语言,用于管理和操作关系型数据库。它可以追溯到 20 世纪 70 年代,当时它是由 IBM 首次开发的,并迅速成为各种应用程序的黄金标准。几十年来,SQL 不断完善和扩展,最终在全球范围内被广泛采用。
SQL 的强大之处在于它能够高效可靠地处理复杂的查询、事务和日常数据管理任务。它已成为许多流行的关系型数据库管理系统(RDBMS)的基础语言,例如 PostgreSQL、MySQL 和 Microsoft SQL Server,证明了它在不断发展的数据管理和分析领域中的弹性、灵活性和持久性。
在 PostgreSQL 的特定环境中,SQL 实现以其对 SQL 标准的遵守以及对超出标准 SQL 范围的更高级功能的整合而脱颖而出。这些功能包括复杂的查询、外键、触发器、视图和存储过程等。
InfluxQL 是一种专门为 InfluxDB 打造的查询语言。InfluxQL 具有类似 SQL 的语法,这意味着它的设计类似于 SQL,以便开发人员更容易学习和使用。InfluxQL 是 InfluxDB 1.x 版本中使用的语言。
InfluxQL 的核心优势在于它专门为时间序列数据设计的功能和运算符,包括数据过滤、聚合和转换。该语言还支持持续查询和保留策略,可以实现实时数据处理和高效的时间序列数据管理。
Flux 是一种由 InfluxData 开发的数据脚本和查询语言,旨在处理 InfluxDB 2.x 版本中的查询和数据分析。与 InfluxQL 不同,Flux 被设计为访问各种数据源(包括 SQL 数据库和 CSV 文件),旨在促进跨不同数据集的集成数据分析。
Flux 的语法和操作范式与 InfluxQL 或 SQL 有很大不同。Flux 是一种函数式语言,配备了运算符和函数,用于执行复杂的数据转换和分析操作。它包含各种用于操作时间序列数据、数学运算和处理字符串等任务的函数。
SQL 虽然是一种强大且广泛使用的查询语言,但也存在一些缺点。 时间序列数据提出了独特的挑战,包括大量数据、高吞吐量以及对复杂查询的需求,以分析跨时间间隔的数据。标准 SQL 有时难以满足管理和分析大量时间序列数据集所需的效率和性能。查询可能变得复杂且计算量大,SQL 的严格模式结构也可能在需要灵活性和适应性以应对不断变化的数据结构的情况下带来挑战。
SQL 的设计基于关系型数据库的管理,并非天生适合处理时间序列数据。数据汇总、降采样和保留策略等操作在时间序列数据管理中很常见,但在原生 PostgreSQL 中并没有得到原生支持,尽管 TimescaleDB 缓解了这种情况,因为它添加了许多这些功能。
虽然 InfluxQL 在许多方面与 SQL 相似,但它并不完全匹配 SQL 或其他更高级查询语言的深度和多功能性。InfluxQL 是专门为时间序列数据量身定制的,因此它的范围天生就比较集中和有限。对于想要执行超越基本聚合和过滤的复杂数据操作、转换和分析的用户来说,这种限制可能成为瓶颈。
JOIN 是最明显的例子:虽然 InfluxQL 提供基本的聚合、分组和过滤,但它不支持 JOIN。涉及复杂计算、数据转换或连接多个测量值的查询,在 InfluxQL 中可能很麻烦,或者在某些情况下无法实现。
Flux 的第一个限制是它的学习曲线,这可能是一个巨大的障碍,尤其是对于那些已经习惯了 SQL 或 InfluxQL 的人来说。Flux 引入了新的语法和函数式编程风格,可能需要一段时间才能适应:它的一组复杂功能、运算符和表达式虽然强大,但可能很复杂,而且使用起来有点令人望而生畏。
在功能方面,Flux 作为一种查询语言仍在不断成熟。与 SQL 等成熟的查询语言相比,它是一种比较新的语言,它缺乏老牌语言所带来的丰富的函数库和广泛的社区支持。它还在不断发展,这意味着用户可能会遇到可能会影响现有脚本和应用程序的更改和更新。与 SQL 等更成熟的语言相比,文档、示例和社区知识比较少。
性能也是需要考虑的一个方面。随着 Flux 不断发展,性能、优化技术和资源管理方面的改进仍在进行中。
SQL 在 PostgreSQL 和其他关系型数据库系统中,以其标准化的语法而著称,这种语法经过了几十年的完善。它的稳定性和可预测性是其被广泛应用于各种数据管理应用程序的标志。
InfluxQL 采用类似 SQL 的语法,这种特点对于那些以前使用过 SQL 的人来说,可以提供熟悉感和易用性。它直观、易读,并专注于简化时间序列数据的查询过程。
Flux 与众不同,它体现了函数式编程的原理。这种设计选择赋予 Flux 高级数据处理能力,允许执行更复杂和多样的操作。然而,这也意味着学习曲线更加陡峭,尤其是对于那些不熟悉函数式编程的人来说。
SQL 的优势在于它无处不在。它受到许多关系型数据库系统(包括 PostgreSQL)的支持。它通用的结构和丰富的内置函数使其成为各种数据处理任务的灵活工具。
InfluxQL 专为 InfluxDB 量身定制,并经过精心调整,可以有效地处理时间序列数据。然而,这种专门化也可能成为一种限制,因为它并非设计为对其他类型的数据或数据库具有可扩展性或灵活性。
Flux 以其多功能性取胜。它不仅与 InfluxDB 捆绑在一起,而且还具有可以扩展以用于其他数据源的架构,增强了它在各种数据处理和分析应用程序中的实用性。
SQL 提供了广泛的功能和能力,用于数据检索、操作和分析。在 PostgreSQL 与 TimescaleDB 的结合中,SQL 的数据处理能力得到增强,可以有效地管理、分析和可视化时间序列数据,并具有关系型数据库的可靠性和效率。
InfluxQL 因其查询时间序列数据的效率而闻名。它经过优化,可以处理专门设计用于分析按时间索引的数据点的查询,使其成为实时分析和监控应用程序的首选方案。
Flux 更进一步,提供了增强的功能,可以进行数据转换和分析。它配备了一套丰富的函数和运算符,可以处理复杂的分析、转换,甚至机器学习任务,展现了它在高级数据处理场景中的实力。
SQL,尤其是在 PostgreSQL 中使用 TimescaleDB 等扩展时,提供了可靠性、效率和分析深度的完美结合,并得到了成熟的生态系统和庞大的开发者和用户社区的支持。
InfluxQL 虽然效率很高,但在分析深度方面有时会受到限制。它非常适合标准查询,但对于更复杂的分析任务可能会遇到挑战。
Flux 旨在提供更深入的分析。它的函数式编程基础允许进行复杂的计算、分析和数据操作,使用户能够从数据中提取细致入微的见解。
为了更直观地说明这些信息,让我们来演示一个在指定时间段内查询字段的平均值的示例,分别使用 InfluxQL、Flux 和 SQL。
假设我们要查询过去 24 小时内记录的 温度
测量的平均温度。
在 InfluxQL 中,查询语句可能类似于:
SELECT
MEAN("value")
FROM
"temperature"
WHERE
time > now() - 24h
GROUP BY
time(1h)
这个 InfluxQL 查询语句计算了 "temperature" 测量中 "value" 字段的平均值,其中时间大于当前时间减去 24 小时。结果按一小时间隔分组。
在 Flux 中,类似的查询语句看起来更像这样:
from(bucket: "my-bucket")
|> range(start: -24h)
|> filter(fn: (r) => r._measurement == "temperature" and r._field == "value")
|> aggregateWindow(every: 1h, fn: mean)
在这个 Flux 查询语句中,数据从 "my-bucket" 中检索,range()
函数用于过滤过去 24 小时的数据。filter()
函数将数据缩小到 "temperature" 测量和 "value" 字段。aggregateWindow()
函数用于计算一小时间隔内的平均值。
如果我们要使用带 TimescaleDB 的 PostgreSQL 编写类似的 SQL 查询语句,我们会使用:
SELECT
time_bucket('1 hour', time) AS one_hour_interval,
AVG(value) as mean_temperature
FROM
temperature
WHERE
time > NOW() - INTERVAL '24 hours'
GROUP BY
one_hour_interval
ORDER BY
one_hour_interval;
在这个 SQL 查询语句中,您可以看到以下内容
我们使用 TimescaleDB 函数 time_bucket
创建一小时间隔的桶。
AVG(value)
计算每个时间桶内温度读数的平均值。
在 WHERE
子句中,过滤数据以仅包含过去 24 小时内的时间行。
结果按一小时间隔分组并按顺序排列,以显示平均温度读数的时间顺序视图。
如果您想将一些代码从 InfluxQL 迁移到 SQL(反之亦然),这份速查表将对您有所帮助。
[请注意,这些信息只是简化版(就像所有速查表一样)。请始终确保根据您的特定数据库配置和版本定制查询,并始终参考官方文档以获取详细准确的信息。]
数据库操作 | InfluxQL | SQL |
选择数据 |
|
|
过滤 |
|
|
分组 |
|
|
排序 |
|
|
限制 |
|
|
简单聚合 |
|
|
计数 |
|
|
求和 |
|
|
最小值/最大值 |
|
|
时间间隔之间 |
|
|
特定时间间隔 |
| 仅限于 Timescale
|
按值过滤 |
|
|
连接 | 不支持直接连接,请使用子查询或合并系列 |
|
Having | 没有直接等效项 |
|
连续查询/连续聚合—仅限于 Timescale(在原生 PostgreSQL 中不可用) | ||
创建 |
|
|
删除 |
|
|
列表 |
|
|
插入数据 | ||
单行 |
|
|
多行 | 使用多个 INSERT INTO 语句或将值与换行符连接起来 |
|
删除数据 | ||
特定记录 |
|
|
保留策略—仅限于 Timescale(在原生 PostgreSQL 中不可用) | ||
创建 |
|
|
修改 |
| 不支持直接修改,请重新创建策略或运行 |
列表 |
|
|
压缩—仅限于 Timescale(在原生 PostgreSQL 中不可用) | ||
启用/禁用 | 不支持原生方式,依赖于底层存储机制 |
|
P.S. 您可能想知道为什么我们在上面的表格中没有包含 Flux:创建一份速查表来比较 InfluxQL 和 SQL 相对简单,因为它们语法和结构相似。即使这些只是一些指南,我们相信它们可以帮助您。但是,以对您有用的方式将 Flux 纳入其中则比较困难,因为语法差异很大。直接比较 SQL 和 Flux 具有挑战性。
InfluxDB 使用两种不同的查询语言:InfluxQL 和 Flux,具体取决于 InfluxDB 的版本。InfluxDB 1.x 和 InfluxDB 3.x 使用 InfluxQL,而 InfluxDB 2.x 使用 Flux。
InfluxDB 是一种专门为时间序列数据设计的 NoSQL 数据库。
不使用。InfluxDB 1.x 和 3.x 使用 InfluxQL,这是一种类似于 SQL 的查询语言,用于数据查询和操作。InfluxDB 2.x 使用 Flux,这是一种不同的查询语言。
不作为主要语言。InfluxDB 2.0 主要使用 Flux 作为其查询语言,但也提供对 InfluxQL 的兼容性,以支持现有查询和应用程序。
InfluxQL 使用类似于 SQL 的语法,而 Flux 则具有函数式编程风格。
InfluxQL 提供了一种简化的类似于 SQL 的语法,专门用于查询和分析时间序列数据,使其在特定用例(如实时分析)中更有效。
与 SQL 相比,InfluxQL 的功能和灵活性有限,使其在复杂查询、跨表分析数据或与其他系统和工具集成方面不那么灵活。
在本文中,我们探讨了 InfluxQL、Flux 和 SQL 作为查询语言之间的差异。虽然 InfluxQL 和 Flux 是 InfluxDB 使用的查询语言,并且专门构建用于处理时间序列数据,但 SQL 是一种广泛用于关系数据库(包括 PostgreSQL 和 TimescaleDB)的查询语言。
虽然 InfluxQL 和 Flux 在各自的领域很强大,但 SQL 的适应性、成熟度和综合性,加上 TimescaleDB 的创新,使其成为处理时间序列数据以及广泛的数据管理和分析需求的理想选择。
如果您尚未使用 TimescaleDB,请 查看。如果您已经在自己的硬件上运行 PostgreSQL 数据库,您可以 简单地添加 TimescaleDB 扩展。如果您想在 AWS 中试用 Timescale,请 在我们的平台上创建一个免费帐户。只需要几秒钟,无需信用卡。