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

ListenBrainz moves to TimescaleDB

blog.metabrainz.org

Post reply on HN
Print view View original

11–20 of 100 posts

Re: ListenBrainz moves to TimescaleDB

#11

Post by iliekcomputers »

mfreed wrote: post #9
ilogik wrote: post #6

Earlier quoted context omitted.

https://github.com/metabrainz/listenbrainz-server/blob/b0846...

Thanks. I love developer comments -- we've all written things like "this is hacky and ugly" in our code :) # Note: influxdb-python first replaces each backslash in the username with two backslashes # and because in influx queries, we have to escape each backslash, overall each backslash # must be replaced by 4 backslashes. Yes, this is hacky and ugly.

I wrote that comment 3 years ago! It definitely took me a week or two worth of work to figure out what was happening there. The problem was exacerbated by the fact that the influx cli client then had different behaviour compared to the python client. Not sure if that has been fixed, but this isn't code that I'm really proud of. :D

Re: ListenBrainz moves to TimescaleDB

#13

Post by silvester23 »

iliekcomputers wrote: post #10
silvester23 wrote: post #4

> 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.

ListenBrainz dev here. We wanted stuff like the ability to do stuff like "DELETE FROM measurement where field = blah" and that support didn't exist last time we looked. [0] Another thing that's not mentioned in the post but was a pain point for us was that it's not easy to query for fields with "null" values [1]. I figure a lot of our pain might be because we're not as good at Influx as we are at PostgreSQL. We've be…

True, deleting by value does not seem to be possible. I can see how that would be painful if it's necessary for your use case.

Re: ListenBrainz moves to TimescaleDB

#14

Post by paol »

iliekcomputers wrote: post #12

Hey! I've been working on ListenBrainz [0] for the past 3-ish years. Happy to answer questions if anyone has any. [0]: https://listenbrainz.org

Excited to find out about the project. I regularly use MusicBrainz but didn't know about the sister projects.

I'll definitely be creating a ListenBrainz account. As a long time last.fm user I occasionally worry about the future of the platform. (There have been long stretches of time where it seems to have been in maintenance mode). You seem to support bulk importing last.fm data right?

Re: ListenBrainz moves to TimescaleDB

#15

Post by iliekcomputers »

paol wrote: post #14
iliekcomputers wrote: post #12

Hey! I've been working on ListenBrainz [0] for the past 3-ish years. Happy to answer questions if anyone has any. [0]: https://listenbrainz.org

Excited to find out about the project. I regularly use MusicBrainz but didn't know about the sister projects. I'll definitely be creating a ListenBrainz account. As a long time last.fm user I occasionally worry about the future of the platform. (There have been long stretches of time where it seems to have been in maintenance mode). You seem to support bulk importing last.fm data right?

Yep, we do support bulk import of last.fm data [0].

We also have a Spotify importer that automatically imports stuff from Spotify, if you use Spotify, I would definitely recommend setting that up.

We're a really small team (all volunteers), so we don't move with as much urgency as I'd like to, but we've been making slow but steady progress over the years.

If you find any rough edges, or have any feedback, I'd be happy to hear, my email is in the HN profile. :)

[0]: https://listenbrainz.org/profile/import

Re: ListenBrainz moves to TimescaleDB

#16

Post by akulkarni »

(TimescaleDB co-founder). Thanks for the kind words! I feel especially proud about the first point "openness" - this is something we strive for both technically and culturally.

For example, we have a pretty active Slack channel[0] where you can ask us anything. We've probably given away $$$$ of free support over the years ;-)

[0] https://slack.timescale.com/

Re: ListenBrainz moves to TimescaleDB

#17

Post by contravariant »

hoseja wrote: post #3
pgt wrote: post #2

+1 on escaping measurement names. Quoting from their source code: def get_escaped_measurement_name(user_name): # ... comment omitted return '"\\"{}\\""'.format(user_name.replace('\\', '\\\\\\\\').replace('"', '\\"').replace('\n', '\\\\\\\\n'))

That looks somehow worse than regex in C literal.

Although it seems about par for the course for regexp in elisp.

Re: ListenBrainz moves to TimescaleDB

#18

Post by RedShift1 »

I'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.

Re: ListenBrainz moves to TimescaleDB

#19

Post by mfreed »

Fun 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. :-)

Re: ListenBrainz moves to TimescaleDB

#20

Post by dionian »

iliekcomputers wrote: post #11
mfreed wrote: post #9

Earlier quoted context omitted.

Thanks. I love developer comments -- we've all written things like "this is hacky and ugly" in our code :) # Note: influxdb-python first replaces each backslash in the username with two backslashes # and because in influx queries, we have to escape each backslash, overall each backslash # must be replaced by 4 backslashes. Yes, this is hacky and ugly.

I wrote that comment 3 years ago! It definitely took me a week or two worth of work to figure out what was happening there. The problem was exacerbated by the fact that the influx cli client then had different behaviour compared to the python client. Not sure if that has been fixed, but this isn't code that I'm really proud of. :D

We all have code like that somewhere :)
Post reply on HN