I’m beginning to migrate a graphite project over to a to a new influxdb, I’ve set up the latest open source version v2.7.5.
Coming from graphite its taken me some time to get my head around measurements, tags and fields but I think I’ve now got my data into a sensible structure. It’s time to write some queries…
I’m just about to dive into learning flux, however I notice flux is now in maintenance mode to be replaced(?) by InfluxQL? I think. This is where I’m getting a bit confused as to what is current/deprecated/planned…?
Is it worth me learning flux at this point? Or should I go straight for InfluxQL or SQL of some sort?
I’m totally inexperienced in the flux query languages, but I am however quite experienced with MySQL if that’s any advantage.
So given I’m a new user and this is a new project, what query language would you recommend I learn?
EDIT: Oh I’m also intending to use Grafana for the visualisations, which talks about FlightSQL, so maybe that is the answer, not sure exactly what the difference is between all these!?
@bobemoe Where you’re 1) experienced with MyQL and 2) are using InfluxDB 2.7, you should consider using InfluxQL as your query language. It’s a SQL-like language specifically designed to work with time series data. There will likely be less of a learning curve than using Flux.
Flux is a power language, but it does have a steep learning curve. I think a lot of people look at Flux as a query language that you can script, but I think the better way to look at it is that Flux is a scripting language that’s focused on querying data.
Looking to the future, InfluxDB v3 currently only supports SQL and InfluxQL. InfluxDB v2 supports Flux and InfluxQL. So InfluxQL is probably your best bet since it matches both your experience and where InfluxDB is going.
Brilliant. Thanks for clearing that up. Looks like I cant use InfluxQL in the InfluxDB v2 frontend though but I’ve found a query editor in Grafana so its all beginning to come together. Thanks again
As I browse, research and learn, I keep finding guides and posts saying they are moving away from InfluxQL to Flux because it is more powerful and flexible, that InfluxQL is quite limited. Am I going to be limiting myself using this? Why the move back to InfluxQL if it is limited and Flux was created to address this. What am I missing here?
There’s a lot of history here . Flux was developed for InfluxDB v2 and is designed around the v1/v2 storage engine (Time-structured Merge Tree (TSM)). Flux is incredibly flexible and provides functionality that you just can’t get in a SQL-like query language, but there is a steep learning curve and a bit of hit when it comes to query performance.
The InfluxDB v3 storage engine (IOx) has been implemented in InfluxDB Cloud Serverless, InfluxDB Cloud Dedicated, and InfluxDB Clustered and will soon be available in open source InfluxDB v3 products.
The v3 storage engine natively supports both SQL and InfluxQL, but the Flux architecture doesn’t work well with the v3 storage engine. In an internal test implementation, Flux query performance against the new storage engine was significantly lower.
With that fact and the constant demand for native SQL support from new users and first-class InfluxQL support from established customers, the decisions was made to put Flux into maintenance mode and focus engineering efforts on SQL and InfluxQL for v3.
There is community fork of Flux that includes work to improve compatibility with the InfluxDB v3 storage engine, but this is all community work. All of the internal engineering effort is focused on SQL and InfluxQL. Flux is still receiving security patches and bug fixes, but new functionality is only being added to the community fork.
