31–40 of 57 posts
I looked at some of the alternatives to victoriametrics for Prometheus and they all seem… much much worse…
One of my fondest memories as a summer student at CERN in 1993 (in the Electronics and Computing for Physics department) was the visit to the basement beneath the main computing facility, where a colossal tape robot was in operation. Even at that time, CERN was grappling with exceedingly vast amounts of data.
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?
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…
If I understand this correctly, it deals with high cardinality by dropping data. The operators need to monitor for this and adjust their data to lower the cardinality.
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…
I've personally found InfluxDB more user-friendly than Prometheus for metrics work, since I've used both at scale and compared my own experiences. The industry leans towards Prometheus nowadays, so I'm used to dealing with Prometheus, but I've found PromQL particularly unpleasant for any kind of complex aggregations. You may disagree, and that's okay. Regular SQL seems far nicer to me in comparison, so it's nice to see Influx v3 focusing on that. I wish Prometheus and VM would develop a standard SQL interface.
VictoriaMetrics doesn't fully support PromQL either; its MetricsQL is only about 73% compatible according to this article[0] that the VM docs link to. I certainly hope that VM took this incompatibility and used it as an opportunity to make MetricsQL more enjoyable to use than PromQL.
[0]: https://medium.com/@romanhavronenko/victoriametrics-promql-c...
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.
https://www.influxdata.com/blog/the-plan-for-influxdb-3-0-op...
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