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

131–140 of 162 posts

Re: Influxdb made the switch from Go to Rust

#131

Post by hagen1778 »

manicennui wrote: post #124
GauntletWizard wrote: post #5

Earlier quoted context omitted.

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

That's only a matter of time when they hire younger engineers who are familiar with modern monitoring systems and eager to apply their knowledge in practice.

Re: Influxdb made the switch from Go to Rust

#132

Post by hagen1778 »

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.

> 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

Re: Influxdb made the switch from Go to Rust

#133

Post by demi56 »

pauldix wrote: post #98
demi56 wrote: post #91

Earlier quoted context omitted.

So what’s gonna happen for v1 and v2 ? cause the number of features you’re offering in v3 is gonna be difficult to maintain compared to v1, v2

We're going to continue to support our customers on v1 and v2. We're building migration tooling over to v3 for those that want it. We have multiple years of transition ahead of us, we expect to have customers on all 3 versions for quite a while.

Thanks for the info

Re: Influxdb made the switch from Go to Rust

#134

Post by exabrial »

I love InfluxDB 1.x and the TICK stack. They abandoned a beautiful piece of software to chase shiny things with 2.x... sad to see them do it again.

Someone needs to pickup the original ideas of 1.x since they can't seem to stay focused, as their marketshare is ripe for grabbing.

Re: Influxdb made the switch from Go to Rust

#135

Post by jacobgorm »

My problem with Rust is that compilation is too slow, as is downloading the gazillion crates needed to go anywhere. When I heard it was going to replace C I was expecting similar build times, but in reality Rust builds much slower than C++.

With C/C++ (and CMake + Ninja) it seemed we were finally getting to a point where incremental builds would complete before hitting the 400ms attention span "Doherty Threshold", and now it seems we are going back to the days of having to spend our time sword-fighting (xkcd) during slow builds.

Re: Influxdb made the switch from Go to Rust

#136

Post by pauldix »

exabrial wrote: post #134

I love InfluxDB 1.x and the TICK stack. They abandoned a beautiful piece of software to chase shiny things with 2.x... sad to see them do it again. Someone needs to pickup the original ideas of 1.x since they can't seem to stay focused, as their marketshare is ripe for grabbing.

With 3.0 we've worked hard to pull in the v1 API. Both the v1 write and query endpoints are supported in v3. There may some gaps here and there, but our goal is to make it so that all the things that worked with v1 will work with v3. The only two exceptions would be the subscription API that Kapacitor used and Continuous Queries. We warned people off from using both of those features in v1 as they didn't work well under load.

With v3, I prefer to think of it as us doubling down on core database performance and functionality. With v2 we tried to create this whole development platform. V3 brings our focus back to the core database, which I think will yield better results for everyone.

Re: Influxdb made the switch from Go to Rust

#137

Post by roygbiv2 »

pauldix wrote: post #101
x86a wrote: post #86

Earlier quoted context omitted.

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.

We announced the availability of the v3 successor to Enterprise v1. It supports the v1 API. We're still building data migration tooling, but if you're interested in testing it out just email support or your sales rep.

How does one upgrade from v2 beta to the latest v2? The docs for doing that seem to no longer exist https://github.com/influxdata/influxdb/issues/24393

Re: Influxdb made the switch from Go to Rust

#138

Post by asah »

How big are y'all that you need InfluxDB?

For one database that receives 100M 600 byte JSON records/day, a single node AWS PostgreSQL RDS instance is handling it effortlessly, and the DBA work is very part-time. We keep year+ of summaries and 48 hours of detail, unloading the rest to S3 as parquet files, queryable by Athena if we need. AFAICT, we're spending p.s. a buddy at a top-3 TV streaming service is also doing this for logging all viewing activity, but with Aurora.

Re: Influxdb made the switch from Go to Rust

#139

Post by wtfishackernews »

mfreed wrote: post #113
the_duke wrote: post #64

Earlier quoted context omitted.

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.

Also, Timescale similarly introduced S3 for bottomless data tiering: https://www.timescale.com/blog/expanding-the-boundaries-of-p...

Only for their managed solution at the moment.

Re: Influxdb made the switch from Go to Rust

#140

Post by justin_oaks »

ilyt wrote: post #48
justin_oaks wrote: post #33

Earlier quoted context omitted.

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…

I've heard good things about VictoriaMetrics. I'll have to carve out some time to check it out.

Thanks for sharing your experience.

Post reply on HN