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

OpenTSDB – A Distributed, Scalable Time Series Database

opentsdb.net

Post reply on HN
Print view View original

21–27 of 27 posts

Re: OpenTSDB – A Distributed, Scalable Time Series Database

#21

Post by kev009 »

dschiptsov wrote: post #19
rodionos wrote: post #11

Earlier quoted context omitted.

Not sure if your Java comment is warranted, a lot of Apache projects are either written in Java or run on JVM. Yes, HBase's memstore can be optimized, in particular for small key values, but that doesn't negate a need for time-series databases with proven scaling. HDFS offers that. How you were planning to design your tables in PostreSQL if you have 1m+ unique series inserting at 100K+/sec. Assuming you use timestamp…

We have already seen how Cassandra clone in C++ perform. I think that adding a new indexing strategy to a decent engine could be a good idea. Informix did this.

Mapr has an HBase compatible stack in C++, I would love to see TSDB numbers on that. TSDB is pretty efficient itself and since metrics collection is such a batchy operation JVM isn't really that much of a problem. You can run some dedicated TSDs for front end/UIs to ameliorate JVM pain there too.

Re: OpenTSDB – A Distributed, Scalable Time Series Database

#22

Post by rodionos »

dschiptsov wrote: post #19
rodionos wrote: post #11

Earlier quoted context omitted.

Not sure if your Java comment is warranted, a lot of Apache projects are either written in Java or run on JVM. Yes, HBase's memstore can be optimized, in particular for small key values, but that doesn't negate a need for time-series databases with proven scaling. HDFS offers that. How you were planning to design your tables in PostreSQL if you have 1m+ unique series inserting at 100K+/sec. Assuming you use timestamp…

We have already seen how Cassandra clone in C++ perform. I think that adding a new indexing strategy to a decent engine could be a good idea. Informix did this.

Do you mean Informix Time-Series Extension? It's been around for a while so maybe there are existing things that came out of IBM recently. Last time I checked its schema it was basically storing serie as a blob not unlike OPC historians like Pi.

Re: OpenTSDB – A Distributed, Scalable Time Series Database

#23

Post by nanoojaboo »

krenoten wrote: post #17
secure wrote: post #15

If you’re looking into time-series based monitoring/alerting, I’ve been delighted with http://prometheus.io/ . I’m mentioning this because I previously tried to use OpenTSDB for monitoring (back when prometheus and others didn’t exist), and found it too cumbersome to run (not packaged in Debian, requires an underlying HBase instance, etc.) for my taste. Many more recently created projects, such as Prometheus, come pr…

Prometheus is for smaller problems. You have to manage your own sharding with prometheus, so it doesn't work for handling large volumes of data unless you are willing to do complex automation for a large number of disparate replication topologies. This works fine at Soundcloud, where it came from, because the teams there like keeping their monitoring systems isolated from each other because they don't trust each othe…

I always see Prometheus/SoundCloud developers on here or elsewhere promoting their free product. What benefit do they get if not financial? (modest fame, self-satisfaction that their product's being used etc)

Re: OpenTSDB – A Distributed, Scalable Time Series Database

#25

Post by freezey00 »

I have been reading a lot of these comments here and some of the people who ran into issues just sound like they don't understand what they were using or building. As many have said before opentsdb is great if you understand all of your components. Hbase is somewhat of a black art. You also truly need to understand your data. You cannot just start writing data and when it fails be upset with the product. Opentsdb is no silver bullet to the metrics game but it sure as hell is better than most at a larger scale.

We are doing right now roughly 1.2m/s and will likely grow to 6-8 depending on how we chop this up. Either way you have to use any level of intelligence with this product as you do with others. I cannot stress this enough but plan out your data. Make sure you are very strict with the pattern of how things get written and the amount of tags you allow. No datapoint will initially make sense for you you may have to shift things around a bit. There is an active PR collectd that addresses metric mapping which can be very beneficial to high throughout shops.

Either way just make sure you know what you are getting into and understand your problem as well as your product you are choosing. Opentsdb could be overkill for people who just want a low amount of data per second. You will also need to plan retention policies / long term storage / hardware requirements / etc. remember you are running hbase.

Re: OpenTSDB – A Distributed, Scalable Time Series Database

#27

Post by krenoten »

kev009 wrote: post #20
krenoten wrote: post #14

Earlier quoted context omitted.

I love OpenTSDB, but I think it's highly unusual for people to have "absulutely no issues at all". I ran OpenTSDB at the hundreds of thousands to low millions of ops per second range for several years. OpenTSDB has historically crapped itself when you have writes hit it for rows that it already ran its all-columns-for-an-hour-into-a-single-column compaction on. Now it just drops data on reads. If you have a large tea…

OpenTSDB 2.2 has this hot region problem fixed with salted UIDs.

Badass! This would have saved me about a week of my life if it had come a few years ago!
Post reply on HN