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

41–50 of 162 posts

Re: Influxdb made the switch from Go to Rust

#41

Post by maxprimer »

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 query language powerful, but it's not easy enough for folks to just make that jump from SQL. Flux is much closer to Splunk's search language. It is good at what it does. FluxQL doesn't even have date parsing (which is really odd for a time series query language), but FlightSQL in 3.x seems to be more complete.

Re: Influxdb made the switch from Go to Rust

#42

Post by matsemann »

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.

Re: Influxdb made the switch from Go to Rust

#43

Post by 2bluesc »

mnahkies wrote: post #26
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've always had a soft spot for influxdb after using it for a self hosted datadog/newrelic etc solution many (6+) years ago with great success. Still use it in conjunction with telegraf and grafana for personal project monitoring, but I've not brought myself to upgrade from the 1.x series. Hopefully it's improved, but last time I tried upgrading I found the UX in grafana to be subpar on the newer versions, as I recal…

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.

Re: Influxdb made the switch from Go to Rust

#44

Post by phamilton »

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.

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?

Re: Influxdb made the switch from Go to Rust

#45

Post by danielvaughn »

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…

It’s funny how for the longest time, I was upset with how slowly the web moved. At times I wished they wouldn’t care as much about backwards compatibility.

But now with these VC-funded tech products that have spawned over the last 5-7 years, who have a move-fast-and-break-things attitude, I’m seeing the benefits of the old approach.

I suppose it’s all a matter of trade offs, as with all things, and there’s no silver bullet.

Re: Influxdb made the switch from Go to Rust

#47

Post by influx »

capableweb wrote: post #10
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.

As is tradition, hosted service: https://www.influxdata.com/influxdb-pricing/ Basically either you manage it yourself, or you pay them to do Serverless/Dedicated/Clustered hosted setup for you.

They seem all over the place.

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

Re: Influxdb made the switch from Go to Rust

#48

Post by ilyt »

justin_oaks wrote: post #33
mnahkies wrote: post #26

Earlier quoted context omitted.

I've always had a soft spot for influxdb after using it for a self hosted datadog/newrelic etc solution many (6+) years ago with great success. Still use it in conjunction with telegraf and grafana for personal project monitoring, but I've not brought myself to upgrade from the 1.x series. Hopefully it's improved, but last time I tried upgrading I found the UX in grafana to be subpar on the newer versions, as I recal…

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…

Was very similar for me. No good reason to go V2, the new query language, on top of sucking for anyone that only uses it once every few weeks, also wasn't really supported well in Grafana.

I ended up trying VictoriaMetrics by near accident as infuxdb didn't like something on my raspberry pi, and honestly it has been pretty painless. It is Prometheus-like stack which means you can use any PromQL-compatible things with it. There is "all in one binary", and version split by functions.

VM have tools to migrate from InfluxDB v1. I ended up just sticking old influxdb data in one database, as I wanted to change the format of what I write to it along with the migration.

> 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.

It also have agent that's job is to convert from various protocols, and do the scraping, that includes influxdb, and few other popular protocols.

Re: Influxdb made the switch from Go to Rust

#49

Post by ilyt »

jeroenhd wrote: post #8
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 see Influx pop up a lot in communities like Home Assistant for doing time series data collection. I'm using Postgres for that myself (not a great experience but I knew that when I was too lazy to find alternatives during setup) but people seem very pleased with its performance. I imagine similar dashboard services that don't necessarily work well in Prometheus are a good market for these types of databases. Prometh…

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

Post reply on HN