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

M3DB, a distributed timeseries database

m3db.io

Post reply on HN
Print view View original

121–130 of 138 posts

Re: M3DB, a distributed timeseries database

#121

Post by cube2222 »

sagichmal wrote: post #117
cube2222 wrote: post #74

Earlier quoted context omitted.

This was as of november. Raw Prometheus: Isn't able to hold my data. Thanos: I liked the project, it's architecture and ease of deployment, but after spending a non-trivial amount of time with it I wasn't able to setup any long-term caching. Thanos uses the prometheus storage format. So whenever I was querying one metric, it was downloading all metrics which were in the same block (all metrics basically afaik), this…

> Victoria Metrics: As far as I know it's very well engineered and performs great As someone who has auditioned it, briefly, let me assure you that it is certainly not the former, and only appears to be the latter due to a lot of cut corners and spec-violating implementations.

Could you elaborate on the specifics? I'd be very interested.

Re: M3DB, a distributed timeseries database

#122

Post by idjango »

roskilli wrote: post #81
mbell wrote: post #72

Earlier quoted context omitted.

Most practical applications using Clickhouse for metrics data store the metric index separately. What index you want really depends on the metric system, e.g. with graphite data you don't want an inverted index, you want a trie.

Yes I've seen that also work, it's a lot of stitching together things yourself and we had to put a lot of caching in front of the inverted index we were using, however definitely plausible. ClickHouse doesn't do any streaming of data between nodes as you scale up and down which was a big thing for us since we had large datasets and needed to rebalance when cluster expanded/shrunk. With regards to trie vs inverted ind…

Just to point out that there is inverted index implementation of graphite data working on clickhouse.

Regarding the auto-rebalance feature, I cannot much more agree with you. It's something that clickhouse definitely need to handle internally.

Re: M3DB, a distributed timeseries database

#123

Post by opsunit »

StreamBright wrote: post #114
richieartoul wrote: post #4

Earlier quoted context omitted.

Chronosphere, a startup founded by two of the early M3 engineers, just raised 11 million dollars to build a monitoring platform based around M3DB: https://techcrunch.com/2019/11/05/chronosphere-launches-with... Uber also uses M3DB extensively internally and the project is nowhere near being abandoned or on life support: https://github.com/m3db/m3/commits/master

>> While the founders, CEO Martin Mao and CTO Rob Skillington, were working at Uber, they recognized a gap in the monitoring industry, particularly around cloud-native technologies like containers and microservices What is the actual gap that is not addressed with one or all of the following? - Prometheus / Grafana [1] - Datadog [2] - Cloudwatch [3] 1. https://docs.docker.com/config/thirdparty/prometheus/ 2. https://…

Wavefront: https://www.wavefront.com/

Re: M3DB, a distributed timeseries database

#124

Post by Udik »

gtirloni wrote: post #5
missosoup wrote: post #2

Uber has started many projects that ended up getting open sourced. And many of them are now either abandoned or on life support. H3 comes to mind as something we almost ended up using but luckily avoided. These open-sourcings seem a bit like PR pieces with no guarantees of any support or evolution after being published.

It's opensource. Why should Uber give any guarantees? They are not in the business of selling software. Unless Uber is actively blocking contributions, it's not Uber's fault if no community formed around something they opensourced. As for this being a PR piece, they could have achieved the same with just a detailed blog post and no code. It looks like a expensive PR piece if they have to opensource work that took pro…

> They are not in the business of selling software.

But they are probably in the business of selling themselves as a software/ tech company. People value tech companies, so you'd better be one, even if you do taxi services, produce and distribute tv series, or rent office space.

Re: M3DB, a distributed timeseries database

#125

Post by ForHackernews »

reichardt wrote: post #3
missosoup wrote: post #2

Uber has started many projects that ended up getting open sourced. And many of them are now either abandoned or on life support. H3 comes to mind as something we almost ended up using but luckily avoided. These open-sourcings seem a bit like PR pieces with no guarantees of any support or evolution after being published.

Why do you consider H3 to be on life support? It's basically a finished spec with actively developed implementations. https://github.com/uber/h3

So is Gopher, but almost nobody uses it.

Re: M3DB, a distributed timeseries database

#126

Post by bboreham »

cube2222 wrote: post #74
hagen1778 wrote: post #55

Earlier quoted context omitted.

Since you've done your research, would you mind to post a short list of alternatives and reasons why have they been rejected? Thanks!

