Influx 1.8.10 vs influx v2.x

[bradharley]

I am in the middle of migrating my system to 64 bit and looking at the advantages/disadvantages of also upgrading to Influx 2.x.
-Are there any limitations with v 2.x and signalk plugin?
-What are the advantages and disadvantages wrt this environment?
-Any recommendations?
Thanks in advance
Brad

[tkurki]

Well, I switched from Influx 1.6 because upgrade to 1.8 did not work on the RPi nor on MacOS and at that point in time it was clear that 1.x has no future and 2.x was the way to go because 1.x was no longer used. There were also multiple reports of 1.x databases no longer working for some reason or another, mostly due to their size.

2.x uses Flux as the main query language, so you'll need to learn that to make use of your data for example in Grafana.

Or you can use https://github.com/tkurki/signalk-grafana that includes a Signal K History API datasource, allowing you to just pick the paths & sources & units that you want. Both signalk-to-influxdb (1.x Influx) and signalk-to-influxdb2 plugins support the History API. signalk-grafana is not very polished, but it has worked for me, and if more people use it we can get it ready for prime time.

But InfluxDb 2.x has meanwhile lost its future: in September 2023 Influx Data announced that InfluxDb 3 will be built from scratch and Flux will not be supported any more.

I have not really paid attention to their progress on 3.0. signalk-to-influxdb2 is actually using InfluxDb 2's compatibility API to do its queries in InfluxQL (1.x query language), so if this holds

From an API perspective it will support the InfluxDB 1.x and 2.x write APIs with Line Protocol, the InfluxQL query API (same as in both previous major InfluxDB versions), and all new APIs specifically built for 3.0, including the ability to query with industry standard SQL via FlightSQL or InfluxQL via Apache Arrow Flight.

then it should be either nonissue or very little work to make it work against 3.0. But it looks like 3's _ sweet spot will be for collecting and querying recent data_, so the question is how well that will match the needs of people using Signal K data in InfluxDb.

My recommendation today is to pick 2 and I don't see right now any other working options for a time series database onboard. But I am also going to seriously look into other solutions, like Timescale with Postgis.

[bradharley]

That is a very comprehensive response, and thank you. I currently have influx on docker, so upgrade should be easy, and roll back no big deal if necessary.
As an aside, the guy who's developing postgsail (has a signalk plugin) is using timescale on the server side and I'm assuming likes it. I like the fact that it's based on postgresql and should be more future proof than influx....

[tkurki]

Ah forgot to mention that I've been successful in exporting & importing data between versions in InfluxDb line protocol format. They have instructions. My plan is to use that format for "long term storage", eg. save as .Z in S3 after each season.