I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up. https://github.com/timescale/timescaledb/issues/1835
That seems like a pretty big deal.
Does a WAL backup approach work?
ListenBrainz moves to TimescaleDB
31–40 of 100 posts
Re: ListenBrainz moves to TimescaleDB
#32> If you ever write bad data to a measurement in InfluxDB, there is no way to change it Correct me if I'm wrong, but I'm fairly certain you can just write data with the same timestamp again and it gets updated. Deleting is also easily possible.
You can't for example delete data from a time period to another, to the best of my knowledge.
This is actually pretty straightforward. For example,
`DELETE FROM "foo" WHERE time >= now() - 2d AND time < now() - 1d`
Re: ListenBrainz moves to TimescaleDB
#33I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up. https://github.com/timescale/timescaledb/issues/1835
That seems like a pretty big deal. Does a WAL backup approach work?
TimescaleDB offers a number of backup and restore options, including wal-e (WAL-based), pg_dump & pg_restore:
https://docs.timescale.com/latest/using-timescaledb/backup
There are hundreds of thousands of TimescaleDB databases in production so this is generally not an issue.
Re: ListenBrainz moves to TimescaleDB
#34Fun fact: TimescaleDB exists because we were using InfluxDB + Postgres for a previous IoT project and also found it unworkable (developer experience, query language, reliability, scalability and performance, operations, etc). We first built TimescaleDB as "Postgres for time-series" for our own needs and then decided to open-source it for others. :-)
Have you thought of making a TimescaleDB app like the Postgres.app for macOS? Or could I use Postgres.app to make a TimescaleDB app?
[deleted]
Re: ListenBrainz moves to TimescaleDB
#35I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up. https://github.com/timescale/timescaledb/issues/1835
TimescaleDB definitely supports backups :-) Here is a page from our docs on how to perform Backup & Restore: https://docs.timescale.com/latest/using-timescaledb/backup Not sure what's going on in that one Github issue, but we are looking into it.
It seems to be affecting multiple people too. :(
Re: ListenBrainz moves to TimescaleDB
#36Earlier quoted context omitted.
I'm personally working on migrating a DB I've had for tracking some economic time-series data from Influx to TimescaleDB, and I have to say Outflux is the most savage tool name ever.
One of our designers teamed up with one of our web developers, went away for a week, and came back with this website for it: https://www.outfluxdata.com/
It's missing some kind of wavy background thing in the hero section.
Re: ListenBrainz moves to TimescaleDB
#37I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up. https://github.com/timescale/timescaledb/issues/1835
This issue is related to slightly confusing _warnings_ that the software prints out, it doesn't effect the _correctness_ of the backups.
The warnings are produced by COPY TO, which is used by pg_dump, since COPY TO doesn't copy chunks. It is not an issue for pg_dump, since it also do COPY TO on each chunk table.
Timescale engineer here - was part of discussion about this warning. We need to do another round and see how to remove this confusion.
Re: ListenBrainz moves to TimescaleDB
#38I'm in the process of moving from InfluxDB to TimescaleDB myself and can't wait to get rid of the hoops I have to jump through to get InfluxDB to answer some basic questions, mostly stemming from the fact that InfluxQL doesn't support boolean expressions. Something like 'SELECT MAX(temperature) > 10 FROM...' doesn't work.
Speaking from my own experience, you may save yourself some future effort by moving directly to clickhouse.
Timescale brings its own issues. If your goal is performance, you will be better served by clickhouse.
Re: ListenBrainz moves to TimescaleDB
#39I'm in the process of moving from InfluxDB to TimescaleDB myself and can't wait to get rid of the hoops I have to jump through to get InfluxDB to answer some basic questions, mostly stemming from the fact that InfluxQL doesn't support boolean expressions. Something like 'SELECT MAX(temperature) > 10 FROM...' doesn't work.
Speaking from my own experience, you may save yourself some future effort by moving directly to clickhouse. Timescale brings its own issues. If your goal is performance, you will be better served by clickhouse.
Can you elaborate on those issues?
Re: ListenBrainz moves to TimescaleDB
#40Fun fact: TimescaleDB exists because we were using InfluxDB + Postgres for a previous IoT project and also found it unworkable (developer experience, query language, reliability, scalability and performance, operations, etc). We first built TimescaleDB as "Postgres for time-series" for our own needs and then decided to open-source it for others. :-)
Have you thought of making a TimescaleDB app like the Postgres.app for macOS? Or could I use Postgres.app to make a TimescaleDB app?
You can mount like any PostgreSQL version, including extensions, in Postgres.app. I’ve used both Timescale and Agens with it, with zero problems.