Hacker News Reader

Comment by necubi | Hacker News Reader

We've been running OpenTSDB at a very large scale (~100k writes/s) for the past year and a half and have been pretty happy with it. It's not as reliable on the read side as something like ganglia and the query options aren't as powerful as InfluxDB, but it can scale better than any other option I know of.

The ability to look back into the past and get full-resolution metrics is a huge deal. With Ganglia or Graphite (which aggressively downsample old data) there's a lot of squinting to try to make out patterns past a week or so.

That said, we also use HBase as our main data store, so we have a lot of experience with operating it. I'm not sure I could recommend OpenTSDB to an organization that lacks that expertise.

View on HN

If you were to create an application that relies heavily on a time series database, what would you recommend?

I'm writing an application of this sorts, and my requirements won't be too bad (about 1000-4000 metrics on a per second basis). I will also rely heavily on predefined queries (rollups to 10s, 1m, 10m, 1h, etc.).

I'm hesitant to use OpenTSDB because the community "buy-in" seems to be going down.

EDIT: I can't lose data to downsampling. I will need to store this for both troubleshooting and regulatory purposes.

If it's just a few streams at high frequency, my take would be to bucket it (eg every second or something) and stick it on your favorite database. You could use postgres arrays, the json columntype, or frankly just a blob in those rows containing all the data for a second.

You can then write some simple postgres queries to create the views your talking about and won't have to mess with any of the "look what I wrote last week" "databases".

I wouldn't worry too much about what the community thinks. TSDB fits the bill and works great. That being said, I've also heard wonderful things about druid.io (http://druid.io/), however I've yet to personally try it. We're going to start testing and throwing data at druid early next year though.

Can you talk a little bit about how many nodes it takes to maintain that write rate? We have our own system that's currently handling around 1% of that on a single node, with decent headroom but I've been looking for ways to distribute it. Certainly word on the street is that OpenTSDB performance is not good, at least relative to the resources you throw at it; however since it's based on HBase you can keep scaling even if it's expensive.

The price performance curve is bad at low traffic, but pretty good compared to most other things out there at the higher end of things.

Reply on news.ycombinator.com