Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Influxdb made the switch from Go to Rust

old.reddit.com

Post reply on HN
Print view View original

51–60 of 162 posts

Re: Influxdb made the switch from Go to Rust

#51

Post by tetha »

pphysch wrote: post #40
tetha wrote: post #34

Earlier quoted context omitted.

We're migrating off of InfluxDB due to that rollercoaster, honestly. It's hard enough to find time to maintain the monitoring stack at work. Casually dropping "Oh, and now you get to rebuild the entire grafana to change the query language" on that doesn't help. And apparently, version 3 does the same thing, except backwards. Sorry, but at that point, we've decided to rebuild the entire metric visualization once on Ti…

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.

We're much rather looking at reducing the number of technologies we have and exchanging one specialized one-use database for another one doesn't sound great. And sure, TimescaleDB is a hefty extension and will require some work to understand it, but things like HA, backups and overall management of Postgres are pretty much solved for us.

And beyond that, TimescaleDB works with a few things we have already. We could migrate Zabbix to use TimescaleDB for a large performance boost. Also 1-2 teams are building reporting solutions for the product platform, and they are generating some significant timeseries data in a Postgres database as well.

Re: Influxdb made the switch from Go to Rust

#52

Post by mardifoufs »

bachmeier wrote: post #50

This was discussed on HN at the time (2020): https://news.ycombinator.com/item?id=25049253 At some point HN is going to have to decide if it's the Rust subreddit or a news site.

I think they just completed the transition which is why it came up again.

Re: Influxdb made the switch from Go to Rust

#53

Post by candiddevmike »

mardifoufs wrote: post #7

I love influx but damn do they like moving (too?) fast and quickly changing stuff. In a way, it's pretty cool since it means that they don't get stuck with bad decisions for backwards compatibility reasons, but it's a bit of a roller coaster for users. Not sure what's the best solution though. Having a "stable" but fundamentally limited product (I guess influxdb v1) or breaking stuff in hopes of ending up with a way…

I'm honestly surprised the CTO is still employed.

Re: Influxdb made the switch from Go to Rust

#54

Post by PaulWaldman »

phamilton wrote: post #44
pphysch wrote: post #40

Earlier quoted context omitted.

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.

A reason I would still bias towards postgres is the maturity of managed solutions (including decoupled compute/storage solutions like Aurora and AlloyDB). Are managed "proper OLAP DB" solutions competitive with managed RDBMS from a price and ease of use standpoint?

Using TimescaleDB from a managed provider is limited, unless of course that provider is Timescale. Other managed providers are only permitted to use the TimescaleDB Apache 2 Edition.

This link has a comparison of features[1].

[1] https://docs.timescale.com/about/latest/timescaledb-editions...

Re: Influxdb made the switch from Go to Rust

#55

Post by ilyt »

matsemann wrote: post #42
vb-8448 wrote: post #3

Can someone explain what's the InfluxData's market? Or how they make/plan to make money? If we speak about metrics, Prometheus just win.

Prometheus only handle aggregated data, though. While with influx you can store the events themselves with labels etc. While Prometheus is often good enough for standard metrics, it is just things it can't handle.

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.

Re: Influxdb made the switch from Go to Rust

#56

Post by PaulWaldman »

candiddevmike wrote: post #53
mardifoufs wrote: post #7

I love influx but damn do they like moving (too?) fast and quickly changing stuff. In a way, it's pretty cool since it means that they don't get stuck with bad decisions for backwards compatibility reasons, but it's a bit of a roller coaster for users. Not sure what's the best solution though. Having a "stable" but fundamentally limited product (I guess influxdb v1) or breaking stuff in hopes of ending up with a way…

I'm honestly surprised the CTO is still employed.

He is a founder.

Re: Influxdb made the switch from Go to Rust

#57

Post by pstuart »

tekla wrote: post #23

Is it possible to do HA with Influxdb OSS yet?

That shift is what lost me.

Admittedly I was at a shop that wasn't likely to shift to an enterprise version so not a direct economic loss on their part but definitely stopped thinking of it as a solution to consider.

Re: Influxdb made the switch from Go to Rust

#58

Post by PaulWaldman »

The issue is that InfluxDB is an infrastructure product. Changing the core impacts the way users interact with the product. If Figma decided to change their backend, it could be transparent to users.

Opinions could be different if first they implemented a complete compatibility layer, Flux included, prior to making the migration.

Re: Influxdb made the switch from Go to Rust

#59

Post by ilyt »

GauntletWizard wrote: post #5
vb-8448 wrote: post #3

Can someone explain what's the InfluxData's market? Or how they make/plan to make money? If we speak about metrics, Prometheus just win.

I am about the biggest Prometheus stan that you can find, but I will not mock or denigrate influx db. They are a runner-up, but there is room in this market for runner-ups, and their feature set does match some that Prometheus is not good at.

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.

Re: Influxdb made the switch from Go to Rust

#60

Post by mardifoufs »

maxprimer wrote: post #41
mardifoufs wrote: post #7

I love influx but damn do they like moving (too?) fast and quickly changing stuff. In a way, it's pretty cool since it means that they don't get stuck with bad decisions for backwards compatibility reasons, but it's a bit of a roller coaster for users. Not sure what's the best solution though. Having a "stable" but fundamentally limited product (I guess influxdb v1) or breaking stuff in hopes of ending up with a way…

Been using both 1.x and 2.x for telemetry (oss & paid both). I am pretty excited with 3.x's interoperability. Archiving to standard data formats makes the data science team's job's easier, and with a more standard ANSI SQL query engine with jdbc support, and high cardinality tags, it will greatly speed up front end development and analysis use cases. As well, I am one of those folks that happens to find the Flux quer…

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.

Post reply on HN