This was as of november. Raw Prometheus: Isn't able to hold my data. Thanos: I liked the project, it's architecture and ease of deployment, but after spending a non-trivial amount of time with it I wasn't able to setup any long-term caching. Thanos uses the prometheus storage format. So whenever I was querying one metric, it was downloading all metrics which were in the same block (all metrics basically afaik), this…

Cortex has a design much more like M3DB than Thanos; I wouldn’t expect the same problems as Thanos at all.

(I am a Cortex maintainer)

Re: M3DB, a distributed timeseries database

#127

Post by valyala »

1996 wrote: post #88
buro9 wrote: post #12

Earlier quoted context omitted.

It's a database for a metric platform. Think of OpenTSDB and Prometheus. Or for a better comparison think of Thanos https://thanos.io/ As to whether they could fulfil Uber's needs, the thing about scale (real massive scale - I work at Cloudflare) is that everything breaks in weird ways according to your specific uses of a technology. The things listed above work for companies, until they don't. There's few things tha…

> ClickHouse come to mind for wholly different use cases than a time series database. ClickHouse works fine as a TSDB if you don't mind getting a little dirty

There is a TSDB solution if you don't want getting a little dirty - VictoriaMetrics [1]. It is built on the same principles as ClickHouse [2].

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...

[2] https://medium.com/@valyala/how-victoriametrics-makes-instan...

Re: M3DB, a distributed timeseries database

#128

Post by nwsm »

StreamBright wrote: post #114
richieartoul wrote: post #4

Earlier quoted context omitted.

Chronosphere, a startup founded by two of the early M3 engineers, just raised 11 million dollars to build a monitoring platform based around M3DB: https://techcrunch.com/2019/11/05/chronosphere-launches-with... Uber also uses M3DB extensively internally and the project is nowhere near being abandoned or on life support: https://github.com/m3db/m3/commits/master

>> While the founders, CEO Martin Mao and CTO Rob Skillington, were working at Uber, they recognized a gap in the monitoring industry, particularly around cloud-native technologies like containers and microservices What is the actual gap that is not addressed with one or all of the following? - Prometheus / Grafana [1] - Datadog [2] - Cloudwatch [3] 1. https://docs.docker.com/config/thirdparty/prometheus/ 2. https://…

Logging / Monitoring is the hottest market to disrupt right now.

Re: M3DB, a distributed timeseries database

#129

Post by roskilli »

idjango wrote: post #122
roskilli wrote: post #81

Earlier quoted context omitted.

Yes I've seen that also work, it's a lot of stitching together things yourself and we had to put a lot of caching in front of the inverted index we were using, however definitely plausible. ClickHouse doesn't do any streaming of data between nodes as you scale up and down which was a big thing for us since we had large datasets and needed to rebalance when cluster expanded/shrunk. With regards to trie vs inverted ind…

Just to point out that there is inverted index implementation of graphite data working on clickhouse. Regarding the auto-rebalance feature, I cannot much more agree with you. It's something that clickhouse definitely need to handle internally.

That's interesting, I had not heard of ClickHouse as a backend for Graphite with an inverted index. Let me know if you have any links to that.

I'm assuming this is an out of process inverted index used alongside ClickHouse? Or is it more of a secondary table contained by ClickHouse which can be searched to find the metrics, then the data is looked up?

The latter scales not as well with billions of unique metrics since it's always a scan across the unique metrics stored in the time window your query searches for (since any arbitrary dimensions can be specified, all must be evaluated). This is the drawback of PromHouse which is an implementation of Prometheus remote storage on top of ClickHouse - and the major reason why PromHouse was only ever a proof of concept rather than a production offering.

Re: M3DB, a distributed timeseries database

#130

Post by cerberusss »

iamleppert wrote: post #111
jjeaff wrote: post #96

Earlier quoted context omitted.

There seems to be a pervasive misconception by the very employees at Uber, that they built their own chat platform. When in reality, and someone please correct me if I am wrong, uChat was a white labeled Mattermost. I have heard that the team that put it together actually tried to hide that fact from the company (for the glory, I guess). But that could be apocryphal.

Why not just use IRC?? It scaled for the entire internet.

These IRC replacements do more than that. There are voice and video calls, integrated file sharing, and a whole bunch of tools that you can add.

To be honest, I don't much like Slack because I feel the desktop app doesn't feel like a real macOS app. And I don't use all these features. So in the end, IRC would be fine for me. But it wouldn't for the rest of the company.

Post reply on HN