InfluxQL Support? Month Aggregation

InfluxDB 2
1

Hi all!

I have a dashboard system implemented in InfluxDB 2.1 OSS using InfluxQL over HTTP (I migrated from 1.8 quite recently). I need to use the 1mo aggregation, but unfortunately, it is not available on InfluxQL, but it is allowed on Flux. I do not want to port all my InfluxQL queries to Flux, as currently there is no a direct path, i.e.:

  • Multiple field aggregation over a measurement with string/numeric fields cannot be done directly, but it works fine with InfluxQL. It is possible to use isType, but it is not available until 2.2.2.
  • It is complex to run multiple aggregations at the same time (i.e., mean, max, min). It is something trivial with InfluxQL, and seems to be complex on Flux, issuing multiple queries, joining them, etc.
  • Return data now changed to CSV, which is not quite confortable to work with, specially taking into account we are consuming it as an REST/API. I have done some approach to use pivot, group, and json to provide a column with formatted json, but not sure how it affects the performance.
  • I did not executed performance tests, but it seems to me that Flux queries are slower than InfluxQL? Just a perception.

My concern here is if InfluxQL will continue to be supported and updated with new features, specially with month aggregation. I understand that Flux is much more advanced system and can provide much more flexibility, but it seems to require much more expertise to do the same basic things that where available on InfluxQL.

So, is there plans to still support InfluxQL? is there any possibility to include month aggregation to InfluxQ?

2

Hello @alvarolb.
I don’t know if/when that will be supported.
I don’t think Flux requires more expertise. I think it’s actually easier than InfluxQL, but I’ll admit that I didn’t think that at first. I attribute my initial resistance to Flux to being uncomfortable with seeing the data structured in a different way. Once I got used to that shift and understood group keys, I found it much easier.

To your points:

  • You can still perform multiple field aggregation over a measurement. You just need to apply the toInt() or toFloat() functions before the aggregations. You can’t take the mean of descriptive metadata anyways. You can filter those fields out. For example:
from(bucket: "noaa")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "h2o_feet")
  |> filter(fn: (r) => r["location"] == "coyote_creek")
  |> filter(fn: (r) => r["_field"] != "level description")
  |> toInt()
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")
  • Running multiple aggregations isn’t difficult, but I agree it is a shift. You don’t have to use joins. It would be something like:
data = from(bucket: "noaa")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "h2o_feet")
  |> filter(fn: (r) => r["location"] == "coyote_creek")
  |> filter(fn: (r) => r["_field"] != "level description")

mean = data |> mean()  |> yield(name: "mean")
min = data |> min()  |> yield(name: "min")
max = data |> max()  |> yield(name: "max")

While this might appear to be longer, I find it easier to read. Also imho that’s where the “triviality” of InfluxQL ends and where Flux begins to shine.

  • I recommend using Client Libraries so that it’s easier to consume the output.

  • It depends on your data and the query you’re trying to run. There are tradeoffs but a lot of what you can do with Flux you can’t do with InfluxQL. Some queries are faster in Flux.

I’m happy to help translate any InfluxQL queries to Flux for you to help you get started. I want to help you discover that learning Flux is actually easier than you might imagine and worth your time (This is coming from someone who shared similar feelings about it at one point and now really doesn’t look forward to having to work with InfluxQL).

Also, you might find this documentation helpful: