Factry joined the InfluxDays 2018 in London last week, where we were introduced to a new and exciting addition to the Influx ecosystem: Flux. Flux is a new functional language that will allow users to gather complex data from the Influx database. As it sparked our enthusiasm immediately, we wanted to share our excitement with you in the form of a short introduction.

Disclaimer: Flux is currently still under development, and it will only become available on production systems on a later date.

An introduction to Flux

Flux was contrived by Paul Dix, Co-founder and CTO at Influx, and it was also Paul who introduced us to Flux on InfluxDays 2018. Flux promises to become the new language to access and process time series data. It brings an alternative to the Influx Query Language, or InfluxQL, which is currently used to gather data from the Influx database.

Shortcomings of InfluxQL

InfluxQL is an SQL-like language, in contrast to an SQL-true language, that allows the user to use familiar select statements to gather data from the database. However, it also comes with a variety of limitations: SQL was originally created for relational databases, which have a significantly different form than a time-series database. Because of this, statements which are common in a relational database, such as joins on tables, were deemed impossible in InfluxQL. This makes it impossible to perform e.g. calculations between two different time-series without the proper pre-processing. Also, complex group by statements come with limiting restrictions, and to use a having statement, one has to work with either Continuous Queries, or restricted sub-queries.

Flux to the rescue!

Influx acknowledged the shortcomings of InfluxQL for its use in a time-series database, and that is why they have introduced a brand-new language called Flux.

Flux is a functional language, and is especially developed to work with time-series databases (although it is not necessarly restricted to it). At its base, it needed to provide the Influx community with a flexible and smart solution to fetch, aggregate and manipulate time-series data, without any of the pitfalls or shortcomings of InfluxQL. To give an idea on how this was accomplished, let’s look at the three limitations discussed before: complex joins, complex group by-statements, and the having statement.

Joins between time-series

Suppose we have a requirement to show the average of two temperature sensors, for the last 30 minutes, which are stored in Influx in two separate time-series, TempSensor1 and TempSensor2, respectively.

This can easily be solved in Flux using the following statements:

ts1 = from(db: "InfluxDB")
	|> filter(fn: (r) => r["_measurement"] == "TempSensor1"
	|> range(start: -30m)
ts2 = from(db: "InfluxDB")
	|> filter(fn: (r) => r["_measurement"] == "TempSensor2"
	|> range(start: -30m)
join(tables:{ts1:TempSensor1, ts2:TempSensor2}, on:["Tank"]
    ,fn: (tables) => (tables.ts1["_value"] + tables.ts2["_value"]) / 2)

Because of the modular set-up of the Flux language, the statements are easily comprehended, even if you have never seen the Flux language before.

Complex Group Bys

Similar to joins, performing complex Group By statements in Flux is incredibly easy, as can be shown in the following example.

Suppose we wish to group our result set based on tags that are attached to the time-series. This can be done as following:

from(db: "InfluxDB")
    |> range(start: -30m)
    |> group(by: ["tag_a", "tag_b"])

Having clause

Because of the modular setup of Flux, where every statement in itself actually produces a resultset, it becomes very easy to simulate a having clause in Flux, as can be seen by the following example.

Suppose you want to have the mean value of a certain sensor TempSensor1, but only when the value is larger than 20 degrees. This can be achieved as follows:

from(db: "InfluxDB")
	|> filter(fn: (r) => r["_measurement"] == "TempSensor1"
	|> range(start: -30m)
	|> window(every:10m)
	|> mean()
	|> filter(fn: (r) => r._value > 20

Conclusion

We were pleasantly surprised with the possibilities that Flux offers, and there is still so much more to discover. Besides solving the limitations that come with InfluxQL, Flux will also provide more functions that will enhance the possibilities of analysis which we can do with time-series data, share functionalities within the Influx community, and it will even support unit testing.

The coming weeks and months we will keep our eye on the [Flux repository] (https://github.com/influxdata/platform/tree/master/query), and on the growing Flux spec sheet.

And in case you were wondering: yes, Flux has even been adopted already - albeit in a beta stadium - by [Grafana] (https://github.com/grafana/influxdb-flux-datasource).