Influxdb made the switch from Go to Rust

Like you, I've stuck with Influx v1, Telegraf and Grafana. My policy is to upgrade only when there are significant reasons to. When I evaluated InfluxDB 2, there were no major reasons for me to switch. Of course, the data ingested in my case is relatively small. YMMV.

I looked at TimescaleDB but at the time there was no easy way to get data from Telegraf to TimescaleDB. Telegraf finally merged code that allows writes to Postgres databases, but it took like 3 years to do that.

Ultimately, I still stuck with InfluxDB v1 because sending data to it via the InfluxDB line protocol is so simple. I have a couple of bash scripts that use awk to transform command output to Influx line protocol and send it to InfluxDB. It's just so simple. I love it.

I love learning about new things, but the InfluxDB v1 keeps working fine so I may not switch from it until something forces me to do it.

I delayed upgrading to flux and finally bit the bullet this summer, and a month later read the announcement deprecating it.

Next time around I'm going to give TimescaleDB a look.

Are you running the "OLAP" TimescaleDB on the same instance as your regular OLTP Postgres? This is the only reason I would entertain TimescaleDB, if I had a strict "1 server" requirement. I briefly deployed and looked into it and there were a lot of footguns like with compression.

If not, I would suggest looking at a proper OLAP DB. VictoriaMetrics has been great and was easy to set up.

Fair warning, I had serious scaling issues with Timescale.

Solutions like Grafana Mimir, Victoria Metrics, Clickhouse, or yes, the new Influx implementation, are much more scalable and will give you much fewer headaches.

ClickhouseDB is realy brilliant, btw, it's a powerhouse. Especially with the fairly recent additions that enable hybrid local + S3 option, pushing older metrics to S3 for cheap long-term storage.

Another alternative to timescale could be hydra. Haven’t tried it myself but the promise of columnar tables seems wildly useful.

We are influxdb enterprise customers and looking to do the same thing. They've kept their enterprise offering on 1.x, which has kept us mostly happy, but seeing what's going on in their OSS stuff is horrifying and we're looking to avoid the crash and burn at the end of the tunnel.

Same here. I joined current company 3 years ago when Influx v2 was coming out. I was supposed to build some analytics on top of it. It was very painful. Flux compiler was often giving internal errors, docs were unclear and it was hard to write any a bit more complicated code. The dash is subpar to graphana but graphana had just raw support. There was no query builder for flux so I tried building dashboards in influxv2 but the whole experience was excrutiating. I still have an issue open where they have an internal function incorrectly written in their own flux code and I provided the fix and what was the issue but it was never addressed. Often times I had a feeling that I found bugs in situations that were so basic that it felt like I was the only person on the planet writing Flux code

What are you migrating to?

Yes I think v3 is pretty solid, and it's nice that they are still supporting v1 and v2. But I think the "migration" from v1 to v2 was the "painful" part. Not because it was too hard to migrate (I guess you don't even have to, since it's still supported), but because it introduced a very different approach, that was supposed to be the future of influx, that was just basically dropped in the next release. I think some commitment towards v3 might help in that regard. As you said, flux is powerful and took some time to get used to but it's now basically useless if you took the time to get into it.

I like that they are converging towards SQL, but at the same time it's a bit like going back to square one. They seem more convinced about going full SQL this time though, but yeah

Just searching for this, I stumbled on this documentation page that illustrates the point very well:

https://docs.influxdata.com/influxdb/v1/query_language/

In the same page (about the original influxql in v1), there is a depecration notice for v1 stating that v2 is the stable version, implying that InfluxQL is not recommended. And a pop up notice stating that v2 (flux) is basically deprecated and just in maintenance mode, and that you should use InfluxQL. But as I said in my earlier comment, I guess in some ways that's better than being too rigid and sticking with bad or less ideal technical decisions.

He is a founder.

serious question on behalf of the uniformed, why? I feel that society encourages people to double down and be consistent even if they are armed with better information. we could be better if we didn't have to stick to the one true path, no?

