ListenBrainz moves to TimescaleDB

154 点作者 kingkool68将近 5 年前

15 条评论

mfreed将近 5 年前

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

评论 #23917848 未加载

评论 #23920122 未加载

120bits将近 5 年前

Interesting read and thanks for sharing.Not too long ago, I was asked to work on some analytics project and it required time-series data. I'm not a rockstar programmer and don't really know much about trends. So, I ended up googling and stumble upon InfluxDB. It felt like that right choice and I started playing with it. As the time passed, I realized that it might be a good software and I'm sure people love InfluxDB, but it wasn't the right choice for me. I didn't really like the docs, maybe its good now. And I had the same feeling about query syntax, it felt weird.I moved to TimescaleDB and never looked back. I have it production for almost 2 months now. 20 tables and over 100Million writes/week. One of things I really liked was staging, I don't use docker and or anything fancy. I have bash script that and it runs on centos box and all timescale extension and postgres database are packaged together.I was impressed by the timescale compression feature. I wasn't using it earlier because I had to be careful about what columns I need to segmentby. I would love to see some more features but I'm sure timescaledb team is already on it.

评论 #23919219 未加载

评论 #23922679 未加载

pgt将近 5 年前

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

评论 #23916279 未加载

评论 #23916156 未加载

评论 #23916255 未加载

iliekcomputers将近 5 年前

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

评论 #23916468 未加载

评论 #23918941 未加载

RedShift1将近 5 年前

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.

评论 #23917435 未加载

评论 #23917320 未加载

评论 #23918411 未加载

评论 #23919529 未加载

评论 #23922688 未加载

akulkarni将近 5 年前

(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] <a href="https://slack.timescale.com/" rel="nofollow">https://slack.timescale.com/</a>

gregors将近 5 年前

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. It worked well. There was a bug we ran into, but it was an existing one documented on github and was addressed pretty quickly.I still like influx, and would use it again but beware of the cardinality issues.

评论 #23977388 未加载

awinter-py将近 5 年前

timescale is a postgres extension. 'postgres as a platform' is an interesting world to live in.postgres built-in RBAC is clunky or people would be relying on it, but an ecosystem of postgres plugins could include cleaner or smaller versions of this feature.Even things like complex migrations (github's gh-ost, for example) could exist as DB plugins.

decafninja将近 5 年前

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?

评论 #23977522 未加载

评论 #23921411 未加载

osigurdson将近 5 年前

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

silvester23将近 5 年前

> If you ever write bad data to a measurement in InfluxDB, there is no way to change itCorrect 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.

评论 #23916328 未加载

评论 #23916282 未加载

rweichler将近 5 年前

Figured I'd use this as an opportunity to plug my own service: <a href="https://eqe.fm" rel="nofollow">https://eqe.fm</a>Only works on jailbroken devices but it works well, has a local backup, and has been maintained (by me) for 2 years now.Server costs are $2.50/mo, so this will stay up as long as I am alive.

jbmsf将近 5 年前

I'd love to hear more about how your data ingestion works. I'm thinking of implementing TimescaleDB myself, but in my initial read of the docs, the focus seemed to be managing the database, not getting data into the database...

评论 #23919838 未加载

iEchoic将近 5 年前

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

评论 #23945583 未加载

thejosh将近 5 年前

I really want to love timescaledb, it's great.. except for the minor issue of not being able to back up.<a href="https://github.com/timescale/timescaledb/issues/1835" rel="nofollow">https://github.com/timescale/timescaledb/issues/1835</a>

评论 #23917831 未加载

评论 #23918298 未加载

评论 #23919057 未加载

评论 #23917900 未加载