So, we need a new database engine instead of mere using tables with partitioning in PostgreSQL with a timestamp as a primary key? And it is Java - waste two times more resources than the data you have ™
OpenTSDB – A Distributed, Scalable Time Series Database
11–20 of 27 posts
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#12Disclosure: I work for Axibase.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#13So, we need a new database engine instead of mere using tables with partitioning in PostgreSQL with a timestamp as a primary key? And it is Java - waste two times more resources than the data you have ™
B+ trees are not optimized for the kinds of write-heavy workloads that you typically stick in HBase (LSM-tree).
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#14It is alot of work to keep up. I would use KairosDB instead. https://kairosdb.github.io/ .
What sort of work are you referring to when you say it's a lot to keep up? We've been using OpenTSDB here in an extremely high traffic setup for about a year now, with absolutely no issues at all. It took a few hours at most to setup and figure out scaling.
If you have a large team of engineers writing data into it, they will sometimes abuse the schema by overloading single metrics with many tags. Every permutation of tag*value creates a new row per hour of data. This creates extremely hot shards when engineers inevitably do something like store a client IP address into a tag. When this happens, you may have to write some web-UI scraping code to figure out which regions are getting the most traffic (assuming you have "extremely high traffic setup" numbers of region servers), or script up something like misra-gries on a tcpdump of its inbound metrics to see where the hot shit is so you can get somebody's deploy reverted. I know of some companies that have forked OpenTSDB and prefixed each row with a hash such that it spreads overloaded metrics around the cluster much more evenly. KairosDB solves this by not using a lexicographically sharded database (Cassandra).
When run properly, it runs great. But that takes some really painful learning experiences to learn how to do, generally.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#15I’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 pre-packaged in a Docker container and can run on a single host — often they’re even a single binary.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#16We'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 (…
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 ev…
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#17If 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…
For problems where you require a single source of truth for high volumes of data, you can't really justify that kind of effort for the data management when distributed databases have been created to solve this problem.
Prometheus is nice and featureful, but it makes me laugh when the proponents (usually [ex-]soundcloud folks) brag about how scalable it is.
Side note: they love to say that because it's pull based, that magically makes it more scalable. This is a crock of shit. Push vs Pull doesn't get you out of capacity planning, and from this perspective they are identical in terms of throughput requirements. Pull means you need a single source to know about a ton of endpoints. Push means you need a ton of sources to know about a single endpoint. Which one is simpler to operate? They say it's more scalable because when they failed to properly do capacity planning, it hid their dropped data more effectively and their dashboards kept running, oblivious to the degredation.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#18The hard part is HBase and to a lesser degree HDFS.. there are just a lot of things to read and learn about, and failure to address one of them will eventually cause interesting struggles. That said, my company looked at the field in 2012 and chose OpenTSDB, and it's handled things well enough considering fairly poor configuration of HBase. We recently reevaluate the space and tried Influx and Karios. Influx fell on its face in several ways that will take years to fully iron out, Kairos trades one set of evil for another, so we decided to do some learning and redeploy OpenTSDB correctly. As far as open source options, it's far ahead in the battle hardened department.
If you want to consider it, I would advise checking out some of the slides/videos on http://www.hbasecon.com/ - these two being the most critical:
* OpenTSDB and AsyncHBase Update
* HBase Performance Tuning @ Salesforce
HBase seems pretty vibrant. There's been a lot of progress with things like WAL shipping and performance tweaks like SSD block caching, off GC heap support, read access from multiple regionservers. OpenTSDB plugs along at a slower pace, but it's much more professional than i.e. Influx changing storage engines 5 time and getting worse with each. The OpenTSDB 2.2 release looks really exciting and fixes some hard high rate problems for both reads and writes: http://opentsdb.net/docs/build/html/new.html#id1
In the commercial space, Circonus looks pretty interesting and comes built and recommended by people I trust. It goes a lot farther than metrics storage. I wasn't able to get my management to do more than a video call to really dig in and evaluate it myself.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#19So, we need a new database engine instead of mere using tables with partitioning in PostgreSQL with a timestamp as a primary key? And it is Java - waste two times more resources than the data you have ™
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…
I think that adding a new indexing strategy to a decent engine could be a good idea.
Informix did this.
Re: OpenTSDB – A Distributed, Scalable Time Series Database
#20Earlier quoted context omitted.
What sort of work are you referring to when you say it's a lot to keep up? We've been using OpenTSDB here in an extremely high traffic setup for about a year now, with absolutely no issues at all. It took a few hours at most to setup and figure out scaling.
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…