Thanks for your reply! Dumb question (I couldn't find a definitive answer) but will v3 InfluxQL be compatible with v1? Is there an article about the changes between v1 and v3?

I guess I'd rather have that than ossifying on a completely flawed architecture. Apparently flux was kind of a dead end, and while it's super risky and illustrates issues in decision making, it's still better than just doubling down on something that their own team consider to be futureless or too flawed.

It's weird because I got here from a link on lemmy.

thanks! killer example.

how are you dealing with failover?

how are you dealing with interactive reporting?

how large are your records?

is the s3 data in cold storage? how much is stored in S3 right now? is it warm-enough to query via (e.g.) athena?

Don't get me wrong, I don't denigrate Influx DB. They have some interesting features that prometheus doesn't have, I just don't think that this features can lead to a mass adoption(and money).

Let's put this way: is there any killer feature that can ditch most of the Prometheus installations in their favor?

I think they missed one thing: Nobody wants to get locked in with the runner-up.

If they on top of that provided some compatibility layer for Prometheus/PromQL, like few other competitors did, then the prospective enterprise client have warm fuzzies that if they don't like it they don't need to rewrite entirety of their stack to work with something else. People could also use the existing ecosystem and "just plug it in", even replacing Prometheus instances they might have.

In the end people want to ingest the metrics and display it in Grafana. They don't need another visualisation solution that has less support and documentation. They don't want to learn new weird query language that is simulatenously more verbose and less readable than PromQL or even influxQL from v1.

I think you'd find that Prometheus is way behind a number of solutions in the corporate world, including Graphite, DogStatsD, etc. Popularity on HN does not translate to real world popularity.

Do you know if there is any particular advantage of Influx over Prometheus for IOT stuff? I also have noticed that Influx is way more popular in that space, but I don’t know whether the reasons are technical or just social (more tutorials, more shared experience, etc).

VictoriaMetrics all-in-one binary is honestly everything that I need in my home IoT things.

Prometheus-compatible interface for query, a bunch of ingest protocols, smaller memory usage than InfluxDB (v1, haven't tested v2 coz new language have less grafana support). Options to scale too

Yeah, I know, but there are a lot of competition in this field. Every cloud provider, Grafana and other players have their own managed Prometheus compatible solution.

They seem all over the place.

https://www.theregister.com/2023/07/11/influxdata_apologizes...

Maybe i miss something, but the version 3 is just the database, they abandoned the TICK stack some time ago.

Can you expand what you are missing?

Prometheus is not just the db itself, it’s the ecosystem around it. You’ve got service-discovery, alertmanager and basically every application in existence having a /metrics endpoint and some pre-made Grafana dashboard.

AFAIK only difference is that in Influx a given row can have more than one value so say "interface traffic" would be

    interface_if_octets host=router,instance=eth0,rx=123584,tx=213956

while in prometheus it would be

    interface_if_octets host=router,instance=eth0,type=rx 123584
    interface_if_octets host=router,instance=eth0,type=tx 213956

which in theory yes it is more compact but it gave me more annoyances than advantages during querying

>While Prometheus is often good enough for standard metrics, it is just things it can't handle.

My experience is that just anything made to ingest and analyze logs ends up mediocre for metrics and vice versa. I don't think I've seen single product that did both well or efficiently. So I'd rather have good metrics and just use ELK/Graylog/whatever else for logs.

> Prometheus only handle aggregated data, though.

That's not true. You're referring to pull-based approach for metrics collection. It has its tradeoffs (like fixed interval scraping), but has a lot of benefits too (like higher reliability). Check the following link [0] from VictoriaMetrics docs, which supports both push and pull approaches. Prometheus also gained push support this year, though.

However, the main difference between Prometheus-like systems (Thanos, Mimir, VictoriaMetrics) and more traditional DBs for time series like InfluxDB or TimescaleDB is that first are designed to reflect system's state, and last are designed to reflect system's events. That's the main difference in paradigm, data model, and query languages. There is a reason why PromQL is so easy in 99% of cases, and so complex and annoying when users want to express what they get used to in traditional databases.

I'm saying this because I went through creating a Grafana datasource for ClickHouse [1] and I felt how complicated it is to express a most straightforward PromQL query in SQL, and vice versa.

If you'd like to learn more about differences between common queries for plotting time series in PromQL and SQL see my talk here [2].

[0] https://docs.victoriametrics.com/keyConcepts.html#write-data

[1] https://grafana.com/grafana/plugins/vertamedia-clickhouse-da...

[2] https://youtu.be/_zORxrgLtec?t=835

Does InfluxDB support event-based data models? For example, imagine something simple an SQL database's query log. Each query is an event, with data such as latency, rows, block I/O and so on, and metadata such as the database, the full SQL query, and so on. This is the kind of use case where traditional "measurement"-based time series databases like Prometheus aren't a good fit, because you have huge column cardinality for the labels (one value per query). Meanwhile, more general-purpose columns databases like ClickHouse and BigQuery have no issues with this type of data.

Haven't downvote, but I can't make sense of your comment in the context of this article.

Maybe you have some context or background info I don't have?

Yes, and in another HN post the Influx founder stated (me paraphrasing) it’s and it’s all about SQL compatibility.

Rust is not hype.

Sure, the write definitely could have helped releasing these new features, but the language transition itself takes non-trivial effort and could have been used for adding additional features instead. I haven't seen any evidence that such a language transition is desperately needed. Also I said deprioritize adding features, not stop adding features, mind you. The core question here is what kind of benefit we are seeing by changing the language.

If you are a fan of Rust and want to rewrite all your just because of that and you are the CTO, whatever, what can I say. But the title here is a bit clickbait-y and I really don't see much reflection on the languages themselves and how to balance the business needs for such a transition.

What is meant by separating compute from storage? This keeps being mentioned as if it were some new paradigm shift so I assume there's a non-obvious situation.

To be fair, we didn't drop everything and do a rewrite. Over the last 3.5 years (the length of time for this project), our total engineering team has ranged from 50-90 people. For the first year it was me and two other people. Then for the 2 years following that it was 9 people total.

It wasn't until late last year that we made the decision to go all in on the rewrite and made that the focus of everyone in engineering. And we did that because we had 4 years of experience trying to get v2 and Flux to be successful, with modest results.

Most of the time we were developing this version, we were spending massively more engineering effort on developing v2 or maintaining v1 for our customers.

>excuse to use rust

Using rust for any other reason than its the best option technically, is just fad chasing.

Smaller job pool?

How does learning Rust reduce your chances of getting a new job? Learning new stuff increases your chances, not decreasea them.

I'd love a blog or a write up on the rewriting process, lessons learnt etc. It would be awesome!

Go does too. Those two feel like the most hyped languages currently on HN.

Yeah, I'm sure they spent 3 years working on it to get on the front page for only a few hours. I'd get this argument maybe if you're talking about a pet project...

You can write a database in Go, sure, but if you want to compete at the very top end, you need all the control. Go is nice in the way that Go is nice (if you even agree with that statement) precisely because it doesn't have that control. Unless it is a terminal goal for a database to be in Go simply to be in Go (BoltDB seems to fit into this category) or you don't care to compete at the very top end, I think it's a mistake to even start in Go.

To be honest, most of the "we started in Go and switched to Rust" stories read to me as "you should have always known that you should have started in Rust" (or C++ or something, though I'd choose Rust out of the viable set of languages here too). It's IMHO always been obvious that Go was not really viable, I mean, sure, you can get farther than you could with starting with Python, but, it's not something Go was even trying to solve.

If you're scaling horizontally it's doubtful that language choice of rust Vs Go is going to make a difference.

Not enough, anyway, to make a complete rewrite more profitable over adding features.

After all, it's not as easy if influx was plagued by concurrency bugs, was it?

A move to a safer language than go just doesn't seem worth it, and there's little to no performance gain when you can just throw more hardware for that tiny performance difference.