TimescaleDB 1.0 Is Production Ready

https://blog.timescale.com/1-0-enterprise-production-ready-time-series-database-open-source-d32395a10cbf

47 18 8 years ago

blog.timescale.com

msiggy• 8 years ago

I'm excited to give this database a try if I can find some free time.

dominotw2• 8 years ago

I evaluated this heavily but had to backoff because scale is limited to a single machine. Really eager for their clustering solution.

RobAtticus5• 8 years ago

Sorry to hear, though I'd like to mention that there is a fair amount of scale you can get out of a single TimescaleDB node. We scale with disk space so you can throw more disks at it; we have production users who are in the hundreds of billions of rows and 10s of TB of data on a single node. Also with support for streaming replication you can spread out your read load and get HA support. But yes, we will have more to say in the coming months about clustering though.

grumpydba• 8 years ago

Hi,

are the upcoming clustering efforts developed with the intent to be mainlined in postgresql ?

Indeed some way to automatically failover/failback (ie automate pg_rewind) without all the keepalived/pacemaker/haproxy/patroni stuff is really needed.

jason_slack• 8 years ago

What were the specs of the machine you were using?

athenot2• 8 years ago

It would be nice if they did a quick comparison to InfluxData and other time series databases.

RobAtticus5• 8 years ago

We do have comparisons, but judging by their Medium read times some may not be considered "quick" :)

* Influx: https://blog.timescale.com/timescaledb-vs-influxdb-for-time-...

* Cassandra: https://blog.timescale.com/time-series-data-cassandra-vs-tim...

* Mongo: https://blog.timescale.com/how-to-store-time-series-data-mon...

We also released a tool called Time Series Benchmark Suite (TSBS) here that someone just submitted a PR for Clickhouse: https://github.com/timescale/tsbs/pull/26

There is also this spreadsheet that compares a bunch of different time series databases, including TimescaleDB: https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCE...

Hopefully some of that is useful :)

athenot2• 8 years ago

Thanks a lot, this is useful for comparing.

Edit: did a quick search and the discussion for the first link is here: https://news.ycombinator.com/item?id=17766566

zip1234• 8 years ago

How fast is it when it has a TB of data? I realize that this is affected by the machine it is running on, but just curious how long those sample queries in the docs would take to run.

nevi-me• 8 years ago

I spent about 8 months writing data to TSDB. I was sending about 200 vehicle locations per 7-10 seconds for most of the day. I guess around 1 million events per day.

I played around with the data in the first week of setting it up, but then I ignored the feed for months.

When I came back on the 8th month, I couldn't get many/most queries to run in decent time. I didn't diagnose the issue, but I stopped the data stream and archived the database. My data was around 100GB, and I was reading it from a server-grade HDD. (I'll update my answer if I can find more accurate details when I get home).

I don't think it was a TSDB issue, might have been on my side. If I can restore my old data into a fresh DB, I'm going to try TSDB again with the data. I'm doing a Stats degree part time, so it'd be interesting to apply some forecasting knowledge to my dataset.

dominotw2• 8 years ago

They have some numbers on their blog. Its very fast but I think their tests was both index and data in memory.

sman3933• 8 years ago

Can this be used side by side on normal Postgres cluster? As in could I have one DB for app data, and one for metrics data? Considering switching from MySQL (ndb cluster) to running a Postgres cluster and this could be a good motivator.

RobAtticus5• 8 years ago

Yep, absolutely. Regular PostgreSQL tables coexist alongside TimescaleDB (hyper)tables in the same database. We believe that's actually a pretty big plus since you can keep metadata that you may need to join on your metrics data without doing it in an application layer.

sman3933• 8 years ago

Good to hear! how does the current TimescaleDB single node limitation play into it?

valyala• 8 years ago

TimescaleDB is great for storing time series comparing to vanilla ProstgreSQL!

Unfortunately it sometimes looses in storage cost-effectiveness comparing to competing TSDBs - https://medium.com/@valyala/when-size-matters-benchmarking-v...

TimescaleDB 1.0 Is Production Ready

Related Stories