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

CERN swaps out databases to feed its petabyte-a-day habit

theregister.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: CERN swaps out databases to feed its petabyte-a-day habit

#21

Post by ilyt »

theossuary wrote: post #19
ilyt wrote: post #10

I really like VictoriaMetrics's architecture vmagent takes care of all the pesky edge things like emulating prometheus config parsing and various scraping bits. It also does buffering in case you lose network connection for a while, and accept vast spread of different protocols vminsert/vmselect scale separately from eachother and your queries don't bother your ingest all that much. vmstorage does just that, storage.…

What version of Influx were you running? I'm interested if v3 will be more competitive than v2.

1.8, migration path to 2.0 was a no-no. Don't remember exact reasons back then but we decided to have wait-and-see approach and see how alternatives grow up as our data generally grows in predictable rate

Also frankly Prometheus support is a massive positive. For better or worse industry standarized on apps using Prometheus as ingest for metrics, and also most of the materials related to that will of course give examples in PromQL

Flux is frankly hieroglyphs for people using it 20 minutes a month like our developers

This is given example on how to raise value in Flux to power of two

    |> map(fn: (r) => ({ r with _value: r._value * r._value }))
This is example of that in prometheus

    value ^ 2
This is example of calculating percentage in Flux (from their webpage)

    data
      |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
      |> map(
          fn: (r) => ({
              _time: r._time,
              _field: "used_percent",
              _value: float(v: r.used) / float(v: r.total) * 100.0,
          }),
      )
This is how you do it in PromQL

    space_used / space_total * 100
Flux is atrocious for "normal users".

Re: CERN swaps out databases to feed its petabyte-a-day habit

#22

Post by [deleted] »

hintymad wrote: post #15
ComputerGuru wrote: post #13

Missing from the title: leaving InfluxDB and Prometheus for VictoriaMetrics.

This is puzzling. I'm not sure how VictoriaMetrics solved the cardinality problem? When running an aggregate query that sums up some counters for a single metric over the dimension of instances in a time window of larger than a few hours, VictoriaMetrics would barf with error for the querying having too many time series (or data points? I forgot the exact wording). This clearly shows that 1/ Victoria Metrics does not…

[deleted]

Re: CERN swaps out databases to feed its petabyte-a-day habit

#23

Post by contravariant »

keep_reading wrote: post #6

I also dropped InfluxDB at work due to its terrible performance. VictoriaMetrics is great I was using Promscale (TimescaleDB) but they EOL'd Promscale which forced us to Victoria. But either way both of these are much faster than Influx Don't get fooled into the latest InfluxDB rewrite. I think the latest is cloud hosted only too? So stupid

Honestly the database isn't half as useful as the tool they wrote to grab the metrics. At least I think telegraf was written by the same people? It seems to have the exact opposite design philosophy.

Re: CERN swaps out databases to feed its petabyte-a-day habit

#26

Post by everforward »

ilyt wrote: post #21
theossuary wrote: post #19

Earlier quoted context omitted.

What version of Influx were you running? I'm interested if v3 will be more competitive than v2.

1.8, migration path to 2.0 was a no-no. Don't remember exact reasons back then but we decided to have wait-and-see approach and see how alternatives grow up as our data generally grows in predictable rate Also frankly Prometheus support is a massive positive. For better or worse industry standarized on apps using Prometheus as ingest for metrics, and also most of the materials related to that will of course give exam…

Flux looks like it has the opposite design philosophy of PromQL: it makes simple things harder and hard things simpler.

I probably wouldn't default to it, but I've had to solve some issues that were complicated in PromQL that would probably be easier here. E.g. I had to work on a Prometheus monitoring/alerting setup where metrics were all recorded in UTC, but alerts should only fire during local business hours. We ended up with something like a thousand character PromQL query that was utterly illegible (have pity on whatever poor soul has to update it when DST goes away).

Flux looks like it would have a more legible solution to that, though at the cost of making simple analysis way more complicated than it probably needs to be.

Re: CERN swaps out databases to feed its petabyte-a-day habit

#28

Post by foobiekr »

qwertox wrote: post #9

At the end of the article it says " InfluxDB said in March this year it had solved the cardinality issue with a new IOx storage engine. " Does this mean that in the end it wasn't really necessary to switch to VictoriaMetrics' offering?

isn't this like their fourth storage engine? doesn't that get old after awhile?

Re: CERN swaps out databases to feed its petabyte-a-day habit

#29

Post by narism »

hintymad wrote: post #15
ComputerGuru wrote: post #13

Missing from the title: leaving InfluxDB and Prometheus for VictoriaMetrics.

This is puzzling. I'm not sure how VictoriaMetrics solved the cardinality problem? When running an aggregate query that sums up some counters for a single metric over the dimension of instances in a time window of larger than a few hours, VictoriaMetrics would barf with error for the querying having too many time series (or data points? I forgot the exact wording). This clearly shows that 1/ Victoria Metrics does not…

There are a number of circuit breakers in VictoriaMetrics that limit the number of time series/datapoints in queries to limit CPU/RAM usage. These can be tweaked with the -search.max* command line flags. I think the default query limits for data points per series are 30M and number of series is 300K.

What do you consider reasonable cardinalities or a true TSDB?

Re: CERN swaps out databases to feed its petabyte-a-day habit

#30

Post by ericb »

qwertox wrote: post #9

At the end of the article it says " InfluxDB said in March this year it had solved the cardinality issue with a new IOx storage engine. " Does this mean that in the end it wasn't really necessary to switch to VictoriaMetrics' offering?

That should read:

InfluxDB said in March this year it had solved the cardinality issue with a new IOx storage engine for it's hosting customers only

There isn't an influxdb that you can download with cardinality solved.

Post reply on HN