Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

> Have a read about the design intent and architecture to get deeper info on how it's different - but basically, indexes aren't retained locally

Would appreciate if you refer to link where this explained. But from what I was able to find, both Mimir and Prometheus store indexes within data blocks. It doesn't matter where data blocks are: locally or on S3. Because you still need to read the index and fit it in the memory in order to locate the needed data. So I don't understand how S3 helps here, unless you run an additional store-gateway which does this job instead.

> but Mimir was designed to handle much more data than Prometheus was

Do you have any numbers to refer? Isn't Mimir based on Prometheus source code? The storage, indexes, query engine - that should be the same or mostly the same. I'd be really surprised if Mimir could outperform significantly Prometheus in monolithic mode.

If I understood correctly, the whole "Mimir was designed to handle" is related to microservice architecture, to its horizontal scaling capabilities and ability to shard read queries across multiple components.



Sure, no problem - I typed 'mimir architecture' into my search engine to get the link I was thinking of:

https://grafana.com/docs/mimir/latest/get-started/about-graf...

Perhaps indexes wasn't the optimum word. There's some references to Prometheus' memory usage if you go looking, typically if you're searching around 'why does prometheus use so much memory'.

I'm struggling to find the comparative metrics on capacity that you're seeking, though I do recall seeing them previously, and having run up multiple prometheus instances (in vanilla and agent-mode) and fed those into mimir, I'm aware that prom has some non-negotiable limits on time series.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: