RobAtticus

11 ms·

61.
by RobAtticus 8y ago
Not sure I follow exactly what you're asking. You can do read replicas for HA/failover/read sharding which you can do with regular PostgreSQL databases as well. So at least on the axis TimescaleDB presents no limitations.
62.
by RobAtticus 8y 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 witho
63.
by RobAtticus 8y 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.t
64.
by RobAtticus 8y 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 o
65.
by RobAtticus 8y ago
It sounds like this is done via automatic registration, which solves a major objection that opponents of voter IDs in the USA generally have (i.e., IDs are too hard for some people to get to make them a prerequisite). Automatic registration
66.
by RobAtticus 8y ago
California is the highest state; DC is the highest of the regions listed at 20.2% vs California's 19% [2]. Also interesting to note that the rate in California has been dropping over the past few years - 20.6% avg for 2013/2014&#x
67.
by RobAtticus 8y ago
Nothing to share at the moment, but we appreciate you pinging them!
68.
by RobAtticus 8y ago
Just to give a little (estimated) timeline: * Currently our first release candidate is available via Github and Docker * We are aiming to release a 2nd release candidate next week * Sometime shortly after that (1-2 weeks) we'll go fina
69.
by RobAtticus 8y ago
The problem is you are talking about a different problem than the OP. The OP was talking about a few MB and CPU _from the server's perspective_, while you are talking about a few MB and CPU _from the client's perspective_. Yes it
70.
by RobAtticus 8y ago
The article mentions 100k page views being ~24MB extra a month, which means we are talking about a token of ~240 bytes. So for a single user you are talking about several kilobytes if they are multiple views to the server, which is now seve
71.
by RobAtticus 8y ago
Golang is not better than every other language in every single detail, yet gofmt uses tabs...
72.
by RobAtticus 8y ago
>What is the way to create indexes after data migration? You can migrate the data and then do the normal PostgreSQL `CREATE INDEX` syntax to create the indexes on the hypertable. It's not an option to create_hypertable or anything,
73.
TSDBs at Scale – Part Two(circonus.com)
5 points by RobAtticus 8y ago|0 comments
74.
by RobAtticus 8y ago
Gotcha, no worries :)
75.
by RobAtticus 8y ago
Thanks for the kind words! Yes, we are definitely looking to expand our use cases to support a variety of scenarios and parameters so that we can give the most comprehensive evaluation for people looking to store time series data. And not y
76.
by RobAtticus 8y ago
Whoa, happy to see this here so quickly after we published. I'm one of the main authors of this tool (with lots of help from the team here at Timescale), so happy to answer any questions! Feedback welcome too :) I'll also note tha
77.
by RobAtticus 8y ago
This blog posts compares SQL with Flux, a query language from Influx. Flux blog post: https://www.influxdata.com/blog/why-were-building-flux-a-new... Previous HN discussion on that post: https://news.ycombin
78.
by RobAtticus 8y ago
I think his point was as a consumer it is difficult to know your final bill since some items are exempt, some are taxed at a lower rate, etc.
79.
How to store time-series data in MongoDB, and why that’s a bad idea(blog.timescale.com)
13 points by RobAtticus 8y ago|1 comments
80.
by RobAtticus 8y ago
>TimescaleDB is currently limited to time-based partitioning To be clear, TimescaleDB supports partitioning by other dimensions, as long as one dimension is time-based. That is, one partition must be time based, but you can additional di
81.
by RobAtticus 8y ago
>They did not graph write speed in the article though, which was a bit disappointing, so I assume the difference was negligible Did you mean query performance? There are write speed/insert numbers under "Insert performance meas
82.
by RobAtticus 8y ago
Somewhat related article (re: IoT platforms): https://www.slideshare.net/kartben/iot-developer-survey-2018 Those of us at TimescaleDB hope to see PostgreSQL move up in the rankings (at least pass 'Don't Know&
83.
by RobAtticus 9y ago
>Look beyond those selective statistics, FB.com is dead. That's a bit of a strange conclusion when their financials show increasing revenue and increasing profit, quarter over quarter and year over year. From 2016 to 2017 their reve
84.
by RobAtticus 9y ago
I'll second this one. Very easy to read and flows really well in my opinion. He builds up ideas very naturally with just the right balance of academic and colloquial.
85.
by RobAtticus 9y ago
Re: setting up a cluster With TimescaleDB we've focused on single node performance to try and reduce the need for clustering. We've found performance scales very well just by adding more disk space if needed and more cores. So may
86.
by RobAtticus 9y ago
That is currently next in our pipeline for a benchmark blog post. Early results look good on both the read and write side in terms of raw performance, with the benefit of more complex queries being more easily expressable.
87.
by RobAtticus 9y ago
We do support UPSERTs: http://docs.timescale.com/v0.8/using-timescaledb/writing-dat... There is one limitation mentioned there ("TimescaleDB does not yet support using ON CONFLICT ON CONSTRAINT with a named k
88.
by RobAtticus 9y ago
Thanks! We're continuing to try and get that accomplished ourselves. It always helps for them to hear from potential users to let them know there is demand for it. We have an issue with instructions tracking this: https://gi
89.
by RobAtticus 9y ago
We touched on this a bit elsewhere when someone asked about InfluxDB. One of the biggest advantages is that by being built on Postgres, we are able to support the full range of SQL/RDBMS features including secondary indices, complex WH
90.
by RobAtticus 9y ago
Our open source version already supports some forms of scaling/clustering today: e.g., read-only replicas for hot standbys and increasing query throughput. Timescale also supports hundreds of thousands of row inserts (millions of metri

More ›