ListenBrainz moves to TimescaleDB • Hacker News Board

Re: ListenBrainz moves to TimescaleDB

#91

Post by silvester23 » Thu, Jul 23, 2020, 10:58 AM UTC

samhld wrote: post #54

sgt wrote: post #43

Earlier quoted context omitted.

Ok, we had an issue deleting data from a series. The delete just hung and never completed. I assumed this was not really possible on Influx. Perhaps this is an edge case.

(Solution architect at InfluxData here) Out of curiosity...what was the need for this DELETE? Deleting (not dropping) being somewhat of a "second class citizen" was a design choice to make room for more pressing time series needs. In my experience, `DELETE`ing is rarely necessary.

We work a lot with forecast data and sometimes mistakes happen and a forecast gets written to the wrong time series or for the wrong period. In these cases we do not want to drop the complete time series but only delete the erroneous parts.

While it is indeed a rare occurence, it is also very slow.

Re: ListenBrainz moves to TimescaleDB

#92

Post by iEchoic » Thu, Jul 23, 2020, 1:03 PM UTC

Has anyone used Prometheus as well as TimescaleDB in production and have thoughts to share on those, comparatively?

Re: ListenBrainz moves to TimescaleDB

#93

Post by justinclift » Thu, Jul 23, 2020, 2:08 PM UTC

akulkarni wrote: post #45

justinclift wrote: post #35

Earlier quoted context omitted.

It seems to be affecting multiple people too. :(

That issue is now closed by the original author: "Data is successfully dumped. also i can see the constraints, indexes are also copied successfully." https://github.com/timescale/timescaledb/issues/1835

Cool. :)

Re: ListenBrainz moves to TimescaleDB

#94

Post by 1996 » Thu, Jul 23, 2020, 3:46 PM UTC

fiddlerwoaroof wrote: post #74

1996 wrote: post #66

Earlier quoted context omitted.

> InfluxDB is purely proprietary (paid, closed source). And clickhouse is not. I just suggest skipping the timescaledb step to someone migrating from influx, and going straight to clickhouse. > For the TSL version, what it primarily restricts is the cloud providers like AWS and Azure from offering TimescaleDB-as-a-service (e.g., TimescaleDB Community on AWS RDS) If there is some kind of emergency and I need to have t…

Apart from license issues, Clickhouse is just really impressive: it’s a minor pain operationally, but in our tests it left all the Postgres-based timeseries solutions in the dust for real-time analytics without rollup tables.

> Clickhouse is just really impressive: it’s a minor pain operationally, but in our tests it left all the Postgres-based timeseries solutions in the dust for real-time analytics without rollup tables

There are many things I'm willing to tolerate with that level of performance!

Re: ListenBrainz moves to TimescaleDB

#95

Post by akulkarni » Fri, Jul 24, 2020, 11:38 PM UTC

iEchoic wrote: post #92

Has anyone used Prometheus as well as TimescaleDB in production and have thoughts to share on those, comparatively?

We have quite a few in our Slack channel: slack.timescale.com

Feel free to ask over there :)

(Btw - TimescaleDB is designed to work with Prometheus. You can see more here: https://github.com/timescale/timescale-prometheus)

Re: ListenBrainz moves to TimescaleDB

#96

Post by osigurdson » Tue, Jul 28, 2020, 5:10 AM UTC

In some cases it is difficult to define the table columns up front. Instead, a few tables: Object, Property, Time and Value (example below) are defined which make it possible to create new items on the fly. This works reasonably well up to a few billion records in the value table. However it does end up taking a lot of space (covering indexes/requisite memory are required for performance). It would be great to see a Postgres compatible solution that solves this problem in a more optimal way than a stock RDMS.

Object objectId objectName other...

Property propertyId objectId FK propertyName other...

Time timeId time other..

Value timeId FK propertyId FK value

Re: ListenBrainz moves to TimescaleDB

#97

Post by valyala » Tue, Jul 28, 2020, 4:14 PM UTC

1996 wrote: post #41

RedShift1 wrote: post #39

Earlier quoted context omitted.

Can you elaborate on those issues?

It would be too long. To quickly summarize, from the pain of backups (unless you setup a WAL replica, the load may take your database down), the large size of the data on disk (timescale does offer some compression now, but it's still too much), the low performance of large queries, the memory requirements - it's death by a thousand papercuts! Don't get me wrong, timescale is a great way to get started with time seri…

Did you try VictoriaMetrics for storing time series data? This is specialized high-performance time series database, which is based on ClickHouse ideas [1].

[1] https://medium.com/@valyala/how-victoriametrics-makes-instan...

Re: ListenBrainz moves to TimescaleDB

#98

Post by valyala » Tue, Jul 28, 2020, 4:24 PM UTC

gregors wrote: post #76

We too started off with influx but it wasn't a good fit mainly due to use having issues with high cardinality. I don't know if this is still the case with current implementations, but what it boils down to is if your data is searchable by a "user_id" really look elsewhere. That might be an oversimplification but that's the gist of it. I was fully ready to just roll my own partitioned table and gave TimescaleDB a shot…

If you have cardinality issues in InfluxDB, then just substitute InfluxDB with VictoriaMetrics :) [1]

[1] https://medium.com/@valyala/insert-benchmarks-with-inch-infl...

Re: ListenBrainz moves to TimescaleDB

#99

Post by valyala » Tue, Jul 28, 2020, 4:32 PM UTC

decafninja wrote: post #78

As someone who wants to pick up a time series DB to learn, what would be the best in terms of being the "industry standard"? InfluxDB? TimescaleDB? I'm familiar with some basics of kdb and use it often in my day job, but from what I understand that isn't widely used outside of finance?

The following time series databases are popular right now:

* ClickHouse (this is a general-purpose OLAP database, but it is easy to adapt it to time series workloads)

* InfluxDB

* TimescaleDB

* M3DB

* Cortex

* VictoriaMetrics

The last three of these TSDBs support PromQL query language - the most practical query language for typical time series queries [1]. So I'd recommend starting from learning PromQL and then evaluating time series databases from the list above.

[1] https://medium.com/@valyala/promql-tutorial-for-beginners-9a...

Re: ListenBrainz moves to TimescaleDB

#100

Post by jarym » Sat, Aug 01, 2020, 8:13 PM UTC

enordstr wrote: post #81

jarym wrote: post #60

Earlier quoted context omitted.

Have you been following ZHeap and do you think Timescale will benefit from a storage engine like that (less write amplification)?

Another Timescale engineer here. As previously pointed out, zheap should work as a drop-in in TimescaleDB. In fact, I just tried it and it works. However, it currently requires an unmerged PR to work properly: https://github.com/timescale/timescaledb/pull/2082 , as well as further testing.

Nice! Thanks. Postgres is just amazing in so many respects. The work you guys do contribute to that.