ryanbooz

10 ms·

31.
by ryanbooz 5y ago
(Post author) This is a great post to give you some talking points: https://blog.timescale.com/blog/what-the-heck-is-time-series... I also love this recent one we did with some non-standard time-series data that the NF
32.
by ryanbooz 5y ago
We were using tags, so that "else" block isn't the one being used for ClickHouse. Regardless, the table that is created (by the community and verified by former CH engineers) orders by created_at, not time and so that query s
33.
by ryanbooz 5y ago
All the same tests. You simply pointed to a shell script that's configurable to run tests for each database. We provided details in the blog post of exactly what settings we used for each database (cardinality, batch size, time range,
34.
by ryanbooz 5y ago
(Post author) I'm not sure why you think that's creative engineering. What you're pointing to is the depth of available configuration that the contributors to TSBS have exposed for each database. It's totally open source
35.
by ryanbooz 5y ago
(Post author) Thanks for the compliment! It's becoming a habit with us and benchmarks. We just really want to dig in and understand what's going on and why things work the way they do. ;-) There really are so many nuances and as w
36.
by ryanbooz 5y ago
(N.B. post author) Thanks for the feedback. Without knowing your situation, one of the things we show in the blog post is that TimescaleDB compression often changes the game on those kinds of queries (data is transformed to columnar storage
37.
by ryanbooz 5y ago
[TimescaleDB DevRel here] Citus has been a great product and tool for helping to push the scaling story in Postgres and certainly has it's uses. That said, the three big differences that come to mind initially when talking about time-s
38.
by ryanbooz 5y ago
That's a great catch @xdanger and you're right, my comment wasn't accurate. Honestly I rewrote the response a few times and this part wasn't cleaned up which is totally on me. The overall concept that I was intending to
39.
by ryanbooz 5y ago
[Timescale DevRel here] @zX41ZdbW@ - Thanks for pointing out the various benchmarks that have been run by other companies between Clickhouse and TimescaleDB using TSBS[1]. As we mentioned, we'll dig deeper into a similar benchmark with
40.
by ryanbooz 5y ago
(Timescale DevRel here) We've recently been working through a detailed benchmark of TimescaleDB and Clickhouse. The DELETE/UPDATE question has been an intriguing story to follow - and I honestly hadn't considered the GDPR ang
41.
by ryanbooz 5y ago
Horizontal scaling within TimescaleDB is still geared around time-series data and (distributed) hypertables. https://docs.timescale.com/timescaledb/latest/how-to-guides/... https://docs.timescale.c
42.
by ryanbooz 5y ago
(DevRel at Timescale) The resurfacing of this article today is particularly interesting as I work on a new blog post and video talking about managing all aspects large-scale data, specifically geared towards time-series, but certainly appli
43.
by ryanbooz 6y ago
Thanks for sharing! Glad to hear it's been a successful venture for you. Hope we get to hear more about it at some point!
44.
by ryanbooz 6y ago
It's all detailed in the post (granted... it IS a detailed, long read ;-) TL;DR; - TimescaleDB was tested with a cloud setup in Digital Ocean, separate client and server. We actually ran a second, unpublished, test into Timescale Forge
45.
by ryanbooz 6y ago
TSBS did batch 100 metrics at a time, the max per request that Timestream allows. As we (and others) have suggested, this could easily be one of the reasons it's harder to ingest more quickly without significantly more threads. Timesca
46.
by ryanbooz 6y ago
We're happy for people to poke at this and helping us to improve. It's obviously hard to work at something for weeks, see the numbers (even knowing you really tried for days to move the needle) and then still publish numbers that
47.
by ryanbooz 6y ago
Please see below for correction... but at some point today a poster said "~2 weeks" for Timestream... but that's incorrect. We ran the data load/ingest for "~2 days" (40 hours). Just want to make sure the right
48.
by ryanbooz 6y ago
(Post author from Timescale) For the record, in reviewing HN conversation tonight I saw this and realized it was an incorrect quote of the article. Totally honest mistake I'm sure, but I wanted to set the record straight. We spent a li
49.
by ryanbooz 6y ago
> Another suggestion I'd make is to run the Amazon Timestream clients across multiple AZs if you aren't already. The blog post doesn't mention whether all the t3 instances are in the same AZ or not. They were all run in th
50.
by ryanbooz 6y ago
We've been hard at work with lots of great features for TimescaleDB 2.0, which should be GA in the next couple of weeks which makes multi-node available for anyone to use! There is a branch for PostgreSQL 13 support available for beta
51.
by ryanbooz 6y ago
While true, this is only the Apache-2 version. See @mfreed's response below for links and more detail.
52.
by ryanbooz 6y ago
Our experiments all ran on cloud instances (DO and Timescale Forge) that use storage that are replicated across multiple AZs/racks for greater reliability and fault tolerance.
53.
by ryanbooz 6y ago
Great summary, thanks! The two main things most developers will benefit from is how we manage the automatic partitioning of your incoming data (hypertables), something which is non-trivial to do yourself even though other tools exist for it
54.
by ryanbooz 6y ago
I'd just add that if you have any belief that your application will grow, and it's time-series in nature, there's usually only upside to starting with a time-series specific database now. The hoops you'll jump through as
55.
by ryanbooz 6y ago
This is a likely option, too. Your observations on pricing are keen. The one thing that threw me was querying. The limitations felt more Athena-like than PartiQL. And the billing based on scans felt almost like Redshift Spectrum. I mean, S3
56.
by ryanbooz 6y ago
(Disclaimer: post author and Timescale employee) I'm sorry you feel like we were trying to be dishonest in the post. On the contrary, we put a lot of effort (and 7,000+ words) into trying to explain everything that we did - just as we&
57.
by ryanbooz 6y ago
(Disclaimer: blog author and Timescale employee) There are two main points here. 1. To complete this benchmark workload, it took less than an hour in two different environments (Digital Ocean self-managed & Timescale Forge fully managed
58.
by ryanbooz 6y ago
Timescale is a freely available PostgreSQL extension built in the open, and anyone can contribute. That's one of the great things about PostgreSQL - it was built to be extensible and allow customization. YAY! Again, you're free to
59.
by ryanbooz 6y ago
We've made every effort to be open about all of the testing we do and many people outside of Timescale contribute to TSBS. As an aside, we tried to solicit help/feedback on both Twitter and Redit groups. One AWS employee reached o
60.
by ryanbooz 6y ago
TimescaleDB is purpose built for time-series data on Postgres. We offer native compression on this data and smart, easily adjustable partitioning, continuous and real-time analytics, automated time-series data management (retention, reorder

More ›